Do the SSL Watchmen Watch Themselves? 171
StrongestLink writes "In an intriguing twist on the recent Comodo CA vulnerability discussed here last week, security researcher Mike Zusman today revealed that three days prior to StartCom's disclosure of a flaw in a Comodo reseller's registration process, he discovered and disclosed an authentication bypass flaw to StartCom in their own registration process that allowed an attacker to submit an authorized request for any domain. During a month which was marked by the continuing paradigm shift to SSL-verified holiday shopping, the Chain of Trust continues to run off the gears, and Bruce Schneier is even commenting publicly that SSL's site validation mission isn't even relevant. What lies ahead for the billion-dollar CA industry?"
Nope. Government AND private companies (Score:5, Interesting)
It's better to use private companies with government oversight.
I now live in Ukraine and we have such a system. Government licenses private companies to work as certification centers and mandates that only certain (strong) crypto algorithms must be used.
As a result, I can use my private key to sign my tax report for IRS (or tax report for my company). IRS in turn uses its own key to sign their letters.
That's pretty cool, if you think about it.
Re:Let governments handle SSL (Score:4, Interesting)
It is becoming increasingly clear that SSL certificates issued by private industry cannot be trusted... Who then should issue certificates? The only entity that doesn't have to make money--your governments.
The problem with your idea is, even though you're correct that private industry cannot be trusted in this matter, the government cannot be trusted in this matter either.
These are technical flaws, not policy flaws - mistakes are happening due to software errors, NOT because some executive decided that allowing anyone to have a certificate without verification would be a great idea. I may trust the government's intentions, but experience suggests that they won't develop a system like this in-house, but contract it out to the lowest bidder, who is likely to have far less experience with this sort of thing than the current players.
For starters, we could make SSL certificates fall under the same kinds of laws that govern passports or drivers licenses. If you forge one, or enter fake information, you could be charged under the same laws that faking a drivers license fall under.
Pretty much all current spam is illegal under the CAN-SPAM act, so spammers could be charged under that law. They're not. I have no confidence that fake SSL certs would be prosecuted.
Taking a harder line on certs. (Score:5, Interesting)
There are really three tiers of SSL certs being sold:
Current browsers don't distinguish between #1 and #2. They should. "Domain control only validated" certs are enough to secure some social networking site or blog, but not good enough to send someone a credit card number. If they're taking your money, the cert should contain enough info to allow you to find and sue them.
Our SiteTruth [sitetruth.com] system distinguishes between #1 and #2, because we're looking for business identity. It's a useful way to filter out the "bottom feeders".
The problems with bogus SSL cert issuance seem to be, so far, confined to the "Domain control only validated" certs. This is an additional good reason to distinguish between them and the better tiers.
Re:Let governments handle SSL (Score:3, Interesting)
Their business makes money by issuing certificates to paying customers, not rejecting customers for bad information. The more stringent their policy, the more applicants they reject, and the less money they make. It is simple math.....
Who then should issue certificates? The only entity that doesn't have to make money--your governments.
Sir. I am not sure where you live but here in America we have seen countless changes made by various government agencies just so they can grab more tax money for there already inflated budgets.
Allow me to weave a tale for my fellow readers. My very first job was in a paper and printing supply warehouse. Things were great. I worked there for about 6 months before I got a rather strange call. It was a customer of ours who placed regular orders for pens and toner and the like. She said she was going to be placing a year end order and would like to know what our current prices on commodity items were. I gave her the run down for copy paper her normal toner carts and some other odds and ends. She said okay and a few minutes later I had a PO in the fax machine.
Now there normal purchases were anywhere from 5-50 dollars. She sent me a PO for 10000 dollars even. The top of the list was her standard set of supplies there was then a note to fill the rest of the 10000 bucks on copy paper.
Now being young and trying to do a good service i called her back to make sure there had not been a mistake. She told me no, that is correct. "We need to spend the rest of our budget or they will not give us as much next year".
Yes, the current system might have holes but I for one am all for keeping business private and reducing the size of MY current government
Re:Taking a harder line on certs. (Score:1, Interesting)
I find this site a bit concerning. I entered my site, which does not use SSL anywhere, and it flags it up red. Surely a site not using SSL should say 'no info available'?
Re:Taking a harder line on certs. (Score:3, Interesting)
Personally, I lost faith in the CAs and the certs they sign early on. I was at a sort of b2b expo (The dot-com boom was just barely beginning but nobody knew it).
I met a representative from a CA that I won't identify, but I'm sure you've heard of them. He came prepared to give 'why you need a cert and https' sales pitch to various sorts of people from CEO to sales to CTO to techie.
He wasn't (apparently) prepared to discuss trust and authentication in any depth. When he told me (paraphrased) that they "KNOW the entity they give a cert to isn't committing fraud because they have to sign a LEGAL DOCUMENT that says they aren't!", *I* KNEW that there was going to be a problem sooner or later.
Of course, https is screwed up anyway because of the way it munges security and authenticity together. Ideally, browser and server should immediately do a key exchange, then once the connection is encrypted, perform optional authentication after the browser sends the host field. The lock icon should indicate encryption and authentication separately.
While I agree with the current idea of a default keyring and trusts since the average user would be lost otherwise, the trust levels should be fully configurable by the user.