 |
 |
Hi Albert, Good to know. I am not in favor of introducing a new bucket because eventually all the clients/servers will move to signed parameters yielding the "old" bucket obsolete. Also, I really don't see any advantage in introducing a new bucket as appending is just fine. My two cents. Andy On Wed, 12 Dec 2018, Albert Rossi 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. > > > 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. > > > Al > > > **** Postilla: We would highly recommend increasing the length of P that the SLAC server uses in the DH key generation. We use a (hard-coded) 512-bit prime number generated by Openssl which we know passes validity tests and is considered to be safe. > > _______________________________________________ > Albert L. Rossi > Application Developer & Systems Analyst III > Scientific Computing Division, Data Movement Development > FCC 229A > Mail Station 369 (FCC 2W) > Fermi National Accelerator Laboratory > Batavia, IL 60510 > (630) 840-3023 > > > ________________________________ > From: Brian Bockelman <[log in to unmask]> > Sent: Tuesday, December 11, 2018 10:08 PM > To: Yang, Wei > Cc: Dmitry O Litvintsev; xrootd-dev; Albert Rossi; Paul Millar; ganis > Subject: Re: question about using DH_compute_key calls in XrdCryptosslCipher > > Hi Wei, Dmitry, > > Coming back to this -- > > How should we proceed? Is there any way that dCache could switch to the unpadded version? I'd prefer to not have random failures from our dCache sites... > > Wei - I don't understand your comment about memory leaks for unknown bucket types. Is there a known problem with the client? Or is this just a theoretical concern? > > Brian > >> On Dec 7, 2018, at 5:47 PM, Yang, Wei <[log in to unmask]> wrote: >> >> forgot to give the link between bucket and DH. DH parameters are transmitting in one of the bucket, with type "kXRS_puk". I guess Brian is proposing to send both unpadded and padded DH pars, in two different bucket (with different type). >> >> -- >> Wei Yang | [log in to unmask] | 650-926-3338 (O) >> >> >> ˙˙On 12/7/18, 2:36 PM, "[log in to unmask] on behalf of Yang, Wei" <[log in to unmask] on behalf of [log in to unmask]> wrote: >> >> Gerri is probably the right person to answer. From what we see, bucket is a unit for info exchange used in Xrootd GSI security. Many (unique) types of buckets can be added to a buffer (of type XrdSutBuffer), the buffer is then serialized and sent to the other end of the wire. The other end can retrieve those buckets based on their type. >> >> This brings up another question: is dcache implementation using similar data structure? If so, some of the documents we will produce can stay at bucket/buffer level. Otherwise, we need to find out how deep we need to dive to find a common denominator between the C++ and Java implementations. >> >> -- >> Wei Yang | [log in to unmask] | 650-926-3338 (O) >> >> >> On 12/7/18, 1:51 PM, "[log in to unmask] on behalf of Dmitry O Litvintsev" <[log in to unmask] on behalf of [log in to unmask]> wrote: >> >> Brian, >> >> How would it work with a "new bucket"? I am just not connecting the issue of padding >> and DHE signatures Andy is adding. Please expand a bit. >> >> Dmitry >> >> ________________________________________ >> From: Brian Bockelman <[log in to unmask]> >> Sent: Friday, December 7, 2018 3:09:37 PM >> To: Dmitry O Litvintsev >> Cc: [log in to unmask] >> Subject: Re: question about using DH_compute_key calls in XrdCryptosslCipher >> >> Hi Dmitry, >> >> It's a timely email - about 1 hour ago, Andy merged a PR that was tinkering with the contents of this bucket (adding a signature to the DHE to mitigate a MiTM). >> >> Unfortunately, OpenSSL 1.0.2h is fairly new compared to the minimum version Xrootd must support (RHEL6's 1.0.1e). >> >> What if we introduce a new bucket type for this and the extension that Andy just merged? How accepting is the dCache code of new bucket types? >> >> Brian >> >>> On Dec 7, 2018, at 2:58 PM, Dmitry O Litvintsev <[log in to unmask]> wrote: >>> >>> Hi, >>> >>> dCache uses bouncycastle (BC) java crypto library. >>> When we updated to BC version 1.5 we started to see occasional >>> (about 1 in 200) exceptions: >>> >>> javax.crypto.BadPaddingException: pad block corrupted >>> >>> when using xrdcp with gsi security against dCache xrootd server. >>> (secure handshake fails). >>> >>> We have tracked down the problem to the padding the secret with leading >>> zeroes when converting number to to byte array that has been introduced >>> in BC based on RFC 2631 (2.1.2) specification and the use of DH_compute_key in XrdCryptosslCipher in xrdcp client. >>> >>> We replaced DH_compute_key with DH_compute_key_padded calls and do not >>> observe the issue anymore. >>> >>> DH_compute_key_padded appears in openssl in version 1.0.2h [25 Aug 2016]: >>> >>> """ >>> *) New function DH_compute_key_padded() to compute a DH key and pad with >>> leading zeroes if needed: this complies with SP800-56A et al. >>> [Steve Henson] >>> >>> """ >>> >>> Are there principal objections/considerations of not using DH_compute_key_padded in XrdCryptosslCipher? (beyond compatibility issue - obviously a client implemented w/ DH_compute_key_padded would not work against server implemented w/ DH_compute_key). >>> >>> If turns out there are no objections we could think of some backward-compatible way >>> of introducing these functions. >>> >>> Thank you, >>> Dmitry >>> >>> ######################################################################## >>> Use REPLY-ALL to reply to list >>> >>> To unsubscribe from the XROOTD-DEV list, click the following link: >>> https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DXROOTD-2DDEV-26A-3D1&d=DwIFAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=7PHi3TDlwkvpc07MjENbOxVFl0u_sEurf250JnUFWCU&m=-HqMYppV4NUNFG0CTrXkFgpdzNNtVAAuFc6ivwtlwcI&s=jvnjAL9G37ZCLjoId5YQFcKcN72gTSW1iQEo5qIDN_8&e= >> >> ######################################################################## >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the XROOTD-DEV list, click the following link: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DXROOTD-2DDEV-26A-3D1&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=JERWGNkbKy0Lwgb3que_jMmI86TlBIkdQULIAchfD7M&s=BbI6F4UN68bChbILqFMSlJRXnoVNTfYBEn7gu3xpmls&e= >> >> >> >> ######################################################################## >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the XROOTD-DEV list, click the following link: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DXROOTD-2DDEV-26A-3D1&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=JERWGNkbKy0Lwgb3que_jMmI86TlBIkdQULIAchfD7M&s=BbI6F4UN68bChbILqFMSlJRXnoVNTfYBEn7gu3xpmls&e= >> >> >> >> ######################################################################## >> Use REPLY-ALL to reply to list >> >> To unsubscribe from the XROOTD-DEV list, click the following link: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DXROOTD-2DDEV-26A-3D1&d=DwIFaQ&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=JERWGNkbKy0Lwgb3que_jMmI86TlBIkdQULIAchfD7M&s=BbI6F4UN68bChbILqFMSlJRXnoVNTfYBEn7gu3xpmls&e= > > > ######################################################################## > 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 > ######################################################################## 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