## 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.

```text
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/pst_dDdz9jB6m7J8_gf1H7fjWA