Honor explicit ports in HTTPS checks#267
Conversation
|
@arpitjain099 - Are the stack traces that appear when running the tests you added necessary? Is there any way to get rid of them? They misled me into thinking that tests had failed when I ran |
Hmmm...looks like the stack traces are indeed necessary because of the way that |
|
Good catch, and they're not actually necessary - that was the test leaking pshtt's own exception logging. Both tests stop the scan early by raising from |
Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
The two new tests stop the scan early by raising from perform(), which https_check catches and logs via logging.exception. That dumped a traceback into the pytest output even though the tests pass. Wrap the calls in self.assertLogs(level=ERROR) so the expected error log is captured instead of printed. Signed-off-by: Arpit Jain <arpitjain099@gmail.com>
4f43a6b to
b9bf6d0
Compare
dav3r
left a comment
There was a problem hiding this comment.
This all looks good, but I'd like to see one more test added: test_http_check_defaults_to_port_80 since that logic is being added in this PR as well.
Doh- I didn't notice that this PR had auto-merge enabled, otherwise I would've used the "Request Changes" option. |
@dav3r no worries let me check |
Follow-up to #267, which also added the http -> port 80 default. This covers that branch, mirroring the existing port 443 test. Signed-off-by: arpitjain099 <arpitjain099@gmail.com>
Fixes #254
This came from https_check always building the SSLyze target with port 443 after slicing the URL string. If someone scans
domain:9443, the port was not handled correctly and cert trust or chain fields ended up null.This updates target parsing to use
urlparseand pass the parsed host plus parsed port to SSLyze. When no explicit port is present, it still defaults to 443.I also added unit tests that assert calls to
with_ip_address_lookupfor:example.com:9443-> hostexample.com, port9443example.com-> hostexample.com, port443I could not run
pytestend-to-end in this local environment because thenasslbinary fails to load (_SSLv2_methodsymbol issue on macOS toolchain). I still verified changes by compiling modified files and running a targeted Python harness with stubbed SSLyze modules to validate host and port parsing.