I'm surprised not to see it mentioned here yet, but Firefox 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.
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.
> 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. :-(
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.
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 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.
>> 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.
> - 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? ;-)
>> 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.
> 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.
> 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?
Eddy Nigg wrote: > 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 wrote: >> 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
Eddy Nigg wrote: > 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.
> 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?
> 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?
> 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.
> 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.
> none of the two images is visible with my Fx3.6. I don't give any > guarantees about my prefs and addons, though.
> Jan
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.
> none of the two images is visible with my Fx3.6. I don't give any > guarantees about my prefs and addons, though.
> Jan
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.
