Re: [TLS] HTTPS client-certificate-authentication in browsers
Anders Rundgren <anders.rundgren@telia.com> Thu, 28 July 2011 09:54 UTC
Return-Path: <anders.rundgren@telia.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 7BB4821F8C66 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 02:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.843
X-Spam-Level:
X-Spam-Status: No, score=-1.843 tagged_above=-999 required=5 tests=[AWL=-1.599, BAYES_00=-2.599, FB_MAKE_MONEY=1.555, J_CHICKENPOX_43=0.6, J_CHICKENPOX_55=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_LOW=-1]
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 23+6IhZ6H5D6 for <tls@ietfa.amsl.com>; Thu, 28 Jul 2011 02:54:03 -0700 (PDT)
Received: from smtp-out12.han.skanova.net (smtp-out12.han.skanova.net [195.67.226.212]) by ietfa.amsl.com (Postfix) with ESMTP id 8952121F8C63 for <tls@ietf.org>; Thu, 28 Jul 2011 02:54:03 -0700 (PDT)
Received: from [192.168.3.119] (193.12.106.2) by smtp-out12.han.skanova.net (8.5.133) (authenticated as u36408181) id 4DF89E7F0080B529; Thu, 28 Jul 2011 11:54:01 +0200
Message-ID: <4E3131AA.5010703@telia.com>
Date: Thu, 28 Jul 2011 11:53:46 +0200
From: Anders Rundgren <anders.rundgren@telia.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: Stefan Winter <stefan.winter@restena.lu>
References: <mailman.1209.1311842548.23921.tls@ietf.org> <4E31299F.6060400@restena.lu>
In-Reply-To: <4E31299F.6060400@restena.lu>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Cc: 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
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:54:04 -0000
http://www.hbci-kernel.de/fints.htm I'm happy that none the banks I have talked have any interests in such crap. The usage level of the German eID is hardly measurable either. /A On 2011-07-28 11:19, Stefan Winter wrote: > 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. > > > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls
- [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