Quick CNAME question

A question just came to me and I'm not sure, hopefully someone can help.

A firewall is acting on a URL, not an ip. I have 2 domains. Right now they each have an A record to the same server. If I put a CNAME from domain a to domain b, will said firewall see all requests as going to domain b, or will it still show based on the URL typed in the address bar?

Firewall is probably looking at the URL. If there is no 302 redirect or the site doesn't answer with some other host name, then you will still have the same URL in the bar. And the URL will be what HTTP requests use originally. The host part of that is looked up in DNS and the DNS resolver gets the CNAME and then asks for the resolution on that and gets an IP- but that IP is mapped to the original host name. I don't believe the browser gets anything but the final result (the IP) from the DNS stack. All the other transactions to that host will use the IP for TCP, but in the HTTP headers the host name is used. So if the firewall is actually looking at the HTTP session- you should still have the same enforcement from the firewall.

Firewall is probably looking at the URL. If there is no 302 redirect or the site doesn't answer with some other host name, then you will still have the same URL in the bar. And the URL will be what HTTP requests use originally. The host part of that is looked up in DNS and the DNS resolver gets the CNAME and then asks for the resolution on that and gets an IP- but that IP is mapped to the original host name. I don't believe the browser gets anything but the final result (the IP) from the DNS stack. All the other transactions to that host will use the IP for TCP, but in the HTTP headers the host name is used. So if the firewall is actually looking at the HTTP session- you should still have the same enforcement from the firewall.

For unencrypted HTTP. Move up to HTTPS and the firewall can't look into the HTTP session anymore-- all it'll be able to see is the IP (so there's a loophole there if you're relying on deep packet inspection for filtering and permitting HTTPS/SSL).

All the other transactions to that host will use the IP for TCP, but in the HTTP headers the host name is used.

If this weren't the case name-based virtual hosting wouldn't work with cname records, but it does.

Jonathon wrote:

For unencrypted HTTP. Move up to HTTPS and the firewall can't look into the HTTP session anymore-- all it'll be able to see is the IP (so there's a loophole there if you're relying on deep packet inspection for filtering and permitting HTTPS/SSL).

Unless the Firewall is smart enough to detect clients sending a SNI (introduced in RFC 3546) record in their TLS Client Hello message.

For unencrypted HTTP. Move up to HTTPS and the firewall can't look into the HTTP session anymore-- all it'll be able to see is the IP (so there's a loophole there if you're relying on deep packet inspection for filtering and permitting HTTPS/SSL).

Not true if you are doing SSL intercept on the firewall. Plenty of firewalls can use a trusted a cert then man-in-the-middle and still get all the http traffic in the SSL stream. If you don't have the trusted cert, you can be redirected to another page.

In any case (SSL intercept or not) the IP resolution still happens as I described and you can still see the IP source/dest in the TCP header, but depending on implementation, you may not have the firewall acting on the URI unless SSL intercept is being used.