Launching in 2015: A Certificate Authority to Encrypt the Entire Web • Hacker News Board

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#441

Post by xorcist » Wed, Nov 19, 2014, 1:48 PM UTC

jessaustin wrote: post #378

xorcist wrote: post #342

Earlier quoted context omitted.

Which root keys? The ones you store on your web server, which just got compromised?

Why would one store them there? Why not just use them to sign other keys that are actually used in online systems?

No, the question is what to do when you need to rotate them. Because that need will arise somewhere, globally, if we were to run the secure web on trust-on-first-use.

It's not interesting why someone hypothetically did get their root keys compromised, it's interesting how the proposed system would cope with it.

(Downvoting the question is not really a web scale way to build a global trust system.)

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#442

Post by IgorPartola » Wed, Nov 19, 2014, 1:58 PM UTC

jcase wrote: post #437

IgorPartola wrote: post #304

Earlier quoted context omitted.

What does it matter who issues your cert if your registrar controls your domain name? They can transfer your domain name to the FBI, your competitor, your ex-husband, whoever. They can keep it for themselves, and they can publish their own DNS servers as authoritative, making all traffic flow through them anyways. They already are in 100% control of your domain and you are at their mercy. You already trust them enoug…

This article[0] is largely about DNSSEC and DANE but it might give you some insights why making registrars the sole authorities isn't such a good idea. [0] http://www.thoughtcrime.org/blog/ssl-and-the-future-of-authe...

I may be dense but it seems to me that your registrar is still the trusted entity no matter what:

- they sell you the domain name. Doesn't matter how you try to authenticate yourself to clients (cert pinning aside), the registrar can seize the domain at any point.

- they control what your authoritative name servers are. They could easily change these on you.

- they populate the whois database, which is used when you purchase your TLS certs. This means that a registrar can list joe@fbi.gov as you the contact, and have Joe get a completely valid cert.

- one important issue that the article does not mention is that you are forever locked into trusting the site operator. This means that you as a user already must trust another entity.

This, what I am proposing is that out of the current trust list: [site owner, registrar. CA] we cut out the CA. Once again, the registrar always trumps the CA in their ability to seize your domain. At the same time, the CA provides zero protection against the registrar misbehaving. This article talks about shifting trust from the CA to the registrar and how that's bad. I posit that you already trust the registrar, forever (or as long as you are willing to use their TLD) so you would be strictly reducing the amount of entities you need to trust, never adding new ones.

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#443

Post by balabaster » Wed, Nov 19, 2014, 3:48 PM UTC

anonbanker wrote: post #148

balabaster wrote: post #123

How does a CA that's formed by a conglomerate of U.S. companies (under the jurisdiction of the NSA) make us any safer than we are currently? It doesn't. The chain of trust chains up all the way to a U.S. company, which can be coerced into giving up the certificate and compromising the security of the entire chain. I'm on the side of the EFF trying to encrypt the web, but this is not the solution.

truth be told, it doesn't make anyone safer. it's a big fat placebo, especially once the NSA realizes that this project is entirely under their jurisdiction. Now, if there was a project in Iceland or Seychelles that was doing something similar, I would be much more apt to participate.

Security theatre for the win(?) Do these people [EFF] not realize that the people they're trying to win over are network nerds? These are people that actually understand this shit and the repercussions of it.

I can't profess to understanding all the details of encryption infrastructure, but I learned very quickly in kindergarten, you can't trust anyone you don't know. It doesn't matter who they are, who they know or what they know. Half the time, you can't even trust "cold hard facts", the facts are frequently misinterpreted, fabricated or eventually proven to be wrong - once it was a fact that the earth was flat, then we were the centre of the universe, now the universe as we know it is held together by a God particle. Science claims facts that invalidate there being a God... all facts are a matter of our fallable understanding of this scientific instrument we are building. Even people you do trust can be coerced into doing things that compromise your ability to trust them or their motives.

If you want to automate trust, then you're eventually going to have to realize that you can't. All you can do is mitigate the cost of being wrong.

Absolute power corrupts absolutely - the CA (or whoever controls that CA) has absolute power in this scenario. If you have the director's family hostage, everyone else's security just went down the pan.

Chain of trust is like putting all your eggs in one basket. You just don't do it. Web of trust is a marginal step up, but it's more of a pain in the ass and can also be overcome by a group with malicious intent.

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#444

Post by organsnyder » Wed, Nov 19, 2014, 3:57 PM UTC

locusm wrote: post #409

organsnyder wrote: post #252

Earlier quoted context omitted.

> especially since a basic SSL certificate is free From where? StartSSL only gives out free certs to individuals. For my company, they've actually required me to get organizational validation in the past, which wasn't cheap ($200, IIRC—$100 for the organizational validation, plus $100 for stage 2 personal validation, which also required me to upload images of my driver's license and passport).

Domain validated certs for websites are free, got one a couple of weeks ago for a site.

If it was for an organization, you only got the cert because they didn't catch it. For some reason, my account got flagged as high-risk, and every cert I request needs manual review. During one of those reviews, they rejected my cert request and told me that since it was for an organization, I needed organizational validation. This was for a standard certificate—not extended validation. I think they must've either visited the company website or checked whois.

Their FAQ alludes to this, but doesn't really make it explicit:

> The certificate is for my company, what shall I do?

> In the Class 1 settings (free), the only possible relationship between StartCom and the subscriber is > with individuals, i.e. natural persons. StartCom has no relationship with the organization a subscriber > may represents and acknowledges only the subscriber. All responsibilities according to the StartCom > CA Policy are that of the subscriber personally, even in case he/she decides to obtain certification as > an employee or representative of an organization. > Organizations should perform Class 2 validation and an organization name may only appear in a digital > certificate at Class 2 level and higher.

http://www.startssl.com/?app=25#2

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#445

Post by balabaster » Wed, Nov 19, 2014, 4:01 PM UTC

zorked wrote: post #205

balabaster wrote: post #123

How does a CA that's formed by a conglomerate of U.S. companies (under the jurisdiction of the NSA) make us any safer than we are currently? It doesn't. The chain of trust chains up all the way to a U.S. company, which can be coerced into giving up the certificate and compromising the security of the entire chain. I'm on the side of the EFF trying to encrypt the web, but this is not the solution.

Something like Certificate Transparency would counter that - where the browser can only accept certificates that have been made public record. So the owners will at least know when their domain has been attacked.

A site owner would normally know when their logs are no longer accumulating traffic that something was wrong. When their site still appears to be up and they get as far as analyzing router logs to realize that they're actually getting no traffic, even though the site appears to be functioning normally would be a huge red flag that something is very wrong. I would expect any operations team worth their salt to understand this inside of 15 minutes anyway.

Certificate Transparency may help to alert people, it's certainly a step in the right direction, but it doesn't fix the problem in my mind. I honestly don't think the problem can be fixed. All we can do is try and mitigate the risk of our trust being broken.

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#446

Post by balabaster » Wed, Nov 19, 2014, 4:06 PM UTC

kybernetikos wrote: post #346

IgorPartola wrote: post #282

Earlier quoted context omitted.

> Encrypted (Certified) COOL GREEN I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain. > Encrypted (Self-Signed) EVIL RED Not quite. Your user does have the ability to permanently trust this certificate. However, if I am trying to access gmail.com over HTTPS, I better not get this error. Otherwise, I kno…

>> Encrypted (Certified) COOL GREEN > I think we can agree that this case is correct. If you have a properly vetted cert, more power to you. The browser should tell your users that you do own this domain. Maybe. I just checked my browser and it already trusts more than 100 certificate authorities from all around the world, including some companies that I don't trust, some governments that I don't trust, but mainly co…

The problem here is that getting a vetted cert - or worse, compromising the authority that vets those certs is relatively trivial for a nation state, or even someone that's morally compromised enough to say, kidnap the CA Director's family. The fact is, trust is easily compromised and the current infrastructure needs to be hardened against that.

Even if the browser only had a single authority you do trust... how easy would it be for someone to force them to do something to compromise your trust? For instance with an NSL bound with a gag order?

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#447

Post by drderidder » Wed, Nov 19, 2014, 4:29 PM UTC

This is a great initiative. On the other hand, I'm beginning to think that security models based on any central authority will always be at risk of getting compromised from within. Techniques that allow trusted security to be established between two parties without the need for a third-party authority to validate them would be nice to see.

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#448

Post by droopybuns » Wed, Nov 19, 2014, 4:34 PM UTC

IgorPartola wrote: post #400

droopybuns wrote: post #392

Earlier quoted context omitted.

>We need to stop publishing stuff over HTTP. Period. This is a short sighted solution. If you go this route, then you are constraining authentication to the client. Users always choose bad passwords, so we are stuck. In mobile networks, you have the network in a position to strongly authenticate the subscriber, without necessitating the weaknesses that can come with bad passwords. I generally agree that TLS is desira…

FWIW, this is the route we are already going with HTTP/2: as implemented SPDY pretty much requires encryption. Also, while mobile networks can authenticate my mobile phone and the hops from my phone to their edge router can be "trusted" (don't forget that the NSA is snooping here), I want end to end encryption. I want to know that the only two entities able to send/receive data are the site I'm trying to talk to and…

I understand your argument. Barring some of the hyperbole of your worst case scenario, I totally get it.

In my opinion the rationality of your perspective is one of the most damaging consequences of the NSA's behavior.

Attacking the client is easy for both hackers and nation states. Moving the control to infrastructure tends to cut out whole swaths of script kiddies. There are important scenarios where this makes a ton of sense (m2m, iot, many mobile apps) and those assholes have just burned everyone's trust to the point that nascent solutions are no longer viable.

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#449

Post by spacecowboy_lon » Wed, Nov 19, 2014, 5:13 PM UTC

digitalsushi wrote: post #32

This certificate industry has been such a racket. It's not even tacit that there are two completely separate issues that certificates and encryption solve. They get conflated and non technical users rightly get confused about which thing is trying to solve a problem they aren't sure why they have. The certificate authorities are quite in love that the self-signed certificate errors are turning redder, bolder, and big…

no it means a trusted third party has not verifed who you are connecting to is who he/she says they are

Re: Launching in 2015: A Certificate Authority to Encrypt the Entire Web

#450

Post by IgorPartola » Wed, Nov 19, 2014, 6:34 PM UTC

byuu wrote: post #408

IgorPartola wrote: post #399

Earlier quoted context omitted.

FWIW, Igor did code up nginx to support HTTPS, despite terrible SSL libraries :) I don't really understand the problem you are having. If your sites are small personal/side projects, why worry about things like your web server? That stuff is so trivial, it's boring. If your sites are so large that the overhead that HTTPS has over HTTP makes that much of a difference (pretty sure that'd be Google, Facebook, Twitter, a…

> why worry about things like your web server? I want to do different things that haven't really been done before. I want to write my site in C++ instead of PHP. In my own case, it's not as much about speed (that's a free benefit), it's more about the language: I favor the strong typing, compile-time checking and stronger inheritance model. What I envision is that I have C++ source files. I upload one, the server see…

Got it. Well, while I can't see why you'd want C++ of all languages for this (Haskell seems like what you are really looking for), apache might actually be your friend here. At an old $WORK we had a number of web applications written in C++ and C (yup!), as apache modules. This way apache does most of the boring stuff such as header parsing, routing requests, config files, etc. and you do just the functional parts of your site/app. Then again, this was one of the slowest and most error-prone ways to code this up, and the guys working on this were full time C/C++ devs.