Re: [TLS] Asking the browser for a different certificate

Kyle Hamilton <aerowolf@gmail.com> Mon, 29 March 2010 19:36 UTC

Return-Path: <aerowolf@gmail.com>
X-Original-To: tls@core3.amsl.com
Delivered-To: tls@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A73713A6907 for <tls@core3.amsl.com>; Mon, 29 Mar 2010 12:36:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.131
X-Spam-Level: *
X-Spam-Status: No, score=1.131 tagged_above=-999 required=5 tests=[BAYES_50=0.001, DNS_FROM_OPENWHOIS=1.13]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vfe3Q1osaKKj for <tls@core3.amsl.com>; Mon, 29 Mar 2010 12:36:27 -0700 (PDT)
Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by core3.amsl.com (Postfix) with ESMTP id 6D00B3A67EA for <tls@ietf.org>; Mon, 29 Mar 2010 12:36:27 -0700 (PDT)
Received: by pwi10 with SMTP id 10so7124217pwi.31 for <tls@ietf.org>; Mon, 29 Mar 2010 12:36:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:received:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=TXi4JwgQKkLMgFniF8vJoNPB84BY2jMwdryPtVCVxH8=; b=svoDX3FalOqYs6FJ/h66hi25JG3F9J9RSDNjYBQ25sHZTIepxyGbsNW4lyKkmDMily dvDmWUs+R5N4aV8WaMFo3E2oPfB3AQfreHPJBiDFI1V/zcDnyR3mEHJiG8oMwKkL+GWI pSDZPLE/75v2+EQqIYGUQYUuV7Nk9frhb16D4=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=BopeFpvfU2egjxvKIkWLsu/vJE4yMrPyTK//1/zmRZqTYgBCqMj8ejM6vZ6z98gKV9 6nRMrwnt4w4kkvuvu0Pe5ypbtQgEdR+dd0Rin0OWf5b7alD1UJYbpHjMbVE7KChll1Is bi3jMoi3Yt1mBp5eCe+5W+ClJWJGwRUCeJJMM=
MIME-Version: 1.0
Received: by 10.231.167.3 with HTTP; Mon, 29 Mar 2010 12:36:52 -0700 (PDT)
In-Reply-To: <201003291745.o2THjKgr017986@fs4113.wdf.sap.corp>
References: <4BAE396B.9090104@extendedsubset.com> <201003291745.o2THjKgr017986@fs4113.wdf.sap.corp>
Date: Mon, 29 Mar 2010 12:36:52 -0700
Received: by 10.141.88.10 with SMTP id q10mr374371rvl.253.1269891412996; Mon, 29 Mar 2010 12:36:52 -0700 (PDT)
Message-ID: <6b9359641003291236t4e7bd0c6ycc5c5a435f38f3cf@mail.gmail.com>
From: Kyle Hamilton <aerowolf@gmail.com>
To: mrex <mrex@sap.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: tls <tls@ietf.org>
Subject: Re: [TLS] Asking the browser for a different certificate
X-BeenThere: tls@ietf.org
X-Mailman-Version: 2.1.9
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/listinfo/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: Mon, 29 Mar 2010 19:36:28 -0000

I thought this was what the ADH ciphers were supposed to handle:
create a private channel, and then authenticate each end of that
channel inside the protection of the ciphered channel.

The "public WiFi" attack is much less far-fetched than you might
think.  10 years ago, it was preposterous -- nobody provided public
network links except libraries.  Now, though, you have airports that
offer free wifi.  Mineta San Jose International Airport provides a
link to an ipsec driver that will allow you to tunnel your wireless
packets via ipsec to their router; this suggests that they take
information-disclosure security very seriously.  Much more seriously
than you seem to be.

It's not just airports, though.  Between Santa Cruz and San Jose,
there's a fleet of buses operated by Amtrak that have wifi on board.

Information-disclosure vulnerabilities are things that I'd like to see
mitigated as much as possible.  Yes, I know it's impossible to know
that you're talking to the entity that you think you are, without
authenticating -- and it's impossible to authenticate without
providing some uniquely-identifying information.  However, limiting
that disclosure of information to one endpoint, most likely not on the
same subnet you are, mitigates a LOT of problems with someone near you
identifying you.

(Of course, requiring the client to identify itself before proceeding
with a handshake... that's something I wish that TLS provided for.  I
find it odd that ipsec provides for it -- but evidently computer
credentials for ipsec are supplicant-based, while user credentials for
TLS are applicant-based.)

-Kyle H

On Mon, Mar 29, 2010 at 10:45 AM, Martin Rex <mrex@sap.com> wrote:
> Marsh Ray wrote:
>>
>> On 3/26/2010 8:14 PM, Martin Rex wrote:
>> >
>> > Would the browser be able to
>> > tell the server in a ClientHelloExtension "Don't bother sending
>> > me a CertificateRequest, because I don't have one", then
>> > the server could skip the CertificateRequest message if the
>> > application/configuration allows the handshake to complete without
>> > client certificate.
>>
>> That would be a significant information leak.
>>
>> Consider an attacker passively sniffing public wifi in a coffee shop
>> near a targeted organization. Now he sees who has his smart card in the
>> reader and activated.
>
>
> To me this sounds extremely farfetched.
>
> The ClientHello also "leaks" the maximum protocol_version that your
> client supports, the cipher_suites and compression algs your client
> is willing to use.
>
> The reason why a client may be sending that information may be manyfold,
> not necessarily a presence of a Smartcard.  A client could implement
> a caching of a users decision to present a client cert, e.g. on a
> per-server basis, or for a specific amount of time (for the next X hours).
>
> For those users that use SmartCards enabled for TLS client cert
> authentication, you will see their entire certificate flying by
> in the clear in the regular TLS handshake when they connect
> to the TLS server for which they plugged their SmartCard in the
> first place.
>
> And would you make your client include a "certificate URL extension"
> even when the client does not have a client certificate.  Well, maybe
> -- if you are the CIA and ordering your constant daily batch of pizzas.  :)
>
> Maybe you should not use any secure authentication protocols like
> Kerberos or TLS if you want to entirely hide that fact, that you possess
> secure client credentials.
>
>
> -Martin
> _______________________________________________
> TLS mailing list
> TLS@ietf.org
> https://www.ietf.org/mailman/listinfo/tls
>