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

#391

Post by zobzu » Wed, Nov 19, 2014, 3:40 AM UTC

themartorana wrote: post #162

zobzu wrote: post #68

Whos auditing the ca?

Who's auditing the auditors? Remember Moody's? It's not entirely analogous, but it's not far from it. At some point down the chain, you have to rely on trust to some degree. Either disappear in to the wilderness and completely disconnect from the grid or - at some point - you have to trust someone.

All CAs for most browsers are all audited by a third party. That's what provides the trust.

https://cabforum.org/baseline-requirements/ https://www.mozilla.org/en-US/about/governance/policies/secu... https://www.mozilla.org/en-US/about/governance/policies/secu...

Geez the people without a clue wanting to patronize on HN - I'm telling you - nothing like that to lose faith in humanity.

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

#392

Post by droopybuns » Wed, Nov 19, 2014, 3:40 AM UTC

IgorPartola wrote: post #282

rufb wrote: post #247

Earlier quoted context omitted.

So this is where we stand: Encrypted (Certified) COOL GREEN Encrypted (Self-Signed) EVIL RED Unencrypted NOTHING / NEUTRAL CHROME I think there's a pretty blatant antipattern here, and I'm not talking about colourblind-proofing the browser chrome.

> 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…

>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 desirable, but if we go all in, there are interesting and potentially more desirable alternatives that are lost.

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

#393

Post by jameshart » Wed, Nov 19, 2014, 3:45 AM UTC

h4xar wrote: post #383

jameshart wrote: post #333

Earlier quoted context omitted.

Interesting - that's news to me, and does allow a domain-registry-based hierarchy. I guess there's the old revocation-check problem, though - when someone transfers a domain or it expires, you'd need to be able to revoke the authority cert. Potentially leads to a lot of revocation checks to validate a cert chain correctly...

You mention that the revocation-check problem is old, which is certainly true, but I think you allude to the possibility that a domain-registry-based hierarchy will exacerbate that problem in the form of an increase in revocation checks. I'm not sure that would be the case; it should be about the same. What difference does it make if I owned a domain, got a cert from a CA, and stopped owning the domain -- vs -- got t…

I guess you're right - I was considering the fact that someone once owned a domain was a threat, but it is already.

But with a delegated chain of certs, the problem does get worse - not least because you'd require individual domains to manage their own certificate revocation.

But since there's basically no secure way to obtain CRLs or perform OCSP cert validation, it's kind of moot.

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

#394

Post by justinreeves » Wed, Nov 19, 2014, 4:03 AM UTC

pilif wrote: post #60

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…

> A self signed certificate warning means "Warning! The admin on the site you're connecting to wants this conversation to be private but it hasn't been proven that he has 200 bucks for us to say he's cool" no. It means "even though this connection is encrypted, there is no way to tell you whether you are currently talking to that site or to NSA which is forwarding all of your traffic to the site you're on". Treating…

Moxie Marlinspike's Perspectives addon for Firefox was a good attempt to resolve some of the problems with self-signed certs.

Unfortunately, no browsers adopted the project, and it is no longer compatible with Firefox. There are a couple forks which are still in development, but they are pretty underdeveloped.

I wonder if Mozilla would be more likely to accept this kind of project into Firefox today, compared to ~4 years ago when it was first released, now that privacy and security may be more important topic to the users of the browser.

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

#395

Post by kijin » Wed, Nov 19, 2014, 4:10 AM UTC

lambada wrote: post #181

Looking at the spec [0] I'm concerned about the section on 'Recovery Tokens'. "A recovery token is a fallback authentication mechanism. In the event that a client loses all other state, including authorized key pairs and key pairs bound to certificates, the client can use the recovery token to prove that it was previously authorized for the identifier in question. This mechanism is necessary because once an ACME serv…

I suppose they could check WHOIS at a regular interval to check whether a domain secured by one of their certs has expired, and update the state of the ACME server accordingly?

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

#396

Post by SilasX » Wed, Nov 19, 2014, 5:08 AM UTC

tptacek wrote: post #347

SilasX wrote: post #300

Earlier quoted context omitted.

>The only "security" derived from unauthenticated TLS presumes that attackers can't see the first few packets of a session Could you elaborate here? With a self-signed cert, the server is still not sending secret information in the first few packets; it just tells you (without authentication) which public key to use to encrypt the later packets (well, the public key to encrypt the private key for later encryption). T…

There are no such attackers.

You're saying that everyone able and willing to passively snoop, is also able and willing to compromise the channel and mimic the server?

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

#397

Post by seanp2k2 » Wed, Nov 19, 2014, 5:40 AM UTC

caf wrote: post #386

moe wrote: post #332

Earlier quoted context omitted.

The solution is something nobody hasn't quite come up with. SSH has. It tells me: WARNING, You are connecting to this site (fi:ng:er:pr:in:t) for the first time. Do your homework now. IF you deem it trustworthy right now then I will never bother you again UNLESS someone tries to impersonate it in the future. That model isn't perfect either but it is much preferable over the model that we currently have, which is: Bli…

Certificate Patrol can give you something like this for Firefox.

+1 for Certificate Patrol; used to use it until it got too annoying for me. Same with RequestPolicy; another great extension that is unfortunately a lot of work if you surf a lot, esp these days, when everything is hosting assets on CDNs.

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

#398

Post by Animats » Wed, Nov 19, 2014, 6:03 AM UTC

patrickmcmanus wrote: post #261

Animats wrote: post #216

The EFF has a bad track record in this area. The last time they tried something to identify web sites, it was TRUSTe, a nonprofit set up by the EFF and headed by EFF's director. Then TRUSTe was spun off as a for-profit private company, reduced their standards, stopped publishing enforcement actions, and became a scam operation. The Federal Trade Commission just fined them: "TRUSTe Settles FTC Charges it Deceived Cons…

> If it's public static content, what is SSL protecting? https:// helps protect the act of participation and deters the building of dossiers. Its the difference between the books in the library and the list of books in the library you have read.

Since SSL doesn't hide the length of the encrypted document, an attacker can make a good guess as to what public static content is being read.

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

#399

Post by IgorPartola » Wed, Nov 19, 2014, 6:06 AM UTC

byuu wrote: post #315

IgorPartola wrote: post #291

Earlier quoted context omitted.

Wow, of all the arguments I could think of against the current CA/TLS/HTTPS situation, a hobbyist deciding to write their own web server would not be one of them... Yes, you should just conform and stop doing this. Or at the very least you could let another process to TLS termination and just handle HTTP if you really want to create your own off-by-one remote code execution errors instead of using the ones supplied b…

> a hobbyist deciding to write their own web server would not be one of them nginx started out as a hobby project by Igor Sysoev. Maybe he should have just used Apache too? > Or at the very least you could let another process to TLS termination and just handle HTTP A well-designed HTTPS->HTTP proxy package could work. Install proxy, and requests to it on 443 fetch localhost:80 (which you could firewall off externally…

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, and nobody else), then why use your own server implementation which you must know contains more bugs than something like nginx which is already blazing fast. All of these things are a solved problem, there is no reason to solve them again unless you are explicitly developing a web server, an email relay, etc. If so, that's awesome, but in 2014 if you develop a web server that doesn't work with HTTPS, it's pretty much dead on arrival.

Having said that, check out http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/.... This sounds like exactly what you need.

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

#400

Post by IgorPartola » Wed, Nov 19, 2014, 6:11 AM UTC

droopybuns wrote: post #392

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…

>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 myself.

Let's think about it this way: in 2014 I propose a new protocol and implementation where you run a program on your device and I push arbitrary code to it. I also include code from advertisers, partners, third party affiliates, and my buddy Dave. All of this is done over clear text with no authentication, no authorization, no proof of identity or ownership, and over unsecured networks. Here's the link to the installer :) Yeah, I wouldn't sign up for that either.