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?"
CACert (Score:5, Informative)
try it....
Re:CACert (Score:5, Informative)
Seconded. go here [cacert.org].
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.
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:
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: (Score:3, Interesting)
Sure. You're supposed to trust that your connection between you and the other end of a conversation using that cert will be encrypted.
That's all certs have ever provided; the rest is 100% marketing myth on the part of the CAs, and misunderstood excuses on the part of conspirators like the Mozilla foundation, Microsoft and so on. The fact is that any cert can be compromised within seconds after it is issued, and so can brow
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: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.
Re: (Score:3, Interesting)
At last a well researched reply :)
You've probably missed some hypothetical ones.
Re: (Score:3, Informative)
Heap overflows can be just as dangerous as stack overflows, although nontrivial to exploit.
Stack overflows are preventable too though.
Overwriting returns via stack overflows are totally preventable by using a separate stack for storing return addresses (as in Forth).
Data overwrites are preventable in varying degrees with sentry values.
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
Which doesn't answer the question as their certificate isn't supported in Firefox.
Re:CACert (Score:5, Informative)
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..
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: (Score:3, Insightful)
Sounds like a good way to keep the riff raff out.
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.
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.
Re: (Score:3, Interesting)
Sigh. The point of encryption is to hide what you are saying from some people, while revealing it to some other people. Do you really not understand that you can't do this if you don't know which people you're talking to?
The point of SSL is validation, then encryption. Without both, it's useless. And if you were paying attention to the noise about DNS cache poisoning last week, you should know that, without validation, SSL is truly useless.
Re: (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
Re: (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--wh
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:You've missed the point (Score:5, Informative)
Re: (Score:3, Insightful)
Re: (Score:3, Informative)
The cert isn't included in any browser your are likely to use.
Re: (Score:2)
Comment removed (Score:4, Insightful)
Re:CACert (Score:4, Insightful)
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.
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.
Comment removed (Score:4, Informative)
Re: (Score:3, Informative)
It's much more stricter now. For one thing, they don't sell certs to individual, only to companies. And they also physically mail you a USB signing device for driver signing, not just a certificate.
Re:CACert (Score:4, Insightful)
Re: (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: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: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.
Re: (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 d
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: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.
Re: (Score:3, Insightful)
Oligopolies and cartels can legitimately be complained about too, you know!
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: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.
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, 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.
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...)
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.)
Re: (Score:3, Insightful)
Given the many problems with the way CAs actually verify identities (and don't actually v
Re: (Score:3, Informative)
And my point was that there are commercial certificates (RapidSSL springs to mind) accepted by IE and Firefox that doesn't require any authentication besides having control over the domain. You won't get a meaningful name in the cert, except OU=Domain Validated, but you will get an SSL connection without browser warnings
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.
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...
Re: (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
FF3 is right (Score:3, Interesting)
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!
If you're not willing to lay out as little as $15 for an SSL-Cert that will work on FF3, you are a hokey, untrusted individual!
Re: (Score:3, Informative)
I wasn't willing to shell out $100 (about half my yearly profit!) for the stupid certificate.
It's not quite as bad as all that. Namecheap offers "RapidSSL" for $13 a year. They even have a deal [namecheap.com] where you can get a free SSL cert with registration or transfer of a domain. Still, yeah, SSL certificates are kind of a racket.
Re: (Score:3, Interesting)
Re: (Score:3, Informative)
I'm sure you do. Irrelevant.
>> Again, FF's fault how?
Its not - it has to do with root CAs...like the title of my post implies (let me clarify) [Firefox is] "Not the first one..." [Google Checkout does this too]
>> It's not like it's impossible to accept a self-signed cert, and for all the "scripting" you've done, why don't you mention a quick blurb about FF3's advanced c
I've expirienced this myself. (Score:5, Interesting)
Re:I've expirienced this myself. (Score:5, Informative)
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.
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.
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.
Re: (Score:3, Informative)
I don't see them in my CA collection that shipped with Firefox 3.0.1pre. What's their browser coverage?
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).
Re: (Score:3, Informative)
Sorry, but you have no idea what you're talking about.
GD gives you a full blown SSL cert that works just like what you would get from Verisign.
$30 for a standard cert, $200 for a "wildcard" cert which lets you SSLize all your subdomains.
Re: (Score:3, Informative)
Untrue.
You can get a chained cert for very cheap from godaddy (and others) that will use your own domain name (www.yoursite.com).
Comment removed (Score:5, Insightful)
Re: (Score:3, Interesting)
If you have no guarantees about the identity of the person on the other end, how do you know that your session is really private, when it could be someone sitting in the middle, pretending to
Comment removed (Score:5, Insightful)
IE7 (Score:3, Informative)
IE7 / StartSSL (Score:3, Informative)
IE7 is worse, because its user interface does not ask the user if they want to add the site as an exception as Firefox 3 does. The end result is you get the big, scary warning in IE7 every time you visit the site, but you get it only once in Firefox 3 because you need to add the exception before it will let you proceed to the site.
Anyway, get a free cert from StartSSL [startssl.com] and the problem is solved.
Monopoly? (Score:5, Informative)
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 severa
Re: (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.
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).
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 becau
Monopolistic? FUD alert. (Score:2)
You keep using that word. I do not think it means what you think it means.
There are more Certificate Authorities than just Verisign; e.g. Thawte, GeoTrust & GoDaddy.
GoDaddy charges $15/year for a single-domain SSL cert.
Ah, let's just solve that FACTOR problem... (Score:3, Funny)
1. Step 1 - FACTOR algorithm in polynomial time
2. Step 2 - SSL is obsolete, and certificates are pointless
3. Step 3- PROFIT!
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.
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.
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: (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).
Re: (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
Re: (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-
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.
Re: (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 distribu [verisign.com]
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.
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.
Dumbest statement in the history of security? (Score:4, Insightful)
This is a contender for dumbest statement in the history of security.
The correct solution... (Score:4, Insightful)
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.
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.
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.
Re: (Score:2, Insightful)
Re: (Score:3, Informative)
I wasn't involved in the auditing process when the company I worked for started it's CA, but I believe that assessor is WebTrust. The fees are... significant; as are the physical and technical security requirements.
CA signed certificates aren't quite a license to print money, but almost.
Complying with SOX, PKI, and PCI security requirements all at the same time was an interesting experience.
Re: (Score:3, Funny)
someone with a stuffed wallet. They essentially would have no more room in their pocket to earn money from people who simply want want credentials on their verified, secure web site. Unfortunately that isn't happening soon.
Sounds like a job for Shuttleworth [markshuttleworth.com] then!
Re:Will Firefox do anything about it? No. (Score:4, Informative)