httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <ylavic....@gmail.com>
Subject Re: svn commit: r1585090 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c
Date Wed, 16 Apr 2014 12:15:48 GMT
On Sat, Apr 5, 2014 at 2:57 PM,  <kbrand@apache.org> wrote:
> Author: kbrand
> Date: Sat Apr  5 12:57:43 2014
> New Revision: 1585090
>
> URL: http://svn.apache.org/r1585090
> Log:
> Bring SNI behavior into better conformance with RFC 6066:
>
> - no longer send a warning-level unrecognized_name(112) alert
>   when no matching vhost is found (PR 56241)

>From a client perspective, it is a loss of information, couldn't the
admin have an option ...

> +                /*
> +                 * RFC 6066 section 3 says "It is NOT RECOMMENDED to send
> +                 * a warning-level unrecognized_name(112) alert, because
> +                 * the client's behavior in response to warning-level alerts
> +                 * is unpredictable."
> +                 *
> +                 * To maintain backwards compatibility in mod_ssl, we
> +                 * no longer send any alert (neither warning- nor fatal-level),
> +                 * i.e. we take the second action suggested in RFC 6066:
> +                 * "If the server understood the ClientHello extension but
> +                 * does not recognize the server name, the server SHOULD take
> +                 * one of two actions: either abort the handshake by sending
> +                 * a fatal-level unrecognized_name(112) alert or continue
> +                 * the handshake."
> +                 */

for the first action suggested in the RFC?

This base_server directive would help prevent vhost misuse at the
source, whatever the vhosts' configs are, and however we relax the
Host vs SNI check.
Thus one can trust httpd's (base) config to know whether or not the
handshake has reached the requested vhost.
This is already/always the case currently, the difference is when it
takes place (before vhosting), and the SSL level alert (vs "400 Bad
Request" now) that would help the client to know what's happening.

That option would cause empty SNI to be refused too, and maybe
multiple SSL vhosts on the same IP:port to be error-ed on startup
(when SNI is available in the underlying lib).
Whether it should be on/off by default depends on the change
introduced by this commit (SSL alert warning => 400) and how clients
handle warning level SSL alerts.

I may be misleaded though...

Regards,
Yann.

Mime
View raw message