Re: Fix for the TLS renegotiation bug

2010-02-23 Thread Kai Engert

On 23.02.2010 02:21, Jan Schejbal wrote:

Hi,

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


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

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-23 Thread Kai Engert

On 23.02.2010 02:21, Jan Schejbal wrote:

Hi,

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


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

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-22 Thread Jan Schejbal

Hi,

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 


--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-20 Thread Eddy Nigg

On 02/21/2010 03:10 AM, Jean-Marc Desperrier:

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.


--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-20 Thread Jean-Marc Desperrier

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.


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.

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-19 Thread Eddy Nigg

On 02/20/2010 12:22 AM, 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?


--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-19 Thread 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.


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?

--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-19 Thread Jean-Marc Desperrier

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.

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-19 Thread Eddy Nigg

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


That would be the even bigger surprise.

--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-19 Thread Jean-Marc Desperrier

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

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-18 Thread Eddy Nigg

On 02/18/2010 03:54 PM, 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?


--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-18 Thread Daniel Veditz
On 2/18/10 5:54 AM, Eddy Nigg wrote:
> 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

-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-18 Thread Wan-Teh Chang
On Sun, Feb 14, 2010 at 9:28 AM, Daniel Veditz  wrote:
> 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.

Yes, we should also announce the first NSS 3.12.6 release candidate
(CVS tag NSS_3_12_6_RC0).  I will make sure we post an
announcement today.

Wan-Teh
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-18 Thread Eddy Nigg

On 02/18/2010 02:43 PM, 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.


--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-18 Thread Eddy Nigg

On 02/18/2010 02:37 PM, Kai Engert:

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...

--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-18 Thread Kai Engert

On 18.02.2010 02:45, Eddy Nigg wrote:


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


-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto

Re: Fix for the TLS renegotiation bug

2010-02-17 Thread Eddy Nigg

On 02/17/2010 12:52 PM, Jean-Marc Desperrier:

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.


--
Regards

Signer:  Eddy Nigg, StartCom Ltd.
XMPP:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-17 Thread Jean-Marc Desperrier

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.

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Re: Fix for the TLS renegotiation bug

2010-02-14 Thread Eddy Nigg

On 02/14/2010 07:28 PM, Daniel Veditz:

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:start...@startcom.org
Blog:http://blog.startcom.org/
Twitter: http://twitter.com/eddy_nigg

--
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto


Fix for the TLS renegotiation bug

2010-02-14 Thread Daniel Veditz
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.

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
-- 
dev-tech-crypto mailing list
dev-tech-crypto@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-tech-crypto