| |||||||||||||
|
| |||||||||||||
The EFF SSL ObservatoryThe EFF SSL ObservatoryPosted Aug 6, 2010 15:30 UTC (Fri) by JoeBuck (subscriber, #2330)Parent article: The EFF SSL Observatory While it seems idiotic to make an SSL certificate for "localhost", I can understand why these get created. If your company has a machine on the internal net named payroll.mycompany.com, and you go to https://payroll.mycompany.com to file your timesheet, you might think that you can just type https://payroll. But your browser will then freak out: Alert! Alert! The host name doesn't match! That's because it's stupid: if the two names refer to the same IP address, this should not be an error. But it can lead IT people to quiet down their panicked non-technical VPs by making certs for every name a machine might be referred to as.
(Log in to post comments)
The EFF SSL Observatory Posted Aug 6, 2010 18:05 UTC (Fri) by HenrikH (guest, #31152) [Link]
Yes it should be an error and thankfully it is. SSL does not protect the ip of the machine, it rather protects the name of the site, the name that it presents to the user via the URL.
Multihomed web servers would be impossible to secure with your scheme of accepting the cert for site.com just because it was given to me by the site sitte.com which resolves to the same ip. I hope you see the problem with that.
For situations like the one you described it's better to buy wildcard certificates since you then can use the same certificate for *.domain.com
Unfortunately a wildcard cert for *.domain.com does not protect domain.com itself though, perhaps for good reasons I don't know.
The EFF SSL Observatory Posted Aug 6, 2010 18:11 UTC (Fri) by flewellyn (subscriber, #5047) [Link]
>Unfortunately a wildcard cert for *.domain.com does not protect domain.com itself though, perhaps for good reasons I don't know.
Yes, it does. I have seen this in action.
The EFF SSL Observatory Posted Aug 7, 2010 5:02 UTC (Sat) by alankila (subscriber, #47141) [Link]
Subject alternative name can be set to two values: domain.com, *.domain.com.
The EFF SSL Observatory Posted Aug 15, 2010 15:16 UTC (Sun) by kleptog (subscriber, #1183) [Link]
While it's OK to give an error, it should not require you to click half a dozen times to accept the certificate, which will then be permanently trusted. Instead it should see that the name in the certificate resolves to the same IP you're looking at and offer to connect you to that site instead.
Hell, I'll take an automatic redirect. Anything is better than the adding of lots of implicitly trusted certificates to your store when you don't actually know them from a bar of soap. That would be nice in situations where machines have lots of CNAMEs.
The EFF SSL Observatory Posted Aug 7, 2010 11:05 UTC (Sat) by tialaramex (subscriber, #21167) [Link]
Of course it's understandable why they get created
What's astonishing is that they get signed
Imagine if you went to a local notary public, perhaps a magistrate say, and asked them to sign paperwork authenticating pictures of a generic clothing model as being pictures of you for a passport application.
What would be astonishing is not that you might do this, but that a magistrate (in this case, practically all the magistrates) would sign the paperwork. The pictures are cut from a magazine!
Even more astonishing would be if these same magistrates, who are clearly incompetent, were to object to a new policy of allowing bakers and gardeners to act as notary publics on the basis that such people lack the skills.
The CAs which have been shown to be utterly incompetent in this analysis are strongly against allowing non-traditional organisations to act as CAs. But we see that in fact they'll allow anyone into the game - so long as they pay a high fee. Not only banks, dubious national governments, and the military, but also supermarkets.
For years people have been scared about rogue CAs. But rogue CAs have never been proved to exist. What definitely does exist is incompetent CAs. Indeed it appears that all or most of the major CAs are incompetent. In many ways an incompetent CA is worse, because if we identified a rogue CA the upstream vendors would all remove that CA from their trust network, and eventually things would get better. But we know that everybody turns a blind eye to the incompetence. Spooks and organised criminals don't need to run their own rogue CA, they can just send fake headed notepaper to Verisign and get a cert issued in the name of any organisation in the world.
The EFF SSL Observatory Posted Aug 12, 2010 9:41 UTC (Thu) by jschrod (subscriber, #1646) [Link]
For internal networks, maybe. (Though one would use a subject alternative name then, not a new cert.) But such certs should not be found on the Internet, where this study detected them.
The EFF SSL Observatory Posted Aug 13, 2010 13:05 UTC (Fri) by buchanmilne (subscriber, #42315) [Link]
You shouldn't be filing your timesheet from a browser running on the ERP server (which is the only situation the 'localhost' cert will/should help you).
Seriously though, for internal-only sites, why not deploy your own CA cert, so you can easily issue certs with subjectAltName's matching the short name, the IP address etc. Or, look for a commercial CA that will allow that (which could be more work than the previous option :-().
The EFF SSL Observatory Posted Aug 24, 2010 11:04 UTC (Tue) by robbe (subscriber, #16131) [Link]
One commercial CA supporting subjectAltName is Thawte (no endorsement, it's just the one we normally use). There are certainly others, I'm sure. With Thawte, each additional name increases the price of your certificate, though (anybody surprised?). So cost may still be a factor to set-up your own CA.
|
|
||||||||||||