-
Notifications
You must be signed in to change notification settings - Fork 2.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
HTTP option any_af breaks TLS SNI #708
Comments
I can see the problem and how this is a good fix. But I wonder if it would be more useful to add the |
I definitely agree that this option is squarely relevant to the transport, not HTTP, so At the same time, I have felt that modifying the comm-level options is not something that I should put forward in the context of this issue so I kept the change as localized as possible. Let me see what it would take to implement the address resolution in |
Here is the broader patch for
and for
|
Please let me know if you have any questions or concerns with the broader patch, which is hopefully aligned with Dan's feedback. Otherwise I will combine and commit both patches in about a week. |
Looks good! |
Committed as 99fa808 (I forgot to tag the commit message.) P.S. I did look for any legacy script code that invokes |
NSE HTTP requests with option
any_af
result in TLS requests that populate SNI with an address, instead of the hostname. Example code:The reason is that the hostname gets replaced with an address in function request (a local function in
http.lua
), losing the original name:Subsequent code then unsurprisingly populates SNI with the new
host
value.The following patch seems to resolve the issue by converting the
host
string into a table and preserving the original name astargetname
:Please let me know if you see any issues with the patch or you believe that the problem should be resolved differently. Otherwise I will commit the patch in a few weeks.
The text was updated successfully, but these errors were encountered: