ALB SNI / Host Header mismatch officially supported?

Question

I have a particular setup that is currently working, but I am trying to find docs or something to make sure it is definitely supported and not just something that might get fixed later on.

I have a shared internet-facing ALB that I am using for several unrelated applications. Right now, it has 1 default ACM Cert attached, for example for a domain `shared-alb.com`. The default action is to return a fixed 503 response. DNS for `shared-alb.com` publicly resolves to the ALB.

I then add a single additional routing rule: if Host header matches `example-a.com` then forward to some target group. I do _not_ have an ACM Cert covering this domain attached to the ALB. DNS for `example-a.com` does _not_ resolve to the ALB.

This I know is non-standard, but I am able to successfully make requests to my target group by forcing the hostname in the SNI ClientHello to be `shared-alb.com` and not match the Host header in the actual HTTP request `example-a.com`.

For example, this would succeed: (note: I don't even need to pass `-k` to ignore SSL errors, because the TLS connection is valid for the `shared-alb.com` hostname)

curl -H "Host: example-a.com" https://shared-alb.com

AFAIK most other servers will reject a request if the SNI host does not match the HTTP Host header, or at least require some manual settings override to allow it. But it seems AWS ALB will allow this out of the box? I can't find in the [docs](https://docs.aws.amazon.com/elasticloadbalancing/latest/application/create-https-listener.html#sni-certificate-list) anything specifically mentioning this. It does talk about "smart certificate selection" for SNI, but it does not go on to say anything about the routing rule evaluation for host headers caring or not caring about matching.

The different applications this ALB will be sitting behind are all on Cloudfront. For this example, one CF distribution would be set up with `example-a.com` as its CNAME with a valid ACM Cert (attached to CF but not ALB), and with `shared-alb.com` as its custom origin domain name, and configured to forward the Host header. And DNS for `example-a.com` resolves to the CF distribution. It does look like Cloudfront specifically does allow this sort of non-standard request to the origin: https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/http-502-bad-gateway.html#ssl-negotitation-failure so my guess is that it all is intentionally supported. I just can't find docs on the ALB side to validate.

Accepted Answer

Hello,

Thank you for contacting AWS re:Post !

The setup that you deployed is expected behavior. In normal, condition, client first initiate TLS connection, sending Hostname in SNI field in Client Hello Packet. Only after a successful TLS handshake, Application data will be exchanged, with the client sending a Host Header, same as Hostname in SNI. However, we can manipulate Host header via command :- curl https://shared-alb.com -H "Host: example-a.com". This is called Domain Fronting, which involves establishing a TLS connection with a SNI field different from the HTTP Host Header. For example, the TLS connection might connect to www.example.com, and then send an HTTP request to www.example.org. The Domain Fronting is allowed by ALB, as ALB can support multiple Domains/multiple Host headers. Hence, it is recommended to create Host header condition in ALB listener rules, only for domains for which ALB has SSL/TLS Certificate associated, to only allow genuine traffic.

However, CloudFront does not support Domain Fronting. CloudFront includes protection against domain fronting occurring across different AWS accounts.

Refer to the "Domain fronting" section in AWS documentation :- 
https://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/CNAMEs.html#alternate-domain-names-restrictions

I hope that you find this information helpful.  If you have any further queries or concerns, please do not hesitate to reach out to us.

Thanks! Anil

ALB SNI / Host Header mismatch officially supported?

関連するコンテンツ