On 08/29/2008 07:09 AM, Kaspar Brand wrote: >> Making SNI support configurable at runtime also seems a more attractive >> solution to me - it would basically mean that in ssl_init_ctx(), the SNI >> callback is not registered unless it's explicitly configured. I would >> suggest using something like >> >> SSLEnableSNI port [port] ... >> >> which would be used as a per-server directive (i.e. not within vhosts, >> only globally) and enable SNI on the specified ports. > > Attached is a proof of concept for such an "SSLEnableSNI" config > directive (for 2.2.x only). > > Will need more fine-tuning, most likely, but I would appreciate to get > feedback whether this is considered a feasible approach - thanks.
With the current patches applied to trunk we are now pursuing a different way to handle SNI enablement: As said several times we consider name based virtual hosting for SSL *without* SNI as not recommended and insecure. This has not changed with the SNI patches applied to trunk. Thus we came up with the following behaviour: If you compile httpd against an TLS extension enabled Openssl then IP based virtual hosting with SSL works as before. This means with SNI enabled clients as well as with not SNI enabled clients. Name based virtual hosting with SSL does *only* work with SNI *enabled* clients. Not SNI enabled clients receive a 403 when contacting any of the name based virtual hosts (which enables you to set a nice error page to explain to the user what happened and which browser to use). We discussed creating a directive that would disable this behaviour and would allow not SNI enabled clients to still work. But as this directive would have a documentation that says: Don't ever use it we saw no sense in this. But thanks for the patch anyway. Regards Rüdiger
