[HN Gopher] Let's Encrypt has turned on stricter validation requ...
___________________________________________________________________
Let's Encrypt has turned on stricter validation requirements
Author : mmoez
Score : 281 points
Date : 2020-02-19 16:18 UTC (6 hours ago)
(HTM) web link (community.letsencrypt.org)
(TXT) w3m dump (community.letsencrypt.org)
| fs111 wrote:
| I have the shell one as a t-shirt and it is fun to see who "gets
| it" when I wear it to work.
| mittalprat wrote:
| For readers interested in understanding the technical details
| about potential BGP attacks on domain validation, which serve as
| a motivation for Let's Encrypt's multi-perspective validation
| deployment, see the following paper from USENIX Security:
| https://www.usenix.org/conference/usenixsecurity18/presentat...
| dgacmu wrote:
| And for background on the multiple perspectives validation
| approach:
|
| http://www.cs.cmu.edu/~dga/papers/perspectives-usenix2008.pd...
| Avamander wrote:
| The first paragraph already highlights the issue I have with it.
| I don't want to loosen my firewall, some countries and their IP
| ranges just need not access my server.
| scarejunba wrote:
| Yeah, looks like you have created a problem there for yourself.
| Back to other SSL providers for you, then. Unless you want to
| jump through some hoops.
| ahyattdev wrote:
| You can use pre and post renewal hooks in order to temporarily
| disable those firewall rules.
| elmo2you wrote:
| And how does filtering on the IP range of a country prevent
| traffic from that country? Or are you also blocking every known
| proxy and VPN service? Are you sure that your strict firewall
| even provides the security you wish it did?
|
| Either way, letsencrypt will probably have a somewhat fixed
| pool of these challenge validation IP addresses/ranges, so
| adding those to a white list should probably work with a strict
| firewall.
| Avamander wrote:
| It blocks unsophisticated resource waste mostly, as other
| commenters have said, just like changing an SSH port would.
|
| > Either way, letsencrypt will probably have a somewhat fixed
| pool of these challenge validation IP addresses/ranges, so
| adding those to a white list should probably work with a
| strict firewall.
|
| They won't publish the ranges as far as I've read.
| yjftsjthsd-h wrote:
| I'm pretty sure that even a 50% mitigation is still valuable,
| and a remarkable number of attacks are completely
| unsophisticated. Having gone over server logs specifically
| looking at this sort of thing, I can tell you that a lot of
| attacks absolutely do appear to originate in countries that
| are vanishingly unlikely to have legitimate interest in the
| site (this was a small local business in the US, with logs
| showing a lot of `/wp-admin`-type attempts from Asia/Russia).
| So yes, blindly banning unexpected countries is very likely
| to reduce the number of attacks that you get, and if nothing
| else reduce log spam. It's a bit like changing your SSH port:
| easy to bypass, but it still reduces attacks by quite a bit.
| gruez wrote:
| >but it still reduces attacks by quite a bit.
|
| But that's a wrong metric to optimize for. Cutting down the
| number of "attacks" by 90% doesn't improve your security.
| If your server has a vulnerability that can be picked up by
| script kiddie scanners, changing the default port only
| delays the inevitable.
| Sohcahtoa82 wrote:
| I think the idea isn't to increase security, but to
| _decrease_ log spam from attacks that are attempted but
| won 't work.
|
| For example, if you don't have WordPress, then all the
| attempts to access /wp-admin will _never_ work, but
| _will_ fill your logs with 404 errors.
| Avamander wrote:
| It does improve security by improving the SNR in logs.
| CommieBobDole wrote:
| I don't agree with this at all - 'delaying the
| inevitable' is 90% of security; it's the basic assumption
| when practicing defense in depth.
|
| You scan for and patch known vulnerabilities, and assume
| that some unknown ones still remain. You deploy WAF to
| block some of the unknowns or at least make them harder
| to exploit. You harden the host and segregate the network
| to make it harder for the attacker to move laterally when
| they manage to exploit something anyway. You use SIEM or
| just regular log review to hopefully catch attackers that
| have been delayed by your defensive measures.
|
| Putting your service on a non-default port is a perfectly
| valid measure as part of a larger defensive strategy. It
| has its pros and cons, you've got to be aware of what
| threats it mitigates and what it doesn't, but it can be
| useful.
| mr_toad wrote:
| > I'm pretty sure that even a 50% mitigation is still
| valuable
|
| It's about as useful as wearing a condom 50% of the time.
| dspillett wrote:
| I have my certs issued to a VM this is not accessible via
| HTTP(S) anyway, just DNS. It runs a small DNS server which
| answers to _acme-challenge.* requests "forwarded" via CNAME. As
| that is the only part of is visible to the rest it has a very
| small security surface to worry about. It then pushes out the
| keys & certs to the places that need them (directly in the case
| of local machines, less directly for some others).
|
| I set that up originally for a wildcard, as http validation is
| not supported for them and I didn't fancy mucking about
| automating updating the main bind instances, but it is
| convenient for the others too and will be unaffected by these
| changes.
|
| Not a perfect solution for everyone of course, copies of all
| the keys are in one place for one thing, and it all in one
| place could be bad or good for maintenance (single point of
| failure, but single service to monitor & maintain), but worth
| considering if you expect problems with http validation.
|
| _> some countries and their IP ranges just need not access my
| server_
|
| I'm guessing that they won't be using locations that are
| commonly blocked in this way anyway. And if they do happen to
| use one, you may be fine as only two of the three external
| checks need to be responded to.
| nomercy400 wrote:
| I've read about this a few times now, but have been unable to
| find a good resource on how to set such a VM up. Do you have
| a link or resource somewhere so that I can at least get
| started?
|
| Still unexperienced with letsencrypt, but I know enough that
| I cannot use the standard way.
| sergiotapia wrote:
| I'm with you I have China completely blocked from my servers.
| There is no reason for anyone in that country to access my apis
| jlgaddis wrote:
| Recently, the U.S. government accused four Chinese nationals
| in the Equifax hack. The U.S. says they made us of something
| like 34 servers in 20 countries to carry out the attack.
|
| Do you really think you're stopping anyone in .cn who wants
| to actually connect to your server from doing so?
|
| Proxies and botnets are a thing.
| sergiotapia wrote:
| I don't care - my country block is a two second thing that
| cuts off the vast majority of regular people hitting my
| server.
| vegardx wrote:
| Then use a different method of validation, like DNS?
| Avamander wrote:
| Impossible (to do safely) with most providers I've seen, even
| CloudFlare doesn't offer a properly limited API key.
| stilldavid wrote:
| This is now supported as of a few weeks ago! I just set it
| up for a new domain using a cancel-able API key.
| watermelon0 wrote:
| I've just checked it, but with API tokens, I can only
| allow 'edit' rights on DNS records for a specific domain.
|
| There is no way to create a token allowing access only to
| _acme-challenge record.
| RL_Quine wrote:
| So delegate the validation with a CNAME and do it somewhere
| that's not cloudflare. They provide signing with their own
| CA for origin certificates so I don't really know why
| you're using Let's Encrypt at all.
|
| Your idea of just randomly blocking access from certain IP
| address ranges doesn't really provide you with any security
| at all. If you're worried about rusaian hackers or
| whatever, most people exploiting anything have access to
| botnets with whatever bespoke IP address ranges they need
| to bypass those sort of rules.
|
| In anti fraud we see this commonly, people using stolen
| details will happily get better matches with GEOIP than the
| legitimate users of the credentials. Blocking specific
| countries IP allocations is just providing a false sense
| security on your part.
| Avamander wrote:
| > So delegate the validation with a CNAME and do it
| somewhere that's not cloudflare.
|
| Like? For what price?
|
| > Blocking specific countries IP allocations is just
| providing a false sense security on your part.
|
| No, it's a preventative measure. Just like changing SSH
| to a non-standard port reduces pointless attempts.
| throw0101a wrote:
| > Like? For what price?
|
| If you own _example.com_ , you can delegate to
| _dnsauth.example.com_ for $0 (or simply the price of a
| Internet-facing machine that has DNS open).
|
| Say you want a cert for _www.example.com_. LE will check
| for ownership by looking up __acme-
| challenge.www.example.com_. Instead of having a TXT
| record with the nonce, __acme-challenge.www_ is actually
| a CNAME pointing to __acme-challenge.www.dnsauth_ --where
| the TXT nonce lives.
|
| The DNS daemon that is authoritative for _dnsauth_ can be
| the traditional BIND, or other software:
|
| * https://github.com/joohoi/acme-dns
|
| This is often called 'DNS alias' mode:
|
| * https://github.com/acmesh-official/acme.sh/wiki/DNS-
| alias-mo...
|
| * https://www.eff.org/deeplinks/2018/02/technical-deep-
| dive-se...
| Avamander wrote:
| I did not ask "how", I wished to know who supports a DNS
| service like that and for what price.
| GuyPostington wrote:
| The parent stated that you can run your own DNS server
| temporarily for the cost of the hardware to run the
| server and shut the DNS server off after the certificate
| has been issued. The cost is basically free.
| throw0101a wrote:
| > _I did not ask "how", I wished to know who supports a
| DNS service like that and for what price._
|
| And as I stated in the very first sentence, it is self-
| serve:
|
| > _If you own_ example.com _, you can delegate to_
| dnsauth.example.com _for $0 (or simply the price of a
| Internet-facing machine that has DNS open)._
|
| We do this at work: our main registrar does not have a
| restricted API, so we have a sub-domain that lives on a
| DNS server in our DMZ. Internal ACME clients update the
| desired TXT records when asking LE for a cert.
|
| The cost is the price for keeping a VM running and
| updated, which for us is minimal since it is on our
| private cloud.
| jlgaddis wrote:
| Any DNS service which allows you to create a CNAME RR
| supports it. You delegate the subdomain to any DNS server
| you wish.
|
| This isn't some special "Let's Encrypt DNS forwarding
| mode" that DNS providers have to explicitly support. It's
| simply part of "how DNS works".
| TrueDuality wrote:
| Even with CloudFlare in front of your servers, it is
| still valuable to use Let's Encrypt certificates. You can
| turn on Full Strict SSL validation to the backend and
| reduce another attack vector. It's an unlikely attack
| vector to be exploited but it's also a trivial amount of
| work to implement.
|
| Every layer of security makes attacks that much more
| costly.
| RL_Quine wrote:
| Like I said cloudflare signs certificates for your origin
| as well.
| tialaramex wrote:
| And if you always use Cloudflare (or at least are sure
| you'd have days-weeks not minutes-hours between making a
| decision to cease using Cloudflare and actually
| executing) then it's actually safer to tell them you'll
| use their Origin certs rather than a public CA as well as
| likely being easier.
| aianus wrote:
| Why can't you do this safely with AWS? You can restrict the
| API key to write only to the zone _acme-challenge.<your
| domain>.
| vegardx wrote:
| Smart way to do it, but it will set you back $0.5/month.
| You can likely do it cheaper with Lambda and API Gateway,
| but you'll have to invent the secret sauce yourself.
|
| I'm always a little surprised when there are short
| comings in IAM like that with route53 and records. It
| seems like a natural thing to be able to control, but for
| some reason you don't have resource level controls on
| hosted zones. It's all or nothing.
| josteink wrote:
| DNS validation once setup is so much easier to work with, for
| all use-cases I can imagine, I will never go back to HTTP-
| based authentication.
|
| Really, do give it a try.
| eric_b wrote:
| It's already painful to get Let's Encrypt set up in a web farm
| scenario. This won't make it easier.
| GuyPostington wrote:
| You should check out https://community.letsencrypt.org and ask
| for help there!
| snapetom wrote:
| If you or your company has enough money for a web farm, you
| should just buy your own cert.
| GreenJelloShot wrote:
| What? Web farms are automatically expensive? A web farm can
| literally be two Raspberry Pis behind a simple load balancer.
| What if this isn't "my company"? What if I run a web farm at
| home for fun?
|
| Besides, your argument could be used to justify any price
| hike! "If you can afford X, then you can afford Y!"
| teraflop wrote:
| How does it make it any more difficult?
| jaas wrote:
| The blog post is probably more understandable and relevant for
| readers here:
|
| https://letsencrypt.org/2020/02/19/multi-perspective-validat...
|
| Maybe we can get the link changed?
| oefrha wrote:
| The current link [1] is a lot more concise and informative
| (specifically, what users should do) IMO. The blog post expands
| a little on BGP hijacking but honestly it could be summarized
| in one short paragraph.
|
| [1] https://community.letsencrypt.org/t/acme-v1-v2-validating-
| ch...
| jsjddbbwj wrote:
| I don't see how that less technical, more full of fluff post is
| better for readers of this website
| MrStonedOne wrote:
| It doesn't require 3rd party javascript to read?
| wpietri wrote:
| I'm fine with keeping the original link. But the original
| post doesn't actually explain why this is happening, while
| the suggested replacement explains the problem.
| spydum wrote:
| I don't see how this resolves BGP hijacking attacks? If I
| announce a more specific route all four locations should still
| land on my hijacked network... Or is this trying to race the BGP
| propagation?
| mittalprat wrote:
| If the domain is hosted on a /24, then more specific routes
| will be filtered out by default in most ASes. Also, with the
| increasing adoption of RPKI, in conjunction with its maxlength
| option, more specific attacks will be a challenge for
| adversaries.
| jaas wrote:
| It doesn't "resolve" BGP attacks. The point is an attacker
| would have to pull off three or four successful attacks at
| once, which is harder than pulling off just one, especially if
| they hope to go unnoticed.
| tialaramex wrote:
| Or of course for smaller targets their attack is just much
| closer to the target than to any of the multiple viewpoints,
| and so this mitigation makes no difference to them
| whatsoever.
|
| We shall see how well this works in practice. Assuming it's
| relatively cheap it's harmless to at least try.
| creeble wrote:
| TL;dr - can this be fixed by updating to the latest certbot
| package?
| progval wrote:
| You don't need any update.
| londons_explore wrote:
| This is a good start...
|
| But I think it would be far better for them to focus on
| _alerting_ webmasters if someone does manage to get a new
| certificate issued for a domain before the old one expires.
|
| Certbot should reference the old certificate when doing a
| renewal. If someone registers a new certificate while an old one
| is valid and without referencing the old one, the owner of the
| old certificate should be notified loudly (sms, different-domain
| email, etc). Same if they register a certificate through a
| different provider.
|
| Today all of the above is possible with certificate transparency
| logs, but nobody looks in them, so they're useless.
| sysashi wrote:
| I've also received a notification email about my outdated acme
| client, thanks!
| Rebles wrote:
| I may be naive, but it seems like it might be more secure if the
| first step was to deploy a self-signed cert on the server, step
| 2, give Let's Encrypt the public key of the self signed cert, so
| Let's Encrypt can validate who you are, then proceed with Let's
| Encrypt's regular validation process, obviously replacing your
| self-signed cert with the one issued by Let's Encrypt at the end.
| smw wrote:
| Wouldn't an attacker be able to create a self-singed cert just
| as easily?
| mittalprat wrote:
| Indeed, the self-signed cert idea doesn't work in this
| context.
| tialaramex wrote:
| Self-signed. Yes, an attacker would not ordinarily find this
| harder to pass than the http-01 challenge today. Validation
| using this approach was method 3.2.2.4.9 ("Test Certificate")
| and is no longer permitted for new issuance under current
| Baseline Requirements.
|
| Let's Encrypt offers three ACME methods which implement
| 3.2.2.4.6 ("Agreed Upon Change to Website"), 3.2.2.4.7 ("DNS
| Change") and 3.2.2.4.10 ("TLS Using a Random Number").
| kardos wrote:
| Sounds like the TLS-SNI-01 challenge that had a fatal flaw in
| some circumstances:
| https://community.letsencrypt.org/t/2018-01-09-issue-with-tl...
| tialaramex wrote:
| The problem with tls-sni-01 is that it assumed nobody would
| be crazy enough to let you configure their HTTP-only web
| server to answer HTTPS requests for their names. So logically
| if a server answers HTTPS requests for a name, on an IP
| address that DNS says is the right address for that name,
| that must be the right server, no?
|
| But it turns out cheap bulk hosting sites, especially using
| Apache HTTPD often did this because it worked fine by
| default.
|
| The symptom for ordinary users would be you try to visit
| https://cat-videos.example/ and it gives a certificate error
| saying the site has a certificate only for aaa-microwave-
| repairs.example do you want to continue? If you say "Yes" you
| get an error page. Eventually you remember it was http://cat-
| videos.example/ no need for the 's' and that works. Weird but
| ultimately harmless.
|
| What has happened is the Microwave repairs people paid for
| working HTTPS, with a valid certificate for their name, the
| Cat Video people didn't bother. But both set the bulk hosting
| site as the correct IP address for their servers.
|
| Now, when you connect to that IP address and ask for cat-
| videos.example using SNI, the remote server _should_ go "Er,
| no?" and you just get an error. But Apache's default
| behaviour instead figures you want the default web site and
| default certificate, which will typically be alphabetically
| first on that server.
|
| This destroys the security assumptions for tls-sni-01,
| because "it's safe unless people use cheap bulk hosting" is
| essentially identical to "it's not safe" and getting Apache
| to fix things was too late. Bad guys could sign up for a bulk
| host used by their target for non-TLS sites, and add a bogus
| site named like aaaaaaa.bad-guys.example and use this to
| attack the target with tls-sni-01 challenges.
|
| So, the replacement ACME challenge doesn't rely on SNI it
| uses ALPN instead. Also some people actually tested to check
| that Apache isn't also dumb enough to go "Um, I don't
| recognise this ALPN, I guess that means I should press on
| anyway and cause breakage" which fortunately it is not.
| drcongo wrote:
| Excellent explainer, thanks.
| foota wrote:
| Wait... How does letsencrypt know who is giving them the public
| key cert?
| contravariant wrote:
| Presumably they can then confirm that the public key matches
| the certificate that's currently on the webpage.
|
| Unless someone successfully preforms a MITM attack on
| letsencrypt but then all bets are off.
| MrStonedOne wrote:
| Too bad I can't read them because the site doesn't load at all
| with 3rd party scripts disabled.
| GuyPostington wrote:
| Here you go, read the source.
| https://raw.githubusercontent.com/letsencrypt/website/master...
| MrStonedOne wrote:
| Thank you
| xfalcox wrote:
| Is that because assets are hosted in a CDN?
| kps wrote:
| It took me three tries _with_ scripts enabled; perhaps they 're
| overloaded.
|
| (Taking 5MB and 2s to send 500 words of text can do that, but
| since the primary audience of Let's Encrypt is web folks,
| there's some schadenfreude in my weltschmerz.)
| codegladiator wrote:
| It works for me with NoScripts blocking the two js requests it
| tried to make.
| thenewnewguy wrote:
| Works fine for me, uMatrix with javascript disabled by default.
|
| Edit: Ah, upon testing it breaks if you have 1st party JS
| allowed but not 3rd party. This is pretty reasonable in my
| opinion.
| azdle wrote:
| For me it seems to also require that you turn on "Spoof
| <noscript> tags" in uMatrix.
___________________________________________________________________
(page generated 2020-02-19 23:00 UTC)