Bug 34607 - Support for Server Name Indication
Support for Server Name Indication
Status: RESOLVED FIXED
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl
2.5-HEAD
All All
: P1 enhancement with 33 votes (vote)
: ---
Assigned To: Apache HTTPD Bugs Mailing List
:
Depends on:
Blocks:
  Show dependency tree
 
Reported: 2005-04-25 22:01 UTC by Paul Querna
Modified: 2014-02-17 13:59 UTC (History)
18 users (show)



Attachments
Patch for SNI support in Apache 2.2 or later (6.65 KB, patch)
2007-03-07 02:27 UTC, Kaspar Brand
Details | Diff
Patch against SNI code as currently available in trunk (13.97 KB, patch)
2008-01-09 03:44 UTC, Kaspar Brand
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Paul Querna 2005-04-25 22:01:05 UTC
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.
Comment 1 Paul Querna 2005-10-23 19:24:49 UTC
IE 7, Beta 2 includes support for TLS Server Name Indication:
http://blogs.msdn.com/ie/archive/2005/10/22/483795.aspx

Comment 2 Joe Orton 2006-01-06 10:38:56 UTC
Looks like the OpenSSL side of this is being done for 0.9.9!
Comment 3 Kaspar Brand 2006-04-20 16:12:17 UTC
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... ;-)
Comment 4 William A. Rowe Jr. 2006-07-18 18:57:54 UTC
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.
Comment 5 Yusuf Goolamabbas 2007-03-06 08:12:34 UTC
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
Comment 6 Kaspar Brand 2007-03-07 02:27:34 UTC
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.
Comment 7 Dr Stephen Henson 2007-08-29 09:39:40 UTC
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".
Comment 8 Rainer Jung 2007-10-14 07:03:52 UTC
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]
Comment 9 Dr Stephen Henson 2007-10-19 06:00:37 UTC
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.
Comment 10 Dr Stephen Henson 2007-11-16 16:24:06 UTC
(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.
Comment 11 Guenter Knauf 2007-12-21 07:41:16 UTC
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).

Comment 12 William A. Rowe Jr. 2008-01-07 10:32:25 UTC
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).
Comment 13 Kaspar Brand 2008-01-09 03:44:07 UTC
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)
Comment 14 Guenter Knauf 2008-01-11 17:04:27 UTC
(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).

Comment 15 Guenter Knauf 2008-01-11 17:18:55 UTC
(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 16 Kaspar Brand 2009-04-08 09:11:53 UTC
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]).
Comment 17 Diego Caravana 2009-04-19 07:03:00 UTC
(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
Comment 18 Kaspar Brand 2009-05-23 00:34:53 UTC
Backport committed to 2.2.x: r776281