Google: Maintaining digital certificate security

Posted Mar 24, 2015 22:58 UTC (Tue) by josh (subscriber, #17465)
In reply to: Google: Maintaining digital certificate security by flussence
Parent article: Google: Maintaining digital certificate security

Again, I *really* can't bring myself to get upset about a CA that's giving certificates away for free charging a nominal fee for revocation (that in practice is less than a certificate would have cost from anyone else).

But in any case, hopefully Let's Encrypt will make this all easier.

> Anything a bit closer to the web and reality than ASN1 (itself a rich source of nasty bugs) and X.509. libsodium looks like a good starting point.

Fair enough, but someone needs to actually build and standardize a real protocol on top of that. It's far too easy to get wrong. And as awful as ASN.1 is, TLS has had close scrutiny from a huge number of people, which is a high burden for any potential replacement to meet.

> I'm also not a fan of the STARTTLS command - it's something that can conveniently go missing without detection, depending on the protocol it's used in. Secure should be the default, compatibility be damned.

No argument there. Open port, immediately start cryptographic handshake protocol.

Google: Maintaining digital certificate security

Posted Mar 25, 2015 6:06 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (14 responses)

> TLS has had close scrutiny from a huge number of people, which is a high burden for any potential replacement to meet.
Yet people still keep finding glaring errors in it. It means this protocol is a failure.

Google: Maintaining digital certificate security

Posted Mar 25, 2015 8:06 UTC (Wed) by tialaramex (subscriber, #21167) [Link] (13 responses)

Glaring errors in _the protocol_, such as?

The last few rounds of crypto protocol attacks have concentrated on messing about with padding. That's a great place to look because "I'll just handroll something and it'll be so simple it won't have any mistakes" people like you often are frustrated to discover that padding is even necessary and they decide they don't care about it at all, thus opening up an avenue of attack.

But TLS from the outset specified that padding is always to have a specific value and be verified along with the payload, thus defeating this sort of attack. That's a result of scrutiny by people who know what they're doing.

Google: Maintaining digital certificate security

Posted Mar 25, 2015 18:06 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (12 responses)

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

Google: Maintaining digital certificate security

Posted Mar 25, 2015 12:25 UTC (Wed) by rich0 (guest, #55509) [Link]

Suppose I go ahead and request 1000 SSL certs from StartSSL.

I then publish those 1000 private keys so that anybody can spoof those domains. Those certificates are completely compromised.

StartSSL won't revoke any of them.

Why exactly should browsers trust StartSSL to issue certificates? They have a policy of not revoking certificates they know are compromised, even if it is pointed out to them.

If they need to start charging up-front I don't have a problem with that. I'd prefer not having any free SSL options so that there is pressure to create one, rather than having a free SSL option that isn't secure and causes everybody problems.