Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer

Martin Rex <Martin.Rex@sap.com> Tue, 29 September 2009 21:48 UTC

Return-Path: <Martin.Rex@sap.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 D623228C0CE; Tue, 29 Sep 2009 14:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.986
X-Spam-Level:
X-Spam-Status: No, score=-5.986 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, HELO_EQ_DE=0.35, 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 bdba1+e1APoO; Tue, 29 Sep 2009 14:48:03 -0700 (PDT)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id BD8A83A69FF; Tue, 29 Sep 2009 14:48:02 -0700 (PDT)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id n8TLnMCE011633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 29 Sep 2009 23:49:22 +0200 (MEST)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200909292149.n8TLnLpA006226@fs4113.wdf.sap.corp>
To: mike-list@pobox.com (Michael D'Errico)
Date: Tue, 29 Sep 2009 23:49:21 +0200 (MEST)
In-Reply-To: <4AC18CDC.40105@pobox.com> from "Michael D'Errico" at Sep 28, 9 09:28:12 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Cc: simon@josefsson.org, tls@ietf.org, ietf@ietf.org
Subject: Re: [TLS] Last Call: draft-ietf-tls-rfc4366-bis (Transport Layer
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: martin.rex@sap.com
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 Sep 2009 21:48:03 -0000

Michael D'Errico wrote:
> 
> > 
> > I do not see why you consider this a vulnerability in the _server_!
> 
> Because a malicious client could theoretically establish a secure
> connection using one server domain and then ask for pages from a
> different domain.  If the server does not check for this, it could
> potentially leak sensitive information.


You're barking up the wrong tree.  If the client did not use TLS,
the server wouldn't even know that.

It is inappropriate to assume that virtual hosting provides seperation
of content and draw a conclusion that, when accesses via HTTPS,
will provide a secure seperation of content instead.

If the lack of such a server-side check is a problem for your
server, then your server problably has a severe design flaw in
its session management.


> 
> And I'm curious: why do you call matching the commonName weak?

Because in the vast majority of situatins it is the last step
in a long row of flawed assumptions.

Security is only as strong as its weakest link.  The authentication
process based on a DNSName involves a number of very weak authentications.

DNS domain names are not very genuine, and it is very non-obvious
which domain names are used by the business or peer someone is
looking for and which are used by others (different businesses with
the same name, cybersquatters or attackers).  Most HTTPS-URLs opened
by Web Browsers are served through plaintext HTTP pages.

Then most Browser PKIs come with a hundred or more trusted CAs
preconfigured, and browsers trust them equally.  Whether or how
secure the authentication is that the CA performs before issuing
a certificate is another flawed assumption that weakens the
rfc-2818 server endpoint authentication.

A final flaw that is still present in most browsers is the
lack of memory.  Not memorizing the certificate that a
server presented on the last contact perpetuates the
weakness of the original authentication.

Personally, I think that deriving a server endpoint identifier
from a network address is the most flawed assumption of all.

That is like asserting that if someone opens on a random door
on which you knock, and shows you an ID card with the correct
street address -- then he must be a GOOD guy.


-Martin