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

Rob P Williams <rwilliams@certicom.com> Tue, 29 June 2010 15:03 UTC

Return-Path: <rwilliams@certicom.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 0A06D3A6BAD for <tls@core3.amsl.com>; Tue, 29 Jun 2010 08:03:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.603
X-Spam-Level:
X-Spam-Status: No, score=-2.603 tagged_above=-999 required=5 tests=[BAYES_50=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
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 lLSk2Cg+S4NE for <tls@core3.amsl.com>; Tue, 29 Jun 2010 08:03:13 -0700 (PDT)
Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 8E2503A69B1 for <tls@ietf.org>; Tue, 29 Jun 2010 08:03:13 -0700 (PDT)
X-AuditID: 0a401fcb-b7c04ae000000afa-90-4c2a0b3b2344
Received: from XHT105CNC.rim.net ( [10.65.12.216]) by mhs03ykf.rim.net (RIM Mail) with SMTP id DC.67.02810.B3B0A2C4; Tue, 29 Jun 2010 11:03:23 -0400 (EDT)
To: undisclosed-recipients:;
Received: from XCH117CNC.rim.net ([fe80::a136:e723:2796:5b59]) by XHT105CNC.rim.net ([fe80::24dd:699b:a19e:2bcc%11]) with mapi; Tue, 29 Jun 2010 11:03:23 -0400
From: Rob P Williams <rwilliams@certicom.com>
CC: "tls@ietf.org" <tls@ietf.org>
Date: Tue, 29 Jun 2010 11:03:22 -0400
Thread-Topic: [TLS] Eleven out of every ten SSL certs aren't valid
Thread-Index: AcsXlQpeoYsNXnhQRGKxbE0aBMAWggAAbLVg
Message-ID: <7C6BDB4BD9974646856544650C016B82139E7C@XCH117CNC.rim.net>
References: <E1OTVaY-0004g3-OW@wintermute02.cs.auckland.ac.nz> <201006291350.o5TDoMoO018788@fs4113.wdf.sap.corp> <AANLkTinWDU7RKXRU1drErtWZSdOyGwSymOBdwXSnYMEB@mail.gmail.com>
In-Reply-To: <AANLkTinWDU7RKXRU1drErtWZSdOyGwSymOBdwXSnYMEB@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
content-transfer-encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAwAAAZEU4MqXFODLPA==
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: Tue, 29 Jun 2010 15:03:15 -0000

Two comments, one on protocol, one on research...

Protcol:
========

RFC 3546 (3.1):
   If the server understood the client hello extension but does not
   recognize the server name, it SHOULD send an "unrecognized_name"
   alert (which MAY be fatal).

Asking www.goolemail.com for www.oracle.com proceeds with mail.google.com's certificate...

Martin's example of www.gmex.net sends a html forward to www.gmex.de using www.gmex.de's certificate...

SNI has the mechanism to say:
	Not me!   - which Google Mail isn't using...

SNI should have the mechanism to do what GMEX is doing - but doesn't.
	Client Hello: Give me www.gmex.de
	Server Hello: Let's use RSA!, ps: but you should try www.gmex.net 

Browsers could then make a more informed choice then just a "this site is bad" page.



Let's draft SNI(II)!!!



Research:
=========

What steps are being taken to verify that 'valid' ssl is even intended?

The www.oracle.com example is perfect. Oracle doesn't have an SSL site so you get an Akamai certificate - and your browser says, "This is not trusted" - which is correct!

I wonder how different your numbers are when the IP address is reversed and compared again to the certificate. That's one way to measure lack of intent to have an SSL site.

Test servers that we host have self signed certificates with various key sizes and curves... We do not intend for them to be trusted. A regular user who has no interest in TLS interop getting a non-trusted warning from these test servers is a good thing. All the test sites out there are skewing your numbers.

It appears like the people at www.gmex.de intend for people to access them as www.gmex.net - that's why they bought the www.gmex.net certificate...

If you are trying to prove that lots of people don't intend to have SSL on their website, or have it accessed the way your tried - then you could well be on the road to achieving that goal.

These sound like numbers intended to scare people. If you are going to publish without the first paragraph mentioning that "100% of modern browsers will alert a user to configuration issues that are detected herein" - then... what's your point?



--
rob | Team Lead, Certicom Java Toolkits
Certicom Corp. | A subsidiary of Research In Motion Limited

rwilliams@certicom.com
www.certicom.com


















-----Original Message-----
From: tls-bounces@ietf.org [mailto:tls-bounces@ietf.org] On Behalf Of Adam Langley
Sent: Tuesday, June 29, 2010 10:12 AM
To: mrex@sap.com
Cc: tls@ietf.org
Subject: Re: [TLS] Eleven out of every ten SSL certs aren't valid

On Tue, Jun 29, 2010 at 9:50 AM, Martin Rex <mrex@sap.com> wrote:
> Try "www.oracle.com", "www.googlemail.com", "www.gmx.de".
> You can get correct answers for "mail.google.com" and "www.gmx.net".

You should get a correct certificate for www.googlemail.com if you
present a Server Name Indication extension.


AGL
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls

---------------------------------------------------------------------
This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client or other applicable privileges), or constitute non-public information. Any use of this information by anyone other than the intended recipient is prohibited. If you have received this transmission in error, please immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.