On 13:45 Tue 26 May , Helga Velroyen wrote: > On Tue, 26 May 2015 at 15:34 Apollon Oikonomopoulos > <[email protected]> > wrote: > > i) Implement a proper CA, have all client certificates signed by > > that > > CA and use that same CA for client authentication, together with the > > fingerprint whitelist. Signing the certificate would make sure that > > the Subject DN sent by the server would always match the Issuer DN > > of client.pem, as per RFC 5280. This is obviously a high development > > cost solution, and partly redundant because we don't need to rely on > > a CA to perform authentication. > > > > ii) Collect *all node certificates* and use all of them as "trusted > > CAs". As discussed above, when we set server.pem as the "client CA" > > (HttpBase._CreateSocket), we do so exploiting the fact that it > > shares the same CN with all clients. Instead of collecting just the > > fingerprints in ssconf_master_candidate_certificates, we can > > collect the certificates themselves and load them all as trusted > > CAs using Context.set_client_ca_list()[1]. This will make sure that > > the client will send their own certificates regardless of how the > > Subject DN is encoded, and will also allow things like setting a > > different CN for each node. This can work in parallel with the > > fingerprint whitelist, but maybe later we can completely drop the > > latter and rely on normal SSL verification rules (not sure about > > the security implications, it's just a suggestion). > > > > [1] > > https://pythonhosted.org/pyOpenSSL/api/ssl.html#OpenSSL.SSL.Context.set_client_ca_list > > > > I think solution ii) above is the easiest and most straight-forward to > > implement. It is also more correct from an SSL standpoint than what we > > have today. Helga, any opinions on this? > > > > Besides i) and ii), there is another option, if I understand correctly: > iii) When creating client.pem, read the server.pem first enforce the same > encoding on client.pem that server.pem has.
I thought of that too, but unfortunately there seem to be no knobs to force this, unless you resort to calling `openssl ca'. PyOpenSSL doesn't seem to use openssl.cnf and I'm not sure it has an interface to force the string encoding. > > I think we should do iii) first as a quick fix, but do either i) or ii) to > solve the problem properly. > > I personally would love to implement i) as it seems to be the proper way to > use SSL, but my suggestion for that did not receive much enthusiasm for > getting resources (aka time) to implement it when I proposed that in the > first place. > > Option ii) sounds most feasible wrt to time an resources (although also > here, it would take a while if I am supposed to implement it myself). I > think I even had that idea in mind when I proposed the node security doc, > but realized that it would vastly complicate renewing server.pem as all > client.pem would need to be renewed or at least resigned as well. With ii) you don't need to reissue client.pem's. They will still be self-signed, it's just that you won't use server.pem as a client CA (which it actually isn't) on the noded anymore, and you will use all client.pems as CAs (which they are for that matter). For that to work, you just need to store the actual MC certificates in ssconf, rather than only the fingerprints. Nothing else should need to be changed.
