Decentralized SSL Observatory
February 29, 2012 7:32 PM   Subscribe

EFF's HTTPS Everywhere v2 adds support for Chrome and adds Decentralized SSL Observatory to the FireFox version,

SSL Observatory helps cryptographic researchers find implementation problems and now warns users when known problems are detected. And it plays nicely with Tor of course.

There is another interesting EFF project in the works called Sovereign Keys that seeks to replace the certificate authority system entirely, which has proven leaky. It appears the EFF aren't the only ones looking to replace the certificate authorities.
posted by jeffburdges (18 comments total) 18 users marked this as a favorite
 
When is Metafilter going to move to https?
posted by humanfont at 8:05 PM on February 29, 2012 [9 favorites]


I'd also like to see metafilter made available via HTTPS (I was trying to build a HTTPS Everywhere policy for mefi earlier this week when I realized it wasn't even an option on most pages).

Regarding the CAs themselves... I'm not a cryptographer by any means, but it seems apparent to me that they form a single point of failure in the system, and over the last couple years they've been failing well and often. I heard that, last April, the US Army shipped a 30 million record CRL - that seems like an untenable system. Not to mention the number of browsers and applications that don't even honor a CRL or otherwise check certificate validity.
posted by These Premises Are Alarmed at 8:18 PM on February 29, 2012 [1 favorite]


humanfont: pretty much never, per several MeTa threads.
posted by indubitable at 8:37 PM on February 29, 2012


I was thinking about how to get around the "man in the middle" attack. In theory, if they stand in between you and a source, they can modify whatever they want. But they have to know to look at (and replace) a piece of data. That means you could theoretically use some kind of Steganography. But that only works if you know the steganographic algorithm and they don't.

Here's another option though: You could setup a system to automatically share your copy of the root certificates using your cellphone. So if you pass some random person on the street, you're phones will verify with each other that they have the correct root keys. Then when you get home, your phone syncs with your computer and everything is verified.
posted by delmoi at 8:40 PM on February 29, 2012


humanfont: "When is Metafilter going to move to https?"

Seeing as SSL can add some drag (processor usage) to server loads, probably never (no I don't really read MeTalk).
posted by Samizdata at 9:03 PM on February 29, 2012


Should All Web Traffic Be Encrypted?

Maybe not tomorrow, maybe not next year, but over the medium to long term, adopting encrypted web connections as a standard for logged-in users is the healthiest direction for the future of the web. We need to work toward making HTTPS easier, faster, and most of all, the default for logged in users.

posted by gen at 9:16 PM on February 29, 2012 [2 favorites]


Seeing as SSL can add some drag (processor usage) to server loads, probably never (no I don't really read MeTalk).

In modern stacks with modern machines there is negligible hit for CPU usage, most of that cpu usage being taken on session initialization. In practical terms there is very little impact from running SSL on a resource utilization perspective.
posted by iamabot at 9:33 PM on February 29, 2012 [3 favorites]


HTTPS support for MetaFilter content seems like the perfect feature to make available only to members that paid their $5.

Actually, HTTPS support for MetaFilter content seems like the perfect feature to make available only to those members that were here before Matt started charging $5.
posted by birdherder at 9:34 PM on February 29, 2012 [1 favorite]


Yeah, the CPU load for SSL on MeFi would be totally negligible compared to the ColdFusion backend

The Sovereign Keys proposal is the real meat here:
In the Sovereign Key design, certificate warnings are unnecessary. For websites that chose to publish a Sovereign Key (more on how you do that below and in the design docs), the web browser or email client will never show a certificate warning. Instead, if an attempt to connect over TLS results in a session that isn't cross-signed by the Sovereign Key, the browser can automatically circumvent the attack. The strongest way to do this is to compute a hash of the Sovereign Key, and use that as the .onion address of a Tor hidden service. It is also possible to use proxies or VPNs for weaker versions of this protection (in a later post we'll talk about why it's better to use Tor hidden services for this purpose). Because these methods may be slow, the user can be shown a message along the lines of "Experiencing difficulty establishing a secure connection to this site. Give us a moment while we try harder...", with a nice friendly spinning hourglass or beachball, or better, a realtime depiction of the progress of attack circumvention process.

If, after an attempt at circumventing attacks, the browser still cannot establish a verified connection to the server, it reports an error indicating that the server is unreachable.
This is long, long overdue and would kill about 10 birds with one stone. Everyone and their mother knows that the current certificate authority system is a complete racket - a handful of companies cashing out by sprinkling their oligopolized holy water over a bog standard encryption keypair, resulting in a bizarre and needlessly complicated and insecure world for everyone

I thank [deity] practically every day that there's organizations out there like the EFF and Mozilla that are very consciously working towards an internet and web that's decentralized, secure and resilient. They are very aware that the great inertial forces of the world are trying very hard to gain levers of control over the internet now that they've realized it's importance, and tools like this are a way of using technology to change the rules of the game

If they're ultimately successful, within 10 years nearly every person on earth will spend most of their day in close proximity to a device that gives them uncensored, unfiltered access to get and share whatever information they want with whoever they want - to organize and cooperate remotely, privately, instantly. If a government decides their people can't have that right, they'll no longer have a line-item veto - oh, you get most of the internet, just not these sites. Just not these files. Just not pages with these words. The technological reality will dictate that pulling the plug on the whole thing as hard as they can will be the only option - a free internet or no internet - and we all saw how that went down in Egypt in 2011. By 2020 it would probably be like shutting the power off: an act of obvious government suicide

I'm not quite sure most people yet understand how powerful a truly decentralized, anarchist internet would be as a tool for the masses
posted by crayz at 10:13 PM on February 29, 2012 [12 favorites]


Seeing as SSL can add some drag (processor usage) to server loads, probably never (no I don't really read MeTalk).

The computational expense of encrypting HTTP is greatly overestimated by virtually everyone, particularly people who have been around for a few years and cut their teeth on older hardware, where it really was kinda painful. (Myself included. Anyone else remember PCI SSL accelerator cards?) However, there are a number of real-world, large-scale HTTPS implementations which bear out the low cost of enabling encryption by default.
In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that.

If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more.
And that was back in January of 2010 -- if you have hardware that's less than two years old, it'll probably be even less of an issue, and it's becoming more and more trivial all the time.

The biggest PITA related to deploying HTTPS isn't the hardware requirements anymore, it's obtaining and managing the certificates. Even if you're part of a big organization, for whom the CAs will play nice (and they really do bend the rules for big enough organizations, especially government buyers), it's still a big waste of time to create and process the CRLs, install the certificates, and then keep the damn things up to date when they expire. And the amount of money that the CAs charge for their "service" is often somewhere between ridiculous and extortionate. The latest cash cow seems to be wild-card certs; why these ought to be more expensive than a regular cert is beyond me.

So if we can provide some sort of alternative to the CA system, modern hardware has already eliminated the biggest remaining drawback to deploying transit encryption.
posted by Kadin2048 at 9:13 AM on March 1, 2012 [2 favorites]


Also, many servers have dedicated crypto chips that can handle offload of some of the math for SSL; the Servers Formerly Known As Sun have had these for years.
posted by wenestvedt at 9:39 AM on March 1, 2012


I'm not really sure I understand why this Sovereign Key proposal is superior to Moxie's Convergence project, aside from the fact that convergence is only an option for Firefox users. I really like the idea of using network perspectives and being able to to select my own trusted notaries in order to judge what is a legitimate site and what is not. Of course, I'm a "power user" (or whatever), so naturally I'd use this info to run my own notary and direct my less-technical friends to use my notary if they trust my judgement and process.

Maybe the Sovereign Keys idea is solving a different problem (or is identifying a fundamental problem that I am overlooking), but what's the incentive for a Facebook (for example) to start publishing a Sovereign Key? With a solution grounded in network perspectives, we merely need to ask other nodes what they are seeing, requiring no effort on the part of the publisher. Plus, these Sovereign Keys are written to some "semi-centralized" servers, which are verified via CA-signed certs - the same CAs that we are all hell-bent on replacing?

I like the effort, but I'm not so sure this idea is going to take off...CAs are just a bit too entrenched/embedded into the average user experience, and any solution that includes them reducing their role will be sabotaged.
posted by antonymous at 9:40 AM on March 1, 2012 [1 favorite]


CAs are just a bit too entrenched/embedded into the average user experience, and any solution that includes them reducing their role will be sabotaged.

I don't think that most users even know what a CA is, or even that they exist; they just see the little green bar that tells them a page is encrypted (if they even notice that).

The only people who like the CA system are those who actually work for the CAs themselves, and even they, I hope, feel a little dirty self-loathing when they get up in the morning. I certainly have never met any software developer or site owner who wouldn't take a giant piss on Verisign et al, unless it would somehow stop them from burning alive.
posted by Kadin2048 at 9:48 AM on March 1, 2012 [2 favorites]


I certainly have never met any software developer or site owner who wouldn't take a giant piss on Verisign et al

Pleased to meet you. I'm a software developer who doesn't hate the CA system. As long as Verisign doesn't issue two certs with the same CN, and as long as Verisign's public key(s) are distributed with everyone's OS and browser, they're doing the job we need them to do.

(Of course I've never paid Verisign for a certificate with my own money so I'm not sure how expensive they are. Is that why some people hate them?)

I have some co-workers who hate CAs, but they're only dimly aware of why we need them, and would just self sign everything if not for the "annoying warnings" the user gets with an untrusted cert, as if the warning itself is what you're avoiding, and not the fact that the user's browser could be connected to a MITM or a completely different site than what they think. I might be missing some reasons to hate the CA system, but at least I know why we need them.
posted by Pruitt-Igoe at 12:04 PM on March 1, 2012


> I might be missing some reasons to hate the CA system

There's something Kafkaesque about having to get "trust certificates" from outfits one does not in the least trust.
posted by jfuller at 1:28 PM on March 1, 2012


But you can "trust" them because you already have a copy of their public key bundled with your OS. If a website presents you with a cert for CN=ebay.com that was issued by Verisign, you can trust that they got it from Verisign, and the website is in fact ebay.com.

That's assuming they wouldn't issue a cert with CN=ebay.com to someone who wasn't ebay.com, but they have a good track record of not doing that. (Other CAs, such as TrustWave and DigiNotar, not so much).
posted by Pruitt-Igoe at 2:57 PM on March 1, 2012


Pruitt-Igoe, the point is that we should not have to rely on browser vendors - whether Mozilla, Microsoft, or Google - to make trust decisions for us. What happens if a company like Comodo gets hacked - are they allowed to continue to issue certs until their poor security practices become public knowledge?

There have been examples in the past of companies issuing certs for any old domain just because someone asked for them - what methodology are they employing to make sure they have a "good track record" anyway? There's a good talk from Moxie Marlinspike last year at BlackHat on the topic when he unveiled Convergence. It's a bit long, but it's entertaining (in a scary way) and thorough.
posted by antonymous at 3:32 PM on March 1, 2012


That's assuming they wouldn't issue a cert with CN=ebay.com to someone who wasn't ebay.com

That's a hell of an assumption to make. Keep in mind that the security of the entire CA-based system is only as good as the policies of the weakest registrar whose certificates are included by default in your browser or OS. (And if you are designing a site or application, then it's your users' browsers or OS, over which you have even less control.) So even if Verisign does its job, if any of the myriad other CAs that your system is set to trust aren't, you can potentially be MITMed. And that exposes a huge, gaping flaw in the whole model.

Bluntly, it just doesn't scale very well. To allow everyone to get certificates, there have to be a lot of CAs. When you have a lot of CAs, it's unavoidable that they're going to be compromised, or lax, or just plain lazy about verifying ownership of domains.* And when you involve money — the purpose of a CA is to sell certificates — there's a strong incentive for a bad CA to cover up their misbehavior for as long as possible.

We saw this happen with DigiNotar: they covered up an apparent root compromise (that allowed unchecked cert issuance) for at least a month, possibly longer, and it's not clear that they would have ever copped to the problem had the attackers not gotten greedy and issued a wildcard against *.google.com. If the attackers had just been targeting lower-profile domains, they probably could have gotten away with it for a long time.

It's impossible to say with confidence how many CAs that are in the trusted root store of most users' systems are compromised right now. My machine, as of right now, has 153 trusted root certificates (and this is after I manually deleted a bunch of them). How many of them are legit, and how many of them are just a credit card acceptance page tied directly into a script that signs a CSR? How many of them are running on servers with unpatched security holes? How many are run by people who owe money to someone who might ask them to generate a bogus certificate in a manner that they could not refuse? I have no idea. And neither does anybody else!** It's a crummy system that tries to do too much. CA-based SSL is overly ambitious, and this ambition — one might go so far as to say 'hubris' — to tie certificates unambiguously to meatspace individuals or organizations, to give users a binary yes-it's-perfectly-secure/no-it's-a-total-forgery result, gives it really nasty failure modes.

For forcing users to pay ridiculous sums of money in return for what amounts to a very small degree of security, the CA system deserves to be abandoned. A more limited system, which mainly tried to assure users that the site they're connecting to today is the same one that they've connected to 25 times previously this month, and perhaps that it's the same site that their friends John, Joe, Steve, and Sam and 99% of the rest of the internet have connected to with regularity, would be far better in virtually every respect.

* Or, are vulnerable to being forced by a government to issue a duplicate cert, in order for that government to intercept traffic. Verisign might be a paragon of conscientiousness when it comes to verifying Joe Customer's CSRs, but when some Star Chamber court (e.g. FISA) tells them to sign one, I suspect they'll sign. Since the CA-based SSL system doesn't have any place for certificates that are simultaneously legitimately issued and fraudulent, a user presented with one of these certificates won't ever know. This is because the whole trust model behind CA-based SSL is simplistic and flawed.

** And even if someone, presumably in charge of adding CAs to the trusted root list of browsers and OSes, did know everything about every CA on the list, down to how far in debt the sysadmins at each one might be, who precisely is keeping tabs on the people making the decisions of which CAs to include, and whether they could be compromised? Even better than compromising a CA would be to get a CA of your own added to the root store. There's a "turtles all the way down" aspect to the whole business, where users are forced to place their trust in non-obvious places, hidden far behind a green address bar or a red warning notice.
posted by Kadin2048 at 11:24 PM on March 4, 2012 [3 favorites]


« Older TEDsters   |   Avengers Assembling Newer »


This thread has been archived and is closed to new comments