Become an SSLAdmin In a Few Easy Steps 64
Renderer of Evil writes "With news that it is rather simple to mimic authority with many webmail providers in order to coax an SSL certificate authority into creating one for the domain, a Canadian security expert has decided to take it upon himself to see who out there is actually vulnerable and provide information to the public on how prevalent this issue is as we speak. Out of eleven webmail services chosen at random and without prejudice, just under half of them permitted him to register with credentials (ssladmin) that allowed him to create an SSL certificate in their name. In most of these cases, there was a pre-existing, legitimately-acquired certificate."
Update: 04/19 01:30 GMT by S : Kurt Seifried's original paper, on which the BetaNews article is based, provides more detailed information on the subject (PDF).
Re:Sometimes (Score:2, Informative)
In order to get a SSL certificate for your domain for use with E-Mail you have to provide an email address on which the CA sends an E-Mail to confirm your identity.
Most CAs have a list of predefined addresses, one of which is ssladmin@.
Re:Sometimes (Score:5, Informative)
In a nutshell:
When you log in to your email account, the server sends you a certificate to confirm that it does indeed belong to the email provider and not an eavesdropper.
By registering an email account like "admin" or "ssladmin", an attacker could contact certification authorities and request a new certificate pretending to be a staff member of the service.
They could then use that certificate to intercept and redirect your connection to their own server, intercepting passwords and emails, while your browser will still tell you that you are connected with a genuine mail server.
Re:Sometimes (Score:2, Informative)
Certificate authorities (which issue certificates for SSL to web sites and email providers) must somehow know whom they're talking to when they are presented with a certificate signing request. While this authentication phase was meant to involve some documentation, for quite some time now the only proof of identity required to get an SSL certificate is to be able to receive mail under a list of "special" mail addresses under a domain. One of the names is "ssladmin@example.com" (where example.com is the domain for which the SSL certificate is going to be issued). If you can receive mail for that address, you can go to a number of certificate authorities and get a certificate for example.com. It is therefore expected that mail services do not allow regular users to get that email address or one of the other dozen special addresses. It turns out that the importance of these addresses is not widely known amongst mail service providers. That enables attackers to get SSL certificates for the domains of these services, which can then be used to perform man-in-the-middle attacks on all mail users of these services, i.e. read their passwords and their mail regardless of in-transit encryption.
Re:Sometimes (Score:1, Informative)
In a nutshell:
When you log in to your email account, the server sends you a certificate to confirm that it does indeed belong to the email provider and not an eavesdropper.
By registering an email account like "admin" or "ssladmin", an attacker could contact certification authorities and request a new certificate pretending to be a staff member of the service.
They could then use that certificate to intercept and redirect your connection to their own server, intercepting passwords and emails, while your browser will still tell you that you are connected with a genuine mail server.
Oh, so rather than being a guide to administering your own SSL certificates and SSL-using services, like Slashdot's title implies, it's really talking about a social-engineering security vulnerability with several email providers. Yes, that clears things up nicely.
Re:Sometimes (Score:4, Informative)
He doesn't need to try this, it's established procedure. Yes, the idea behind SSL was to require more reliable identification than just being able to receive mail for one of a few mail addresses. What was initially the plan with SSL is now called an "extended verification" certificate. Regular SSL certificates are less secure than DNSSec distributed keys would be. DNSSec would at least ensure actual control over the domain, not just the ability to receive mail for that domain. The lack of proper authentication by the certificate authorities has been a problem for a long time and this is just another outrageously simple way of getting a certificate for someone else's domain.
Let me be clear on this: It's the CA's fault. The mail provider could plug this hole by not allowing users to register these addresses, but those addresses are arbitrary. It's the CA's job to ensure that they're only giving certificates to the owners of a domain.
Re:Sometimes (Score:3, Informative)
Would it really be that simple? Wouldn't a CA require any correspondence from the mail site be signed with one of their certificates?
Yes it would, and no they wouldn't. Most certificates are issued in a completely automated manner, and there is no good way to make sure that a certificate hasn't already been issued for the domain by another CA (one could try making an HTTPS connection to the server, but that's still vulnerable to manipulation).
Re:Sometimes (Score:5, Informative)
It depends on who will issue the certificate. Serious companies like Network Solution, Thawte or even Godaddy will send a validation email to the owner of the domain (if it's listed in the whois data) or require you to create a new file on the web site or a DNS CNAME to prove that you have admin right on the domain. It's a bit of a pain in the ass when you are registering SSL certs for a third party partner, but it's rather safe.
Some SSL companies though will simply ask you to provide an email for that domain and send a validation link to that email. So you could create ssladmin@hotmail.com and they would happily create you a perfectly valid SSL certificate for hotmail.com you could use for man in the middle attacks.
Re:Sometimes (Score:2, Informative)
No, the CA sends mail to an address of your choice, which must be in the domain that the certificate signing request is for and have a user part which is on a list of "special" addresses for domain ownership verification. This mail contains a code which you then use to confirm that you can indeed read email for that address. Then the CA signs the certificate and you're done. This is not news. TFA is about the fact that the existence of this (stupid) protocol appears to be unknown to quite a lot of mail service providers who consequently do not reserve these addresses and instead allow mere users to register them, which puts these users in a position where they can get certificates for the domain of the mail service provider.
Re:Sometimes (Score:5, Informative)
You sure are angry for a Sunday morning. From the Betanews article:
So, it's not the attacker sending an email from ssladmin@example.com to the certificate authority asking for a cert that does it. It's the attacker telling the certificate authority that ssladmin@example.com should be used to prove control over of the domain, then RapidSSL.com would send a confirmation email to that address assuming it was under control of the right people. I guess ssladmin is on a predetermined list of email addresses they allow for authentication.
So, yes, he can demonstrate this.
Re:Sometimes (Score:4, Informative)
That's exactly right. The primary email contact is taken from WHOIS, but there are a few addresses that seem to be alternatives for most CAs (e.g. hostmaster). But for some CAs, the list of alternate addresses is rather long, ie:
administrator@seifried.org
admin@seifried.org
info@seifried.org
hostmaster@seifried.org
root@seifried.org
ssladmin@seifried.org
sysadmin@seifried.org
webmaster@seifried.org
info@seifried.org
postmaster@seifried.org
This is the revised list which is in use by RapidSSL (a Verisign subsidiary) now, before the discussion was started. The original list was longer and contained generic addresses like is, it and mis (mis?!). It's not surprising that some mail providers didn't prevent people from registering a few of those.
The whole thing is documented on https://bugzilla.mozilla.org/show_bug.cgi?id=556468 [mozilla.org] and in the Kurt Seifried's original article on the issue http://www.linux-magazine.com/Issues/2010/114/BREACH-OF-TRUST [linux-magazine.com] (which are really the two links the Slashdot summary should have had).
Re:Sometimes (Score:3, Informative)
You are right, the SSL certificate is not used to intercept the connection. It is merely used to disguise an intercepted connection as a genuine one.
The interception itself can be done by many different technical means, including DNS poisoning/spoofing, packet sniffing on a wireless network, etc. These aren't always trivial or feasible - but the risk of them is the reason SSL certificates exist in the first place.