 |
 |
Hi @abh3 - Did a lot of studying of the OpenSSL code and how XrdTls implements it. The good news is that there's likely no way that the TempCA implementation could beat it -- for a remote host, the existing XrdTls code accesses a single file and loads a single CA from it. For the TempCA code, while it also loads a single file, there's still a need to parse linearly through all the available CAs. This goes back to the question about the `libcurl` backend: OpenSSL assumes that the CA directory is hashed according to a specific hash function, allowing a cheap lookup. However, `libcurl` makes no assumption about an OpenSSL backend and assumes the CA directory is just an unorganized directory full of CAs -- which then causes all the I/O problems. So, I don't see any way we can improve what XrdTls does in general and right now the only case I see for TempCA is in the XrdTpc code. That said, I _do_ like the current location of the code (it's all about TLS handling, might as well put it in the XrdTls directory). I believe several of your points are addressed by the latest commit, which moves things out to a separate thread. That reduces the maximum cost of getting a reference to a good set of CAs to the refcount increase on the shared pointer -- instead of potentially a scan of the directory. Given the TempCA piece is necessary for correctness in the libnss backend - and an important reduction in I/O for openssl - instead of making this a daemon-wide config option, I think we should go back to having this on-and-required by default. Toward another question above: libcurl only can create new connections while its handle is available. Thus, as long as the shared pointer lives for the entirety of the libcurl transaction, you're guaranteed that the CA lifetimes are long enough. Finally, there's the question of the location of the CA temporary file. I chose the `/tmp` as I can rely on `mkstemp` to create the file and there's a plethora of daemons that make the (reasonable) assumption small temporary files can be kept there. It works nicely as a configuration-free way to proceed. If you had a good suggestion for another location, I'm quite interested. For example, a good improvement would be a directory assumed to be owned by the `xrootd` user: with that, we can avoid security issues that cause us to rely on `mkstemp` in the current code and use non-changing, well-known filename for the CA file. Then, we don't need to refcount the CA usage as libcurl can always open the exact same file. -- You are receiving this because you commented. Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/pull/1431#issuecomment-813797392 ######################################################################## 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