Let's Encrypt IP Addresses Used for Validation

Help
1

Since Let’s Encrypt won’t give out a list of their IP addresses (Need a list of Let's Encrypt IP addresses and
Whitelisting LE IP addresses / ranges in Firewall) in use for HTTP validation, here is a way you can find out assuming your web server logs access requests (mine does):

sudo apt-get install john
cat access_log.1 | grep "Let's Encrypt" | awk '{print $1}' | unique ips
cat ips

john package listed above provides a unique utility that is pretty handy :smiley:

I think Let’s Encrypt should maintain a list for us to see. Some of us use firewall solutions such as PeerGuardian Linux, and evidently, some of their IPs are listed in some lists on iblocklist.

Maintaining such a list could get Let’s Encrypt ranges off of such lists a lot easier.

For now, I’m maintaining my own list of Let’s Encrypt IPs :slight_smile:

2

IMHO: The “benefit” doesn’t outweigh the “risk”.

I think you can go about this in a completely different (and yet just as secure) way.

  1. Allow HTTP from the entire world (no Geo blocks, no IP blocks, NO BLOCKS AT ALL)
  2. Handle only challenge type requests as needed (locally, via proxy, etc.)
  3. Forward all other HTTP requests to HTTPS
    And that is where you block whatever you deem needed to be blocked - in HTTPS (and other ports)

In this scenario, you never let any IPs reach your systems via HTTP.
[which is more than can be done with any block list - that is after-the-fact blocking]

4 Likes
3

This would be ideal in an ideal world. Unfortunately, there are too many hackers and bad people out there looking to exploit web apps, drain resources, and screw up anything they possibly can. Have you ever hosted WordPress sites? The amount of exploits and the searching for such exploits is so great that your server can get overwhelmed from too many requests running incredibly inefficient and costly code. So, unfortunately, that just doesn’t work…

1 Like
4

Did you read my entire post?
Let me point you to the highlight:

If you don't know how to implement this you should ask or do a web search.
If you are hosted on a very restricted environment, then you are already at the mercy of the HSP.

1 Like
5

How is that limited to HTTP and not affecting HTTPS?

6

No one's stopping you of course, but it will break. People have made their own list before and it broke when Let's Encrypt implemented multi-perspective validation. Your list will break if (when) Let's Encrypt adds additional cloud servers, or adds additional cloud providers, etc. It's just a matter of time. And Let's Encrypt isn't under any obligation to warn users that they're adding IPs, since they've warned that they will change over time.

Look at how many people are still coming on this forum asking for help with ACMEv1 deprecation, even though that was announced ages ago. Many, many users of LE don't closely follow their announcements (which is understandable). Many users of an IP whitelist would set it up and forget about it. Let's Encrypt will eventually need to add new IPs, and this would cause operational pain for everyone who whitelisted the old ones even if they announced it long in advance. (The person who set it up might no longer even work there by the time it has to be changed.)

There's no reason for them to deal with this operational burden when there's already a solution for people running non-public servers - the DNS challenge.

3 Likes
7

It affects both. Did I ever specifically mention only HTTP?

1 Like
8

Then I totally missed your point.
Mine was to open HTTP and leave HTTPS as is (with whatever blocks you like).
So that part (HTTPS) is unchanged.
If you allow HTTPS access then they can still do the "damage" you say via HTTPS instead of HTTP.
If you are suggesting that they will be able to do more "damage" via HTTP if allowed, then you are not yet fully understanding the solution provided.

To add some further clarity: LE should never need to connect to your systems via HTTPS (only HTTP).

1 Like
9

I think Let’s Encrypt’s policy on all of this is really clear and has never changed. It’s something like this:

  • If you want to use HTTP-01, you have to allow Let’s Encrypt to reach your site on port 80.
  • If you want to use TLS-ALPN-01, you have to allow Let’s Encrypt to reach your site on port 443.
  • Otherwise, you should use DNS-01. (You have to allow Let’s Encrypt to reach each authoritative DNS server for _acme-challenge records in your zone.)
  • Let’s Encrypt will validate from multiple unpredictable IP addresses which will change gradually or suddenly over time with no prior announcement.
  • You can create various restrictions at appropriate protocol layers if you want: for example, for HTTP-01, you could allow the public to only request /.well-known/acme-challenge and no other paths, while for TLS-ALPN-01, you could allow the public to only connect using the acme-tls/1 protocol and no other protocols. (It’s true that if there’s a vulnerability at a lower protocol layer in your server’s software stack, these limitations won’t mitigate it.) You can also time-limit the public’s ability to access these things so that they are only accessible at the moment that your ACME client is performing an associated challenge.
  • Let’s Encrypt won’t support, document, or cooperate with other methods of limiting its validation access, and using them will probably make validation unreliable, maybe failing unexpectedly a random number of months or years from now. Of course, Let’s Encrypt can’t stop you from trying. You can clearly learn experimentally what some of the validation IP addresses are at a given moment in time if you choose to, but that’s no more a good idea than experimentally testing what the Google crawler’s IP addresses are and whitelisting those in a firewall (if you wanted your site to be indexed by Google).
7 Likes
10

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.