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

191–197 of 197 posts

Re: Milestone: 100M Certificates Issued

#191

Post by giobox »

nlawalker wrote: post #190
giobox wrote: post #140

Earlier quoted context omitted.

One annoying thing I've seen less technical stakeholders ask about with letsencrypt is "why the padlock isn't green" in Safari/Edge. Unlike Chrome and I think Firefox, those browsers only display a green padlock for SSL certs with EV, which of course letsencrypt doesn't (and arguably can't really) do. The "grey padlock" for an otherwise perfectly valid certificate seems to confuse a very small subset of users, especi…

>> only to trust "green padlocks" It's not so much about browser-specific behavior, it's about using the padlock to ensure that the company or other entity you're interacting with is the one you wanted, as opposed to only ensuring that the server you're talking to is the one indicated in the address bar. A gray padlock is better than none, but telling less technically-inclined, clicks-all-the-links, fat-fingered user…

Given how piecemeal the use of EV certs is by big companies, I'm not sure EV as implemented today delivers any 'real' benefits. It absolutely is about browser specific behaviors. How can you tell users only to interact with companies if they have an EV certificate, when huge internet properties like Amazon, Google and Facebook don't use them? In reality you can't, which means Safari/Edge's behavior arguably doesn't really help anyone. I'm not saying Safari/Edge shouldn't tell the user an EV certificate is present, they absolutely should, but that the approaches used by rival browsers arguably make more sense.

I think Chrome/Firefox got this one right by using a green padlock for both valid EV _and_ DV certificates like Letsencrypt, displaying the extra EV information clearly inline in the URL bar if it is present. The changing color in Safari/Edge can give the impression that the the non-EV certificate is somehow less secure, which in technical terms is not the case. Questions of identity verification and security of data transmission are two separate issues which the Safari/Edge approach arguably conflates - both EV and DV can provide equal security of transmission, even if only EV provides some degree of identity confirmation.

As a user, it's simply not possible to make the distinction too - if I visit your fake Bank Of America site with a grey padlock, how can I even be sure the 'real' site had an EV certificate and a green one, when there's so many companies that don't? As a user you are effectively forced to treat the grey and green padlocks the same, so why not make them the same color and display extra EV info if it is there, like the other browsers?

Re: Milestone: 100M Certificates Issued

#192

Post by nlawalker »

giobox wrote: post #191
nlawalker wrote: post #190

Earlier quoted context omitted.

>> only to trust "green padlocks" It's not so much about browser-specific behavior, it's about using the padlock to ensure that the company or other entity you're interacting with is the one you wanted, as opposed to only ensuring that the server you're talking to is the one indicated in the address bar. A gray padlock is better than none, but telling less technically-inclined, clicks-all-the-links, fat-fingered user…

Given how piecemeal the use of EV certs is by big companies, I'm not sure EV as implemented today delivers any 'real' benefits. It absolutely is about browser specific behaviors. How can you tell users only to interact with companies if they have an EV certificate, when huge internet properties like Amazon, Google and Facebook don't use them? In reality you can't, which means Safari/Edge's behavior arguably doesn't r…

I agree with you. My point - which I admittedly didn't state very well - is that the best-practice messaging to non-technical users needs an update. In the earlier days of the web, it was as simple as "look for the padlock," because the state of SSL was such that generally only legit sites had it. With the presence of LE and the overall failure of the "web of trust", this is no longer good advice - they need to carefully double-check the address bar as well.

Re: Milestone: 100M Certificates Issued

#193

Post by pas »

eropple wrote: post #121
pas wrote: post #32

And most of that is because LE [still] doesn't issue wildcard certs, nor does it really plan to :(

And that is a without-exception good thing. Wildcard certificates are dangerous and encourage bad practices around SSL. You shouldn't use them. Instead, you should fix your workflow to know exactly what domains you have and have active and use automated tooling to provision them correctly.

Currently security sandboxing happens basically per Origin. Since schema and port is fix, and I don't want to force every user/potential-user/demo-user/anon to register a domain (so the LE rate limit doesn't apply, and nobody want's bloated 100 SAN certs).

I know the names, but rerolling a cert takes time, takes up resources, etc.

Re: Milestone: 100M Certificates Issued

#194

Post by philliphaydon »

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…

So the Low risk of compromise for most people is more important than the ability to easily maintain a system? If a certificate is going to be compromised it's most likely going to be the most important cert to the system anyway. A hacker isn't going to go after the meaningless ones. But by your logic I should increase the maintainability of the system for no benefit.

Obviously this is highly dependent on the usage of the certs to begin with.

Re: Milestone: 100M Certificates Issued

#195

Post by niutech »

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…

> Automated SSL certificate generation and deployment via LetsEncrypt with zero human intervention

Unless you are on a shared hosting, which is still one of the most popular options.

Re: Milestone: 100M Certificates Issued

#196

Post by [deleted] »

tokenizerrr wrote: post #156
cyphar wrote: post #136

Earlier quoted context omitted.

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.

[deleted]
Post reply on HN