Wandering Thoughts archives


Where cryptographic hashes come into TLS certificates

There has recently been a bit of commotion about whether or not to deprecate 'SHA1 certificates' for TLS, or at least how fast to do so. If you know something about TLS in general, this may sound a bit peculiar, because TLS certificates are based on public key cryptography (and public key signatures, where the CA signs your certificate and public key to say that they approve of it). SHA1 is not a public key system (that would be eg RSA), it is a well known and now old cryptographic hash.

Where SHA1 and other cryptographic hashes come into the picture is that CAs do not actually sign your certificate and public key. Directly signing lots of data with a public key is a very expensive and time-consuming thing, so what most everyone does instead is they take a cryptographic hash of the data to be 'signed' and it is that cryptographic hash that is directly signed through public key cryptography itself. Since SHA1 hashes are only 160 bits (20 bytes), you can see that this represents a very big savings over what is probably hundreds of bytes of certificate data and public key information.

(This is a savings not just when the CA generates the signature but also every time it is validated, which is on every TLS connection. Well, almost every TLS connection. On the other hand, I found a SHA1 certificate and according to the detailed information in Firefox the 'Certificate Signature Value' is 256 bytes, the same as with a SHA256 certificate. This is probably less than the full certificate data, but it's clearly a lot more than just the SHA1 hash.)

Since the CA is only actually signing the SHA1 hash, not the full certificate and public key, you can 'break' their signature if you can create a second certificate that has the same SHA1 hash. With the same hash, the CA's certificate signature applies just as much to your malicious certificate as it does to the original certificate that the CA actually signed. TLS certificate validation will happily accept your malicious certificate instead and so on.

(I think that a sufficiently determined client could detect your malicious certificate under some circumstances, by looking up the SHA1 hash in the growing certificate transparency system and seeing that the details don't match.)

So when people talk about 'SHA1 certificates' or 'SHA256 certificates', this is really a shorthand for 'certificates that are hashed and signed using SHA1'. There is nothing intrinsic about the certificate data itself that is tied to the hashing algorithm used, so I believe that a CA could do things like re-issue a certificate it originally signed using SHA1 as a SHA256 certificate.

(It's probably obvious, but I should say it for the record: the choice of hashing algorithm for certificate verification doesn't affect the security of your public and private keys, so it is (or would be) perfectly safe to get a certificate re-issued this way with the same keys. In some situations this may make certificate changeover easier.)

At a mechanical level, you generally set the hashing algorithm when you generate a CSR (in OpenSSL, via eg 'openssl req -new -sha256 ...'). However, basically all of the information in a CSR is advisory except for your public key, and I know that there are at least some CAs that basically take your CSR, extract the public key and maybe a few other pieces, and give you back a certificate that they put together themselves. These CAs are likely to ignore your choice of hashing algorithms too.

(Since no new SHA1 certificates are supposed to be issued after December 31st, pretty soon all CAs should either ignore you asking for a SHA1 hash or reject your CSR.)

tech/TLSCertificatesAndHashes written at 02:45:05; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.