Nice work. Some comments after a quick read'n'grep of the code:
I think the authorities and auth_level should be removed from handshake.pike. Having the same variables in handshake.pike and context.pike is confusing and invites bugs.
I don't see where the certificates are used for verifiction. Is that done at all? The steps needed are, for both client and server verification:
1. Check that root of the certificate chain is trusted. First issuer should be the subject and issuer of a certificate in the authorites list (those are "self-signed", i.e. subject = issuer).
2. Check that the chain is valid, i.e. that subject of one certificate is the issuer of the next, and that certificates have the proper flags set (thus is unfortunately more hairy than it should. Peter Gutmanns x509 guide is required reading).
3. Dig out the public key from the certificates, and use that to verify the signature that the peer sends. The point is that we must ensure that the peer has access to the private key corresponding to the certificate.
4. On the client side, verify that the Common Name attribute of the server's certificate matches the hostname (this perhaps best left to Protocols.HTTPS, or other users of SSL, since it's https specific).
5. On the server side, match the distinguished name of the clients certificate against some database or rules about who should get access. Again, perhaps all the SSL module should do is to present the common name of the client and of the root issuer to the user of the application using SSL.
I tried to find the code doing 3. THere is some code under the case STATE_server_wait_for_verify, HANDSHAKE_certificate_verify, which seems to boil down to a call of rsa_verify via session->cipher_spec->verify. However, that seems broken, because it uses an rsa key stored in the context, which should be our *own* key, not the peer's.
I think the received certificate chain, as well issuer/subject and other information we dig out from it, should be saved in the session object.
/ Niels Möller (vässar rödpennan)
Previous text:
2004-01-14 23:21: Subject: Re: SSL part two
Well, I'll try to help out where possible, though I get nervous when fiddling with something someone has perhaps done for a specific reason. In the case of the sslfile problem, it's not at all clear to me why the code is what it is. It's entirely possible I'm missing something that's completely over my head.
As a show of my hopefully good intentions, I've fixed the context and handshake to look in the context for client certificate settings first. I've also added some convenience functions to Standards.PKCS.Certificates for making it easier to get the right value for the certificate authorities field in context.
Now it appears that the certificate is requested, and sent back to the server, which is a big step in the right direction.
Bill
On Wed, 14 Jan 2004, Johan Sundström (Achtung Liebe!) @ Pike (-) developers forum wrote:
I think that is an area of Pike that is somewhat lacking in caring maintenance, even though the Roxen people of course still tend to the parts they use themselves. IMO, it would be nice of you to improve and extend (and perhaps even document some :-) the API:s there, with extra credit for backwards compatibility.
/ Johan Sundström (Achtung Liebe!)
/ Brevbäraren