A follow-up of r64178....

A follow-up of r64178.

Check for TLS 1.1 and TLS 1.2 (not yet supported)
version numbers to be future-proof.

Avoid a null pointer dereference when SSL client
authentication is used with SSL 2.0.  This will
be removed when we remove SSL 2.0 support.

Define the SSL_CONNECTION_VERSION_xxx enum constants
separately so we can assert their values are in range
at compile time.

R=eroman
BUG=53659
TEST=none

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

[wtc, 2010-10-29 17:49:50]

eroman: please review this CL.

I annotated two places to provide background info for you.
Please ask me if it's still not clear.

http://codereview.chromium.org/4211006/diff/1/3
File net/socket/ssl_client_socket_nss.cc (right):

http://codereview.chromium.org/4211006/diff/1/3#newcode1108
net/socket/ssl_client_socket_nss.cc:1108: // doesn't support them yet), so we
use 0x0302 and 0x0303 directly.
Here are the SSL version macros defined by NSS:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/sslp...

TLS 1.0 = SSL 3.1
TLS 1.1 = SSL 3.2
TLS 1.2 = SSL 3.3

I know this is confusing :-)

http://codereview.chromium.org/4211006/diff/1/3#newcode1657
net/socket/ssl_client_socket_nss.cc:1657: // trying to make this work, as we
plan to remove SSL 2.0 support soon.
When SSL 2.0 is used, NSS calls this function here:
http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/security/nss/lib/ssl/sslc...

Note that NSS passes NULL as the third argument (ca_names)
to this function.  This is an inconsistency of NSS between
its SSL 2.0 and SSL 3.0 code.  (In SSL 3.0, NSS passes a
non-NULL ca_names with ca_names->nnames=0 under the same
condition.)

[eroman, 2010-10-30 03:35:31]

lgtm

[wtc, 2010-11-01 18:25:17]

eroman: please review Patch Set 2.

In keeping with the recent decision that SSLInfo should not be
used for non-SSL connections, I removed SSL_CONNECTION_VERSION_NONE.