DPI Http01 solver for linux with nfqueue #1845
Open
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request will add http.nfqueueport option, which when assigned a port will put a nfqueue rule on firewall to capture http request for token path, block it to reach web server and craft request packet for it. (Linux only)
Why anyone do that? because with this solver it don't need to care about any webserver on port 80.
Why this is draft PR? because this is just enough to run, and much to do yet (ex: currently can't handle ipv6 (not sure it skips or panics), no reasonable docstring, and some more bugs maybe)
using nfqueue for port-sniffing solver isn't my original idea:
https://community.letsencrypt.org/t/using-nfqueue-on-linux-as-a-novel-webserver-agnostic-http-authenticator/192625/23
http.nfqueueport is with port number option so run on pebble, but does it really need to set a port number or just blindly running on port 80 is enough?