Fix for the TLS renegotiation bug
Daniel Veditz
nightlies implement the new TLS spec to prevent the renegotiation
flaw. The fixes in NSS can also be used to build your own patched
version of moz_nss for apache.
Huge thanks to Nelson Bolyard for implementing the spec in NSS and
Kai Engert for the client (Firefox) integration piece.
To solve the problem for real in the long run both servers and
clients need to be patched, and patched clients and servers must not
talk to unpatched servers and clients. In the short run that's
unrealistic so the Firefox settings are currently extremely
permissive, but paranoid users who only need to talk to a couple of
servers that they know are patched could make it strict if they like.
Test server at https://ssltls.de
Firefox nightlies have been patched since Feb 8 or 9
https://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
Kai's write-up on the various client options
https://wiki.mozilla.org/Security:Renegotiation
Official RFC (released Friday)
http://tools.ietf.org/html/rfc5746
Currently the only change in Firefox behavior is that it will not
RE-negotiate with an unpatched server--but it will complete an
initial handshake so it's still vulnerable to the flaw. This will
break client-auth in most cases so there's a global pref that allows
unsafe renegotiation, and another pref so you could whitelist a
server or two you need to do client-auth with.
Firefox will also spit out messages to the error console for each
unpatched server it encounters. Another pref will show "broken-ssl"
indicators for such servers and yet another will refuse connections
to unpatched servers if you really want to get hardcore (and not use
SSL at all for a while).
These are _test_ builds and don't necessarily reflect how we'll ship
a future Firefox update. For updates on the stable branches we'll
probably have to allow unsafe renegotiation for a while, it's not a
good strategy to ship a security updates and force people to choose
between security and connecting with their bank/gov't/work. Or we
might have to do some UI work so affected users can tweak this
without having to wade into about:config.
Although currently not an option, one approach might be to downgrade
EV sites to normal SSL if they aren't patched and at least put
pressure on the sites that think they have something to protect.
Later this year we can start showing broken SSL indicators for
unpatched servers, when at least some servers are patched.
-Dan Veditz
Eddy Nigg
> To solve the problem for real in the long run both servers and
> clients need to be patched, and patched clients and servers must not
> talk to unpatched servers and clients. In the short run that's
> unrealistic so the Firefox settings are currently extremely
> permissive,
>
I'm not sure this is correct, because it breaks client authenticate.
This is the only case where renegotiation is/was really needed.
With that, it's breaking the client certificate authentication of a
couple of ten thousands of active user accounts at StartSSL. I take it
as a reward for being the only CA protecting sensitive information with
something better than username password pairs. :-)
> This will
> break client-auth in most cases so there's a global pref that allows
> unsafe renegotiation, and another pref so you could whitelist a
> server or two you need to do client-auth with.
>
Yes, and who is going to teach them all to revert something which will
in the long run remain vulnerable? I believe this is the wrong approach
and Mozilla should really wait until the the most commonly used servers
implemented the new RFC as well (at least). Those are Apache with
mod_ssl and IIS.
> These are _test_ builds and don't necessarily reflect how we'll ship
> a future Firefox update. For updates on the stable branches we'll
> probably have to allow unsafe renegotiation for a while, it's not a
> good strategy to ship a security updates and force people to choose
> between security and connecting with their bank/gov't/work.
>
Right! As such, I want to make you aware that it's possible to mitigate
the risks, for example servers may refuse client-initiated
authentication, leaving client certificate authentication working for
server initiated re-negotiation. Then the application layer can further
protect the server, because after all, a client certificate has to be
presented by the client. This will make an attack on the server mostly
useless.
> Later this year we can start showing broken SSL indicators for
> unpatched servers, when at least some servers are patched.
>
I'm afraid that in the meantime we'll have to get used to the hundreds
of support calls from those using nightlies. And I suspect that the
share of the typical audience at StartCom is higher than elsewhere. :-(
--
Regards
Signer: Eddy Nigg, StartCom Ltd.
XMPP: star...@startcom.org
Blog: http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg
Jean-Marc Desperrier
> On 02/14/2010 07:28 PM, Daniel Veditz:
>> permissive,
>
> [...] it's breaking the client certificate authentication of a
> couple of ten thousands of active user accounts at StartSSL. I take it
> as a reward for being the only CA protecting sensitive information with
> something better than username password pairs. :-)
Eddy, maybe you could talk here in mdt.crypto about the kind of
difficulties you have, and we'd see together how website owners with
similar problems should solve them.
If you currently have a https site that's partly open and partly
accessed only with client authentication, I think the only reasonable
way out is to break it in two.
Have secure.startcom.com with no cert and authent.secure.startcom.com
with client cert.
Technically, we could imagine some smart solution at the server level,
but it would be complex, fragile and require code changes, so really the
easiest is to simply separate completely.
Eddy Nigg
> Eddy Nigg wrote:
>> On 02/14/2010 07:28 PM, Daniel Veditz:
>>> [...] Firefox settings are currently extremely
>>> permissive,
>>
>> [...] it's breaking the client certificate authentication of a
>> couple of ten thousands of active user accounts at StartSSL. I take it
>> as a reward for being the only CA protecting sensitive information with
>> something better than username password pairs. :-)
>
> Eddy, maybe you could talk here in mdt.crypto about the kind of
> difficulties you have, and we'd see together how website owners with
> similar problems should solve them.
I think the long term fix is obviously implementing the new RFC.
> If you currently have a https site that's partly open and partly
> accessed only with client authentication, I think the only reasonable
> way out is to break it in two.
Not sure what you mean, but the server doesn't accept client initiated
renegotiation. Renegotiation happens only upon client certificate
authentication ONCE per authenticated session. The session is handled at
the application layer, not SSL session.
> Have secure.startcom.com with no cert and authent.secure.startcom.com
> with client cert.
That's not the issue, there is only one secure mode, during
authentication and thereafter. Client authentication happens once when
you authenticate.
> Technically, we could imagine some smart solution at the server level,
> but it would be complex, fragile and require code changes, so really
> the easiest is to simply separate completely.
At the moment that's the best we got - actually the only modification
needed was to disable renegotiation at the server for everything else.
The rest was already handled properly at the application level.
Obviously I can't say the same thing for clients which allow
renegotiation for any other reason and rough servers, respectively an MITM.
Kai Engert
>
>> If you currently have a https site that's partly open and partly
>> accessed only with client authentication, I think the only reasonable
>> way out is to break it in two.
>
> Not sure what you mean, but the server doesn't accept client initiated
> renegotiation. Renegotiation happens only upon client certificate
> authentication ONCE per authenticated session. The session is handled
> at the application layer, not SSL session.
>
>> Have secure.startcom.com with no cert and authent.secure.startcom.com
>> with client cert.
>
> That's not the issue, there is only one secure mode, during
> authentication and thereafter. Client authentication happens once when
> you authenticate.
Eddy, describing the solution in more detail:
- configure secure.startcom.com to never request client auth
- configure authent.secure.startcom.com to always request client auth
This avoids having to renegotiate, because the require authentication
level is set during the initial handshake to the server.
This requires that you split your content into two separate servers,
jump to authent.secure.startcom as soon as a user wishes to use a cert,
and remain at secure.startcom while you don't need the user to be
authenticated.
Kai
Eddy Nigg
> Eddy, describing the solution in more detail:
>
> - configure secure.startcom.com to never request client auth
>
> - configure authent.secure.startcom.com to always request client auth
>
> This avoids having to renegotiate, because the require authentication
> level is set during the initial handshake to the server.
>
> This requires that you split your content into two separate servers,
> jump to authent.secure.startcom as soon as a user wishes to use a
> cert, and remain at secure.startcom while you don't need the user to
> be authenticated.
>
OK, now I got it...indeed an interesting approach. Why haven't I thought
about this myself? ;-)
I'll check it out and have some tests going...
Eddy Nigg
>>
>> This requires that you split your content into two separate servers,
>> jump to authent.secure.startcom as soon as a user wishes to use a
>> cert, and remain at secure.startcom while you don't need the user to
>> be authenticated.
>>
>
>
> OK, now I got it...indeed an interesting approach. Why haven't I
> thought about this myself? ;-)
>
> I'll check it out and have some tests going...
>
Which reminds me that we were at this stage already in the past.
Basically the authenticated session would have to be relayed through to
the second server, something I rather prefer not to do. I suspect that
there is no other way around that.
Daniel Veditz
> Which reminds me that we were at this stage already in the past.
> Basically the authenticated session would have to be relayed through to
> the second server, something I rather prefer not to do. I suspect that
> there is no other way around that.
You could always patch your servers to support the new protocol.
Unfortunately this flaw is not fixed until all servers and all
clients are patched, and getting there is going to be painful.
If you use apache then patches are available for both mod_nss and
mod_ssl. If you use some other server then site admins such as
yourself should contact them and press for a solution. You'll need
one soon enough, and getting fixes from a non-open-source vendor
might take a long lead time.
I don't expect to ship a stable version of Firefox with broken SSL
client-auth any time soon but it seemed appropriate for "Minefield"
testing. We may revisit the Minefield choice if it's breaking too
much, but maybe we'll just release note the temporary pref --
Minefield users are supposed to be savvy consumers of alpha software
well capable of handling that kind of thing.
-Dan Veditz
Eddy Nigg
>
> Which reminds me that we were at this stage already in the past.
> Basically the authenticated session would have to be relayed through
> to the second server, something I rather prefer not to do. I suspect
> that there is no other way around that.
>
Trying the different sub domain trick doesn't work on the same server
but different host and IP. I assume that's because the server reuses the
cached SSL session and initiates a renegotiation upon certificate
authentication. Does that make sense so far?
Jean-Marc Desperrier
> Trying the different sub domain trick doesn't work on the same server
> but different host and IP.
Let me phrase this explicitly :
- You use only one Apache instance
- You configured two virtual hosts inside that instance
- Then :
- either each virtual host listens on a different IP
- or they listen on two different ports,
and you use a firewall to redirect the two separate external IP on
those two ports on the same internal IP
> I assume that's because the server reuses the
> cached SSL session and initiates a renegotiation upon certificate
> authentication. Does that make sense so far?
We'll it may be so, but it'd be a little surprising.
It requires two "bug/feature" I think :
- a server that allows reusing the same SSL ID on a different virtual
host. I can see how it could happen that the SSL ID pool is actually
shared between all virtual servers, but it's still not very clean.
- a client that tries to reuse the SSL ID if the request goes to the a
different host inside the same subdomain. Now that's harder to think of
it as anything else than a quite ugly bug, but we'd have to live with it
if it's the case
Eddy Nigg
>> Trying the different sub domain trick doesn't work on the same server
>> but different host and IP.
>
> Let me phrase this explicitly :
> - You use only one Apache instance
Correct.
> - You configured two virtual hosts inside that instance
> - either each virtual host listens on a different IP
Correct.
> We'll it may be so, but it'd be a little surprising.
> It requires two "bug/feature" I think :
> - a server that allows reusing the same SSL ID on a different virtual
> host. I can see how it could happen that the SSL ID pool is actually
> shared between all virtual servers, but it's still not very clean.
In any case it didn't solved the renegotiation. Either the NSS
implementation is broken or mod_ssl does something surprising. Now, NSS
works great with itself (as mod_nss and client), but what about the rest...
> - a client that tries to reuse the SSL ID if the request goes to the a
> different host inside the same subdomain. Now that's harder to think
> of it as anything else than a quite ugly bug, but we'd have to live
> with it if it's the case
That would be the even bigger surprise.
Jean-Marc Desperrier
> Trying the different sub domain trick doesn't work on the same server
> but different host and IP. I assume that's because the server reuses the
> cached SSL session and initiates a renegotiation upon certificate
> authentication. Does that make sense so far?
I just tried configuring a similar configuration, and thought more and
more whilst doing that it doesn't make sense, that it can't fail in the
way you described. And it doesn't (with two ports, but it definitively
would be the same with two IP).
But I met whilst configuring it a problem that *could* be the cause of
your problem.
Did you configure the "SSLVerifyClient require" option of the second
virtual server on the *root* of the second virtual host ?
It must not be inside a sub-directory, or you will get a renegotiation
error, even if your URL directly points to that directory.
Another point : We'll need to document that renegotiation is the default
and systematic behavior of IIS, even when client authentication is
required everywhere. You must change a flag with a script to correct that.
Eddy Nigg
> I just tried configuring a similar configuration, and thought more and
> more whilst doing that it doesn't make sense, that it can't fail in
> the way you described. And it doesn't (with two ports, but it
> definitively would be the same with two IP).
>
> But I met whilst configuring it a problem that *could* be the cause of
> your problem.
>
> Did you configure the "SSLVerifyClient require" option of the second
> virtual server on the *root* of the second virtual host ?
Actually not, only on a particular location. However I wonder how that
should make a difference in case the only connection is made to a
particular URL.
> It must not be inside a sub-directory, or you will get a renegotiation
> error, even if your URL directly points to that directory.
And the logical explanation to that would be? Obviously we'll make some
further test along your comments, just wonder where the difference is.
> Another point : We'll need to document that renegotiation is the
> default and systematic behavior of IIS, even when client
> authentication is required everywhere. You must change a flag with a
> script to correct that.
Right. And does that omit renegotiation by the server?
Eddy Nigg
> On 02/19/2010 08:59 PM, Jean-Marc Desperrier:
>> I just tried configuring a similar configuration, and thought more
>> and more whilst doing that it doesn't make sense, that it can't fail
>> in the way you described. And it doesn't (with two ports, but it
>> definitively would be the same with two IP).
>>
>> But I met whilst configuring it a problem that *could* be the cause
>> of your problem.
>>
>> Did you configure the "SSLVerifyClient require" option of the second
>> virtual server on the *root* of the second virtual host ?
>
> Actually not, only on a particular location. However I wonder how that
> should make a difference in case the only connection is made to a
> particular URL.
>
>> It must not be inside a sub-directory, or you will get a
>> renegotiation error, even if your URL directly points to that directory.
>
> And the logical explanation to that would be? Obviously we'll make
> some further test along your comments, just wonder where the
> difference is.
>
Apparently it does works - sort of. Still some way to go if this can /
will go into production. But I consider it pure luck so far...Apache
performs a renegotiation when none is needed when configuring client
authentication at a particular location, is there a logical explanation
for that? Or even considered correct implementation?
Jean-Marc Desperrier
> Apache performs a renegotiation when none is needed when configuring
> client authentication at a particular location, is there a logical
> explanation for that? Or even considered correct implementation?
Yes, there's a logical explanation and Apache is doing nothing wrong here.
The parameters of the SSL session, including SSL client authentication,
are negotiated before the server sees any data from the client, so
before the SSL server has any idea which location will be accessed.
The best Apache can do at this moment is to use the parameters that are
set for the root of the virtual server concerned. After negotiation is
complete, the client sends the GET/POST request, the server sees which
location is actually accessed, and has to do a full renegotiation if
there's a difference in the parameter for that location.
Where Apache is failing is in that it will quite often do a
renegotiation when you access successively two locations which
parameters are compatible, or even identical. So the best is too set the
parameters at the root, and not overwrite them anywhere.
Eddy Nigg
> On 20/02/2010 03:25, Eddy Nigg wrote:
>> Apache performs a renegotiation when none is needed when configuring
>> client authentication at a particular location, is there a logical
>> explanation for that? Or even considered correct implementation?
>
> Yes, there's a logical explanation and Apache is doing nothing wrong
> here.
>
> The parameters of the SSL session, including SSL client
> authentication, are negotiated before the server sees any data from
> the client, so before the SSL server has any idea which location will
> be accessed.
> The best Apache can do at this moment is to use the parameters that
> are set for the root of the virtual server concerned. After
> negotiation is complete, the client sends the GET/POST request, the
> server sees which location is actually accessed, and has to do a full
> renegotiation if there's a difference in the parameter for that location.
Aha - yes, this makes sense.
>
> Where Apache is failing is in that it will quite often do a
> renegotiation when you access successively two locations which
> parameters are compatible, or even identical. So the best is too set
> the parameters at the root, and not overwrite them anywhere.
OK, done. This seems to work now and no renegotiation happens. Nice
trick and does the job apparently.
Jan Schejbal
> Test server at https://ssltls.de
none of the two images is visible with my Fx3.6. I don't give any
guarantees about my prefs and addons, though.
Jan
Kai Engert
Firefox 3.6 does not yet have any fixes for this. As of today, only the
experimental nightly builds have it (mozilla-central). Please read the
starting post of this thread.
You may track the arrival of fixes into Firefox 3.6.x at
https://bugzilla.mozilla.org/show_bug.cgi?id=545755
Kai
Kai Engert
Firefox 3.6 does not yet have any fixes for this. As of today, only the