Google: Maintaining digital certificate security

Posted Mar 25, 2015 18:06 UTC (Wed) by Cyberax (✭ supporter ✭, #52523)
In reply to: Google: Maintaining digital certificate security by tialaramex
Parent article: Google: Maintaining digital certificate security

> Glaring errors in _the protocol_, such as?
Being so complex that it can't be implemented sanely.

Padding and ability to downgrade are just symptoms - any modern protocol should avoid them entirely.

Google: Maintaining digital certificate security

Posted Mar 25, 2015 18:18 UTC (Wed) by dlang (guest, #313) [Link] (7 responses)

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.

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.

Google: Maintaining digital certificate security

Posted Mar 25, 2015 22:17 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (3 responses)

Padding is needed because many modern cryptographic primitives don't actually work on arbitrary bit strings. For example AES only works on blocks of exactly 128 bits. You'd know that if you had the faintest idea what you're talking about.

Google: Maintaining digital certificate security

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

AES-CTR and AES-GCM work perfectly fine on unpadded data. Even with the good old AES-CBC you can simply omit padding bytes from the wire protocol.

Google: Maintaining digital certificate security

Posted Mar 25, 2015 23:29 UTC (Wed) by cesarb (subscriber, #6266) [Link] (1 responses)

AFAIK, to "omit" padding on CBC one has to do ciphertext stealing. You can't simply "omit padding bytes", a block cipher mixes a block throughly so that if even one bit of ciphertext is changed or lost, that block once decrypted is garbage.

Google: Maintaining digital certificate security

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

Yes, you're certainly right. My bad. I used ciphers in block mode too long ago.