Re: [TLS] HTTPS client-certificate-authentication in browsers
Stefan Winter <stefan.winter@restena.lu> Thu, 28 July 2011 09:19 UTC
Return-Path: <stefan.winter@restena.lu>
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 9D4A621F8C79 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 02:19:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.451
X-Spam-Level:
X-Spam-Status: No, score=-0.451 tagged_above=-999 required=5 tests=[AWL=-1.707, BAYES_00=-2.599, FB_MAKE_MONEY=1.555, GB_ABOUTYOU=0.5, J_CHICKENPOX_43=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_73=0.6]
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 A3iH227MkUu9 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 02:19:30 -0700 (PDT)
Received: from smtprelay.restena.lu (smtprelay.restena.lu [IPv6:2001:a18:1::62]) by ietfa.amsl.com (Postfix) with ESMTP id 8B7A521F8C71 for <tls@ietf.org>; Thu, 28 Jul 2011 02:19:29 -0700 (PDT)
Received: from smtprelay.restena.lu (localhost [127.0.0.1]) by smtprelay.restena.lu (Postfix) with ESMTP id 4BD19109FC for <tls@ietf.org>; Thu, 28 Jul 2011 11:19:28 +0200 (CEST)
Received: from [IPv6:2001:a18:1:8::155] (unknown [IPv6:2001:a18:1:8::155]) by smtprelay.restena.lu (Postfix) with ESMTPS id 2EEFF107C2 for <tls@ietf.org>; Thu, 28 Jul 2011 11:19:28 +0200 (CEST)
Message-ID: <4E31299F.6060400@restena.lu>
Date: Thu, 28 Jul 2011 11:19:27 +0200
From: Stefan Winter <stefan.winter@restena.lu>
User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110624 Thunderbird/5.0
MIME-Version: 1.0
To: tls@ietf.org
References: <mailman.1209.1311842548.23921.tls@ietf.org>
In-Reply-To: <mailman.1209.1311842548.23921.tls@ietf.org>
X-Enigmail-Version: 1.2
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig8B113A623DF3CA2908555D93"
X-Virus-Scanned: ClamAV
Subject: Re: [TLS] HTTPS client-certificate-authentication in browsers
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: Thu, 28 Jul 2011 09:19:30 -0000
Hi, >>> Lots of banks wants to use CCA for their users. >> > >> > That is a non sequitur. >> > >> > Banks (here in Germany) have abandoned tradtional TANs based on >> > the unconditional presumption that client PCs are infested with >> > malware, and most banks in Germany are currently replacing indexed TANs (iTAN) >> > presumably based on the perception that malware on clients (trojans/phishing) >> > has caught up with iTAN procedure complexity. >> > >> > At this point, with the presumption that all client PCs are >> > thoroughly infested with malware, going for a Single Sign-On >> > mechanism would be completely braindead and irresponsible. > So using client certificates for authentication is such a bad idea that > there is no point in looking into issues on how to make it better? > > How is the German e-card supposed work then? Just trolling around on this list every now and then, but can't resist to comment because I got my new eID card and also HBCI access recently. eID: The electronic identity card contains lots of personal details about you in some credential storage. It must be put into a whitelisted, EAL-whatever certified hardware device, connected via USB. There is one well-defined application on your computer which can ask the reader to retrieve a *subset* of the personal information stored. Other applications on the computer talk to this one application via an API. Your card reader will present the name of the application which wants the data, the pieces of data it wants to have from your card, and will ask for your authorisation to reveal that personal data. That is done via display+PIN directly on the card reader; no secret information ever leaks the card reader unless authorized directly on the device by the user. [1] This exhibits a property of the system which plain presentation of a X.509 certs won't allow: send only a subset of the stored information. It was refreshing to see this in action when I got my reader last week: my car insurance website signalled they need my real name, birthdate and birthplace to log me in to manage my insurance contract - not the rest of "me" that the card stores as well. Did that, logged into their website, no need to even create a username/password combo. Note that I didn't use the term "client certificate" at all - the system does involve PKI, but it's invisible to the user; all he has is a hardware token and a PIN. Sure: you need the card reader. Joe Sixpack can manage to go to a shop and put money on the shelf to get it, I assume - he does that same thing when buying a TV. Joe doesn't even have to know or care about how to get a "certificate" - he just gets all the stuff piggybacked on his usual plastic ID card. Banking: These days, TAN lists are going away. Alternatively, several approaches come into use: a) cell phone transaction numbers: enter transaction details on website, website generates a TAN for this very transaction, sends it along with the input it received from you to your (pre-registered) cell phone, you enter the number from the cell phone into the website. - A second, independent channel makes sure that even if the PC's comms channel is compromised, harm is prevented. b) offline generated transaction numbers. You get a hardware device, branded to your bank account (provisioned secrets). Its only interface to the outside world is a black&white camera to read a bar code; and a display to show a resulting TAN. Workflow is: you enter your transaction details on the web site, they generate $SOMEDATA from it (which includes the transaction details). $SOMEDATA is signalled to the hardware device via barcode scan, which uses it to generate a TAN based on the pre-provisioned secrets and $SOMEDATA. Bank does the same computation, TANs must match. Again, a second channel comes to the rescue even if the PC is compromised. c) HBCI - Home Banking Computer Interface. There is no browser at all(!). An application uses the HBCI API to talk to bank servers. Client authenticates with a smart card to be put into a card reader. All crypto again happens on the card reader. Joe sixpack gets the smart card+PIN by checking a box on his bank acocunt application and doesn't need to know anything more. None of these use Client Certificates in a browser. All of them survive if the PC is malware-infested. But yes, there are still attacks on these - they are not the cure-all. Greetings, Stefan Winter [1] There are also readers without a keyboard. If you use these, too bad for you, because then your infested PC will log your PIN and so on. Because of that, the system got quite some beating when introduced. -- Stefan WINTER Ingenieur de Recherche Fondation RESTENA - Réseau Téléinformatique de l'Education Nationale et de la Recherche 6, rue Richard Coudenhove-Kalergi L-1359 Luxembourg Tel: +352 424409 1 Fax: +352 422473
- [TLS] HTTPS client-certificate-authentication in … Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Peter Saint-Andre
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Paul Wouters
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Daniel Kahn Gillmor
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Matt McCutchen
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Stefan Winter
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Anders Rundgren
- Re: [TLS] HTTPS client-certificate-authentication… Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] EU cards Anders Rundgren
- Re: [TLS] EU cards Henry Story
- Re: [TLS] EU cards Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex
- Re: [TLS] EU cards Anders Rundgren
- Re: [TLS] EU cards Peter Gutmann
- Re: [TLS] EU cards Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] EU cards Anders Rundgren
- Re: [TLS] EU cards Henry Story
- Re: [TLS] EU cards Nikos Mavrogiannopoulos
- Re: [TLS] EU cards Yoav Nir
- Re: [TLS] EU cards Blumenthal, Uri - 0668 - MITLL
- Re: [TLS] HTTPS client-certificate-authentication… Wan-Teh Chang
- Re: [TLS] EU cards Henry Story
- Re: [TLS] HTTPS client-certificate-authentication… t.petch
- Re: [TLS] HTTPS client-certificate-authentication… Peter Gutmann
- Re: [TLS] HTTPS client-certificate-authentication… Martin Rex