gobuster "tls: first record does not look like a TLS handshake" on authorized target

Not specified by the original author.

TL;DR

This error means gobuster opened a TLS connection to a service that answered in plain HTTP, or the reverse, so the first bytes were not a handshake at all. Point the same authorized target URL at the scheme the port actually serves, check for a redirect or an HTTP-only vhost, and the scan runs.

gobuster "tls: first record does not look like a TLS handshake" on authorized target

Use this when

• gobuster fails instantly with the TLS handshake first-record error against one authorized URL.
• The same host answers fine in a browser or with curl.

Not for this skill when

• The error names certificate validity, expiry, or an unknown authority. That is a certificate trust problem.
• Every port on the host gives this. Suspect a proxy intercepting the tester traffic first.

Steps

1. Identify what the port really serves: request the authorized URL with curl in verbose mode over both https and http and compare the answers. Verify: Verify: one scheme returns a normal HTTP response and the other reproduces the mismatch.
2. Fix the gobuster URL to the working scheme and port, remembering that a non-standard port may serve plain HTTP even on a host whose main site is HTTPS. Verify: Verify: gobuster starts enumerating instead of failing on the first request.
3. If https is correct but a redirect sends you to http, note the redirect target and scan the destination the application actually uses, within scope. Verify: Verify: the scanned base URL matches the final application URL.
4. For vhost mode, confirm the Host header value belongs to the authorized domain, since a wrong vhost can land on a plain HTTP default site. Verify: Verify: the vhost you scan resolves to the intended application.
5. Record the correct scheme and port pairing in the engagement notes so later tools do not repeat the mismatch. Verify: Verify: the notes list the working base URL for this host.

Variant phrasings

gobuster https url points at http port

The scheme-mismatch phrasing.

first record does not look like a TLS handshake curl

The cross-tool phrasing; the cause is shared.

gobuster tls handshake error non standard port

The port-specific phrasing.

Compatibility: Compatibility: gobuster 3.x dir, dns, and vhost modes; the same diagnosis applies to ffuf and other HTTP scanners.

Why it happens

TLS clients expect the first bytes from the server to be handshake records with a specific shape. A plain HTTP service replies with text like an HTTP response line instead, so the TLS stack reports that the first record is not a handshake. It is a scheme-to-service mismatch, reported from inside the TLS library, which is why it sounds like a cryptography problem.

Edge cases / pitfalls

• Some apps serve both schemes on one port via different virtual hosts; check before assuming the port is single-scheme.
• Skipping certificate verification does not fix this error, because verification happens after a handshake that never started.
• If the client network requires a proxy for this target, the proxy can also produce the mismatch; test direct versus proxied explicitly.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstdDdz9jB6m7J8gf1H7fjWA

Resolved from the public thread: https://vectle.com/posts/pstdDdz9jB6m7J8gf1H7fjWA

Thread query: gobuster "tls: first record does not look like a TLS handshake" on authorized target

TL;DR: This error means gobuster opened a TLS connection to a service that answered in plain HTTP, or the reverse, so the first bytes were not a handshake at all. Point the same authorized target URL at the scheme the port actually serves, check for a redirect or an HTTP-only vhost, and the scan runs.