Re: [TLS] Connection diversion to other subdomains

Matt McCutchen <> Mon, 01 November 2010 04:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B0CE3A67A7 for <>; Sun, 31 Oct 2010 21:01:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id sx-zck+4jDBA for <>; Sun, 31 Oct 2010 21:01:48 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 26DE33A6825 for <>; Sun, 31 Oct 2010 21:01:48 -0700 (PDT)
Received: from (localhost []) by (Postfix) with ESMTP id 7A27B51C06C for <>; Sun, 31 Oct 2010 21:01:48 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws;; h=subject:from :to:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s=; b=CsZwindktVrvpDIx+y7AAuU3ga6Na5oq0/altReGJ0X X//bFBXSOCdz7Li52uxC91a0OH7FwAPdIYiTGzy7XPCHrBWJKV/oAj+M3QtD+W19 j64Gv+K8Sez1pJIU9d4Pki5JuTgW2601cP5OsM/dmwqCtJeKrp7BvO3t2qjrj6NY =
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed;; h= subject:from:to:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s=; bh=WvGjcqIXM55ailUgmTXGi6lm8cg=; b=GsdNjEMZmj mnFbH6Ly4Ca28sVT6Kke+8V4gft4qo3NI+V7rLqPGPfOkV0nHWYI2x4nmpzhzLZU NorPEYKhm8poiXMniQiX846wXMBGoMZ/jIoYmjTZco0CJhD2EWvNDOGNk06h+jSx 6U0+O+iXIJIyx6RCZVs/h81KGImZ0C5T8=
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPA id 47E4951C063 for <>; Sun, 31 Oct 2010 21:01:48 -0700 (PDT)
From: Matt McCutchen <>
In-Reply-To: <1288582952.6095.25.camel@mattlaptop2.local>
References: <> <1288582952.6095.25.camel@mattlaptop2.local>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 01 Nov 2010 00:01:41 -0400
Message-ID: <1288584101.6095.39.camel@mattlaptop2.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.4
Content-Transfer-Encoding: 7bit
Subject: Re: [TLS] Connection diversion to other subdomains
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Nov 2010 04:01:49 -0000

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