Re: [TLS] Finished verify_data collision (Was Re: draft-turner-ssl-must-not)

Marsh Ray <marsh@extendedsubset.com> Thu, 08 July 2010 15:34 UTC

Return-Path: <marsh@extendedsubset.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 8AF533A6AD9 for <tls@core3.amsl.com>; Thu, 8 Jul 2010 08:34:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[AWL=1.101, 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 2TpKrjahhkd8 for <tls@core3.amsl.com>; Thu, 8 Jul 2010 08:34:00 -0700 (PDT)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id 9B9673A6AFD for <tls@ietf.org>; Thu, 8 Jul 2010 08:33:56 -0700 (PDT)
Received: from xs01.extendedsubset.com ([69.164.193.58]) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from <marsh@extendedsubset.com>) id 1OWt6u-0007nm-H8; Thu, 08 Jul 2010 15:34:00 +0000
Received: from [192.168.1.15] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id A1FF86334; Thu, 8 Jul 2010 15:33:53 +0000 (UTC)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 69.164.193.58
X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX1/YjjU5QRmrkhmC1zfsXe8nzaWNCBj4r5c=
Message-ID: <4C35EFE1.7090502@extendedsubset.com>
Date: Thu, 08 Jul 2010 10:33:53 -0500
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.10) Gecko/20100527 Thunderbird/3.0.5
MIME-Version: 1.0
To: Nikos Mavrogiannopoulos <nmav@gnutls.org>
References: <C858DD65.5897%uri@ll.mit.edu> <4C33954B.5070308@extendedsubset.com> <87zky372ew.fsf@mocca.josefsson.org> <4C35107D.6040505@extendedsubset.com> <AANLkTinOHuAZT79Cwm75gsCANpjRCkB2bWAc4vWF23Ez@mail.gmail.com>
In-Reply-To: <AANLkTinOHuAZT79Cwm75gsCANpjRCkB2bWAc4vWF23Ez@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: Simon Josefsson <simon@josefsson.org>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Finished verify_data collision (Was Re: draft-turner-ssl-must-not)
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: Thu, 08 Jul 2010 15:34:01 -0000

On 07/08/2010 03:07 AM, Nikos Mavrogiannopoulos wrote:
> [...]
>> * Mitm needs to obtain the client's premaster secret as part of the attack
>> (the key material is needed to generate the hash). Note this is trivial with
>> some real clients in common use that don't validate the server cert until
>> they receive the Finished message.
>
> Why is this trivial?

Mitm can present his own cert that he has the private keys to. It might 
be self signed, signed by a CA cert calling itself "Verisign", or signed 
by the real Verisign but issued to mitm.example.com.

Another possibility is that he could downgrade the connection to 
something he could break.

> If you do mitm it will be discovered at the
> verification point and game is over.

Maybe not. Attacker may have accomplished his objective, he may only 
need 50 ms of unauthorized access (or to commit one transaction) in 
order to install a persistent backdoor.

Considering the lack of concern typical web users have for certificate 
warnings, I think there's plenty of room for an attacker to avoid or 
delay detection. When was the last time you compared the binary RSA 
parameters on a cert warning? A successful attack on unattended systems 
may be recorded in the logs as simply a single connection failed.

- Marsh