Allow the SSL session cache on Win/Mac to be used even after a client cert key is removed

The current implementation of client authentication for Windows and Mac matches the NSS implementation, in that it continously checks that the private key is still accessible. The intent is that once the user removes the private key (such as by ejecting a smart card, if it's stored on one), then the existing SSL sessions will become invalidated. However, depending on the smart card middleware, this may involve non-trivial work being done every SSL record, and may be causing a performance regression for authentication.

The new behaviour is that any negotiated SSL connections remain valid, even after the smart card is ejected, and any established SSL sessions are not invalidated and may be reused. This matches the observed behaviours of IE and Safari. Smart card client auth on Linux is unaffected and will continue polling the smart card to determine if it's been ejected / the key has been deleted.

BUG=71928
TEST=none

Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=74716

[Ryan Sleevi, 2011-02-06 01:24:22]

PTAL. Would you prefer the Chromium patch in the directory is updated as part of
this CL or as part of a separate CL?

[wtc, 2011-02-06 03:02:31]

LGTM.  Thanks!  This is one of the cleanups I suggested
when I reviewed your platform client auth patch, but I forgot
about it.

I prefer you update the NSS patch as part of this patch, but
it's not necessary.

http://codereview.chromium.org/6413010/diff/1/net/third_party/nss/ssl/ssl3con.c
File net/third_party/nss/ssl/ssl3con.c (right):

http://codereview.chromium.org/6413010/diff/1/net/third_party/nss/ssl/ssl3con...
net/third_party/nss/ssl/ssl3con.c:2015: return PR_TRUE;
It would be nice to document the consequence of returning
PR_TRUE without checking.  You can just copy a concise summary
of the CL's description.

[PhistucK, 2011-02-06 06:54:54]

This sounds like trading security for performance. How is that acceptable?
Enterprises\laptop users are not going to like this.

[Ryan Sleevi, 2011-02-06 07:52:12]

On 2011/02/06 06:54:54, PhistucK wrote:
> This sounds like trading security for performance. How is that acceptable?
> Enterprises\laptop users are not going to like this.

Maybe my initial title was wrong/misleading, as you still need the key to do the
actual client auth handshake. It just doesn't need to be continuously available
for the duration of the handshake. I updated the title to reflect that.

Relevant conversation is on the related bug, in
http://codereview.chromium.org/2828002/show , and in a similar place at
https://bugzilla.mozilla.org/show_bug.cgi?id=167756

This CL matches Apple's behaviour, but diverges from NSS's implemented behaviour
and MS's documented behaviour. I do agree, PhistucK, that there are going to be
people who are concerned that a session/connection should be invalidated the
moment a user removes their card. At the same time, other users may not share
that concern, and so I deferred to wtc (as both OWNER and as someone well versed
in the target area) to make the call about who gets to win by default. The
related bug is pretty annoying, and though it's dependent on the smart card and
middleware, it's an unfortunate regression.

The above CL makes SSL client certificates behave with the same general
principals of session cookies - they remain active for the duration of the
browsing session, and you're continuously authenticated without having to
provide your credentials for every request (other than the cookie/SSL session
ID). Not ideal, but not unprecedented in terms of web or security. This use case
matches Wan-Teh's analogy of having a key that unlocks your door, but you don't
have to keep your key on you in your house at all time.

The counter analogy is that a smart card is like an ID badge that must be worn
at all times (and in fact, for FIPS-201 US federal agencies and DoD, their smart
card IS their ID badge that must be worn at all times). Under that scenario, if
your card is removed/you don't have a badge on you, you should be escorted off
the premises / things should be locked down.

I suspect that, in time, this decision will get revisited as solutions are
explored for the user who really wants super-s3kr3t-security.

[Ryan Sleevi, 2011-02-06 08:26:12]

On 2011/02/06 06:54:54, PhistucK wrote:
> This sounds like trading security for performance. How is that acceptable?
> Enterprises\laptop users are not going to like this.

I should also mention that it's a case where MS's documentation may be
misleading (see http://crrev.com/73919 - MSDN says AT_SIGNATURE is never used,
but empirically it is). On Windows though,
http://technet.microsoft.com/en-us/library/cc938350.aspx is available as one
possible means of mitigating.

IE at least, with one particular non-minidriver CSP I have handy, I can remove
the card completely and the SSL session cache remains valid. If I clear the
cache on the server, then every subsequent attempt to use that server fails
until I restart IE. This applies even in the most recent versions, even on 7. So
this change will see us behaving IE-like in that respect (whether or not that is
a good thing is a separate discussion)

So far, IE has been "good enough" for the enterprise customers, so I suspect
that us matching the behaviour won't be the end of the world. There is an option
in IE to clear the SSL session state (Tools -> Internet Options -> Content ->
Clear SSL State), which resets all identities and clears the SSL session cache.
So that is also something that we can/should look into.

FWIW, I did implement some improvements over IE's behaviour in
http://crrev.com/73914 , so that you can actually re-auth with the server if you
were to re-insert your card after auth fails.

I was curious if you could explain what you meant by the laptop user scenario
though.

[PhistucK, 2011-02-06 09:17:29]

Thank you for taking the time to explain.
It sounds like an acceptable compromise if this is sufficient for enterprise
users who are used to Internet Explorer like behavior anyway (though still not
sufficiently secure for sensitive material, of course, just like Internet
Explorer).

> I was curious if you could explain what you meant by the laptop user scenario
> though.

Enterprise users can use desktop computers and\or go out with their laptops, but
users (on their own) with their own sensitive materials can also use their
laptops. This is probably the same thing, but a laptop is more likely to be
forgotten open in the middle of a hall than a desktop computer (;)), which is
why it is more important for laptops (in my opinion).

[wtc, 2011-02-06 15:53:10]

Even with the employee ID badge/ATM card metaphor, it
would be sufficient if the removal of the smart card
locks the computer screen automatically.  If the screen
is locked, individual applications do not need to kill
the SSL connections authenticated with the smart card.

The employee ID badge/ATM card metaphor also makes it
difficult to use multiple computers simultaneously.

[wtc, 2011-02-06 16:29:44]

http://codereview.chromium.org/6413010/diff/1/net/third_party/nss/ssl/ssl3con.c
File net/third_party/nss/ssl/ssl3con.c (right):

http://codereview.chromium.org/6413010/diff/1/net/third_party/nss/ssl/ssl3con...
net/third_party/nss/ssl/ssl3con.c:2015: return PR_TRUE;
rsleevi: thank you for looking up the NSS bug.  It reminded
me that NSS may have encountered and solved the same
performance problem, by polling a smart card no more often
than some fixed time interval.

If you're interested in implementing that solution, you may
keep the clPlatformAuthValid code, and just disable it here
in this function.

NSS has a convenient place (lib/pk11wrap layer) to implement
the smart card polling delay logic that can be shared by all
SSL connections.  Our platform client auth code doesn't have
such a central place yet.

[wtc, 2011-02-06 16:34:13]

http://codereview.chromium.org/6413010/diff/1/net/third_party/nss/ssl/ssl3con.c
File net/third_party/nss/ssl/ssl3con.c (right):

http://codereview.chromium.org/6413010/diff/1/net/third_party/nss/ssl/ssl3con...
net/third_party/nss/ssl/ssl3con.c:2029: !PK11_IsPresent(slot) ||
What I meant by the lib/pk11wrap layer of NSS is the
PK11_ functions, such as this PK11_IsPresent(slot) call
here.

It is possible that implementing the same solution for
platform client auth will change the code significantly,
and we might as will just remove the current
clPlatformAuthValid now.

[commit-bot: I haz the power, 2011-02-12 00:26:57]

Try job status for 6413010-1 on win: 2

[commit-bot: I haz the power, 2011-02-12 01:52:17]

Change committed as 74716