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

131–140 of 476 posts

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

#131

Post by Spooky23 »

3pt14159 wrote: post #58
Someone1234 wrote: post #42

Earlier quoted context omitted.

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…

All the attacker needs to do is target the "CA" of the target.

For example, in an individual user situation, if the "CA" is a mac user, you use a local exploit, and export the private key from the Keychain. Done.

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

#132

Post by jackalope »

schoen wrote: post #105
jackalope wrote: post #51

Earlier quoted context omitted.

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…

There are lots of different barriers to adoption. With this project we are attacking several of them at the outset, including the cost of obtaining a certificate, and the inconvenience or difficulty of obtaining and installing it for users who don't do that every day. Because of the open protocol we also aspire to support users with more complex configurations and requirements, who are absolutely welcome and encourag…

My concern is that your reach is too far. Asking domain administrators to trust your software to manipulate private keys (and server configurations) is as troubling as asking end users to click past security warnings. The whole purpose of the CSR is to obtain the signed certificate without putting the private key at risk. This decoupling isolates the challenge of identity verification in a reasonable place (nobody is saying it's easy). With your client, you're essentially telling people you accept checks or credit cards, but only if they show you their gold. It sets a bad precedent.

I do want your certs for free! But I also want/need to trust you and know that you're following best practices, not just with me but with everyone.

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

#133

Post by seryoiupfurds »

pilif wrote: post #111
Joeri wrote: post #102

Earlier quoted context omitted.

Self-signed certificates are still better than http plain text. I understand not showing the padlock icon for self-signed certificates, I don't understand why you would warn people away from them when the worst case is that they are just as unsafe as when they use plain http. IMHO this browser behavior is completely nonsensical.

How would a browser know that the the self-signed certificate that was just presented for www.mybank.com is intended to be self-signed (show no error, but also show no padlock) or whether it's the result of a MITM attack because www.mybank.com is supposed to present a properly signed certificate (show error)? How would you inform people going to www.mybank.com which is presenting a self-signed cert in a way that a) t…

If the user typed www.mybank.com, let the server redirect to https but don't show the lock icon if it's self-signed. This is no worse than an impostor that just doesn't redirect to https.

If the user typed https://www.mybank.com, show the usual warning for self-signed certificates.

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

#134

Post by jbinto »

M2Ys4U wrote: post #113
zymhan wrote: post #104

Earlier quoted context omitted.

The warning is designed to let people know that who you're talking to can't be proven, which is important when someone tries to impersonate a bank, or your email provider, or any other number of important sites.

CA-signed certificates don't prove you're talking to who you think you are either as any CA trusted by your browser/OS can sign any certificate.

Yes. That's not perfect. But it raises the bar for forgery to "can sign certificates as a root authority", which is still fairly high. (e.g. I can't do it, and neither can you.) It stops coffee shop/hotel wifi operators and mobile providers from injecting content into your session.

If we encourage users to blindly accept self-signed certificates (giving us end-to-end encryption but sacrificing identification), nothing would stop those actors from altering your HTTPS sessions as easily as they alter your HTTP sessions today. It's throwing the baby out with the bathwater.

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

#135

Post by schoen »

jackalope wrote: post #132
schoen wrote: post #105

Earlier quoted context omitted.

There are lots of different barriers to adoption. With this project we are attacking several of them at the outset, including the cost of obtaining a certificate, and the inconvenience or difficulty of obtaining and installing it for users who don't do that every day. Because of the open protocol we also aspire to support users with more complex configurations and requirements, who are absolutely welcome and encourag…

My concern is that your reach is too far. Asking domain administrators to trust your software to manipulate private keys (and server configurations) is as troubling as asking end users to click past security warnings. The whole purpose of the CSR is to obtain the signed certificate without putting the private key at risk. This decoupling isolates the challenge of identity verification in a reasonable place (nobody is…

Oh, our software does NOT send the private key to the CA. Never never never never. The point of having it manage the keys is not to give us access to them, it's to be convenient for the end-user, on the end-user's own system, under the end-user's control.

You can tell because our software is open source, written in Python.

https://github.com/letsencrypt/lets-encrypt-preview

We expect the users to get this software from their operating system repos, like from the Debian package repository -- the very same place they get their Apache or Nginx packages. We are not asking people to get the software directly from us, or to use it without being able to read it and check that it's safe and does what they want.

Edit: And if you want to implement your own client, we encourage you to do that -- the more clients the merrier!

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

#136

Post by srj »

tatterdemalion wrote: post #40
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…

The warning pages are really ridiculous. Why doesn't every HTTP page show a warning you have to click through? But it's not like MITM attacks are not real. CAs don't realistically do a thing about them, but it is true that you can't trust that your connection is private based on TLS alone. (unless you're doing certificate pinning or you have some other solution).

Eventually maybe the browsers will do that. Currently far too many websites are HTTP-only to allow for that behavior, but if that changes and the vast majority of the web is over SSL it would make sense to start warning for HTTP connections. That would further reduce the practicality of SSL stripping attacks.

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

#137

Post by medmunds »

cmwright wrote: post #34
jadavis wrote: post #29

Earlier quoted context omitted.

If each domain name can get a non-wildcard cert for free, quickly, why do you need wildcard certs? For multi-subdomain hosting on one server? Just wondering.

For my previous use cases, it's ideal for dynamically created subdomains of a web application. If I know ahead of time, it's easy to grab a cert for any subdomain. However if a user is creating subdomains for a custom site or something similar, it's much nicer/easier to have the wildcard cert.

The lets-encrypt demo makes it look like you could easily script cert acquisition for new subdomains. And the CA domain validation appears to be totally automated (and fast).

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

#138

Post by acveilleux »

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.

If you can make microsoft.com serve up the correct challenge response, you'll be able to get a cert for them issued by the this project. This isn't a pure rubber-stamping service.

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

#139

Post by mike-cardwell »

I'm hoping that one day soon, I'll be able to remove this line from my nginx config:

  ssl_certificate /path/to/file.crt;
My web server will notice that I want SSL, but haven't specified a path to a cert. It will then go off and generate one and get it signed automatically using an API like the one being discussed. It will also handle renewing automatically when the time comes.

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

#140

Post by [deleted] »

lazyjones wrote: post #92
iancarroll wrote: post #79

Earlier quoted context omitted.

The NSA has no CA. The only attack they really have is brute force or server compromise - both of which undermine pinning.

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

[deleted]
Post reply on HN