Re: [TLS] Connection diversion to other subdomains

Matt McCutchen <matt@mattmccutchen.net> Fri, 29 October 2010 15:53 UTC

Return-Path: <matt@mattmccutchen.net>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44C0B3A63D2 for <tls@core3.amsl.com>; Fri, 29 Oct 2010 08:53:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hfbmokJc7Ez5 for <tls@core3.amsl.com>; Fri, 29 Oct 2010 08:53:06 -0700 (PDT)
Received: from homiemail-a14.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by core3.amsl.com (Postfix) with ESMTP id 345553A63C9 for <tls@ietf.org>; Fri, 29 Oct 2010 08:53:06 -0700 (PDT)
Received: from homiemail-a14.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTP id 77AC48C090; Fri, 29 Oct 2010 08:55:00 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; c=nofws; d=mattmccutchen.net; h=subject:from :to:cc:in-reply-to:references:content-type:date:message-id :mime-version:content-transfer-encoding; q=dns; s= mattmccutchen.net; b=inGJlCEvNA+eq955H8UopzNVIErj65yjvqnK3lS05oa vQI7qBQ+OcQCrQ8g5DkMldn0LDHtdjk4q3pv9RwbOE9yJuCN2Jz/Ot62eJ+mzo7e qqUjbrnZR5DcFkyhBZeU26ngHLu7QvGe+6ptCg9FNitwsUCCiPTXeETM+MOGp8ls =
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=mattmccutchen.net; h= subject:from:to:cc:in-reply-to:references:content-type:date :message-id:mime-version:content-transfer-encoding; s= mattmccutchen.net; bh=7lNcisx33+DruA8x+EGwEmRnmrQ=; b=N0FhpPGxzi tqGhey8VeN/yVhrp5yGp8R5P5iW4v5cgjq2TIvYkVzlY77Rmg9glAzLQWkAlsah+ HoKWfa7RsP9tp98fQMQ5+dHvUMD/T5u+F7s3vp2pYCJjTEqdM7QmY27wPqx0ZHZq jimtgsPnL9RYLsJZ+0jzxmGbHarUk79Z0=
Received: from [129.2.142.162] (129-2-142-162.wireless.umd.edu [129.2.142.162]) (Authenticated sender: matt@mattmccutchen.net) by homiemail-a14.g.dreamhost.com (Postfix) with ESMTPA id 1F5AA8C06A; Fri, 29 Oct 2010 08:54:59 -0700 (PDT)
From: Matt McCutchen <matt@mattmccutchen.net>
To: Marsh Ray <marsh@extendedsubset.com>
In-Reply-To: <4CCAE36B.3030403@extendedsubset.com>
References: <4CC765D6.6020704@KingsMountain.com> <1288145780.6053.50.camel@mattlaptop2.local> <1288147744.6053.51.camel@mattlaptop2.local> <1288238488.2016.17.camel@mattlaptop2.local> <4CCAE36B.3030403@extendedsubset.com>
Content-Type: text/plain; charset="UTF-8"
Date: Fri, 29 Oct 2010 11:54:58 -0400
Message-ID: <1288367698.16220.31.camel@mattlaptop2.local>
Mime-Version: 1.0
X-Mailer: Evolution 2.30.4
Content-Transfer-Encoding: 7bit
Cc: IETF TLS WG <tls@ietf.org>
Subject: Re: [TLS] Connection diversion to other subdomains
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 29 Oct 2010 15:53:07 -0000

Marsh, thanks for the detailed advice.  Here are responses to some of
your points:

On Fri, 2010-10-29 at 10:08 -0500, Marsh Ray wrote:
> I've always been suspicious of wildcard certs, but didn't have real 
> ammunition to argue against them. You may have identified one, but 
> people may point out that it's only an issue in combination with the 
> known problem of HTTP servers accepting invalid Host headers.

I don't consider this issue a reason not to use wildcard certificates.
Since name-constrained delegation is (unfortunately) not widely
implemented by clients and not available for a reasonable price from
public CAs, wildcard certificates are quite practical for organizations
that want to operate a large number of subdomains.  But like any
security technology, they require careful deployment to prevent bad
things from happening.

> * Contact the three or four groups doing net-wide SSL cert surveys (SSL 
> Observatory, Qualys, etc). Get statistics from them and convince them 
> that wildcard certs are a vulnerability worth flagging.

As above, I won't argue that, but maybe they could incorporate the same
test I did manually, of connecting to a server with a wildcard
certificate and sending a request with SNI + HTTP Host for a subdomain
supposed to be served elsewhere.  Qualys/SSL Labs is probably the right
group to do this since they already look for different kinds of
deployment mistakes, while SSL Observatory is more focused on studying
the sprawl of the public CA system.

-- 
Matt