Re: Fix for the TLS renegotiation bug
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
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
On Sun, Feb 14, 2010 at 9:28 AM, Daniel Veditz dved...@mozilla.com 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: List/remove cached S/MIME capabilities
Hello, Michael. No. No such mail client exists that allow tune/edit recipient's S/MIME caps. This is because some influential people consider: * S/MIME caps are just a part of mail security protocol * protocol shouldn't be exposed to end user to prevent security compromise. * we shouldn't confuse user. Securing mail should just work w/o exposing these gory details. You can find relevant discussions in other newsgroups, not this one. Best regards, -- Konstantin Andreev. On 18.02.10 14:06, Michael Ströder wrote: I'm using Seamonkey 2.0.3 under Linux. Is there a way to list and tweak the cached S/MIME capabilities for certain recipients? Ciao, Michael. -- 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
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
