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

Kyle Hamilton <> Mon, 29 March 2010 19:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A73713A6907 for <>; Mon, 29 Mar 2010 12:36:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Vfe3Q1osaKKj for <>; Mon, 29 Mar 2010 12:36:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 6D00B3A67EA for <>; Mon, 29 Mar 2010 12:36:27 -0700 (PDT)
Received: by pwi10 with SMTP id 10so7124217pwi.31 for <>; Mon, 29 Mar 2010 12:36:53 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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 with HTTP; Mon, 29 Mar 2010 12:36:52 -0700 (PDT)
In-Reply-To: <>
References: <> <>
Date: Mon, 29 Mar 2010 12:36:52 -0700
Received: by with SMTP id q10mr374371rvl.253.1269891412996; Mon, 29 Mar 2010 12:36:52 -0700 (PDT)
Message-ID: <>
From: Kyle Hamilton <>
To: mrex <>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: tls <>
Subject: Re: [TLS] Asking the browser for a different certificate
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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 <> 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