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
- [TLS] Server Name Indication (SNI) in an IPv6 wor… =JeffH
- Re: [TLS] Server Name Indication (SNI) in an IPv6… Simon Josefsson
- Re: [TLS] Server Name Indication (SNI) in an IPv6… Matt McCutchen
- Re: [TLS] Server Name Indication (SNI) in an IPv6… Matt McCutchen
- Re: [TLS] Server Name Indication (SNI) in an IPv6… Steingruebl, Andy
- Re: [TLS] Server Name Indication (SNI) in an IPv6… Marsh Ray
- Re: [TLS] Server Name Indication (SNI) in an IPv6… Steingruebl, Andy
- Re: [TLS] Server Name Indication (SNI) in an IPv6… Marsh Ray
- Re: [TLS] Server Name Indication (SNI) in an IPv6… Michael D'Errico
- [TLS] Connection diversion to other subdomains Matt McCutchen
- Re: [TLS] Server Name Indication (SNI) in an IPv6… Steven Bellovin
- Re: [TLS] Server Name Indication (SNI) in an IPv6… aerowolf
- Re: [TLS] Connection diversion to other subdomains Marsh Ray
- Re: [TLS] Connection diversion to other subdomains Matt McCutchen
- Re: [TLS] Connection diversion to other subdomains Martin Rex
- Re: [TLS] Server Name Indication (SNI) in an IPv6… Dean Anderson
- Re: [TLS] Connection diversion to other subdomains Florian Weimer
- Re: [TLS] Connection diversion to other subdomains Marsh Ray
- Re: [TLS] Connection diversion to other subdomains Florian Weimer
- Re: [TLS] Connection diversion to other subdomains Marsh Ray
- Re: [TLS] Connection diversion to other subdomains Joe Orton
- Re: [TLS] Connection diversion to other subdomains Marsh Ray
- Re: [TLS] Connection diversion to other subdomains Matt McCutchen