Live data from Hacker News

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

eff.org

451–460 of 476 posts

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

#451
post #60

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…

It's interesting that your boogeyman in the NSA and not scammers. I think scammers are 1000X more likely. Escpecially since the NSA can just see the decrypted traffic from behind the firewall. There's no technology solution for voluntarily leaving the backdoor open.

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

#452

Earlier quoted context omitted.

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

I am not quite sure what you are saying. Is it that it is in fact better to allow HTTP to exist vs providing HTTPS backed by some type of trusted infrastructure? Or is it that you are saying that we can build a brand new from scratch solution and need to fix the existing system somehow?

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

#453

Earlier quoted context omitted.

You speak as if the power of NSLs has a functional limit - it doesn't, which is what makes the entire concept so dangerous. There's nothing stopping the requirements from being "mint us a certificate according to these specs" and additionally "okay, now pin this certificate in your browser".

You might want to read up on what an NSL actually is, since you and the GP are clearly very confused.

Explain, please.

What prevents an NSL from compelling Google from minting a new certificate (they are a CA), providing the keys to the bad guys, and distributing that certificate in Chrome? NSLs have been used in the past to compel positive action (c.f. Lavabit), so I really don't see how you think there's any practical limit to their power.

My understanding is that there isn't a limit. If I am wrong about this, then kindly reply directly here so we can all learn instead of giving the "read up on" non-answer.

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

#454

Earlier quoted context omitted.

> This case should be eliminated. We need to stop publishing stuff over HTTP. Period. HTTP is perfectly fine for information originating on and never leaving controlled, trusted, internal networks, and there is no reason to pay the overhead for HTTPS for those cases. There's other use cases where its probably not worth the (small) overhead for HTTPS.

No it is not. I have talked about this on here before, but I don't mind repeating myself: - Your small blog you publish over HTTP is now opening the door for me, the attacker to mess with any traffic originating from your site. Say you host your resume on your site. I can substitute it with a much less flattering version. Say you host a code snippet. I can add a little obfuscated fork bomb or root kit at the end. Say…

What's worse is that there has already been at least one case of an ISP rewriting links to Amazon for all of their customers. https://news.ycombinator.com/item?id=6992897

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

#455
post #60

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…

Just a small nitpick: I'm pretty sure the NSA has access to a CA to make it look legit.

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

#456

Earlier quoted context omitted.

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

I am not quite sure what you are saying. Is it that it is in fact better to allow HTTP to exist vs providing HTTPS backed by some type of trusted infrastructure? Or is it that you are saying that we can build a brand new from scratch solution and need to fix the existing system somehow?

It's better to allow http to exist.

There is an opportunity for new authentication approaches that can't exist in a TLS-everywhere world.

I'm looking at http://en.wikipedia.org/wiki/Generic_Bootstrapping_Architect... in particular.

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

#457
post #440
post #427

Earlier quoted context omitted.

> A self-signed certificate is trivially MITMed unless you have a way to authenticate the certificate. Trivial? Yes. As trivial as intercepting plain HTTP? No. The NSA or adversary du jour can vacuum up anything sent over plain HTTP with zero risk. Self-signed HTTPS forces the attacker to commit some resources and, more importantly, run the risk of exposure. Security is not a binary (no encryption scheme is perfect),…

https://news.ycombinator.com/item?id=8625420

HTTPS with self-signed certificates remains better than plain HTTP. The fact that you can propose an unimplemented, unstandardized, theoretical scheme that would offer the same advantages as HTTPS with self-signed certificates does not make HTTPS with self-signed certificates worse than plain HTTP.

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

#458
post #389

Earlier quoted context omitted.

various 3rd parties. this is required by the cab forum which my browser requires as well. inform yourself if you want to write stuff like that. even more, its sad that people think CAs have zero checking and just give what, money to browsers to be included? Thanksfully its not like that yet.

So,if you knew the answer to your own question, why did you ask?

I did not, actually. Same subject, but the question is different since this is a CA signed by a CA in this case.

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

#459

Earlier quoted context omitted.

>man-in-the-middled passively "eavesdropped" is the word you're looking for.

I think NSA was calling it Man On The Side? Or was that something different?

It's slightly different. QUANTUM man-on-the-side deployments can always read packets and inject packets, but it appears cannot stop packets getting through or change them en route.

Deployments in the wild appear to use cable splitters to read, so often have no direct write access due to transport layer limitations and sometimes deliberate "Data Diode" one-way firewalls on the hot pipe (just in case?); they communicate with instrumented boxes closer to 'home' on a management network, which do not have to be on-path themselves, some of which may well be hacked routers, to do packet injection. C&C was centralised pingbacks, but that lost races (typical latency: 670ms-ish) so is now distributed (with QUANTUMFIRE).

They can use that knowledge and capability together to race to control a TCP connection, after which the real packets will be discarded by the target endpoint (because the seq is "wrong"), after which they are fully man-in-the-middle and can inject redirection headers (QUANTUMINSERT), tracking cookies (QUANTUMCOOKIE) or infect downloaded executables (QUANTUMCOPPER); they can also inject RSTs to force TCP connection resets (QUANTUMSKY; also used by Blue Coat, the .cn Golden Shield, and many others).

Note this implies that they are detectable and locatable, if you know what to look for.

(Sorry I can't be much more helpful without going in and taking one, and I think they would very strongly disapprove of that. )

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

#460
The real problem here is that http is unencrypted by default. It really should be encrypted so that passive listeners can't see the traffic. I know that this is no protection against man in the middle attacks, but at least WiFi sniffers and similiar would be stopped. State Actors would have to actively do something which might be registered. It would be a great improvement, because in the current system, most websites are going to stay unencrypted because it takes money and effort to set up a certificate. The millions of shared hosters won't do it by default.

What we can do: - Change the http protocol to be encrypted? - create an apache module that automatically does this and needs no setup time (generate private keys automatically?)

Of course there shouldn't be any indicator of this encryption in the adress bar of the browser.

Maybe it's too late.

Post reply on HN