Re: [TLS] Handshake not under protection

Marsh Ray <marsh@extendedsubset.com> Mon, 21 December 2009 22:47 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 851323A697C for <tls@core3.amsl.com>; Mon, 21 Dec 2009 14:47:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.592
X-Spam-Level:
X-Spam-Status: No, score=-2.592 tagged_above=-999 required=5 tests=[AWL=0.007, 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 guQg+J3p5Bod for <tls@core3.amsl.com>; Mon, 21 Dec 2009 14:47:43 -0800 (PST)
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by core3.amsl.com (Postfix) with ESMTP id AD71F3A682C for <tls@ietf.org>; Mon, 21 Dec 2009 14:47:43 -0800 (PST)
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 1NMr2F-0006Nq-5n; Mon, 21 Dec 2009 22:47:27 +0000
Received: from [127.0.0.1] (localhost [127.0.0.1]) by xs01.extendedsubset.com (Postfix) with ESMTP id 12F5A603A; Mon, 21 Dec 2009 22:47:25 +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: U2FsdGVkX18ivlOoDHX6M4lzQR2iNHoocC08zgVrBKk=
Message-ID: <4B2FFB00.4050505@extendedsubset.com>
Date: Mon, 21 Dec 2009 16:47:28 -0600
From: Marsh Ray <marsh@extendedsubset.com>
User-Agent: Thunderbird 2.0.0.23 (Windows/20090812)
MIME-Version: 1.0
To: mrex@sap.com
References: <200912212222.nBLMMs7D011751@fs4113.wdf.sap.corp>
In-Reply-To: <200912212222.nBLMMs7D011751@fs4113.wdf.sap.corp>
X-Enigmail-Version: 0.96.0
OpenPGP: id=1E36DBF2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: tls@ietf.org
Subject: Re: [TLS] Handshake not under protection
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: Mon, 21 Dec 2009 22:47:44 -0000

Martin Rex wrote:
> Michael D'Errico wrote:
>> If a DHE cipher suite is used, then the server can be authenticated
>> using only Certificate and ServerKeyExchange.  With RSA cipher suites,
>> you are correct that a client doesn't authenticate the server until
>> Finished verifies.
> 
> I'm not sure I can follow why you think it is protected.
> 
> RFC-5246, 7.4.3.  Server Key Exchange Message
> 
>       struct {
>           select (KeyExchangeAlgorithm) {
>               case dh_anon:
>                   ServerDHParams params;
>               case dhe_dss:
>               case dhe_rsa:
>                   ServerDHParams params;
>                   digitally-signed struct {
>                       opaque client_random[32];
>                       opaque server_random[32];
>                       ServerDHParams params;
>                   } signed_params;
>               case rsa:
>               case dh_dss:
>               case dh_rsa:
>                   struct {} ;
>                  /* message is omitted for rsa, dh_dss, and dh_rsa */
>               /* may be extended, e.g., for ECDH -- see [TLSECC] */
>           };
>       } ServerKeyExchange;
> 
> There is signed_params in the Server Key Exchange Message, but
> it does _not_ seem to protect from MitM (when the attackers objective
> is to elicit a Certificate message with the client's identity
> from the attacked client).
> 
> If an attacker has a rogue server that wants to determine the client's
> identity, then this attacker could open a connection to the particular
> server to which it knows the client will reveal his identity,
> resend the ClientHello just received and obtain a ServerHello and
> ServerKeyExchange that match and then replay this information to
> the client (i.e. the server_random used by the real server and
> the signed_params sent by the real server.

I think you stopped too soon:

http://tools.ietf.org/html/rfc4346#page-42
>      struct {
>           select (KeyExchangeAlgorithm) {
>               case diffie_hellman:
>                   ServerDHParams params;
>               case rsa:
>                   ServerRSAParams params;
>           };
>        } ServerParams;
> 
>       params
>           The server's key exchange parameters.
> 
>       signed_params
>           For non-anonymous key exchanges, a hash of the corresponding
>           params value, with the signature appropriate to that hash
>           applied.
> 
>       md5_hash
>           MD5(ClientHello.random + ServerHello.random + ServerParams);
> 
>       sha_hash
>           SHA(ClientHello.random + ServerHello.random + ServerParams);

AFAICT, MitM is forced to pass the same DHE params from the server to
the client, else he breaks the signed hash which covers ServerParams.

Since he passes the correct DHE params S->C, he cannot intercept the
traffic from client to server.

- Marsh