Slashdot Mirror
Ask Slashdot: Does SSL Validation Matter?
An anonymous reader writes "Right now, in an email list excluded from the public eye, some bright people are discussing the future of SSL. Under debate is (a) do they allow DV (domain only validation) certificates to continue to exist (exist for e-commerce use? only encryption use?) or do they require a higher degree of certificate validation? (b) Do they allow certificates to be issued with non-unique common names (certificates used on internal networks, think your exchange server) or do they ban the practice? If this were 'hypothetically' a heated debate going on right now and you could chime in, what would you say?"
Ask the Chinese. They've been pwning our ass for so long, they know what's secure and what isn't.
What's disturbing is that whoever is allowed on this mailing list imagine that they can make decisions out of the public eye and in secret. I call for them to make their discussions public immediately, with their list open to subscriptions and posting, and all past messages archived on the web for all to read. Failing that, we must ensure that no one respects the decisions of any committee operating in secret, for if they hide from the public, they don't have our interests at heart.
From my cynical POV, the industry is all about money and little to do with security. From the browser makers to the CAs.
The browsers by default won't warn you if say your US bank's server cert is one day signed by CNNIC (China) while you're in China. Or vice versa.
The CAs (Verisign, Comodo etc) have been known to sign certs that they shouldn't. And the browser makers don't kick those who repeatedly screw up.
When SSL keys can be distributed through DNSSEC, there's no need for CA-granted domain-only certificates. Then you can have just "extended validation" certificates from CAs.
It needs to go away.
SSL has numerous applications and needs that it serves. What we really need is a graduated system of "validity" which allows for things that don't need the "uber-valid" level of certs to operate.
Secondly, the long-standing ripoff in terms of costs extracted from this system are a symptom of this problem, creating and maintaining a monopoly-level stranglehold on doing things that don't need to cost nearly as much as they do.
Personally, I would prefer a decentralized web-of-trust kind of system for all but the highest level of confidence (maybe even for that, too, but I can envision a necessity to still centralize the absolute top layer).
-SS "Teach the ignorant, care for the dumb, and punish the stupid."
Personally, I would prefer a decentralized web-of-trust kind of system
Which means that instead of CAs making money, the airlines will, as people will have to fly to key signing parties in order to get their public keys into the global web of trust as opposed to a local one.
I want my free encryption because I don't trust some 3rd party to tell me whether I should trust the web site that I am visiting. Encryption and identity should never have been tied together in the first place. It's unfortunate that this business method has succeeded as long as it has.
I like to think of it in the same way that fancy labels like "fair trade" and "organic" make it onto coffee packaging. Coffee growers with money buy the labels so that it is easier to sell to soccer moms who think they're doing good when in reality, they're giving money to people who already have it.
Signed SSL certificates are a fancy (albeit invisible) label that gets slapped onto your encryption so that a silly warning message that doesn't mean much won't appear in the web browser of a soccer mom. She sees the little "lock" icon, doesn't get a confusing certificate warning message, and is happy to make her purchase on the scams-r-us website because, "Golly-gee! It's $800 less on THIS website!"
Granted I only have a fundamental understanding of signed certificates (this is me admitting that my understanding might be flawed), but unsigned, unique private/public keys are just that, unique. Not any more or any less difficult to crack given the equivalent level of signed keys.
I guess the point I'm trying to make is that (tying my thoughts back to the topic) I can't give a damn. I'm going to have to buy the certificate to appease buyers anyway, so debating the future is moot and I might as well put up with whatever changes they decide to make in the future.
SSL is useful for defense in depth, but should not be used as a catch-all.
What *should* happen is that a minimum level of certificate should be available, and cheap, that allows secure connections to and from a particular site. A medium level of certificate should be available for e-commerce, and cheap enough for mom-and-pop e-commerce, and should require that all information necessary to identify and report fraud or theft be displayed--even if in small writing--together with a link to reporting instructions on a government website. A high level of certificate should further require the electronic signature of the seller's bank and of the insurance company, at which a seller should be required to maintain a dollar amount of insurance to cover damage to the purchaser due to shoddy seller security or fraud.
Banks which routinely allow fraud use should have their access to the monetary system revoked.
In addition, any company that claims your transaction is secure because of SSL should have their SSL certificate revoked by the certifying organization. SSL makes the connection more secure; it does not make your credit card transaction necessarily safe--but the latter impression is what millions of e-commerce sellers effectively claim.
-- IANAL, this isn't legal advice, and definitely isn't legal advice for you. Also, Squee!
Allow a single site to have either multiple certificates or multiple signatures from different providers. This means that important sites could be signed by e.g. both Verisign and Globalsign, so it would be possible for users to remove trust of a provider without losing the TLS protection. Without this, there will never be a free market for certificates and browser makers will have to include root certificates from even the least trustable providers, so it simply HAS to happen. Fortunately it is relatively easy to implement.
For extra points, implement support for off-site certificate stores so third parties can attest to the validity of a particular key. Groups of users could collaborate to verify the certificates of sites, which could create a level of protection against fraudulent certificates from the primary providers. This proposal is much harder to implement securely.
Finally! A year of moderation! Ready for 2019?
These are oganizations that we already deal with and are in the business of establishing our identities and securing transactions.
When you're paying money on-line, you (or your browser) should sign the payment authorization using your own bank account's private key (provided for free with your account) and the encrypted with the public key for the destination account. The recipient will submit the signed authorization to his bank for payment.
For SSL protection of your web site, the government should issue SSL certificates as a free option whenever they are confirming your identity anyway. For people the obvious touch-points are when you get a social security card, driver's license, passport, or birth certificate. For companies, the certificate should be part of your company registration.
It is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail. - Abraham Maslow
Of course not. Internal SSL certificates should be what they are, internal. Manage your own CA with WS2K8's CA role or with openssl, and distribute your certificates internally. You do not want hackers to get their hands on a certificate that can be used to breach multiple internal networks that will trust other CAs.
The capitalist approach : create a system of identity bonds, similar to performance bonds.
Link a bond to a cert or set of certs. Create a cryptographic methodology (easy) to ensure the bonds are in force (through typical issuers).
If the identity of the party is disproven, the bond and linked certs are nullified, and the discoverer is paid.
The greater the bond, the more assurance you have that the identity is real. E.g. MSFT might have a $10M bond, whereas a spammer might have a $10,000 bond.
Etc.
A recent evaluation showed that 80% of sites with certificates did not have them set up properly anyway.
As someone else already pointed out, browsers by default do not even warn you if a site's cert is invalid. Why? Because so many sites had invalid certs that people became intolerably annoyed at the constant warnings and just shut them off anyway.
That same study concluded that there are too many Certificate Authorities today, and they do an inadequate job of validating their customers before issuing certificates. Some CAs issued multiple certs to the same party, others actually issued the same certs to multiple parties! (Definitely a no-no.)
It's a broken system. Not because of bad design, necessarily, but because of the failures of people who administer it.
The barrier to entry for a cert authority to be recognized by browsers is too high, as a consequence the price for certificates is too high - it is based on near-monopoly conditions.
Hypothetically, I'd tell them to stop worrying about SSL and get busy rolling out IPv6 where this problem (and several other pressing issues) are solved. But that's because I have an engineering mindset, not a committee one. The answer to "Is this technology out of date or poorly implimented?" is universally yes in my world. Nobody gets it right, and it's a bloody miracle the internet continues to work in spite of its own massive structural deficits.
#fuckbeta #iamslashdot #dicemustdie
Domain Validation (DV) certs are not the same as OV, Organizational Validation, or EV, Extended Validation, certs. Web SSL certs are OV or EV. DV certs are intended to validate that the FQDN is valid (i.e. correctly owned by the domain). This is the job that DNSsec is meant to address in many ways. There's already been public discussion on some of the crypto forums such as mozilla-crypto (ok, for some value of "public" - but it's not a closed list). The DNSsec crowd have asked about putting certificate signatures in DNSsec and the entrenched CA crowd got all up and in arms and huffy about it. But DV certs would just tie the certs to the domain owners, and that's all, which is exactly what can be done in DNSsec. And, yes, we all know, the domain could be faked but that's not the point. The point is to tie a certificate back to the domain owner or not. The OV/EV certs are what validate the organization claiming to own the domain/FQDN. The CA crowd doesn't like the fact that DNSsec can do for free what they can charge money for. DNSsec puts the power totally in the hands of the domain owners (where it bloody well belongs). Now if we could just get certain bloody registrars, like Network Solutions, to let us register our key signing keys, we could get on with things. The root zone (.) is signed. The .org, .net, .com, .edu, and .gov zones are all signed and numerous other ccTLDs are signed. Godaddy and others are reported to be accepting DNSsec registrations. Where is Network Solutions? A sleep at the switch last I looked. And OpenDNS continues to pout, whining "I donwanna... Use DNS Curve or I'm gonna cry." DV certs are a solution in search of a problem and DNSsec is a better solution.
The CA/Browser forum (which is dominated by certificate authorities) is proposing to make changes in the way EV certificates are issued. The changes weaken EV certs.
Existing EV cert policy is that EV certs MUST contain the organization name, its business name and address, and its jurisdiction of incorporation. In the proposed draft, (p. 13) "Organization name is OPTIONAL".
This essentially makes EV certificates meaningless. The whole point of an EV certificate is to unambiguously identify the business owning the certificate. So if you need to sue, file criminal charges, or send in a collection agency, you know where to send the process server, cops, or collection agents.
(At SiteTruth, our system considers SSL certificates without a business name and address to have no value in establishing the legitimacy of a company. We've always done this for "domain controlled only" certs, and will now do it for EV certs missing a business name or address.)
I am under the impression that these certificates are supposed to verify the authenticity of the host that you're connected to. Yet when I asked a major bank who issued their certificate, never mind to verify the authenticity of the certificate itself, they didn't have a clue what I was talking about. In that case, what's the point of them? I am still subject to man-in-the-middle attacks after all.
I've been using the following to help me validate certificates:
http://perspectives-project.org/
They have a bunch of systems that monitor SSL certs for changes. They call them "notaries". You can run a notary, too.
It helps to make sure the cert you're seeing is what everyone else is seeing and no one is doing a man-in-the-middle attack on you.
A certification authority should be assigned inside of a domain's DNS to a particular IP or range of IPs for redundancy. Those certification servers can either be internally controlled by the owner of the domain or handled by a trusted third party like the current CA providers.
When a client validates a certificate, it would double check the certificate received came from a trusted source listed on the DNS cache on the local computer and then remotely on a trusted source provided by the client maker, a set of standard trusts (like the current major certificate authorities) or custom sources setup by the client's user (for private local domains and such).
The client can then check the certificate against one of the other certification servers listed on the DNS (can require two IPs like most name servers) for validation. If the certificate isn't listed with any of the CA peers, the CA peers don't recognize the certificate's CA or if the DNS information between the two checks are different, the certificate would be considered invalid.
NetSol is Verisign, which is a CA. Of course they aren't excited about DV-equivalents...
SSL certainly does matter when you want to perform a secure transaction with confidence. It should remain optional though. There are enough loops and hoops to jump through to create a reliable domain from which you can send email. SSL would, if mandated, become a problem for millions of current domain admins, especially if you have to pay for a complete version, and it's a commodity product. Quite expensive for people who do not have a commercially focused domain. I think a healthy ptr record in your DNS should be sufficient for most intents and purposes....and the use of SSL has far surpassed the need for it. So it's important in some instances, but not required in most. You shouldn't have to have it to run an email server, but it's a good option if you'd like an added level of security.
We do need a class of certificate that simply verifies that we're talking to the host we expect to be talking to (ie. that the name of the host using the certificate matches the name of the host in the URL). That's sufficient for encryption-only purposes, where I'm using SSL not to validate the remote end's identity in any way but merely to prevent eavesdropping on the data stream by third parties. DNSSec addresses some of that, but it doesn't provide the encryption layer that SSL does.
Bluntly put, there's a lot of cases where I don't care about the absolute, real-world identity of the entity I'm talking to, only that I'm talking to the same entity every time. Think the Dread Pirate Roberts.
1) Stop selling the idea that certificates "verify" who you're talking to. They don't. They never did. As soon as I compromise your server -- easily done, as history shows -- I have your certificate. If it is remote across your network, a little more work, but still, soon I'll have it. Now you have still encryption of the intermediate channel, but the wrong person is catching the data.
2) Tell the truth for once, and let people know that certificates provide encryption of the intermediate channel, hardening ONLY that channel against interception (but NOT proofing it.) ID is NOT provided, only an invalid assumption of ID built out of the lies of Verisign and its co-scammers.
3) Stop "allowing" certificates at all. We can easily make them at zero cost, and we should. The whole "Verisign" thing is a complete and utter scam, and always has been, one with the collusion of the browser makers with the fake warnings and "scare the user" policies. Giving ownership of the encrypted data channel to profit making operations was a stupid, stupid move, and has served only to cripple e-commerce from the day it began -- it's one more useless and endless cost for the small entrepreneur to have to absorb, and therefore in the end, the consumer. Further, it has evolved into a higher stakes / cost game of buying that little green verification bar in some browsers. Scams upon scams.
Doesn't matter how "smart" the people are working on this. They'll go with the money.
I've fallen off your lawn, and I can't get up.
Make it illegal to ship a browser that accepts improperly configured sites, and remove CA's from the market if they are found to have deliberately issued certs who's purpose is intercepts. "Honest mistakes" are tolerable but cert's with 100+ SAN's ?.
Make it illegal to intercept/proxy SSL - even in the corporate world - block is fine, intercept is not.
You'd be amazed how many corp's quietly intercept and inspect SSL traffic.
Fixing the browser fixes 90% of the site problems, if customers can't connect they'll fix the problems or go away.
For my private webmail that only I use (read: general purpose internal use thingies), a self signed - and expired - certificate is as good as one signed by some incompetent CA. And much cheaper. :)
It has been sufficiently demonstrated that the current certificate authorities aren't worthy of much trust. Just like the USPTO
I apologize for the lack of a signature.
Won't work, as long as spammers and scammers can cheaply create phony entities in the web of trust.
Can you think of a practical attack against, say, the trust metric used on Advogato.org?
One of my pet peeves with SSL is the ominous warnings that are presented when the certificate is not signed by a "trusted party".
First of all, I think it is useful to have encryption, even if you don't verify the identities of the endpoints.
Secondly, there are often more ominous warnings for SSL-without-verification than for cleartext communication. This seems backwards to me.
Thirdly, if you look at the trusted parties, there is often a list which includes many organizations most users have never heard of, let alone really have a basis to trust. Some trusted parties actually have rather troubled histories.
I think it is good to think about how to make our communications more secure. Particularly, users often expect their communications to be private; only known to themselves and the intended recipient. I think we should work to make protocols actually behave that way, and SSL could be a part of this. Which means we need to critically evaluate SSL, too.
Please correct me if I got my facts wrong.
Maybe except for the part where site owners have to pay a fee for the privilege of encrypting their users' communications with them, which is a barrier that means a lot of web site owners, in particular people who aren't running their sites for a living, just won't bother.
Even if add-ons like Perspectives make use of self-signed certificates practical, there's also the problem that Internet Explorer on Windows XP and Android Browser on Android 2.x don't support more than one server certificate per IP address. This lack of SNI means each domain needs its own IP address, and now that all /8s have been allocated, such hosting is substantially more expensive than bargain basement name-based virtual hosting.
Perspectives fails if the server's only connection to the Internet backbone is through a MITM. In this situation, all notaries would see the same MITM'd certificate. It also fails if you're trying to host more than one unrelated HTTPS site on port 443 of the same IP address, as the server won't know which hostname's certificate to present to clients running SNI-less browsers (Internet Explorer on Windows XP or Android Browser on Android 2.x).
What I care about is that that's the same entity I successfully did business with before
So when you do business for the first time with a given entity, whom do you trust?
It was a solution to two separate problems:
Secure the communication and ensure the identity.
It works for securing the communication, we need a better solution for ensuring identity.
Note: If I had the answer, I wouldn't be "here"...
BREACH OF TRUST - Find out why you can’t trust your web browser or certificate authorities.. Covered in Slashdot - Become an SSLAdmin In a Few Easy Steps.
Certificates are good for encryption. That's it. With the insane amount of "trusted CAs"
that come pre-trusted with every browser nowadays, that's all that is possible.
Hoping to achieve anything beyond that is naive.
From a very insightful talk about the topic:
SSL certificates provide honesty-box security
Use a $495 Verisign certificate
– People will come to your site
Use a $9.95 budget CA certificate
– People will come to your site
Use a $0 self-signed certificate
– People will come to your site
Use an expired or invalid certificate
– People will come to your site
Use no certificate at all, just a disclaimer saying that you’re secure
– People will come to your site
[Use DNSSEC and CAs in parallel] until such time as there are so few non-DNSSEC supporting clients that you can do away with the CAs.
There are a lot of things that I'm waiting for "until such time as", but I don't foresee "such time" happening within one investment horizon.
You can even put a scary message on web pages for non-DNSSEC supporting clients [...] pointing them to a place where they can update their software to support DNSSEC.
They won't follow that link; they'll just visit the site's competitor. This is true especially in cases where no update to support DNSSEC is available at all for a given platform.
What *should* happen is that a minimum level of certificate should be available, and cheap, that allows secure connections to and from a particular site.
Such a certificate is already available. It's called "Go Daddy Standard SSL with a promo code". The problem here is web browsers that don't support more than one distinct certificate on port 443 of a single IP address. These non-SNI-savvy clients include Internet Explorer on Windows XP and Android Browser on Android phones and pre-Honeycomb tablets.
should require that all information necessary to identify and report fraud or theft be displayed
The SiteTruth search engine already requires that businesses display their street address.
Perhaps some other entity that has a good track record for correctly identifying others.
I have a name for such an entity: a "certificate authority".
Not some company I've never heard of before in a country I know little about.
Then your problem is with browsers accepting certificates from too many CAs and providing no way to restrict which countries' businesses a given CA is allowed to certify. For example, a CNNIC cert on a business serving the U.S. market should raise a red flag.
A lot of deployed clients don't support SNI, which means they support only one certificate per (address, port) pair. This means only one SSL site can run on port 443 of a given IP address. And with hosting providers such as Go Daddy using name-based virtual hosting to pack up to 1,000 different web sites onto a single IPv4 address, SSL on all sites becomes impractical. But the larger AAAAddress space of IPv6 lets hosting providers go back to address-based virtual hosting.
Also IPsec.
NetSol is Verisign, which is a CA.
VeriSign sold its registrar business (NetSol) to Pivotal Equity in 2003 and its CA business to Symantec in 2010. It's down to running two root servers and acting as the back-end registry for .com, .net, .name, .cc, and .tv.
Because it doesn't require waiting for clients to support DNSSEC.
1) Yes certificates can validate your identity, provided the roots and intermediates are kept secure. You should never be issuing client certs from the local server cert, which many people do. Only an idiot keeps the root cert on an online server . Smartcards can provide security for the end user's private certs. It all boils down to a secure implementation. The flaws you describe result from an insecure implementation.
2) Yes, encryption is one use of SSL. The question was about SSL validation.
3) Again, we're talking about crappy implementation here - aka Verisign and other CAs that give out certs like candy and don't bother to verify identity properly. It also doesn't help that browsers and OSs are setup to trust less than reputable CAs (ie Firefox trusting certain Chinese CAs).
As I see it, notaries acting as short-term CAs to proxy DNSSEC would have to prove themselves to the browser makers just as any other CA would. Such an audit costs a substantial chunk of change; how is such a notary supposed to afford it? And how is such a notary supposed to afford servers, bandwidth, etc. to stay in operation? With a lot of sites using a notary and signing a new certificate every hour, I imagine that'd be a lot of CPU and bandwidth. Web site operators would end up paying for the notary service just as one currently pays a CA for a domain-validated certificate.
A handful of people between nearby cities can extend the range of the web of trust.
As I understand the web of trust, a path from one party to another with more edges provides a weaker assurance than a path with fewer edges. A longer path increases the chance that a confused node is in the path. Thus, having to go through a couple dozen nodes to reach the other party dilutes the trust. And if only a tiny subset of people travel, these people will be bottlenecks in the trust graph.
Eventually, the web could spread between all cities, just by spreading between people at nearby cities.
Not between continents.*
the problem is getting everyone involved, not just crypto geeks.
But who has suggested a solution?
* Europe and Asia are one continent for this purpose.
You can get free SSL certs
StartSSL certificates are valid only for individuals, not businesses. For an individual's web site run as a hobby, the price of a domain-validated cert isn't a barrier as much as the price of hosting that includes a dedicated IP address. A lot of clients still lack SNI, which means they can't see more than one unique certificate on port 443 of a given IP address, and that isn't very compatible with shared hosting providers' common practice of putting upwards of a thousand different domains on a single IPv4 address.
from startssl
I thought StartSSL had shut down. When did it resume services? Google startssl resume only gives stories about the initial suspension, not the resumption.
1) Stop selling the idea that certificates "verify" who you're talking to. They don't. They never did. As soon as I compromise your server -- easily done, as history shows -- I have your certificate. If it is remote across your network, a little more work, but still, soon I'll have it. Now you have still encryption of the intermediate channel, but the wrong person is catching the data.
... and certificates don't cure AIDS either. But that's not what they're supposed to be used for.
Certificates are meant to secure the communication channel, in order to make sure no unauthorized third party taps in the middle. If the end points are compromised (server or client workstation), all bets are off.
That's why organization that care (such as some banks) make damn sure that their servers are secure, and cannot be compromised. A bank however has no jurisdiction on the path from its customers to its servers, so it cannot make sure that no router at an ISP or Wifi access point at a coffee shop is compromised. That's where SSL and certificates come in: making sure that the communication is secure, even if some nodes on the route are compromised. However, it doesn't protect against compromise of end points, and never was meant to.
3) Stop "allowing" certificates at all. We can easily make them at zero cost, and we should. The whole "Verisign" thing is a complete and utter scam, and always has been, one with the collusion of the browser makers with the fake warnings and "scare the user" policies. Giving ownership of the encrypted data channel to profit making operations was a stupid, stupid move, and has served only to cripple e-commerce from the day it began -- it's one more useless and endless cost for the small entrepreneur to have to absorb, and therefore in the end, the consumer.
You can get cheap certificates at startssl.com . Basic one-site certificates (no wildcard, no subject alt names) are free, anything more fancy costs 59.90$ per identified user (but unlimited number of certificates... great for hobby hosting operators!)
Further, it has evolved into a higher stakes / cost game of buying that little green verification bar in some browsers. Scams upon scams.
... and even that, you can get from startssl.com (if you feel you need it), but it's more expensive.
To people who understand the technology it doesn't matter but who has end users like that?
A big improvement would be to require e-commerce servers to protect their private key in a hardware accelerator that won't give up the key. This would protect the certificate if the server is compromised. Someone might be able to use the accelerator, via some type of proxy hack, but the certificate would be safe after a compromised server is reloaded.
Maybe the "scam" factor could be reduced if the certificates were signed by two or more entities in different jurisdctions.
There is a model of how to have an encrypted system replace its clear-text equivalent. SSH.
Math nerds are just making everything too complicated. Yes, there may be some technical perfection which we can strive for, in version 3.0 Version 1 is just totally fucked, it is both unsuccessful at being perfect, both technically and politically, and is just too fucking hard. Make 2.0 work, and work everywhere. When faced with a technical question, see what SSH does.
http://ask.slashdot.org/story/11/08/06/1841210/Ask-Slashdot-Does-SSL-Validation-Matter#We can solve 90% of the problem basically overnight, and put those bloodsucking extortionists out of business. Do what SSH does.
I don't think third party verification is stupid, though verisign etc charge way too much, it should be under $10/year... I use StartCom's free SSL for a couple domains, the only annoyance is annual expiration, which is tolerable. I think the excessive warnings are over the top... having it tell you with an okay/cancel dialog the first time you connect that the cert is self issued, then warn if it changes more than a month before expiration (in case of MITM attack (open hotspot yassiger pineapple type devices).
Also, one cert per IP is a pain with IPv4 and shared hosting, but IPv6 will resolve that issue. (eventually).
Michael J. Ryan - tracker1.info
The required X.509 certificates are simply a requirement of SSL and TLS. there is nothing requiring you to use SSL/TLS to secure an HTTP data channel or other channel other than it is the technology embedded in just about every browser on the planet. The purpose of validating certificates is for a 3rd party (e.g. Verisign or some other entity) to vouch that the certificate you have received chains up to the the trust root at Verisign and they vouch that they signed it - mathematically. Since your browser trusts Verisign automagically due to the Verisign trust authority added to your browser trust cache, you then accept that the certificate receive from XYZ.com was at least created by Verisign if the XYZ.com certificate chains and hasn't been revoke or expired. In theory this is suppose to validate that XYZ.com is the the correct XYZ.com. To make this happen the XYZ.com domain name is embedded in the X.509 certificate which was then signed by Versign. Is this a perfect system? Absolutely not. In fact your browser by default trusts too many authorities at this point. Just take a look at how many Firefox trusts out of the box. If you simply wanted to create a secure tunnel between two end points then X.509 certificates are simply unnecessary. IPSec and SSH are a point-to-point secure channel protocols that do not require certificates but you can use them to make key management easier. You can also simply make up your own should you desire. This isn't magic. The problem is that when you want others to talk to your new protocol they won't be able to.
Security discussions often end up lacking the details needed for real progress. People who know better rarely seem to be involved from what I've seen. Knowledgeable need to speak up and educate the policy makers.
SSL is just fine for communication; identity it is as only as good as the signers -- which are not so good and just in it for the easy money. Browsers make money from being in the con game which also causes progress to be slowed. The best identity solution I have seen so far leverages the existing tech and is a Firefox add-on already: http://perspectives-project.org/
Me, I've been bugging my state officials (you should too) that we need the government involved as a signing authority. Not because its flawless (I bet it out performs the private signers easily) but because every BUSINESS already must register their corporation (LLC too) and they should get more than just a TAX ID and some paper. They should get a signed cert. This can be be used for multiple things not just SSL certs which support multiple signers. At least then one can see that a gov has recognized their corp in addition to whatever other signers are involved.
All the above uses existing tech. If you want to get into identity and encryption for the next generation, then I would suggest decoupling different forms of security not only in discussions but also in the implementations. Nothing says that one can't have an identity system verify the keys used for any form encryption-- the two do not need to be combined as if they were addressing the same problem..
Democracy Now! - uncensored, anti-establishment news
For better or worse, the idea that https is a means of verifying who you are talking to has been hammered into people's head.
That's something that's going to be really really hard to change.
So this is what I would like to see:
1. EV certificate to be strengthened. Not only should they be hard to get, they should also require the servers that they are used on to be audited externally every year. There should also be automated testing done daily, which would include any newly discovered vulnerability. I believe that EV needs to remain for banks, virtual currencies system, trading platform and so on. They shouldn't even be made available to SMBs like they are now. Maybe it should even include a whitelist only list of IPs for a particular certificate. Browsers would have to query the list to ensure that it is a valid IP for the certificate.
2. Include a "Validated" tier, this is somewhere in between EV and domain only. Site seals should go there. Information about what has been validated should be included.
3. Yes, keep the domain only certificate. People need encryption for a variety of purposes on their website and these should be available for 20$ or less per year.
As for non unique global names, like exchange servers, ditch them. It's not that hard to have a full domain name for them and use an SSL for that. If they are really needed, make sure that the certificate require that the connection is on a private IP address.
The only mailing lists that matter in terms of making decisions on internet infrastructure are the publicly viewable ones over at the IETF, like those of the Transport Layer Security working group. The poster could be complaining about a group of script kiddies with their own mailing list in Nebraska for all we know.
Which you cannot guarantee, therefore you cannot use them to validate identity.
The entire industry -- from scamming fees out of site owners to fooling the consumer and coercing and co-opting the browser authors -- is predicated upon the single critical idea that certs imbue a transaction with safety because you know who you're talking to. But the fact is, you don't have any idea who you're talking to; and furthermore, you cannot, and furtherestmore, the cert couldn't tell the user or the browser or the source site if the folks at both ends were the "right ones" even if it was true. All the cert does is implement intermediate communications line security -- as far as we know, presuming the NSA hasn't done what we all know it would most like to do and is either in the process of doing or has already done.
If there were such a thing as a "secure implementation" (which there isn't -- you have no idea where the hack will come from... a business associate? The cert authority? A lover? An intrusion? Use of force? Installation error? Stray gamma ray? Bad chip? Browser vulnerability? Language vulnerability? Worm? Virus? Some combination of the foregoing? Or etc., ad infinitum), certificates still wouldn't assure you it was in place. Claiming that they in any way validate identity is purest scamming.
No. The fact is that as far as we outside the government know, the SSL mechanism presently legitimately encrypts between points, IE the intermediate channel. The next fact is that certificates cannot, period, end of story, provide validation, nor have they ever done so. It's a scam to say that they do if you understand them; if you don't understand them -- and by that, I don't mean just the mechanism, I mean the environment they exist in and are expected to function in and the ways and means people are known to go to to get around such efforts, and the immense benefits available from doing so when they are circumvented -- then you're simply ill-informed and wrong.
Again, we are not. We are talking about the impossibility of implementation, in response to the bogus claim that identification and authentication are possible with the certificate mechanism. Which Verisign (used here as a placeholder for every CA) knows, and is why Verisign and etc don't seriously try to do it. They know perfectly well it's a scam. If they give you something to point at, like the hilarious methods they claim provide your identity (never mind the site's identity), then you'll be misled into trying to address the wrong issue. The actual issue is that this is a scam and cannot work at all, not just that the CAs have no serious knowledge who the certificate holders really are. It's not about identification and authentication. It's about the illusion of identification and authentication. All they have to do is put up a solid enough false front to make it look like they're trying, then misdirect the tech types into tech issues instead of thinking about how the whole system works, and they're golden.
I've fallen off your lawn, and I can't get up.
I don't see how that would drive traffic to competitors.
If a site offers only a DNSSEC cert and not a domain-validated CA cert, people without the plug-in who click through to check out will get a self-signed certificate warning and think the business isn't reputable. Or people will get redirected to a page about a web browser that supports DNSSEC certs but then discover that they don't have administrative privileges to install such a browser.
For example, try installing the latest version of Firefox while you have an out of date Flash player
Or try visiting a site with an SWF object on an iPad: it redirects to a page on Adobe.com saying Apple won't let Adobe make a Flash Player for iOS.
DNSSEC doesn't strictly require platform support.
It does if your platform only has one browser that's been digitally signed to run on it. Such platforms include game consoles, iOS devices, and Windows Phone 7 devices.
Someone could pretty easily create a DNSSEC resolver as a browser plugin similar to this one
Just installed it. Thanks for the link.
for any given browser.
That is, for any given browser with a suitable plug-in architecture and someone who cares enough to maintain such a plug-in. I doubt that browsers on devices made by Apple's iDevice division, Sony Computer Entertainment, Nintendo, or Windows Phone 7 licensees have such a suitable plug-in architecture.
Some background:
http://www.digicert.com/dv-ssl-certificate.htm
(No, I don't work for digicert)
The DV certs are those cheap http://www.nlnetlabs.nl/publications/dnssec_howto/#x1-290003.4 The administrator of the zone file can sign the zone.
"We do need a class of certificate that simply verifies that we're talking to the host we expect to be talking to "
See Bruce Schneier's Practical Cryptography for digital ID's.
"The browsers by default won't warn you if say your US bank's server cert is one day signed by CNNIC (China) while you're in China. Or vice versa." If you don't trust one of the Root CA's, delete it from your browser's certificate store. I do.
I just got back from Defcon 19 and Moxie had a talk on the future of SSL. He discussed a project he was working on called Convergence that for now is just a firefox plugin but what it does is rather than communicate with a certificate authority such as Comodo or Verisign it communicates with a notary instead. You can decide which notaries to trust on the fly. No more self signed SSL warnings, no more trusting Comodo when they get hacked. Exciting stuff! So to answer the question does SSL validation matter? If it did, it won't for long. Check out www.convergence.io and see for yourself, I've been using it since I got home from Defcon.
There is already support for arbitrarily long certificate chains, and if all the CAs cooperated they could just sign an existing certificate chain with their own intermediate CA, the web site could tack that newest signature (along with any other necessary certificates in the chain) onto its existing chain and to an old SSL client it would just look like the newest CA was the ultimate source of trust, but the new version of SSL clients could verify that the web site's certificate has actually been signed by more than one locally trusted CA.
This particular workaround would probably not be the best solution; as far as I know it would require each root CA to sign every other company's root certificates as intermediate authorities. Perhaps by using a new set of root certificates that aren't trusted by old browsers it wouldn't be as big of a problem because only the top-level signer would use their traditional root CA key. New browsers would know about the new multi-chain root certificates and identify each of them in the chain. In the end, it would probably be better to just extend the TLS specification to send multiple certificate chains if the client requests them.
In short, we need a web of trust for X.509 certificates. PGP was right all along.
No one puts the signing certificates online (doing so gets it pulled from browsers pretty quickly and requires a $100,000 audit to be re-added), so with the existing system the certificate will be revoked immediately after someone has noticed the compromise. This means that your plan, while costing more, would do nothing to reduce the size of the attack window.
I am TheRaven on Soylent News
All of the arguments against center around the problems associated with Verisign and browsers as if SSL had no other use.
That is plainly false.
Certificates are frequently used to ensure that there is no man-in-the-middle attack when a specific software package is installed on both client and server and both installations come with the certificates. In this instance, certificate verification provides a lot of meaning and assurance about the connection between the client and host.
Certificate revocation doesn't work, though. An attacker capable of doing a man-in-the-middle attack on unencrypted data can quite easily stop browsers from finding out the certificate's been revoked, and the last browser to attempt to detect this attack (Chrome) gave up long ago because it couldn't distinguish it from the annoyingly frequent actual failures of SSL certificate authorities to answer requests for revocation information.
1) Stop selling the idea that certificates "verify" who you're talking to. They don't. They never did. As soon as I compromise your server -- easily done, as history shows -- I have your certificate. If it is remote across your network, a little more work, but still, soon I'll have it. Now you have still encryption of the intermediate channel, but the wrong person is catching the data.
2) Tell the truth for once, and let people know that certificates provide encryption of the intermediate channel, hardening ONLY that channel against interception (but NOT proofing it.) ID is NOT provided, only an invalid assumption of ID built out of the lies of Verisign and its co-scammers.
3) Stop "allowing" certificates at all. We can easily make them at zero cost, and we should. The whole "Verisign" thing is a complete and utter scam, and always has been, one with the collusion of the browser makers with the fake warnings and "scare the user" policies. Giving ownership of the encrypted data channel to profit making operations was a stupid, stupid move, and has served only to cripple e-commerce from the day it began -- it's one more useless and endless cost for the small entrepreneur to have to absorb, and therefore in the end, the consumer. Further, it has evolved into a higher stakes / cost game of buying that little green verification bar in some browsers. Scams upon scams.
Doesn't matter how "smart" the people are working on this. They'll go with the money.
I totally agree. I have a private network (connected to the internet) and have my own validation certificates but firstly, before creating these certificates and believing that a "trusted" certificate from Verisign was better, I checked with Verisign only to find that the cheapest (for email) was over $1,500 while a general certificate was over $2,500. Why the hell would I spend this kind of money when all I want is for my family overseas to be able to connect to my server to download photos and other family files to their own computers? Crazy, crazy, crazy!!!
How do you propose hardening a communication channel against man-in-the-middle attacks? It was only through Firefox's certificate management that I became aware that my company was engaging in man-in-the-middle attacks on my banking sessions. I want to be alerted to those sorts of things.
Unless I store my certificate unencrypted, which is as stupid as storing a list of passwords unencrypted, gaining access to my server doesn't get you access to my certificate.
1) Yes certificates can validate your identity, provided the roots and intermediates are kept secure.
Which you cannot guarantee, therefore you cannot use them to validate identity.
The entire industry -- from scamming fees out of site owners to fooling the consumer and coercing and co-opting the browser authors -- is predicated upon the single critical idea that certs imbue a transaction with safety because you know who you're talking to. But the fact is, you don't have any idea who you're talking to; and furthermore, you cannot, and furtherestmore, the cert couldn't tell the user or the browser or the source site if the folks at both ends were the "right ones" even if it was true. All the cert does is implement intermediate communications line security -- as far as we know, presuming the NSA hasn't done what we all know it would most like to do and is either in the process of doing or has already done.
.
Paranoid much? Your arguments have not pointed out any fundamental technical problems with using SSL to verify the server-side. It all boils down to the commercial CAs and browser makers failing to hold up their part of the web of trust. They issue certs without verifying who is applying and browser are apt to include the public certs for CAs you might want to trust.
Have you even looked a the private and DOD implementations? Nearly 1 million CAC smartcards issued using PKI certificates? Those are examples where the implementation is done according to best practice and works just fine to authenticate servers and users.
Despite the shenanigans of the commercial CAs, SSL validation does have one benefit still - when your browser says the site has been hijacked, there usually is a problem though usually not malicious. Granted most people ignore the warning and continue anyway (I don't think the browser should let you, btw) but that problem will exist even with dnssec.
So given all your negativity, what do you propose for a solution?
SSH does a nicer job on placing validation in the eye of the beholder.
Key exchange is open and visible, and one time with fingerprints.
The hard exchange of asymmetric certificates then symmetric for session traffic is the same.
The SSL method of doing it for you and presenting colored tiles is odd, and the infinitely varying psychological games from browser version to browser version to attempt and scare people into paying attention is ridiculous.. if not debilitating. Worst of all is the IESC whatever Microsoft went berserk with.. its the first thing anyone who has to use IE disables.. its almost the anti-EULA.. you must agree to disable all security to prove abdication of Microsoft responsiblity for security. The OCSP.. wow is that nuts.. its the same "thought process".. we goofed and signed for a bunch of popular domains so our service is no longer trustworthy.. "disable [here]" to release us from all responsibility for our mistake.. never mind that your browser will take 30 seconds per domain included per page.. the average being 8 per page.
DNSSEC looks a little better in that certain domains are held to a higher standard for validation.
I think however it would be better to validate a path per session, perform a traceroute and do certificate validation for the entire path before traffic begins. The anonymous path is the real problem. Or make it an option when initating certain connections.. like with your bank.. document the trail.
For almost 2 decades, making certificates that browsers would accept prohibitively expensive for most has ensured that the largest part of Internet traffic is still transmitted unencrypted (or susceptible to eavesdropping). Proponents of crypto bans and Clipper chips probably wouldn't call that "stupid" at all, but rather revel in getting their way for so long even without implementing any of these measures.
Up 20% recently BTW, and still requiring intermediate certificates that are a hassle to install particularly in Plesk.
There seems to be no good reason why a certificate for wildcard (or simply more than one) subdomains should require more thorough validation (and hence much higher cost) than for the second level domain itself though.
The fundamental technical problem is that the SSL certificate cannot prove that the server has not been compromised, and is therefore not truly proving the identity of the server, but merely proving that the server has a copy of the private key registered for the domain. This basically makes the identity aspect of the cert no more valuable than a self-signed cert or bare public key stored in the DNS record, assuming that DNS is sufficiently secure.
Let's step forward a couple of years into a world where every root is signed with DNSSEC. You have a verifiable path for determining that a domain record was not altered in transit, and that domain record could trivially contain a public key record. Therefore, the only way someone could compromise it is by actually hijacking control of the domain at the registrar level.
Now, if you can hijack control of the domain at the registrar level, you can also get a domain validation cert.
Congratulations. In the world of DNSSEC, non-EV certs are completely and utterly vestigial anachronisms that provide no additional security.
Thus, the only question that remains is whether EV certs provide any real value. Every study I've ever seen on the subject suggests that the answer is no.
Check out my sci-fi/humor trilogy at PatriotsBooks.
For problems in this kind, Perspectives works pretty well, I think. Maybe you think so, too, since you use it in all your Firefoxes?
I agree. But I just like arguing edge cases because if a given solution's edge cases are easy to solve or to minimize, it's easier to make a solid case for adopting the solution.
Yes, for the scenario in which you are accessing a virtual host via HTTPS, and the virtual host wasn't given its own IP address
Correct. Running over a thousand sites on one IPv4 address is the norm for budget shared hosting. Shared hosting providers don't offer SNI, and my best guess is that hosting providers don't want to have to deal with the cost of answering hosting clients' complaints that visitors using IE on XP can't see the HTTPS section.
or the server can't use or doesn't have an X509 v3 subjectAltName certificate
True, a so-called UCC can list several hostnames as subjectAltName entries. For example, a single certificate could cover hobbyclublocator.com, www.hobbyclublocator.com, hclubl.com, and www.hclubl.com, because they're all the same site. But I've read that it's poor practice to list several unrelated web sites as subjectAltName entries on one certificate. So if hobbyclublocator.com, philshobbyshop.com, tiltandgo.com, and 5dsoftware.com are not the same site, they shouldn't have the same private key.
And I wouldn't say Perspectives "fails" in those scenarios. More precisely, it cannot work for those scenarios.
I treat "fails" as including "cannot work". If a public key distribution mechanism "cannot work" to reassure customers that their passwords, session tokens, and credit card numbers won't get eavesdropped, then it "fails" to give customers enough confidence to shop there, and it "fails" to convert visitors to orders. Both a false negative and a false positive are different forms of "failure".
I think that SSL validation should be farmed out to the respective governments according to their country TLDs, and that SSL should be removed altogether from TLDs that are not postfixed by a country TLD. From that point the country can contract out to various organizations to take care of the validation process.
This is because an organization can only be validated or invalidated through their respective country's government, usually through the same means that the country uses to tax and regulate them. This means more control in the governments hands, but it also places more control in the users hands, as they can choose not to trust an entire government by removing their signing certificate from the computer's trusted certificate chain. And it would mean organizations cannot bypass due process and register a domain or certificate from another country in order to take advantage of lax laws. An added bonus, the government can fine a CA for improper handling of certificates, as it would fall directly under their jurisdiction, failing to do so meaning that the country tld would be shitlisted by OS vendors and administrators all over the place. Reputation is key.
As the situation stands now, the entire system can be compromised by any CA that does not do proper checking when issuing out certs, or any key that is compromised.
Starbucks, Harbuckle of Breath.
DNSSEC-based domain validation is an exciting possibility. But I've heard concerns over it:
For the time being, we will make just one remark about this. Many people have been touting DNSSEC PKI as a solution to the problem. While DNSSEC could be an improvement, we do not believe it is the right solution to the TLS security problem. One reason is that the DNS hierarchy is not trustworthy. Countries like the UAE and Tunisia control certificate authorities, and have a history of compromising their citizens' computer security. But these countries also control top-level DNS domains, and could control the DNSSEC entries for those ccTLDs. And the emergence of DNS manipulation by the US government also raises many concerns about whether DNSSEC will be reliable in the future.
Could you address those?
One problem with the startssl certificates is that they also provide the option to generate your private key if you like. Clearly, this was a bad move. Now every website that uses a startsll certificate could be one that correctly submitted a CSR and hence the CA doesn't have your private key, or it could equally be one where startcom generated the private key and thus could potentially keep this key and subvert your traffic. You just don't know.
I think it was a very unwise business decision to provide this feature.
Unless of course, I've miss understood and they don't do this, but I think they do.
Another problem is that some large corporations don't include their CA certificates in their proxies and thus sites protected by them do not pass into that corporate. Frankly, based on the decision to auto generate private keys there may be some justification to not trusting those certificates.
Please comment, because I wouldn't want to get this wrong because startcom look like one of the only reasonably priced options out there.
The most important thing that needs to be done is to fix things so that the client can know if the cert has unexpectedly changed.
In its current state, https seems to be mostly concerned with fighting cheap MITM attacks against sites that the user has never visited before. This is stupid. It's FAR more important to prevent moderately-difficult MITM attacks against sites that the user visits on a regular basis. SSH handles this well, but it only works as well as it does because the user can be expected to know when the server's cert is legitimately expected to change -- a practical impossibility with HTTPS. HTTPS doesn't even try: anyone on the (very long and rapidly growing) list of people who can sign certs (that the browser will recognize) can provide a valid new cert at any time, for any site, and the user will never even know that the site's cert has changed. This is very bad.
The solution is for the site, whenever it is visited, to supply the user with information about when the cert is expected to change next, and for the browser to REMEMBER this (with the cert). If the cert changes unexpectedly, alarms go off.
Currently, scary alarms go off mostly when the client computer's date is incorrect -- which happens frequently on older computers, because the coin cell on the motherboard dies. (Current browsers make no attempt whatsoever to verify that it really is 2185 or whatever before presenting the user with the big scary warning about the site's cert being invalid, and the warning doesn't say "either your computer's date, 25 January 2185, is WAY OFF and it's really only 2010 or so, OR ELSE the server's cert is expired.") Even if the date could be verified independently, the current approach assumes that a cert that WAS valid but has been allowed to expire is a great deal riskier than a cert that wasn't expected to change for another eight months and has suddenly been altered for no reason. This is wrong and backward. A cert that changes (more than a few days) before it was to expire is in principle WAY more likely to be nefarious than a cert that was allowed to expire before being replaced, especially if the new cert is signed by a different CA than the one that signed the previous cert.
Cut that out, or I will ship you to Norilsk in a box.
DNSSEC-based domain validation is an exciting possibility. But I've heard concerns over it:
For the time being, we will make just one remark about this. Many people have been touting DNSSEC PKI as a solution to the problem. While DNSSEC could be an improvement, we do not believe it is the right solution to the TLS security problem. One reason is that the DNS hierarchy is not trustworthy. Countries like the UAE and Tunisia control certificate authorities, and have a history of compromising their citizens' computer security. But these countries also control top-level DNS domains, and could control the DNSSEC entries for those ccTLDs. And the emergence of DNS manipulation by the US government also raises many concerns about whether DNSSEC will be reliable in the future.
Could you address those?
Yeah, I'll give it a shot.
First off "the right solution to the TLS security problem" is a problem. "TLS security" is not a single (the) problem but a multifaceted problem. DNSsec addresses (doesn't totally solve - none do - but does address) one of those facets (tying the cert to the domain owner). The fact that a malicious state level actor controls both DNS (and their ccTLD DNSsec signing) and the certificate authorities just leaves you in almost the same spot except I would argue that DNSsec has a leg up there. Not perfect, but better and more verifiable.
Controlling the CA, they can spoof a MITM certificate claiming to be you. Now, you have to validate all your certificates from an outside point of view. Or they issue the certificate and key to you (bad BAD practice done by many CAs for TLS E-Mail certs - they should NEVER have possession of the private key) and you will never be able to tell if they are abusing your cert or not. That's bad. That's real bad.
With DNSsec, you give them your public key signing key (ksk). They either properly sign it and publish it or they don't. You can verify this in the public DNS (plenty of public query servers and looking glasses and historical sites for DNS - aot site certs where you're on you own). You use your private ksk to that public key to sign your zone signing public keys (zsk) and you publish that public key yourself, which you can then also verify. Then you sign your records with the private key of your zone signing key. All of this should be confirmable from the public DNS but, in the case of a malicious state actor, you may still have to confirm it from an outside view (a looking glass or secure remote server) but you only need to verify that THEY properly published YOUR ksk public key and that they are not blocking DNSsec. You never give them your private key (never underestimate the power of what Bruce Schneier calls "rubber hose cryptography" - they beat the bejesus out of you till you give them the bloody key).
Is it bullet proof? In the face of a malicious state actor, nothing is bullet proof. We can only try to make it tougher for them.
Of course you are half right, but also completely wrong. The right question to be asking, is " Does the verification provided by the certificates and the browser's response provide any protection to end users?" The answer, despite all the flaws you mention, is "yes". If Google got owned, then yes, their ssl cert's verification would be moot. But that would require owning google, rather than just hijacking your router's dns tables. Which one is easer?
Why not simply make SSL recursive and tied to DNS?
The root servers sign the root certificates for TLD CAs. These sign a domain-limited CAs when one registers their domain. And organizations can sign everything within their domain (and make that as complex or simple as they need).
So SSL is effectively free, apart from some minor administrative costs. It's unique (the current DNS system already has the rules and procedures in place to make sure a name is unique and can't be trivially transferred to another party). And you don't really put your trust into anything you didn't effectively trust in some way before.
To make this manageable you probably want some additional intermittent CAs (the signing CA and the one which is safely tukked away in some vault somewhere). So a simple verification for 'update.microsoft.com' would be something like:
root server extra secure CA (for signing TLDS) -> .com extra secure CA (for signing domains under .com) -> .com working CA (for signing domain under .com) -> .microsoft.com extra secure CA (for signing anything under .microsoft.com) -> .microsoft.com working CA (for signing anything under .microsoft.com) ->
trusts working root server CA (for signing TLDS) ->
trusts
trusts
trusts
trusts
trusts update.microsoft.com server certificate
Much of these validations can be cached. Any changes can result in warnings (kind of like SSH connections to a machine for which the key has changed) which can be prevented if their is also a double signature from the previous CA certificate for that level (though the extra signature is only sensible if the path from the root is already deemed to be correct, it's just to make it painless for CAs to have a pretty short lifetime and to transparently reissue a replacement).
Adding these warnings also prevents simple takeovers even if some part of the chain is temporarily compromised (only for certain types of compromisings) or if someone pressured a party to issue it a conflicting certificate. So secure parts that we've already been in contact with before will be almost impossible to redirect without some warning.
Warnings themselves would probably be pretty significant since self-signing is effectively a thing of the past for anybody who has an officially registered domain. And the amount of root CAs to keep updated is also very manageable.
Furthermore because of all the intermediate CAs (especially in the top of the hierarchy) that should be the same for most people on the internet, one can easily add some kind of external validation system like 'perspectives' (or a more mash like system) to monitor what others perceive these to be.
Sure it wouldn't be watertight, but at least it's tied to something that's uniquely identifiable and which is often transmitted out-of-band (I don't have to search for my bank on the internet, I know what their official domain is! and for stuff I didn't know what their domain is I probably don't even know if it's their official domain and no amount of signing legalize or technology will fix that).
So if we could just make trust recursive and implicit with domain registrations (which shouldn't warrant any big price changes for it it mostly an administrative issue, which anything related to dns already is). Than we have the basics for trust system that normal humans can comprehend.
And by all means let the current SSL companies do what they have been really doing all these years. Which effectively has nothing to do with SSL and which is a poor excuse for "authentication" (what good is authentication when "identification" is a much bigger problem in real life (if you know a "Jan Jansen" than it's probably another person than the "Jan Jansen" I know, which equally translates to some company in your village/country and some company with the same name in another village/country. So if you don't
"Moo!" -- Anonymous Cow