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.

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

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

Re: List/remove cached S/MIME capabilities

2010-02-18 Thread Konstantin Andreev
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

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