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

51–60 of 476 posts

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

#51

Post by jackalope »

overshard wrote: post #11

The "How It Works" page, https://letsencrypt.org/howitworks/ , has me a bit worried. Anytime I see a __magic__ solution that has you running a single command to solve all your problems I immediately become suspicious at how much thought went into the actual issue. If I'm running a single web app on a single Ubuntu server using Apache then I'm set! If I'm running multiple web apps across multiple servers using a load…

I run Apache httpd, and there's no way I'd let a wizard anywhere near my configuration files or private keys, much less run it on a production server.

I think it's about time for a free CA that is recognized by all clients, but you still need to establish a trust chain to exchange a CSR for a signed certificate. This service needs to be server agnostic. The barrier to adoption isn't configuration, and HTTPS isn't the only thing that uses certificates.

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

#53

Post by jolan »

tmmm wrote: post #50

Won't people need to have LetsEncrypt CA certificate installed on their computers to not get that red SSL incorrect certificate thing? Other than that, this is awesome.

The "How It Works" page (https://letsencrypt.org/howitworks/) says:

- Obtain a browser-trusted certificate and set it up on your web serve

IdenTrust is listed as a sponsor and is the CA for the letsencrypt.org certificate so I'm guessing they're doing some sort of partnership.

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

#54

Post by tmmm »

jolan wrote: post #53
tmmm wrote: post #50

Won't people need to have LetsEncrypt CA certificate installed on their computers to not get that red SSL incorrect certificate thing? Other than that, this is awesome.

The "How It Works" page ( https://letsencrypt.org/howitworks/ ) says: - Obtain a browser-trusted certificate and set it up on your web serve IdenTrust is listed as a sponsor and is the CA for the letsencrypt.org certificate so I'm guessing they're doing some sort of partnership.

I mean ordinary people who will visit the page.

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

#55

Post by joshmoz »

tmmm wrote: post #50

Won't people need to have LetsEncrypt CA certificate installed on their computers to not get that red SSL incorrect certificate thing? Other than that, this is awesome.

IdenTrust will be cross-signing our roots while we apply to root programs.

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

#56

Post by michaelbuckbee »

danielweber wrote: post #25
lowglow wrote: post #3

Free CA? This is cool. Why this wasn't done a long time ago is beyond me. (Also please support wildcard certs) An interesting thing happened at a meet-up at Square last year. Someone from google's security team came out and demonstrated what google does to notify a user that a page has been compromised or is a known malicious attack site. During the presentation she was chatting about how people don't really pay atte…

I'll run a free CA right now. Who wants a cert for microsoft.com? NB: This is a bit unfair, because the existing for-money CAs haven't always stopped someone from registering microsoft.com.

You raise a good point though, SSL/TLS Certs are trying to deal with two separate problems:

1. Over the wire encryption (which this handles)

2. As a bad, but the best we've got site identification system for stopping phishing mechanism.

Currently, for even the cheapest certs (domain+email validated) - the CAs will reject SSL cert requests for anything that might be a phishing target. Detecting "wellsfargo.com" is pretty easy, where it gets tricky is things like "wellsforgo.com", "wellsfàrgo.com" etc. Which if I'm looking at this right will just sail through with LetsEncrypt.

I suspect we're going to actually end up with two tiers of SSL certs as the browser makers have started to really de-emphasize domain validated certs [1] like this vs the Extended Validation (really expensive) certs, to the point where in most cases now having a domain cert does not know green (and maybe doesn't even show a lock) at all.

As a side note, Google had announced that they were going to start using SSL as a ranking signal [2] (sites with SSL would get a slight bump in rankings), from this perspective the "high" cost of a cert was actually a feature as it made life much more expensive on blackhat SEOs who routinely are setting up hundreds of sites.

1 - Screenshots: https://www.expeditedssl.com/pages/visual-security-browser-s...

2 - http://googlewebmastercentral.blogspot.com/2014/08/https-as-...

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

#57

Post by desdiv »

mike_hearn wrote: post #39
tatterdemalion wrote: post #36

Earlier quoted context omitted.

I don't see how this actually keeps the CA PKI from being a scam. While I personally trust the EFF & Mozilla right now, as long as I can't meaningfully revoke that trust, it's not really trust and the system is still broken.

You can revoke your trust in any CA at any time, you don't even need to see any errors! Just click the little padlock each time you visit a secure website and see if the CA is in your good books. If it's not, pretend the padlock isn't there! OK, that's a little awkward. A browser extension could automate this. But in practice, nobody wants to do this, because hardly anyone has opinions on particular CAs. It's a sort…

Can't you just delete the CA from the browser?

On Firefox it's preferences -> advanced -> certificates -> view certificates.

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

#58

Post by 3pt14159 »

Someone1234 wrote: post #42
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…

I totally agree that CAs are a racket. There's zero competition in that market and the gate-keepers (Microsoft, Mozilla, Apple, and Google) keep it that way (mostly Microsoft however). That being said: Identity verification is important as the encryption is worthless if you can be trivially man-in-the-middled. All encryption assures is that two end points can only read communications between one another, it makes no…

It is not a legitimate requirement.

HTTP can be man-in-the-middled passively, and without detection; making dragnets super easy.

In order for HTTPS self signed certs to be effectively man-in-the-middled the attacker needs to be careful to only selectively MITM because if the attacker does it indiscriminately clients can record what public key was used. The content provider can have a process that sits on top of a VPN / Tor that periodically requests a resource from the server and if it detects that the service is being MITM then it can shut down the service and a certificate authority can be brought in.

Edit: Also, all this BS about how HTTPS implies security is besides the grandparent's point: certificates and encryption are currently conflated to the great detriment of security, and they need not be.

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

#59

Post by iancarroll »

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…

I'm not entirely sure I understand your point, so if I misunderstood you please correct me.

First, TLS has three principles that, if you lose one, it becomes essentially uselsss:

1) Authentication - you're talking to the right server

2) Encryption - nobody saw what was sent

3) Verification - nothing was modified in transit

Without authentication, you essentially are not protected against anything. Any router, any government can generate a cert for any server or hostname.

Perhaps you don't think EV certs have a purpose - personally, I think they're helpful to ensure that even if someone hijacks a domain they cannot issue an EV cert. Luckily, the cost of certificates is going down over time (usually you can get the certs you mentioned at $10/$150). That's what my startup (https://certly.io) is trying to help people get, cheap and trusted certificates (sorry for the promotion here)

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

#60

Post by pilif »

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 this as a grave error IMHO is right because by accepting the connection over SSL, you state that the conversation between the user agent and the server is meant to be private.

Unfortunately, there is no way to guarantee that to be true if the identity of the server certificate can't somehow be tied to the identity of the server.

So when you accept the connection unencrypted, you tell the user agent "hey - everything is ok here - I don't care about this conversation to be private", so no error message is shown.

But the moment you accept the connection over ssl, the user agent assumes the connection to be intended to be private and failure to assert identity becomes a terminal issue.

This doesn't mean that the CA way of doing things is the right way - far from it. It's just the best that we currently have.

The solution is absolutely not to have browsers accept self-signed certificates though. The solution is something nobody hasn't quite come up with.

Post reply on HN