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

Let's Encrypt: How It Works

letsencrypt.org

Post reply on HN
Print view View original

61–70 of 123 posts

Re: Let's Encrypt: How It Works

#61

Post by organsnyder »

schoen wrote: post #42
akerl_ wrote: post #38

Earlier quoted context omitted.

Yes, I need to trust some things. But I can limit the amount of trust I need to have by limiting the number of things to run. I can add a reminder to my calendar to say "hey renew your certs", or better yet I can add a check to my existing monitoring service to look at expiration dates. Why run a whole new persistent service just for this?

There won't be any sort of requirement to allow our tools to run automatically. But the existing track record of expiring certs suggest that some people are having trouble remembering to do the renewals manually, so it may be useful to have a tool that does it automatically for people who want that.

The vast majority of sites fall into the category of "encryption would be nice, but not worth the time." All of my hobby sites (various forums, a site for my choir, etc.) fall into that category. Automagic TLS done right is an improvement from no TLS, IMHO, even if it comes with its own new set of potential attack vectors.

Re: Let's Encrypt: How It Works

#63

Post by iancarroll »

organsnyder wrote: post #57
iancarroll wrote: post #37

Earlier quoted context omitted.

> I guess that means for users setting up certs for the first time they can't just put some content up on example.com and need to use DNS or something else to prove ownership. FYI, CAs do this already (HTTP validation), but an easy fix is to generate a self signed cert and pass the fingerprint of it to the CA.

Not sure how the self-signed cert would make things better. Couldn't an MITM attacker do the exact same thing? Presumably, the MITM attacker would already be the party making the (fraudulent) request to the CA, so they could submit their own fingerprint.

I suppose you're correct, I wasn't thinking that the attacker would also submit the request. I guess if you're MITMing CA requests you're screwed anyhow.

Re: Let's Encrypt: How It Works

#65

Post by grey-area »

Great project to smooth out the really painful process at present for acquiring certs. How about an FAQ page or a few clarifications?

Things I wanted to know which were not immediately apparent:

Will it be broadly accepted from day one? Yes, apparently, though see the identrust issue below.

Will it generate a keypair but keep the private key on your server? Yes.

Will it work without having to babysit an interactive prompt? Yes.

Will it just let you generate key,csr,crt and do your own config changes? Yes.

Questions I still don't know the answer to:

Will it provide wildcard certs? No idea. I'd love it to be true as this is the part of current CA's which really irks me - the price gouging over something which costs them nothing more to provide. Can't see anything on the website about it.

How does it auto-renew, does it have to run all the time?

Why is the cert for identrustssl not trusted in Chrome or Safari? That doesn't inspire confidence : https://www.identrustssl.com/

Can every CA support issuing certs this way please? :)

Re: Let's Encrypt: How It Works

#66

Post by mappu »

Wilya wrote: post #4
radiospiel wrote: post #2

I am somewhat excited about letsencrypt, but isn't ownership verification via DNS not a bit, hmm, strange? After all, a proper certificate should defend against MITM attacks; so if an attacker would be able to take control over the target's DNS, he could easily create a certificate, which looks legit for all intended purposes. Or do I miss something in that regard?

Ownership verification is already done via DNS by existing CAs. If an attacker has full control over your DNS, he can already change the DNS records and trick a CA into delivering him a genuine certificate. This isn't really a MITM attack.

What existing CA's offer this?

The ones i've used (godaddy, startssl, namecheap/ssls.com rapidssl/positivessl) all wanted email verification iirc.

EDIT: of course that's equivalent to verifying the MX. Never mind!

Re: Let's Encrypt: How It Works

#67

Post by adamtj »

tedunangst wrote: post #21

Unfortunate choice of wording. From the web page: > Obtain a browser-trusted certificate and set it up on your web server From the "RFC" on github: > In the background, the web server contacts the CA and uses ACME to request that a certificate be issued for the intended domain name(s). > Once the CA is satisfied, the certificate is issued and the web server automatically downloads and installs it, potentially notifyi…

They're generating the certificate, not the keys. Those are different things. You can probably think of the certificate as the computer equivalent of photo ID for the server.

They both show who you are (Driver's License: your name, cert: hostname), what you look like (DL: photo of you, cert: the key's fingerprint) and provide proof that they are genuine (DL: difficult and illegal fake, cert: practically impossible to do the math to forge a signature).

Note that they mention certificate singing requests. If the CA generated the keys, it wouldn't also need a CSR. It could just generate and send you the public and private keys and the signed certificate for them. However, it does need some information about the keys it's signing. You provide that information in the form of a CSR.

Re: Let's Encrypt: How It Works

#68

Post by mappu »

schoen wrote: post #39
schizoidboy wrote: post #34

Great project! Please also provide a yum repository and instructions (and any others you feel are popular enough). You may want to look at the way SSLMate does it, with an operating system drop down selection (Debian, Ubuntu, RedHat, Arch, Mac, Other).

We are actually hoping to have packages shipping from the official OS repositories, so you won't even have to get the package from us. (If anyone wants to help with this aspect, please get in touch.)

Is it possible to get new packages into Jessie post-freeze?

Re: Let's Encrypt: How It Works

#69

Post by ZoFreX »

organsnyder wrote: post #57
iancarroll wrote: post #37

Earlier quoted context omitted.

> I guess that means for users setting up certs for the first time they can't just put some content up on example.com and need to use DNS or something else to prove ownership. FYI, CAs do this already (HTTP validation), but an easy fix is to generate a self signed cert and pass the fingerprint of it to the CA.

Not sure how the self-signed cert would make things better. Couldn't an MITM attacker do the exact same thing? Presumably, the MITM attacker would already be the party making the (fraudulent) request to the CA, so they could submit their own fingerprint.

You are positing a MITM on the CA though, which is a bit trickier than MITM'g a user, I would have thought?

Re: Let's Encrypt: How It Works

#70

Post by ZoFreX »

cmwright wrote: post #8
haroldp wrote: post #7

It seems like the one thing this doesn't/can't address is the IP shortage. Does help much if example.com is virtual hosted on the same IP address as 100 other sites?

The SNI stuff ( http://en.wikipedia.org/wiki/Server_Name_Indication ) helps with this if you can do without XP support.

And also Android 2.3 stock browser support.
Post reply on HN