What they're testing
Whether you understand the boundary of a security layer — where a great many misconceptions begin.
The short answer~30 seconds
HTTPS gives three things on the wire: confidentiality (nobody in the middle reads it), integrity (nobody alters it undetected), and SERVER authentication (you're talking to that domain). It does NOT protect against: a compromised server, an application vulnerability, wrong data, or the domain itself being a scam — a phishing site has a padlock too, because a certificate proves domain control rather than intent.
The long answer
Worth adding: what still LEAKS despite HTTPS — the domain you visit (through SNI and DNS), packet sizes and timings, and the IP address. For some sites the response size alone is enough to infer which page you're on. So HTTPS protects the CONTENT, not the metadata.
On configuration, two cheap and worthwhile things: HSTS so the browser never tries HTTP for your domain again (closing the downgrade window from the second visit onward), and an HTTP → HTTPS redirect at the outermost layer. Certificate pinning is rarely worth it on the web — it causes more outages during certificate rotation than it prevents attacks.
What they'll ask next
?Do internal service-to-service calls need HTTPS?
Yes, under a zero-trust model — the internal network is no longer assumed safe. A service mesh does this nearly for free with mTLS, which additionally authenticates both ends, where ordinary HTTPS authenticates only one.
These lose points
- "We have HTTPS, so we're secure." It protects exactly one leg of the journey, and most vulnerabilities live at the ends.