Re: [TLS] Implementation survey: Client Certificate URL extension
<Pasi.Eronen@nokia.com> Mon, 07 April 2008 07:35 UTC
Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2F6128C2F9; Mon, 7 Apr 2008 00:35:56 -0700 (PDT)
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 ADC4728C3B1 for <tls@core3.amsl.com>; Mon, 7 Apr 2008 00:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.085
X-Spam-Level:
X-Spam-Status: No, score=-5.085 tagged_above=-999 required=5 tests=[AWL=1.514, BAYES_00=-2.599, 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 bk9BKw50HlL3 for <tls@core3.amsl.com>; Mon, 7 Apr 2008 00:35:54 -0700 (PDT)
Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 1D51A28C2F8 for <tls@ietf.org>; Mon, 7 Apr 2008 00:34:58 -0700 (PDT)
Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m377YwvO019178; Mon, 7 Apr 2008 10:35:09 +0300
Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Apr 2008 10:35:06 +0300
Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 7 Apr 2008 10:35:06 +0300
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Mon, 07 Apr 2008 10:35:07 +0300
Message-ID: <1696498986EFEC4D9153717DA325CB7247F9A7@vaebe104.NOE.Nokia.com>
In-Reply-To: <200804041253.m34Crdxq028117@fs4113.wdf.sap.corp>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [TLS] Implementation survey: Client Certificate URL extension
thread-index: AciWUwAVQQUeJB9vTBmkZIhYwJ0XKgCLn6Qg
References: <1696498986EFEC4D9153717DA325CB7247EFE3@vaebe104.NOE.Nokia.com> from "Pasi.Eronen@nokia.com" at Apr 4, 8 11:24:30 am <200804041253.m34Crdxq028117@fs4113.wdf.sap.corp>
From: Pasi.Eronen@nokia.com
To: martin.rex@sap.com
X-OriginalArrivalTime: 07 Apr 2008 07:35:06.0544 (UTC) FILETIME=[E6807300:01C89881]
X-Nokia-AV: Clean
Cc: tls@ietf.org
Subject: Re: [TLS] Implementation survey: Client Certificate URL extension
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-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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces@ietf.org
Errors-To: tls-bounces@ietf.org
Martin Rex wrote: > Pasi.Eronen@nokia.com wrote: > > > > This vulnerability of Client Certificate URL is already described in > > the Security Considerations text in RFC 4366, so it isn't anything > > particularly new. > > > > In the context of web browsing over TLS, it isn't really different > > than, say, the ability to include IMG URLs pointing to arbitrary > > hosts (not just the one the HTML page came from). > > It is completely different! > > The regular HTTP/HTML based attacks attack the client/browser. > > The certificate extensions and the client-cert-URL extension for TLS > attack the server, and there is no "must visit a hostile website" > involved at all, the server is guaranteed to fall prey to every > attack automatically if it supports/implements such a feature (or > "inherits" this feature from the underlying middleware). You're quite right, I wasn't thinking clearly -- this is indeed quite different, since it targets the server. Nevertheless, it is described in RFC 4366 already; do you think there's something more we should add in 4366bis? Best regards, Pasi _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
- [TLS] Implementation survey: Client Certificate U… Pasi.Eronen
- Re: [TLS] Implementation survey: Client Certifica… Rob Dugal
- Re: [TLS] Implementation survey: Client Certifica… Dieter Bratko
- Re: [TLS] Implementation survey: Client Certifica… Martin Rex
- Re: [TLS] Implementation survey: Client Certifica… Peter Gutmann
- Re: [TLS] Implementation survey: Client Certifica… Pasi.Eronen
- Re: [TLS] Implementation survey: Client Certifica… Martin Rex
- Re: [TLS] Implementation survey: Client Certifica… Peter Gutmann
- Re: [TLS] Implementation survey: Client Certifica… Nelson B Bolyard
- Re: [TLS] Implementation survey: Client Certifica… Pasi.Eronen
- Re: [TLS] Implementation survey: Client Certifica… Martin Rex
- Re: [TLS] Implementation survey: Client Certifica… Mike
- Re: [TLS] Implementation survey: Client Certifica… Eric Rescorla
- [TLS] AIA cert fetching seen as harmful Nelson B Bolyard
- Re: [TLS] AIA cert fetching seen as harmful Eric Rescorla
- Re: [TLS] AIA cert fetching seen as harmful Nelson B Bolyard
- Re: [TLS] AIA cert fetching seen as harmful Eric Rescorla
- Re: [TLS] AIA cert fetching seen as harmful Mike
- Re: [TLS] Implementation survey: Client Certifica… Florian Weimer
- Re: [TLS] AIA cert fetching seen as harmful Nelson B Bolyard
- Re: [TLS] AIA cert fetching seen as harmful Nelson B Bolyard
- Re: [TLS] AIA cert fetching seen as harmful Mike