ACME.challengeTests connects with the external domain and ip address - won't work behind secure routers #32

New Issue

Ghost · 2020-08-24T04:30:36Z

Ghost commented

2020-08-24 04:30:36 +00:00

There should be a way to pass the localhost as the host to test.
What happens when loopback is not enabled in the router, is that the whole greenlock-cli fails due to the test emitting an ECONNREFUSED.
And in most cases loopback should not be enabled in the router as it's a security hole allowing an attacker to spoof the packet's source.

There should be a way to pass the localhost as the host to test. What happens when loopback is not enabled in the router, is that the whole greenlock-cli fails due to the test emitting an ECONNREFUSED. And in most cases loopback should not be enabled in the router as it's a security hole allowing an attacker to spoof the packet's source.

coolaj86 commented

2020-09-21 18:40:59 +00:00

You've got a compound problem there.

Either the router should be properly configured with hairpinning, or it should be properly configured without hairpinning. It should not be half configured.

Without hairpinning the request should work just the same as any other request - it goes out to external DNS servers, gets the external IP, makes a request out to the external IP that comes back in through the NAT of the router.
With proper hairpinning the request should be rewritten by the router and turned back on itself.

That said, you can update /etc/hosts to get the localhost behavior that you desire... it just defeats the purpose of the test, which is to check that an outside source can properly get inside.

You've got a compound problem there. Either the router should be properly configured with hairpinning, or it should be properly configured without hairpinning. It should not be _half_ configured. - Without hairpinning the request should work just the same as any other request - it goes out to external DNS servers, gets the external IP, makes a request out to the external IP that comes back in through the NAT of the router. - With proper hairpinning the request should be rewritten by the router and turned back on itself. That said, you can update `/etc/hosts` to get the localhost behavior that you desire... it just defeats the purpose of the test, which is to check that an outside source can properly get inside.

Ghost commented

2020-09-22 04:53:10 +00:00

Well, the point of “hairpinning” is to create a loopback that will circumvent the problem that occurs without it.
And without it, the packets that are meant for the machines behind the NAT are received by the router with the inbound ip being a local ip. Any secure enough router will drop those- as it can easily be an attack.

There’s a specific vulnerability that my CSP pointed me to, in order to convince me not to set this up- this is something unpublished yet. Should probably be published soon. And it looked bad enough to convince me anyone could fool the router by crafting the packets with simple tools.

Now in some configurations it may be complicated or undesired to modify hosts for this purpose. That’s why I think a flag in the configuration to toggle this off will be great!

Also it’s common to use external tools in order to check for external ip address, external access etc. As internal access != external access.

I think that for the very least- it should not fail on this check, but throw a warning that will be used for diagnostics if the whole process fails.

Well, the point of “hairpinning” is to create a loopback that will circumvent the problem that occurs without it. And without it, the packets that are meant for the machines behind the NAT are received by the router with the inbound ip being a local ip. Any secure enough router will drop those- as it can *easily* be an attack. There’s a specific vulnerability that my CSP pointed me to, in order to convince me not to set this up- this is something unpublished yet. Should probably be published soon. And it looked bad enough to convince me anyone could fool the router by crafting the packets with simple tools. Now in some configurations it may be complicated or undesired to modify `hosts` for this purpose. That’s why I think a flag in the configuration to toggle this off will be great! Also it’s common to use *external* tools in order to check for external ip address, external access etc. As internal access != external access. I think that for the very least- it should not **fail** on this check, but throw a warning that will be used for diagnostics if the whole process fails.

Sign in to join this conversation.

No Label

No Milestone

No Assignees

2 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: coolaj86/acme.js-ARCHIVED#32