 |
 |
OK, I will give a go on this. Here is the idea based on hostAPD (thank you Oliver for that crucial pointer) which we can freely use as it's under a BSD license as opposed to other software packages. It also provides an idea on how to simplify the whole refresh process.
From my understanding, the SSL_CTX object is associated with one X509_store that holds the CA certs and CRLS. Typically, there is one such object and it is used with all new connections. During connection processing the information in the X509_store is used to verify the incoming cert. Because, there is one store, if you want to refresh that store you need to lock everything down until that happens; a rather brutal affair. This is why LCMAPS decided to have 64 contexts so only 1/64 of possible connections are blocked when the store has to get refreshed. I think this overly complex and based on what I see in hostAPD there is a much easier way of doing this.
Since in XRootD we have centralized all the TLS handling; so, we have the ability to maintain a shadow context. Everyone who needs to setup a connection asks the central context object for the SSL_CTX. We can hand that out and maintain a reference count to it. When the connection is closed, that context has to be returned and we decrease the reference count. So, we know when it can be deleted. If we need to refresh the CRL’s we do so on the shadow SSL_CTX. Once we set that up the shadow SSL_CTX replaces the one we will be giving out and we decrease the reference count to the old one as we no longer need it. It will get deleted when all uses of it are gone. This allows us to always give out an SSL_CTX object with a current X509_store.
So, essentially we are doing rolling refreshes and always have an SSL_CTX object that is current for new incoming connections. That way we don’t need to block any threads due to a CRL refresh. Does all of this sound reasonable to everyone?
This is rather trivial to do in R5 but in R4 we don’t have that framework. I think I can do a minimal implementation that would work for the R4 series so I don’t waste time doing it all twice over. Mind you, the only person at the moment that needs “fresh” CRL’s is HTTPS because it uses the presented cert for authentication. XRootD uses GSI which already refreshes CRL’s on its own.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1