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

Our First Certificate Is Now Live

letsencrypt.org

Post reply on HN
Print view View original

41–50 of 263 posts

Re: Our First Certificate Is Now Live

#41

Post by schoen »

toomuchtodo wrote: post #18
tokenizerrr wrote: post #14

Earlier quoted context omitted.

This is not what regular style certificates verify. That is what Extended Validation certificates verify and they're not issued by letsencrypt.org and generally are a lot more expensive. The only thing that regular-style certificates verify (this is what current CAs do, you can also grab a free one with automatic validation at https://www.startssl.com/ ) is that the person who controls the domain name has requested t…

> This is not what regular style certificates verify. That is what Extended Validation certificates verify and they're not issued by letsencrypt.org and generally are a lot more expensive. I'd like to see LetsEncrypt move into this territory though. What current private business providers are charging for this service is border-line extortion.

EV validation will have a marginal cost because of the offline interactions. DV can be done at almost no marginal cost. That's why Let's Encrypt can exist at all.

Re: Our First Certificate Is Now Live

#42

Post by dragonwriter »

Someone1234 wrote: post #2

This is a tiny bit odd. So they have issued their first certificate, but they don't have cross-signing in place yet? So between now and november 16th they'll be issuing a whole bunch of effectively broken certificates unless people manually install their root CA? Why even push this today if you don't have cross-signing available? Without that Let's Encrypt is effectively broken out of the box. PS - I actually like Le…

You keep saying the word "broken" when nothing is broken at all, just the certificates are only useful in limited contexts.

Re: Our First Certificate Is Now Live

#43

Post by kodablah »

ck2 wrote: post #23

Everyone repeat after me, wildcards, wildcards, wildcards. (just hoping they will appear next year) One more nail in the coffin of the ssl cert mafia.

While I too would like to see wildcards, doesn't the fact that you can programmatically obtain a cert for a subdomain obviate most of the wildcard needs? Sure it's a bit more difficult but if your service has some form of sorts to make a subdomain work for a specific word, surely it can request the cert at that time. Having said that, obviously keeping track of only one cert and not having to build this into your apps is much more preferred.

Re: Our First Certificate Is Now Live

#44

Post by RyanZAG »

Does anybody know if there is any protection built in against MITM or DNS poisoning attacks?

It feels like this makes network hop security far more important. If I'm able to insert a MITM or DNS poisoning anywhere between where letsencrypt.org's servers are and where it thinks the requesting server should be then I can generate a false certificate.

For example, Amazon's DNS resolves for letsencrypt as 1.2.3.4 which routes along a set path - say 2.3.4.5 and 3.4.5.6. To verify that I control amazon.com, letsencrypt is going to try and fetch http://1.2.3.4/something (through DNS resolving). If I can get MITM access on 2.3.4.5 and pass back /something to the request, letsencrypt is going to generate a certificate for me that I can use to say I am amazon.com for the entire world.

Is there any protection against this built into letsencrypt for this? Maybe checking if amazon.com already has https:// ? Although I'm not sure if there is any way to get around a DNS poisoning attack...

In essence, this seems to mean that you can take a single successful MITM and turn it into a globally authorized MITM. Right?

Re: Our First Certificate Is Now Live

#45

Post by ck2 »

bracewel wrote: post #36
ck2 wrote: post #23

Everyone repeat after me, wildcards, wildcards, wildcards. (just hoping they will appear next year) One more nail in the coffin of the ssl cert mafia.

The major problem with this is that the IETF validation working group hasn't come up with a definite procedure for deciding what the apex of a domain is, and how to validate control over all subdomains above it yet.

That's what Domain Validation (DV) is for and what most less-expensive wildcards use.

Re: Our First Certificate Is Now Live

#46

Post by bracewel »

dtech wrote: post #39
bracewel wrote: post #36

Earlier quoted context omitted.

The major problem with this is that the IETF validation working group hasn't come up with a definite procedure for deciding what the apex of a domain is, and how to validate control over all subdomains above it yet.

Doesn't ownership of domain.tld also imply ownership of *.domain.tld?

That's the relatively simple case, but there are a number of corner cases that make the process much more complicated.

See https://github.com/letsencrypt/acme-spec/pull/97 for a discussion of why this was scraped from the ACME specification proposal.

Re: Our First Certificate Is Now Live

#47

Post by superuser2 »

RyanZAG wrote: post #44

Does anybody know if there is any protection built in against MITM or DNS poisoning attacks? It feels like this makes network hop security far more important. If I'm able to insert a MITM or DNS poisoning anywhere between where letsencrypt.org's servers are and where it thinks the requesting server should be then I can generate a false certificate. For example, Amazon's DNS resolves for letsencrypt as 1.2.3.4 which r…

Any CA performing domain ownership validation would be vulnerable to the same thing. If you can fake its WHOIS requests or make it appear as if the domain making the request does in fact have the "canary" file they told you to host to prove ownership, then you can get any CA to give you a cert for any site.

You have to trust something.

Re: Our First Certificate Is Now Live

#48

Post by 0x0 »

RyanZAG wrote: post #44

Does anybody know if there is any protection built in against MITM or DNS poisoning attacks? It feels like this makes network hop security far more important. If I'm able to insert a MITM or DNS poisoning anywhere between where letsencrypt.org's servers are and where it thinks the requesting server should be then I can generate a false certificate. For example, Amazon's DNS resolves for letsencrypt as 1.2.3.4 which r…

You can already do that today with most CAs.

They may do domain validation by looking up WHOIS and emailing the contact address there.

You could MITM the DNS MX lookup and respond with an IP address of an SMTP server you control, and grab the validation code in the verification email as it is dutifully delivered to you just as easily.

Edit: In fact, come to think of it... For DNS you might not even need to MITM, just be able to spoof the IP source in an UDP package and correctly guess the remote source port + possibly a query ID, and race the real DNS server? I wonder how feasible that would be at for example 1 Gbps?

Re: Our First Certificate Is Now Live

#49

Post by doppel »

ck2 wrote: post #23

Everyone repeat after me, wildcards, wildcards, wildcards. (just hoping they will appear next year) One more nail in the coffin of the ssl cert mafia.

I can absolutely understand the need for this, but until then with a bit of code and the automated workflow you could make requests for new subdomains on-the-fly.

Re: Our First Certificate Is Now Live

#50

Post by icebraining »

jonknee wrote: post #35

It's amazing that it takes a free provider to make things simple: https://letsencrypt.org/howitworks/ I'd actually pay more than I do now for SSL certs to get that kind of simplicity.

SSLMate seems pretty easy as well: https://sslmate.com/

(No affiliation, I just saw their HN post some time before)

Post reply on HN