Do the SSL Watchmen Watch Themselves?

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?"

Comments

Let governments handle SSL

[coryking]

SSL certificates are one area best served by government. Bear with me here,

SSL certificates are the online version of your driver's license or your passport. We entrust our governments to provide us with reliable, trustworthy forms of identification. We know that if we see a driver's license or a passport, we can be reasonably certain the person holding said identification is who they claim.

It is becoming increasingly clear that SSL certificates issued by private industry cannot be trusted. Since private industry issues them, there are real standards for how one qualifies for a certificate. A $20 SSL cert from Godaddy is just as valid of identification as a $500 one from Verisign. Worse, the private industry has a conflict of interest. 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, they have to make it as easy to get an SSL certificate as possible or go under. (The bond rating industry suffers from a different, but somewhat similar conflict of interest, actually)

Who then should issue certificates? The only entity that doesn't have to make money--your governments. Ideally you should be able to walk into whatever agency issues photo identification in your country and somehow get an SSL certificate issued. Businesses and non-profits could get them issued by checking a box on the form they use to set up a corporation or LLC.

Letting the government deal with this has many extra benefits. 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. For second, if done right, good governments would issue these for virtually nothing and maybe protocols like S/MIME would finally get widespread adoption.

What about open source projects who currently cannot afford SSL certs? Well, if the government does it, they could file as a non-profit and get one for free (or reduced cost).

How would this work from a technical standpoint? How would browsers deal with a long list that has every countries certificate authority? Dunno, but it seems it wouldn't be a big problem. It is a technical problem though, so we can solve it somehow.

What international agency would regulate this? Who regulates passports? Dunno, but seems to me we already have a long history of internationally recognized identification--both for business and personal use. Why not task those guys with SSL certificates? This is more of a political problem, and isn't as easy to solve as the technical bits.

Bottom line, I know we all seem to hate more government, but SSL certificates are one thing governments should be doing, not private industries. It might create a new class of problems, but I suspect the new problems will be much less severe than the ones we have now.

Re:Let governments handle SSL

[Anonymous Coward]

I can't wait to see the phishing websites validated by the Nigerian government's CA.

Re:Let governments handle SSL

[wizardforce]

Your trust of government is simply astonishing after what the Bush administration has been up to for the last eight years especially considering all those slashdot stories concerning fumbling incompetence on the part of certain governments... The problem wish computer security isn't private industry, it's that there are few direct consequences for companies that produce faulty security systems, banks with shoddy security etc.- legally granted limited liability is a problem, Once they find their own heads on the chopping block after a security flaw is found they'd be a lot more keen on solving the problem.

Re:Let governments handle SSL

[djupedal]

>SSL certificates are one thing governments should be doing

So, after wading patiently thru your treatise, it would seem you elected not to answer the question, which would explain your warmth towards politicos, at least :)

Re:Let governments handle SSL

[minsk]

So you have some governments that issue high-quality reliable certificates.
And some corrupt ones which can be bought for peanuts.

So someone has to choose which root certificates to trust.
Someone, probably being the browser makers.

So what would it solve?

Re:Let governments handle SSL

[timmarhy]

I have to say your wrong. government won't do any better job of this, in fact they don't do a better job of anything really. ultimately it comes down to do you trust a CA? i have to say never, so i don't rely it, instead i examine each certificate and accept or reject them based on other factors.

Re:Let governments handle SSL

[Phroggy]

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.

Re:Let governments handle SSL

[Cyberax]

So we need some way to rate CA quality...

Also, we can consider using money to fix this problem. For example, we can make all CAs put a big sum of money into an escrow account to be given to the first person who shows that CA doesn't perform 'due diligence' while issuing certificates.

Re:Let governments handle SSL

[Anonymous Coward]

SSL certificates are one area best served by government.

I look forward having my next firefox trusting by default certificates issued by the nigerian government... So much more trustable than even a godaddy.

Re:Let governments handle SSL

[mortonda]

Who then should issue certificates? The only entity that doesn't have to make money--your governments.

Specifically, I would opt for Notary Public, maybe as a specially trained office, but the function is nearly identical.

Re:Let governments handle SSL

[thetoadwarrior]

I couldn't be bothered to read this whole thing at 3am but I will say this. There is no reason a $20 cert from GoDaddy is any less valid than a $500 verisign one. The largest difference is one is making you pay extra just as you would for a sports car but in the end both get the job done.

Lastly, trusting the government not to cock this up relies on all countries doing the same thing and it relies on governments sorting their acts out and stop fucking things up as virtually every government seems to do.

Re:Let governments handle SSL

[Cowmonaut]

Hey now, don't belittle the strengths of a bureaucracy because of Bush. There are certain things it can do well, licensing is one of them. It's not perfect (not hard to get a fake ID) but its good enough (moderately difficult to get a GOOD fake ID). Plus, then you know for sure that someone is checking on the security of the certificates because that's 50% of their job.

Now if only they'll make it so where there is a road, there is pipe (for the most part) and get some of the boonie yahoos some decent DSL/Cable/Fiber runs. I wouldn't mind paying taxes as a means for internet access, just like I do for road access. It's convenient and helps everyone. And like the government can't tap my 'Net connection easily now anyways...

Re:Let governments handle SSL

[Lumenary7204]

The United States under the Clinton/Gore administration already tried something similar to this; five words spring to mind: "Clipper, Skipjack, and Key Escrow". (If you need a refresher, I suggest the book "Crypto" by Steven Levy.)

The **last** thing I want is for my government to be the entity that issues the requisite public/private key pairs to the private institutions and companies with whom I do business. My business is **my** business - and not the government's business - until a **legitimate** search warrant or indictment says otherwise. And even then, it's still **my** business.

As the article posting indicates, SSL is built around a Chain of Trust. People buy SSL certificates from the likes of VeriSign, Thawte, Equifax, etc., because they are well-known and (ostensibly) trustworthy organizations.

I, for one, do not entirely trust my government. I don't trust VeriSign and crew all that much, either, but their reputations are a strong motivation for them to do their jobs reasonably well, and provide products that perform as advertised. To do otherwise would damage their reputations, resulting in lost customers and weaker profit margins.

Most governments, on the other hand, don't care much about their reputations, and have little regard for profit margins (just look at the US Government's annual budget deficit). They therefore have no compunction against using excuses such as "national security" and "protect the children" to provide (at best) or mandate (at worst) inferior solutions to technological problems.

Admittedly, some companies - like AT&T, for instance - are so large and well-entrenched that they sometimes bow to the mandates of government, and little heed the damage done to their reputations because of it.

But most companies are not that large, and can ill afford to lose face in the marketplace. Reputation is their bread-and-butter, so they do what's in their own best interests, which may even coincide with their customers' best interests.

Re:Let governments handle SSL

[Darkness404]

Plus, then you know for sure that someone is checking on the security of the certificates because that's 50% of their job.

Yes, and there are also supposed to be people making laws that agree with the constitution and striking down unconstitutional ones, and people that make sure patents are valid before they get approved. But in both of them they fail in their jobs.

And think about the ways that governments would abuse this system. For example AT&T might not have a decently secured site, but because they agreed to wiretap they might give them a certificate. On the other hand a site that sells materials disagreeing with the US government might be rejected a certificate because the government simply disagrees with them regardless of the status of the site.

Re:Let governments handle SSL

[wizardforce]

Plus, then you know for sure that someone is checking on the security of the certificates because that's 50% of their job.

Don't be so sure:
http://www.computerworld.com.au/index.php/id;50110485 they [at least the UK] seem to be fairly adept at losing things, if they screw up big time you still pay for it.. when a company screws up bad enough at least people might have a chance to look elsewhere- no, I think the solution here is to make use of that horrible trait of human nature- greed, well at least enlightened self interest that is... let people deliver a headshot to these companies in court everytime there's a major screw up and things will improve... I think in this case we shouuld be careful with how much power we give the feds, it may seem like a great idea at the time, a lot of things do but idiots like Bush make it very clear that the less power we give these twits the better.

Re:Let governments handle SSL

[Plutonite]

The more stringent their policy, the more applicants they reject, and the less money they make. It is simple math, they have to make it as easy to get an SSL certificate as possible or go under. (The bond rating industry suffers from a different, but somewhat similar conflict of interest, actually)

It's never that simple, clearly, because there is another factor called "trust". If you let in too many false positives, you lose the trust hierarchy and are pushed out of business by the other (more stringent) competitors. Who will put the government out of business when their sloppiness leads to disasters(as it uniformly has when dealing with security)? We trust the government locally because federal/state docs are produced with other federal/state documentation - we have 'faith' in the authentication mechanisms that have been in place before digital technology(though they can also be fooled of course). In fact, online trust is such a hard freakin problem, that I imagine the only way to provide decent answers is the continued commercial activity and competition in the field.

Re:Let governments handle SSL

[Anonymous Coward]

The **last** thing I want is for my government to be the entity that issues the requisite public/private key pairs to the private institutions and companies with whom I do business. My business is **my** business - and not the government's business - until a **legitimate** search warrant or indictment says otherwise.

I beleive the process for obtaining a ssl certificate involves you generating the key pair, then sending the public key to the CA for them to sign with their public key. The CA never sees your private key, and thus there is no such security issue.

Re:Let governments handle SSL

[DiegoBravo]

>> We know that if we see a driver's license or a passport, we can be reasonably certain the person holding said identification is who they claim.
>> but seems to me we already have a long history of internationally recognized identification--both for business and personal use.

Apparently no. That's the reason the travel to USA is now a PITA with all that added biometric registrations.

And for developing countries, the passports never were enough: because immigration laws, most require visa applications that are also a PITA.

I'm not sure if this kind of inter-national burden can be added to IP data without converting Internet in a nightmare or clueless regulations.

Re:Let governments handle SSL

[Anonymous Coward]

Are you for real?

It's not perfect (not hard to get a fake ID) but its good enough (moderately difficult to get a GOOD fake ID).

I am sure you are speaking from personal experience... and not just pulling those "DIFFICULTY LEVELS" out of your crevice.

make it so where there is a road, there is pipe (for the most part)

"For the most part"... nice qualifier. What do you mean by that? SPECIFICALLY.

And like the government can't tap my 'Net connection easily now anyways...

You think that's something to say "ho-hum" about??? Where did you COME FROM?

Re:Let governments handle SSL

[SpaceLifeForm]

Exactly. As an end-user (businesses refer to you as a consumer), you expect
that the website you are interacting with is who you *trust* them to be.
And as the end-user, you expect that the reason you trust the site is because
you have the lock showing in your browser, and you believe the SSL system
is trustable.

Yet, as the end-user, what have you personally seen as evidence
that the https protocol using SSL is really trustable?

Most people have seen nothing.

And yet, here someone says the government should be trustable?

You have to be out of your fucking mind to believe that
the CA role should be managed (mis-managed) by government.

You can't trust government at *ANY* time, so why would this help
fix the CA problem?

Re:Let governments handle SSL

[Anonymous Coward]

Someone modded it Funny but with the current call by the rest of the world for the United States government to allow *them* to have some say in what the internet is or is not for them, and us being as unpopular as we already are, I'd rather it be mostly commercial.

Here's an example. My neighbor(s) across the street are annoying fucks. Their white trash son has to drive past our place at 2am with his truck stereo so loud it can drown out our system at times, and I own a real system, not a GPX $59.95 but I digress. At least one of the kids also throws eggs at one of our cars and they're too stupid to realize that the trail of the eggs every single time has pointed directly at their house, they don't come from other directions. They set off MASSIVE fireworks at all hours of the night long before and after the 4th, to the point that there was a guy killed in the middle of September 2008 right up the street; he was killed at midnight but wasn't found until 8am(his mother was home at the time) and no one called because everyone thought the gunshot was those assholes setting off fireworks again and the cops never did anything to my neighbors when we called so it became a futile effort.

Anyway, the point of the story is. Do you have any idea how long it has taken the government to do absolutely nothing about it despite complaints from everyone around?

Now imagine that you need the Chinese government to stop directing Iliketoletgoatsfuckme.com to your rated-PG educational site about farm animals. We saw how they did with complaints at the Olympics.

If your company can lose a million dollar contract for giving a bad certificate, you'll get shit done quick to remedy it.

Re:Let governments handle SSL

[pha3r0]

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:Let governments handle SSL

[celle]

You forget, many of the companies are limited or just plain monopolies. They don't have to care about reputation as they always know they're going to get paid. So essentially we're getting screwed at both ends and still can't trust anybody. The government has some advantages as an issuer, it's huge, not going away soon, and bureaucracy helps keep the corruption away and eventually can be held accountable for what corruption there is as it's all public. Look at all the hundreds of business scandals of the last eight years and I doubt you can count on more than one hand the number of people held accountable for all of them. That's including the latest series of financial/real estate debacles. The threat of lawsuits hasn't been all that effective at reigning any of this in either. Business has advantages of being more dynamic, well, more than government, and the effects of competition in the market. I won't get into private records as neither side has any kind of shiny record.

According to many arguments, not just mine. Private companies, especially big companies, can't be trusted and neither can government. Guess we're screwed, eh folks?

Maybe go back to actually visiting and talking with people/businessmen and snail mail for business transactions.

Re:Let governments handle SSL

[MindlessAutomata]

Your overall point is rather silly, but this in particular stuck out:

Worse, the private industry has a conflict of interest. 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, they have to make it as easy to get an SSL certificate as possible or go under. (The bond rating industry suffers from a different, but somewhat similar conflict of interest, actually)

Actually, if the business wants their SSL certs to continue to mean anything, then they very well will be rather stringent, at least theoretically. If the certs are meaningless it devalues the certs meaning less people want it in the end. To use a loosely analogous example, a magazine wants to have a lot of stuff to publish, but they won't publish everything--they'll (theoretically) do fact-finding and verifying before bringing things to print. Bungling facts is going to lower their reputation. "More", in the end, can often lead to "less", and business knows that.

On the other end, the government isn't going to be so concerned on the value of the certs because, hey, it's not like the government particularly cares what you think about their certs. The idea that a business must make it as easy as possible to get an SSL certificate "or go under" is ludicrous.

I find it interesting that you trash business doing SSL certs for profit motive supposedly making them hand out certs like candy to get money, and then you go and say an advantage of the government, which you claim "doesn't have to make money" (I guess they can just print it off, but that devalues the overall money supply...), basically can just "rubber stamp" an SSL cert for anyone who walks in! So apparently it's bad for a business to not be (supposedly) stringent but the government can just hand them out to whoever walks in, being a lot less stringent?

We already have laws that could apply to forging SSL certs--fraud. Forgery, probably, or maybe those laws could be updated. Kind of like how, you know, the whole scamming thing often done by shady websites is already illegal in the first place?

As far as licenses, those are different from security measures, which an SSL is.

Then, SSL certs would not be equal for all countries, and we can't just let the USA hand them out. Nigerian SSL certs? HAH!

In the end, though, the real truth is that with computers, nothing is simple, and to think that you'll end up with a "perfect" or "not-easily-breakable" SSL scheme is just as misguided as the pro-DRM crowd. You make it, someone else will break it, whatever it is, whatever system it is.

Re:Let governments handle SSL

[Hordeking]

SSL certificates are one area best served by government. Bear with me here,

SSL certificates are the online version of your driver's license or your passport. We entrust our governments to provide us with reliable, trustworthy forms of identification

No, it's not the equivalent of a driver's license. A driver's license (or other issued gov't ID) is there for the Gov't to verify it has given you permission to do something (for instance, to drive). The fact that it serves as a general purpose identification is an example of feature creep.

Licenses and passports can be faked. 18-21 year olds do it all the time. Making it harder only sets up an arms race. My friend, what we have here is the SSL version of a fake ID.

The government shouldn't be in the business of deciding who and who not to verify. What if they decide to not verify or revoke a cert of someone critical of them?

SSL certs work because you trust the issuer. And the issuer's issuer, and the ultimate issuer.

This isn't an easy problem, as most users of the internet aren't exactly "security" sensitive (even the savvy ones). They look at the top for an "https" and at the status bar for a lock icon. If everything looks good, they go about their business.

For security, it's probably back to the drawing board. For most things, SSL certs probably do well enough in the meantime.

Re:Let governments handle SSL

[MindlessAutomata]

Let me clarify my last statement:

You make it, there is no guarantee that someone won't end up breaking it, or find some flaw or way around the system.

Re:Let governments handle SSL

[MindlessAutomata]

People want justice in the world. They want karma, they want a god or a superhero to come down from above and fix the ills of the world. They want safety, they want security, they want peace.

Government, like religion, usually works so long as you believe in it. When you stand back, however, you often see just how useless and ineffective it is, just like everything else. Truth is, you're not going to find any justice. No hero or knight in shining armor is going to ride out of the smoke and save you.

You can't escape from risk. A lot of the ills of everything else in the world (corruption, stealing, cheating) find their way in government just like everything else. But still people act and pretend as if the government really will be that magical entity that can make things all better, that won't be corrupt, that won't be like everything else in the world.

You are quite right about how businesses will deal with bad certificates. If they've got a bad reputation, then no one is going to give a shit about them. Nobody that is informed is going to buy a security system that doesn't work.

Re:Let governments handle SSL

[sjames]

Clipper etc. was a scheme where a back door was explicitly built in. A system where the government signs your PUBLIC key without ever seeing your private key wouldn't permit such abuses.

That is part of the solution. In addition, the web of trust needs to be more configurable in any case. I may trust a particular key's validity. I might or might not trust keys signed by it. Further, I might trust that much but not trust keys signed by a particular key to sign other keys (I know the key belongs to the person and that person will be careful enough to verify the identity of people he signs, but he's a terrible judge of character so I don't trust him to know who I should trust).

Re:Let governments handle SSL

[Lumenary7204]

You forget, many of the companies are limited or just plain monopolies. They don't have to care about reputation as they always know they're going to get paid.

One could argue that the telephone carrier industry as a whole falls into this category. AT&T may no longer be a monopoly vis-a-vis "Ma Bell". However, one could make a case that "Alltel + AT&T + Sprint + T-Mobile + Verizon" add up to a "collective" monopoly, or (more properly) a hegemony.

The government has some advantages as an issuer, it's huge, not going away soon, and bureaucracy helps keep the corruption away and eventually can be held accountable for what corruption there is as it's all public.

Gotta disagree on this one. Cases in point: Watergate, Iran-Contra, NSA/AT&T Room 641A (not to overuse the example), Coingate, Danngate, Rodgate... That's just a small list of US Federal and State scandals, from off the top of my head; an exhaustive list would fill many, many, many pages (did I say "many"?). The first three scandals listed all revolve around "national security" in some way, shape or form; the last three scandals mostly involve personal gain and prestige.

And while all scandals go public at some point (it's not a scandal if the public never finds out about it), the "accountability" factors do little to stem the tides of backroom dealing. Either way, governments often use "accountability and transparency" to justify actions taken in the name of "national security".

The threat of lawsuits hasn't been all that effective at reigning any of this in either.

Don't even get me started on tort reform in the US...

Private companies, especially big companies, can't be trusted...

That argument could go either way: On one hand, private companies in the US appear to lack a certain "trustworthiness" because they don't need to file quarterly and yearly financial performance statements with the SEC. On the other hand, private companies aren't bound to the "profit-NOW!!" whims of a large pool of shareholders, so they tend to take a longer view of things and operate in a more conservative fashion.

Public companies in the US are somewhat more transparent, because they are required by law to file quarterly and yearly earnings statements with the SEC. These statements are available to the general public, so any underhanded activities by public companies are more likely to be noticed. However, public companies are driven by necessity to take a shorter-term, more immediate view with regard to cashflow because their shareholders demand instant gratification.

Re:Let governments handle SSL

[Hurricane78]

I trust the Chinese government as well as the US government to handle this. You just have to know how to handle them.

The Chinese you simply tell, that they have a second child that they conceived while listening to anti-communistic music, cross the street when the light is green, and read American news sites.

The US you tell, that they just "pirated" the latest hit album from Osama Bin Laden for their karaoke machine while wearing this shirt.

I'm joking. You could really tell both governments anything that includes "they could be bad". They will "find" something themselves as soon as they know you exist anyway.

Re:Let governments handle SSL

[Kent Recal]

So you trust your government less than a random company that has bought its CA status with money?

Re:Let governments handle SSL

[m50d]

You trust each government to sign certificates in its own TLD - Australian government handles .au, French government handles .fr, etc. Then if people want to trust a .cx (say) website that's up to them.

Re:Let governments handle SSL

[wizardforce]

given enough competition I trust that if any of them prove themselves unworthy of trust that it's still a better system than any of our governments could design and no I really don't trust a governmental monopoly over competitive private industry especially when our little government has been caught spying on its own people.

Re:Let governments handle SSL

[Eskarel]

That's not really what signed certs are for though.

You don't really use your signed cert to encrypt your data(for data encryption you don't need a signed cert, and additional information is used within the SSL procedure to generate temporary keys. I can get a copy of the signed cert for your bank, but that doesn't mean I can read the transaction you're making. You don't even have to have a signed certificate to have secure transmission of data.

Signed certs are about validating "who" someone is, they are pretty much exactly like a drivers license of passport, and that's a perfectly valid place for government to be in. That doesn't mean that doing S/MIME through a government agency is necessarily a good idea(at least not for all things), but having the government be the issuer of the certificate used to identify you is a totally different kettle of fish.

Re:Let governments handle SSL

[DarkOx]

You are totally wrong giving the problem to governments does nothing to address the trust issue. Is a cert from Libia as good as one from the UK? How could the average person know other then by using applying the same international prejudices we use today for other things? How is that any different then trusting Godaddy more or less then Verisign?

The problem is a certain popular web browser shipping with windows and the most popular open source browser for following the behavior of the former ilk. They scare uses with big warning dialogs and traffic signal colors rather then educate them on what certificates are and how they really work. They don't even educate users on what they are actually used for and ignore the fact that multiple uses exist.

For instance there are lots of cases where I don't need or care to positively identify the entity on the other end. I just want to encrypt what I am sending to keep my activities a little more secret from prying eyes. In that case a cert from any place is a good as the next the only thing that matters is key length and cipher employed.

Positive identification for or B2B site? The best cert is the self signed one our sales staff physically hands the customer out-of-band. They know who gave it to them! They saw them in person there is no doubt of the validity of the public key. That is much stronger then a third party CA which at best used a automated telephone dial back system to validate me; no matter how much the bribed browser makers to scare folks with red and yellow address bars.

SSL as it exists to day is a RACKET and nothing more these companies should be investigated for RICO and conspiracy with browser authors and each other. That is what government should be doing.

Re:Let governments handle SSL

[Kent Recal]

Would you care to elaborate on how a private company is supposed to compete for trust and profit at the same time, without sacrifying one for the other?

Oh and btw: A governmental CA can not be used to "spy" on anyone. Put down the tin foil...

Re:Let governments handle SSL

[Anonymous Coward]

Mod parent "+7 On The Ball."

Re:Let governments handle SSL

[wkk2]

I'm sure governments would also like to generate your private key while they issue certs. Maybe a middle ground would be to have government enforced standards with audits on the CAs.

Re:Let governments handle SSL

[Znork]

As basically every government is, or wants to, listen in on any traffic they can I don't only not trust them, I am utterly certain that they will issue any number of falsified certificates enabling them to intercept and MITM any SSL communication they want to. The CA's have yet to indicate that desire. Not that I think most would hesitate to sign a false certificate on request from the government anyway.

So for the purpose of certificates, I trust governments far less than a random company. Of course I also trust those random companies even less than I trust any random self-signed certificate as well.

The trust chain between me and the holder of a self-signed certificate is the only one short enough not to contain external parties potentially interested in eavesdropping.

Re:Let governments handle SSL

[Znork]

without ever seeing your private key

Why would they need your private key? As long as they can sign any key as being valid for being 'you' they can make their own signed public/private key pair purporting to be you and MITM any communications to you. To get around that you'd still need out-of-band exchanges of the keys in which case the government signing serves no purpose.

In addition, the web of trust needs to be more configurable in any case.

Without a doubt.

Re:Let governments handle SSL

[Rich0]

Yes, that is how it works TODAY. However, it would only take one bill passed by congress (think Patriot Act) to have the government just issue both keys. Don't worry - they'll only use the copy they keep for "important reasons."

Re:Let governments handle SSL

[JoelKatz]

"The only entity that doesn't have to make money--your governments." It's also the entity that suffers the least for its mistakes.

Re:Let governments handle SSL

[JoelKatz]

"Would you care to elaborate on how a private company is supposed to compete for trust and profit at the same time, without sacrifying one for the other?"

You can't sacrifice trust for profit if you're in the trust business. All you have to sell is the trust people have in you. Give that away and you have nothing to sell.

Re:Let governments handle SSL

[Kent Recal]

I am utterly certain that they will issue any number of falsified certificates enabling them to intercept and MITM any SSL communication they want to.

Well, if that is your concern then you are just utterly clueless about how SSL works.
The CA can not spy on your SSL traffic, no matter how much they want it.

Re:Let governments handle SSL

[wizardforce]

why on earth would you continue to use an untrustworthy company's product if there is any competition whatsoever? why would a company stay in business making profit if people abandon them for more trustworthy companies? If a company wants to make as much money as possible [profit] and being untrustworthy undermines that profit base, why would they be able to continue? the only situation where things could not improve in this manner is with a monopoly, private or public monoplies have no incentive to improve, they get cash either way... all monopolies become inefficient, yes all of them, even this benevelant government you speak of... it's a trust that it does not deserve.

Re:Let governments handle SSL

[AnyoneEB]

The CA cannot spy on any arbitrary SSL traffic, but they can MITM any SSL connection (that they can intercept) because they are able to create a trusted certificate that says anything they want so they can make their own key pair and sign that. Then they can spy on any connection they MITM. More work than just looking and theoretically detectable, but CAs certainly have the ability to spy on SSL connections if they want to.

Re:Let governments handle SSL

[sjames]

Why would they need your private key? As long as they can sign any key as being valid for being 'you' they can make their own signed public/private key pair purporting to be you and MITM any communications to you. To get around that you'd still need out-of-band exchanges of the keys in which case the government signing serves no purpose.

They would only need my private key if they wanted to implement the 'key escrow'/clipper sort of snooping. My only point was that just having the government sign your public key doesn't enable that.

I do agree that there are cases where a government might impersonate someone itself. That's where the configurable web of trust comes in. You might even want to add the concept of scenario and assign different levels of trust based on the scenario. For example, if I'm browsing the website of a Chinese business I would likely trust a key signed by the Chinese government. If I'm talking to a friend in China about politics, I probably DON'T trust a key signed by the Chinese government.

Re:Let governments handle SSL

[ArsenneLupin]

Be careful what you wish for.

The result:

• Usage of this CA will be compulsory for securing interacting with the government
• Usage of this CA will be compulsory for securing interacting with all banks of the country
• Actually, this CA is not really a government entity, but a for-profit company that likes to make you pay through the nose
• This government-sponsored monopoly likes to prop up other monopolies or create other monopolies
• You'll be paying through the nose for gizmos such as signing sticks that don't actually work as expected.
• If you try to fuck with them, you'll be left with ugly stains on the backseat of your car

Re:Let governments handle SSL

[starfishsystems]

I agree with sjames when he disputes your comments regarding similarities between Clipper and X.509. Except that they both concern cryptography, there are no similarities between them.

The Clipper fiasco was a failed attempt by US government to build a deliberate back door into a specialized crypto algorithm. It was doomed for many reasons, not least because governments such as mine pointed out that it would not be in our national interest to import products which used the Clipper chip. Realizing that the US would effectively embargo itself, the Clinton administration eventually came to its senses.

People seem to be confusing SSL with X.509 in this discussion. There is no issue with the SSL protocol. The X.509 certificate framework, which SSL uses, is based on asymmetric cryptography. You state that certificate authorities issue public key pairs. This is an elementary misunderstanding of how asymmetric crypto works. In fact the principal, that is you for example, generates the key pair, then sends the public key to the CA to be signed. This signed object is the certificate. Only the public key is ever on the wire, and there is no risk in exposing it. You can hand it out to strangers, and in fact that's the whole point of having it. Conversely, you never send the private key anywhere, so there is no back door.

You don't entirely trust your government. Well, that's fair, I guess. But take a look around. Let's be practical. Your government already collects taxes to fund its many operations. It already passes legislation and operates a police force and a penal system. It already provides the civil infrastructure we depend on for our daily lives. It already manages a massive identity infrastructure which facilitates our use of public roads and payment of taxes, not to mention voting. It already negotiates with other governments to make reciprocal arrangements regarding passports, trade, and so on. Now you're saying, whoa, that's all cool but for God's sake don't let the government sign certificates?

Re:Let governments handle SSL

[Anonymous Coward]

A very bad idea.

Your government (or any organisation with access to the key stores) now has a copy of every single public/private key pair, which they can use to lawfully(or unlawfully) intercept and decrypt all SSL traffic with...

 

Re:Let governments handle SSL

[Znork]

You need to look up how man in the middle attacks work. As long as they can create a signed certificate saying their server is the destination server they can transparently proxy your communications.

For non-government CA's it's tricky, as they'd have to spoof or control DNS for the domain in question, but for a government it would be trivial. There's already many examples of redirects and censorship proxying being done, and as long as a government can either produce, or compel to be produced, signed certificates authenticating their proxies as the destination they can proxy and read SSL traffic as well.

Re:Let governments handle SSL

[eigenstates]

When we speak of government and id issuance, should we talk about the incredible ease of hacking the RFID chips in the new passports? The push for national ID cards?

Security online is simply a fallacy. DVDJon cracked 'the uncrackable' and just posted it online and now how many DVD ripper programs are there? They even make the DVD players now so they will play burned discs. The idea that they can some how eliminate intrusions in to SSL or prevent media copying with DRM is absurd. And then trying to heap creating this movable Potemkin Village on to the government's plate just means that they will lose focus on what they are really supposed to be doing.

Plus the closer they get to this Internet- the worse it gets.

Re:Let governments handle SSL

[ckedge]

Do you know who I'd trust with this kinda thing? Certain groups of people in the NSA*, NASA, and Education Instututions. If anyone knows how to make something bulletproof, if anyone knows how to do category-5 (CMM) software development, it'd be people from the first two agencies, and people from the latter are both smart and already incented to do things for the good of mankind. And it shouldn't be US centric, of course, everyone in the world should sign on and provide some money and people (I'm a Canuck right here.)

IF we established a federal government agency whose ENTIRE PURPOSE was to set the standards and issue certificates and handle really complicated really important things just like this, an agency that had no other job, and if you hired people from the NSA and NASA to do it... I think it'd kick ass.

The important thing would be to give them just the one job, not give them conflicting aims. Ala the NTSB vs the FAA. We want something as independent and effective as the NTSB, WITHOUT something like the FAA having a say, maybe even the teeth or authority to over-ride the real world equivalents of the FAA.

National Software Security and Certificate Agency

NSSCA
  or
NSCA

Somebody with the right connections should suggest this to the right aides or agency heads of Mr. Obama's new organization.

(*) Yes, the NSA. They're the ones that spend all the time on cryptography, who make unexplainable suggestions to encryption standards bodies that 10-20 years latter turn out to have avoided serious vulnerabilities, etc etc. They've got some kickass people in there.

Re:Let governments handle SSL

[Kent Recal]

Claiming that such a scenario would be "trivial" for a government or anyone else is just nonsense.
The government does not own DNS, nor does it own the ISP pipes. If they want to go to such lengths as to fake a CA they can just as well rubberhose a privately owned CA into doing it for them today - and it would probably be much cheaper on a per-case basis than permanently maintaining the required infrastructure themselves.

Furthermore, what interest does the government have in snooping on our online banking and online shopping sessions on a broad scale?
If you take your tinfoil hat off for a second you'll probably realize: None, zero. They can get all the information contained in these transactions for much cheaper after the fact, if they feel so inclined.

Oh, and the real terrorists and organized criminals are probably smart enough to not rely on an american CA either way... This whole discussion is just way beyond the point.

Let's take a look at reality, January 2009:
The very real problem that we have today is that the privately owned CAs are happily handing out certs to anyone who transfers a few dollars to them - no questions asked. The reason for this is simple: They must sell as many certs as possible - or they go out of business. In order to achieve that goal they have to "streamline" the process of obtaining a cert as much as possible, up to the point of compromising trust because no meaningful checks are performed.

A government CA on the other hand would not suffer from this conflict of interest. In fact, the opposite is true: Governments have a vested interest in providing a secure eCommerce infrastructure to their citizens because that translates to more money spent on the internet and more tax dollars to collect. When you lose money to the Russian Business Network in a phishing attack then the government loses money, too. A private CA doesn't care about phishing attacks because by the time that happens they have already sold two certs; one to you and one to the phisher.

And please don't sing the fairy tale of CAs going out of business when they issue certs to phishers.
VeriSign has issued a spoof cert for microsoft.com and last time I checked they were still in business. Spoofed certs for lower profile targets (i.e. your friendly online shop) can be had with little effort as the CA standards are sinking constantly.

Re:Let governments handle SSL

[Kent Recal]

I take it you have never order a SSL certificate at a shop like RapidSSL, instantSSL and the ilk?
If your definition of trust translates to "owns (or stole) a credit card" then yes, today's PKI is perfectly fine.

Re:Let governments handle SSL

[Znork]

Claiming that such a scenario would be "trivial" for a government or anyone else is just nonsense.

Many governments already do siphon off traffic to proxies and/or interfere in ISP DNS services for child porn blocking, as well as for various intelligence purposes. To think that's hard to do when it's already done is rather disingenious.

they can just as well rubberhose a privately owned CA into doing it for them today

They probably do it regularly. I can't see Verisign objecting to a national security letter. But this thread was originally about having the government _as_ CA.

They can get all the information contained in these transactions for much cheaper after the fact

For some types of information and under certain legal circumstances, sure. Making it even easier and with even fewer parties involved is not in the interest of privacy and security.

They must sell as many certs as possible - or they go out of business.

Oh, don't think I'm a fan of private CA's either, I've made the economic interest point against private CA's myself. Third party trust is inherently flawed; there simply is no third party with more interest in keeping your communications secure than you and whoever you are communicating with. To have any chance at being protected against defection you'd need several independent signers; for practical purposes you're better off just using self-signed certificates and importing private CA certificates valid for specific domains you communicate with under controlled circumstances (physical distribution or other out of band distribution).

Re:Let governments handle SSL

[banished]

Your points are reasonably well thought out, but would this be the same government we think could do a better job of running our healthcare system? I'd rather keep the current set of problems than create another faceless, unaccountable bureaucracy. However, some minimum standards for CAs set by government (NIST?) while leaving implementation to private industry might be appropriate.

Congress is in session. Hide your wallet.

Re:Let governments handle SSL

[z-j-y]

The government never wanted public access to cryptology, they almost jailed PGP author.

Politics aside, you are turning a mathematical problem to a law enforcement problem. It is better to rely on mathematical strength(as far as the best mathematicians know) to fend off fraud. When an existing method is found flawed, quickly move on to a stronger one.

And you do buy locks from private companies, even though breaking in is already illegal, right?

Re:Let governments handle SSL

[z-j-y]

the entire point of CA is to prevent the theoretical man-in-the-middle attack.

if you don't believe in MITM attack, CA is pointless, and government CA is waste of money.

if you do believe in MITM attack, government CA obviously can spy you much easier than any private ones. because they are saying, I am not middle man, because I just told you so.

Re:Let governments handle SSL

[lee1026]

However, this kind thing goes on in private companies all of the time as well. The problem here is one that exists with any sort of large organization.

Re:Let governments handle SSL

[JoelKatz]

All I'm trusting them to do is verify the domain. They do that.

Making it harder to get any certificate at all just means that less traffic will be encrypted. That's a much worse problem than man-in-the-middle attacks.

Re:Let governments handle SSL

[Anonymous Coward]

We need John Postel to personally issue each one.
RIP.

Re:Let governments handle SSL

[MobyDisk]

Clipper, Skipjack, etc. were completey different. Those systems were encryption systems designed so that the government could snoop. Verifying the contents of an SSL cert does not require any special encryption and does not require divulging the private key to the authority.

Re:Let governments handle SSL

[Anonymous Coward]

Wrong. Let CA's degenerate into nothing and let SSL be nothing more than an encrypted stream, which is all it ever was anyway.

Re:Let governments handle SSL

[Sloppy]

IF we established a federal government agency whose ENTIRE PURPOSE was to set the standards and issue certificates and handle really complicated really important things just like this, an agency that had no other job, and if you hired people from the NSA and NASA to do it... I think it'd kick ass.

Entire purpose? How can a government agency have protecting against MitM be their purpose, while that same government has a law like CALEA? At best, their purpose would be "protect against MiTM, except when..."

Re:Let governments handle SSL

[Sloppy]

Worse, the private industry has a conflict of interest.

Who doesn't?

What's next?

[Anonymous Coward]

"What lies ahead for the billion-dollar CA industry?"

Ummm, let me guess... government bailout?

Nope. Government AND private companies

[Cyberax]

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:Nope. Government AND private companies

[__aasqbs9791]

Sadly again it seems I live in a country behind the times (USA). Low broadband access rates, civic authorities that have never even heard of public/private key signing, etc.

Re:Nope. Government AND private companies

[Darkness404]

Low broadband access rates,

Err, you do know that most of it is because the population of the USA is spread across a large area whereas just about any country in Europe (minus Russia) would fit within our borders? If the USA had roughly the same everything just scaled down to the size of a mid-sized state, I'm sure the USA would have the highest broadband access rates in the world.

Re:Nope. Government AND private companies

[iammani]

Its the same in India, I can file my taxes online, and sign them with my private keys (Issued by 3 authorized private cos) or print the confirmation, sign and hand it to the tax office physically.

Re:Nope. Government AND private companies

[__aasqbs9791]

And yet that doesn't address any of my other concerns. I used to think that was the case, but look at all the other things we are no longer first in, and also consider what we did with phone lines and plumbing. We got every house wired up for phones and plumbing in this country. Well, I've heard some places still don't have one or the other, but you get my point. We should have this done already for broadband, but we aren't even close. And that's just for broadband. What about the other things where the population is all that matters, and surface area doesn't (the other half of my argument from above as an example)?

Re:Nope. Government AND private companies

[witherstaff]

OH boy, the 'but the US is huge' argument that comes up every time broadband in the US is discussed. I'd buy that if our metro areas were chocked full of fiber speeds and just the rural areas were slow. The fact is that even in our largest metro areas the US broadband is horrid.

A recent study shows that even our smalled state, Rhode Island, with population density of over 1000 per square mile, has an average speed of only 6.7 Mbps. If you can't make that dense of an area high speed there is something seriously wrong with our system. Namely the Telco lobby arm is so strong that their gov't sanctioned monopoly remains and speeds don't improve.

Re:Nope. Government AND private companies

[Anonymous Coward]

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.

Until a worm takes over your computer and starts impersonating you (or worse, uploads your private key to the cloud). Or are there "tamper-proof" USB keys that actually store the keys that you have to physically plug in when you want to sign something?

Re:Nope. Government AND private companies

[LiENUS]

something like that.

Re:Nope. Government AND private companies

[Anonymous Coward]

The linked study shows nothing of the kind. You cannot base broadband penetration on reported speeds from home users.

My area has 32Mb cable connections available, but the reported speed from home users in my area is going to be much, much lower simply because most people are on the 6Mb plan or get 768k DSL or even dial-up if it's cheap. And that's the way it is all over the United States.

Studies show (sorry, too lazy to link) that the vast majority (~90%) of broadband users in the United States are on the lowest tier plans available and wouldn't pay as little as $10 to double their connection speeds.

Re:Nope. Government AND private companies

[Anonymous Coward]

all that means is the users in rhode island don't need much more than 6.7Mbps on average. Frankly I'm shocked it was that high. Most people I know could still get by with 512k dsl.

Re:Nope. Government AND private companies

[Ed Avis]

Since when was six megabits per second not 'high speed'? To me that sounds like enormous bandwidth. A wireless LAN might have only twice that. Sure, for high-definition porn in real time you might want more, but 6Mb/s is ample for all but the most greedy users.

More relevant is the quality of the upstream network and the amount of contention.

Re:Nope. Government AND private companies

[c_g_hills]

It depends on where you live. When you can get 100mb/s to your home, 6mb/s seems pretty slow.

Re:Nope. Government AND private companies

[neumayr]

But then, the US are a federation of states. How come those states don't take care of their telecommunication infrastructure on their own?
They most likely don't go to some federal entity if their road system needs an upgrade..

Re:Nope. Government AND private companies

[Znork]

Sweden, Finland, Norway and Canada whose population density is lower than the US yet have higher broadband penetration seem to suggest that theory may not be entirely accurate.

Re:Nope. Government AND private companies

[Anonymous Coward]

Why can't it work like that in Poland. We're your neighbors.

Re:Nope. Government AND private companies

[Hognoxious]

Maybe their average population density is lower, but for Canada at least that's misleading. Most of the population is in a belt along the US border. I think Sweden is the same, most people live in a few cities on the Baltic coast and hardly anyone lives in the rest.

However I don't buy the argument that the problem with the US is size and low population density; it certainly didn't stop them building roads to almost everywhere.

Re:Nope. Government AND private companies

[drinkypoo]

The simple truth is that the US is huge. The best solution is to ram through whatever legislation is necessary to get the latest and greatest wireless tech up to cover the last mile. Honestly though the answer there might just be to push mesh networking to the masses. We desperately need to augment the internet as we know it with a mesh network just to increase reliability.

Re:Nope. Government AND private companies

[Nursie]

Just not true.

80% of the US population lives in urban or suburban environments.
The US has a roughly equivalent size and population to the EU.

This excuse has run out of steam.

Re:Nope. Government AND private companies

[Anonymous Coward]

From the ITIF (via a 10 second Google search)(http://www.itif.org/files/2008BBRankings.pdf):
Average download speed in the US: 4.9 Mbps.
Average download speed in Canada: 7.6 Mbps.

From Wiki(http://en.wikipedia.org/wiki/List_of_countries_by_population_density):
Population density of US: 31 (pop/km^2)
Population density of Canada: 3 (pop/km^2)

You need to stop drinking whatever koolaid people hand you.

Re:Nope. Government AND private companies

[Cyberax]

Yes, there are certified secure hardware tokens available. They are optional, though.

There's also a centralized mechanism for key revocation.

Re:Nope. Government AND private companies

[Anonymous Coward]

Average download speed in the US: 4.9 Mbps.
Average download speed in Canada: 7.6 Mbps.

Meaningless. This is what people have, not necessarily what is available.

countries_by_population_density

It's not the density, it's the distribution.

Consider two countries that are 1000 miles by 1000 miles in size and have equal populations.

In one country, the population is spread evenly across all 1,000,000 square miles. In the other country, 99% of the population lives within 100 miles of one of it's borders.

Both have the same population density, but it will be much more difficult (read: expensive) to bring broadband to the first country than the second country.

Re:Nope. Government AND private companies

[Anonymous Coward]

Worms don't take computers; people give computers to worms. If you don't want worms, then don't run them.

Paradigm Shift?

[Zordak]

Apparently somebody didn't get the memo that the only valid way to use this phrase anymore is to mock people who want to grow the enterprise by leveraging synergies.

That is a technical problem

[coryking]

You'd have the browser show which country issued the certificate. Use a flag, use something. Firefox already does this by using a tooltip.

Plus, unlike private companies, we all have a sense of which countries certificates we may or may not trust. A user would get suspicious if "bofa.com" was using a certificate issued by Nigeria or "tesco.com" had a certificate that wasn't issued in the UK. What the fuck is the difference between a certificate issued by Thwarte vs. Verisign? Beats me!

Re:That is a technical problem

[Architect_sasyr]

You're putting a bit too much faith in the user I think.

Perhaps if the browser stored every certificate the first time it was seen, then flagged the user when it was changed (combined with relying on certificate chains and the like) we wouldn't be having so many issues with MiTM.

Re:That is a technical problem

[Kent Recal]

No and yes. I think both of you are making great points.

The flags are a great idea because they give the users who care a meaningful tool to assess the trustworthyness of the site at hand.
Knowing the country of origin is much more meaningful than an anonymous padlock.

Saving the cert fingerprint and raising an alarm on change is not even a great idea by any means - it is just obvious, absolute baseline stuff.
The Mozilla guys are seriously humiliating themselves by fucking up the SSL handling even more instead of fixing the fundamentals...

Re:That is a technical problem

[BlueNoteMKVI]

SSL certificates expire every year (or two or three). If the browser popped up a message to every user when the certificate was updated due to expiration, it would frighten many users away - users who know nothing more than "look for the padlock" if that. I think the idea of the browser checking the certificate for changes is definitely valid, but you'd have to be careful about just when you put out that popup.

Sorry to go off-topic

[Anonymous Coward]

WTF does this tag mean?
"quiscustodietipsoscustodes"

I can't parse it at all. ... Oh.

Qui.....odes

Re:Sorry to go off-topic

[Anonymous Coward]

WTF does this tag mean?
"quiscustodietipsoscustodes"

Who eats custard with custard creams?

Re:Sorry to go off-topic

[chill]

quis custodiet ipsos custodes

Latin for "who will watch the watchers".

Re:Sorry to go off-topic

[93 Escort Wagon]

quis custodiet ipsos custodes

Latin for "who will watch the watchers".

So did you know that phrase before it was used on Star Trek: TNG?

Re:Sorry to go off-topic

[chill]

I sort of tuned out TNG after a while. I didn't realize it was used in there. Also, I don't know if they used the Latin or just a rough translation in Enemy of the State.

One year of high school Latin did it for me.

ILLEGITIMI NON CARBORUNDUM!

Re:Sorry to go off-topic

[Anonymous Coward]

Some of us actually studied Latin, so yes, I knew this before I watched ST-TNG.

Re:Sorry to go off-topic

[Anonymous Coward]

So did you know that phrase before it was used on Star Trek: TNG?

One word: Watchmen.

Re:Sorry to go off-topic

[Anonymous Coward]

they will watch themselves..

Re:Sorry to go off-topic

[lee1026]

So far, at least, similar systems have worked well with a great deal of other identity related things (passports, driver licenses, military ids, etc, etc). Regardless what is actually watching the watchers, it would appear that it worked well.

CONTINUING paradigm shift

[Anonymous Coward]

the change from brick and mortar retail to online shopping probably can't be described as anything else.

demontrate control of the domain in question

[dencarl]

Why don't they use the method Google uses to verify control of a domain (and hence ownership)?

The CA should require a unique file (containing a serial number) to be posted to a specific location on the website. Failing that you should be able to receive mail to an arbitrary email address at the domain.

CAs who don't employ a technical measure (such as above) to verify domain ownership *prior* to issuing a cert would be taken out of the list of trusted CAs.

Re:demontrate control of the domain in question

[lord_sarpedon]

I believe StartCom and probably the other free providers do something like this. StartCom is in Firefox by default, by the way.

Re:demontrate control of the domain in question

[polarsd]

Well, who is going to do that? What about all those browsers that don't get updated, and even so, why trust the update? This is the same problem as with Certificate Revocation Lists (CRL). For the most part, the relying party doesn't check.

Re:demontrate control of the domain in question

[cdrguru]

A brute force attack upon a server which gives you the ability to receive email through it or place files on it does not mean you have legal "control" over the domain.

OK, it tends to indicate it but it is not any real assurance.

Re:demontrate control of the domain in question

[blueg3]

Kaminsky's DNS attack -- and the BGP hack, for that matter -- demonstrate pretty clearly why being able to masquerade as a particular host to the CA is not sufficient to prove you are actually the proper owner of that domain.

You might be wrong

[coryking]

I have no confidence that fake SSL certs would be prosecuted.

Do governments crack down on people who fake their passports? If so, what is their motivation for doing so? How would their motivation for cracking down on SSL forgeries be any different?

Re:You might be wrong

[Fjandr]

How would their motivation for cracking down on SSL forgeries be any different?

You can't transport someone into a country with a fake SSL cert.

Re:You might be wrong

[Anonymous Coward]

Uh.. I think the new passports basically ARE ssl certs.

Re:You might be wrong

[Fjandr]

The ramifications of using a fake SSL cert vs forging a fake passport are vastly different. I thought that would be obvious, but I forgot this is Slashdot.

Re:You might be wrong

[dwye]

> The ramifications of using a fake SSL cert vs forging a fake passport are vastly different.

Correct. A fake SSL cert would be, if the government controlled it, the equivalent of forging their currency. Everyone knows how nicely governments treat counterfeiters.

Re:You might be wrong

[Fjandr]

Forging currency is pretty high up there on the no-no list. Only governments and banks are allowed to create value out of thin air (or rather by stealing value from currently-existing currency). I can hardly see forging an SSL cert, if government issued, coming anywhere near the legal repercussions of forging currency.

Re:*demonstrate* control of the domain in question

[dencarl]

oops, typo in subject: *demonstrate* control ...

We need multiple tiers

[lord_sarpedon]

Need a two tiered system.

The world is so fucked up right now as far as censorship and snooping. We need encryption, everywhere, right now.

Tier 1:
"httpe" that acts similar to SSH - big warning on key changes. Known key can be included in html links even from untrusted sites (such as from a google search results page) for a cautionary warning with no loss of security. No prompt for a new site. Prompt if it changes. Prompt if a link gives a 'known' key different from the given one.

Very easy to gradually deploy.

Tier 2:
Well-known certs for the root nameservers. Stick self-signed cert in DNS records. Sign DNS responses. Imposes a chain of trust type requirement on lesser nameservers.

Tier 3:
The fancier certs being passed around these days which are supposedly hyper deluxe verified. Actual monetary cost involved here. Determine a magic solution to make at least a few of the CAs trustworthy.

Re:We need multiple tiers

[Onymous Coward]

Your Tier 1 may be functionally available already. Plus some.

Check out Perspectives.

If you would rather not read, this page may give you the idea at a glance.

Re:We need multiple tiers

[phantomfive]

You are totally paranoid to a ridiculous degree (seriously, when was the last time you were censored, or even snooped on?), but you make a good point. It would be excellent if you could install your public key in the DNS server. Then if all traffic from the DNS server were encrypted, it would be extremely difficult to create a man-in-the-middle attack, in fact a number of attacks would be made quite difficult or impossible. There may even be a provision for this already in the DNS specification, since it is an extensible protocol. It would just be a matter of convincing DNS hosts to allow to store that information.

Re:We need multiple tiers

[Anonymous Coward]

Very easy to gradually deploy.

Doubtful. Microsoft stick to a standard like ssh and make it interoperble? Did hell freeze over or what?

Re:We need multiple tiers

[Anonymous Coward]

Include the site's key fingerprint in the DNS record. If I have a domain name, I can look up the finger print and be sure that I am talking to the server that I think I am talking to.

What's important is that if I enter "blah.com" into the address bar, I am actually talking to blah.com.

It was vaporware anyways

[Gothmolly]

The "industry" provided no value - it merely allowed you to pretend you were somehow secure, above and beyond the actual SSL part. Smoke and mirrors. If this "industry" dies, it will be a market correction, nothing more.

A Better "Web of Trust"

[a302b]

What about simply creating a better web of trust? For example, if you only trust governments, then you only accept certificates issued by them. If I trust Verisign but not Godaddy, then I only accept Verisign and the other sites I trust.

This is how a web of trust should work. People trust certain sites to issue certificates. As certain sites gain trust, more people want to get certificates from them, etc. I might trust my friend Bob, but there is no reason you should. If a bank or e-commerce site wants to do business, then they need to make sure that they get certificate(s) from sources that the majority of their clients also trust. Simple as that.

This way, governments can issue certificates with the stature you mention. At the same time, it is not monopolized by them, and people who don't trust the government are also free to use certificates by private companies.

Re:A Better "Web of Trust"

[ArsenneLupin]

What about simply creating a better web of trust?

Congratulations!

You Sir have just re-invented CaCert. CaCert is a certification authority which operates by a web-of-trust model: users certify each other after seeing id, and only users having gathered a minimum amount of assurance points can get a certificate.

Unfortunately, CaCert is not trusted by the browsers (such as Mozilla or Konqueror), who seem to be more hung up about expensive audits and pompous root key signing ceremonies.

Other CA's, such as Comodo/CertStar or RapidSSL/GeoTrust don't seem to have any problems being blessed by browsers though. Thanks to these fly-by-nighters it's still very easy to mount an Mitm attack using your open Wifi honeypot, which will be undetectable, unlike this poser here.

Bruce is wrong

[dachshund]

"SSL protects data in transit but the problem isn't eavesdropping on the transmission. Someone can steal the credit card on some server somewhere. The real risk is data in storage. SSL protects against the wrong problem," [Schneier] said.

I respect Bruce, but I think if you say something true enough times, you lose sight of the fact that in this case it may not actually be a valid point. While credit card theft is a major problem, Phishers frequently target bank account login credentials--- which are not stored all over the place. In this case, SSL is one of the primary protections keeping you from all kind of hell (losing your credit card is a pain in the butt, but usually it's insured... losing your banking credentials can be a huge disaster). Now imagine that instead of a few rubes being conned by Phishing emails, you had millions of relatively savvy customers at a large ISP diverted to a fake Bank of America site (perhaps with help from insiders at the ISP). The losses could be substantial.

Again, Bruce is right about one problem but not necessarily about every problem (and I can't help but notice that he works for a storage company...)

Re:Bruce is wrong

[jd]

Well, no, they're not stored every place. Usually, they're stored on the user's web browser or in some other similar system. As I recall from the paper on The Internet Auditing Project, their SSH security was broken because someone had the password on their Windows box and the Windows box was broken into. Also bear in mind that there were many stories in 2008 of servers being cracked, leading to the loss of hundreds of thousands, occasionally millions, of credit card numbers. So whilst I agree with you that Bruce isn't identifying all of the critical points, I would argue that there are an enormous number of weaknesses in existing systems and that almost all of them have been exploited in the past.

For online shopping, I take the line that credit card numbers (and indeed any other personal information) should never be stored on online servers. That information should be passed, still encrypted, to servers behind the DMZ. If DMZ-based systems need to authenticate against such data, they should authenticate against a strong cryptographic hash of that data, never against the raw data itself. All actual use of the data should be on internal, secure networks that have no direct outside access and only very controlled, very limited communication with DMZ-based machines which should be assumed to have already been broken into.

For personal machines, browsers have way way too much access to data. The same basic concept should be applied as for servers, so that browsers are completely sandboxed, the key data (such as accounts, passwords and so on) is kept by software with no direct outside access, and that browsers should merely proxy that data (again, already in encrypted form) to remote sites. Ideally, browsers should never manipulate raw data of any kind, with all true client-side I/O (be it JPEG images, SSL certificates, or whatever) being handled elsewhere.

Re:Bruce is wrong

[NynexNinja]

If counterpane is a storage company, then microsoft is a furniture company.

Re:Bruce is wrong

[Anonymous Coward]

Did BT buy Microsoft too?

Re:Bruce is wrong

[blueg3]

Actually, it's mostly popular to get bank credentials directly from the user's machine via malware. Jacking SSL isn't as successful.

Re:Bruce is wrong

[John Hasler]

Well, not a storage company, but: Counterpane Sold to BT

Re:Bruce is wrong

[John Hasler]

> Jacking SSL isn't as successful.

Yet.

Re:Bruce is wrong

[marcosdumay]

"Jacking SSL isn't as successful."

Jacking SSL wasn't sucessful exactly because it was strong, so there was no known vector to attack it. Since malware couldn't attack SSL, they refrained to less efficient tatics, like relying on the ignorance of the user.

Now, that SSL is broken, it is almost certain that they will start to use the more efficient attacks, that directly target SSL.

Re:Bruce is wrong

[Anonymous Coward]

Yes, Bruce is completely wrong. I don't care if the sweat off his balls knows more about crypto than MIT's graduating class.

MITM attacks may not be a large threat, but were it not for SSL, phishing would be much much easier. If "the real problem" is CC #s in storage, then why are skimmers so often used? Why go through the time and effort if all you need to do is snarf them off a server, Bruce?

I like Bruce, and as a cryptographer he has done many great things. As a pundit, he needs to get some new material. Maybe he should send some of the press inquiries to Ross Anderson for a while.

Re:Bruce is wrong

[blueg3]

SSL isn't really broken. There's one attack against it. It was already known that the attack was possible, the only question was the difficulty. As it stands, reproducing their work is fairly difficult. There's also a quite effective mitigation -- don't accept certificates where any elements of the certificate chain other than pre-trusted root certs use only MD5 as their hash algorithm.

bailout?, Not what I was thinking, but ...

[reiisi]

I was thinking more along the lines of jail time. Scams that take money under false pretenses often do result in jail time.

But, then I thought about the recipients of the current bailouts, and bailouts do seem to be an alternative to jail time.

You could be right.

Re:demonstrate control of the domain in question

[dencarl]

I'm not sure an internet level hack should be considered a valid weakness. By that logic the only way to validate identity is via telephone or fax. But wait, where is that contact info coming from? A Whois lookup could be compromised by the same technique.

Taking a harder line on certs.

[Animats]

There are really three tiers of SSL certs being sold:

1. "Domain control only validated" certs. This means the cert issuer got an answer from an e-mail sent to the domain. This is the "QuickSSL" tier.
2. "Location and business identiti validated" certs. What SSL certs were supposed to mean. The cert issuer actually checked out the business for existence. At this tier, there's often a "relying party" guarantee.
3. "Extended validation" certs. The cert issuer had to meet some audited standards to issue the cert. Mostly used by banks.

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 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:Taking a harder line on certs.

[Anonymous Coward]

Current browsers shouldn't be in a position to *have to* distinguish between #1 and #2. The CAs should have been earning their keep and doing most of #3 all along. The whole basis of the certificate hierarchy is an establishment of "trust". CAs are charged with ensuring that trust isn't miss-placed and they've sold out for quick bucks.

You either trust something or you don't. "Almost trusting" doesn't cut it when I'm making an electronic payment. EV certificates are a symbol of the CA industry attempting to charge for the service they should have been providing in the first place ... again.

Re:Taking a harder line on certs.

[Anonymous Coward]

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.

[Rich0]

The problem is that there is no reason why the vast majority of http communications should be unencrypted as they are today. If you make the SSL verification standards even more stringent, then the cost of obtaining a certificate will raise to a point where SSL will only be used for the most critical functions. Stuff like gmail would be in the clear - which isn't appropriate.

If anything we need to make SSL certs EASIER to obtain, but better distinguish in their use. Even self-signed certs should be usable with browsers clearly explaining the limits of their security and not just flashing warning signs all over the place (which don't appear when not using SSL - even though plain http is even more vulnerable to attack than https using a self-signed certificate).

Re:Taking a harder line on certs.

[JoelKatz]

"The problem is that there is no reason why the vast majority of HTTP communications should be unencrypted as they are today."

The problem is that HTTPS is not cache-friendly. Is there really a reason why every single one of my 8 computers should download its own copy of a 100MB operating system update? (I live in the mountains and have lousy Internet access.)

This is not SSL's fault. But unfortunately, SSL and HTTP are not well-integrated. There is no way to tell what encrypted data is public and what isn't -- you can only secure your bank transactions by assuming all data is private, and that's horribly inefficient.

Re:Taking a harder line on certs.

[sjames]

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.

Re:Taking a harder line on certs.

[ArsenneLupin]

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!"

A marketroid spouting nonsense about technical matters. What else is new?

Of course, you and I know that a CA is supposed to verify identity of the party that they're issuing a certificate to, not its trustworthiness (unless they're issuing a sub-CA certificate, but that's a different matter). Much misunderstanding does indeed come from this misconception of a CA's role.

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.

Ok, now you seem to fall prey to the same misconception. Without being sure about the identity of the party your communicating with, there can be no security. Think about it.

You could be talking to an interloper who does nothing else than pass your messages to your bank, and your bank's messages to you. And take notes, of course.

That's what's is called a man-in-the-middle-attack. And apparently they're not just the stuff of some James-Bond movie, but occasionally do happen in real life. Here, a prankster was setting up an open Wifi honeyspot and rigged it to eavesdrop on SSL communications. Of course, Firefox caught the bad certificates, which the victim dutifully shrugged off and filed as a bug. Haha. Or maybe it was a trawl, she did indeed mention that she was "bumming off an unsecured Wifi access point" a leetle bit too early in the thread...

Without public key verification (either by certificate, or by manually comparing fingerprints) there can be no security against such attacks.

Re:Taking a harder line on certs.

[sjames]

Actually, I am well aware of the issues w/ MITM attacks. However, IF ssl established encryption, then virtual host, then authenticity (to varying degrees of confidence as configured by the user's trust settings), https wouldn't require a seperate IP per virtual host anymore. If I'm talking w/ my bank, I'll surely require authentication as well as encryption.

There are cases (such as a private lan to an internal server) where authentication (particularly CLIENT authentication) w/o encryption may be reasonable.

Of course, authentication often means little. If I am contacting https://argleblargle.nu/ for the first time, I don't have any Idea who that is even if they are authenticated. At most, I can know if I visit again that it's the same place I visited last time.

Re:Taking a harder line on certs.

[ArsenneLupin]

However, IF ssl established encryption, then virtual host, then authenticity (to varying degrees of confidence as configured by the user's trust settings), https wouldn't require a seperate IP per virtual host anymore.

It doesn't. There are several approaches to the problem:

• subjectAltNames and wildcard certificates. Nowadays, certificates can carry multiple site names. Just make a certificate containing all site names (not supported by all CA's, but Entrust and CaCert do)
• SNI (Server Name Indication). This allows the webserver to use a different certificate for different virtual hosts. Soon to be supported by mod_ssl, but already supported (for several years) by mod_gnutls

• . Most clients (browsers) today support it out of the box, only Konqueror seems to be lagging behind, alas!

There are cases (such as a private lan to an internal server) where authentication (particularly CLIENT authentication) w/o encryption may be reasonable.

Client is almost never authenticated via SSL anyways. You're right about the private LAN. Easyest LAN-based attacks are passive eavesdropping, rather than active Mitm. But in most other cases, encryption without authentication of the peer just doesn't make sense. But in a private LAN, you're probably in a position of setting up your own CA anyways, as basically you control your browser's CA lists.

If I am contacting https://argleblargle.nu/ for the first time, I don't have any Idea who that is even if they are authenticated.

But you do know that it's argleblargle.nu, rather than somebody who managed to poison DNS or hijack your router.

Re:Taking a harder line on certs.

[sjames]

Most clients (browsers) today support it out of the box, only Konqueror seems to be lagging behind, alas!

It looks like it is FINALLY on the way, but still practically useless. Notably, no version of IE on XP supports it. Some sites may not care, but most will.

Of course, any alternative would also take time to get support, so that's not a knock on SNI.

Re:Taking a harder line on certs.

[ArsenneLupin]

Notably, no version of IE on XP supports it. Some sites may not care, but most will.

We're speaking about security here. Who cares about IE or Windows? If you've got a virus on your machine, all transport-level security won't help, as the malware will intercept your data before it's encrypted. Or it'll just add a bogus CA to IE's certificate store.

Re:Taking a harder line on certs.

[sjames]

We're speaking about security here. Who cares about IE or Windows? If you've got a virus on your machine, all transport-level security won't help, as the malware will intercept your data before it's encrypted. Or it'll just add a bogus CA to IE's certificate store.

The support team at any e-commerce site fielding a zillion complaints from XP users might care. Yes, there's probably a keylogger and every other bit of malware on the customer's machine, but if the transactions with the webserver at least appear to work OK, the support team doesn't have to hear about it.

Which Government?

[upuv]

You have placed your trust in the government. However which one?

Most governments would with the best of intentions try to do the right thing. However some would not. Some would down right look at this as a cash cow. It would be ripe for the picking of corruption and miss use. With next to no legal recourse.

So who governs the government?

I would contend that this belongs in the hands of grander body. The UN or blocks of countries, the EU, NAFTA, African Union, G8,9,10,11(What ever it is now). etc. At least this way there is an established forum for discussion, sanction, policy standardization.

You are correct on the other hand that companies are not the right bodies to govern the safety of web commerce. This is just begging for greed, non-disclosure and abuse.

Re:Which Government?

[Repossessed]

Ideally, more than one the UN+ a local country competing would be better than either on their own.

Re:demonstrate control of the domain in question

[blueg3]

The domain has to be registered to someone, and the path to companies who hold the "someone" information can be made trusted. You don't have to issue a whois query and hope that the information hasn't been tainted.

For the issuing of SSL certificates, which essentially protect against network-level hacks, being susceptible to network-level hacks is a pretty big deal.

Full Disclosure

[StartCom]

There was huge difference between the recent events and how they were handled. Full Disclosure.

Re:Full Disclosure

[Onymous Coward]

Indeed. Though it's interesting that no one here seems to be thinking about your company's culpability/performance. Either they assumed it was a similar incident (and probably also didn't look twice at the name of the company), or they're only vaguely thinking "SSL bad!" I wouldn't worry about public perception, though sharing your full disclosure is of course due diligence.

Anyone following closely enough will see that Schmoilito clarified your company's performance and behavior. (And I noticed that he was referencing my post on your blog.) Your defense in depth and quick response basically exonerate you. However, please discuss with the other persons who "gave you permission" (so far, Eddy, you look to me like the guy running the show) that your company's giving full disclosure after someone else disclosed your vulnerability makes it look like your hand was forced rather than that you're trying to run an open show.

You should have arranged with Schmoilito about who (probably both of you) would disclose and how and when it would be done. If not at the time of the incident you should have discussed this with him shortly thereafter. I realize it's not half a month since, but the sooner the better. Who knows? Maybe you'll be personally involved in finding a serious vuln at another CA and have to out them, and then you'd want to have already emptied your closet of skeletons.

Anyway, I give your company's response to the incident an A-. Overall very good performance, but points lost for having the attacker disclose your vuln before you, especially when you had cooperative interaction with them.

Re:Full Disclosure

[StartCom]

I'm quite pleased to receive a A- :-)

The reason for not disclosing anything before is perhaps quite easy to understand. Minor events are logged in the ongoing events logs and no further actions are required. Events in the magnitude of issuing a certificate wrongfully due to a bug and which requires modifications to the systems, require detailed reporting (as seen in the "critical event report"). Those reports were reviewed in time by relevant parties and will be presented to the auditors during auditing. A major event like a CA key compromise (we don't sign directly from the root) would have to be made public and handled according to the "disaster recovery guidelines". In such an event, all software vendors, subscribers and the general public must be informed immediately.

The event which happened recently wasn't a major event, but obviously important enough to act accordingly and issue the critical event report. Important to note that no third party could have relied on and have taken damage. Therefore the resolution was appropriate. The disclosure was done in order to prevent any rumors and false accusations about what did and what not happened (once it was published by Mike).

Re:Full Disclosure

[Onymous Coward]

Well then, okay, a solid A. I get the general idea of the non-criticality of the incident, and that mitigates the disclosure time delay. (I still recommend putting good effort towards coordinated disclosure with the vuln finder, if just for PR purposes.) And I like hearing about predetermined procedures for handling (major) events. (I bet you even have specific plans for how to notify "all software vendors, subscribers, and the general public", i.e., in which forums or to which lists or email addresses reporting must be done.)

That said, I'm not very familiar with the intricacies of the CA business and am probably not the best grader. Still, from a layman's perspective, it looks to me like StartCom's behavior in this scenario is sufficient for trust in the organization's procedures and operation.

Now if only the entire SSL PKI model weren't so iffy, what with any trusted CA (out of dozens) being able to subvert the whole system. I get the impression for this model to continue to "work", such as it might, things will have to change. Primarily the stringency of CA performance (and auditing) requirements. And so I don't mind you raising hell when you see shoddy (or even negligent, or even malfeasant) practices. And I am glad to see efforts like Sotirov et al.'s "Creating A Rogue CA Certificate" project, even if it makes me scared. Better frighteningly informed than blithely insecure.

I don't know how feasible this idea is, but I'd rather have a genuine web of trust rather than a commercial one or an institutional one (like what Mozilla corp. or MS or Apple or Opera provide). A real web of trust based on keys vouching for other keys ... vouching for CA performance, thus defining my browser's CA list. Maybe this is a dream and there's no way a system like this would survive gaming or no way it could be practical because people are lazy, but I like the dream. Here's a related project that leans in a democratic direction, Perspectives. Have you seen this?

Re:Full Disclosure

[StartCom]

Correct, specific plans exist for various scenarios. Concerning the web-of-trust, there are some inherent problems without a unifying institutional body. See, security has some clear rules which are easier to enforce in a corporate environment. Specially if you work at StartCom ;-)

And yes, I heard about "Perspectives", so it might have currently a single-point-of-failure problem. Personally I don't believe that it should provide a means for self-signed certificates. It might however provide a good additional layer to existing efforts.

Re:Full Disclosure

[StartCom]

Correction, no single-point-of-failure problem. Retracting this statement.

Nigerian CA?

[Anonymous Coward]

And which browsers will have that CA's root certificate installed by default?

I know you were joking, but you kind of underlined the point of the GP. Was that your intent?

Showtime Network had a documentary about this...

[mosel-saar-ruwer]

A recent study shows that even our smalled state, Rhode Island, with population density of over 1000 per square mile, has an average speed of only 6.7 Mbps. If you can't make that dense of an area high speed there is something seriously wrong with our system.

The Showtime Network had an extended documentary about this very phenomenon - it was called Brotherhood.

My answer is

[coryking]

These are valid questions, no doubt. Who oversees passports? I'd look real closely at how those get handled and steal the bits that work for them. There is a lot of overlap between the two.

With next to no legal recourse.

Once governments handle SSL, this becomes politics on an international level just like trade. If those damn Canadians don't stop with the crappy certificates, we Americans will just stop buying their maple syrup. Or something like that.

That said, ultimately "legal recourse" always distills down to who has the biggest guns.

But you are trading one nightmare for another

[coryking]

My nightmare is a bunch of companies with massive conflicts of interest issuing bullshit certificates. Nobody but nerds understand SSL and Mom and really even myself cannot tell what makes a good certificate "good".

I also think government SSL would actually increase innovation in other, more productive industries. Government issued SSL certificates would most likely mean everybody gets ones. That means things like S/MIME become widespread and SPAM gets harder. That means code signing becomes widespread and not something that costs $300 to $1000. That means with the right legislation non-profit open source companies could get SSL certificates for reduced cost.

Regulations have costs--no doubt. But sometimes the costs of non-regulation are higher. See also: the banking system.

Re:But you are trading one nightmare for another

[DiegoBravo]

Governments never agreed in a single worldwide way to generate trivial sequential numbers (for example, SSN are useless outside USA) and I find a bit impractical (from a political POV) that they can agree on a single scheme for something a lot more complex (and potentially dangerous) like SSL certs.

And in that hypothetical scenario, be ready for USA banning Cuba CA's (and all current enemies); same the other way against USA; and also more bans against several categories of immigrants (as currently happens with driving licenses and SSN.)

I think the problem is more complex so it demands from users some better criteria for decisions, instead of just delegating the decisions to the local government.

Finally, I don't agree with you that geeks understand SSL certs... common geeks just happen to know how to install or get some fingerprint on them but no more. So yes, the current implementation of certs is broken.

The companies...

[Elsan]

The companies will shout "SAVE US!" and we'll whisper... "No."

And yet

[coryking]

You dont seem to worry that Verisign or Goddady has access?

openpgp

[buanzo]

mod_openpgp
enigform

Re:Let governments handle SSL - be the cow....

[Anonymous Coward]

I'm sorry it must be some problem with the software, we cancceled your certificate and I'm afraid we can't retrieve a lost certificate. Oh and please go to the back of line G to speak with the TSA person downstairs - you didn't plan on flying anywhere honey did you?
I'msosorryhaveaniceday
NEXT

Security is an illusion

[Anonymous Coward]

SSL's, or TLS's, are just a layer of obfuscation to minimise (or make it unprofitable) to intercept data between browsers and servers. That's the intent anyway. Nothing new here.

However in practice the security provided by SSL's and CA's is therefore not much more than an illusion for consumers, at a cost.

If we return to the premise that there is no real security and give the onus back onto the business sector, and individual consumer, we'd be doing a better job than further twisting and fragmenting the SSL's verification processes.

The only thing that such complication of SSL verifications seems to do is make the human link ever more so likely as the weakest link. Which it was [is] in the beginning, except it will become even more expensive, and more bureaucratic.

I am not saying we should give up on making life difficult for would be crackers and thieves, but rather saying that the veil of obfuscation should be removed from the consumers, and many of the online traders. Mainly because the veil is non-existent for the thieves and technicians, and only serves to blind the lambs for them.

As for solutions, or alternatives, all I am going to suggest here is that we should have another good look at the points of failure in the transaction, and consider the latest and most cost effective implementations.

One thing is for sure. Keeping the victim shrouded in ignorance at transmission stage will not help them regarding their due diligence at every other step of the transaction.

Schneier is wrong

[Sloppy]

"SSL protects data in transit but the problem isn't eavesdropping on the transmission. Someone can steal the credit card on some server somewhere. The real risk is data in storage. SSL protects against the wrong problem," he said.

[emphasis mine] "The" problem? No, it just doesn't protect against everything that can wrong wrong. It sure as hell doesn't protect against the "wrong" problem.

First of all, you can protect your storage. Not everyone's system is open, and even of those that do have vulnerabilities, they're not always easy to get into. And if we did manage to protect everyone's storage, then somehow I think Schneier would be chastising us for not protecting transmission. He'd be saying, "Secure storage doesn't fix the problem because someone can just eavesdrop on transmission."

Second: holy crap, credit card numbers are all you care about? SSL is used for more than transmitting credit card numbers. There might not even be anything sensitive stored. That doesn't mean you shouldn't bother to protect transmission (both its secrecy and integrity). Have we forgotten that governments have been caught red-handed looking at everything? Have we forgotten that some ISPs are modifying web pages to insert their own ads? What was once paranoid vision by geeks, is now accepted mainstream. That alone is good reason to use SSL (or something like it), even if what you're doing isn't commercial.

It's fine to point out that SSL isn't the magic solution that suddenly makes everything "secure" but comments as general as what Schneier just said, are bullshit.