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

[Kyle Hamilton <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>