httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yann Ylavic <>
Subject Re: svn commit: r1585090 - in /httpd/httpd/trunk: CHANGES modules/ssl/ssl_engine_init.c modules/ssl/ssl_engine_kernel.c
Date Fri, 18 Apr 2014 09:11:26 GMT
On Fri, Apr 18, 2014 at 10:34 AM, Kaspar Brand <> wrote:
> On 16.04.2014 16:00, Yann Ylavic wrote:
>> Before this commit, the client knew it was not reaching any vhost by
>> receiving an SSL alert (warning), and could stop.
> In practice, most SNI-capable clients have ignored these warning-level
> alerts (which is completely in line with RFC 5246, which states "If an
> alert with a level of warning is sent and received, generally the
> connection can continue normally").
> Whether or not the server acknowledges to have a suitable cert for the
> name requested by the client in the SNI extension isn't that relevant,
> IMO. The most important (and absolutely essential) thing the client has
> to do is to check the expected name against those included in the
> certificate (RFC 6125, acceptable reference identifiers vs. presented
> identifiers), irrespective of any potential TLS warning-level alert he
> might have received on the connection.

Agreed, still it may be useful (for some potential client) to get the
real error when it handshakes with an SNI which is not acceptable on
this server, and for the server the sooner the better IMHO.

>> The new option would prevent the default vhost to be used (when SNI is
>> available), and let the client know (still).
> As pointed out by RĂ¼diger in his latest message, there is no point in
> disallowing access to the default vhost based on whether an SNI
> extension was sent by the client or not: the default vhost is
> effectively the "global" one for SSL connections - "SSLEngine on" should
> only be configured within vhosts, see also [1]. Ever since mod_ssl was
> added to 2.0.x [2], a "_default_:443" vhost was used to handle all SSL
> requests.

Well, if one want to be really strict about SNI, and don't have a
wildcard cert (say the poor man, still with multiple name-based
vhost), is the default SSL vhost relevant?

I'm not arguing about setting this by default, nor we can't do it
another way, but that it's a legitimate situation where one could want
to deny at handshake time, with the relevant message for the client to
know why (instead of 400, 503 or even bad cert which just leaks
another service).

> Thanks for your vote with r1588257, Yann, in any case - now merged to
> 2.4.x with r1588424.

You're welcome, this could be done in a second step :p


View raw message