This is a tracking bug for supporting 'Server Name Indication' in mod_ssl, as specified in RFC 3546. This is currently blocking on OpenSSL supporting the required bits upstream.
IE 7, Beta 2 includes support for TLS Server Name Indication: http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx
Looks like the OpenSSL side of this is being done for 0.9.9!
What do you think of this patch? http://www.edelweb.fr/EdelKey/files/apache-2.2.0+0.9.9+servername.patch I'm using a slightly modified version of this patch on my Apache-2.2.0-plus-mod_ssl-linked-against-openssl-SNAP SNI test server, which is available at https://sni.velox.ch https://alice.sni.velox.ch https://carol.sni.velox.ch https://bob.sni.velox.ch https://dave.sni.velox.ch https://mallory.sni.velox.ch https://www.sni.velox.ch https://test.sni.velox.ch (and so on) I'm aware of mod_gnutls, written by the original reporter of this bug - but nevertheless I think it would be useful to have SNI support in mod_ssl, too... ;-)
FYI... patches outside of the 'asf' domain are under any arbitrary license the author designates. Patches submitted (attached to the bug database, emailed to dev@httpd mailing list, etc) by the original author are submitted (by the ASL 2.0) under the terms of the Apache Software License 2.0 - which would be required for the patch to be considered for incorporation into the httpd code base. If you want to attach your patch to this incident under ASL 2 we would be happy to consider it. Obviously, OpenSSL support is still a gating factor.
As per comment #4, the author of the patch indicated in #3 has emailed it to dev@httpd which can be seen from this link to an archive http://marc.theaimsgroup.com/?l=apache-httpd-dev&m=117311733932367&w=2 Would request that this patch be now considered for review
Created attachment 19676 [details] Patch for SNI support in Apache 2.2 or later For the sake of completeness, I'm attaching the modified version of Peter's patch, which I have been using on the test site mentioned above since April 2006. Here is a short overview of my modifications: 1) in set_ssl_vhost(), I've added checks for the ServerAlias directive, so that certificates with multiple dNSName entries in the subjectAltName extension can be used, too (these checks are reusing code from matches_aliases() in vhost.c); 2) #ifdef'd the warning "You should not use name-based virtual hosts in conjunction with SSL!!" - i.e. suppress this message if SNI support is compiled in; 3) in ssl_hook_Access(), limited the change of the SSL_CTX to the case where tlsext_hostname isn't set yet (in all other cases, leave it at the default VirtualHost - we no longer have to return HTTP_FORBIDDEN); 4) in ssl_hook_Fixup(), inserted an additional environment variable (TLS_SNI) which can be used later on to determine if (and what) SNI extension the client sent (e.g. in CGI scripts, or when using CustomLog); 5) adapted indentation (spaces instead of tabs). The diff is against 2.2.x, but applies cleanly against (and seems to work ok with) trunk, too.
Note that SNI support has been backported to OpenSSL 0.9.8 but not official release contains it yet, 0.9.8f will be the first. TLS extension support is disabled by default in OpenSSL 0.9.8 and must be explicitly enabled at compile time using "enable-tlsext".
OpenSSL 0.9.8f got released recently. The changelog confirms inclusion of the needed extension: *) Add initial support for TLS extensions, specifically for the server_name extension so far. The SSL_SESSION, SSL_CTX, and SSL data structures now have new members for a host name. The SSL data structure has an additional member SSL_CTX *initial_ctx so that new sessions can be stored in that context to allow for session resumption, even after the SSL has been switched to a new SSL_CTX in reaction to a client's server_name extension. New functions (subject to change): SSL_get_servername() SSL_get_servername_type() SSL_set_SSL_CTX() New CTRL codes and macros (subject to change): SSL_CTRL_SET_TLSEXT_SERVERNAME_CB - SSL_CTX_set_tlsext_servername_callback() SSL_CTRL_SET_TLSEXT_SERVERNAME_ARG - SSL_CTX_set_tlsext_servername_arg() SSL_CTRL_SET_TLSEXT_HOSTNAME - SSL_set_tlsext_host_name() openssl s_client has a new '-servername ...' option. openssl s_server has new options '-servername_host ...', '-cert2 ...', '-key2 ...', '-servername_fatal' (subject to change). This allows testing the HostName extension for a specific single host name ('-cert' and '-key' remain fallbacks for handshakes without HostName negotiation). If the unrecogninzed_name alert has to be sent, this by default is a warning; it becomes fatal with the '-servername_fatal' option. [Peter Sylvester, Remy Allais, Christophe Renou, Steve Henson]
Note that it is possible to reliably check if TLS extension support is in OpenSSL at compile time by seeing if the version number is 0.9.8f or later and that OPENSSL_NO_TLSEXT is *not* defined.
(In reply to comment #9) > Note that it is possible to reliably check if TLS extension support is in > OpenSSL at compile time by seeing if the version number is 0.9.8f or later and > that OPENSSL_NO_TLSEXT is *not* defined. The logic used in the patch: #ifndef OPENSSL_NO_TLSEXT #ifndef SSL_CTRL_SET_TLSEXT_HOSTNAME #define OPENSSL_NO_TLSEXT #endif #endif is also fine for detecting extension support in OpenSSL. The result being that support will only be included if compiled against a version of OpenSSL supporting TLS extensions.
committed slightly modified (env var prefixed with 'SSL_') to trunk now: http://svn.apache.org/viewvc?rev=606190&view=rev also I've created a patch for the httpd 2.0.x line: http://people.apache.org/~fuankg/diffs/httpd-2.0.x-sni.diff perhaps useful for those who might need it (as a customer asked me for).
Since SSL Upgrade wasn't accepted for backport to 2.0, I'm guessing we won't rally the support for backporting this either, although it's most kind of you to post this for users who are interested, Guenter. We can try getting folks behind backporting this to 2.2 sometime in the near future (although preferably not in the immediately pending release).
Created attachment 21365 [details] Patch against SNI code as currently available in trunk (In reply to comment #12) > We can try getting folks behind backporting this to 2.2 sometime in the near > future (although preferably not in the immediately pending release). What are the chances of getting it into 2.2.8, nevertheless? I'm attaching a diff against the current trunk version (committed by Guenter on 2007-12-21/2007-12-29), which basically reflects the version I posted to httpd-dev (see http://mail-archives.apache.org/mod_mbox/httpd-dev/200801.mbox/%3c477BBD86.9020600@velox.ch%3e). It also includes a fix for an issue with SSLVerifyClient in the version posted to httpd-dev on 2008-01-02 I discovered in the meantime (per-directory restrictions were no longer working properly). A backport of this latest version of the code for 2.2.x is available at http://sni.velox.ch/httpd-2.2.x-sni.diff (Guenter, feel free to copy this to people.apache.org)
(In reply to comment #13) > Created an attachment (id=21365) [edit] > Patch against SNI code as currently available in trunk commited: http://svn.apache.org/viewvc?rev=611216&view=rev > A backport of this latest version of the code for 2.2.x is available at > http://sni.velox.ch/httpd-2.2.x-sni.diff > (Guenter, feel free to copy this to people.apache.org) thanks, did that so that the backport proposal points now to the fixed diff: http://people.apache.org/~fuankg/diffs/httpd-2.2.x-sni.diff also I've created a new patch for the httpd 2.0.x line: http://people.apache.org/~fuankg/diffs/httpd-2.0.x-sni.diff this depends also on this patch: http://people.apache.org/~fuankg/diffs/httpd-2.0.x-ap_vhost_iterate_given_conn.diff perhaps useful for those who might need it (as a customer asked me for).
(In reply to comment #12) > Since SSL Upgrade wasn't accepted for backport to 2.0, I'm guessing we won't > rally the support for backporting this either, well, sure I'm all after getting folks to use latest. Unfortunately that is not always possible. There are many many users out who are bound to a specific Apache line, f.e. many Oracle users are still stick with the 1.3.x line; on NetWare we have the issue that we have a couple of non-opensource modules which we have only for 2.0.x line available, and this situation will never change I guess; f.e. we have an iPrint module running on 2.0.x line, and we cant users just force to upgrade to later 2.2.x since they would loose iPrint functionality. Same goes for at least 4 other modules too; so this might be a reason why Brad suggested backporting SSL Upgrade. I think that such situations with commercial Apache modules happen to a lot of users on other platforms too, and we should probably discuss this again from this point of view. Currently I see no good reason why we should force those users to either go without these enhancements, or to patch self / use unofficial builds. Gün.
Comment on attachment 21365 [details] Patch against SNI code as currently available in trunk This patch is more than obsolete, actually. Since January 2008, a lot of improvements have been checked into trunk (e.g. Rüdiger's recent work on storing the server_rec in the proper place [http://svn.apache.org/viewvc?view=rev&revision=757463]).
(In reply to comment #16) > (From update of attachment 21365 [details]) > This patch is more than obsolete, actually. Since January 2008, a lot of > improvements have been checked into trunk (e.g. Rüdiger's recent work on > storing the server_rec in the proper place > [http://svn.apache.org/viewvc?view=rev&revision=757463]). So there's any chance that we'll see a back-port of the changes related to SNI to Apache 2.2? Diego
Backport committed to 2.2.x: r776281