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: (Score:1, Interesting)
Re: (Score:1, Insightful)
Yeah, it's a mystery why you were downmodded.
Sometimes (Score:2)
I have no idea what Slashdot articles are talking about.
and at least for SSLAdmin, their is no easy search able definition.
Re: (Score:2, Redundant)
From TFS: "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."
Does that help?
Re: (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: (Score:2)
Would it really be that simple? Wouldn't a CA require any correspondence from the mail site be signed with one of their certificates?In TFA the author never succeeds (or tries) to get a CA to go along.
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: (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: (Score:2)
Re: (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 serv
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: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: (Score:2)
Yeah I know, that's why I don't work with them unless absolutely required to do, like some of our partners do. They are much more expensive and much more annoying to work with than Godaddy for example. Not that I like Godaddy, who at least should have chosen a name that make them look like a serious business, but at least their pricing is fair.
Re: (Score:1)
Re: (Score:2)
Re: (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: (Score:2)
Well, doing the former is rather simple; there are tons of tutorials for that on the Internet. Technically, when one takes advantage of this flaw, they do become a SSL admin in the eyes of the CA, which is the point.
I'm sure the complaints would've been loud and clear if the articles were on the former.
Re: (Score:2)
Agreed, about the Slashdot article title. More accuracy in the future, please? Or someone else start a news for nerds site? Thanks.
But this: "it's really talking about a social-engineering security vulnerability with several email providers" is not quite right.
The vulnerability exists because of a lack of protocol and is (loosely) a social engineering vulnerability between the CAs and those email providers. That is, the CAs are also part of the vulnerability.
Re: (Score:2)
I thought it had to be something like that.
Thanks for the information.
I am surprised that they would allow anything with admin in it, I would assume any email I got with admin@whatever.xxx (or something like that) would be from the runners of the email service.
Re: (Score:2)
Re: (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.
Re: (Score:2)
Re: (Score:2)
A huge mitigating factor for this flaw is that most huge free-email services (Google Mail, Hotmail, Yahoo, et al) prevent the registration of typical admin-like names (root, admin, ssladmin, postmaster, webmaster, etc). Additionally, some SSL CAs (StartCom, GoDaddy) do attempt to look up the real admin of the site and send confirmation emails there, which makes this useless.
While it's a serious flaw that needs to be attended to, it's not as impacting as it seems. (In fact, Seifried used portugalmail.pt as o
Re: (Score:3, Insightful)
Re: (Score:2)
A huge mitigating factor for this flaw is that most huge free-email services (Google Mail, Hotmail, Yahoo, et al) prevent the registration of typical admin-like names (root, admin, ssladmin, postmaster, webmaster, etc).
I'm sure that Jesus himself has come down from heaven and told them all the names, that every single SSL CA uses, which they need to reserve on their system. And comes down with an update when some brand new SSL CA decides that they'll send SSL certs to configssl@
Or, you know, not.
Additi
Re: (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 dom
Re: (Score:2)
It turns out that the importance of these addresses is not widely known amongst mail service providers.
Yes, the important of these addresses that SSL providers decided to invent out of thin air is not well known to random other people. Imagine that.
There actually are real defined role accounts. 'ssladmin@' is not one of them. Neither is, for a more surreal example of where they will send the cert, 'info@'. People can't just wander around inventing role accounts for third parties and then pretending they
Re: (Score:2)
"Out of eleven webmail services chosen at random and without prejudice"
so actually it probably is not interesting, just random chance.
1999 just called ... (Score:3, Funny)
... they want their exploits back.
The CA's are not doing their due dilligence (Score:3, Interesting)
They really should:
1. Do more out of band communication; e-mail being virtually impossible to verify is not a good medium to confirm who you are dealing with.
2. They should probably use the contact on the domain registration period. Most of them accept any number of alternate mail address that might or might not be protected. root@doamin, hostmaster@domain, ssladmin@domain, administrator@domain, postmaster@domain, and so forth. This is the exploit done in the TFA.
Re: (Score:2, Insightful)
Correct. He says he's not sure whom to blame.
*I'm* sure whom to blame: the CAs, who are falling prey to the "man who walks in in a UPS uniform" trick.
The LHS of your email address does *not* constitute an authentication scheme, people.
Re: (Score:2)
Re: (Score:1)
I switched to DigiCert a few months ago and they are much more "rapid" than rapidssl was ever for us.
Our original account with Rapid was under one company name. We subsequently changed the holding company's name on a later request and apparently our account was flagged for manual validation 100% of the time. Each time we renewed it would take 4 or 5 days of faxing forms, confirmations, phone calls from hell, etc.
The nice thing was, at the time, they were one of the few SSL providers to allow unlimited re-is
Re: (Score:2)
Re: (Score:2)
The original article I wrote at http://www.linux-magazine.com/w3/issue/114/054-055_kurt.pdf [linux-magazine.com] (that was copied by this guy) covers that:
for the phone verification, you can just use an anonymous prepaid cell and mumble; it’s automated and doesn’t care
The phone check does nothing security wise, it is just a bit of security theater
easy fix (Score:2)
This is nothing new (Score:5, Insightful)
This is nothing new, we've been talking about issues like this since the introduction of SSL. Either you have onerous and thorough verification, which makes SSL a real pain to deploy and discourages adoption, or you have an easy-to-game system that makes SSL less secure. Security always involves lots of effort, and that's simply at odds with the way things are "supposed to work" on the Internet.
Re: (Score:2)
It doesn't make SSL less secure. It just makes it less trustworthy. You should never trust an SSL certificate to provide you with any identification. SSL's are there to encrypt the connection and so far, that level of protection provided is fairly immune to attacks.
If you want a website to identify themselves, they should provide you with something else, an identifier that is unique to your account with them that you might have established before (as many banks are starting to do - they provide a picture wi
Re: (Score:2)
We can actually validate certificates relatively well using "notaries". This gives us in effect validation of identity. It's better than trusting CAs, and you don't have to buy certificates:
"Perspectives"
Demo [networknotary.org]
About [cmu.edu]
Firefox extension [cmu.edu]
This SAME thing/study was already done. (Score:1)
Re: (Score:2)
> When will these companies learn.
Learn what? That neither their customers nor the users actually give a damn about security? They already know that.
Install "Perspectives" (Score:2)
When will registrar be required to do this? (Score:2, Insightful)
Re: (Score:2)
> ...and how about requesting that it should be a free service...
That would just mean that those of us who don't need certificates would have to pay for them anyway.
Re: (Score:1)
- the number of accredited registrar
- the price of domains
- the fact that there's a lot of competition and
- the economy of large scale
I am convince that such added charge would be insignificant. I shall now spell the current situation where SSL certs are overpriced, when they should cost nothing (eg: there's no server to maintain once the cert has been issued, just a trivial function to implement on a web site) while there are root servers to keep online and the registry database itself to
List to be truncated (Score:2)
Verisign just told me they're going to truncate the list of eligible email addresses down to a more manageable 6.