With news that it is rather ridiculously simple to mimic authority with many webmail providers in order to coax an SSL certificate authority (CA) into creating one for the domain, I decided to take it upon myself 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 me to register with credentials (ssladmin) that allowed me to create an SSL certificate in their name. In most of these cases, there was a pre-existing, legitimately-acquired certificate.
All of them were contacted prior to this blog entry being posted. Out of the five that I contacted, one responded to me directly and informed me that the issue was being addressed, another one had a ticket filed but has no followed up nor closed the account, one had my account banned outright, and the rest did not comment. I was successful in registering a new account for a CA service for one of the providers, but did not complete the request and didn't bother for the rest of them.
News of the issue came out late last month that it was "trivially easy" to register certificates for webmail services. Typically, you'll see accounts such as "administrator", "postmaster", and "root" barred from registering as either they'll already exist or they'll have been included in some sort of blacklist.
Many CAs will issue certificates to a list of pre-existing e-mail accounts typically containing the administrator, postmaster, and root accounts, but also including ssladmin. Because of this irresponsible method, you have the situation that we have here.
With all of that said, it's a bit muddled on who is exactly at fault, but I will elaborate on this a bit later.
As I had said earlier, I chose at random and without prejudice eleven free webmail services. Let's just cut to the chase and list off the services I attempted to register ssladmin with:
Sites that won't let me
- AOL Mail
- Hushmail (says it is forbidden)
- Mail.com (same as above)
- Mail.ru (says it exists already)
- Windows Live Hotmail
I would also like to point out that with Inbox.com, in order to register and use my account, I had to install some horrid, pointless, useless toolbar. It refused to permit me to log into the service without it being installed. I'd hate to imagine what the toolbar does outside of Inbox.com.
Why is this a problem?
The simple summary: man in the middle.
The not so simple situation: it takes a bit to pull off.
The easiest example I can make of how one can take advantage of this is with Nokia's Ovi service. Ovi is not only an e-mail service, but it also provides software updates, access to an application store, picture sharing, maps, and music. It can also provide access to personal data such as your contacts and files.
Being that Ovi is accessible from a wireless LAN, one could theoretically place an access point in a strategic point (such as a coffee shop) and wait for a Nokia user to check into their Ovi service. If the access point is setup to intercept traffic going to Ovi and the victim's phone connects via the wireless LAN, it could be setup with a certificate that is completely valid by the phone's standards. Once that is done, whatever else is up to the attacker.
While this may seem minor, this same problem could be pulled off via an ISP that allows self-registration of e-mail addresses. Seemingly trustworthy websites could end up becoming subject to attacks that otherwise would not be easily doable without severe compromising of existing accounts.
Being that it was the Easter long-weekend, I decided to register all accounts using the name "Jesus Christ"--this includes the Certcom certificate that I am about to demonstrate.
Since Inbox.com was the first and only one that I bothered to try and make an SSL certificate for, here are two screenshots demonstrating the problem at hand.
As you can see above, this is a normal account that was registered using normal means just like every other service.
And here's my SSL CA account registration. This is prior to providing a certificate signing request that I could have easily done on my own without using any webmail service's servers.
You'll also notice in the second screenshot that that HTTPS is not in use, but Inbox.com does have a valid certificate provided by Thawte.
This is what you should see when you attempt to register. It's funny how Hushmail here gave me alternatives but none of them worked anyway.
I contacted almost all of the noted offending webmail providers with a basic form letter explaining my method and suggested that they repaired the problem immediately. A form letter was created and sent to the individual postmaster and abuse accounts with a deadline of April 17th before this would be made fully public.
However, as I was able to pull off a Certcom registration with Inbox.com, I immediately filed a ticket telling them to close the account. They did so without any response to my alternative e-mail address and for whatever reason, Certcom had decided to block my home Internet connection.
This ticket was filed out of pure frustration, so it seems a bit terse and short.
Nokia's Ovi.com service still permits me to login. I did make an attempt to register a FreeSSL certificate for the site, but nothing came out of it.
Excite's customer support auto-responded no more than ten minutes after I had sent the message with the incident number 100407-000013. The account is still active as we speak.
Lavabit responded to me first within a half-hour of my message being sent. They have addressed the issue. Honestly, these guys were most on the ball.
Mail2World has yet to respond.
The simplest solution using pre-existing infrastructure is to force CAs to send e-mails only to contacts listed in the WHOIS. Provided that the record is valid and complete, it'll provide a much more secure method to registering and renewing certificates.
Beyond that, it may also be time to scrap CAs all together and adopt solutions such as DNSSEC. Being that becoming a trusted authority is rather trivial and that more and more it is appearing that the whole SSL CA system is littered with holes, an alternative is needed to take care of potential eavesdropping and certificate hijacking. DNSSEC is not the complete solution, but is definitely a part of the direction.
The fault in all of this doesn't completely reside with the webmail providers but really the CAs. With that said, those allowing customers to register e-mail accounts without proper and reasonable filtering need to be aware of potential abuses. A simple review of what is allowed and is not allowed as a name would do a lot of good.