Wandering Thoughts archives

There is a surprising amount of old SSL code in running MTAs

SSL has a number of old, dark corners. One of them is 'SSL2 handshake compatibility', where clients that want to be able to talk to a SSLv2 server must start their conversation out with a (special) SSLv2 ClientHello. Of course this means that a SSL v3 or TLS server that wants to be able to talk to such clients needs to accept the SSLv2 ClientHello and then upgrade the connection to SSLv3 or TLS afterwards, in a coordinated dance with the client. Now, SSLv2 has been dead for a long time now, but of course SSL libraries don't like removing features so SSLv2 client support lingered on for years and years after SSLv2 servers had probably all vanished, and along with it lingered SSL2 handshake compatibility. All of this is generally invisible in server logs, which will just reflect that SSLv3 or more likely TLS was negotiated in the end.

Except if you run a Go-based TLS server, that is, because Go doesn't support SSL2 handshake compatibility. As Filippo Valsorda notes, the browsers and browser software that supports this is now really, depressingly old and most people won't care about them anyways. Unfortunately, HTTPS is not the only TLS based protocol in the world and browsers (and browser libraries) are not the only things making TLS connections. In particular, SMTP supports TLS, which means that MTAs thus talk TLS.

I have a Go based SMTP server with TLS support and it logs TLS setup errors, so I actually have an opportunity to see how many sending MTAs try to do SSL2 handshake compatibility. It turns out that there were more than I expected, although the good news is that the number of such servers has fallen over time and that some of the really eyebrow raising parties seem to have stopped doing this.

(When I started my sinkhole SMTP server in the spring and summer of 2014, some of Yahoo's mail servers were still doing SSL2 handshake compatibility for outgoing SSL connections. That seems to have changed since then.)

I've done various casual checks on the machines trying to do this with my server, and they've turned up a wide variety of apparent sending MTAs, many of them running on Unix machines (unless someone has ported eg qmail to Windows). At least some of them are running MTA code that seems very old by now (eg), although this doesn't say anything definitive about how old their SSL libraries are.

At one level most of this is not really surprising. We've always known that there are very old servers out there and old servers mean old SSL libraries with old behavior, which this very definitely is. On another level I am surprised by just how common this seems to be. My little SMTP sinkhole is not really a hotspot of activity, yet practically the day I recently started logging these messages again I was getting some sending MTAs that were trying to do this.

Unfortunately this also means that if you care about maximal SSL support for MTAs and similar server side software, you probably want to consider still supporting SSL2 handshake compatibility. Users clearly update browsers, IMAP clients, and so on far more frequently than people update server side software like MTAs and OS SSL libraries (and OSes, for that matter).

(I also suspect that visible programs like browsers, IMAP clients, and so on are somewhat more likely to explicitly tell their SSL libraries to turn off now obsolete features like SSL2 support, SSL2 handshake compatibility, and so on. I expect that much MTA code just goes with the SSL library defaults, which means that if the library is conservative about what it deprecates the MTA goes along with that.)

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

A surprise about cryptographic signatures

I won't say that I know a lot about cryptography, but I know a certain amount. What this really means is that every so often I get the opportunity to be really surprised about something in cryptography. The most recent incident came about from reading Andrew Ayer's Duplicate Signature Key Selection Attack in Let's Encrypt. I had to read the article more than once before I really understood the problem, but here is the cryptographic thing that really startled me, boiled down:

A digital signature is not necessarily tied to a message.

As Ayer puts it:

Digital signatures guarantee that a message came from a particular private key. They do not guarantee that a signature came from a particular private key, [...]

By extension (and Ayer mentions this later), a signature does not uniquely identify a message; many pairs of messages and keys may result in the same signature. The specific vulnerability that Ayer exploited is that in RSA, if you have a message and a signature, you can quite easily generate a private key that produces the given signature for the message. The original Let's Encrypt protocol was vulnerable to this issue because it had you basically publish your signature of their validation message to you. Since this signature was on its own, an attacker could arrange a situation where it was also a valid signature for a different message signed with the attacker's key.

(The article is well worth reading in full, just to absorb the details of both how this works in RSA and how the specific attack worked against Let's Encrypt's original protocol.)

Until I read this article, I would not have expected this result at all. Had I been in a situation where it mattered, I wouldn't even have thought about the assumptions I was making about how a message, a signature, and a private key were connected; I probably would have just assumed that a signature was inextricably tied to both the message and the private key. Nope. Not so at all.

The direct lesson I take away from this is that anything involving a signature floating around on its own is dangerous, and if I ever design any sort of validation protocol I should avoid it. The indirect lesson is yet another useful reminder that I do not know enough about cryptography to be designing anything involving cryptography. If I try to do this in any non-toy context, the things I don't even know I don't know will probably eat me for breakfast without breaking a sweat.

One limit to how much TLS can do for you against MITM attacks

One of the bits of TLS news recently has been that Kazakhstan is apparently planning to force all Internet users in the country to install a new TLS root certificate (see eg here and here) and then probably use that certificate to intercept whatever HTTPS communication they want to. This situation points out what is not so much a limitation of TLS and encryption in general as a simple absence of magic.

The obvious assumption to make is that the Kazakhstan authorities are going to end up blocking HTTPS connections that aren't willing to accept their MITM certificates. At this point, TLS is up a creek. If an attacker with control over your network link is willing to enforce a policy of 'you can only communicate if we can read your traffic', well, mainstream software has no good options. If it prioritizes secrecy over communications, you can't talk at all; otherwise, you have no secrecy. There is no magic third path.

(Non-mainstream software can attempt to smuggle traffic through various forms of steganography and concealment, but this is not really viable for popular software; the attacker will soon become aware that this smuggling is going on and block it.)

This doesn't mean that TLS is useless in this situation. TLS is forcing the Kazakhstan authorities to do this in public, in a very visible way. Without encryption or the (weak) authentication that certificate validation provides, Kazakhstan could have done this on the sly (and in fact they undoubtedly are doing it for HTTP and other plaintext traffic, just as plenty of other people are). TLS is even forcing this to be visible to software (at least software that has access to the certificate chain).

An encryption system that doesn't allow itself to be defeated this way (including TLS software that refuses this MITM certificate even if the user has accepted it) cannot 'win' on a technical level; its traffic will get blocked and it will fail to achieve both of availability and secrecy. It can only win (if it does eventually win) at the social and political level, if the resulting lack of communication is sufficiently important and painful to change the attacker's actions. Urging that software fail in the favour of secrecy here is essentially a bet that the social level will win out in the end.

(If Kazakhstan is really serious about this they're going to have to block a lot of other network protocols and connections. But they can certainly do this if they want to badly enough; after all, it's no different than what 'block by default' outbound firewalls do in many organizations. Of course they may not go this far; picking off the majority of encrypted traffic might be good enough.)