What Would It Take To Have Open CA Authorities? 529
trainman writes "With the release of Firefox 3, those who have been using self-signed certificates for SSL now face a huge issue — the big, scary warning FF3 issues which is very unintuitive for non-technical users. It seems Firefox is pushing more websites in to the monopolistic arms of companies such as Verisign. For smaller, especially non-profit groups, which will never have issues with domain typo scammers, this adds an extra and difficult-to-swallow cost. Does a service such as this need the same level of scrutiny and cost since all that is being done is verifying domain and certificate match? This extra hand holding adds a tremendous cost and allows monopolistic companies such as Verisign to thrive. Can organizations such as Mozilla not move towards a model that helps break this monopoly, helping establish a CA root authority that's cheap (free?) and only links the certificate to the domain, not actual verification of who owns the domain?"
I doubt it will happen. (Score:1, Insightful)
SSL certs are a great source of revenue. Why would someone want to make a free one.
To create a free one you would have to get Microsoft to agree. They would never do that for say Mozilla "which would a logical choice to do this."
I don't think Microsoft would do it for Google.
It is a way to print money. I wonder just how much revenue Microsoft and or Mozilla get from the different CA root Authorities?
A difficult and hard to swallow cost? (Score:3, Insightful)
$27 a year? (GoDaddy) $50 a year? (InstantSSL) etc.
Sorry, but if an organisation can't swallow around $50 a year then they have more serious problems that wanting SSL.
Comment removed (Score:5, Insightful)
Domain only? (Score:2, Insightful)
I'm all for breaking the monopoly of current root CAs, but for the most part, that's already being undertaken over at OpenCA [openca.org], which is indeed trying to get included into major browsers. (Last I heard, they had problems with IE, but Mozilla and perhaps Apple were willing to let them try if they had several audits, among other things.)
Perhaps a better solution would be for Firefox 3 to detect self-signed certificates (separate from expired, or wrong-domain certificates) and warn the user that there's no good way to be sure that the people running the website are who they say they are, but that if all they want to do is connect and have an encrypted communication, have a simple (but slightly scary) button to proceed, once per session. That of course wouldn't protect against man-in-the-middle attacks, but that's the reason the root CA infrastructure is in place. Getting something like OpenCA in more browsers is probably the best (only?) fix for that.
Re:I doubt it will happen. (Score:2, Insightful)
"Open" vs. "Secure" - A Contradiction (Score:4, Insightful)
I think the optimum solution would be a cheap root CA who is also highly trusted.
I don't know who this would be - maybe someone like a traditional brick-and-morter "bank" which could vogue for an SSL certificate being validated in the same way that are able to link a bank account to a person, company, SSN, etc.
I was going to say also someone like Google.
The point is, if a CA-signed cert was $5, no one would be complaining, but if any 'ol shmucks signed certs were automatically accepted by your browser, the whole system wouldn't mean anything.
You're kidding right? (Score:2, Insightful)
It sounds like some people need to educate themselves on security and the reasons for SSL in the first place. Also take a look at the current situation on the internet - for example how do phishing sites currently operate?
One of the biggest reasons for using or trusting SSL is that you can trust that the website is who they say they are. If you give out certs without validation, you're not helping the community at all.
If you think just encryption is enough, you're wrong. People are rarely defrauded because their packets were intercepted. Using encryption on the internet is like using a armored car to deliver $5 from the man on a park bench to the hotdog stand on the corner. The endpoints are the biggest security problem these days.
All of the phishing attacks have to do with sending you to a malicious site that convinces you to enter your information.
There are cheaper SSL certs out there than verisign, do some shopping around.
Firefox is not trying to harm a small site. They are trying to protect the community from the phishing attacks.
Comment removed (Score:4, Insightful)
Certification trust levels (Score:5, Insightful)
The certification authorities really need to get together with the web browser vendors so the big scary warnings can be made trust-level-appropriate.
For example:
Domain confirmed: [green][yellow][red]
Responsible Party Identity Confirmed: [green with seal][green][yellow][red]
Where "yellow" meant unconfirmed or self-signed and not whitelisted SSL or an easy-to-fake or -steal ID such as a credit card, "red" meant revoked, expired, or invalid credential, and "green" meant a valid SSL or hard-to-fake or -steal personal ID such as a driver's license backed by a notary. "Green with seal" meant a financially-backed guarantee, something big banks would probably get.
Most small-time web sites would be either green/yellow or yellow/yellow, depending on if they had self-signed certificates.
The cost of a "no identity confirmed" green/red certificate shouldn't be much more than domain registration. A "yellow/red" self-signed certificate would remain free.
If people expect "green with seal" when dealing with major financial companies, "green" with most businesses, and "yellow" for personal web sites, they'll give the appropriate level of trust.
Re:Domain only? (Score:2, Insightful)
Trust is the issue (Score:4, Insightful)
The problem with SSL certificate is that what you're supposed to be buying is trust. Your 400$ is supposed to be for VeriSign to validate that (a) an entity of that name/address pair exist; and (b) there's supporting evidence that the applicant represents that entity.
The reiterate strongly: Certificates are about authentication not encryption!
This isn't cheap, it requires a fair bit of effort.
Also, the CA needs to be trusted in the first place. That's very gray, but even old VeriSign is a lot more trustworthy then "Joe Q. Random Computer Service Associates" with a PO Box in RU.
Most proponent of "free" CAs really want the little padlock without any concern about trust because they implicitly trust themselves. Suppose you did have a shall-issue free-for-all CA on the web. What value would you place on its certificates? Would you trust that entity to not have a compromised private key?
Re:Not the first one... (Score:3, Insightful)
The problem is the warning and it should really be changed. These sorts of certs do not guarantee the identity of the parties involved, they just make it difficult to impossible to eavesdrop. There isn't any reason why the key couldn't be stolen or misappropriated.
I definitely sympathize with you, paying that kind of fee is kind of ridiculous. Which is why I do not have one. But really the issue is that Google and the other companies want reliable certs and they're not going to accept all of the certs. If a smaller authority is reliable the only issue is keeping track of them to make sure that's still the case and adding them.
I'd definitely consider asking them about it, especially since it's causing them to lose smaller stores about it.
Comment removed (Score:5, Insightful)
Monopoly?! (Score:3, Insightful)
Not to mention there are a bunch of second level CA's that are very reasonably priced. I think trainman needs to do a bit more research. If you can't afford GoDaddy's prices, I don't think you really need to be concerned with your customers freaking out.
Re:CACert (Score:5, Insightful)
Which does absolutely nothing to stop scaring visitors of your website. We need something that is accepted by default.
Re:Trust is the issue (Score:1, Insightful)
Certificates are all about encryption. Places I can sniff your packets from:
1. A hub.
2. A switch.
3. A Wireless Access Point (hub using invisible cable).
4. Routers on the Internet that I've hacked.
Places I can replace the certificate with one of my own self-signed under the same name from:
1. A hub (ARP spoofing and you use me as your default gateway).
2. A switch (ARP spoofing, confuses the switch too)
3. A WAP (ARP spoofing)
4. Routers on the Internet that I've hacked.
Note that if I'm on your computer, I can just grab the data ahead of time; and if I'm on the endpoint server, I can just use their private key. A fun game is to download all the private keys off a shared hosting server, since they often leave that directory world-readable.
Does No One Understand English Any More? (Score:5, Insightful)
The O.P. mentions "...monopolistic arms of companies such as Verisign."
Okay, look. The word "monopoly" has as its prefix the stem "mono-," from the Greek, meaning "one." That means there can only be ONE "monopoly."
A phrase such as "monopolistic company LIKE Versign..." is absurd on the face of it. If there are other companies LIKE Verisign, then there is no monopoly.
Is it REALLY that hard to understand?
This is an example of how the rising generation is so used to "buzz words" chosen for shock value, etc., and has gone completely away from clarity of speech and writing. What the O.P. means to say, really, is "I don't want to pay the going rate for this service, so I'll call Verisign 'a monopolistic company' because everyone knows 'monopolies' are bad, and that will communicate the 'badness' of 'companies like Verisign.'"
Oddly, the word "rhetoric," also from the Greek (rheteros, "a speech") used to be a positive appellation for the study of good, clear communication of thoughts and ideas. But it has also succumbed to the buzz-word dementia, and now usually means "empty words."
How sad.
Re:CACert (Score:4, Insightful)
Levels of certification (Score:3, Insightful)
There are already plenty of providers selling crap "domain control only validated" certs. We (as SiteTruth [sitetruth.com]) regard those as having no value, and we encourage others to do the same. If it doesn't have an "L" (location) field, it's worthless. The introduction of those crap "quick SSL" certs poisoned the whole cert industry.
It's a problem that certificates which verify business name and address cost too much. They ought to cost maybe $25 per year. Validation isn't that expensive. That's what registered mail is for.
There used to be some enthusiasm for "web of trust" schemes of certification, but since the bad guys organized into criminal networks, domain farms became popular, and it became easy to get phony GMail accounts in bulk, that approach is obsolete.
Re:CACert (Score:4, Insightful)
Well, then O-B-V-I-O-U-S-L-Y you're in favor of evil "monopolies like Verisign," of which there are, of course, several (which means they're not "monopolies" at all, then, but since we just want to say "they're mean and charge too much money," why quibble?)
Re:CACert (Score:5, Insightful)
Verisign and friends aren't much better. They have given SSL certs to all kinds of scammer or ridicuous domain names in the past, and continue to do so.
Trusting that companies like Verisign are doing the right thing is no better than doing nothing.
Re:Certificates ARE about ENCRYPTION (Score:3, Insightful)
Re:Certificates ARE about ENCRYPTION (Score:5, Insightful)
The problem as I understand it is that self-signed certificates are NOT as secure. Specifically a man in the middle attack can easily fake a certificate because your site needs to send the public key to the user in an insecure way (ie: third party intercepts public key, send their own public key, to you they look identical).
The point of a CA is to prevent this by having a public key come pre-loaded on your machine so there is no possibility of successful interception (ie: the replaced public key would be rejected by the CA).
Comment removed (Score:1, Insightful)
You've missed the point (Score:5, Insightful)
This needs to be transparent for it to work. You've already lost the vast majority at "root cert". They have absolutely no fucking idea what you're talking about. That isn't going to change.
If it's not in the default install, it doesn't exist.
Re:CACert (Score:5, Insightful)
Given the general security principle, espoused by most web browser makers, of "Trust nobody unless it's a secure connection, and even then be careful"...
Actually, the principle espoused by most web browser makers seems to be "Trust anybody if your connection is unencrypted, but if you wish to encrypt your traffic, trust no-one unless they've given a wad of cash to a CA."
It seems to me that a user using an unencrypted connection to an unidentifiable web site (that is to say, all http web sites) should receive even more warnings than a user using an encrypted connection to an unidentifiable web site. But somehow, that's not the case.
This Firefox scaremongering isn't just driving people into the arms of Verisign, it's also driving webmasters away from using encryption, even where web forms might be involved. Too bad - encryption is a good thing.
Re:CACert (Score:5, Insightful)
Have you ever applied for an SSL certificate? It's a PITA, because you do have to provide the issuer with a load of documentation (usually comprising of some legal documents such as your employer's charter et al, plus evidence you do, actually, work for them) to confirm you're who you say you are.
What are you talking about? I buy SSL certificates ALL THE TIME, and it couldn't be easier. It's easier than buying the domain name. It's automatic and happens in seconds these days. I have no idea where you get your certs from but yo, you don't seem like you know what the hell you're talking about.
Re:CACert (Score:5, Insightful)
A chain is only as strong as it's weakest link. Verisign can require all the verification they want, but there are other "trusted" root CAs that don't.
I purchased an SSL cert, and because my spam software rejected the provider's messages (with good reason), they had to send my ssl cert to a throwaway address I set up. There was nothing in the way of identification verification.
Regardless of whether or not this was a "one-time" instance, once again we have people trusting big providers simply because they are big providers. A revenue stream does not make you secure.
There is no difference between a free cert, a $25 cert, and a $500 cert - other than the fact that no free cert providers have trusted root CAs by default. Nobody actually reads the certificates, the only time an end user ever cares about cert's it is because a dialog popped up that gave them a warning, and half the time with a warning, the end user simply clicks on through anyways.
People should see SSL certs for what they are - end point-to-end point encryption mechanisms and nothing more. Thinking they are anything more is simply a false sense of security.
Re:CACert (Score:4, Insightful)
I think FF3's cert thing is lamer and lamer (Score:5, Insightful)
I think FF3's cert thing is lamer and lamer
I've been thinking about this... and I'm happy to have FF3 mark the unsecure, secure, and EV-secure sites differently. But it's really, really lame to say that any self-SSL site is WORSE than a random non-SSL site. It's only the same. If they're going to go through the trouble of getting people used to trust markings, they should just mark the self-SSL sites like they mark the unsecure sites. Changing the URL bar to say:
(unverified) https:/// [https]
Would be enough, if they were changing the color/style of the secure sites. (Sure, don't give the self-SSL a lock icon. Fine.)
This is a very uninformed post (Score:1, Insightful)
Other people have said it in nicer ways, so mod me redundant, but this is one of the more uninformed posts I've seen here lately. Real certs do two things:
The warnings are there for self-signed certs because self-signed certs don't do #2. Who cares about the encryption if it's not necessarily a company you trust?
I can imagine a not-for-profit CA that does #2, and maybe can charge less money than Verisign for it, and maybe that can be accepted by the browsers by default after enough time. But it would still cost some money because step #2 is not zero work. But the most important thing is that the browsers should not be pushing this forward--the browsers should wait until that CA is up, running, and proven before they do add it to their default list.
Re:CACert (Score:3, Insightful)
Oligopolies and cartels can legitimately be complained about too, you know!
Re:Certificates ARE about ENCRYPTION (Score:3, Insightful)
Bullshit, a self signed cert contains almost *NO* protection at all compared to a pure plaintext session. If anything, firefox needs to be more paranoid about things like sending things like session cookies, and posts with password fields in clear text.
When a cert failure occurs, there needs to be more than just an "OK" button to click through.
If you want proof, just sit at an airport with cain open for an hour. I think someone like you would be shocked at how many VPN and email credentials for some major fortune 500 companies you can grab.
Re:CACert (Score:3, Insightful)
Sounds like a good way to keep the riff raff out.
Re:CACert (Score:3, Insightful)
Note, that is an SSL123 cert and not an extended validation certificate. If you get an EV cert you have more hoops to jump through going to far as faxed letterhead and the likes.
Although worth noting, if you already have a relationship with Thawte then the process is easier and takes less time. The first cert always takes the longest.
Re:Does No One Understand English Any More? (Score:2, Insightful)
wow, you're pretty pissed about the summary, but how about correcting the poster's misuse of monopoly with oligopoly instead of ranting about how these kids should get off your lawn.
there is something of an enforced oligopoly in the market as only companies that are trusted by default are really usable by web sites serving the general public. the key thing to fix this is to have MS and mozilla trust more root CAs by default and open the market for more competition..
there are some significant barriers to entry into the root cert market, which allow the vendors to charge higher prices than they would be able to if there were low to no barriers to entry. it's simple economics. the most profitable markets are the ones that are difficult to get into, so it's in the economic interests of verisign et al. to keep the barriers in place. that doesn't necessarily mean that there is collusion in the market, but there sure is incentive.
i don't agree that the post is there to shock, it's there to gripe about a mostly closed market and ask for some kind of solution. not a bad issue to raise at all.
--philo
Re:I think FF3's cert thing is lamer and lamer (Score:3, Insightful)
Given the many problems with the way CAs actually verify identities (and don't actually verify potential criminality), I don't really see the point in this aspect of certificates. Surely the fact that they provide public key encryption for sensitive information is far more important and should be encouraged.
Re:I've expirienced this myself. (Score:2, Insightful)
In your case, it's probably appropriate to ask your uses to add CACert or a self-signed certificate to their browsers.
This isn't rocket science.
But it does create a problem with non-tech savvy users try to visit your site and get scared off by the scary warning message.
The specific situations I'm thinking of when I posed the Ask Slashdot, and am currently trying to deal with, are academic and non-profit sites that need encryption. All I want is a cert that will allow visitors to our research project from around the world and differing levels of computer savvy, to visit our web app without getting scary browser messages.
Unfortunately the system is 100% geared towards commercial entities that needs to verify identity. There's nothing for the non-commercial sector, and that's what I'm looking for something to fill.
I had a user yesterday who thought our app was down because he installed FF3 and got this scary error message. Fortunately he was only on the other side of campus and I could walk over and show him how to setup an exception. I can't do that for a researcher in India, China, or Europe.
There has to be a way to get an easy "this cert belongs to this domain" validation without costing huge amounts of money or giving scary, incomprehensible to non-tech user messages.
Re:CACert (Score:5, Insightful)
Would you care to somehow substantiate that claim? How are you going to compromise that cert? What do you mean by "compromise"? Without serious arguments and proofs you really sound like that crazy Time Cube guy.
Do you even have any understanding of how PKI works? Could you prove it by elaborating on it and presenting real attack scenarios? Because without that you just seem to be a troll.
Re:Certificates ARE about ENCRYPTION (Score:3, Insightful)
Wrong. The point of certificates is authentication. The exact same encryption and key exchange thats used in SSL can be done without certificates anywhere in the chain. It is just kind of silly to do the authentication or the encryption without the other.
You obviously know nothing of the types of attacks certficates are there to protect, such as dns hijacking.
No, this is not a bad thing for Firefox. Having non-authenticated certificates allowed by default would break down that layer of trust that people expect when they visit a site using a valid certificate signed by a trusted root. That would be far worse for a web browser than making it hard to access websites that want to use SSL but are too lazy/cheap to get a authenticated certficate.
Go back to your hippie commune to whine, and get a cluepon or two on your way.
Public keys and identification (Score:2, Insightful)
I or anyone else can make a public key, and claim it belongs to GW Bush. The process of distinguishing the real public key for GW Bush from fraudulent pretenders is called "identification". True, many/most paid certs don't do a very good job of it, but a public key is worthless for preventing "man in the middle" attacks unless you have some form of confidence that key A belongs with person A.
Dumbest statement in the history of security? (Score:4, Insightful)
This is a contender for dumbest statement in the history of security.
Re:You've missed the point (Score:3, Insightful)
Re:CACert (Score:3, Insightful)
I think his point is not that there was danger in sending the public key, but that there was no attempt made to verify even that he was connected with the domain. So if you go to a website and submit a certificate request, and then they send back the public key to an e-mail address at the domain the certificate is for, then there's at least some pretense of verification. You've demonstrated that you at least have access to an e-mail address at that domain in order to get that public key. (or else you've done something else clever)
If, on the other hand, they're willing to send that cert to some random gmail address, then I can probably pick any random website I want and get a certificate for that site, without having *any* connection or contact with that site. There's not even a weak pretense of verification.
I can't speak for the mods, but maybe that (paired with essentially calling the guy an idiot) is why your other post got modded down?
The correct solution... (Score:4, Insightful)
Re:I've expirienced this myself. (Score:4, Insightful)
This is utter nonsense.
There is no security benefit to having the browser flip out over self-signed certificates. In fact, it *reduces* security by forcing some sites that would have used self-signed certificates to stop using SSL entirely.
The simplest non-wrong thing to do would be to simply treat self-signed SSL certificates just an insecure site. That way no one is being "tricked" by it, but the self-signed sites still get the security of being encrypted.
The best thing to do would be to mark sites with self signed certificates differently than CA-signed sites (sort of like extra-validation certificates are marked green). Maybe Green with a lock for extra-validation, yellow with a lock for normal validation, and purple with a feather pen for self-signed.
Re:A Trust Web for Victory (Score:3, Insightful)
This idea is very interesting indeed. If I understand you correctly, you're proposing to move the web of trust PKI known from PGP/GPG to the arena currently occupied by X.509 and hierarchical PKI, right?
This could really lift the burden of managing the complexity of trust, life cycles, secure storage of central CA private keys from the CA. I can see that even Verisign has significant problems with that. Their certs don't seem to specify OCSP URLs yet, and they had some scaling problems with CRL distribution points [verisign.com]. Distributing the PKI could solve lots of problems and the cost of maintaining that infrastructure would be more evenly distributed, too, which would lead to practically free certification (with some hidden costs, obviously, mostly in time and effort of participating parties).
There are potential problems here that I see, though.
Adapting the web of trust idea to the web for the HTTPS protocol would need preparing and constantly tweaking some variables. E.g. above what level of trust should Firefox's address bar turn yellow? How do you communicate the level of trust of the given site to the user so that he's likely to understand it correctly?
And how do you prevent coordinated abuse of that system? Note that the OpenPGP's web of trust has never been tested in the situation where successful attacks would be so highly rewarded as they currently are in the realm of HTTPS/X.509 (think phishers and other scammers).
For example, a network of criminals might recruit some number of homeless people from large cities around the world. These people have their IDs, and are willing to do anything for some money they need to spend on food/alcohol etc. It's quite common for those homeless with nothing to lose to get recruited, shaven, dressed and sent into bank offices to open small disposable credit accounts in their own names using their IDs, only to hand all the money they can get to their recruiters who give them some small percentage which they are going to quickly spend anyway. Then they run into trouble with law enforcement when it turns out they cannot pay, but hey, they didn't quite realize what was this all about, they weren't quite sober anyway.
Now the criminals might find it beneficial to recruit those people to go into key signing parties and obtain verified signatures on their keys/certificates practically for free (well, say one cheap wine per signed key). When they collect the necessary amount, they cross sign those keys to gain high enough level of trust and set up a large scale phishing site. They make gobs of quick cash before the web of trust reacts to the manipulation, which can require a significantly long time in a loose informal structure like this.
Would the idea that you propose be resilient against concerted efforts like this one?
Re:CACert (Score:3, Insightful)
Maybe I'm missing something, but gpgauth is setup to make sure you are talking to the same key every time--and not that some company has verified that xyz.com is who they say they are.
Use slashdot as an example. I don't care if they've been verified by Verisign. Seriously--what do they know about me. UID, username, email, website, and a few other BS details.
The scenario is this: Surf to slashdot for the first time ever. Read it, love it, decide to sign up. You click 'sign up', enter your username and your public key. The server now 'knows' you. It encrypts some random data to your public key and sends it to you along with it's public key. You decrypt the data with your key, re-encrypt it to the servers key, and then send it back. You're authenticated.
Now the next time you go back, you enter your username and encrypt some random data to the servers key. If the server is a man in the middle, it won't be able to decrypt your random data. If it's legit, it can decrypt it and re-encrypt it to you. You've just verified the server. Then it sends you some random data, and you decrypt/reencrypt to it. You've just verified both ways.
You're right that there's nothing there to validate that Slashdot is really at 123 whatever st. in Springfield, but you have verified that the server is the same one you signed up with in the beginning--and really, that's all that matters with a lot of sites.
Nothing to hide? (Score:3, Insightful)
Even if you have nothing to hide now, one day you may, and then you probably don't want to advertise the fact by sudden conspicuous switch to encryption.
You might want to encrypt everything possible simply to make life harder for those who listen everything in the hope of catching something valuable.
Re:CACert (Score:3, Insightful)
Do you really seriously believe that plaintext email from an ISP to a domain account is secure? None of the measures you propose is even remotely secure; that you even propose any of those things is ridiculous. If someone controls your upstream router, what does any of those tactics prove to anyone?
The correct solution, as I've said elsewhere, is to couple the DNS with the public key distribution, by using DNSSEC and publishing public keys in the DNS. Without DNSSEC, DNS is insecure. With it, certificate authorities are useless middlemen, and create opportunity for subversion without providing any benefit whatsoever.
In other words, once we have a secure DNS--along with client software to pull public keys out of that, instead of using certificates signed by untrustworthy, costly, third parties--the CAs are obsolete. Naturally, companies like Verisign have been dragging their heels on DNSSEC because it leads to the demise of one of their big cash cows.
DNSSEC is the solution to a number of problems, and will lead to vastly improved security of the Internet by providing a verifiable, trustworthy, highly redundant, distributed, hierarchical database. Once we have that, we'll wonder how we ever got by without it, and why we tolerated the stupidity of the very concept of a CA for so long.