Hacker News Reader

Comment by hardwaresofton | Hacker News Reader

Glad to hear this! Let's Encrypt is such an amazing resource -- it single-handedly caused a leap in internet security as well as removing what was essentially a artificially inflated (IMO) barrier to entry (for most people) to getting certs.

Has anyone set up the new wildcard certs? If so, who did you choose as your DNS 01 Challenge[0] provider? I currently do DNS through a local provider and they don't have an API so it's been out of my reach.

View on HN

For wildcard certs, I run my own DNS infrastructure, so I just created the _acme-challenge records as indicated by the first run of certbot

Are you unable to add arbitrary TXT records with your provider?

I am, but I'm trying not to do it manually -- I actually use cert-manager[0] on a tiny kubernetes cluster -- which means when I make an Ingress for an application (app.example.com) (which does what it sounds like), watcher processes kick off and go get a cert for me with http 01 validation currently. This works thanks to cert-manager being able to automate the process of setting up the proper /.well-known/xxx route with access to kubernetes features.

cert-manager also supports DNS 01, but of course they support the bigger providers (so they'll take some options and do the web requests to set up the TXT records)...

I haven't looked into it a crazy amount (since in the end I can still just make multiple http 01 validated certs), but was just curious.

[0]: https://github.com/jetstack/cert-manager/

FWIW Personally I just use the DNS RFC2136 plugin for certbot. I use bind for DNS.

Could you expand on this? You run bind on your server, then you add your own server as an (additional?) nameserver to your domain's registrar?

You can also set up a CNAME record to delegate the challenges to a provider with a supported API.

Thanks for the tip -- that sounds like a great way forward. I can't find any documentation on it however after checking the community page (https://community.letsencrypt.org/t/acme-v2-production-envir...)... Do you have a pointer to the documentation on this feature?

Thinking about it again I'm not sure that I fully understand what you were suggesting -- are you suggesting adding a CNAME for x.example.com that redirects to yyyy.different-provider.com, and letting let's encrypt follow and work it out?

I also wanted to know how everyone was trusting with their DNS requirements/how people were making the decision (cost, trust, privacy, country of origin, whatever else).

_acme-challenge.yourdomain.example CNAME whatever.name.your.txt.record.lives.at.invalid

Probably the easiest way forward if you have any infrastructure yourself is to simply delegate some subzone of one of your domains to a nameserver you run yourself (like, delegate letsencrypt.yourdomain.example to your own nameserver), then point your CNAME to a name beneath that, and configure that nameserver for dynamic updates so your LE client can change the TXT record(s) on that server as needed.

Have you tried it?

According my reading of the challenge specification [1] it shouldn't work. Notice that it says:

> 2. Query for TXT records for the validation domain name Verify that the contents of one of the TXT records match the digest value

To me, this means that it should issue a query for TXT records only (not for ANY) and hence the server shouldn't even see your CNAME "redirector" record.

Thus, if your method works, either the server is wrongly implemented, there's a flaw in my reading comprehension, or the specification should be amended...

[1] https://ietf-wg-acme.github.io/acme/draft-ietf-acme-acme.htm...

CNAME records are dereferenced by the recursive resolver, not the client software, so querying for TXT records will work

You might want to read the DNS specification to find out what "query for TXT records" means :-)

Not sure why this is downvoted, this works and is supported.

Alternatively, you can delegate the _acme-challenge zone to a nameserver under your control, although you then have to configure each of the zones on the nameserver too.

One more thing that I'm not sure I understand.

Since I'll need an _acme-challenge.* PER-DOMAIN, doesn't this just move the goalpost to setting up the CNAME records (instead of TXT records directly), assuming my current registrar doesn't support wildcard CNAME entries?

If I'm understanding DNS 01 ACME challenges correctly, to register two subdomains first.one.example.com and second.one.example.com, I need to set up TWO TXT records, _acme-challenge.first.one.example.com and _acme-challenge.second.one.example.com. This means I need two CNAME records (or one if wildcards were enabled)...

I do thank you for your input, thinking about this has lead me to the possibility of just running my own nameserver all-together, I'm going to evaluate all these approaches and see how they pan out, and write a blog post to share.

I haven't used wildcard LE certs yet, but from what I know those only need a TXT record under one name. What you describe applies when you want a certificate that lists multiple explicit names, then each name gets validated individually, and so you need one TXT record per name to be validated (though you can still point all the CNAMEs to the same TXT record name, as long as they aren't used for concurrent validation).

Doing it this way is also more secure, since it means you don't have to give your web server unrestricted write access to every DNS record under your domain.

acme-dns is specifically designed for this purpose: https://github.com/joohoi/acme-dns

If you use BIND you can set an UPDATE ACL that allows your web server access to change acme challenges only: https://fanf.dreamwidth.org/123294.html

BIND looks fantastic but I really like the restricted nature of acme-dns -- I don't know much about DNS and I don't want to inherit a huge amount of functionality that I don't know how to properly administer -- I really only want to manage a nameserver for acme challenges.

By "UPDATE ACL" I believe that you are referring to the DNS UPDATE RFC[0] -- it looks like cert-manager doesn't support generic UPDATEs yet[1].

[0]: https://tools.ietf.org/html/rfc2136

[1]: https://github.com/jetstack/cert-manager/issues/468

It’s pretty easy to make `dehydrated` use `nsupdate` for DNS challenges: https://github.com/fanf2/doh101/blob/master/roles/doh101/fil...

This is huge, thanks! It looks like there's also a PR into to cert-manager to support it:

https://github.com/jetstack/cert-manager/pull/787

I've had no issues with wildcard certs and Cloudflare as my DNS provider.

You're OK giving your browsing history to Cloudflare?

I think he meant that his site is using cloudflare as its dns provider, not his personal computer.

The parent comment is reffering to the fact that they use CloudFlare to host DNS for the domains they control. That has nothing to do with the DNS resolvers their computers use (CloudFlare is certainly a reasonable choice there though... unless you don't use DNS at all, you have to trust someone)

Ok. But if they use Cloudflare, which MITMs traffic, all their users data is in plaintext to Cloudflare. Which leaks not only history, but also logins/passwords of site users.

My beef with CF is that I can not see which sites are behind CF.

Cloudflare has very specifically owned IPs and a number of tell tales to show that a site is behind it. Why do you have beef when it's practically dead simple to see that a site is protected by cloudflare. There's zero obfuscation.

Please, how exactly in browser I can see it?

https://chrome.google.com/webstore/detail/claire/fgbpcgddpmj... https://addons.mozilla.org/en-US/firefox/addon/cloudflare-cl... Are two ways I found with a very quick Google search.

Well, thanks, but as I thought, its not that easy. First one is by CF themselves, no source :) Second is not used and not working. And nothing for Safari.

So some thing you can look for in a request:

  * `server: cloudflare` - Although CloudFlare uses a nginx, they report 
    themselves properly in the server header
  * `Cookie: _cfudid:*` - CloudFlare uses the cookie header to identify 
    users and prevent abuse. If you delete this cookie too many times,
    your IP is flagged by CloudFlare and you may receive an interstitial 
    blocking you from accessing a site.
  * IP Ranges: https://www.cloudflare.com/ips-v4 and 
    https://www.cloudflare.com/ips-v6 - CloudFlare owns the routing 
    to these IP addresses. If you want, setup some Firewall Rules to block 
    access to these ranges.

All in all, CloudFlare is probably the least of your worries. You might want to do some investigation on your ISP, some of which MITM and track any insecure content.

No joke. CloudFlare is near the bottom of my list of worries. I'm most concerned about my bank. They know goddamn everything about my spending history, and it's a complete treasure trove of data because it actually shows where I spend money.

I'm second most concerned about my ISP. They see every outgoing connection I make, and have no trouble tying it all back to me.

Cloudflare is... just not that big a deal. Are you concerned about Microsoft being able to MITM every connection to a site hosted on Azure? Amazon being able to MITM every connection made to AWS? Google being able to MITM every connection made to GCE?

"Yes" is a fair answer, but it means you're using a minuscule fraction of the available internet. Otherwise I don't really see the need to pick on Cloudflare. They're doing exactly what the company that's using them asked them to do (and getting paid for it too...)

> doing exactly what the company that's using them asked them to do

But how do I, website user, can know it? Given how many sites are served by CF, my private, decrypted, data can be aggregated and I would have no clue.

For ISPs use VPN. And I doubt (seriously) AWS (Azure) has means to do MITM, reading private keys from virtual machines? cmon.

Banking is a real bitch, agree :)

How many people using AWS, GCP or Azure are terminating TLS on their instances, instead of on the offered load-balancing services? How many services run (partially) not in VMs, but on PaaS (e.g. App Engine), load data directly from storage services (e.g. Firebase or S3), ...

We've told you several times how to know it as a user. You just conveniently are skipping over it..

You posted link to source for Claire after making this comment. I said thanks above.

Personally I trust that GDPR and its potentially enormous fines provide sufficient economic incentive for these big cloud companies to do the right thing.

That is to say I now believe that not only are Google, Cloudflare, Amazon not proactively sniffing traffic, but also that they'll have invested a massive amount of money making sure it's really hard to do undetected.

Of course I also fully expect that any one of them would give me up to law enforcement iff compelled by a court.

>And I doubt (seriously) AWS (Azure) has means to do MITM, reading private keys from virtual machines? cmon.

that's only if the website(s) are only using their IaaS offerings (which I doubt because they're crazy expensive compared to DO or vultr) and not their PaaS offerings. With PaaS (think heroku), they terminate the SSL and control the software for the http server, not you.

Even the IaaS offerings have widely-used load balancing services that terminate SSL.

https://aws.amazon.com/elasticloadbalancing/

https://cloud.google.com/load-balancing/

https://azure.microsoft.com/en-us/services/application-gatew...

Today, data is the new oil. If you have a legal tap to people's data - you're valued hundreds of billions.

Google and Facebook have legal taps, users willingly provide their chats, emails, links, likes, photos, connections, locations, because its great service and its free. Both are Ad companies by main revenue, and its vital for them to use people's data.

AWS, Azure, Apple are not Ad companies, their main revenue is paid infrastructure, paid software and paid hardware. Their customers are not users, but companies. Reputation risks of openly using the data tap themselves will ruin existing revenue. What companies doing with users data is not their concern. Apple is an exception, with closed ecosystem, strong privacy and security and main income from hardware.

Cloudflare is something in between. They provide reverse proxy services, where your little site sits behind huge wall, for free. Income comes from paid WAF security features and ability to upload to CF your own SSL certs. In any case, you have to allow MITM of people's data.

Incentive for CF to use user's decrypted data is huge - it may shoot it up to ranks of Google and Facebook, to $100x Billions. So I have my doubts if that data is not being harvested.

I think I've said too much already, shutting up :)

> Cloudflare is... just not that big a deal. Are you concerned about Microsoft being able to MITM every connection to a site hosted on Azure? Amazon being able to MITM every connection made to AWS? Google being able to MITM every connection made to GCE?

It's not just Cloudflare themselves though. It's everyone else on the open Internet between the Cloudflare edge node and the site I actually wanted to connect to.

I'm not too worried about the parties that the site operator has a direct contractual relationship with, but traffic from Cloudflare could be going unencrypted to literally anyone with an AS number.

> You might want to do some investigation on your ISP

Doesn't most ISPs have to live up to certain laws about protecting the customers? I think those regulations are much more strict than what is required of CloudFlare.

Incorrect, the source is freely available, :).

https://github.com/cloudflare/claire

well done, my bad :)

> Ok. But if they use Cloudflare, which MITMs traffic, all their users data is in plaintext to Cloudflare.

Using Cloudflare for DNS, and only DNS, doesn't subject you to this.

If you decide to use their reverse proxy features, then sure, the MITM criticism applies.

That's optional though, right? IIRC, you could still have SSL termination occur on your end but you lose tons of features which would require CF MiTM.

Yes, that's optional.

> My beef with CF is that I can not see which sites are behind CF.

Sites behind CF usually include two headers in the responses: cf-ray and expect-ct.

If you see these headers, it's almost certain the response is coming from CF. So its likely those extensions are doing that, perhaps you might be able to verify the source code.

If the thought of connecting to a site hosted by Cloudflare absolutely disgusts you. Vist https://www.cloudflare.com/ips/ for a list of IPs that you can block.

Yes, thanks, I knew about headers and ips. Disgust is too strong word, aware is better :) some info may be sensitive and it goes in plaintext via CF. Its time to write my first extention, sigh.

All content delivery networks have this limitation. Not sure why you're targeting Cloudflare specifically.

No reason. Maybe because they have good PR and offer 'free' SSL, which many just take. I'm unaware of market size of other CDNs.

Do other CDNs offer free plans with SSL?

That has nothing to do with someone's browsing history...

Seems like you just have an issue with CloudFlare, and will keep changing the subject.

CF is in unique position to aggregate decrypted data from all users of many websites, attracted by 'free' plan with provided SSL.

This is against the whole idea of SSL, a closed tunnel between users and websites, so yes, I have an issue.

Plus many users set their DNS resolvers to CF DNS, browsing history goes here.

Let's Encrypt effectively shoots a hole--and this is a good thing--in the idea that TLS is for a meaningful kind of identification and establishes once and for all that the primary reason for TLS is for secured communication across the open internet.

And...that's it. CloudFlare operates in this spirit. It does not route traffic from its edge nodes across the open internet. It routes it across its private network.

So, no, it's not against "the whole idea of SSL"; it's what you have decided the idea of SSL is and nobody else on the internet really agrees with.

The amount of disingenuity you're hucking in this thread is pretty gross and you should stop.

CloudFlare can be used purely for DNS -- in which case they are one of the better DNS services because they have an API that almost everyone supports.

But you are completely correct that running a CDN (HTTP or HTTPS) requires you to MITM everything. The same complaint applies to Akamai, Level 3, or any other CDN you can name. It definitely is a problem, but not one of CloudFlare's own making.

It would be a fair criticism of CloudFlare to say that they've made their defaults tend towards MITM even though it is very likely that most websites don't actually need a CDN -- meaning that they are MITM-ing more traffic than they need to. And they have had pretty bad bugs in the past that revealed large amounts of private data that was sent over TLS but was MITM'd by them[1].

I do agree that CloudFlare being so central to so many large websites is a problem though. I just don't agree that this discounts their use as a purely-DNS service.

[1]: https://blog.cloudflare.com/incident-report-on-memory-leak-c...

I'm not alone, praise be. Lol :)

Haven't tried with the wildcard certs yet but I've been using lego + Cloudflare as the DNS challenge provider with no issue. Works very nicely and it's scripted to automatically renew every 60 days.

Now, it would be great if Cloudflare supported LE integration at it's free tier (replacing the Cloudflare wildcard cert).

I use digitalocean, but also have a few wildcard manually verified with the --manual flag and a bit of cut & paste. It is 5 minutes every 3 months but it is free so I haven't bothered to automate it (just get an intern doing it every couple months). Lame, I know.

yeah, I bought a secondary domain for my budgeting project on Saturday and as soon as I had the dns configured I ran certbot on the server. something like 30 minutes from finding a good domain name to having ssl set up.

I use digitalocean's DNS and had no problems getting wildcard certs. It's a bit annoying to wait for the updated records to resolve but other than that I had no issues.

Wildcard certs suddenly make auto renewing a challenge. For now, I just manually do it by updating DNS when monit tells me certs are getting old.

Reply on news.ycombinator.com