Re: [TLS] Connection diversion to other subdomains

[Matt McCutchen <[e-mail]>]

On Sun, 2010-10-31 at 23:42 -0400, Matt McCutchen wrote:
> If a web server gets a request over TLS with a Host header that doesn't
> match any of the sites it is supposed to serve, it should return an HTTP
> error instead of serving content from some "default" site.  Ideally, the
> error should not convey false information about the real server (e.g.,
> 404 would be bad).  There's no error code that exactly fits the
> situation; 400, 403, and 503 are decent.

I just noticed that RFC 2616 section 5.2 prescribes the use of error 400
(Bad Request) for wrong Host headers.  But I'm uneasy about the use of
error 400 because it suggests that the client is at fault, which isn't
true if an attacker diverted the connection.

In general, a network attacker cannot cause an HTTP request over TLS to
complete with a different HTTP-level outcome than it should; there is
just this one stupid case where several different servers are authorized
and willing to take the request.  It would be much better to catch
connection diversion at the TLS level, like any other network
shenanigans.

-- 
Matt