[TLS] MITM attack on delayed TLS-client auth through renegotiation

Martin Rex <Martin.Rex@sap.com> Wed, 04 November 2009 17:27 UTC

Return-Path: <Martin.Rex@sap.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 6F20D28C0EC for <tls@core3.amsl.com>; Wed, 4 Nov 2009 09:27:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.462
X-Spam-Level:
X-Spam-Status: No, score=-5.462 tagged_above=-999 required=5 tests=[AWL=-0.702, BAYES_05=-1.11, HELO_EQ_DE=0.35, 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 ZlJ76v0awey1 for <tls@core3.amsl.com>; Wed, 4 Nov 2009 09:27:41 -0800 (PST)
Received: from smtpde03.sap-ag.de (smtpde03.sap-ag.de [155.56.68.140]) by core3.amsl.com (Postfix) with ESMTP id 4C67D28C0F6 for <tls@ietf.org>; Wed, 4 Nov 2009 09:27:41 -0800 (PST)
Received: from mail.sap.corp by smtpde03.sap-ag.de (26) with ESMTP id nA4HS1s5007450 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <tls@ietf.org>; Wed, 4 Nov 2009 18:28:01 +0100 (MET)
From: Martin Rex <Martin.Rex@sap.com>
Message-Id: <200911041728.nA4HS0rd003407@fs4113.wdf.sap.corp>
To: tls@ietf.org
Date: Wed, 4 Nov 2009 18:28:00 +0100 (MET)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Scanner: Virus Scanner virwal05
X-SAP: out
Subject: [TLS] MITM attack on delayed TLS-client auth through renegotiation
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: mrex@sap.com
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: Wed, 04 Nov 2009 17:27:42 -0000

After elaborating so much about the client cert authentication
through renegotiation with Microsoft IIS, I'm beginning to believe
that there is a potential security problem with that scheme,
because it is susceptible to a MITM attack.

How serious the problem is depends on whether and how the client
performs the server identification on the renegotiation TLS handshake.

The problem:  when Microsoft IIS is configured to request a client
certificate after having received the request, then it WILL perform
an unauthenticated request!  Sending the reply back only to the
authenticated client is a poor excuse for acting on an unauthenticated
request.


Attack scenario:


             sess1                                 sess2
  TLS client <--->  rogue TLS server (doing MITM)  <--->  victim MS IIS


The roge TLS server waits for innocent clients to connect and offers
to accept the same TLS client certs than the victim MS IIS server.

If a TLS client with a promising TLS client cert connects (sess1),
then the rogue TLS server establishes an anonymous TLS connection
(sess2) with the victim MS IIS server and sends the request it wants
performed (URL with command parameters) to the victim MS IIS server--
which replys with a Hello Request asking for a full TLS handshake
of an entirely new and independent authenticated TLS session (sess3)

At this point, the rogue TLS server starts relaying the TLS
handshake messages between the TLS client and the victim MS IIS,
i.e. it forwards all handshake messages it receives over sess2
to the client over sess1, and likewise forward all handshake
messages it receives over sess1 to the victim MS IIS over sess2.

The ChangeCipherSpec is the last Handshake message on each
direction that is decrypted/encrypted under the original sess1/sess2
settings, for all further communication, the rogue TLS server (MITM)
will forward the incoming network data 1:1 to the other side
(because that is protected under keys known only to the TLS client
and to the victim MS IIS.


The victim MS IIS server has no means to detect that it has been
attacked.  Whether the TLS client cares about receiving a different
TLS server cert in the renegotiation handshake and what it will
do about it -- if anything, depends entirely on the application
of the TLS client.  At the TLS level, everything looks just fine.

I'm not sure that all clients will repeat the server authentication.
They can be expected to verify the server certificate before sending
off their request.  Depending on the API architecture, they may not
always realize or care that a renegotiation was performed while they
were sitting on SSL_read() waiting for the server reply.

And even if they decide to perform an additional server endpoint
identification, they might be doing it after the renegotiate
handshake has been successfully completed -- a point where the
victim MS IIS has started performing the action requested
in the anonymous request from the MITM.


-Martin