Government Could Forge SSL Certificates

FutureDomain writes "Is SSL becoming pointless? Researchers are poking holes in the chain of trust for SSL certificates which protect sensitive data. According to these hypothesized attacks, governments could compel certificate authorities to give them phony certificates that are signed by the CA, which are then used to perform man in the middle attacks. They point out that Verisign already makes large sums of money by facilitating the disclosure of US consumers' private data to US government law enforcement. The researchers are developing a Firefox plugin (PDF) that checks past certificates and warns of anomalies in the issuing country, but not much can help if government starts spying on the secure connections of its own citizens."

Comments

Is it time yet?

[Skarecrow77]

For the return to tin can and string?

Re:Is it time yet?

[commodore64_love]

Apparently while we were not looking, our last three presidents did this to the Constitution:

(strikethrough)The right of the people to be secure in their persons, houses, papers, and effects, against unreasonable searches and seizures, shall not be violated, and no Warrants shall issue, but upon probable cause, supported by Oath or affirmation.....(/strikethrough) ----- So what's left? Amend.10 - deleted. Amend.9 - deleted. Amend.8 - deleted. Amend.7 - deleted. Amend.6 - deleted. Amend.5 - deleted. Amend.4 - deleted. Amend.1 - deleted.

How ironic. The only rights left are those that forbid soldiers from living in our homes, and the one that allows self-defense of same.

Re:Is it time yet?

[Timothy Brownawell]

For the return to tin can and string?

No, but it might be time for people to start using Perspectives. Which I'd guess is a better version of the new extension these people are making, although I can't really tell due to the PDF being broken (slashdotted?).

Re:Is it time yet?

[Z00L00K]

In any case - this will work only when the CA authority is cooperating with the government, but if you are your own CA then you will be in control of the chain.

Of course - your CA server may suffer an intrusion, but it will require a physical attack from an intruder. Especially if your CA server isn't connected to the net. And there are a large number of tricks to pull to detect intrusions in your facilities. Some of them are centuries old.

Re:Is it time yet?

[LucidBeast]

I like the way you think. You are thinking defending your CA using trebuchets, aren't you? I know they are siege weapon, but still centuries old.

Re:Is it time yet?

[petermgreen]

The problem is they don't need to get the cooperation of the CA that is actually in use, only that of one of the long list that your browser trusts.

Re:Is it time yet?

[spazdor]

We need something new. A distributed certificate authority.

I'm envisioning something like a Massively Multiplayer Online Diffie-Hellman exchange. Math wonks, is something like this in principle achievable?

Re:Is it time yet?

[lgw]

It isn't just online, of course. Today I had to visit a local courthouse. In order to enter and do my business with the local government, I had to wlak through an airport-style security checkpoint. Clearly I was being searched. Just as clearly, the police officers performing the search had no specific reason to believe that I had committed a specific crime.

I don't remember anywhere in the 4th amendment it says "unless we're scared", and yet these balantly unconstitutional seraches happen everywhere, all the time, online and in person, because we're scared. Please stop being scared - the statistical risks from threats like terrorism are a bit iger than the threat of meteor strike, and certainly lower than lightning strike.

Re:Is it time yet?

[aztracker1]

I so wish I had mod points today... One should bear in mind, that the one allowing self defense (right to keep and bear arms) has been increasingly stripped away over the years as well, and the ACLU doesn't even really consider it a right, or worth worth defending. I really do think that Civil War/Revolution will likely break out within the next decade for the U.S.

Re:Is it time yet?

[wealthychef]

I don't know about whether Civil War will break out, but you can certainly argue that a government that spies on its citizens and lies to them is certainly not "of, by and for the people."

Re:Is it time yet?

[Dishevel]

You might have wanted to post that one anon.

Re:Is it time yet?

[mR.bRiGhTsId3]

Uh? You entered government property. Just as you have the right to subject anyone entering your own house to whatever probing you desire before admittance so too does the government before you enter its property. You were not in public; you were in a government owned building. The government cannot randomly search you out on the street because it feels like it.

Re:Is it time yet?

[mlts]

You can always physically armor your CA server. One client of mine has a Windows machine which is permanently offline (was activated via phone so it never has touched the Internet directly.) This machine uses BitLocker with a passphrase to encrypt the volumes, and has inside it a USB card with an Aladdin eToken on an internal port. For signing stuff, the client inserts a USB flash drive or a SD card, signs it with the commercial version of PGP, or the signcode.exe utility that is used for Authenticode signing, pulls the drive/card out, and copies the signed files back onto the network.

This way, if someone tries to boot the server from other OS media, they need the recovery key to decrypt the OS, and upon booting back to the OS, it will hang until someone provides the TPM its PIN, (which will show that the machine was rebooted.) If someone takes the smart card out of the machine, they have 15 guesses to figure out a 32-64 character passphrase. After that, the eToken will erase itself.

No, this is not as secure as a dedicated HSM, but for what the client wanted, it provided enough security, and was a lot less expensive.

Of course an intruder can always use a rubber hose attack against people who have the ability to sign programs and documents, but what this setup gives the client is the ability to have the critical keys protected from some script kiddie who manages to crack into the corporate LAN as their first threat of concern. The second threat being someone trying to physically steal/compromise a machine while nobody is around.

Re:Is it time yet?

[minor_deity]

And who owns the streets? The government.

Re:Is it time yet?

[ghjm]

But we're talking about a courtroom, not a private government office. You can't choose not to "enter government property" when you have been served with a summons. Also, a courtroom is the very definition of a public space. In court, you are as "in public" as you could ever possibly be.

However, the constitution does not prohibit "random" searches or searches where you have not "committed a specific crime." It only prohibits "unreasonable" searches. If the great majority consider it reasonable to be searched when entering a high value terrorism target such as a museum, courthouse or airport, then such searches are unfortunately constitutional.

Re:Is it time yet?

[Simon80]

I second this - If you get it to check EVERY site, it can (in theory) prevent MITM attacks. It isn't configured to do this by default, however - the authors seem to have positioned it as a way of securely automating the "trust on first use" model for self signed sites.

Re:Is it time yet?

[HanzoSpam]

So you're saying that the right of a state militia to bear arms was so much in question that a constitutional amendment was necessary to guarantee it?

Um, yeah. That makes a lot of sense. Sure.

Re:Is it time yet?

[PopeRatzo]

So you're saying that the right of a state militia to bear arms was so much in question that a constitutional amendment was necessary to guarantee it?

Exactly so. At the time the Bill of Rights was drafted, the number one conflict in our congress was over the rights of states vs the responsibilities of the federal government. The fear was that if the federal government was ever to be unwilling or unable to provide protection to the states, that the states wanted assurances that they would always be able to defend themselves. I'm willing to bet that if you read the historical references with an open mind, you'll see what I'm talking about is correct.

Indeed the whole debate at the time was every bit as heated and divisive as the current debate over Health Care Reform. And in fact, the Constitution and Bill of Rights really didn't do all that much to make either side happy. There was no agreement, only a willingness to give the experiment a try. Ben Franklin himself commented on how none of the members of the constitutional congress were really all that happy about the results of their compromises. There was very little confidence among the members of that congress that the entire Constitution and the Bill of Rights would even last a few years. In fact, I recently watched a really good documentary about Franklin, and the creation of the Constitution and the similarities to what's been happening in our current congress over the health insurance reform legislation are quite striking.

You ask the right question, HanzoSpam, and I hope you're willing to explore a little further to find an answer that will satisfy your curiosity. If you'd like a list of historical citations to the debate that raged in the early 1780's over the topic of a national standing army vis-a-vis the rights of the states to form their own militias and how that turned into the 2nd Amendment, drop me an email and I'll send them along.

Be well, friend. I'm guessing that as you accumulate knowledge, your desire to "slug liberals in the teeth" will abate. I'm happy to oblige your quest to learn and grow.

who can we trust?

[Mantis8]

This reminds me of a bumper sticker many of us have seen..."Don't steal, the government hates competition!"

Re:who can we trust?

[Pojut]

Offtopic:

My favorite bumper sticker was one that I had on my truck back when I was in high school: "I sold your honor roll student the answers."

Damn!

[Anonymous Coward]

I'm going to have to go back to using dead drops for communication.

Re:Damn!

[mlts]

Never underestimate the bandwidth of a playing card box full of 32GB MicroSD cards.

Can we get rid of SSL now please?

[TheRaven64]

SSL is, and always has been, and ugly hack. End-to-end encryption should be done at the IP layer, not the TCP layer. Now that we have IPSEC, we have a standard way of doing it properly. The only remaining part of the problem is key distribution, but with DNSSec we can put IPSEC public keys in DNS entries and get end-to-end encryption.

A government able to insert something into the chain of trust is still able to fake a connection, but distributing the chain of trust makes this a bit harder. The US government won't be able to insert something into a .cn domain, for example, although the Chinese government can. For the ultra-paranoid, you can publish the same IPSec public key on both and make clients compare the two. Unlike an SSL certificate, the IPSec key is visible to anyone, even people who don't try to make a connection, so it's much easier to spot if someone has tampered with the connection, and will be cached in ISP's DNS caches, making an unnoticed attack much harder.

Re:Can we get rid of SSL now please?

[Mr Thinly Sliced]

Totally agree.

While we are having our christmas internet list filled, can we also start using DNSSec/IPSec and distributed trust for authentication between email servers please?

Re:Can we get rid of SSL now please?

[L4t3r4lu5]

The US government won't be able to insert something into a .cn domain, for example, although the Chinese government can.

I hear you're a looking for a reason for IPSEC and DNSSec not being implemented. Allow me to introduce a candidate answer.

Re:Can we get rid of SSL now please?

[Meneth]

sudo mod me up

ok :)

Re:Can we get rid of SSL now please?

[Anonymous Coward]

The only remaining part of the problem is key distribution

Wow, with all the hard problems solved we just have this easy one left

Re:Can we get rid of SSL now please?

[TheLink]

The Certlock thing should help (assuming they do it right and the software itself can be trusted), but the problem could have been fixed by the browser makers long ago if they took security seriously. If I remember right, the problem was discussed years ago in a firefox bug report.

Basically the browser should have features to allow you to be warned if:
1) The CA has changed (still vulnerable to "Gov can forge SSL certs with CA's help")
2) The cert has changed (paranoid mode- the Gov can eavesdrop only if they have the private key of the server - IIRC in the old days for some strange reason certain CAs actually made you send them everything, go figure why ;) ).

Now in paranoid mode, some load balancing sites might cause warnings because the certs could be different. For example different certs were installed on the servers serving up the same sites. This could be because they are in the middle of rolling out new certs. However this is not a huge problem, if the sites with the correct certs provide suitable warning in advance the user would realize that and accept the new certs.

FWIW, I'm wondering if this addon actually is OK: https://addons.mozilla.org/en-US/firefox/addon/6415 :).

Re:Can we get rid of SSL now please?

[0123456]

End-to-end encryption should be done at the IP layer, not the TCP layer.

Sorry, but that's nonsense. Encryption should be done at the IP layer as well as by the application; if encryption is only done by IPSEC at a low level, then I have no way of knowing that my connection to my bank is secure, or is even going to the correct site.

To give an example, for a long time I've had my XP laptop at home configured to use IPSEC to talk to my Ubuntu server. Yesterday I discovered that at some point the Ubuntu server had stopped running the startup script that configures it to require IPSEC for connections from the laptop, so I've been connecting to it without encryption for an indeterminate amount of time; and the only way I found that out was because I ran wireshark.

IPSEC is a good idea, but it's definitely not a substitute for application-level encryption and authentication. It's also insanely difficult to configure and debug; I took about two days just to get a handful of PCs in my house talking to each other and even now I have to run a cron job on the Ubuntu server to ping the two Windows PCs every minute in order to ensure that IPSEC does get set up correctly once they're booted as initiating the connection from XP is very unreliable.

Re:Can we get rid of SSL now please?

[TheRaven64]

You are confusing so many issues here that it's difficult to know how to reply. First, you are not using DNS to distribute your keys, so your experience is not particularly relevant. You are also talking about using IPSec for a VPN, rather than for individual connections. Second, there is no reason why the TCP/IP stack could not expose a single function for getting the security state of the connection, telling you whether:

• The connection to the DNS server is secure (using IPSec)
• The DNS record was signed.
• The DNS record contained the IPSECKEY entry.
• The IPSEC negotiation worked.

After calling connect() on a socket created via gethostent(), you would (if your app cared about security) call this function and then present a UI element like the padlock in browsers. There is absolutely no point in using SSL over an end-to-end IPSEC connection.

Re:Can we get rid of SSL now please?

[Threni]

He's not on my sudoers list, and the incident has been reported.

Re:Can we get rid of SSL now please?

[0123456]

You are confusing so many issues here that it's difficult to know how to reply. First, you are not using DNS to distribute your keys, so your experience is not particularly relevant.

How does using DNS to distribute keys tell me whether the connection is really, actually, physically encrypted?

You are also talking about using IPSec for a VPN, rather than for individual connections.

I'm talking about using it for individual connections between PCs..

Second, there is no reason why the TCP/IP stack could not expose a single function for getting the security state of the connection

Why should I trust the TCP stack's idea of whether the connection is secure when my web browser can determine that itself?

There is absolutely no point in using SSL over an end-to-end IPSEC connection.

Unless you actually want to ensure that your connection is actually, really secure, and the only way to do that is for your application to incorporate its own encryption and authentication. Rule #1 of security is to never trust what software outside your control tells you.

Other than performance or really, really badly implemented encryption schemes (e.g. two layers of ROT13), there is no downside to adding another layer of encryption.

Re:Can we get rid of SSL now please?

[TheRaven64]

So I presume your web browser doesn't use OpenSSL / GNUTLS or whatever your host platform's native SSL library is?

Re:Can we get rid of SSL now please?

[Sir_Lewk]

The layer encryption is done on is really irrelevant to this issue, it is the trust model that is broken.

Re:Can we get rid of SSL now please?

[jesset77]

So I presume your web browser doesn't use OpenSSL / GNUTLS or whatever your host platform's native SSL library is?

Noep. Sometimes there are advantages to statically linked libraries. :P

Re:Can we get rid of SSL now please?

[mlts]

Even with IPSec, I'd still use SSL because it does encryption on a higher level, and in some cases, is controlled by app versus app. It also allows for client certificates, so I can lock out a host of problems by having a critical external-facing Web server only allow for authentication via a cert on a smart card. Of course, more sophisticated malware can run a MITM attack by compromising the browser and changing text in flight before it leaves the client machine, but that isn't what SSL is designed to protect against.

IPSec can work keys on the machine layer, but I like packing my own parachute on a higher layer with SSL or SSH.

Re:Can we get rid of SSL now please?

[conspirator57]

This, pretty much. Though the trust model is "good enough" for the vast majority of online business transactions. It's just that some things people want to do with certs from the CAs (and some business transactions) are not appropriate for it given the precedent for governments reading people's mail.

Re:Can we get rid of SSL now please?

[durdur]

SSL (more exactly TLS) is an established, mature, well-designed secure protocol. It's not the problem. The "remaining problem" you mention though has always existed with PKI: how do you manage certificates, distribute them to all the sites that need them, handle revocation, etc. That's a big issue and there is no drop in easy solution.

Re:Can we get rid of SSL now please?

[Anonymous Coward]

You know, with a PKI, the main problem is man-in-the-middle. It's quite possible to defeat that though, using computationally intensive calculations and latency analysis, getting to around 1 in 4 billion chance in only 32 rounds. I should really publish a paper on this, it's pretty cool.

Re:Can we get rid of SSL now please?

[hitmark]

well, there was this recent incident when chinese blocks on facebook and other .com sites spilled over to other dns root servers...

Re:Can we get rid of SSL now please?

[Zarhan]

SSL is, and always has been, and ugly hack. End-to-end encryption should be done at the IP layer, not the TCP layer.

    No way. The higher layer encryption is conducted, the better. The lowest layer where there even is any concept of "end-to-end" is transport.

    Same reason you don't think about doing online banking over WPA-shielded wireless LAN, because you know that the security only extends to the access point.

    Especially with all the locator-identity divergence work going on, or even if IP(v6) anycast comes along as a load balancing method, you really don't want to worry about things in IP layer affecting your security - so just take it higher.

If security is really important to you

[DarkOx]

If you really want to be secure and you are using certificates you should be self signing and exchanging the self signed certs with your partners out of band.

Re:If security is really important to you

[Anonymous Coward]

I like the way OpenSSH does it -- Trust On First Use (TOFU). First time you visit a server you're warned of possible MITM and given a fingerprint (which you could have, say, confirmed in person). After that you never see a warning again unless the server's key unexpectedly changes. No forcing you to automatically trust CAs, and no overstated warnings about self-signed certs.

Re:If security is really important to you

[Cassini2]

If you really want to be secure and you are using certificates you should be self signing and exchanging the self signed certs with your partners out of band.

Precisely. Otherwise, you are always open to a sufficiently sophisticated man in the middle attack.

Re:If security is really important to you

[mpe]

I like the way OpenSSH does it -- Trust On First Use (TOFU). First time you visit a server you're warned of possible MITM and given a fingerprint (which you could have, say, confirmed in person). After that you never see a warning again unless the server's key unexpectedly changes. No forcing you to automatically trust CAs, and no overstated warnings about self-signed certs.

Whereas the way web browsers typically do things you could be communicating with several hundred different entities and not know it.

Re:If security is really important to you

[thijsh]

I really want web-browsers to support this properly, with a dialog that shows that it's self-signed and provides encryption but no verification. Self-signed certificates have a lot of advantages, and the only thing holding back widespread use is those crappy browser dialogs warning you that this website is going to cause the end of life as you know it. There is a legitemate use for encryption without a CA, and this article only confirms that.

The way I see it you have the following levels:
- HTTP (unencrypted, but free)
- HTTPS SSC TOFU (encrypted and free + as a bonus no government can mess with certs apparently)
- HTTPS CA (encrypted + verified)
- HTTPS CA+ (better verification + whatever extra shit they can sell for overpriced certificates)

The question is now: which browser will be the first to support true free and 'open' HTTPS?

Re:If security is really important to you

[mordejai]

This is how we did it in the pre-internet years (early 90s) with PGP.

There are two problems with this approach, however:
1. While it works fine for use between friends and with your company's sites, it's not practical to do with every site you interact with.
2. The tools (browsers, OSs) don't make it easy to add certificates. And, if they did, this would be quickly taken advantage of by malware.

Re:If security is really important to you

[Anonymous Coward]

My Firefox at home already pokes me about "This host has a key that isn't signed by (suchandsuch). Do you want to confirm an exception?"

Then, if changed, it warns me again. Which is nice.

Seems the same thing, to me.

Re:If security is really important to you

[Anonymous Coward]

My Firefox displays a message saying "If you're an average internet user, please stare in confusion, panic, pull the plug on your computer, set your internet connection on fire and call the FBI. If you happen to know what you're doing, you may access this site, though we strongly urge you not to, by standing on one leg for exactly 36 minutes while hitting yourself on the head with a chicken."

Just as the article suggests, it's ready to be overridden by any old large country of questionable ethics at any time, though.

I'd consider an assurance that I'm connecting to the same content provider each time much more assuring than an assurance that I'm always connecting to someone a CA trusts, so I don't see why they have to penalize small sites from using "casual encryption" with a self-signed certificate.

Re:If security is really important to you

[icebraining]

Exactly like Firefox (and probably other browsers): if you delete all the CA certificates, you'll get warned the first time you visit an encrypted site. Firefox shows you the certificate data, and you can accept and mark "Permanently store this exception".

Re:If security is really important to you

[mlts]

Perhaps have Web server certs trusted by multiple CAs, so you might have a level of trust above that. This way, if a website had a cert validated by a CA in the US, Israel, Germany, Russia, and China, one of those CAs might get compromised, but it would take a pretty big international agreement to compromise all of them and generate a bogus cert.

Re:If security is really important to you

[inKubus]

Look at Verisign. They are a fairly global corporation, but yes, the root certs are in the U.S. Of course, there were rumors that they were a branch of the NSA for a while. Almost all of the original members of the Internet were government contractors or universities, so it's going to be hard to get away from that.

If you believe their website, they have a seven layer chain of trust with the root certificates locked in a tamper proof envelope in a locked box in a vault in a secure location somewhere.

For the decentralized approach, you have to actually communicate with people, and transport certs with a known secure means. See Web of trust. Personally, I see this as more possible today than ever. You could visit your bank's local branch and pick up a trusted cert with your cell phone or something, then bring it home and import it into your browser. You could visit another branch and validate the two. A compromise at one branch won't compromise all users because they extend the trust from the central bank.

All of this is possible and recommended. SSL is not a privacy protocol, it's meant to prevent casual eavesdropping only. If someone "pwns" Verisign, they can read all SSL traffic based on their root certs. I would not be surprised at ALL to learn that NSA has them, if not the FBI. But, if you can't trust your own government, who can you trust? So, who cares, I'm glad they know so they can catch crooks.

Re:If security is really important to you

[Anonymous Coward]

What you are really saying is that, once again, this is only going to impact the naive, stupid and honest users, crooks, terrorists, governments and the careful will continue to do as you suggest and not TRUST the public CAs.

Re:If security is really important to you

[Anonymous Coward]

In reality, WOT is really the only way to do things. However, trying to get users to spend the time to install PGP or gpg, make and store a private key securely, and then work on key signing exchanges with other people is far harder than herding cats. a default install of S/MIME is still vulnerable to MITM attacks, but the chance of a MITM attack is far smaller than it is of a stored mailbox being read by unauthorized personnel, or by authorized people who have a gag order on them not to reveal that they are snooping.

With the NSA having keys, this wasn't a big issue because if they did act on any info or someone detected active eavesdropping, the jig would be up. However, if one digs into the root cert list in most Web browsers, there are certs from governments there who likely have little to no interest in protecting anything European, much less American. Governments where people disappear. Of course, one can just drop those certs into the untrusted list, but will Joe Sixpack do this? Doubtful.

So it ends up a tradeoff... CA compromise as a relatively small hazard, versus getting users to actually care about setting up a WOT and them refusing to, so there is worse security. I'd rather trust the NSA on a daily basis than some other world country who would like to know where I live so they can sell the info to street gangs to perfectly time a robbery.

Re:If security is really important to you

[the_womble]

The one thing that governments have consistently been able to reach big agreements on are measures to spy on and control their citizens. Just say "terrorism" and it will sail through.

Re:If security is really important to you

[Anonymous Coward]

http://www.cs.cmu.edu/%7Eperspectives/perspectives_usenix08.pdf

what no one wants you to know

[yup2000]

And it took you how long to figure this out? Anyone with real security in mind would create their own certificates and sign them. What's always been missing is a convenient way to verify the identify of the person you're communicating with. CAs only help in certain situations. SSL has always been more about encrypted content than identification no matter what people try to tell you.

Re:what no one wants you to know

[Dr. Evil]

Well... it *is* about identity, and limiting the scope of who you have to trust.

With SSL, you trust the computer manufacturer, your hardware configuration, your Operating system, your web browser (and root certificates in your web browser) and the Certificate Authority (which is a corporation under the U.S. government).

Self signed certs are better, but you need a second channel to communicate the certificates securely.

Re:what no one wants you to know

[timeOday]

I agree, ssl is really about facilitating secure communications between parties who don't really trust each other, like you and a bank, or you and an online store. Ultimately, that's a job only government can do, akin to (and derived from) contract enforcement, which is how trade among parties is facilitated when there are no tribal or other bonds. If the CA decided to sell you online identity to the highest bidder, what's your recourse? Sue them. So, ultimately the government is the arbiter. Ok then, ssl only helps in "certain" situations, but it's an extremely useful set of situations.

Re:what no one wants you to know

[Anonymous Coward]

Pfft! Anyone with really real security would string their own fiber directly to each router and create their own private network kicking everyone else off the end network while they use it, and then dismantle everything afterward. You kids and your 'certificates'.

Generate your own certificates...

[Anonymous Coward]

and distribute them by mail or something. That doesn't help taking to your bank,
but then again if the government wants your bank balance they'll just ask the bank.

Re:Generate your own certificates...

[MasterOfMagic]

That doesn't help taking to your bank

It sure does. When someone signs up for online banking, make them go to the branch to set a password and give them documentation showing how to verify the certificate and set it up in their browser. Bonus points for making this a bank-specific CA and then having rotating certificates on the bank website that are signed by this bank-specific CA so that this only needs to be done once per computer/browser.

Re:Generate your own certificates...

[Anonymous Coward]

First of all, most people would be completely overwhelmed by the technical aspects of this requirement. Secondly, all cryptographic key information must expire at some point, even CA keys. Right now the browser makers take care of updating the root CA certificates. If you're going the independent route, you'll have to recheck the certificate occasionally. There is no "needs to be done once per computer/browser". And, if you're going to install a bank's CA certificate, remember that this CA can sign certificates for other domains too. There is no provision for limiting the scope of a CA to particular domains (which is a stupid omission IMHO).

Re:Generate your own certificates...

[plover]

Actually, the banks already have a way to distribute the certs: put them on smart cards. The bank can trust the cert because they issued it. The customer can trust the cert because the bank handed it to them.

There are many good security features a smart-card based solution brings to the table. First, the bank is entirely in charge of their own security from end-to-end. There is no trusting of third parties*. The bank is able to uniquely verify the presence of your card, and can refuse to transfer money without it. And if the bank is compelled by a warrant to cooperate with the government, they just hand over the data without fooling around with a clumsy man-in-the-middle attack, .

What's really needed is a ubiquitous smart card reader to be included on standard computer builds.

*Actually, you still have to trust the third parties who provide the applications, operating systems and hardware. The only completely secure way around that is for the bank to provide the actual computer to the customer, via a handheld card device like Vasco makes. A close second is by providing a custom bootable image on read-only media.

Re:Generate your own certificates...

[Anonymous Coward]

or just give them a self signed cert on a cd

Re:Generate your own certificates...

[iluvcapra]

Actually, the banks already have a way to distribute the certs: put them on smart cards. The bank can trust the cert because they issued it. The customer can trust the cert because the bank handed it to them.

An even EASIER solution would just be for them to post the fingerprint for their self-signed certificate on a large sign behind the teller window at all of their branches, essentially staging a signing party -- the area behind the glass is protected by lock and key. They simply tell their customers the option to either use an SSL link with a Verisign-signed cert, or a bank self-signed cert, provided the customer checks the fingerprint and trusts it before continuing. Public certs don't have to be moved out of band, only verified out-of-band. Once the customers can validate the fingerprint they'll know they're talking to the same institution that controls the airspace behind the teller window.

But as it pertains to this problem, it's useless since it's a bank and the gov can just subpoena all of your information anyways.

Re:Generate your own certificates...

[plover]

No, I'm sorry but it's a completely unusable solution because it's not easier for the customers to use or understand. Ultimately, many of their customers are stupid, and it's not their fault. 50% of them are below average, after all. The most we can ever hope for is that they recognize "bank == safe place for my money." And that doesn't absolve the bank of the liability to provide that security, at least not if they want to keep having customers.

So all the technical work of security has to end up in the bank's hands. You can ask a customer to perform only the simplest of instructions, and even those will only be followed if they are required to obtain an immediate payout at the endstate.

"Put this card in the slot in order to withdraw money" is an example of a good model to follow.

"Put this card in the slot and type your secret PIN in order to withdraw money" is an acceptable model to follow, but it's surprisingly close to the limits of what some people are capable of.

"Drive to the bank, write down the 40-digit fingerprint number in our window, go home, run a virus scan, type this URL into your browser without using a bookmark, doubleclick the padlock, click the Security tab, click the View Certificate button, check that the certificate SHA-1 fingerprint is the same as you wrote down, click the details tab, check that the root signer of the certificate hierarchy chain says Verisign, click the close button, dismiss the dialog box, click the login button, type your username, type your secret PIN into this field on the web page, click 'Transfer' to pay your bills on line" is hardly an acceptable model of a use case. Yet it's exactly what is being recommended.

And people wonder why there are security breaches.

Re:Generate your own certificates...

[Burz]

Displaying the fingerprint behind the glass would be excellent, but I've long thought that simply putting it on checkbooks, credit cards and correspondence would work nicely. Trying to substitute a fingerprint for a fake cert wouldn't get very far because too many people would see mismatches with the real cert from the website, fingerprints on older correspondence, etc. Even an option to hear the fingerprint somewhere on the organization's phone menu would be great (and so very easy).

Re:Generate your own certificates...

[iluvcapra]

Fundamentally the use of a self-signed cert versus a CA-signed one has to be left to the bank customer, I think, and if they choose to go the self-signed route they should be taking a small affirmative step, since they're the one that wants the security anyways. There's no more secure method of key exchange than a signing party; smart cards can be hacked, a piece of paper with human handwriting cannot.

We're going for a solution for the safety-conscious/paranoid person... for normal people there's absolutely no problem with the PKI as it stands, since, as I said before, all of their bank info can just be subpoenaed the old fashioned way anyways.

Re:Generate your own certificates...

[iluvcapra]

There's no more secure method of key exchange than a signing party;

Well, that's a little extreme and I regret writing it.

Re:Generate your own certificates...

[plover]

I still think the bank could have cashiers securely distribute smart cards with their self-signed cert on them and do it with a very high assumption of integrity (after all, they know how to control cashiers handling tens of thousands of dollars daily.) Sure, they could still print their certificate's fingerprint in the window, and you could check the fingerprint yourself on the card whenever you wanted; and for the security-minded paranoiac, they would.

What I'm looking for is to give almost the same amount of security assurance to Joe Sixpack, or his dumber brother-in-law. Making a secure system available to them is just as critical as making one available to you or me, because crooks/con-men/phishermen can obviously manipulate the person almost as easily as their computers.

and remember...

[presarioD]

...all this is for your own good...government by the people for the people type of thing...smile...

SSL / HTTPS

[bbroerman]

One more nail in the coffin... (See http://nearlyperfectsoftware.com/secureajax.html for other hacks). Good thing I'm working on a protocol and libraries / utilities that can be used to replace it for all of my work, and my clients... Starting with a secure ajax framework, then on to things like POP, IMAP, SMTP, FTP, Telnet, etc. Should be cool once I get them all done.

Re:SSL / HTTPS

[WrongSizeGlass]

I'm interested in your views and would like to subscribe to your newsletter, but I'm not sure if I trust the certificate governing your 'Subscribe To Our Newsletter' page.

Re:SSL / HTTPS

[ArsenneLupin]

How would this secure ajax framework work? A (trusted) plugin to be installed in the client's browser?

Because, if the client-side javascript is being served by the server over the Web, it's vulnerable: an attacker could just intercept the javascript and insert whatever he wants inside, and pass that on to the client, who would be none the wiser. And as it is non-standard, there'd be no tell-tale signs such as http instead of https, that an astute user could see.

Re:SSL / HTTPS

[bbroerman]

That's the "secret sauce" so to speak of the library. Like I mentioned in a previous post, I have been working with other expert software developers (who are close friends of mine) on code reviews, in-house testing, etc. I don't have the money for expert security people yet, but I am working on other avenues on testing the security of the protocol. I've been working on this library for the past 2 years...

Re:SSL / HTTPS

[ArsenneLupin]

That's the "secret sauce" so to speak of the library.

Security through obscurity... Given enough time and determination, an attacker can intercept and reverse-engineer your library and add as much salt into your secret sauce as he wishes...

The only way to make it secure is to deliver the client part out-of-band over a known secure channel. Anything else may just delay an attack, but not prevent it.

Re:SSL / HTTPS

[Anonymous Coward]

Why don't you just cut out all the unnecessary middlemen and submit all your stuff to thedailywtf.com directly?

Re:SSL / HTTPS

[bbroerman]

Possibly, but time will tell. I've been working on this for 2 years now. I've got some close friends who are long time software experts looking at it. I would love it if I could find some security experts who would review it free, or low cost. In the mean-time, I have been reading every security book I can find. And, like I do with all of my other software testing, I have been going through it looking for different ways to "hack" it and then going back and tweaking the design.

Re:SSL / HTTPS

[ArsenneLupin]

And I mean, with all your reading, and all those smart friends, it never occurred to you, and nobody told you, that somebody ill-intentioned could just replace your library with something that does what it does, but that additionally XmlHttpRequests a copy of the "secure" data to http://evilsite.com?

Re:SSL / HTTPS

[bbroerman]

That's taken into account. I spent many months working through that. Again, that was a key factor in the initial design of the initialization protocol.

Re:SSL / HTTPS

[ArsenneLupin]

And, what solution did you use to avoid such tampering? Loading the library via https? Or just praying to God that hackers wouldn't know how to fake a checksum?

Re:SSL / HTTPS

[bbroerman]

That's the key part that led to the patent app. and no, it doesn't use https or prayer. And... the basic principal can be applied to other applications and protocols as well. Once I get the latest version of this library tested, optimized, and done, I'm going to start writing other apps that use the basic protocol, starting with FTP, POP3, and Telnet. Sorry I can't get more into it here, but I am waiting on the patent for the base protocol first.

The Obama govt isn't evil

[Anonymous Coward]

Well, at least it would be Obama watching our every move instead of Bush, so it's not that bad. //head-smack

Re:The Obama govt isn't evil

[Errol backfiring]

It's usually not the head puppet who is watching. It is the people in government who are not rotated at the elections who do this.

Does that mean...

[alexhs]

Does that mean that self-signed certificates are now more secure ? :)

Re:Does that mean...

[TheRaven64]

No. This is not a passive attack, it is a man-in-the-middle attack. The government gets an SSL certificate that looks like the remote one. You connect to their computer, thinking it's the remote computer, authenticate, and it then does the same with the remote machine. With a self-signed certificate, this is even easier because any certificate looks the same as the self-signed one.

It does mean that pre-shared certificates (whether signed by a third-party or not) are more secure. Unfortunately, these are not practical for most purposes. The entire point of the SSL chain of trust is that you only need to pre-share a small number of certificates and these can then sign others.

Re:Does that mean...

[fuzzyfuzzyfungus]

Self-signed certs are more secure; but only if you have some way of distinguishing them. "Self signed certs" as a generic class, are man-in-the-middle city because anybody can produce one. The feds don't even have to coerce the CA, they can just sign their own.

A specific self-signed cert, that you have some out-of-band reason for trusting, is extremely secure because only by compromising the computer storing the signing key could an adversary produce a fake one of those.

The problem is, outside of fairly trivial scenarios(corporate intranet with self-signed certs, worker drones' browsers trust that cert by group policy; small group of paranoics who know each other IRL exchange keys under the bridge at midnight), establishing that out of band reason for trusting a cert is a pain in the ass, and not amenable to any particularly clear solution.

CAs are basically the ugly-not-really-all-that-good solution that has the virtue of working in practice. You trust the cert because the big corporation whose business is attesting to the trustworthiness of certs says you should trust it. Easy, simple, and actually works ok from a strictly financial perspective(ie. the amount of money that Verisign can make by selling overpriced sequences of bits that make the magic green bar appear in consumer browsers is greater than the amount that they could make by MiTM attacking a whole bunch of banking sessions and then fleeing to Namibia with their reputation in tatters).

Where it breaks down is non-strictly-financial situations. It is highly unlikely that clandestine cooperation, for surveillance purposes, with state agencies is all that costly to Verisign, or their ilk(and may in fact be lucrative, as doing various sorts of wiretaps is for the telcomms). If your threat space is just occupied by script-kiddies and Ukranian cyber criminals, commercial CAs work pretty well. If it is occupied by state entities who want information rather than money, there is no particular reason to expect them to work.

Re:Does that mean...

[ArsenneLupin]

No. Without any further verifications, self-signed certificates can be spoofed by the common crook, whereas CA-signed certificates can only be spoofed by governments.

With further verification (customer manually checks certificates finger-print), both self-signed and CA-signed would be secure, but then you wouldn't really rely on the signature at all, but rather on the fingerprint.

Re:Does that mean...

[alexhs]

I wrote my previous post under the misunderstanding that governmental agencies could get a copy of the original certificate private key, not that they could get a different private key with the same certification information.

That second case of course mean that "trusted" certificates are neither better nor worse than self-signed certificate. This is a MITM attack that only works well in the case of a first connection (as you should be wary of a certificate change as long as the preexisting certificate didn't expire).

In the first case, however, it would mean than the government could impersonate the certificate owner at any time, which is not possible with a self-signed certificate, as you're only ever giving the public key.

This is of course overlooking the fact that you're not giving your private key to the certification organism either, but a certificate signing request.

Re:Does that mean...

[X.25]

No. Without any further verifications, self-signed certificates can be spoofed by the common crook, whereas CA-signed certificates can only be spoofed by governments.

Hi.

Please spoof my self-signed certificate.

Thank you.

Re:Does that mean...

[u38cg]

I complain about this every time the subject comes up, but the problem is a contractual one. You are having to place trust in a CA you have no contractual relationship, so what mechanism causes that CA to work in your favour? None. Browsers should ship without any root certificates, and users should pay to subscribe to whoever they choose to provide them with root signing services. Economics would help enforce the trust issues. It isn't a magic bullet, of course, but to me it takes the biggest weakness out of the way.

Re:Does that mean...

[fuzzyfuzzyfungus]

I have my doubts about that one, on two basic grounds:

1. It isn't clear that a contractual relationship would save you from any threats that CA self-interest with respect to reputation isn't already saving you from. Any CA knows that they are dead if the browsers drop them. Further, most commercial applications of the ability to man-in-the-middle somebody are illegal. Thus, the risks of the CA selling you out for some modest commercial gain are already fairly small. On the other hand, you will have a very hard time getting a contract that will protect you if the Feds show up at the CA's office with a perfectly legal warrant/national security letter/Lettre de cachet and an offer to pay "reasonable expenses" related to the ongoing investigation. Your contract will be of even less use if some spook shows up and tells the relevant person at the CA that he'll fucking Jack Bauer his entire family if he doesn't provide the fake cert.

2. The browser-user's choice of trusted CAs is only up to him in a fairly theoretical sense. Yes, technically, the browser user is free to modify whatever config file or key directory dictates what CAs his browser trusts. However, he has no control over what CAs the websites he wishes to visit choose to buy their certs from. They do this on their own; based on cost, or vendor reputation, or similar factors. If site X uses vendor Y, the security of your interaction with site X is dependent on vendor Y, whether you like it or not. You have no mechanism(aside from sending letters to site X, inc. demanding a change) for requesting a cert validated by Vendor Z, who you have decided to trust.

You are perfectly free to narrow your scope of trusted CAs as far as you want; but you'll either have to narrow the scope of your web browsing at the same time, deal with an endless stream of cert warnings, or turn off cert warnings, which hardly makes you safer.

Site operators are the ones with contractual relationships with the CAs and, unfortunately, it isn't clear that their financial motivation will provide any more protection than the strictly commercial stuff. If I run ecommerce.com, I will be seriously pissed if my CA is issuing faked certs for ecommerce.com.evil, or a fake ecommerce.com controlled by somebody who is doing some DNS poisoning. Any such CA would likely find themselves without customers. However, it isn't clear that I'd care all that much whether or not my CA is complying with feds, even if I have a choice in the matter. Even if my CA doesn't, my credit card processor(or, for that matter, me) might well just be slapped with the warrant instead. Plus, of course, there is the competitive pressure in favor of cheap 'n shoddy certs.

Re:Does that mean...

[Anonymous Coward]

Of course there's a mechanism causing the CA to work in your favor: if they don't, and if they give a government fake certificates, and if that becomes known, they would be pulled from the default list of CAs installed in browsers. That would cause the certificates they sold to all their customers to pop up with a warning, and their customers would migrate to a different CA within days, and the offending CA would lose all their business and fold up. It's a web of trust, and if you prove that you're not trustworthy you're going to lose your business.

DNSSEC has a similar attack against it

[tepples]

with DNSSec we can put IPSEC public keys in DNS entries

Unless the government compels domain name registrars to sign phony DNS public keys.

For the ultra-paranoid, you can publish the same IPSec public key on both and make clients compare the two.

Which is little different from hosting something at two different domains with TLS certs from different registrars in different countries.

Re:DNSSEC has a similar attack against it

[TheRaven64]

Which is little different from hosting something at two different domains with TLS certs from different registrars in different countries.

It's very different. The server does not need modifying at all. It only needs a single IPSec private key, you are just distributing the public key via two different routes. The client doesn't even need to try connecting in order to verify the integrity of the key, it just needs to try fetching the two different DNS records and comparing their IPSECKEY entries. If they are different, don't connect at all. Importantly, individual clients don't need to do this check; you just need someone to be perform this lookup periodically to see if either of the DNS entries has been modified. Because the DNS entries are cached, you can't easily perform this attack on a single client, you need to do it on a network, and that makes it a lot harder to do secretly.

Re:DNSSEC has a similar attack against it

[Mr Thinly Sliced]

DNSSEC has a similar attack against it

Except with TLS you are putting the logic and handling in every application. Putting it further down the stack makes it easier to update/patch etc.

There really needs to be just one place to put the necessary functionality and fix the bugs (which we have to fix anyway to get the implementation of IPSec/DNSSec correct).

Re:DNSSEC has a similar attack against it

[iluvcapra]

Putting it further down the stack makes it easier to update/patch etc.

It's worth pointing out that the technique described here isn't a "hack" that can be patched, it's an intrinsic feature of public-key crypto, and specifically a direct consequence of unreservedly trusting the CAs. The CAs are capable, using no tricks or computer hackery, of creating as many "redundant" signed certs for the same qualified name as they wish.

Re:DNSSEC has a similar attack against it

[Anonymous Coward]

You're half right. Using two channels with different affiliations to make sure you got the right public key is indeed an option with DNSSEC. Of course something similar could be done with SSL, too: The server could present a certificate with one signature on one port and the other signature on the other port, both for the same public server key. If the signatures check out and the public key is the same, then you're safe, unless there's collusion between the two certificate chains.

Where you're completely wrong however is the assumption that attacks can't be performed against single clients. The government can MITM the route to the DNS server(s), so it can not be assumed that you're seeing the same responses as everybody else. The phony records can be created just for you and nobody else ever needs to receive them. Defending against an attacker who can read and modify all your connections is not trivial at all.

Re:DNSSEC has a similar attack against it

[MasterOfMagic]

The problem with a system that relies on trusted third parties is that these third parties have to be, well, trusted. This implies that they are trustworthy. Have you evaluated all of the CAs on the list included with your operating system and browser for trustworthiness? I know I haven't. I've delegated that to the OS vendor and the browser vendor. Should I be doing this? Do I have evidence that shows that my OS vendor and browser vendor are trustworthy? And whose interest do they work for?

These are all things that need to be evaluated when dealing with a system that requires trusted third parties. The problem, of course, is that very few people actually do this. SSL is a system that requires trusted third parties if you are to put any trust in the fact that the certificate signed by a CA really belongs to the person the CA says it belongs to.

[This is, technically not true with self-signed certificates. Anybody can be a CA. Just self-sign a certificate and use that to sign the certificates of others. The problem is that you're not included by default. Of course, there are some sites that have their own CA, either for business reasons or because they can. They have an internal CA that they use to sign certificate for business purposes. These CAs are verified and pushed to machines, either by Active Directory at Windows sites or some other mechanism. There's no reason that an individual can't do the same when they generate certificates. The problem is that the fingerprint of CA certificates needs to be validated out of band in order for you the avoid a man in the middle attack when distributing the CA certificate to somebody else. This sort of distribution of SSL certificates would not require a trusted third party, but you would need to be able to identify the person or organization giving you the fingerprint and judge their trustworthiness.]

Re:DNSSEC has a similar attack against it

[Sancho]

This is, technically not true with self-signed certificates. Anybody can be a CA. Just self-sign a certificate and use that to sign the certificates of others. The problem is that you're not included by default. Of course, there are some sites that have their own CA, either for business reasons or because they can. They have an internal CA that they use to sign certificate for business purposes. These CAs are verified and pushed to machines, either by Active Directory at Windows sites or some other mechanism. There's no reason that an individual can't do the same when they generate certificates. The problem is that the fingerprint of CA certificates needs to be validated out of band in order for you the avoid a man in the middle attack when distributing the CA certificate to somebody else. This sort of distribution of SSL certificates would not require a trusted third party, but you would need to be able to identify the person or organization giving you the fingerprint and judge their trustworthiness.

But if you still trust the third-party CAs, then this is still subject to the same attack. Even though you've added your CA to the trusted list, a third-party could coerce another CA to sign a certificate for your domain, and then perform a MITM attack on you.

The only way to be sure is to trust no one but your own CA.

Re:DNSSEC has a similar attack against it

[Anpheus]

But isn't the point of DNSSEC that the US Government couldn't forge a certificate for a .cn domain? They'd have to have the root key, I doubt China would give that out.

Re:DNSSEC has a similar attack against it

[DragonWriter]

It's worth pointing out that the technique described here isn't a "hack" that can be patched, it's an intrinsic feature of public-key crypto, and specifically a direct consequence of unreservedly trusting the CAs.

Unreserved trust for CAs isn't an intrinsic feature of "public key crypto", or even of SSL more specifically. Its quite possible to use SSL without trusting any third party CA (though that means you can only deal with people using SSL that you have a preexisting relationship with to exchange certs), or less intrusively, one could design user agents to provide an option of whether to trust a certificate (including providing the CA information) the first time it was presented, rather than treating trust of a CA as absolute.

And within the broader realm of public key crypto, its possible to do "web of trust" systems which amount to requiring validation of the identity of an entity from multiple CAs, none of which is extended more than minimal trust individually.

Re:DNSSEC has a similar attack against it

[iluvcapra]

Unreserved trust for CAs isn't an intrinsic feature of "public key crypto", or even of SSL more specifically.

My point is that this isn't a design flaw, and that public key cryptography allows an authority to sign whatever it wishes to sign. The concept of a root CA only signing certificates of people who legitimately hold the name/organization/entity those certs are bound to is sortof... wait...

I've never gotten a cert from a CA, do they ever even make a promise or agree in writing that they won't sign any certs that use your names but who aren't you? Deadly serious, because honestly what keeps them from doing this, aside from good manners? Is there anything that keeps them from offering a $10,000 "impersonate anyone" package? It seems that the only thing that would keep them from doing this is it would ruin SSL for credit card transactions, but as long as they were able to keep that part of the business unmolested...

In any case, this problem isn't technological, it's fundamentally a policy issue.

Re:DNSSEC has a similar attack against it

[Anonymous Coward]

Bad example, because the DNSSEC root key (which signs the records containing the TLD public keys) is in US hands. The root key is the one key which can be used to forge all others. Everybody else can only forge keys in their part of the hierarchy.

Anyway, let's assume the root key is split or some other way is found to ensure the authenticity of TLD keys. That doesn't affect what I wrote: A similar second-channel approach could be implemented with SSL, and attacks on individual clients by someone in control of the keys are not prevented by the DNSSEC security model (as is).

TheRaven64 incorrectly assumed that a targeted attack was infeasible and that therefore the second-channel verification could be shifted to public services which monitor DNS for manipulations which are correctly signed but inconsistent with other channels (in the example the second domain name under .cn for the same server). If the client trusts the verdict of another server and does not verify the second set of domain records himself, then a targeted attack is still possible, even without access to the signing keys of the second domain.

Re:DNSSEC has a similar attack against it

[Xenophon Fenderson,]

It's worth pointing out that the technique described here isn't a "hack" that can be patched, it's an intrinsic feature of public-key crypto...

No, the technique described is a consequence of the X.509 trust model, which is hierarchical. SPKI/SDSI and PGP/GPG have different trust models that don't require certification authorities, although I'm sure that they have their own weaknesses.

Re:DNSSEC has a similar attack against it

[inKubus]

We do this with our VPN: the VPN client is installed on a laptop on-site, and the group cert is copied to the laptop. That is the trust layer. You have to have a trusted cert on the device you wish to use. If you get it from the internet, it could be the wrong one. If you install it from the lan, you have more control over it being the correct one. Then, as you mentioned, you can also verify the fingerprint manually using other means (phone, postcard, etc.)

They've Always Been Pointless

[segedunum]

SSL certificates only provide the ability to encrypt communication between a browser and a server. That's all it's for. Alas, many people have have tried to build in some level of 'trust' to SSL as well, and the money racket that has grown up around issuing SSL certificates on an ad-hoc basis just so someone's browser doesn't complain needs to go the journey. Those root certificates in your browser are just money for old rope. We definitely need something better.

Re:They've Always Been Pointless

[petermgreen]

Encryption is of limited utility if you aren't sure who your encrypted session is with. Since manual key exchange has practical problems browsers went for the

Unfortunately the major browser vendors have put WAY too many CAs on the trust list meaning that pretty much any significant governement in the world can ask/order someone to generate them a cert for any domain. Some criminals probablly can too.

IMO the proper way to do it would be to have a chain of trust system as part of DNS so the only people who can vouch for you are the operators of the registry containing your domain. I think dnssec may be trying to do this but it will have an uphill battle to replace the current broken system.

Re:They've Always Been Pointless

[owlstead]

SSL certificates only provide the ability to encrypt communication between a browser and a server. That's all it's for.

No they are not. They are for providing authentication. You would not need any certificates to encrypt communications. Of course, you can then do a man in the middle attack, but you can only get around that by authentication anyway.

Alas, many people have have tried to build in some level of 'trust' to SSL as well, and the money racket that has grown up around issuing SSL certificates on an ad-hoc basis just so someone's browser doesn't complain needs to go the journey.

This has indeed be identified. There are a couple of things with that. 1) SSL certificates are, normally, just issued to the owner of the site. That already provides some security. 2) you can get certificates that provide more trust nowadays.

Those root certificates in your browser are just money for old rope. We definitely need something better.

I'm not so sure that the current SSL certificate scheme could not be fixed. Just saying we need something better does not fix anything.

People could e.g. vote for SSL certificates for a specific site (same as PGP uses certificates signed by many persons to create trust). Another idea is to very clearly notify the user when a previously unused root certificate is used (I'll get suspicious when a banking site suddenly uses the [insert suspicious country of choice] certificate for its root. An option to display changeover of server certificates may also be a good idea.

Especially if you try and trick users on a large scale, it only takes one person to alert the authorities that something is amiss.

Re:They've Always Been Pointless

[segedunum]

No they are not. They are for providing authentication.

SSL certificates do not provide authentication on any practical level, but many people think that they do. That's the point.

Re:They've Always Been Pointless

[owlstead]

What do you define as "practical level" ? Are there *that* many attacks on the system? I see a lot of infected client and host systems. I see a lot of phishing going on. What I personally don't see is a lot of MITM attacks on SSL.

I do think that the system could be (greatly) improved. What I don't see is the whole SSL certificate system as being pointless.

Government CA's

[Anonymous Coward]

This isn't any news.. The Dutch government got it's root certificate imported in all popular browsers (named Staat der Nederlanden CA). So they can issue a certificate for a site and no browser would warn you about a invalid certificate or something..

Banking secrecy laws

[ArsenneLupin]

Not a theoretical concern, but a very real one.

Many European countries (Germany, Belgium) now have electronic identity cards, which double as PKI signing tokens, with which you can authenticate yourself to web services, such as your bank.

When Luxembourg introduced a similar system they didn't piggy back it on an id card, but issued "signing stick" and smart cards just for the purpose of PKI.

You may wonder why, especially since an electronic id card is already in planning in Luxembourg as well.

The answer is obvious: many customers of Luxembourgish banks are foreigners, couldn't thus get a Luxembourgish id card, but wouldn't trust their own government's id cards, so an ad-hoc system was needed: Luxtrust.

Unfortunately, Luxembourg doesn't have any native smartcard industry, so they had to buy the chips from the French... who just shipped units with a predictable random number generator, dramatically reducing the number of possible private keys. FAIL.

And the BSI institute (which "certified" the cards) "overlooked" this weakness, because the Germans too have a vested interested in spying on communications with Luxembourgish banks. DOUBLE FAIL.

Re:Banking secrecy laws

[owlstead]

"And the BSI [www.bsi.de] institute (which "certified" the cards) "overlooked" this weakness, because the Germans too have a vested interested in spying on communications with Luxembourgish banks. DOUBLE FAIL."

That's a pretty serious accusation - personally I would put this strictly in the "paranoid scheming" box unless you've got anything to back up that claim.

Re:Banking secrecy laws

[Anonymous Coward]

So they just overlooked it instead of "overlooked" it then? Doesn't sound much better.

Re:Banking secrecy laws

[Cyberax]

Are you sure they haven't just shipped Debian on these sticks? :)

Re:Banking secrecy laws

[TheMidget]

It's interesting how the public perception of the various countries is different.

You can suggest that the French can slip a backdoor into their products to compromise a neighboring country, and nobody bats an eye.

But if you suggest that Germany may deliberately overlook a backdoor, everybody is outraged, Germany is a serious country, they don't do that.

... all the while, in recent news, it was Germany (not France) who bought CDs full of stolen Swiss bank customer data, thus encouraging Swiss banking employees to not only violate their terms of employment, but also the laws of their country!

Yet, it's France that gets the bad rap. I wonder why that is...

Re:Banking secrecy laws

[owlstead]

Personally, I don't give France a bad rap at all (unless it has got something to do with their previous nuclear decisions).

I'm just saying that suggesting that BSI, a company that is credited for giving out Common Criteria certifications, is involved in counter-espionage requires at least some indication of guilt on their part.

And they would be doing this by deliberating slipping through a bad implementation made by a (largely) French company - for their next door neighbor Luxembourg no less? And then they are going to listen in to the connections of the citizens just to do - well what exactly?

I'm in no doubt that this is physically possible, but it scores pretty high on my bull-shit-o-meter.

Re:Banking secrecy laws

[he-sk]

Interestingly, the Swiss High Court in Lausanne ruled in 2000 that Swiss tax authorities can use "stolen" data to prosecute tax evasion. Similarly to the recent case, the Germans got hand of a CD-ROM containing incriminating banking information and then forwarded data about Swiss citizens to the Swiss authorities.

Source (in German): http://www.sueddeutsche.de/politik/825/502064/text/

Re:Banking secrecy laws

[Anonymous Coward]

And then they are going to listen in to the connections of the citizens just to do - well what exactly?

Find tax evaders, of course.

Quis custodiet ipsos custodes?

[Bearhouse]

I think we've had this debate on /. before, no?
Who do you trust to issue certs? Certainly not Verisign...the UN, then?

no duh

[Sloppy]

Nobody would ever seriously say that x.509's single point of failure for trusted introducers is a good idea; it just happened to be easy to deploy and got some encouragement along the way because some people could make money on it. But as soon as you look at it in terms of security, it doesn't fare very well.

OpenPGP encourages multiple certifiers for an identity: so they're all required to conspire to sell you out. Conspiracies are hard. Build your next network app on top of Gnu TLS and make sure you test with OpenPGP, so that some day we can switch to modern (and by modern, I mean about 1990-level tech) crypto.

BTW, governments are a great example, but always remember that they are not the only entities with capability or motivation to point a gun at someone. And even if you don't believe that, you've got to admit there are multiple governments, and only one of them at most, is accountable to you. Anyone who says that the cert system should be left vulnerable because the public has an interest in making sure that communications aren't "too secure," definitely isn't thinking about all the angles. The inherent weaknesses of X.509 should never have been used as an argument for building the web on it.

Re:no duh

[Bearhouse]

Agree.
BTW, I thought that X.509, (OK in later versions), could support WOT topologies?
Was just not implemented that way; presumably because central authorities liked the 'simple' hierarchical structure...
Of course, regarding 'too secure' systems, look what happens to people who promote them...
http://en.wikipedia.org/wiki/Philip_Zimmermann#Criminal_investigation_by_US_Customs

So trust the CAs a little less

[johndoe42]

There a "fix" that should help a lot: have browsers cache all certificates that they've accepted. Then, whenever a site *changes* its certificate, give a bit fat warning and optionally send the new certificate to some repository of questionable certificates.

If that repository starts to see bogus certificates signed by a CA, revoke that CA's root certificate.

To really make it work, HTTPS should have a mechanism to indicate that a certificate may not be changed until such-and-such a time, and there should be a way to (later, when using a different internet connection) tell a website what certificates you've seen that claim to identify it. That way the web site operator can go after bad CAs itself.

Re:So trust the CAs a little less

[rufty_tufty]

But then don't you need a CA for that repository?
What happens when that starts to fail?

I call bullsh*t

[Sardonis]

Quoth the website:

Distribution of encryption keys and code is performed with a Patent Pending process that is immune to man-in-the-middle attacks

Does NOT use SSL or third party certificates.

Can't do authentication without some trusted authority or web-of-trust. I'd like to see this 'Patent Pending process' examined by experts...

Re:I call bullsh*t

[bbroerman]

I am looking forward to that. Unfortunately, as a one man shop, I don't have the money to pay experts. I am offering free licenses to the library (with the applicable NDA) for the first 20 or so medium size businesses that want to give it a trial run. I am also working with the company that I work for (my day job) to see if they will sponsor the testing / trial of the software with some of their clients. Additionally, I have many software professionals as friends whom I have asked to do code reviews and in-house trials.

Re:I call bullsh*t

[Sardonis]

Thanks for your response. I hope the patent gets issued soon, so I can read it. No serious expert will probably touch your procedure as long as it is secret. What is the point of reviewing a protocol/procedure if your peers can't check your work?

Re:I call bullsh*t

[bbroerman]

well. I've put a LOT of hours into this, and I would really like to reap some benefit from it... I do FOSS from time to time, and I've put some things out there over the years, but this one is one I'd like to get something back out of... I have trusted peers checking my work currently. I am looking for some security experts (and in the mean time, I'm reading all of the security books I can get) that will do it at no or minimal cost.

Re:I call bullsh*t

[david_thornley]

Okay, so how many security experts will put in serious work just to make money for you? If what you're doing is any good, then it will take a lot of work to examine it for weaknesses. They will doubtless want to bill you at their usual rates. At the end of that, at best, what you'll have is a statement that Joe Security Expert couldn't find a serious problem in as many hours as you're willing to pay for, and that's not going to convince anybody competent in the field.

The only way anybody is going to take this seriously is if you publish all the details. That way, anybody who wants will be able to analyze it. Whether they'll bother for a new protocol that costs money to implement is another question.

At that point, there will be a new patent-encumbered protocol available, with very limited use because the security community isn't going to examine it in depth until it's either in heavy use or open for free use. (If it starts getting used, the cracker community will be happy to examine it, but they don't publish in the same journals.)

Sorry, guy, but your chances of making a noticeable profit from royalties is really slim. You might do better publishing openly and doing consulting.

Re:I call bullsh*t

[bbroerman]

Well, I've got a year to see. If I don't get anything in that time, I've already planned on releasing it as FOSS. Who knows, maybe a company will see it, like it, and buy the rights. Oh, and I already do consulting. Have been for years.

Story misses the point

[Old97]

The fact that governments can use or abuse technology to spy on its citizens is not news. That's as newsworthy as saying that if I had possession of your computer long enough I could find out all your secrets. If you want protection from your government, you have to do something about your government. In democracies you have some options and generally have laws and the rule of law (mostly). In such countries being vigilant and vocal can make the government behave if enough citizens participate. In autocratic countries you have to expect the worst I suppose and try to work around it. Which ever is the situation, you can't trust technology, especially one relying on a shared infrastructure (e.g. internet, ca's, etc.) to safeguard your secrets from everyone, especially anyone who has physical access to it.

Re:Story misses the point

[JesseMcDonald]

If you want protection from your government, you have to do something about your government.

Even assuming this were a practical solution, what about all the other governments out there, and the CAs within their jurisdictions? It only takes one CA caving to one government—not necessarily yours—to circumvent the trust authentication for any site.

Re:Story misses the point

[Old97]

True. It's also possible that non-government organizations could corrupt a CA for their purposes. My point is that the issue really isn't governments, it's the vulnerability of the entire scheme. Governments will spy. Criminals will spy. That's a given. If you can't secure against physical access to key components of the shared infrastructure or the end points you rely on then you have a vulnerability.

Re:Story misses the point

[psydeshow]

Let's say Liechtenstein controls a CA that is trusted by your browser. They can issue a fake cert for mail.google.com and happily MITM all your GMail connections provided they can rig your hosts file or own your router.

As we all know, there is very little you can do about the Liechtensteiner government.

Re:Story misses the point

[Old97]

Let's say criminals in Russia compromise a CA site in the U.S. by bribery or threats. You're a lot worse off then you would be with the nefarious Liechtensteiners on your tail. (Like who would care?) The point is that if the CA is compromised by anyone you have a problem.

Paranoia is all well and good...

[DrgnDancer]

Essentially if you really want secure end to end communication with someone that is more or less fool proof and not subject to outside interference you have to manually exchange keys. It's always been this way. Any time you do less you are trusting *someone* other than yourself and person at the remote end. The simple point is that we *have* to trust someone to exist in society. We trust that the government will not suddenly decide to print "Braquats" and declare Dollars (or Pounds, or Euros, or whatever) useless. We trust that the bank won't wander off with all our money. We trust that our ISP isn't just putting up servers that pretend to be the Internet and are slowly stealing everything we type into our browsers. We trust that the grocery store hasn't poisoned all the produce. Virtually every social action we take involves some modicum of trust that the "other guy" is acting in reasonably good faith.

Thus far the certificate authorities have been trustworthy. Could they be compromised? Of course. Could the clerk at the grocery store be bribed to poison all the produce? Of course. Do we have any reason to think the CAs *have* been compromised? Not that I'm aware of. It's pretty straightforward. Are you doing something that needs to be *completely* secret? Exchange keys with the remote end manually. Are you doing something that needs to be as secret as one can reasonably expect while still dealing public entities? Use the CAs. They have an extremely good track record and seem to be about as trustworthy as anyone can reasonably expect.

Re:Paranoia is all well and good...

[0123456]

Do we have any reason to think the CAs *have* been compromised? Not that I'm aware of.

The fact that someone's selling a box allowing MITM attacks with forged keys is a little bit suspicious... and since there are now so many CAs around the world it should be easy for governments to find one who'll happily sign a fake key for them, or set up trustuswerefromthegovernment.com as a new CA to sign any key they want.

Re:Paranoia is all well and good...

[pixelpusher220]

Thus far the certificate authorities have been trustworthy.

not exactly, we only don't know that they haven't been untrustworthy. There's a pretty big difference.

Re:Paranoia is all well and good...

[aaaaaaargh!]

Are you doing something that needs to be *completely* secret? Exchange keys with the remote end manually.

That is utterly misleading. There is no such thing as complete secrecy. It is also wrong to ask yourself: Do I trust this entity unconditionally? You should only trust an institution conditionally. It all depends in what you're using the encryption for. Can you trust CAs for financial transactions? So far, apparently yes. Can you trust CAs with your international trade secrets as a non-US company? NOT a good idea. If you have a relatively secure side-channel for key exchange and are a non-US citizen with trade secrets, it's better not to rely on SSL for your communication but on your own certificates. You wouldn't trust SSL for the transmission of secret nuclear missile launch codes either, would you? The trustworthiness of institutions and protocols depends on case-by-case evaluations and the stakes at hand, and this has absolutely nothing to do with paranoia.

Re:Paranoia is all well and good...

[Xylantiel]

... you have to manually exchange keys.

No. You can get most of the way there with a model like that of PGP: if multiple entities that you trust have vouched for the this one, then you have some confidence. This is what the "web of trust" is all about. The CAs fail both counts -- multiple trust paths are not required and why should I trust any particular CA? The article is just pointing out another reason to not trust the CAs.

With real PKI management I could choose for any particular communication whether I trusted the CAs under the jurisdiction of a particular government. But the truth is that such a level of security is rarely necessary in an absolute sense that can't be "repaired" later by, for example, legal remedies.

Re:Paranoia is all well and good...

[dkf]

Can you trust CAs for financial transactions? So far, apparently yes. Can you trust CAs with your international trade secrets as a non-US company? NOT a good idea. If you have a relatively secure side-channel for key exchange and are a non-US citizen with trade secrets, it's better not to rely on SSL for your communication but on your own certificates.

You're highly confused as to just what a CA does. All a CA really does is make statements about identity. They don't say anything about the cryptographic algorithms being used. They don't say anything (much) about how you use the certificates they issue.

Who can be a CA? Anyone! (Well, so long as they can stand using the software tools. The openssl ca command is pretty horrible.) The only constraint is that browsers won't trust you by default; you'll have to add these custom CAs' certificates manually, and that's only a good idea if you trust the policies of each CA that you add. If you remove all the standard CAs and add in your own for your small group, you've got just as much control as you might ever wish for. (The alternative is to do lots of bipartite key exchange, but that really doesn't scale well. A web-of-trust isn't any more resistant either - people make mistakes and can be corrupted - and remembering-first-certificate has many of its own faults as a rule.)

I'm not very surprised that you're spreading misinformation though. If you've never tried to run a private CA or work out what the protocols actually do for you, you'll be susceptible to magical thinking. Lose 5 geek points for looking like a dumbass about a technical subject.

Re:Paranoia is all well and good...

[Anonymous Coward]

In fact, you're spreading misinformation and you know that. ;-) I was talking about trusting root CAs to prevent a man in the middle attack.You can't trust them for certain usage scenarios, that's a fact. (It's okay for me if you or the OP trust them, though.)

A couple interesting quotes I've seen about CA's:

[rwyoder]

"A CA will protect you from anyone from whom they won't take money."
-- Paul Vixie - on the NANOG mailing list
(Going from memory here, so the quote may not be exact.)

"In the real world, you prove your identity with documents provided by a government.
In the digital world, why are we trusting certificates provided by 3rd-party business???"
-- a former coworker

Told you so

[ugen]

Here is a link to my own reply previously: http://slashdot.org/comments.pl?sid=1534366&cid=31004066

To summarize - I don't see how the "trust system" has any meaning. I don't actually know anyone at those 160+ companies and I sure as hell don't *trust* any one of them, not as far as I can throw them.

In fact, I don't really trust anyone :) and based on that - see no reason that my SSL connection is more or less safe whether the cert for counterparty is signed by a "good" or "bad" CA. Frankly, I trust my bank or Google mail even less than a CA - so what exactly is there to protect?

"Is SSL becoming pointless?"

[John Hasler]

Only a fool would rely on SSL based on the certificates that come with a browser to protect against government. That isn't what it is for. While I object to government snooping in principle (I object to pretty much all government activity in principle) I really have nothing to fear from the NSA learning what parts I am ordering from Jameco. Firefox, HTTPS, and Perspectives provide adequate assurance that I am communicating with the company I intend and that some clerk at some ISP can't snoop my credit card number. For more important stuff I have GPG.

Self-signed certs are now more secure. Silly.

[X.25]

Use self-signed certs. I am not talking about being more secure when doing online shopping and other silly things, but for personal/company usage.

For example, if I create my own CA and sign my own certs for my mailserver, I will import my CA cert (or accept cert once, on 1st mail retrieval, although more risky), and no matter what certificate government puts when doing mitm - I'll get a warning.

But if I buy a cert from Verisign and think that I am totally safe now, I would never get any warnings if government inserts their own certificate (generated on-fly by using Verisign issued intermediate cert with CA=TRUE constrain set, for example, if I remember the mechanics right :), when doing mitm. Can be done with sslsniff, if I remember correctly (been a while since I bothered with SSL/TLS stuff)

And government won't be able to get a cert issued by my own CA, so they won't be able to get past the checks, and I will eventually get a popup when any of their certificates show up.

I think this was a known issue since 2002 or so (look up Moxie's work).

What about a DNS TXT record with hints?

[DdJ]

So the problem is that two different CAs could issue certs for the same host, and some have essentially back doors?

Know what I'd like to see? How about a DNS TXT record that tells you what the real, trusted CA for a given site is? Like, let people assert "for my domain, do not trust any certs unless they come from this particular CA", using DNS as an out-of-band channel that would have to be compromised separately from the SSL negotiation.

Wouldn't that be relatively easy to implement (for those who care to), and reasonably effective against anyone who can't compromise the root DNS servers?

Re:What about a DNS TXT record with hints?

[Anonymous Coward]

because DNS is certainly a secure system

Re:What about a DNS TXT record with hints?

[Anonymous Coward]

Anyone who is powerful enough to stage a MitM can inject fake DNS responses to you.

That's what Government is supposed to do...

[mi]

Enforcing the Law — using, among other things, eavesdropping on communications — and prosecuting wars, are practically the only things, a government of a free country is supposed to do. Because no one else can be allowed to do these things...

Everything else — and I do mean everything: elementary and higher education, personal retirement, health care, communications, transportation — should be left to the competing enterprises. If only because they are much easier to switch from one to another, than it is to change the government...

There's a simlpe way to do this yourself.

[DamnStupidElf]

Disable trust in the root certificates so that your browser always prompts you to verify an SSL certificate until you mark it as trusted. The first time you visit a site, hit it from a few different IP addresses and make sure the SSL cert matches on all the different connections to rule out a MITM attack, then verify the chain of trust up to the now-untrusted root CAs. If you think you can still trust whichever root CA signed the cert, mark the site's cert as fully trusted and the browser won't bug you until the cert changes (either due to legitimate replacement or a MITM attack).

Of course this is mostly a moot point because just about any company will happily comply with law enforcement requests to intercept your connections through a legitimate SSL session.

Certificate Patrol

[hile]

While not a perfect solution, this https://addons.mozilla.org/en-US/firefox/addon/6415" for firefox helps a little bit: it stores the certificates to a sqlite database in your profile and warns if the certificate changes.

If you get mitm on the first connection, you still have a problem, but the extension can at least detect if someone is trying to do it in future...

Provable

[fulldecent]

A single false, signed certificate from anywhere provides undeniable cause to revoke a CA from all browsers.

Re:Provable

[Burz]

A single false, signed certificate from anywhere provides undeniable cause to revoke a CA from all browsers.

A very good point. However, there is no reason why a privileged attacker (e.g. a government or an insider) couldn't use the fake certs sparingly in a targeted manner.

Further, the CA in question could be any of the relatively minor ones who may have more interest in cashing out with a large government entity and getting revoked than in continuing to run a small CA with little revenue.

About time

[Anonymous Coward]

I've been crying foul about this for years, and get flame-modded every time. But even here, the researcher missed the issue. If I'm going to wiretap somebody, I'm not going to freaking request a fake key for the domain. I'm going to request the CA's signing key, and *issue* a fake certificate for *EVERY* domain my target goes to. Maybe their first connection times out at times for some reason...whatever...DNS hickup.

Most of the math can be precomputed anyway--the average user would never notice.

My only question is given that somebody "reputable" finally "published" this vulnerability, will firefox finally take self signed keys seriously? Because their attitude in recent releases is freaking disgusting. Just give me a tool to know when the key changes already--and give me some extra cautions if it changes outside a specific window of its expiration date.

Mechanisms exist to prevent these "attacks"

[Halo-]

A lot of these "attacks" can be prevented by properly implementing your PKI. For example, some of the articles (and several commenters) make mention of "using a Root CA to generate sub-CA's which then generate rogue certs". Sure, the system allows this to happen, but it also provides constraints to prevent it. One of usual "basic constraints" (which is an X.509 attribute) of a certificate is: "Max path length" which means: "how deep can a signature chain extend from me, if I am trusted" For most people, there should never be a trusted CA in their keystore which has a max path length greater than 1. (Meaning it can vouch for others, but those others cannot vouch for a second level of trust).

Additionally, all X.509 certificates contain a "Key Usage" field, which specifies what the key can be used to validly sign. For most people, they should never have a certificate in their root store which has the "CA signing" bit set. This is another way to prevent a "trusted" CA from creating a rogue CA which can then issue bad certs.

Finally, there are multiple methods for checking if a certificate is still trusted as part of a regular, ongoing, and sometimes even per-use basis. (OCSP, CRL, etc...) In the past, when I worked on PKI's, these often weren't implemented, but increasingly they are today most browsers support them. (Which is not to say browsers are the only users of X.509 certs.)

What this should mean is that as soon as evidence emerges that a formally "trusted" CA has done something shady, it can quickly be disabled in the field.

In a perfect world, a CA should be sufficiently incented by the threat of being "revoked" via OCSP or whatever that it would never entertain the idea of creating a rogue cert. Imagine the pressure on a large CA like Verisign if they got a root cert yanked. Suddenly ALL of their customers get labeled as compromised.

NSA has lots of CPU power

[Anonymous Coward]

The NSA has lots of CPU power. What makes us think they need the CA's cooperation to spoof a cert? That's so 1990's thinking.

No kidding.

[Anonymous Coward]

Most of these people just don't get it. The other obvious clue is that the entire PKI infrastructure was created and put into motion by the NSA. I mean, duh.

About f*cking time

[Yvanhoe]

This whole CA thing is based on a hierarchical chain of trust, you can't keep it invisible for long. All certs are not equally trustable. We shouldn't get used to assimilate the "secure" icon to a completely trusted user, but just as a second grade security that our (incompetent) banks rely on. When they are not simply using http...

SSL is great for protecting credit card numbers

[einhverfr]

Let's face it, the primary application of a trusted CA is to protect credit card numbers in ecommerce transactions. This is a great technique for that, and is in fact, well designed for that application. BTW, the government wouldn't even have to forge an SSL certificate. The basic premise of SSL assumes the secrecy of certain things. If the government could compel the CA to provide the certificates and keys, they wouldn't even theoretically have to do a man-in-the-middle attack but could circumvent the anti-eavesdropping elements of SSL entirely.

However, if you are trying to protect data which is different, and may be considered sensitive in this context, this constitutes a larger issue. At that point you basically have a few options, but they all involve running your own infrastructure.

Corrupted CAs ? What's the point paying them ?

[Thanatiel]

Do I understand correctly that Verisign has been corrupted ?
If it is true, it means that Verisign authentifed certificate aren't worth zlicht.
It's a good thing removing a CA from the CA root is a simple enough thing to do.

I'm particulary glad my "secured" sites are using a CA I generated (on a non-networked computer) and that I distributed to the users.

So let's fix it

[ecloud]

Firefox and webkit and apache are extremely popular. Why not introduce a new security model, just for that combination at first, in which the browser holds the private key, encrypts the submission with it, and sends the public key to the server with which to encrypt the response, on top of using a server-side key at the same time? And augment that with a chain-of-trust model in which you can see how many of your friends (people you know personally and trust) have accepted that particular server-side cert as valid. Or any other such techniques which I don't understand because I'm not a security wonk. :-) Anyone with some clout in the community (Mozilla and/or Apache forefathers) could easily make something like this happen, since free software projects are in control of both ends. In that light I don't see why this wasn't fixed long ago.

"Just use SSH" could also be an answer for the web as well, but maybe it's better not to put all our eggs in one basket.

With fingerprint verification

[Burz]

a self-signed cert becomes more trustworthy than a CA-verified one.