Thousands of SSL Certs Issued To Unqualified Names 128
Trailrunner7 writes "The recent attack on Comodo and several of its associated registration authorities has spurred quite a bit of re-examination of the way that the Web's certificate authority infrastructure works--or doesn't. One interesting result of this work is that the folks at the Electronic Frontier Foundation have discovered that there are more than 37,000 legitimate certificates issued by CAs for unqualified names such as 'localhost,' or 'Exchange,' a practice that could simplify some forms of man-in-the-middle attacks. 'Although signing "localhost" is humorous, CAs create real risk when they sign other unqualified names. What if an attacker were able to receive a CA-signed certificate for names like "mail" or "webmail?"' Such an attacker would be able to perfectly forge the identity of your organization's webmail server in a "man-in-the-middle" attack!'"
Re:No news here (Score:5, Informative)
It is new because you would issue a cert for the internal host from your own internal CA. In this case a remote, third-party, seemingly trusted CA has issued a cert for an unqualified host. That's a massive difference and a huge cause for concern.
Re:Wheres the data coming from? (Score:5, Informative)
From the main page [eff.org]...
Re:No news here (Score:5, Informative)
Re:I have a solution!!!! (Score:4, Informative)
Where you don't care about a determined attacker but want to stop a casual eavesdropper.
For example a blog where you want to require users to login. Stolen passwords are a pain but not a major issue but being able to stop people just sniffing them off unencrypted wifi connections makes sense.
Or want to stop ISPs seeing/hijacking pages to insert ads. Although ISPs could do a MITM attack on self signed certs, it's likely that before very long someone will notice an ISP doing it to one cert at which point people will very quickly see that it's happening to all of them.
Many (most?) SMTP servers will negotiate TLS with self signed (or non "official" CA signed certs) if it's available. It would be interesting to know how many email servers are setup to refuse to send if the cert cannot be verified. I'm sure there are some servers out there that do this (and they're probably only allowing manually installed CAs as well) but I expect they're few and far between.
Even between my home mail server that receives my mail and the backup mailserver I have if my home server is unavailable I forward using TLS (and the CA is installed) but I've not even considered bothering to block it if the certs don't match. If MI5 or the police decide they do want to intercept this mail then I probably wouldn't notice as the only visible symptom would be in the mailserver logs where it would no longer say the cert verified OK but someone at an ISP in the link is not going to accidentally start copying my mail traffic like google did with WIFI.
Tim.
Re:No news here (Score:4, Informative)
http://www.apple.com/support/iphone/enterprise/ [apple.com]
Re:No news here (Score:5, Informative)
You should also add in the time it takes to install that cert on every device.
If it's a small company that doesn't have the money to set up their own CA, which was the initial basis of your argument, then they also won't have hundreds or thousands of devices to import the CA cert into. If they have a dozen employees, then it'll take all of 45 minutes to install the cert on an iPhone for all of them.
There are 2 basic attitudes I see here:
1. Who cares if the user gets errors, they should have installed the cert
2. Just set it up according to Microsoft's recommendations and not have users complain.
#1 will result in numerous calls to whatever helpdesk is available. In the extreme, you get the owner/ceo/exec/etc... barking at you because they don't understand the error message. Or, you use an internal CA and have to manually manage all devices. What do you tell the owner when they get a new phone on Sunday morning and ask you why they can't just set it up.
The user shouldn't have installed the cert. If the user can install certs, then you've got much bigger security issues than an error message in the browser. The IT person/department/support company should install the cert. You also don't have to manually manage all devices. I love these people that think they know enterprise IT, because they can plug in a printer and share it between their two home PCs.
Most devices allow some type of remote, group policy based management. If they don't, they really don't end up in businesses. Windows machines can have the cert added by group policy from the domain controller. Blackberry devices have a management platform that allows for similar group control. iPhones have it, too, from what I understand, although I don't support them myself, so I have to go on input from others.
And when the owner gets his new phone, and wants to set it up to check his email on Sunday morning? You tell him that unauthorized devices aren't allowed to connect, to protect his executive bonus from being rerouted to a cracker's swiss bank account. You can relax the security measures, if he puts in writing that he's ok with losing his bonus to crackers. Otherwise, you can set up the phone for him first thing Monday morning when he gets to work.
#2 results in no errors for the end user...it just plain works. The only ones who seem to have a problem are engineers/techs that don't seem to care what the end-user experience is.
You can go about this either way. It's your choice.
I prefer to setup systems so that users don't need to call me every time they get a new device, computer,etc. That is what the autodiscover service is for!
A good end user experience for wireless networks is for any user-provided device to just be able to connect to the network with a click or two, and immediately be able to access anything they need. Of course, this means that your wireless has to be completely unencrypted, with no firewalls protecting anything at all, no passwords required for access, or what have you. Because if there was even a slight impediment to the end user, it would be a bad user experience.
Is that seriously what you're recommending?
Security practices are there for a reason. Sometimes you get overbearing idiots who want a 78 character alphanumericspecial password with no repeated characters, no writing it down, and you have to change it every week, true. Overreaching "security by rulebook" is sometimes counterproductive.
But having "legitimate" CA providers giving out certs for "mailserver" and equally generic hostnames, is downright dangerous. You can do that kind of thing safely with your own CA, because after you've imported the CA cert into your devices, your "mailserver" cert will be allowed, but not some MITM cracker's "mailserver" cert, because it wasn't generated by your CA. Your CA is only recognized within your organization, on your own devices.
When Comodo, Verisign, or anybody else is generating "mailserver" certs, then absolutely anybody with a browser is at risk of their "mailserver" being impersonated by anybody else's "mailserver" cert, because the CA is publicly recognized.