This is a post I’ve been meaning to write for a while. I hear a lot of people talking about the merits of SSL/TLS and I see people building extremely critical apps that effectively rely almost entirely on SSL/TLS to work. I see people relying on the basic concept of domain ownership to protect them, and it’s troublesome. To illustrate the reason, let’s go back to the 90s – when Alice in Chains and Nirvana were rocking the airwaves.
Once upon a time we had the idea that email should have some security put around it. SSL seemed like a fine enough security mechanism, so SSL was chosen by the masses to be the primary means of building encrypted email. The problem, though, is that SSL was not designed to have more than one domain name pointed at it. If an administrator of a domain wanted to host, say, two domains, they would have to buy two certificates and have them on different IP addresses. That’s just a pain! And besides, certificates were pricey.
So how did we solve this problem in the 90s? We started using snake-oil certificates. Snake oil certificates allow the connection to become encrypted, but they aren’t verifiable. So rather than having just one domain be verifiable, now none of them were. This was a problem for people who were validating the SSL certs before sending email. So what did they do? They turned off SSL validation in email. That’s right – effectively every mail administrator everywhere turned off the check that determined if they were actually talking to the right server or not.
Domain registrars and certificate authorities use email as a primary means to contact you. Normal certificates need to be issued to and verified by email addresses at the domain in question. Likewise domain name servers rely on email for things like forgot password flows. These are often straightforward addresses like email@example.com or firstname.lastname@example.org and so on. This means that if an attacker is able to man in the middle the email server, they can simply request a valid certificate or password reset, which is sent to them. Once they have that, they can do a great deal of damage.
Here’s the basic process:
- The attacker performs a man-in-the-middle (MitM) attack.
- The attacker listens for incoming requests as a MitM but puts a snakeoil certificate in place.
- The attacker initiates some function on the registrar or Certificate Administrator that sends the target domain an email.
- The registrar/CA connects to the domain – which, at this point, is really a MitM — and sees the snakeoil certificate.
- The registrar/CA ignores the fact that the cert is snakeoil and sends the email to the attacker.
- The attacker now has whatever sensitive information was in that email – a forgot password link, a verification link for new certificates, or whatever.
- The attacker can now use that information to forward a request to reset the password or issue a new certificate
- Now the attacker can change the DNS to point the entire domain somewhere else, take over the entire domain, or use the now-valid SSL certificate that was issued to front end the web-server. (A snakeoil certification could not usually be used that way, because browsers would complain about an SSL/TLS mismatch error).
The problem is that the domain SSL certificate authorities, like everyone everywhere, have disabled the check that would ensure that the SSL cert is valid. The result is that your websites – most if not all websites! — are probably vulnerable to an attack like this. Buying valid certificates won’t solve the problem, because domain registrars and SSL certificate authorities are not requiring valid certificates to be issued and used for email servers before sending sensitive information over email.
Special thanks to an anonymous source for adding the following: An additional and potentially worse problem is that, in most cases, the MTA->MTA transaction has NO SSL/TLS. It’s not even that they accept self-signed ones, the MitM can just deny encryption entirely. From the Microsoft docs on their exchange protection system: “The FOPE service supports opportunistic TLS, meaning that it first attempts to deliver TLS, but if it is unable to establish a TLS connection with the destination server, then it delivers via regular SMTP.”
Therefore, for the time being, web security is reducible to SSL/TLS security, which is reducible to email security, which is broken. Or in Haiku form:
Web needs SSL; Which Relies upon Email; Which is muy Broken.