Slashdot Mirror
Thousands of SSL Certs Issued To Unqualified Names
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!'"
These are not names the CA should be issuing. The only reason for issuing them is greed.
Make the CA aware that should any illegal activity be done using unqualified names that the CA will held legally responsible.
Watch the unqualified names disappear overnight.
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.
Burns: We're building a casino!
McAllister: Arrr. Give me 5 minutes.
Obviously, the notion that CAs are fundamentally broken, dubiously competent, and somewhat parasitic is bad for business and therefore can be rejected out of hand.
Therefore, I propose the following: All browsers shall be required to stop trusting those inexpensive standard SSL certs, as well as certs issued by budget CAs. 'Extended Validation' certs will now be baseline, with prices remaining unchanged, and two new levels of verification will be added:
'Extended Validation: Pinky Swear!'(indicated by a green background with two interlocking pinky fingers) will have the same standards as 'EV'; but with the additional promise that we had the work experience kid, or a script, whichever is cheaper, check that the certificate request wasn't made from a hotmail account.
'Double-Secret Extended Validation'(icon TBA, pending negotiations with film rightsholders) is so secure that we can't even tell you the process by which we verify applications; but it is super secure.
This should solve all CA related trust issues.
Where are the EFFs SSL Observatory getting their data from, how well has it been validated? Their website only says "We have downloaded datasets of all of the publicly-visible SSL certificates on the IPv4 Internet" which doesn't say anything really - who is compiling this data and how are they doing it?
To avoid "this is an un-trusted root CA", you should use a public cert.
Is it better to setup the cert properly to not give errors, or teach your users to ignore them?
I'd rather teach users to get IT to install our internal CA certs onto their devices before they'll connect so that all the other internal services signed by our CA will work correctly as well.
Of course, we could just pay some "trusted" chimps for a wildcard cert for our internal domain, but having our own certificates with direct control over them and the ability to issue whatever we need when we need it is somewhat preferable.
You know you can add your internal CA to the trust chain and take care of the problem without having to abuse the system, right?
"set up the cert properly" means to tell the mobile device about your CA.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
It takes a few minutes on a linux netbook. I think any company can afford 15 minutes and a $250 netbook.
A certification is a statement of opinion. (And furthermore, it is a statement by a complete stranger who has no relationship with you and owes you jack shit.) The sooner we learn this, the sooner we will start to work on real solutions to the problems (i.e. switch to OpenPGP). If you charge CAs with complicity, you are just legitimizing the flawed idea behind our current CA infrastructure and reinforcing the idea that certifications are some kind of sacrosanct objective statements of truth (or in this case, negligent or malicious statements of falsehood), yet that position is a complete denial of reality.
People treating CAs whom they have never personally met and have a relationship with, as fully trusted, is what has really failed here. In real life (as opposed to the internet fantasy) you can't fully trust a faceless CA's (Comodo, Verisign, whatever) statement that keyid xxx is so-and-so, any more than you can trust a stranger on the street to hold your wallet for an hour while you step away. Let's end the fantasy, instead of going to court and demanding that the delusion be continued to be given respect.
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
.local. is a valid TLD that is used NOW. It is used by multicast DNS. All devices on the local network that support mDNS are expected to advertise themselves in the .local domain.
I am TheRaven on Soylent News
A widely trusted CA shouldn't issue certificates for unqualified hostnames. It is a bad practice. And if a document calls a bad practice for a best practice, I'll question the validity of said document.
However, I think the main target for criticism should be the SSL clients. When a client access a domain name that is not fully qualified, it should expand it to a fully qualified domain name before validating the certificate. The concatenation of unqualified hostname and DNS search path happens on the client machine. I don't see any good reason for using this concatenation for DNS lookup but not for validating the certificate. Ideally the resulting hostname would be visible to the user. For example for URLs in a browser, I would make the browser implicitly redirect to the fully qualified hostname. In fact such an implicit redirection would be a good idea even for http requests. Using unqualified hostnames has a drawback because the http server may only have the fully qualified version configured, the administrator might not always know about the use of a DNS search path since clients need not be on the same network as the server.
If clients would always use the fully qualified domain name for validating certificates, then there would no longer be a reason to issue certificates with unqualified hostnames.
One question remains, can clients mistake what was intended as an unqualified hostname for a fully qualified hostname. (I don't know if the representation in the certificates use a trailing dot to distinguish the fully qualified hostnames from unqualified hostnames). If the clients cannot tell the difference, this could be a security problem. A heuristic that is used in many places is, that if there is a dot somewhere in the middle of the hostname it is a fully qualified hostname, and otherwise not. However even if there is multiple components separated by dots, you can still append a DNS search path. And a hostname with a single component can be a valid fully qualified hostname. A few TLDs actually have A records for the TLD (all cases I know of will redirect to the administrator for the TLD).
Do you care about the security of your wireless mouse?
If you want nonstandard certificates, you should setup your own internal CA and add that CA as trusted on the devices where you need it. Devices where you cannot add a CA shouldn't be using SSL to access unqualified hostnames. In those cases get a certificate for the fully qualified hostname, and configure the device to use that.
Do you care about the security of your wireless mouse?
Yea, its uber tricky ... if your using an OS that wasn't actually designed for enterprise use.
I freaking hate defending MS, but in a domain/active directory setup, running your own internal CA is painless. The CA cert is automatically pushed to all machines in the domain so the domain can function properly anyway so every windows machine is covered by default. Cert expired? no biggy, republish, click click click, entire domain updates within 24 hours, small offices within minutes.
Users don't need to know anything about CAs or certs, the OS and servers do their job and take care of all that for you.
Unix machines aren't as nicely integrated into ActiveDirectory so you have to manage those some other way, but if your a company of any size at all, you've already got a way to manage your unix boxes don't you?
Running your own CA is only an issue if you don't know what you're doing, i.e. not an admin, just someone who plays one for their local business who doesn't know any better. If you have a clue, its not particularly difficult.
Of course, the fun flip side to that is ... I can and have issued a fully trusted cert sites outside our network in order to snoop on encrypted traffic via an SSL bouncer, and since the cert is signed by our internal CA, everyone validates it just fine.
Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
You should also add in the time it takes to install that cert on every device.
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.
#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!
http://www.apple.com/support/iphone/enterprise/
turn up the jukebox and tell me a lie
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.
"City hall" in German is "Rathaus" Kinda explains a few things......