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

Open
by Ghost opened 4 years ago · 2 comments
Ghost commented 4 years ago

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.
Owner

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.

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

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.