Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
You bring up what I consider a classic cart-horse problem. Indeed, ztn requires TLS because the token has to be encrypted. All implementations of this rely on TLS to do that. In our case if one of the security protocols requires TLS then the connection itself must use TLS off the bat (I believe dCache does it that way as well). The reason is that there is no good way clean way of turning on TLS the moment you encounter a ztn request. This, as you point out. is exacerbated when the client thinks it can do TLS but, in fact, cannot. So, the client cannot honor the server's requirement that the connection must use TLS. The ztn issue here is sort of a sideshow since this problem exists whenever a site decided to mandate TLS even if it did not want to use ztn. Of course, the desire is to use ztn when it is possible and not when it is not possible and do it securely. Mind you it's rather odd because if you can't use ztn because you can't use TLS in the scenario show here then you really can't use x509 to begin with. So, there is precious little left to use and we may be beating a dead horse here.
@amadio and I had a long discussion about this and what a possible secure solution might look like, It always came down that if the client can't do TLS then it should not claim that it can. If the claim is accurate then we would be able to provide the client with a list of protocols that better correspond to it's capabilities. That's easier said than done. The straightforward thing works -- no cert directory then TLS will not work. Same should you have a directory but it's empty. But if you have something in the directory it might not be complete and you'll never know until something fails because a CA cert is missing or expired.
So, we agree that the client should at least make sure that the TLS context was successfully created and if it was not continues as if it were not TLS capable however likely that other things will fatally fail anyway.
So, now the server knows the client is not capable of TLS so the server can exclude ztn from the list of available protocols. Unless, of course, it's the only one. Then we necessarily have to fail the login for security reasons.
Now, that's a lot of work and requires that a new set of clients be deployed which is the hardest part to accomplish. Practically, it would be easier to make sure the worker nodes were fully configured then trying to side-step this particular restriction. That's especially true for Atlas and CMS as both rely on x509 as an alternative to tokens. (or vice versa depending on your viewpoint) But if tokens won't work then neither will x509 in this scenario. So, we are back to square one unless your alternative is something other than x509 for eosatlas, is it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
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