Hi Brian,
My comment regarding "unknown" bucket is: If a server sends an extra bucket, and the old client doesn't know this, the bucket will not be picked up. In that case, what will happen? Will it cause memory leak in the client?
This isn't a serious problem for a short living client. But it will have a larger impact to the long running client like Xcache, etc.
Gerri eventually chose to resolve our previous problem (signed DH pars) by conditionally replace unsigned DH pars by signed DH pars if XrdSecgsiVERSION > XrdSecgsiVersDHsigned.
So we basically have a few options: using extra bucket or piggy back to an existing bucket, combine with some kind of versioning requirement. I will take a closer look in the next week or so to see if I can come out with something workable.
regards,
--
Wei Yang | [log in to unmask] | 650-926-3338(O)
?-----Original Message-----
From: Brian Bockelman <[log in to unmask]>
Date: Tuesday, December 11, 2018 at 8:08 PM
To: Wei Yang <[log in to unmask]>
Cc: Dmitry O Litvintsev <[log in to unmask]>, xrootd-dev <[log in to unmask]>, Albert Rossi <[log in to unmask]>, Paul Millar <[log in to unmask]>, ganis <[log in to unmask]>
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://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
>
>
>
> ########################################################################
> 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
