diff options
| author | rsleevi@chromium.org <rsleevi@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-02-12 01:52:12 +0000 |
|---|---|---|
| committer | rsleevi@chromium.org <rsleevi@chromium.org@0039d316-1c4b-4281-b951-d872f2087c98> | 2011-02-12 01:52:12 +0000 |
| commit | d9b545cf38a8fb8942e2559623d4b8032b33c954 (patch) | |
| tree | c1cb88fcd831575f7dce32e35bb8111ac9dbefc8 /net/socket/ssl_client_socket_nss.h | |
| parent | a15fe89d6cb5e56869ac4f0012133abaca7f06d8 (diff) | |
| download | chromium_src-d9b545cf38a8fb8942e2559623d4b8032b33c954.zip chromium_src-d9b545cf38a8fb8942e2559623d4b8032b33c954.tar.gz chromium_src-d9b545cf38a8fb8942e2559623d4b8032b33c954.tar.bz2 | |
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
Review URL: http://codereview.chromium.org/6413010
git-svn-id: svn://svn.chromium.org/chrome/trunk/src@74716 0039d316-1c4b-4281-b951-d872f2087c98
Diffstat (limited to 'net/socket/ssl_client_socket_nss.h')
0 files changed, 0 insertions, 0 deletions