Re: [TLS] Eleven out of every ten SSL certs aren't valid

Steffen Schulz <pepe_ml@gmx.net> Wed, 30 June 2010 15:29 UTC

Return-Path: <pepe_ml@gmx.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 9DF493A684A for <tls@core3.amsl.com>; Wed, 30 Jun 2010 08:29:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.835
X-Spam-Level:
X-Spam-Status: No, score=-0.835 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 BGHYI8MmHjuw for <tls@core3.amsl.com>; Wed, 30 Jun 2010 08:29:17 -0700 (PDT)
Received: from mx6.rz.ruhr-uni-bochum.de (mx6.rz.ruhr-uni-bochum.de [134.147.64.30]) by core3.amsl.com (Postfix) with SMTP id 41FD53A67E9 for <tls@ietf.org>; Wed, 30 Jun 2010 08:29:16 -0700 (PDT)
X-Queued: (qmail 9737 invoked by uid 108); 30 Jun 2010 15:29:26 -0000
X-Qmailscanner: from 134.147.119.250 by mx6.rz.ruhr-uni-bochum.de (envelope-from <pepe_ml@gmx.net>, uid 102) with qmail-scanner-2.01 (sophie: 3.05/3.7/4.53. Clear:RC:1(134.147.119.250):. Processed in 0.014937 secs); 30 Jun 2010 15:29:26 -0000
Received: from lak-119-250.wohnheime.ruhr-uni-bochum.de (HELO cbg.dyndns.org) (134.147.119.250) by mx6.rz.ruhr-uni-bochum.de with SMTP; 30 Jun 2010 15:29:26 -0000
Received: by cbg.dyndns.org (Postfix, from userid 1000) id B1AB3127507; Wed, 30 Jun 2010 17:29:26 +0200 (CEST)
Date: Wed, 30 Jun 2010 18:29:27 +0200
From: Steffen Schulz <pepe_ml@gmx.net>
To: tls@ietf.org
Message-ID: <20100630162927.GB17606@cbg.dyndns.org>
References: <20100629204614.GX11785@oracle.com> <E1OTsCc-00010m-Vl@wintermute02.cs.auckland.ac.nz>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <E1OTsCc-00010m-Vl@wintermute02.cs.auckland.ac.nz>
User-Agent: Mutt/1.5.20 (2009-06-14)
Subject: Re: [TLS] Eleven out of every ten SSL certs aren't valid
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: Wed, 30 Jun 2010 15:29:21 -0000

On 100630 at 10:09, Peter Gutmann wrote:
> Nicolas Williams <Nicolas.Williams@oracle.com> writes:
> >On Tue, Jun 29, 2010 at 09:29:01PM +0100, Ivan Ristic wrote:
> >> The fact that we cannot stop bad certs is not relevant. Such sites are
> >> still reducing the effectiveness of SSL, even for the "sites that
> >> ought to be using HTTPS". And that was my point.
> >
> >Maybe, but if there's nothing you can do about this, what do you propose to
> >do then?
> 
> The first step to recovery is to admit that you have a problem.
> 
> In this case we have a very serious problem (close to 100% false positives
> rendering cert use _m_e_a_n_i_n_g_l_e_s_s_ - did I decorate that right?) and
> if, as you say, there really isn't anything anyone can do about this then we
> need to start looking at other solutions, because there's no way we can get
> anywhere with the current one.


Like KCM for all the not-that-important sites. And whereever some more
critical client authentication is involved, the protocol must ensure
that those credentials are only meaningful to the correct server.
Like in client auth via TLS-SRP.

(Now comes the part where somebody replies that this is all solved by
 client certificates and the discussion is closed 'til next time...)



/steffen