This stems from a TryHackMe room which required the discovery of virtual hosts on an HTTPS server which implemented SNI. For most virtual hosts, the main domain's cert worked but simply displayed the same content (e.g. www.domain.com, test.domain.com etc. would get the same response as domain.com).
When valid virtual host was found, a 421 status code was returned, since gobuster had used the original domain.com TLS connection, which didn't use the proper cert for the virtual host.
As it turns out, this status code was enough for gobuster to find the virtual host, but my concern is if the server were configured to simply return the same content instead of an error, these virtual hosts would be missed.
This could be solved with an optional flag like --update-sni or --use-sni which would ensure that a new TLS connection was established with the virtual host used as the SNI.
This stems from a TryHackMe room which required the discovery of virtual hosts on an HTTPS server which implemented SNI. For most virtual hosts, the main domain's cert worked but simply displayed the same content (e.g. www.domain.com, test.domain.com etc. would get the same response as domain.com).
When valid virtual host was found, a 421 status code was returned, since gobuster had used the original domain.com TLS connection, which didn't use the proper cert for the virtual host.
As it turns out, this status code was enough for gobuster to find the virtual host, but my concern is if the server were configured to simply return the same content instead of an error, these virtual hosts would be missed.
This could be solved with an optional flag like --update-sni or --use-sni which would ensure that a new TLS connection was established with the virtual host used as the SNI.