Re: [TLS] Connection diversion to other subdomains

Marsh Ray <marsh@extendedsubset.com> Fri, 29 October 2010 15:06 UTC

Return-Path: <marsh@extendedsubset.com>
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 AD94D3A6A9A for <tls@core3.amsl.com>; Fri, 29 Oct 2010 08:06:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.109
X-Spam-Level:
X-Spam-Status: No, score=-2.109 tagged_above=-999 required=5 tests=[AWL=0.490, 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 2uxTTzurcr7p for <tls@core3.amsl.com>; Fri, 29 Oct 2010 08:06:35 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 5E7773A6A96 for <tls@ietf.org>; Fri, 29 Oct 2010 08:06:35 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1PBqZB-0002mn-Qb; Fri, 29 Oct 2010 15:08:29 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 20F016019; Fri, 29 Oct 2010 15:08:28 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1+St/egGjrStS7Z/meJ2+6kRT6MshFJStU=
Message-ID: <4CCAE36B.3030403@extendedsubset.com>
Date: Fri, 29 Oct 2010 10:08:27 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.14) Gecko/20101006 Thunderbird/3.0.9
MIME-Version: 1.0
To: Matt McCutchen <matt@mattmccutchen.net>
References: <4CC765D6.6020704@KingsMountain.com> <1288145780.6053.50.camel@mattlaptop2.local> <1288147744.6053.51.camel@mattlaptop2.local> <1288238488.2016.17.camel@mattlaptop2.local>
In-Reply-To: <1288238488.2016.17.camel@mattlaptop2.local>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
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:06:36 -0000

On 10/27/2010 11:01 PM, Matt McCutchen wrote:
> Strictly speaking, this is a vulnerability.  Usually the
> effect is just goofy, though on one major web site which I won't name,
> it led to XSS.
>
> How can I get the message out to holders of wildcard certificates that
> they should prevent this attack?

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.

Here's what I would do:

* 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.

* Find existing CVE number(s) which involve this vulnerability 
specifically or wildcard certs general. Referencing a CVE immediately 
sets many processes in motion for organizations to take it seriously.

* Post a description of the vulnerability to the [Full-Disclosure] 
mailing list. Be prepared for no intelligent discussion to ensue, but 
you can be sure that it will be read by the people who matter. It's 
likely that bad guys and professional pen testers will say "well duh 
everybody knows that already" yet there will also be a lot of site 
admins shocked to find they are vulnerable.

* Publish an open-source point-and-click exploit tool, either as a 
standalone module or part of an existing framework (e.g. Metasploit). 
This is not bad-guy hacking (the bad guys know about this already), it's 
simply the process that the industry has chosen, and it definitively 
settles the "is this or is it not a real vulnerability" question.

A plethora of examples show that the availability of a public exploit 
usually greatly reduces the area under the vulnerable-systems-over-time 
curve.

For example, every network app developer knows that plaintext HTTP and 
open WiFi provides absolutely no security, yet the publicity around
http://www.google.com/search?q=firesheep
will probably do more for the adoption of TLS than anything else this year.

- Marsh