5 ms·

How far away are we from being able to kill this ridiculous system? I'm sick of trusting a bunch of certs that are deemed acceptable. Forget security concerns,

How far away are we from being able to kill this ridiculous system? I'm sick of trusting a bunch of certs that are deemed acceptable. Forget security concerns, I'm just appalled that to acceptably do encryption today I need to pay some company! That's wrong. Okay, so the question isn't actually "how we're going to kill it". It's going to die when there's a better alternative. So the question is really, "What can we do to build a strong web-of-trust system while continuing to use the broken one?" I see no reason we can't make some browser plugins, get some activism going in the tech community, and start building it. Just report back what cert was served to you. With that being said, there needs to be a selling point other than building a better internet, otherwise no one will use this plugin. I think there is one, though, and that's security. When your browser comes across a cert that differs, alert the user. You might not get grandma to use it, but it's something. There are issues with this. I want to anonymously report what cert a website serves me, rather than giving anyone curious my entire browsing history. And also poisoning. But the latter is fixed by using this both the existing CA model and the WoT. So yes, there are some problems. But c'mon, it's 2015, let's fix this already.

rtpg 12y ago
I don't get how it's ridiculous. How do I know that Bank of America's website is actually Bank of America? At least I know _somebody_ checked that it was BoA who is controlling the domain. It's obviously far from 100%, but the web of trust has to start somewhere. Distributed web-of-trust works for individuals, but am I supposed to go see Jeff Beezos in meatspace before going to amazon.com? The solution is, of course, delegation. But the end result is you end up with exactly the same CA system as today!
- TheDong 12y ago
  Somebody checked that in the past, yes, but that check doesn't matter for your current connection. Your browser will accept any CA signed cert as valid for the site it's for... if a hacker hacks into a low-profile CA, not even the one that verified BoA, they can MITM you every bit as easily as if they hacked BoA's actual cert authority. The problem here is that the delegation is too broad; we're delegating verifying all websites to all CAs and assume that all CAs are absolutely trustworthy for it to work. That's ridiculous. Chrome has a sort-of-solution built on top of this with certificate pinning where the organization gets a cert from the CA, and then gives it to chrome and claims "Only this cert is valid for our site" rather than all CA's certs... Continuing with our example of BoA, this doesn't matter because they have not opted in [0] to that and in any case that won't apply to non-chrome requests. [0]: https://code.google.com/p/chromium/codesearch#chromium/src/net/http/transport_security_state_static.json https://code.google.com/p/chromium/codesearch#chromium/src/n...
  - bigiain 12y ago
    "Chrome has a sort-of-solution built on top of this" … which scales up about as far as every domain Google owns/cares about, and a few of their friends/partners/sites-that're-politically-or-business-beneficial-to-Google-to-pin. I suspect in my 20 odd years of working with ssl protected websites, there's maybe 2 or 3 sites I've worked on that hav a hope in hell of getting into Chrome's pin list. If you're outside the US Fortune500 or any other countries Fortune100, how easy is it gonne be to get Google to pin your cert? It's nice if you're Twitter - it's _never_ gonna work for mygreatcatphotos.org.au... It's useful, and a great thing they're doing, but as you say, it's _very much_ a sort-of-solution. Perhaps more like a very good two or three bandaid solution, directed at the problem of someone with 99% full body covered 3rd degree burns. "Here, I've got your left thumb and your right big toe covered!"
    - TheDong 12y ago
      They have pretty little form for it :) https://hstspreload.appspot.com/ https://hstspreload.appspot.com/ My guess is no one bothers to fill out the form due to lack of knowledge about its existence. Surely they let in more than just their friends ... though yes, I do recognize this isn't scalable.
      - geofft 12y ago
        They've been pushing back against new people preloading public key pins because it's hard to make sure that someone else understands exactly what the consequences are. (Cryptocat, notably, got this wrong.) But yes, HSTS preloading is totally open, and has been scaling as well as it's been needed.
  - rtpg 12y ago
    this is a really good point. So would a good solutioon be to divy up the delegation? Though I don't know how that could work (how would you know you're on a bank website? a .bank tld?) This is tricky, but I still don't get how decentralisation solves things, because the problem is still the same, except now it's a risk of whatever web-of-trust node you're a part of being compromised instead of a CA.
dmichulke 12y ago
Trustworthy entities (e.g, Mr Schneier and Krebs and whoever they trust) could just offer a signed list of pub-key - identity pairs which can be stored in the block chain. The amount of work needed should be pretty low, they start with the current certificate tree and they just need to update in case of a certificate incident (they probably get this info fast and the update should be easy to do via software). Probably they could sustain this service via donations.
geofft 12y ago
> Forget security concerns, I'm just appalled that to acceptably do encryption today I need to pay some company! That's wrong. Well, you don't need to pay anyone to do encryption. You do need to do pay people to do identity verification. That's a more-than-pedantic difference, even though encryption without identity verification is generally meaningless. First off, you're already paying someone to have a domain name. I sorta understand the distaste on principle, but I've never really understood, as a practical matter, why paying $10+/year for a domain name is totally fine, but paying $5/year on top of that for SSL isn't. (And yes, the race-to-the-bottom has hit $5, see ssls.com. This isn't even counting StartCom and the future Let's Encrypt.) Second, and related to that, what you're paying them for is the human element in key continuity. If you ever lose your key, you're going to want to be able to regain a key for the same website that you've already published everywhere, that everyone already has localStorage for, etc. And be careful about saying that you don't care: Crypto.cat (which, at this point, definitely knows what they're doing) managed to lock themselves out from SSL by requesting a hardcoded public-key pin and then losing all the public keys they'd pinned. This isn't really a risk that you think is realistic until disaster strikes, and the last thing you want in the middle of a disaster is to have to rename your website and convince everyone that they should use the new site. And the process of maintaining infrastructure to re-provision certificates to people costs money. It's possible that it could be funded in different ways (just like, e.g., all of the work that goes into the browsers themselves is funded in ways that don't involve charging website owners or users). But there is a thing there that involves humans, there are advantages to it involving humans, and humans need to be paid.
- shawabawa3 12y ago
  > And yes, the race-to-the-bottom has hit $5, see ssls.com What's the race to the bottom for wildcard certs though? Looks like $80+/year, which is frankly completely ridiculous seeing as it's exactly the same amount of work for the CA. The whole thing's a racket, we would honestly be better off using self-signed certs and certificate pinning (perhaps with a global list of cert pins stored in the browser/a server the browser implicitly trusts) I mean, we have to trust the browser anyway, might as well make it handle all the security
aburan28 12y ago
A better solution could be viable but there are entire companies based upon the pki infrastructure.
mike_hearn 12y ago
Why you think the PKI sucks but can't do any better: https://medium.com/@octskyward/why-you-think-the-pki-sucks-b64cf5912aa7 https://medium.com/@octskyward/why-you-think-the-pki-sucks-b... I wrote this article for the Bitcoin community but most of the logic stands for the web too.
rakoo 12y ago
Some pointers for you: - The Perspectives project (http://perspectives-project.org/ http://perspectives-project.org/) aimed to deploy a range of servers (called notaries), through which you can ask "What cert do you see for https://google.com https://google.com ?", and compare the response. The idea was that certificates should be mostly the same wherever you're asking from. - Convergence (https://en.wikipedia.org/wiki/Convergence_(SSL) https://en.wikipedia.org/wiki/Convergence_(SSL)) is a fork of the same idea. The issue with both of them is, of course, privacy leaks, which the latest version of convergence (https://github.com/mk-fg/convergence#changes-from-upstream https://github.com/mk-fg/convergence#changes-from-upstream) solves with a custom onion routing. The other problem I see is that it still (in the current form) requires the user to manually edit the notaries list. So, it does exist, maybe it's just lacking publicity ?

rtpg 12y ago

I don't get how it's ridiculous. How do I know that Bank of America's website is actually Bank of America? At least I know _somebody_ checked that it was BoA who is controlling the domain. It's obviously far from 100%, but the web of trust has to start somewhere. Distributed web-of-trust works for individuals, but am I supposed to go see Jeff Beezos in meatspace before going to amazon.com? The solution is, of course, delegation. But the end result is you end up with exactly the same CA system as today!

TheDong 12y ago
Somebody checked that in the past, yes, but that check doesn't matter for your current connection. Your browser will accept any CA signed cert as valid for the site it's for... if a hacker hacks into a low-profile CA, not even the one that verified BoA, they can MITM you every bit as easily as if they hacked BoA's actual cert authority. The problem here is that the delegation is too broad; we're delegating verifying all websites to all CAs and assume that all CAs are absolutely trustworthy for it to work. That's ridiculous. Chrome has a sort-of-solution built on top of this with certificate pinning where the organization gets a cert from the CA, and then gives it to chrome and claims "Only this cert is valid for our site" rather than all CA's certs... Continuing with our example of BoA, this doesn't matter because they have not opted in [0] to that and in any case that won't apply to non-chrome requests. [0]: https://code.google.com/p/chromium/codesearch#chromium/src/net/http/transport_security_state_static.json https://code.google.com/p/chromium/codesearch#chromium/src/n...
- bigiain 12y ago
  "Chrome has a sort-of-solution built on top of this" … which scales up about as far as every domain Google owns/cares about, and a few of their friends/partners/sites-that're-politically-or-business-beneficial-to-Google-to-pin. I suspect in my 20 odd years of working with ssl protected websites, there's maybe 2 or 3 sites I've worked on that hav a hope in hell of getting into Chrome's pin list. If you're outside the US Fortune500 or any other countries Fortune100, how easy is it gonne be to get Google to pin your cert? It's nice if you're Twitter - it's _never_ gonna work for mygreatcatphotos.org.au... It's useful, and a great thing they're doing, but as you say, it's _very much_ a sort-of-solution. Perhaps more like a very good two or three bandaid solution, directed at the problem of someone with 99% full body covered 3rd degree burns. "Here, I've got your left thumb and your right big toe covered!"
  - TheDong 12y ago
    They have pretty little form for it :) https://hstspreload.appspot.com/ https://hstspreload.appspot.com/ My guess is no one bothers to fill out the form due to lack of knowledge about its existence. Surely they let in more than just their friends ... though yes, I do recognize this isn't scalable.
    - geofft 12y ago
      They've been pushing back against new people preloading public key pins because it's hard to make sure that someone else understands exactly what the consequences are. (Cryptocat, notably, got this wrong.) But yes, HSTS preloading is totally open, and has been scaling as well as it's been needed.
- rtpg 12y ago
  this is a really good point. So would a good solutioon be to divy up the delegation? Though I don't know how that could work (how would you know you're on a bank website? a .bank tld?) This is tricky, but I still don't get how decentralisation solves things, because the problem is still the same, except now it's a risk of whatever web-of-trust node you're a part of being compromised instead of a CA.

dmichulke 12y ago

Trustworthy entities (e.g, Mr Schneier and Krebs and whoever they trust) could just offer a signed list of pub-key - identity pairs which can be stored in the block chain. The amount of work needed should be pretty low, they start with the current certificate tree and they just need to update in case of a certificate incident (they probably get this info fast and the update should be easy to do via software). Probably they could sustain this service via donations.

geofft 12y ago

> Forget security concerns, I'm just appalled that to acceptably do encryption today I need to pay some company! That's wrong. Well, you don't need to pay anyone to do encryption. You do need to do pay people to do identity verification. That's a more-than-pedantic difference, even though encryption without identity verification is generally meaningless. First off, you're already paying someone to have a domain name. I sorta understand the distaste on principle, but I've never really understood, as a practical matter, why paying $10+/year for a domain name is totally fine, but paying $5/year on top of that for SSL isn't. (And yes, the race-to-the-bottom has hit $5, see ssls.com. This isn't even counting StartCom and the future Let's Encrypt.) Second, and related to that, what you're paying them for is the human element in key continuity. If you ever lose your key, you're going to want to be able to regain a key for the same website that you've already published everywhere, that everyone already has localStorage for, etc. And be careful about saying that you don't care: Crypto.cat (which, at this point, definitely knows what they're doing) managed to lock themselves out from SSL by requesting a hardcoded public-key pin and then losing all the public keys they'd pinned. This isn't really a risk that you think is realistic until disaster strikes, and the last thing you want in the middle of a disaster is to have to rename your website and convince everyone that they should use the new site. And the process of maintaining infrastructure to re-provision certificates to people costs money. It's possible that it could be funded in different ways (just like, e.g., all of the work that goes into the browsers themselves is funded in ways that don't involve charging website owners or users). But there is a thing there that involves humans, there are advantages to it involving humans, and humans need to be paid.

shawabawa3 12y ago
> And yes, the race-to-the-bottom has hit $5, see ssls.com What's the race to the bottom for wildcard certs though? Looks like $80+/year, which is frankly completely ridiculous seeing as it's exactly the same amount of work for the CA. The whole thing's a racket, we would honestly be better off using self-signed certs and certificate pinning (perhaps with a global list of cert pins stored in the browser/a server the browser implicitly trusts) I mean, we have to trust the browser anyway, might as well make it handle all the security

aburan28 12y ago

A better solution could be viable but there are entire companies based upon the pki infrastructure.

mike_hearn 12y ago

Why you think the PKI sucks but can't do any better: https://medium.com/@octskyward/why-you-think-the-pki-sucks-b64cf5912aa7 https://medium.com/@octskyward/why-you-think-the-pki-sucks-b... I wrote this article for the Bitcoin community but most of the logic stands for the web too.

rakoo 12y ago

Some pointers for you: - The Perspectives project (http://perspectives-project.org/ http://perspectives-project.org/) aimed to deploy a range of servers (called notaries), through which you can ask "What cert do you see for https://google.com https://google.com ?", and compare the response. The idea was that certificates should be mostly the same wherever you're asking from. - Convergence (https://en.wikipedia.org/wiki/Convergence_(SSL) https://en.wikipedia.org/wiki/Convergence_(SSL)) is a fork of the same idea. The issue with both of them is, of course, privacy leaks, which the latest version of convergence (https://github.com/mk-fg/convergence#changes-from-upstream https://github.com/mk-fg/convergence#changes-from-upstream) solves with a custom onion routing. The other problem I see is that it still (in the current form) requires the user to manually edit the notaries list. So, it does exist, maybe it's just lacking publicity ?