Live data from Hacker News

ACME v2 and Wildcard Certificate Support is Live

community.letsencrypt.org

91–100 of 321 posts

Re: ACME v2 and Wildcard Certificate Support is Live

#91
post #21

Can anyone list any negatives of Let's Encrypt? I've been using it since the start and just can't find any practical downsides.

The only significant concern I have is that if LE were to essentially "take over" the CA industry, you know, due to being free, and awesome, we'd have a massive single point of failure for the entire Internet's security model. My biggest peeve with the whole "HTTPS Everywhere" push is not the general notion of using encryption, but that the encryption is annoyingly coupled with the CA system, which is terrible for ma…

>I have is that if LE were to essentially "take over" the CA industry, you know, due to being free, and awesome, we'd have a massive single point of failure for the entire Internet's security model.

single point of failure as in, getting hacked and misiussing certificates?

Re: ACME v2 and Wildcard Certificate Support is Live

#92
post #43
post #15

Earlier quoted context omitted.

> The preferable end-of-life date for ACMEv1 should be never. As would be the preferable end-of-life date for SSLv3 and HTTP.

The SSL zealotry drives me nuts. The infosec community screams constantly about "HTTPS everywhere", but they either don't know or don't care about all the effort and pain they're creating for developers who just want their software to work. How many perfectly good sites will be marked ominously as "insecure" by Chrome in the next few months? Sites that were working just fine until someone at Big G decided they weren'…

I hear you. Moving to SSL for millions of old websites is a pain in the ass. It's a degree of effort that people often skim over.

Speaking as someone who's maintained a lightweight presence on the Web for over 20 years, I've thought about the tradeoff and I think it is worth it. Our collective original thinking about protocols skipped security and we've been suffering ever since. I was sitting in the NOC at a major ISP when Canter and Siegel spammed Usenet. Ow. Insecure email has cost the world insane amounts of money in the form of spam. Etc., etc., etc.

You and I probably disagree on the cost/benefit analysis here, which is OK. It'd be helpful in discussion if advocates on both sides refrain from assuming zealotry on the other side.

Re: ACME v2 and Wildcard Certificate Support is Live

#93

Earlier quoted context omitted.

That has to be balanced against the potential pain for users who will be accessing that software whilst vulnerable to having that information snooped or modified. Perhaps for social engineering purposes, perhaps to serve up the latest zero-day, perhaps just for the lulz... who knows? SSL has a history of being a pain in the ass. There are a lot of pain in the ass implementations out there. Everyone gets that. At the…

Your closing argument is essentially “if you’re not with us, you’re against us.” which sounds like quite the zealots argument to me.

Only because having your stuff SSL'ed (not snoopable) is a binary state. And while you might have business reasons for not doing it, putting those above your user's safety is just plain negligent. In the same way that storing plaintext passwords and sending them around via email, or using SMS as a two factor authentication method is negligent.

So in a way, you're right. I'm not sure why that's a negative.

Re: ACME v2 and Wildcard Certificate Support is Live

#94
post #37

Earlier quoted context omitted.

The encryption part is easy -- you don't need CAs for that -- but they're a necessary evil when it comes to verifying ownership. You need to delegate trust to someone , otherwise using the internet becomes too cumbersome.

Automated SSL providers effectively mitigate the idea of "verifying ownership" or "delegating trust", because for example, someone can buy a domain like... googIe.com, get an SSL cert for it, and it's "valid". We're right back to the same level of security of you just checking that the browser bar points at the domain you actually intended to go to. (In this example, bear in mind, Google doesn't use an EV cert, so th…

> We're right back to the same level of security of you just checking that the browser bar points at the domain you actually intended to go to.

So you’re sitting in a cafe, and you go to Facebook.com. Lo and behold, someone’s installed a MITM proxy on the router, that presents its own encryption key instead of Facebook’s, and your browser has no way to tell this because the CA system isn’t a thing. They now have your password, can steal your session to spam your friends, whatever else. How do you prevent that?

Automated domain validated certificates are meant to ensure that when you go to Facebook.com, you’re talking to Facebook.com and not a MITMing router on the way there. They’re not meant to protect against phishing - they’re meant to protect against the very real cases I’ve seen where my mobile ISP adds random JavaScript into the web pages I view, and sells information about me based on my use of the web.

Re: ACME v2 and Wildcard Certificate Support is Live

#95
post #74

One of the wonderful aspects of this, that no-ones pointed out yet, is that these can used for INTERNAL domains, without you having to run your own internal CA. i.e. lets say your internal network DNS domain is 'my-company-lan.com' - all you have to do is ensure that 'my-company-lan.com' is also registered in public DNS[1], and then you can secure ALL your internal services using a free LE wildcard cert, that's autom…

You could do this before too, without wildcards.

Re: ACME v2 and Wildcard Certificate Support is Live

#96
post #55
post #49

Earlier quoted context omitted.

> developers who just want their software to work. Those devs are gonna be really surprised when they find out that unencrypted connections are routinely tampered with. > they either don't know or don't care about all the effort and pain they're creating You have not been paying attention to the hundreds of tools available to make HTTPS painless. > until someone at Big G decided they weren't. And Mozilla. And countle…

> Those devs are gonna be really surprised when they find out that unencrypted connections are routinely tampered with. Except most big orgs now employ MitM tools like BlueCoat to sniff SSL connections too. > You have not been paying attention to the hundreds of tools available to make HTTPS painless. I have, and they don't. They make it easier, but you know what's truly painless? Hosting an html file over HTTP. What…

Oh, so you know better than me what kind of content is on my site? So a static site with my resume needs SSL then to protect the other users?

Absolutely yes. Without that layer of security, anyone looking at your resume could either be served something that's not your resume (to your professional detriment) or more likely, the malware-of-the-week. (Also to your professional detriment).

Do you care for the general safety of web users? Secure your shit. If not for them, for your own career.

Re: ACME v2 and Wildcard Certificate Support is Live

#98
post #80
post #74

One of the wonderful aspects of this, that no-ones pointed out yet, is that these can used for INTERNAL domains, without you having to run your own internal CA. i.e. lets say your internal network DNS domain is 'my-company-lan.com' - all you have to do is ensure that 'my-company-lan.com' is also registered in public DNS[1], and then you can secure ALL your internal services using a free LE wildcard cert, that's autom…

Going to reply to my own comment here. It's at this point that I swear profusely at Microsoft yet again, for pushing the concept of '.local' domain suffixes a decade ago. As it's not a legal TLD, I can't get certs for any of my internal services without rolling my own internal CA, which only works automatically for Windows domain machines, and not for anything else.

The ".local" suffix was a terrible idea, to be sure. Active Directory domain rename in small environments is relatively painless.

Re: ACME v2 and Wildcard Certificate Support is Live

#99
post #55
post #49

Earlier quoted context omitted.

> developers who just want their software to work. Those devs are gonna be really surprised when they find out that unencrypted connections are routinely tampered with. > they either don't know or don't care about all the effort and pain they're creating You have not been paying attention to the hundreds of tools available to make HTTPS painless. > until someone at Big G decided they weren't. And Mozilla. And countle…

> Those devs are gonna be really surprised when they find out that unencrypted connections are routinely tampered with. Except most big orgs now employ MitM tools like BlueCoat to sniff SSL connections too. > You have not been paying attention to the hundreds of tools available to make HTTPS painless. I have, and they don't. They make it easier, but you know what's truly painless? Hosting an html file over HTTP. What…

> Care to link a few?

From Friday, in which Turkey takes advantage of HTTP downloads to install spyware on YPG computers: https://citizenlab.ca/2018/03/bad-traffic-sandvines-packetlo...

From a couple months ago, where Comcast injects JavaScript into HTTP connections: http://forums.xfinity.com/t5/Customer-Service/Are-you-aware/...

Re: ACME v2 and Wildcard Certificate Support is Live

#100
post #92
post #43

Earlier quoted context omitted.

The SSL zealotry drives me nuts. The infosec community screams constantly about "HTTPS everywhere", but they either don't know or don't care about all the effort and pain they're creating for developers who just want their software to work. How many perfectly good sites will be marked ominously as "insecure" by Chrome in the next few months? Sites that were working just fine until someone at Big G decided they weren'…

I hear you. Moving to SSL for millions of old websites is a pain in the ass. It's a degree of effort that people often skim over. Speaking as someone who's maintained a lightweight presence on the Web for over 20 years, I've thought about the tradeoff and I think it is worth it. Our collective original thinking about protocols skipped security and we've been suffering ever since. I was sitting in the NOC at a major I…

Yeah, I'm not opposed to HTTPS. In fact, the reason I get frustrated is because, like you, I've dealt with it at scale for years. I agree it should be used most places, but what about static documentation sites? What about blogs? I've even used Let's Encrypt a few times, and it seems like a great service. But who wants to set up that machinery for a simple resume site?

That machinery has a cost. With every barrier we throw up on the web, it makes it harder to build a reliable site. I also realize this is an argument I've lost. It's so much easier to just say "HTTPS everywhere" than to examine the tradeoffs.

Oh well.

Post reply on HN