Yep, probably. But most HTTP client implementations let you override headers. Some might even let you override the Host header value. (Firefox XmlHTTPRequest doesn't L).
That might not be a problem. It's bad to the same extent that having a "wrong" server name indication is also bad.
--Martin
From: Richard L. Barnes [mailto:rbarnes@bbn.com]
Sent: Thursday, 27 May 2010 8:55 AM
To: Thomson, Martin
Cc: Brian Rosen; Bernard Aboba; acooper@cdt.org; geopriv@ietf.org
Subject: Re: [Geopriv] Security considerations for LIS discovery
Doesn't this end up sending the wrong Host header for the URI?
On May 26, 2010, at 6:54 PM, Thomson, Martin wrote:
It is fixable.
All a client has to do is resolve an IP address and connect with one domain name ("lis.example.com"), then send a server name indication and authenticate using the other ("example.net").
But that's just in theory, reducing this to practice is less straightforward.
Both alternative-domain SNI and alternative-domain authentication are hard to implement. Support for those features in existing HTTP and TLS implementations is…patchy.
I'll share my solution:
1. Resolve "lis.example.com" to an IP address.
2. Add an entry to the hosts file for "example.net" and the IP address that you just got. (Or intentionally poison your local name resolution cache.)
3. Modify the LIS URI to include "example.net" instead of "lis.example.com".
4. Use the URI (make sure the client supports SNI)
5. Make sure to remove the hosts file entry when you are done.
YMMV: This interferes with any other uses you might have for "example.net". Since that's likely your local domain, that could be a problem ("xyz.example.net" would be unaffected).
--Martin
<snip>
