Print

Print


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