Re: [SPAM?]: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests

["William A. Rowe Jr." <wr...@rowe-clan.net>]

On Tue, 26 Nov 2013 18:47:39 +0100
Peter Sylvester <pe...@edelweb.fr> wrote:

> Hi:
> 
> On 11/26/2013 06:18 PM, Kaspar Brand wrote:
> > On 26.11.2013 09:29, Yann Ylavic wrote:
> >> Another point is that SNI can not be an IP address according to
> >> the RFC 6066 :
> >>
> >> 3.  Server Name Indication
> >>     [...]
> >>     Literal IPv4 and IPv6 addresses are not permitted in
> >> "HostName".
> >>
> >> and this is not specifically checked by mod_proxy before filling
> >> SNI.
> >>
> >> Shouldn't the SNI be ommited when the Host is missing/empty or an
> >> IP address too?
> > Yes, ssl_engine_io.c:ssl_io_filter_handshake() takes care of that.
> > (I argued for adding this to OpenSSL back in 2009 [1], but one
> > reaction was "is not exactly a nice thing" and "Looks ugly" [2].)
> Hi,
> 
> Since I am the culprit about that hasty response :-)
> 
> The "design" for sni is: The protocol is between the applications.
> 
> The best thing that the client part in openssl would check is whether
> the servername is syntactically a fqdn, and the server could validate
> this. well, then someone will ask about validation of I18N names

Not really, punycode are syntactically normal dns entries, by design the
i18n mapping was designed not to break yesterday's dns conventions.  The
cert needs to use the punycode representation in the CN

> OpenSSL does not check such things AFAIK. It is not an application
> level firewall. For example, there is no code to check whether a
> hostname matches a certificate, etc.

In fighting with the current logic, I note that we only test the literal
CN, without any consideration of wildcards, alt-subject names, etc.

Is there any openssl logic to help an application author ask 'is this
name foo.example.com represented by this certificate?' in CN/alt name,
testing wildcard expansion?  Writing parsers is easy.  Writing them
correctly is error prone :)

Re: [SPAM?]: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests

[Yann Ylavic <yl...@gmail.com>]

On Thu, Dec 12, 2013 at 12:20 AM, William A. Rowe Jr.
<wr...@rowe-clan.net>wrote:

> On Tue, 26 Nov 2013 18:47:39 +0100
> Peter Sylvester <pe...@edelweb.fr> wrote:
>
> > Hi:
> >
> > On 11/26/2013 06:18 PM, Kaspar Brand wrote:
> > > On 26.11.2013 09:29, Yann Ylavic wrote:
> > >> Another point is that SNI can not be an IP address according to
> > >> the RFC 6066 :
> > >>
> > >> 3.  Server Name Indication
> > >>     [...]
> > >>     Literal IPv4 and IPv6 addresses are not permitted in
> > >> "HostName".
> > >>
> > >> and this is not specifically checked by mod_proxy before filling
> > >> SNI.
> > >>
> > >> Shouldn't the SNI be ommited when the Host is missing/empty or an
> > >> IP address too?
> > > Yes, ssl_engine_io.c:ssl_io_filter_handshake() takes care of that.
> > > (I argued for adding this to OpenSSL back in 2009 [1], but one
> > > reaction was "is not exactly a nice thing" and "Looks ugly" [2].)
> > Hi,
> >
> > Since I am the culprit about that hasty response :-)
> >
> > The "design" for sni is: The protocol is between the applications.
> >
> > The best thing that the client part in openssl would check is whether
> > the servername is syntactically a fqdn, and the server could validate
> > this. well, then someone will ask about validation of I18N names
>
> Not really, punycode are syntactically normal dns entries, by design the
> i18n mapping was designed not to break yesterday's dns conventions.  The
> cert needs to use the punycode representation in the CN
>
> > OpenSSL does not check such things AFAIK. It is not an application
> > level firewall. For example, there is no code to check whether a
> > hostname matches a certificate, etc.
>
> In fighting with the current logic, I note that we only test the literal
> CN, without any consideration of wildcards, alt-subject names, etc.
>
> Is there any openssl logic to help an application author ask 'is this
> name foo.example.com represented by this certificate?' in
> 
> CN/alt name,
> testing wildcard expansion?  Writing parsers is easy.  Writing them
> correctly is error prone :)
>

CN/SubjectAltName and wildcards are addressed in r1425874 (from PR54030).
(with a comment about X509_check_host() available in openssl-1.0.2 only).

Hope this helps.

Re: [SPAM?]: Re: [SPAM?]: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests

[Peter Sylvester <pe...@edelweb.fr>]

On 12/12/2013 12:20 AM, William A. Rowe Jr. wrote:
> On Tue, 26 Nov 2013 18:47:39 +0100
> Peter Sylvester <pe...@edelweb.fr> wrote:
>
>> Hi:
>>
>> On 11/26/2013 06:18 PM, Kaspar Brand wrote:
>>> On 26.11.2013 09:29, Yann Ylavic wrote:
>>>> Another point is that SNI can not be an IP address according to
>>>> the RFC 6066 :
>>>>
>>>> 3.  Server Name Indication
>>>>      [...]
>>>>      Literal IPv4 and IPv6 addresses are not permitted in
>>>> "HostName".
>>>>
>>>> and this is not specifically checked by mod_proxy before filling
>>>> SNI.
>>>>
>>>> Shouldn't the SNI be ommited when the Host is missing/empty or an
>>>> IP address too?
>>> Yes, ssl_engine_io.c:ssl_io_filter_handshake() takes care of that.
>>> (I argued for adding this to OpenSSL back in 2009 [1], but one
>>> reaction was "is not exactly a nice thing" and "Looks ugly" [2].)
>> Hi,
>>
>> Since I am the culprit about that hasty response :-)
>>
>> The "design" for sni is: The protocol is between the applications.
>>
>> The best thing that the client part in openssl would check is whether
>> the servername is syntactically a fqdn, and the server could validate
>> this. well, then someone will ask about validation of I18N names
> Not really, punycode are syntactically normal dns entries, by design the
> i18n mapping was designed not to break yesterday's dns conventions.  The
> cert needs to use the punycode representation in the CN
yes, the client application sets such value into the SNI.
what I wanted to say is that at least in our patch to
openssl we did not add a convenience layer allowing
to present a i18n name in unicode or utf8 and create
the corresponding value and reject invalid things etc.
An openssl client can set whatever chain of characters
it wants. I mentioned checking fqdn just as an example
of a can of worms. The api does not pretend to check valid
dns name, not the restriction of ip addresses, nothing.
It is the server that has to check for  possible garbage.

also, there is no check against whatever is in the
returned ... client middleware like curl do this.
furthermore, for curl, the application also uses
a possibly i18n encoded value as input.


>
>> OpenSSL does not check such things AFAIK. It is not an application
>> level firewall. For example, there is no code to check whether a
>> hostname matches a certificate, etc.
> In fighting with the current logic, I note that we only test the literal
> CN, without any consideration of wildcards, alt-subject names, etc.
>
> Is there any openssl logic to help an application author ask 'is this
> name foo.example.com represented by this certificate?' in CN/alt name,
> testing wildcard expansion?  Writing parsers is easy.  Writing them
> correctly is error prone :)
There used to be no such code in openssl.
(there is such code in gnutls AFAIK)

Therefore there is code in client libraries, e.g. curl.

best regards