We do have a question regarding using another bucket (and what type?) that is unanswered:
older client will not pick up this new bucket, what will happen to a long running client like that?
--
Wei Yang | [log in to unmask] | 650-926-3338 (O)
On 12/7/18, 1:10 PM, "[log in to unmask] on behalf of Brian Bockelman" <[log in to unmask] on behalf of [log in to unmask]> wrote:
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://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
