RoastMyOpsec

News

Host Header vs SNI on Shared TLS for Public Sites

February 6, 2024

Host header vs SNI on shared TLS for public sites is a name-binding decision: SNI (RFC 6066) tells the TLS stack which certificate to present, while the HTTP Host header (RFC 9110) tells the origin which virtual host to serve after the handshake. They should name the same public site. RoastMyOpsec’s free TLS check proves the audited URL is HTTPS with a runtime-trusted certificate; it does not prove SNI/Host isolation, HTTP/2 coalescing edge cases, or that another tenant cannot be requested on the same IP.

The practical difference

On shared CDNs and multi-tenant load balancers, one IP serves many certificates. The client sends SNI during the handshake so the edge can pick a cert. After TLS, HTTP/1.1 and HTTP/2 still send Host (or :authority) so the application picks the site. If SNI says a.com and Host says b.com, you are in misconfiguration or request-smuggling-adjacent territory that belongs to your platform vendor’s hardening — not a DIY exploit write-up.

Default vhosts are how teams leak the wrong site or a boilerplate “welcome to nginx” on a raw IP. That is inventory. HSTS and a single canonical host (www versus apex) still matter so users do not sit on the wrong name. A certificate that covers too many unrelated names is a brand and phishing-confusion issue as much as a TLS one.

This is not a reason to scan other people’s Host values. Roast the origin you own. Confirm in your CDN that unknown Hosts get a 404, not a neighbor’s app.

How to choose based on what you shipped

Pick one canonical hostname, put it on the cert and in SNI, redirect the rest, and set Host/authority to match. On a shared TLS service, use the vendor’s documented vhost isolation and refuse unknown hosts. Do not debug this by pointing tools at tenants you do not operate.

OptionWhen it winsWatch-outTakeaway
Matching SNI + HostEvery public site you operateDefault vhost serving a neighbor or a bannerSame name in handshake and HTTP
Shared TLS / CDNYou want certs without owning the IPUnknown Host falling through to another tenantConfigure isolation; do not DIY attacks
Canonical 301 + HSTSwww, apex, and http should collapseCert missing the name you redirect toOne name users should keep
Raw IP in the browserIt should not win for a marketing siteDefault site or cert mismatch pagesDo not advertise the origin IP

When SNI still wins

SNI still wins as the only practical way to host many TLS names on one IP. The Host header still wins as the HTTP vhost key. A URL roast still wins as a check that your chosen URL is HTTPS — not as a multi-tenant isolation proof. Missing SNI on ancient clients is a compatibility tale; modern public sites assume SNI.

Common mistakes

The first mistake is letting unknown Host headers fall through to a default site on shared TLS.

The second mistake is treating a green padlock on one name as proof every neighbor on the IP is isolated.

The third mistake is expecting RoastMyOpsec to certify SNI versus Host matching as a standalone F.

What a URL roast can prove

The free TLS insight records whether the consented URL is served over HTTPS (or redirected to it) with a certificate the runtime trust store accepts. It does not score SNI versus Host mismatches, JSON-LD, Open Graph, RSS, hreflang, GPC, AI crawler groups, or rel=me as standalone Fs. Pair this with canonical host redirects. The rest of the free pack is headers, cookies, path probes (.git/HEAD, .env, package.json signatures), and js-secrets.

Free audit the URL you own

RoastMyOpsec is a defensive public-surface roast: headers, cookies, sensitive paths, and more — no exploit payloads. Start with the free audit, then open the vault if the blurred findings look expensive.

Free audit now

FAQ

Is SNI a replacement for the Host header?
No. SNI selects a certificate at TLS time. Host or :authority selects the HTTP site after the handshake. They should agree.
Does a URL roast prove shared-IP isolation?
No. It proves HTTPS on the URL you pasted. Tenant isolation is a platform configuration review.
Should I scan other Host names on my CDN IP?
Only hosts you control, with consent. Unsolicited probing of neighbors is out of scope for this product.

Sources

Related guides