On Tue, 26 May 2015 at 16:10 Helga Velroyen <[email protected]> wrote:
> On Tue, 26 May 2015 at 16:03 Apollon Oikonomopoulos <[email protected]> > wrote: > >> 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. >> > > Right, however, I don't think this collection of all client.pems is easy > to implement. The current distribution of the ssconf file is done using the > config's mechanism (thus it was handy to implement), while for collecting > the entire client.pems we would need to build more infrastructure for it. > However, I don't think it is impossible and it is still significantly less > work than option i) would be. > Another advantage that I see with both i) and ii) is that we could actually properly set the hostname in the client.pems and enable hostname verification. > > Cheers, > Helga > >
