Re: [TLS] W3C Content Transformation Proxies guidelines and security

Nikos Mavrogiannopoulos <nmav@gnutls.org> Fri, 10 October 2008 06:00 UTC

Return-Path: <tls-bounces@ietf.org>
X-Original-To: tls-archive@ietf.org
Delivered-To: ietfarch-tls-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7838E3A6907; Thu, 9 Oct 2008 23:00:17 -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 273453A67D8 for <tls@core3.amsl.com>; Thu, 9 Oct 2008 23:00:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[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 EXRj0jDfm9oE for <tls@core3.amsl.com>; Thu, 9 Oct 2008 23:00:15 -0700 (PDT)
Received: from fk-out-0910.google.com (fk-out-0910.google.com [209.85.128.187]) by core3.amsl.com (Postfix) with ESMTP id BE8B43A6859 for <tls@ietf.org>; Thu, 9 Oct 2008 23:00:14 -0700 (PDT)
Received: by fk-out-0910.google.com with SMTP id 18so316768fkq.5 for <tls@ietf.org>; Thu, 09 Oct 2008 23:00:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding:sender; bh=llu4UE3aB882mbXIqidPA9aa/YNDhco5dvnIQavQp+Q=; b=Qq1g711o25YSgGVDGB3G/JRe4QrTOjMLdWrPIksN0K2vYtCGs73p+LTN/BEzDMH8ug vAvMUQzehjC5RW6WtjfYvetYELn3ZAymwZpjEzMS4bdZaF6839QX5eghCmTeYFJLbRIZ RrFII6l5vkhQB+92QBBmwtWiaae2je2aX8A+0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:x-enigmail-version:content-type :content-transfer-encoding:sender; b=tqZC930DTwwOB1iEMfVSNQ31pJovXL1TR5DUKXSF2lhh0uQMsZxg7lbvRHxtVIcADH Pnp7WeaQ6V3fgAQPXSzfQSb09dzmNMKIlBXav9kHiAHgDLd588GxLeRUrmnFLOXeaC8x LLWyma4XzSDWGXp9MXJVdi32dLNcEDNvq4tY4=
Received: by 10.181.62.7 with SMTP id p7mr1062831bkk.7.1223618457455; Thu, 09 Oct 2008 23:00:57 -0700 (PDT)
Received: from ?10.100.1.196? (adsl30-40.ath.forthnet.gr [77.49.221.40]) by mx.google.com with ESMTPS id 28sm1344167fkx.1.2008.10.09.23.00.55 (version=SSLv3 cipher=RC4-MD5); Thu, 09 Oct 2008 23:00:56 -0700 (PDT)
Message-ID: <48EEEF95.6010401@gnutls.org>
Date: Fri, 10 Oct 2008 09:00:53 +0300
From: Nikos Mavrogiannopoulos <nmav@gnutls.org>
User-Agent: Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version: 1.0
To: Francois Daoust <fd@w3.org>
References: <48EDFE85.8020801@w3.org>
In-Reply-To: <48EDFE85.8020801@w3.org>
X-Enigmail-Version: 0.95.0
Cc: Philippe Le Hegaret <plh@w3.org>, Mark Nottingham <mnot@mnot.net>, public-ietf-w3c@w3.org, tls@ietf.org, public-bpwg-ct <public-bpwg-ct@w3.org>
Subject: Re: [TLS] W3C Content Transformation Proxies guidelines and security
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

Francois Daoust wrote:

> HTTPS communications obviously cannot be intercepted by a Content
> Transformation proxy. However, such a proxy can re-write HTTPS links
> that appear in an HTTP response so that the user goes through it when it
> clicks on the link.

Since this is a man-in-the-middle attack, it would be interesting to
know how browsers react in that case. It should be have been made clear
to the user which site he connected to (www.proxy.com instead of
www.amazon.com).

Anyway, about (b). the server cannot detect the attack (unless of course
he requests client certificates) via the TLS protocol, the client could.
The server could detect the attack by noticing few IPs that make many
different transactions.

But actually what you are trying to achieve changes all that is known to
people for "secure" web pages. Now with your scheme you don't trust the
merchant, but the network provider[0]. So for your point (1), I would
say that it is not just a "security" issue, it is a total change of the
protocol currently used for secure web browsing.


[0]. And it is much more than that. Once users get used to have some
proxy between them and the merchant's site, it would be much easier to
attack the TLS protocol that way. That is because noone will verify the
identity of the site they connected to.

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