You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Gervase Markham <ge...@mozilla.org> on 2009/01/22 06:09:25 UTC
TLS/SNI status
Hi,
Short version: I am hoping to find out what the problems are with the
trunk version of TLS/SNI, how they can be fixed, and what the chances
are of a backport to 2.2.
Long version:
The Mozilla project is very interested in the wide and easy use of SSL,
and therefore the wide adoption of TLS/SNI, a TLS extension which
permits multiple SSL sites on a single IP. The lack of need for a static
IP, combined with very cheap certs, makes SSL accessible for almost
everyone. Support for TLS/SNI has been in Firefox since version 2.0, and
IE since version 7, and I believe is in all other major browsers. I
believe IIS supports it also.
As most of you will know, supporting it in Apache requires changes to
OpenSSL (which we funded, and which went into version 0.9.8f) and to the
httpd itself. These have now gone in to the trunk[0]. However, it's top
of the "STALLED" list in the 2.2 STATUS file[1], with a note talking
about "problems with the trunk version".
I'm hoping to learn about what those problems are, what the prospects
are for getting them resolved and then, assuming they are, what the
prospects are for a backport. (Notes in that STATUS file suggest that a
backport might not be appropriate even if the issues were fixed.)
Many thanks to anyone who can shed some light :-)
Gerv
[0] http://svn.apache.org/viewvc?view=rev&revision=606190
[1] http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/STATUS
Re: TLS/SNI status
Posted by Peter Sylvester <pe...@edelweb.fr>.
Gervase Markham wrote:
> Peter Sylvester wrote:
>
>>> As most of you will know, supporting it in Apache requires changes to
>>> OpenSSL (which we funded, and which went into version 0.9.8f) and to the
>>> httpd itself.
>>>
>> I am certainly not one of those "most".
>>
>
> I apologise for the ambiguity; I meant to say that most of you will know
> what supporting TLS/SNI requires (because my default polite position is
> to assume those on a technical mailing list know a lot more than me),
> not that most of you will know that we funded it. My intent was not to
> boast.
>
> And, in fact, looking at our records I am mistaken. It was OCSP stapling
> we funded. My apologies. Please ignore those three words.
>
> Gerv
>
Thanks for the clarification. Errors can happen.
/P
Re: TLS/SNI status
Posted by Gervase Markham <ge...@mozilla.org>.
Peter Sylvester wrote:
>> As most of you will know, supporting it in Apache requires changes to
>> OpenSSL (which we funded, and which went into version 0.9.8f) and to the
>> httpd itself.
> I am certainly not one of those "most".
I apologise for the ambiguity; I meant to say that most of you will know
what supporting TLS/SNI requires (because my default polite position is
to assume those on a technical mailing list know a lot more than me),
not that most of you will know that we funded it. My intent was not to
boast.
And, in fact, looking at our records I am mistaken. It was OCSP stapling
we funded. My apologies. Please ignore those three words.
Gerv
Re: TLS/SNI status
Posted by Peter Sylvester <pe...@edelweb.fr>.
Gervase Markham wrote:
>
> As most of you will know, supporting it in Apache requires changes to
> OpenSSL (which we funded, and which went into version 0.9.8f) and to the
> httpd itself.
I am certainly not one of those "most". I am not aware about
external funding for the pieces mentioned in the
CHANGES files in the dev 0.9.9 branch of openssl.
*) 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]
Re: TLS/SNI status
Posted by Ruediger Pluem <rp...@apache.org>.
On 01/22/2009 12:32 PM, Graham Leggett wrote:
> Gervase Markham wrote:
>
>> Short version: I am hoping to find out what the problems are with the
>> trunk version of TLS/SNI, how they can be fixed, and what the chances
>> are of a backport to 2.2.
>
> According to STATUS:
>
> +1: fuankg
> +0: like ssl upgrade of 2.2, perhaps this is a good reason to bring
> httpd-2.4 to completion? vhost changes could be disruptive to
> third party module authors.
> -1: rpluem: jorton found some problems with the trunk version and
> they
> should be fixed / discussed in trunk before we backport.
> pquerna: Until issues for this feature are fixed in trunk, we
> can not
> backport it.
>
> Can the various people above clarify exactly which issues are
> outstanding for the above?
>
> Searching for jorton and SNI finds a whole lot of development
> discussion, but no concise description of issues outstanding.
IMHO Joe had security concerns that different security sensitive SSL configurations on
different name based virtual hosts do not work as expected and the configuration of the
default host might apply. If the default host has less strict configuration settings
this can open up unexpected security issues.
But yes, I would love to see a list of the outstanding issues as well so that we can work on it.
Currently SNI is on the top of my list for the upcoming Hackathon at AC EU. I hope to get
hold of Joe there :-).
Regards
Rüdiger
Re: TLS/SNI status
Posted by Graham Leggett <mi...@sharp.fm>.
Gervase Markham wrote:
> Short version: I am hoping to find out what the problems are with the
> trunk version of TLS/SNI, how they can be fixed, and what the chances
> are of a backport to 2.2.
According to STATUS:
+1: fuankg
+0: like ssl upgrade of 2.2, perhaps this is a good reason to bring
httpd-2.4 to completion? vhost changes could be disruptive to
third party module authors.
-1: rpluem: jorton found some problems with the trunk version and
they
should be fixed / discussed in trunk before we backport.
pquerna: Until issues for this feature are fixed in trunk, we
can not
backport it.
Can the various people above clarify exactly which issues are
outstanding for the above?
Searching for jorton and SNI finds a whole lot of development
discussion, but no concise description of issues outstanding.
For the benefit of people wanting to know what criteria there are for
backporting patches to previous versions of httpd, binary ABI
compatibility is crucial to make sure that third party modules will stay
working when httpd is upgraded to a new point release.
If the changes involve amendments to data structures that render the ABI
incompatible (and depending on the impact of the change, sometimes this
is unavoidable), the backport cannot happen, and the feature will only
be available in the next version of httpd, which is v2.4.
Efforts are underway to begin releasing alpha versions of what is to
become httpd v2.4, so SNI support is not far away regardless.
Regards,
Graham
--
Re: TLS/SNI status
Posted by Graham Leggett <mi...@sharp.fm>.
Joe Orton wrote:
> Making sure that mod_ssl's existing access control options work
> correctly in an SNI configuration is the critical item (and has proven
> to be non-trivial), otherwise it opens up security holes.
>
> Kaspar Brand did a bunch of great work on this last year; I have not had
> time to fully review and integrate that yet. There is an outstanding
> patch from Kaspar which is not on the trunk yet, the thread below has
> the details:
>
> http://thread.gmane.org/gmane.comp.apache.devel/34360/focus=34493
Is there a bugzilla entry that keeps track of this?
I keep seeing criticism on various lists from people who see SNI stalled
but don't know why, it would be great to be able to tell them "go see
bug X, add your 2c".
Regards,
Graham
--
Re: TLS/SNI status
Posted by Joe Orton <jo...@redhat.com>.
On Thu, Jan 22, 2009 at 04:09:25PM +1100, Gervase Markham wrote:
> Short version: I am hoping to find out what the problems are with the
> trunk version of TLS/SNI, how they can be fixed, and what the chances
> are of a backport to 2.2.
Making sure that mod_ssl's existing access control options work
correctly in an SNI configuration is the critical item (and has proven
to be non-trivial), otherwise it opens up security holes.
Kaspar Brand did a bunch of great work on this last year; I have not had
time to fully review and integrate that yet. There is an outstanding
patch from Kaspar which is not on the trunk yet, the thread below has
the details:
http://thread.gmane.org/gmane.comp.apache.devel/34360/focus=34493
Regards, Joe