Re: [TLS] HTTPS client-certificate-authentication in browsers

Martin Rex <mrex@sap.com> Fri, 29 July 2011 00:06 UTC

Return-Path: <mrex@sap.com>
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 E7EB611E8133 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 17:06:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.63
X-Spam-Level:
X-Spam-Status: No, score=-9.63 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_41=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3ZJflgIq0K3 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 17:06:15 -0700 (PDT)
Received: from smtpde02.sap-ag.de (smtpde02.sap-ag.de [155.56.68.140]) by ietfa.amsl.com (Postfix) with ESMTP id B136411E809C for <tls@ietf.org>; Thu, 28 Jul 2011 17:06:14 -0700 (PDT)
Received: from mail.sap.corp by smtpde02.sap-ag.de (26) with ESMTP id p6T06CaV026884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Fri, 29 Jul 2011 02:06:12 +0200 (MEST)
From: Martin Rex <mrex@sap.com>
Message-Id: <201107290006.p6T06BD0012180@fs4113.wdf.sap.corp>
To: anders.rundgren@telia.com (Anders Rundgren)
Date: Fri, 29 Jul 2011 02:06:11 +0200 (MEST)
In-Reply-To: <4E313B9C.3040104@telia.com> from "Anders Rundgren" at Jul 28, 11 12:36:12 pm
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-SAP: out
Cc: stefan.winter@restena.lu, tls@ietf.org
Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.12
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/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: Fri, 29 Jul 2011 00:06:16 -0000

Anders,

Anders Rundgren wrote:
> 
> These two guys says that having a key in the PC is braindead,
> particularly if you use it from a browser.

I'm sorry for loosing my temper.  You don't deserve this.

I don't know what particular issue banks have with their
weird threat model here in Germany, I'm unable to find an even
remotely reasonable explanation why so many of them are suddenly
violently determined to completely kill any of their existing
paper-based TANs, including iTANs that they introduced just
a few years ago, aggressively touted as something that you need.

I do not want having to carry around any of their fancy hardware tokens
with keypad and display (and personally bear the risk for loosing or
breaking it).  Nor do I want having to carry around a mobile phone,
let alone buy and carry a smartphone for similar reasons.


> 
> Based on 15 years of experience of s.c. "security experts" we
> can safely drop this thread; it won't go anywhere.

TLS when used by web browsers for HTTPS is a transport protocol
with non-persistent connections, which means that the only sensible
operational model for TLS client certs in browsers is for Single
Sign-On, everthing else is either a security problem or a
usability problem or both.

But attributing intent with a web browsers HTTPS CCA authentication or
authorizing transactions with it seems like a very bad idea, because
of the numerous problems in the entire architecture.

Browsers do _not_ enforce that elements on a page all come from
the exact same server when HTTPS is used, and MSIE8 and Safari4Windows
on Windows 7 do not even tell you which server is asking for a client
certificate when showing you the client cert selection box.

I assume that active content could even perform request "dark" in
the background while the pages that you actually see do not look
suspicious at all.

13 years ago Online banking regularly worked with secure browser
setting (i.e. active content disabled), pure-html and very quick
response times.  Today, most online banking requires active
content enabled and is dead slow for no reasonable purpose.


> 
> This attitude was OK before we entered the "Google- and Apple-age".
> It's an entirely different ball-game now!

Smart phones are already attractive targets for theft even with no
additional digital gems added by the end user.  Significantly
further increasing the attractiveness of that target for both,
digital theft through malware and physical theft of the smartphone,
does not seem overly sensible to me.

>From what I read in the german computer magazine,
  http://www.heise.de/artikel-archiv/ct/2011/15/154_kiosk

all existing iPhones and iPad1s seem to have the vulnerability
in the Boot-Rom (i.e. Hardware, no possibility to fix by software update)
that might enable thieves to bypass many if not all of the assumed
"protections" and retrieve your private data.


-Martin