Suggestion to Add a FromIP Header/Field to Boulder Responses

Lunch time for me. I love all the great information and discussion here! :heart: I feel like the most fundamental requests/suggestions are often the most complicated and far-reaching.

1 Like

Unless you're behind a NAT, of course.

I'm like 90% sure that the Let's Encrypt VAs are still behind NAT, because even as recently as this month I've had to help a customer to disable tcp_tw_recycle to prevent Let's Encrypt validation timeouts. (cPanel support enabled it on their server for some reason :face_vomiting:).


Any thoughts here @_az:

1 Like

I think I came late to the game.
But it really seems trivial for anyone to find out which IPs LE is using.
From a security perspective, I only read "smoke and mirrors" so far.
The inbound request for service is not tied to the outbound request for validation.
So, when a "bad guy" makes a request against a domain that they don't control (DNS) they will never see the validation request (whether it contains its' own IP in the request or not).

You make a purchase.
I'm going to delivery a package to your address that contains that purchased item.
But I'm not going to put a return address label on the package.
Because that would let you know where the package came from.

That sounds ridiculous - doesn't it?
There is no anonymity in TCP.
If there is a NAT, there will always be a NAT.
And the NAT'ed IP will always be the same:
curl -4
curl -6
That is who you are.
How would that IP ever change?
How would NOT providing that IP (the one you are using) make things more secure?

1 Like

Many large datacenters have multiple WAN links out to the greater internet and traffic from a given internal device won't always go out the same link even when everything is operating normally. There can also be routing rules that change the outbound link based on destination as well. So traffic sent to US destinations might come from a different IP than traffic sent to UK locations for example.

In short, a device in a NAT'd network can't definitively know what public IP they will appear to be coming from for a given destination.



You are correct, but you might have overlooked what I initially overlooked: The result of the validation attempt is sent to the machine running the client, not the machine being validated (though they are typically the same machine under legitimate circumstances).

  1. I order something to be delivered to your house.
  2. I receive a tracking notification for the shipment of the order (because I did the ordering), which contains the address of the facility from which the order was shipped.

Would the package have been shipped from a different facility if the order were to be delivered to me? Maybe. Hence rmbolger's argument directly above. If I place 10,000 such orders I might be able to start mapping out the company's infrastructure if I can coordinate the destinations with the servicing centers.

I think that's the argument that several here have been making in various ways. Personally, I'm not sure what actual harm knowing the validation originations actually causes.

1 Like

But do you know if any of that is actually in use in this particular case?
[it's a very nice - what if scenario]

1 Like

Yes, true.
But the argument remains the same.
It's TCP.
They can't hide their IP.
You can't hide yours.

1 Like

Absolutely. It's just difficult for me to know the IP addresses delivering to you unless the sender is telling me those addresses... :grin:

1 Like

Yes that prompted this topic.
The "we need to hide our IPs or people will do dumb things" argument is foolish.
People will always find ways to do dumb things and things in dumb ways.
LE already tells them NOT to do anything to prevent HTTP and not to try to whitelist LE IPs.
What more needs to be done?
Go out-of-the-way to ensure they can't?
Well that's not possible, they always can (and some will) no matter what you try and do to stop them.

1 Like

Yep. Exactly. :rofl:

I don't believe in security through obscurity.

1 Like

Both sides make false statements.
Some "security" folks argue that HTTP exposes vulnerabilities and refuse to open it.
But exactly how does HTTPS cure the underlying HTTP vulnerability?
Well it doesn't!
So that side is also (gravely) mistaken.

1 Like

Don't ya know that if we had just cloaked the Titanic it wouldn't have hit the iceberg! :smirk:

Undercover IRS agents... what a TV concept...

1 Like

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