Slashdot Log In
What Would It Take To Have Open CA Authorities?
Posted by
ScuttleMonkey
on Fri Jul 18, 2008 02:06 PM
from the sounds-like-vc-pitch-time dept.
from the sounds-like-vc-pitch-time dept.
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?"
Related Stories
[+]
Technology: VeriSign Jacks Up .com, .net Prices To the Max 215 comments
se7en writes "VeriSign is jacking up prices for the .com and .net domains for the second year running, increasing both by the maximum 7% allowed under its exclusive contract with ICANN. 'Assuming that VeriSign continues the 7 percent rise each year (which seems reasonable given the company's history), registrars will be looking at $9.00 for .com domains by the time the current contract ends in 2012 — a 50 percent increase in six years.' Registrars have no choice but to pony up, and chances are they'll pass the pain on to customers."
[+]
Your Rights Online: VeriSign Granted a Patent Covering SiteFinder 85 comments
An anonymous reader writes "Remember VeriSign's SiteFinder? Turns out that a couple of months back VeriSign was granted a patent on resolving unregistered domains. This came about thanks to its acquisition of eNic, operator of the .CC Domain. How long before Verizon, Earthlink, and OpenDNS are hit up for licensing fees?"
[+]
IT: When Is a Self-Signed SSL Certificate Acceptable? 627 comments
UltraLoser writes "When is it acceptable to encourage users to accept a self-signed SSL cert? Recently the staff of a certain Web site turned on optional SSL with a self-signed and domain-mismatched certificate for its users and encourages them to add an exception for this certificate. Their defense is that it is just as secure as one signed by a commercial CA; and because their site exists for the distribution of copyrighted material the staff do not want to have their personal information in the hands of a CA. In their situation is it acceptable to encourage users to trust this certificate or is this giving users a false sense of security?"
[+]
Technology: Mozilla SSL Policy Considered Bad For the Web 897 comments
Chandon Seldon writes "The issue of digital certificates for SSL and the policies surrounding them comes up repeatedly. I've written an article criticizing the behavior in Firefox 3, which includes a serious comparison of the current Mozilla policy — restricting encrypted HTTP to paying customers — to a violation of net neutrality."
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
CACert (Score:5, Informative)
try it....
Re:CACert (Score:5, Informative)
Seconded. go here [cacert.org].
Parent
Re:CACert (Score:5, Interesting)
They're revoking a certificate roughly every hour, their CRL is 1.9MB in size and from looking at the serial numbers it seems that lots of certificates are pretty close to each other, which means that a significant percentage of issued certs is getting revoked.
This would indicate that their loose verification is being severely exploited by the bad guys.
Now are you completely sure that when you add this CA to your store, you also configure the CRL handling properly? For how often do you schedule download of the CRL? Do you really think it's a good idea to download a 1.9MB CRL every 1 hour (there's no OCSP service for their certs, it seems, at least there's no OCSP URL on their CA certs)?
I suspect that you didn't give a thought to this, as well as the majority of people who install CAcert root certificates in their browser, not suspecting what can of worms from security perspective do they open. They probably don't even know what a CRL is for, not to mention checking the CRL handling settings in their browser after they install CAcert's root x.509.
Parent
Re:CACert (Score:5, Informative)
Well, let's have a look.
Verisign has a much more complex pki hierarchy, so there are much more different CRLs. I've visited my local bank's site and had a look at their cert's chain. There were 3 levels of Verisign CAs above their x.509 cert and two of them had CRL distribution points specified (the top one, Verisign Class 3 Public Primary Certification Authority, had none, but I think it didn't need one since it's highly unlikely that the lower ones like Verisign's Class 3 Public Primary Certification Authority G5 will ever be compromised. They still have a 3rd level below and their 2nd level private keys are probably used only in high security, do-everything-manually-inside a-vault-by-a-highly-trusted-personnel-group context, not for signing any customer's certificate requests).
So I downloaded both CRLs:
and then inspected them:
Parent
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.
Parent
Re:CACert (Score:5, Informative)
There are also two attacks against infrastructure which can compromise a key:
Of all of these, the last one is the only one anyone needs to take seriously. Even then, there are plenty of ways of making directories and files very secure, and making sure that potential exploits like buffer overflows are blocked in advance. (Just use a malloc replacement that prevents them.) The other attacks are so improbable that you can ignore them.
This leave one other attack vector:
This, according to reports, was used to obtain Microsoft's private keys from Verisign. Most reputable cert vendors have established better practices now. Simply choose one that will only deliver keys to an authorized contact point and only after a call-back check or some other authentication scheme.
Parent
Re:CACert (Score:5, Informative)
Parent
Re:CACert (Score:5, Funny)
Or even better, go here [cacert.org], since the above address is an https and Firefox won't accept its self-signed certificate..
Parent
Re:CACert (Score:5, Insightful)
Which does absolutely nothing to stop scaring visitors of your website. We need something that is accepted by default.
Parent
Re:CACert (Score:4, Informative)
If anybody can get an SSL certificate that will be accepted by Firefox, for free, no questions asked... then the entire point of having CA authorities goes down the drain. You can't simultaneously have a certifying entity AND let everybody in. Because if that happens we might as well forget about CA use in the browsers and just use SSL for encryption.
Parent
Re:CACert (Score:5, Interesting)
Sounds perfectly fine to me.
First, what the CA's actually consider "authentication" before issuing a cert is laughable. It ensures nothing except that your credit card wasn't declined.
Second, most people DO NOT pay attention to who the certificate was issued to. Most people don't even know a certificate exists, much less how to see who it was issued to.
Third, especially because of the previous 2 point, a LOT of people really don't care to try and provide those feature. All they want is SSL, so that info isn't transmitted in plain text. If there were a way to do SSL without a CA, that would be great, but as it is you are held hostage to either paying for a certificate or making your website users jump through hoops to accept a self signed cert.
Parent
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.
Parent
Re:You've missed the point (Score:5, Informative)
Parent
Re:CACert (Score:4, Insightful)
All CACert does is verify that you have control of the domain name you're trying to get a certificate for before issuing a certificate. That means that you can, with CACert, register something like "citicardbank.com" using throwaway fake information, put up a phishing website, get a certificate for it, and look perfectly legitimate to anyone you phish, without any of your victims ever being able to find out who you were. It doesn't, of course, have to be phishing. It could be "discountjewelryandelectonics.com", with you raking in the "orders" and running away with the cash, again with nobody able to find out who you are.
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", it makes no sense for Mozilla, Opera, or Microsoft to encourage the use of unaccountable certificates. CACert is fundamentally a bad idea, at least with the current implementation of most web browsers. The only way to make it acceptable is for the user to be warned every time they visit a new website with a certificate signed by a accountability-free CA.
And given it's the warnings the submitter is whining about, well, what's the point?
Parent
Re:CACert (Score:4, Insightful)
Parent
Re:CACert (Score:5, Interesting)
Actually you are way off base here. Mozilla and VeriSign are both members of the W3C Web Security Context working group where one of the things that we have been working on is how to better make use of self signed certificates.
I always enjoy reading articles on Slashdot describing what they imagine the optimum strategy for a large public company is.
Making it easier to use encryption with self-signed certificates is a benefit to a large commercial CA. People who use self-signed certificates today are candidates for an upsell to a public accredited domain validate cert later.
The basic problem is that people think that a CA sells encryption, that is wrong, we sell authentication and in the case of Class 3 or EV, accountability. I cannot guarantee that the merchant you buy from is honest, or that they will deliver that plasma TV. But I can ensure that they are likely to face consequences if they do.
If people really want to set up an open CA then read my book, the dotCrime Manifesto, I describe what we were trying to do when we set up the idea of CA services in the first place. I think that setting up an open CA would be a bit like setting up an open source effort to do people's taxes for them. But someone might work out a way to make it interesting enough for the participants to have it done well.
Parent
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.
Parent
Re:CACert (Score:4, Insightful)
Parent
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.
Parent
Re:CACert (Score:5, Informative)
Why do you need identification to transmit a PUBLIC key (aka SSL cert)? Note: The moderators in this discussion who nuked my other post, like the parent, seem to not understand the difference between public and private keys. Crypto is complicated, but those who don't understand it should not be moderating a crypt discussion!
Nor should they be posting in it. You do not understand the difference between a key and a certificate, nor do you understand the purpose of a certificate authority.
In public/private key cryptography, the public key ensures that one can have a secure conversation with the holder of the corresponding private key. It does not address the problem of verifying who the holder of that key is. So, if Alice and Bob desire a private conversation using asymmetric (public/private) key cryptography, the first step is for them to exchange public keys. However, during the exchange, Mallory intercepts Alice's public key and supplies Bob with Mallory's public key. Mallory can now read the messages between the two and no one is the wiser. Enter the Certificate Authority. The CA's job is to act as a foundation for trust. The CA's key is provided to Alice and Bob securely (i.e. when installing an OS or browser). Alice and Bob can then go to the CA, prove that they are Alice and Bob, and they receive a certificate. The certificate for Alice consists of Alice's public key cryptographically signed by the CA's private key. Bob can then take the CA's public key, which he received previously, and verify the signature on Alice's public key. Bob has then proven that the CA is stating that that public key does in fact belong to Alice.
So, if the CA isn't actually verifying that Alice is Alice or that Bob is Bob, then Mallory can get a certificate that states Mallory is Alice, and we're back to square one.
Parent
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?)
Parent
Re:CACert (Score:4, Informative)
If by "several" you mean "several owned by VeriSign", you're correct. They operate under multiple brands and have purchased a number of other major certificate authorities over the years.
Parent
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.
Parent
Re:CACert (Score:4, Informative)
Actually you can only get a certificate from CACert if you've been assured with enough points, and that's only supposed to happen after in-person ID verification by multiple members. The certificate includes the verified identity of the member, or the organization if that's the case.
You can debate if this web of trust model is acceptable, but it's been used by Thawte for some time now, and its certificate is included in every browser.
Parent
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.
Parent
Re:CACert (Score:5, Interesting)
What do you mean CAcert has no accountability? They have a web of trust in place that actually checks IDs person to person. Thats more than Verisign does. All they do is charge a credit card.
A CAcert server certificate does exactly what it says it should, that the owner/controller of the domain is in control of the server. It does not verify the personal integrety of the person running it. Of course a Verisign certificate says exactly the same thing but some money exchanged hands in order to say so. But you're trained to trust it more because "its always been that way."
Personally I think browsers should ship with no root certificates installed at all, and the user can seek out and install the ones they trust. Have you ever looked at the list of default roots in your browsers? Can you verify that every one of them does more verification than CAcert does?
CAcert is getting close to being audited so that their root will be included in browsers by default. Does that change your stance regarding trusting their server certificates? If not you're going to have to start remembering to remove their root from each browser installation. While in there how many more are you going to remove?
It bothers me seeing people put so much blind trust in Verisign and Thawte and the likes. To take it a step further, have you ever gone out to your bank's web site and written down the fingerprint of their signature and attempted to verify it at your bank? 99.9% out there will say no.
The point of an SSL certificate is to secure the communications line, and to ensure the entity you're communicating with now is the same one you communicated with previously. Intentions of the person/server you're communicating with is outside of the scope. No amount of money exchanging hands will change this fact, yet Verisign has obviously convinced a lot of people to the contrary.
Parent
You think Verisign et al do that? How? +an idea (Score:4, Interesting)
You think Verisign et al reliably do that? How?
There was a /. story maybe a year ago about all sorts of obviously fake ones... what the major cert providers verify is that your payment cleared. Which is _something_ because there's SOME kind of traceability. But it's not much.
I don't really blame them, though, because the problem is fundamental. There's just no real way for them to verify someone is who they say they are, because we don't really have a definition of who that "we" is. It's not like the gov't issues you a social security private key at birth and each corporation too (not to mention going international)
So the thing keeping them secure IS the payment and the record of the payment, and the fact that so many people fall prey to phishing without a valid cert that no one cares.
*****
In my opinion, the best we can do is issue physically linked certs. Cryptographically identical to existing certs, this changes the people part - The certificate authority a) must require a payment, but there's no minimum they can charge b) mails a physical letter with a code c) makes an automated, repeating voice call with a code d) if both codes are entered and they own the domain, issues a cert for that contact info, which can optionally be used to generate certificates for multiple servers.
Now, the hard part is that you haven't verified IDENTITY at all, you've only verified contact information. So the browser would have to literally display this information, if it was one of these contact-certs (perhaps in a bar just below the URL bar) I say in 'these certs' because for these certs you're not even implying that you can trust anything except the
You COULD set this authority up with a relatively small expense. You might be able to write a FF extension to display the addresses. If you have reasonable internal security, you probably could get FF to add you as a trusted authority, at least FOR contact-certs.
That's not GREAT, but it's the best we can do for simply automation for general-purpose merchants/certs... beyond that it's trying to do credit and background checks the old fashioned way.
My only OTHER idea is that the FDIC/NCUA/etc ought to get together and create a CA for US banks. Then you could even make the bank-trusted bar a DIFFERENT color. And presumably the regulators have a secure way to talk to the banks. (I'm not suggesting that this be legally mandatory for the banks to sign up for or use, but I think there's no one who is more likely to be able to authentically verify the authenticity of a US financial institution than the US regulators...)
Parent
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.)
Parent
Re:CACert (Score:5, Informative)
StartCom [startssl.com] is free and already supported by Firefox.
Mozilla just wants CAs to offer some level of accountability and identity verification. Their CA certificate policy [mozilla.org] is explicit in its requirements.
I don't see the point in having Verisign certificates eveywhere, but I also don't see why you should blindly trust a Robot Certificate Authority like CACert, without further assurances.
Parent
Not the first one... (Score:5, Interesting)
When Google Checkout came along, I figured I'd accept that too - so I started doing scripts on my web site to take Google Checkout payments.
This came to a screeching halt when I realized that Google Checkout payments (or at least automated CGI processing of them) would only be done through web sites with SSL certificates signed by one of the "Major Authorities".
I wasn't willing to shell out $100 (about half my yearly profit!) for the stupid certificate.
This FF3 problem is even worse - if you use SSL, your web browser would be screaming to your end-users that you're probably dealing with some hokey-untrusted individual!
Let's just say that in any respect, I won't be having any little buttons on my site recommending that people use Firefox...
I've expirienced this myself. (Score:5, Interesting)
Re:I've expirienced this myself. (Score:5, Informative)
Parent
Try Godaddy (Score:4, Informative)
Please. Don't give money to GoDaddy. (Score:4, Informative)
http://en.wikipedia.org/wiki/GoDaddy#Controversies [wikipedia.org]
This is to say nothing of a number of lower profile controversies and the fact that their entire site is a usability nightmare that seems largely designed to trick marginally informed customers into buying (and cause more savvy customers to explode in frustration).
Parent
No (Score:5, Insightful)
One entire point of SSL is to ensure that the user can trust the site they're connecting to. If I register citicardbank.com, my inability to get an SSL certificate for it without being traced by my phishing victims severely undermines my ability to rip people off.
The only way to get what you're asking for is to get a secondary protocol, somewhere between HTTP and HTTPS, that would provide privacy for the communication link but wouldn't promote the notion that the end domain is what it says it is. Whether such a thing is a good idea is open to question, even if it is desirable.
If push comes to shove, the only problem with the present regime is that it's expensive. There's increasing amounts of competition in that space, so you should expect prices to come down over time. Wait. .com domain names once cost more than what many SSL certs do today.
Re:No (Score:5, Insightful)
First of all, that's not in any way, shape, or form, a counterpoint.
Are you using different top level domains for all your systems? Because if you're not, you should be able to make do with a wildcard SSL certificate, which generally runs to a few hundred dollars per year, not $1,000. Just saying.
In any case, your particular set of circumstances means you have control over who would need the self-signed certificates. In particular, you can legitimately create a CA of your own and import it's certificate into the web browsers of your users, because that CA (you) is accountable to you and your users.
This is very different from someone outside of the organization trying to get "secure access" to your systems, not knowing for sure that they really are connecting to you (and not a typosquatter.)
Parent
Monopoly? (Score:5, Informative)
"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.
Secure DNS can help (Score:5, Informative)
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?
How can anyone possibly establish that a given certificate is associated with a given domain without first proving that they do indeed have the (ownership) rights to establish said association?
What you are asking for can be accomplished via SecureDNS, you can enter the hash of the certificate in the DNS entry and Secure DNS ensures that only the authorized party can enter that association and verifies that it was not changed. SecureDNS facilitates a lot of these kinds of authentication issues by extending the rooted hierarchy of DNS names to securely dissiminate information, whether it be IP addresses of servers or public key commitments. See my paper "Layering Public Key Distribution Over Secure DNS using Authenticated Delegation" (ACSAC 2005).
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.
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?
StartSSL is free or cheap, as you prefer (Score:5, Informative)
They offer certs with domain validation for free. There are gentle attempts to upsell you to higher levels of validation, but their domain validated certificates work without errors. Look here [startssl.com].
If you want certs that are validated to your business' identity (instead of just your domain) and don't indicate in the DN that they were free, there is a small charge.
Certificates ARE about ENCRYPTION (Score:4, Interesting)
it doesnt make a ZIT of difference if the site you are shopping from has a Verisign signed 256 bit certificate or a self signed certificate. almost all certs are encrypted with similar technologies encryption wise. if you are concerned with 'authenticity', you dont know a website or dont trust them or suspect them, you should NOT be shopping there in the first place.
yes, this move of firefox 3 is a VERY bad thing. it really pushes people to the arms of verisign, geotrust (which is verisign) and so on.
not only that, it will also force control panel companies like cpanel, which serve millions of website users through web hosts to have to force users of their services to pay for SSL certs for each server they use or let their users connect to their site control panels through unencrypted connections. that will eventually drive up prices in the high to mid end hosting market. which is BAD, since majority of people host their websites in such small business hosts with $3-4 bucks a month. the overall effect that will have is yet to be seen.
yes, this was a stupid move by mozilla team, unfortunately.
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).
Parent
A Trust Web for Victory (Score:5, Interesting)
Instead of relying on centralized CAs, and implicitly trusting these privileged monopolies, we could shift to trust webs [wikipedia.org].
It's like a social network. You trust who your "friends" trust, and distrust who they don't. With weightings, so some friends' and enemies' associations (and dissociations) count more than others Because some people you trust in their content, but not their judgement of who to trust (and vice versa, but probably more rarely).
Trust webs can perfectly simulate the current centralized trust model. You can just set your trust web to always trust whoever, say, VeriSign trusts, and ignore everyone else, which is what we get by default today. But you could tweak your trust web to say "If my grad student distrusts a site, then ignore whether VeriSign trusts it".
Such a trust web could therefore just ship set up with the current CAs the only trusted authorities, and work exactly the same as now. But we'd each have the freedom (or our sysadmins, who could lock the trust web changes away from normal users) to emphasize whoever we actually trust to influence our automated trust.
Independent authorities could "watch the watchers". So investigators with a reliable track record could become important "second guessers" to the "offical" CAs. People could make their reputation by proving a trusted authority has less than 100% good judgement. And the whole system can become more robust, instead of fracturing as soon as different CAs have different trust levels for different sites.
The technique and some SW is already available, for apps like PGP and others that rely on a Public Key Infrastructure. What's necessary for the critical mass that makes such a system work is for a browser like Firefox to upgrade to a trust web, with an easy and reliable UI with sensible defaults. Then we're as strong as the trust network in which we embed ourselves.
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:Certification crap (Score:4, Informative)
AFAIK, I believe it prevents man in the middle attacks from happening:
You go to mybank.com, but you actually access randommalwareip, which gives you a phony certificate from mybank.com.
Parent
Re:Certification crap (Score:4, Informative)
Certificates don't do that, they guarantee you're talking to the domain you expect to be talking to. CA signed certs prevent man in the middle attacks.
That's it all certs do. If the box you're talking to was hacked, tough. That's outside the scope of SSL certs.
Parent
Re:Certification crap (Score:5, Informative)
The idea of certificates is to authenticate the connection, make it impossible to someone in the middle to pretend to be the server to the client, and the client to the server. Actually, it would be better to require users to have certificates as well, in many cases, as passwords tend to be too trivial.
Now, the price of certificates is horrendous. The passport office provides a document as good, or better, than many certificates, but it doesn't cost many hundreds of dollars to obtain a passport. In fact, as digital certificates are essentially the same as a passport with electronic information, it might be better if the passport office issued digital certificates along with physical passports as a combined package. The added cost to them would be practically nil, and the certificates would have a much greater credibility level than those by most corporations, at least for personal certs.
Parent
Re:A difficult and hard to swallow cost? (Score:5, Informative)
Don't buy from GoDaddy. There are better and cheaper alternatives.
$14.95 - http://www.rapidsslonline.com/rapidssl-certificates.php [rapidsslonline.com]
And unlike godaddy that on is not a chained cert.
Parent