Provides a certificate for SSL client authentication on NSS sockets....

Provides a certificate for SSL client authentication on NSS sockets.
GUI is still missing, so certificates and private keys have to be
stored manually, p.e.:
$ pk12util -d sql:$HOME/.pki/nssdb -i PKCS12_file.p12
Adds --auto-ssl-client-auth command-line option to enable this feature.

Patch contributed by Jaime Soriano <jsorianopastor@gmail.com>;.
Original review URL: http://codereview.chromium.org/220009

R=wtc
BUG=16830
TEST=Try to connect to a web page that requires SSL authentication and
confirm that it connects if and only if a valid certificate is stored in
the ~/.pki/nssdb database.

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

[wtc, 2009-10-15 02:30:37]

Jamie,

Patch Set 1 is your latest patch, merged with the current
tip of the source tree.

I didn't realize we need to copy the CERTDistNames structure
and it's nontrivial to copy CERTDistNames.  I'll try to find
out what's wrong with how you copy it, but I'm inclined to
go back to your original method of getting the client certs
in ClientAuthHandler.

[wtc, 2009-10-15 17:36:20]

Jaime,

I fixed the copying of CERTDistNames.  You can look at
the delta between Patch Sets 1 and 2 to see what the
mistake was.  (You created two arenas, and you allocated
a single SECItem in the 'names' field as opposed to an
array of SECItems.)

I don't like our manual copying of CERTDistNames.  So
after I check this patch in, we should create a follow-up
patch to go back to the old method of looking up the
client certs in ClientAuthHandler.

I will look at why SSL_ReHandshake is necessary next.
I also found that your code doesn't work with sites
that require SSL client authentication.  I should be able
to fix that.

Is there any other issue in your patch that you want me
to look at?

[Jaime Soriano, 2009-10-15 18:27:26]

On 2009/10/15 17:36:20, wtc wrote:
> Jaime,
> 
> I fixed the copying of CERTDistNames.  You can look at
> the delta between Patch Sets 1 and 2 to see what the
> mistake was.  (You created two arenas, and you allocated
> a single SECItem in the 'names' field as opposed to an
> array of SECItems.)
>
Oh, yes, I see...

> I don't like our manual copying of CERTDistNames.  So
> after I check this patch in, we should create a follow-up
> patch to go back to the old method of looking up the
> client certs in ClientAuthHandler.
> 
I neither like the manual copy, are you going to check this in? or should we
wait and do it as I did in my third patch set?
Should I create a new issue for this changes?

> I will look at why SSL_ReHandshake is necessary next.
Ok.

> I also found that your code doesn't work with sites
> that require SSL client authentication.  I should be able
> to fix that.
> 
I use it daily to access to the private web sites of the company where I work
without any problem... In which cases it doesn't work?

> Is there any other issue in your patch that you want me
> to look at?
I don't think so, thanks a lot!

[wtc, 2009-10-15 21:57:14]

On 2009/10/15 18:27:26, Jaime Soriano wrote:
>
> I neither like the manual copy, are you going to check this in? or should we
> wait and do it as I did in my third patch set?
> Should I create a new issue for this changes?

In the interest of time, I've checked in your current patch
after cleaning it up.  Please create a new issue to go back
to the original method of constructing the client_certs_
vector in ClientAuthHandler.

Note: I will be out of town next Monday to Wednesday
(19-21 October).

Re: SSL_ReHandshake: I figured out why you needed to call
it.  We can accomplish that better by using SSL_InvalidateSession.
I added a comment before the SSL_InvalidateSession call to
explain why it's necessary.

> > I also found that your code doesn't work with sites
> > that require SSL client authentication.  I should be able
> > to fix that.
> > 
> I use it daily to access to the private web sites of the company where I work
> without any problem... In which cases it doesn't work?

Some sites request but don't require SSL client auth.  If you
don't send a client cert, the SSL handshake will still succeed,
but the server won't allow you to access the resource that
requires client authentication.

If a site requires SSL client auth and you don't send a client
cert, the server will send an SSL "alert" message such as
"handshake_failure" and fail the handshake.  When this happens,
SSL_ForceHandshake fails with the
SSL_ERROR_HANDSHAKE_FAILURE_ALERT error code.

Since your original code is used only when SSL_ForceHandshake
succeeds, it doesn't handle the SSL_ForceHandshake failure case.