Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

eff.org

Post reply on HN
Print view View original

321–330 of 476 posts

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

#321

Post by tomp »

xorcist wrote: post #294
tomp wrote: post #106

Earlier quoted context omitted.

NSA has NSL (national security letters with gag orders). There are CAs in the US. Mission accomplished.

That would be stupid. Google is a US company. NSA has NSLs. Mission accomplished. No certs involved.

How did you get Google into all this? If you're implying that Google owns a search site/Gmail/a browser, know that there are alternatives, which NSA's target could be using. A fake certificate from a trusted US CA can MITM any connection to almost any website from almost any browser.

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

#322

Post by geofft »

dragonwriter wrote: post #301
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…

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

There's also significant overhead to the community at large in having both HTTP and HTTPS be reasonable systems to use, and requiring that HTTP not show loud warnings. There's also a risk to your organization that you're teaching users that some HTTP sites are reasonable, which is a hard judgment for them to make. I can put up an external website which claims to be internal, and probably get some passwords or confidential information that way.

If you use HTTPS everywhere, there is a tiny bit (but usually negligible) runtime overhead, a bit of process overhead (which this announcement is pushing much closer to zero), and significant simplicity in many other axes. I think the tradeoff leans towards publishing internal sites with globally-valid HTTPS certificates.

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

#323

Post by geofft »

rufb wrote: post #247
pilif wrote: post #60

Earlier quoted context omitted.

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

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.

It's definitely an antipattern. It's hard to solve until we get HTTPS deployable everywhere, because the first browser to defect from this antipattern will lose all its users, so it's extremely important to push on HTTPS being deployable and deployed everywhere.

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

#324

Post by joshuak »

MichaelGG wrote: post #203
lazyjones wrote: post #92

Earlier quoted context omitted.

They can get US corporations (including many CAs) to cooperate. For example, to obtain a fake (but perfectly working google.com certificate, they can ask Google (more or less) nicely to provide one, or they can go ask any CA instead. It's not likely that compromise is required with so many potential sources, some of which may be paid or coerced to cooperate. PS. nice (presumably political) downvote further up ...

The NSA can do this, yes. But, any CA that issues a fake CA for Google will be found out rather quickly, and then will get blacklisted and lose business. So while the NSA can technically do that, they only get a few shots cause each one has a high chance of burning the CA. For lesser sites and narrow targets, this may not be true.

This is precisely the problem with centralized security authorities. As we've seen a state actor can easily force a central authority to share it's private key, thereby granting the state actor the ability to untraceably create it's own certificate chains.

It would also have to control the wire for the attack target, but via wire tapping laws that is already a solved problem. Because they control the connection of the attack target, I don't see how the fact that the certificate chain was compromised would ever become public knowledge.

Web of trust was designed to address the central authority weakness, but itself apparently has scalability issues, although I'm unclear on why.

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

#325

Post by SilasX »

iancarroll wrote: post #318
Tepix wrote: post #313

Earlier quoted context omitted.

Stopping snooping by encrypting without strictly checking certificates the first time you connect is better than not using encryption because it stops dragnet surveillance. Also, active attacks (like MITM) are harder to do and easier to detect than passive attacks (snooping).

That would make dragnet surveillance easier. Just MITM everything and you'll be the Trusted Source™ for all traffic.

Nobody’s suggesting that self-signed certs be treated as trusted or CA-cert equivalent, only that they not be regarded as worse than unencrypted http. In the proposals being discussed, that attack would no more of a threat than MitMs currently are against http.

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

#326

Post by mangeletti »

akerl_ wrote: post #167
mangeletti wrote: post #101

Earlier quoted context omitted.

What authorization is required in this scenario? I'm talking about a novel idea here, one that doesn't fit into the existing CA model. There would be no CA in this scenario; verification would be decentralized, based on shared information, not on knowledge of a secret.

I'm not sure web-of-trust can be considered a novel idea in 2014. We can all look at the variety of web-of-trust methods to see how well that's taken off amongst internet users.

It is novel, in terms of there being any such service in existence, ever.

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

#327

Post by mhandley »

schoen wrote: post #195
justcommenting wrote: post #180

from the ACME spec, it looks like proof of ownership is provided via[0]: >Put a CA-provided challenge at a specific place on the web server or > Put a CA-provided challenge at a DNS location corresponding to the target domain. Since the server will presumably be plaintext at that point and DNS is UDP, couldn't an attacker like NSA just mitm the proof-of-site-ownership functionality of lets-encrypt to capture ownershi…

Four things: (1) You can do the attack you describe today with existing CAs that are issuing DV certs because posting a file on the web server is an existing DV validation method that's in routine use. (2) There is another validation method we've developed called dvsni which is stronger in some respects (but yes, it still trusts DNS). (3) We're expecting to do multipath testing of the proof of site ownership to make…

Let's Encrypt can run a web spider - crawl the web to build a database of actively used domain names.

Periodically poll DNS for the list from that database to obtain the NS records for pretty much all of the web, and also A records for all the actively used hosts you find in the crawl. Keep this cache as a trace of how DNS records change.

Now, do the DNS polling from several different geographic locations. Now you've got a history of DNS from different viewpoints.

When you get a request for a certificate for, say, "microsoft.com", look up the domain name in the way described on the Lets Encrypt description. But also check that this IP address appears in the history, either from multiple locations for a few days, or from one location for a few months.

If this test fails, check if the historic IP addresses for this domain from the polled cache are already running TLS, signed by a regular CA. If so, reject the application.

Otherwise continue with validation in the way described on the Lets Encrypt web page.

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

#328

Post by wbillingsley »

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…

Private to the NSA and reasonably private to the person sitting next to you are different use cases. The current model is "I'm sorry, we can't make this secure against the NSA and professional burglars so we're going to make it difficult to be reasonably private to others on the network".

It's as if a building manager, scared that small amounts of sound can leak through a door, decided that the only solution is to nail all the office doors open and require you to sign a form in triplicate that you are aware the door is not completely soundproof before you are allowed to close it to make a phone call. (Or jump through a long registration process to have someone come and install a heavy steel soundproofed door which will require replacement every 12 months.)

After all, if you're closing the door, it's clearly meant to be private. And if we can't guarantee complete security against sound leaks to people holding their ear to a glass on the other side, surely you mustn't be allowed to have a door.

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

#329

Post by AnthonyMouse »

eksith wrote: post #303
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…

The registrar issuing cert solution would certainly speed up HTTPS adoption; you're dealing with one less org to secure your site. The down-side is that if you decide to move registrars, that still complicates things. What if the new registrar refuses to issue a new cert without a hefty fee? Or what about revoking the previous cert? Now the registrar is functioning as a de facto CA so it doesn't completely eliminate…

> The down-side is that if you decide to move registrars, that still complicates things. What if the new registrar refuses to issue a new cert without a hefty fee?

Then everyone stops using that registrar and they go out of business.

> Or what about revoking the previous cert?

You're asking this as if there is some kind of functioning method of revoking certificates already. If anything this makes it easier because it could be plausible for clients to somehow retrieve who the registrar is for the domain and then only accept certificates signed by that registrar.

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

#330

Post by jameshart »

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…

There's no such thing in X509 as a cert which is authorized only to sign certs within a certain subdomain. A CA is either trusted or not; if it's trusted, it can sign off on a cert for www.google.com.

A system where there's a .com root cert that can sign authority certs for .com subdomains, which themselves can only sign for their own subdomains - that's a great idea. Not part of the standard, though.

Post reply on HN