Subject: Re: [TLS] Connection diversion to other subdomains

From: [email-masked]
Date: Thu, 28 Oct 2010 21:20:30 -0700 (Pacific Daylight Time)

On Wed, Oct 27, 2010 at 9:01 PM, Matt McCutchen <[email-masked]> wrote:

[re SNI and Host header mismatch]
> How can I get the message out to holders of wildcard certificates that
> they should prevent this attack?

First, what would your proposed remedy be?  What do you think the best behavior would be?  Where would you put whatever check you propose in the processing chain of the server?

-Kyle H

---

From: Matt McCutchen <[email-masked]>
Date: Sun, 31 Oct 2010 23:42:32 -0400

On Thu, 2010-10-28 at 21:20 -0700, [email-masked] wrote:
> First, what would your proposed remedy be?  What do you think the best
> behavior would be?  Where would you put whatever check you propose in
> the processing chain of the server?

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.  Perhaps a new error code could
be allocated.

If the server gets a TLS connection with a bad server_name extension, it
would be even better to go ahead and fail the handshake with an
"unrecognized_name" error.  Apache mod_ssl currently is not capable of
doing this; I might enter an enhancement request.

-- 
Matt

---

From: Matt McCutchen <[email-masked]>
Date: Mon, 01 Nov 2010 00:01:41 -0400

On Sun, 2010-10-31 at 23:42 -0400, Matt McCutchen wrote:
> 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