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

ACME v2 and Wildcard Certificate Support is Live

community.letsencrypt.org

Post reply on HN
Print view View original

191–200 of 321 posts

Re: ACME v2 and Wildcard Certificate Support is Live

#191

Post by staticfish »

hamandcheese wrote: post #68
shawabawa3 wrote: post #14

Earlier quoted context omitted.

> I recon some of these providers are going under soon? I really hope so. The cost to providers is exactly the same for a wildcard and a standard certificate, and yet they costs hundreds of dollars. It's unbelievable it's lasted this long

It’s not that unbelievable, what software service are you aware of that is sold at only it’s marginal cost?

It's not "software" in the historic sense, like buying Photoshop or a paying for hosted Slack service. It's literally a command to generate a certificate from their root CA chain.

Yes there's obviously business costs, and they have to employ people to do verification, etc (which they often do a terrible job at), but I think you see what the parent is getting at..

Re: ACME v2 and Wildcard Certificate Support is Live

#192

Post by EtDybNuvCu »

mynameisvlad wrote: post #187
Karunamon wrote: post #96

Earlier quoted context omitted.

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 saf…

So I've heard this argument countless times, and it completely makes sense from a theoretical perspective. Yes, it's very possible for MitM to happen, and that would cause one of the two scenarios you described. But how likely is it to actually happen? For the former, someone would need to target both you and specifically the person who you think will view your resume, and that's, let's be honest, completely unlikely…

I have been MitM'd by my ISP, Comcast, multiple times. Their injection only works on HTTP without TLS.

Re: ACME v2 and Wildcard Certificate Support is Live

#193

Post by orf »

vbezhenar wrote: post #182
orf wrote: post #88

Earlier quoted context omitted.

It's like one apt package and one cronjob away. I think some acme clients even do the Cron handling for you. So, like one command. There is a really great acme client written in bash which is incredibly painless to set up. Literally in the time you've spent thinking about and composing your reply you could have implemented free, secure TLS for your users.

It's not that easy if you don't want to run public http server. I had to write acme client myself because I didn't find a single one simple enough. I spent weeks doing that, comparing to 5 minutes issuing 3-year certificate from wosign when it was a thing. I hate that Google destroyed every free ssl certificate issuer and pushed their child to further dominate the world.

https://github.com/Neilpang/acme.sh does exactly what you want.

Re: ACME v2 and Wildcard Certificate Support is Live

#194

Post by classichasclass »

schoen wrote: post #33
Siecje wrote: post #27

Earlier quoted context omitted.

When you run the Let's Encrypt official client (certbot), it updates itself.

Only if you use certbot-auto, not if you use an OS package. (I'm on the Certbot team.) Also, some people dislike this feature quite a bit, and there are about 100 different clients. https://letsencrypt.org/docs/client-options/

And some people take clients like acme.sh and modify them. I do that myself.

There's enough entrenched inertia to HTTPS without giving people more ammunition regarding the actual amount of work involved. Unless there's a security reason to eliminate the v1 endpoint, please don't.

Re: ACME v2 and Wildcard Certificate Support is Live

#195

Post by mynameisvlad »

EtDybNuvCu wrote: post #192
mynameisvlad wrote: post #187

Earlier quoted context omitted.

So I've heard this argument countless times, and it completely makes sense from a theoretical perspective. Yes, it's very possible for MitM to happen, and that would cause one of the two scenarios you described. But how likely is it to actually happen? For the former, someone would need to target both you and specifically the person who you think will view your resume, and that's, let's be honest, completely unlikely…

I have been MitM'd by my ISP, Comcast, multiple times. Their injection only works on HTTP without TLS.

Sure, I've heard of the Xfinity MitMs which IIRC tracked users in some way. But would that realistically cause any "professional detriment" as expressed by the parent comment? Most users wouldn't even notice it's happening.

Basically, I see it this way:

- You can be MitMed broadly, like the Xfinity case, but the company in question can't really do anything crazy like inject viruses or do something that would cause the user to actually notice because then their ass is going to be on the line when it's exposed that Comcast installed viruses on millions of computers or stole everyone's data.

- Or you can be MitMed specifically, which will cause professional detriment, but would require someone to specifically target you and your users. And I don't see this as that likely for the average Joe.

Really, what I would like to know is: How realistic is it that I, as a site owner, will be adversely affected by the MitM that could theoretically happen to my users on HTTP?

Re: ACME v2 and Wildcard Certificate Support is Live

#196

Post by level3 »

blibble wrote: post #46
0x0 wrote: post #17

DNS providers and domain name registration companies are probably going to get pestered about API access for updating TXT DNS records now... :)

is it common for DNS hosts to provide delegated access at the granularity of individual records? I don't want my webserver to have the ability to change my entire zonefile just so it can authorise certificates!

Not sure if it will work for your use case, but you can also CNAME the _acme-challenge record to a different domain (or a subdomain with a separate zonefile), dedicated only to authorizing certificates.

Re: ACME v2 and Wildcard Certificate Support is Live

#197

Post by georgebashi »

deathanatos wrote: post #156
mholt wrote: post #114

Earlier quoted context omitted.

But issuing 3-year certificates would disqualify them as a CA: https://cabforum.org/wp-content/uploads/CA-Browser-Forum-BR-...

Can you elaborate as to why that would disqualify them? I don't think most of us are intimately familiar with the Baseline Requirements, or want to wade through 60-some pages to figure out your reasoning.

The maximum validity for a cert was recently changed to two years.

Re: ACME v2 and Wildcard Certificate Support is Live

#198

Post by slrz »

merb wrote: post #174
jsmthrowaway wrote: post #76

Earlier quoted context omitted.

What the gently caress does encrypting an HTTP connection have to do with morals or age? You are way outside the realm of making sense, man, and offer commentary that is openly harmful to securing the Internet. Please step back and revisit your woefully misinformed opinion on this. Most people who advocate for security, including myself, have worked on small teams and understand the resources involved. Putting a TLS…

> Putting a TLS certificate on your shit with LE takes minutes. Doing it through another CA is minutes if you have one server, yes. else it's the other way around, because if you have multiple servers you need to do a lot of fancy stuff. And LE also does not work in your internal network if you do not have some stuff publicy accessible. And it also does not work against different ports. Oh and it's extremly hard to h…

You can use Let's Encrypt certificates for non-publicly reachable hosts by using the dns-01 challenge type. That, of course, means that you need some way of properly automating your DNS infrastructure to add the necessary TXT records which, admittely, is sadly not the case in many organizations. It's a solvable problem, though.

I don't understand your last point. Where do you see the problem with letting a reverse proxy talk to a TLS backend? You get the requested server name from the SNI extension and can use that to multiplex multiple names onto a single IP address. The big bunch of NATty failure cases apply to plaintext HTTP just as well, no?

Re: ACME v2 and Wildcard Certificate Support is Live

#199

Post by berbec »

eric_b wrote: post #43
mholt wrote: 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'…

Did you file a bug report on the Mozilla site about forcing HTTPS?

Re: ACME v2 and Wildcard Certificate Support is Live

#200

Post by slrz »

josteink wrote: post #171
jakelazaroff wrote: post #166

Earlier quoted context omitted.

I don't get the notion that some sites don't "need" HTTPS. The threat model it protects against isn't only sensitive information being intercepted, it's also man-in-the-middle attacks that actually change what's delivered. Maybe a hobbyist website only has text and images sitting on its server, but the visitor might receive malware — and that can happen to literally any site served over HTTP.

> I don't get the notion that some sites don't "need" HTTPS. Your failure to grasp this is fairly evident from the rest of your comment.

Plaintext HTTP being fine for delivering public documents might have been true 10 or 20 years ago. Sadly, attacks on and uninvited mutation/corruption of plaintext content has become that super-common (at least in some parts of the world) that you can be almost certain that one or more of your users will be affected by it if you're not taking precautions.

It sucks badly. I'd prefer a less hostile network myself. Even back then there were bad actors but at least you could somewhat count on well-meaning network operators and ISPs. Nowadays it's ISPs themselves that forge DNS replies and willfully corrupt your plaintext traffic to inject garbage ads and tracking crap into it. And whole nation states that do the same but for censoring instead of ad delivery.

Post reply on HN