|
|
Subscribe / Log in / New account

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

If you don't have the ability to downgrade, how can you ever add new encryption options without having a flag day change where everyone changes their software at once?

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.


to post comments

Google: Maintaining digital certificate security

Posted Mar 25, 2015 19:01 UTC (Wed) by pizza (subscriber, #46) [Link] (3 responses)

With 'downgrade' I believe Cyberax is referring to SSL/TLS's ability to renegotiate an already-established session to weaker parameters.

Google: Maintaining digital certificate security

Posted Mar 25, 2015 19:09 UTC (Wed) by dlang (guest, #313) [Link] (2 responses)

that exact same mechanism is needed to renegotiate to stronger parameters.

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.

Google: Maintaining digital certificate security

Posted Mar 25, 2015 19:22 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (1 responses)

> that exact same mechanism is needed to renegotiate to stronger parameters.
No you don't. There shouldn't be 'stronger parameters'. Encryption is either strong or useless.

> 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.
Client cert _authentication_ does not mean 'stronger parameters', it just means that.

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.

Google: Maintaining digital certificate security

Posted Mar 25, 2015 19:46 UTC (Wed) by dlang (guest, #313) [Link]

> No you don't. There shouldn't be 'stronger parameters'. Encryption is either strong or useless.

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.

Google: Maintaining digital certificate security

Posted Mar 25, 2015 19:15 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

Negotiation should happen exactly once - during the handshake. TLS allows to renegotiate it, with ability to use client cert authentication mixed in for an additional fun.

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.

Google: Maintaining digital certificate security

Posted Mar 26, 2015 19:07 UTC (Thu) by kleptog (subscriber, #1183) [Link] (1 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.

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.
https://bugzilla.mozilla.org/show_bug.cgi?id=415033

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.

Google: Maintaining digital certificate security

Posted Mar 26, 2015 19:09 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Here's a good explanation: https://timtaubert.de/blog/2014/11/the-sad-state-of-serve...

And no, in practice they're not used that often.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds