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

[Nikos Mavrogiannopoulos <nmav at gnutls.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 whicFrom tls-bounces at ietf.org  Thu Oct  9 23:00:17 2008
Return-Path: <tls-bounces at ietf.org>
X-Original-To: tls-archive at ietf.org
Delivered-To: ietfarch-tls-archive at 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 at core3.amsl.com
Delivered-To: tls at core3.amsl.com
Received: from localhost (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 273453A67D8
	for <tls at 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 at 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 at 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 at 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 at gnutls.org>
Date: Fri, 10 Oct 2008 09:00:53 +0300
From: Nikos Mavrogiannopoulos <nmav at gnutls.org>
User-Agent: Thunderbird 2.0.0.17 (X11/20080925)
MIME-Version: 1.0
To: Francois Daoust <fd at w3.org>
References: <48EDFE85.8020801 at w3.org>
In-Reply-To: <48EDFE85.8020801 at w3.org>
X-Enigmail-Version: 0.95.0
Cc: Philippe Le Hegaret <plh at w3.org>, Mark Nottingham <mnot at mnot.net>,
	public-ietf-w3c at w3.org, tls at ietf.org,
	public-bpwg-ct <public-bpwg-ct at w3.org>
Subject: Re: [TLS] W3C Content Transformation Proxies guidelines and security
X-BeenThere: tls at 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 at ietf.org?subject=unsubscribe>
List-Post: <mailto:tls at ietf.org>
List-Help: <mailto:tls-request at ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>,
	<mailto:tls-request at ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tls-bounces at ietf.org
Errors-To: tls-bounces at 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 hh 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 at ietf.org
https://www.ietf.org/mailman/listinfo/tls


e 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 at ietf.org
https://www.ietf.org/mailman/listinfo/tls