Transitioning to universal HTTPS (2)

| Comments (3) | COMSEC
In my original post on Loren Weinstein's suggested adoption of universal HTTPS, I said that MITM attacks were a issue I would address in a separate post. This is that post. As cryptographers and COMSEC engineers never tire of pointing out, if your channel isn't authenticated then you're very vulnerable to active attackers. The classic attack is what's called a man-in-the-middle 1 (MITM) attack, but in general the problem is that you can end up talking to the attacker when you think you're talking to the right person. There are a lot of proposed solutions for this, but the only one that really works when you're trying to talk to someone you don't know is to have someone you do know (or at least trust) vouch for them. In TLS this is done with certificates, and the third party you trust is the certificate authority.

Whenever this topic comes up, you hear a lot of complaining about the difficulty and expense of obtaining certificates. For instance, here's Weinstein:

Certificates are required to enable TLS encryption in these environments, of course. And while the marketplace for commercial certs is far more competitive now than it was just a few years ago, the cost and hassle factors associated with their purchase and renewal are very relevant, especially for larger sites with many operational server names and systems.

It's certainly true that certs are an obstacle, though not as big an obstacle as people think. You can get a certificate for as little as $9/year. It's a little inconvenient, but it wouldn't be hard for Web hosting providers (who typically charge rather more than that) to simply issue you a certificate (or work with a CA to do so) as part of your Web site setup. But still, this is obviously more inconvenient than not doing anything. So, do you need a certificate at all? Here's Weinstein again:

However, in a vast number of applications where absolute identity confirmation is not required (particularly when commerce is not involved), self-signed certificates are quite adequate. Yes, as I alluded to in my previous blog posting, there are man-in-the-middle attack issues associated with this approach, but in the context of many routine communications I don't feel that this is as high a priority concern as is getting some level of crypto going as soon as possible.

Given their significant capabilities, why then are self-signed certs primarily employed within organizations, but comparatively rarely for servers used by the public at large, even where identity confirmation is not a major issue?

A primary reason is that most Web browsers will present a rather alarming and somewhat confusing (for the typical user) alert as part of a self-signed certificate acceptance query dialogue. This tends to scare off many people unnecessarily, and makes self-signed certificate use in public contexts significantly problematic.

Security purists may bristle at what I'm going to say next, but so be it. I believe that we should strongly consider something of a paradigm shift in the manner of browsers' handling of self-signed certificates, at the user's option.

When a browser user reaches a site with a self-signed certificate, they would be presented with a dialogue similar to that now displayed, but with additional, clear, explanatory text regarding self-signed certificates and their capabilities/limitations. The user would also be offered the opportunity to not only accept this particular cert, but also to optionally accept future self-signed certs without additional dialogues (this option could also be enabled or disabled via browser preference settings).

This topic has been debated endlessly on mailing lists, so I have no intention of detailing all the arguments. Instead, here's the bullet point version.

For

  • Active attacks aren't a major issue anyway, but passive attacks are, and you can use SSH-style leap of faith (remembering the server's cert) to block most active attacks.
  • What's important is to get people to use any crypto at all, and this whole certificate thing is an impediment.
  • Self-signed certs can be made to install automatically with the server.
  • In the real world, certificates are often screwed up in some way and people already ignore that.
  • Certificates are practically worthless since the CAs practically don't check who you are (the standard thing is to force you to respond to an email send to an admin address at your domain).
  • Many of the important attacks (e.g., phishing) aren't even detectable by certificate checks because the certs are right.

Against

  • What do you mean active attacks aren't important? This is an active attack we're looking at right here.
  • It's true that the certificate thing is an impediment, but that's really a social and engineering issue. Given how cheap certs are and how little checking the CAs do, cert issuance could easily be practically automated.
  • Encouraging people to accept self-signed certs undermines security for all the sites which want real certs—all the reasons why people don't check certs go double for why they won't check that the cert is not self-signed if they see both cases a lot and there's no way to tell what kind of site you should expect to talk to.
  • If you want to encourage the client authors to do something, encourage a free CA (like OpenCA used to be) that does simple email checking. At least that has the same security model as self-signed certs.

This doesn't really cut in either direction, but another possibility is to reserve the https: URL scheme for real certs but to have clients auto-negotiate SSL/TLS silently where possible (like RFC 2817 but done right). This at least gives you channel confidentiality, and if you cache the fact that you negotiated SSL/TLS, then some active attack resistance.

Note that an active attacker can of course downgrade you to straight HTTP (who knows how people respond to whatever warning accompanies "hey, I just negotiated HTTP even though before I was doing HTTPS?") but, then, they could MITM self-signed certs and Weinstein's argument that they won't:

Any ISP that was caught playing MITM certificate substitution games on encrypted data streams without explicit authorization would certainly be thoroughly pilloried and, to use the vernacular, utterly screwed in the court of public opinion -- and quite possibly be guilty of a criminal offense as well. I doubt that even the potentially lucrative revenue streams that could be generated by imposing themselves into users' Web communications would be enough to entice even the most aggressive ISPs into taking such a risk. But if they did anyway, the negative impacts on their businesses, and perhaps on their officials personally as well, would be, as Darth Vader would say, "Impressive. Most impressive."

seems kinda shakey to me.

1. Amusingly, the Wikipedia entry on Interlock, a protocol designed to stop MITM, reads in part:

Most cryptographic protocols rely on the prior establishment of secret or public keys or passwords. However, the Diffie-Hellman key exchange protocol introduced the concept of two parties establishing a secure channel (that is, with at least some desirable security properties) without any such prior agreement. Unauthenticated Diffie-Hellman, as an anonymous key agreement protocol, has long been known to be subject to man in the middle attack. However, the dream of a "zipless" mutually authenticated secure channel remained.

As far as I know, this use of the term "zipless" comes from Erica Jong's novel Fear of Flying, where it refers to a somewhat different type of interaction.

3 Comments

Another issues with certs is that the way they're designed they don't play nice with vhosting - servers frequently provide cert information before they've gotten the host header (whether this is a protocol problem or a malimplementation I'm unclear).

In any case, kudos to the suggestion for adding silent self-cert protocol negotiation to plain old http. Having https be a separate protocol running on a separate port is just plain stupid, and has been a pain in the ass since day 1. One of those completely typical amateurish screw-ups which make their way into internet protocols because the people who design them are frequently not experts at all.

Irritatingly, Perry Metzger wouldn't even let me post a comment on the old coderpunks list arguing in favor of security being added to http, on the grounds that it would be a huge pain from a systems standpoint. He was of course wrong, it's annoying from a software programming standpoint, and trivial from a systems standpoint once that's actually done, but he was, ya know, the moderator.

The name-based virtual hosting issue was a protocol issue in the original SSLv3 design. It's been fixed in an extension which is slowly rolling out.

I have no idea what Bram Cohen is talking about. I never was the moderator of Coderpunks. I don't have any memory of coderpunks even being moderated. I do moderate the cryptography at metzdowd.com mailing list, but I have no memory of his posting something on this topic -- or any other for that matter -- and I generally block messages only for redundancy or being off topic, almost never for disagreements about technical content.

Leave a comment