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 b
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 b
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
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, ther
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 n
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
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).
B
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
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 di
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
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
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
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 than
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 in
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 s
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. R
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 i
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
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
per
19 matches
Mail list logo
