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

Anders Rundgren <anders.rundgren@telia.com> Wed, 27 July 2011 08:19 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 11C0421F8B6E for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 01:19:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.284
X-Spam-Level:
X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, SARE_MILLIONSOF=0.315]
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 Y3wu4ugi+eso for <tls@ietfa.amsl.com>; Wed, 27 Jul 2011 01:19:17 -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 3170A21F852C for <tls@ietf.org>; Wed, 27 Jul 2011 01:19:17 -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 4DF89E7F007E1C9B; Wed, 27 Jul 2011 10:19:12 +0200
Message-ID: <4E2FC9F3.10205@telia.com>
Date: Wed, 27 Jul 2011 10:18:59 +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: mrex@sap.com
References: <201107262051.p6QKpxAd017550@fs4113.wdf.sap.corp>
In-Reply-To: <201107262051.p6QKpxAd017550@fs4113.wdf.sap.corp>
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: Wed, 27 Jul 2011 08:19:18 -0000

Martin,

AFAICT you indirectly say that the de-facto standard for maintaining
(note, not creating) secure sessions on the web, i.e. server-side
HTTPS + session cookies is inferior.

The fact is that exactly $0 has been spent by the people building and
defining the TLS/HTTPS platforms on *researching* the issues I mentioned,
while *hundreds of millions of dollars* has been spent on *code* that
merges client-side PKI and the web in other ways than using HTTPS CCA.

FWIW, InformationCards (now close to an OASIS standard), do not use
HTTPS CCA for authentication to the IDP, but server-side HTTPS and
client-side signed request data.

Anders

On 2011-07-26 22:51, Martin Rex wrote:
> Anders Rundgren wrote:
>>
>> You have a rather elitist way of discussing things.
>>
>> It actually quite hard writing an HTTPS CCA based web app that
>> has similar login and session characteristics as one using password
>> authentication.
> 
> But that is a clear abuse of the TLS client certificate technology
> and _not_ supposed to be usable in this fashion.
>  
> 
>>
>> In your opinion this is an advantage; in my world it represents a
>> hurdle for adoption.
> 
> If you are _not_ looking for seamless single Sign-On, then
> TLS client certs are not the right tool for what you want to
> accomplish (square peg, round hole).
> 
> 
>>
>> Anyway, banks are investing huge in app-level PKI authentication
>> so there is apparently a huge ignorant crow out there.
> 
> But if the "frontend" they are using something as security-broken
> as a plain web browser, then the technology they would need
> is a "frontend signing" browser plugin to produce PKCS#7/CMS signed data
> over well-definied application protocol units.
> 
> 
>>
>> The there are some really interesting differences in path building
>> (which of course is NOT specified at all by TLS) that for example
>> have forced people importing immediate CAs to PC before being able
>> to login using a smart card.
> 
> What particular problem are you facing?
> 
> 
> The TLS protocol is _very_ clear that a Certificate message must
> contain a FULL path, omitting _at_most_ the self-signed certificate
> at the end.  There are several TLS implementations out there with
> significant brokeness with respect to the Certificate handshke
> message (e.g. OpenSSL) which will omit more than just the
> self-signed certificate at the end of the certification path,
> send certificates out-of-order and even include arbitrary
> non-path certificates.  Things that could be trivially checked
> and reported as configuration errors on the server side upfront,
> instead of dumping garbage on communication peers in clear
> violation of the specification.
> 
> 
> -Martin
>