IETF Logo Mail Archive

Re: [TLS] User Defined Key Pair

Juho Vähä-Herttua <juhovh@iki.fi> Tue, 25 June 2013 21:54 UTC

Return-Path: <juhovh@iki.fi>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490B721E80E3 for <tls@ietfa.amsl.com>; Tue, 25 Jun 2013 14:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.903
X-Spam-Level:
X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_QP_LONG_LINE=1.396]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iC5cMr90+dhO for <tls@ietfa.amsl.com>; Tue, 25 Jun 2013 14:54:01 -0700 (PDT)
Received: from kirsi1.inet.fi (mta-out.inet.fi [195.156.147.13]) by ietfa.amsl.com (Postfix) with ESMTP id D202F21F9EE1 for <tls@ietf.org>; Tue, 25 Jun 2013 14:54:00 -0700 (PDT)
Received: from [10.60.82.223] (188.238.211.223) by kirsi1.inet.fi (8.5.140.03) id 51BB5BE300DE69E0; Wed, 26 Jun 2013 00:53:55 +0300
References: <CALxQUYGdagDHr+A4EKN5qPD1jZG+dH8PHwb0-fKJVUN_vC1MSg@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EE97@USMBX1.msg.corp.akamai.com> <CALxQUYGpcKPOAoZ8J56AoUGx8B3JhdmMche8MdQuqD_S=Y22ZQ@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EF0E@USMBX1.msg.corp.akamai.com> <CALxQUYF1=oFBk=WZFoey+28j7MV7YvSkAD-YzJSeQ0Dp7uXmEA@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251EFFF@USMBX1.msg.corp.akamai.com> <CALxQUYH-4HR7sO2jfxQnbro6+xM5hD_hdW-K_a-Esd9yiZ+oug@mail.gmail.com> <2A0EFB9C05D0164E98F19BB0AF3708C711B251F1E5@USMBX1.msg.corp.akamai.com> <CALxQUYEeLRxGz=_CO8pMYc4u2rm8u+u6fTiYH_3UMev-pNFC4g@mail.gmail.com> <CALxQUYF_ekkkGuhQdK7mJFJj5HcHJybXJYyvKZ721Qz_k_Td5w@mail.gmail.com> <377FB9023E313048955F1A4A54DB21009A5676E9@365EXCH-MBX-P3.nbttech.com> <CALxQUYH_mR-_KNnER8DQGrpGZvLF4PgP9c8-g-wkhkg1BiDd1A@mail.gmail.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <CALxQUYH_mR-_KNnER8DQGrpGZvLF4PgP9c8-g-wkhkg1BiDd1A@mail.gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-81052F6D-2943-41E7-94E4-4629800FC56D"
Content-Transfer-Encoding: 7bit
Message-Id: <4E48FD1B-FE92-43C4-A497-24DB13A8FC96@iki.fi>
X-Mailer: iPhone Mail (10B329)
From: Juho Vähä-Herttua <juhovh@iki.fi>
Date: Wed, 26 Jun 2013 00:53:45 +0300
To: "OMAR HASSAN (RIT Student)" <omh1835@rit.edu>
Cc: Paras Shah <Paras.Shah@riverbed.com>, "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] User Defined Key Pair
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/options/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: Tue, 25 Jun 2013 21:54:07 -0000

On 26.6.2013, at 0.12, "OMAR HASSAN (RIT Student)" <omh1835@rit.edu> wrote:
> Besides, even the very 1st time, how do you know that the user is communicating with Facebook for real to get the server’s current timestamp for example.
> 
> All values that the client received from the server will be hashed at the client, and sent back to the server encrypted with the session key, so the server can validate the hash to make sure that no one manipulate the values. This is done in the "finish" message.

I'm not sure you understand how the man-in-the-middle works here. You as a client send a ClientHello to the server, I as an attacker receive it and open a new TCP connection to the server and forward your ClientHello there. Then I get the server random nonce in ServerHello and forward it to you.

When you send your public key, I will replace it with my own public key instead. When the server sends the premaster key I will decrypt it with my private key and encrypt it (or some other premaster secret) again with yours. I will modify all Finished messages accordingly so that everyone keeps happy.

End result is that your "secure" session is actually with me, but all your data is coming from facebook and going to facebook. You would never know the difference. If you would open a "normal" TLS connection, trust the CA and send your public key there, this problem wouldn't exist. And Facebook still wouldn't know your private key.

I don't think this is just a problem with you not communicating your solution to others well enough, you also need to listen. We all want to get rid of CAs, and if it would be as easy as you propose, it most likely would've been done already.


Juho

v2.23.0 | Report a Bug | By Email