Google: Maintaining digital certificate security
Google: Maintaining digital certificate security
Posted Mar 25, 2015 18:18 UTC (Wed) by dlang (guest, #313)In reply to: Google: Maintaining digital certificate security by Cyberax
Parent article: Google: Maintaining digital certificate security
The "downgrade" is just that the software at the two ends is being updated on different schedules and they need to find something they both understand. One side views it as being as secure as it knows how, the other side sees it as a "downgrade" from the best that it knows how.
Posted Mar 25, 2015 19:01 UTC (Wed)
by pizza (subscriber, #46)
[Link] (3 responses)
Posted Mar 25, 2015 19:09 UTC (Wed)
by dlang (guest, #313)
[Link] (2 responses)
A case I ran into a few years back was where we had a site that was mostly open to the public, but we wanted one subdirectory to be protected by a client cert. This required renegotiating the connection.
Yes, in theory it could allow to renegotiate to a stronger connection and not to a weaker one, but how _exactly_ do you define in an unambiguous way which options are stronger than others? Especially as new vulnerabilities are discovered.
Posted Mar 25, 2015 19:22 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
> A case I ran into a few years back was where we had a site that was mostly open to the public, but we wanted one subdirectory to be protected by a client cert. This required renegotiating the connection.
A real protocol should have an optional authentication layer built on top of it. I.e. you establish a secure connection and then use it to transmit a signed token that proves that it's really you (the token must include a hash of the transport-level parameters). There's absolutely no need to renegotiate lower transport levels for that.
Posted Mar 25, 2015 19:46 UTC (Wed)
by dlang (guest, #313)
[Link]
This is not the case. At most you could say that encryption is "strong enough" against a particular threat model.
but just because the NSA could crack something with a datacenter full of computers doesn't mean that the encryption is worthless if what you are trying to protect against is a child in your family.
As for no encryption being stronger than any other, 512 bit RSA keys are not as strong as 4096 bit RSA keys. At one point 512 bit keys were 'strong enough', but now they generally are not considered to be 'strong enough' against any non-trivial threats.
Posted Mar 25, 2015 19:15 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
Then there's an ability to use session tickets to resume TLS connections without a full renegotiation. I'm pretty sure that there are vulnerabilities still undiscovered there, since pretty much nobody actually uses them yet lots of servers inherit it from OpenSSL.
So yes, I think the world would be better with plain text HTTP - we might actually get a simple and secure transport protocol instead of the TLS mess.
Posted Mar 26, 2015 19:07 UTC (Thu)
by kleptog (subscriber, #1183)
[Link] (1 responses)
Eeh, what? Resuming SSL sessions is used a lot. You need it to get any kind of performance out of an HTTPS site. See this bug enabling it in Firefox in 2008.
TLS isn't perfect, but it's come a long way as the knowledge of cryptography has improved. The installed base is not to be sneezed at and we're getting a lot better at pushing out updates.
Posted Mar 26, 2015 19:09 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link]
And no, in practice they're not used that often.
Google: Maintaining digital certificate security
Google: Maintaining digital certificate security
Google: Maintaining digital certificate security
No you don't. There shouldn't be 'stronger parameters'. Encryption is either strong or useless.
Client cert _authentication_ does not mean 'stronger parameters', it just means that.
Google: Maintaining digital certificate security
Google: Maintaining digital certificate security
Google: Maintaining digital certificate security
https://bugzilla.mozilla.org/show_bug.cgi?id=415033
Google: Maintaining digital certificate security