[FEATURE REQUEST] DNS SAN collection or scope creep?

Is your feature request related to a problem? Please describe.

Right now, with respect to SSL/TLS, feroxbuster supports what is necessary to do its job- the ability to either continue when a cert (is expired|has name mismatch|...) which is all that's typically included (or needed) in directory enumeration tools

In other words, this isn't a problem

Describe the solution you'd like

I was considering today that it might be useful in some cases to capture the DNS SAN values from the certificate, and either:

1. Use them for enhancements to the wordlist
2. Report them as structured data or a pem blob in an output line
3. Expand the target list to include each name that is scraped (PROBABLY A BAD IDEA AND I PROBABLY WOULDN"T USE IT ANYWAY)

1 - Using DNS SAN to enhance the wordlist dynamically

In many cases, using the FQDN (as specified at runtime as part of the URL) to enhance the wordlist is effective enough already. This is especially true if there is only one DNS SAN entry, the SAN value matches the FQDN , and the FQDN (as opposed to the IP address) was specified as the target. In this case it offers practically no benefits to users

In other cases, there is a bit to gain from grabbing the DNS SAN values and using some values derived from them as URL paths. One example that is somewhat common for me- enumerating on a host using the IP address instead of the DNS name, as part of a very large batch of endpoints- especially when the certificate has a large amount of DNS SAN values, and various substrings of those names are present as directories- usually because one of the DNS SAN values contains a substring that is the name of an API/application, very contrived example, "lolapi.whatever.com", where /api/lol might exist on the server as an endpoint

2- Logging certificate information as an line in the output file

This is more of a convenience than anything else. It's the sort of thing that I think would be worthwhile to implement only if it's very simple and non-invasive. It can be useful sometimes to see what other (likely) virtual hosts are present in the context of enumeration findings.

Describe alternatives you've considered

There are many tools intended to gather and parse SSL/TLS protocol and certificate info already. If you have a list of URLs, you should have no problem feeding them to these tools

For example, zgrab2 not only grabs the cert information but it parses it and breaks out all of the standard values and many of the more common extensions into a structured format. It also captures protocol handshake info, even down to the post-handshake negotiated master session key

Tools like testssl.sh can also do quite a bit in this area. And of course, there's always openssl s_client -connect ... | openssl x509 -text which is enough to get all of the fields for a certificate. If you do some ugly parsing you can even get some protocol info (-msg -debug -state ...

Point being there are plenty of ways to get all sorts of SSL/TLS protocol and certificate data. Capturing this data is not a groundbreaking capability, but it would be "nice" to have

Additional context

I think it may be a slippery slope to go deeply into the SSL/TLS protocol info or the certificate info. I do, however, think that there may be an opportunity to grab some basic info, since it should be available via some interface (maybe, I don't know how abstracted the SSL/TLS interface that you're using is)

If you wanted to consider this at all, I would imagine the following as potentially of interest for the purposes of logging to the output file:

• Subject CN
• Issuer CN
• DNS SAN extension data
• SSL/TLS protocol version that was ultimately negotiated
• Cipher-suite that was ultimately negotiated
• notAfter, notBefore values
• Or... maybe skip all that and just stick the certificate in PEM format as a line in the output. This is convenient for some workflows and seems the easiest effort

To be clear, I'll say this is in my "what do you think about this?" category of issues, not the "this would be a game-changing feature" category- so please don't feel you need to put too much consideration into it, especially if your gut says you don't want to go down this road at all

Implementation-wise, I imagine for simplicity you would have a separate connection done at the start of the the session, dedicated to getting this data. You could piggyback on the first of the enumeration requests, but that might add a little complexity or uglyness. I'll leave that to you