 |
 |
> On Dec 12, 2018, at 7:33 AM, Albert Rossi <[log in to unmask]> wrote: > > Hello all, > > I am now on this list, so let me chime in on this. > > I can speak to the buckets. If I understand the archaeology of the dCache xrootd code correctly, it looks like the Java data structures were reverse engineered from the C++ data structures. The concept of the bucket is preserved, although I did discover that when coding the TPC client, there were a few minor ambiguities which cropped up. > > I am not entirely sure why the padding would cause the need for a different bucket type. Couldn't one just turn the parameter indicating padded versus unpadded into a list, and the client chooses which one to use and communicates that back to the server? It doesn't look like any other change in the parameters is necessary, at least from our testing.**** > > But these are implementation details. The important thing is that the algorithms used by the SSL library and by the Java BouncyCastle library are not matching up for unpadded. We think (Dmitry took this part over, actually) we have solved the decryption direction -- that is, there are no more errors between the SLAC client and the dCache server. However, going the other way (encryption), the TPC client in dCache occasionally encounters a response from the SLAC server which causes BouncyCastle to report that the generated shared secret is shorter than the blocksize (15 instead of 16 bytes) (offset/limit error). I am trying to figure out if there is a way to solve this without requiring the padded algorithm. At worse, we could catch the error and retry. > Can dCache simply pad before sending the text to BC? > But all of this goes away when both ends switch to the padded algorithm. We had tested this by hacking your 4.8.4 server and client to use the ssl padded method, and by eliminating the compensatory code on our side. I saw 1000 successful transfers for 2 party and 3 party both ways, no padding or offset errors. > > Of course, we would understand the need to preserve unpadded on your end for backward compatibility. Certainly we could do something similar on the dCache end, though the unpadded active TPC will remain susceptible to this occasional (once in every 200-300 transfers?) error unless we find an amelioration. > From Wei's response: > Gerri eventually chose to resolve our previous problem (signed DH pars) by conditionally replace unsigned DH pars by signed DH pars if XrdSecgsiVERSION > XrdSecgsiVersDHsigned. Could we have the padded algorithm always used for the new version of the GSI protocol? If it's as simple as adding extra null bytes to the encoded integer, maybe it would be easy to workaround older version of OpenSSL? Brian ######################################################################## 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