httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: [SPAM?]: Re: Behavior of Host: vs. SNI Hostname in proxy CONNECT requests
Date Wed, 11 Dec 2013 23:51:43 GMT
On Thu, Dec 12, 2013 at 12:20 AM, William A. Rowe Jr.
<wrowe@rowe-clan.net>wrote:

> On Tue, 26 Nov 2013 18:47:39 +0100
> Peter Sylvester <peter.sylvester@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.

Mime
View raw message