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

Milestone: 100M Certificates Issued

letsencrypt.org

Post reply on HN
Print view View original

151–160 of 197 posts

Re: Milestone: 100M Certificates Issued

#151

Post by eropple »

twothamendment wrote: post #149
eropple wrote: post #139

Earlier quoted context omitted.

I don't believe LE has an upper limit on its number of SANs. For systems not explicitly public, whitelists are almost always better than blacklists.

> I don't believe LE has an upper limit on its number of SANs. The limit is 100, unless they removed that when I wasn't looking. Back in the beta I tried one domain, a handful and then, because I couldn't find a technical reason why SAN should be limited, I tried 500. It fails. I have many certs with up to 100 and would be happy if this changed.

The highest I've seen in the wild is 60 or so, so I'll bow to your superior getting-bitten-in-the-ass-by-it. =)

(And if so, in the prior commenter's situation--okay, create three certs. LE might not support 300 certs, but 3 with 100 SANs should work just fine.)

Re: Milestone: 100M Certificates Issued

#152

Post by scaryclam »

steven777400 wrote: post #102
TekMol wrote: post #40

Earlier quoted context omitted.

I have read that, but it seems overly complicated. Why not just give the domain owner a private key and a script that is a few lines long. So he can sign a message from them and prove he has the key?

How do we know that the recipient of the key in your scenario (or the originator of the CSR) is in fact the domain owner? The domain contains contact information, but the exchange can't be done by email - that's not secure. Can't be done by SMS - that's not secure. We don't know them personally, so there's no obvious out-of-band technique that can be used. We'd have to go back to physical snail mail using the address…

I quite like using DNS verification for this sort of thing.

Re: Milestone: 100M Certificates Issued

#153

Post by tokenizerrr »

eropple wrote: post #123
philliphaydon wrote: post #120

Earlier quoted context omitted.

Why is providing wildcard certs not secure???? Amazon seems to do it?

Because once your wildcard certificate is compromised--and you must design systems with the assumption that your certificates will be compromised--it becomes a very achievable exercise to use that wildcard certificate to compromise users going to any of your subdomains. With each domain governed under its own TLS certificate, you install firebreaks between systems to contain the damage an attacker can do. There are v…

Meanwhile SAN is fine? The alternative to wildcards is that you get a single cert with tons of subdomains as alternative name. Exact same risks, yet much more hassle to add subdomains. I don't see it.

Re: Milestone: 100M Certificates Issued

#154

Post by duskwuff »

collinmanderson wrote: post #125
asenna wrote: post #58

Genuine question: Are the other smaller cert-issuing services going out of business? If not, what has been their response to LetsEncrypt? Not that all of them should survive, there are a lot of crappy services that deserved this. But I'm just trying to place myself in their CEOs position and wondering how the game plan should be.

StartSSL effectively died, and I assume LetsEncrypt was part of the reason.

No... the real reason StartSSL died was because they were acquired by another CA, Wosign, which had a number of serious security and management issues. These issues led to both CAs being distrusted by all major browsers.

https://wiki.mozilla.org/CA:WoSign_Issues

Re: Milestone: 100M Certificates Issued

#155

Post by eropple »

tokenizerrr wrote: post #153
eropple wrote: post #123

Earlier quoted context omitted.

Because once your wildcard certificate is compromised--and you must design systems with the assumption that your certificates will be compromised--it becomes a very achievable exercise to use that wildcard certificate to compromise users going to any of your subdomains. With each domain governed under its own TLS certificate, you install firebreaks between systems to contain the damage an attacker can do. There are v…

Meanwhile SAN is fine? The alternative to wildcards is that you get a single cert with tons of subdomains as alternative name. Exact same risks, yet much more hassle to add subdomains. I don't see it.

That's a fine point, if you're using SANs. With Let's Encrypt, you don't need to use a SAN so long as each of your endpoints is distinct. (If they're not, I'm uneasy with your architecture in the first place, y'know?)

However, I would also point out that wildcards allow people who aren't you to create domains that you didn't create and represent them as being from you, which is an attack vector that even SAN enumeration doesn't allow. We're talking whitelists over blacklists.

Re: Milestone: 100M Certificates Issued

#156

Post by tokenizerrr »

cyphar wrote: post #136
philliphaydon wrote: post #120

Earlier quoted context omitted.

Why is providing wildcard certs not secure???? Amazon seems to do it?

Yes, many services "seem to do it". The problem is how do you safely verify that a wildcard certificate is actually being given to the owner of that domain space? It's "trivial" to provide a certificate for a particular domain is owned by someone, but the same techniques don't work for wildcard certificates because now you're verifying only a single domain and providing certificates for an entire class of domains. If…

That SO post makes no sense to me. It claims:

> The authentication test can't merely back down one level to mysub.example.com because that isn't covered by the cert requested, and may not be under the control of the requesting agent either.

This just seems wrong. Performing the check like that seems to be a sane way to do it. If people can't control the base domain they have no business requesting a wildcard cert.

Re: Milestone: 100M Certificates Issued

#157

Post by tokenizerrr »

F_r_k wrote: post #131
twothamendment wrote: post #74

Earlier quoted context omitted.

The price is nice, but what makes it a must have for me is the ability to generate a cert with 100 domains on it and have it validated by hitting the server. The "old" way required all customers/domain owners to either give us control of their domain or to answer an email every time we needed to get a new cert. Now we've automated moving around domains between certs and generate new ones as needed. Validation by emai…

With SNI, what's the advantage of having a cert with 100 domains on it ?

Older clients. Windows XP, android 2, older java versions

Re: Milestone: 100M Certificates Issued

#158

Post by tokenizerrr »

eropple wrote: post #155
tokenizerrr wrote: post #153

Earlier quoted context omitted.

Meanwhile SAN is fine? The alternative to wildcards is that you get a single cert with tons of subdomains as alternative name. Exact same risks, yet much more hassle to add subdomains. I don't see it.

That's a fine point, if you're using SANs. With Let's Encrypt, you don't need to use a SAN so long as each of your endpoints is distinct. (If they're not, I'm uneasy with your architecture in the first place, y'know?) However, I would also point out that wildcards allow people who aren't you to create domains that you didn't create and represent them as being from you, which is an attack vector that even SAN enumerat…

SNI is not yet always an option if you have to support older clients.

It's not about if I'm using SANs anyway. It's that LE is fine with that, but not with wildcard certs.

> However, I would also point out that wildcards allow people who aren't you to create domains that you didn't create and represent them as being from you, which is an attack vector that even SAN enumeration doesn't allow. We're talking whitelists over blacklists.

Can you elaborate what you mean here?

Re: Milestone: 100M Certificates Issued

#159

Post by eropple »

tokenizerrr wrote: post #158
eropple wrote: post #155

Earlier quoted context omitted.

That's a fine point, if you're using SANs. With Let's Encrypt, you don't need to use a SAN so long as each of your endpoints is distinct. (If they're not, I'm uneasy with your architecture in the first place, y'know?) However, I would also point out that wildcards allow people who aren't you to create domains that you didn't create and represent them as being from you, which is an attack vector that even SAN enumerat…

SNI is not yet always an option if you have to support older clients. It's not about if I'm using SANs anyway. It's that LE is fine with that, but not with wildcard certs. > However, I would also point out that wildcards allow people who aren't you to create domains that you didn't create and represent them as being from you, which is an attack vector that even SAN enumeration doesn't allow. We're talking whitelists…

If you have to support older clients--definitely, SAN is your only option if you have to run on the same host. (And I sympathize, because that sucks.) At that point, though, my inclination becomes to attach a bunch more public IPs and wire up my DNS correctly to match.

> Can you elaborate what you mean here?

Me saying "this cert is valid for example.com, foo.example.com, and bar.example.com" is an incrementally better security posture than saying "this cert is valid for *.example.com". It constrains an attacker from running a phishing attack from, say, "private.example.com" or "secure.example.com". You're whitelisting what you're covering by explicitly declaring all of them.

It is incremental, but it's a thing.

Re: Milestone: 100M Certificates Issued

#160

Post by josephjrobison »

Asdfbla wrote: post #108
koolba wrote: post #43

SSL certificate from a traditional provider valid for a year: $10. SSL certificate from a traditional provider valid for two years: $20. Automated SSL certificate generation and deployment via LetsEncrypt with zero human intervention and more importantly zero human intervention to renew it going forward - priceless . --- That's the real value for me. At $10/cert, that's not even a rounding error. But manually generat…

What's the justification of traditional providers to charge for the certificates? Do they offer services or extended certificates that "Let's encrypt" doesn't or is it just a matter of "no one tried to offer it for free before"?

Is this total BS then?:

"Why pay for something that’s free, you ask? When a user visits a website that is secured with a self-signed, or free SSL certificate, most web browsers will post an error message. While some people will click “I understand the risks” and proceed to your site, it’s likely that many people will click the “Get me out of here!” button and never return.

The real problem lies in the fact that self-signed certificates are virtually unregulated. If your site is compromised, it may still appear secure; however, certificates issued by a trusted certificate authority can be revoked and therefore alert users of any potential threats."

Source: http://searchengineland.com/comprehensive-guide-ssl-certific...

Post reply on HN