-
Notifications
You must be signed in to change notification settings - Fork 2.6k
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
Adding SNI override via request annotations #1970
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we also intend to support http variables in SNI field @ehsandeep @Mzack9999? As I see in the issue the user also asked for global vars in SNI field which is not supported here.
@Ice3man543 I think it would make things quite complex. The specific case used the exact value of the |
Hi @Mzack9999 I checked this one but it's not work when using unsafe: true because nuclei will send @tls-sni:request.host in the request otherwise it work correctly so maybe if you add -sni option too , that will solve unsafe: true problem , plus if anyone found target use specific SNI , he will can run nuclei templates e.g. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- merge conflict
-
doesn't work withmoved to Custom SNI support for other protocols #1984unsafe: true
; this applies to CLI flag support as well. - CLI option should override request annotation
Thanks for pointing this out, including |
Proposed changes
This PR implements SNI override via request annotations. The annotations has a syntax like
@tls-sni:value
. ifvalue
is equal torequest.host
then the value of theHost
header is used as SNI name.Checklist
Correlated PRs
Example
$ cat t.yaml
$ echo https://192.168.1.1 | go run . -t t.yaml
Improvements