 |
 |
Hi, I managed to go through this and understand better. As described at https://docs.google.com/document/d/1XjHWMHOXlDWCFtg_AnbfV7R9OICy5pq2IPwQvIwi2vY/edit#heading=h.q53z4zbfemri <https://docs.google.com/document/d/1XjHWMHOXlDWCFtg_AnbfV7R9OICy5pq2IPwQvIwi2vY/edit#heading=h.q53z4zbfemri> in 4.9 we introduced a more correct use of the IV for cipher encryption, which is now unique for each encryption and prepended to the buffer. So, it in normal that a buffer expected to be encrypted, as bmai in kXGC_cert, has 16 bytes (16 is length transmitted with the choice of the cipher) prepended to the buffer content. What is not normal is that the following buffer is not encrypted, as it seems in your case, with ‘gsi’ in bytes 17,18,19 . This I am not able to reproduce in my setup. Gerri > On 04 Mar 2019, at 17:25, Albert Rossi <[log in to unmask]> wrote: > > Gerri, they are at the beginning of the main. > > And they are indeed different at each call. > > So what is the purpose of this? And how am I supposed to produce it? A random 16 byte sequence? > > thanks, Al > > ________________________________________________ > 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: ganis <[log in to unmask]> > Sent: Monday, March 4, 2019 10:23 AM > To: Bockelman, Brian > Cc: Albert Rossi; xrootd-dev; Dmitry O Litvintsev > Subject: Re: SutBucket structure for main bucket in 4.9 > > Hi, > > Well, the 16 IV bytes are supposed to be copied at the beginning of the related bucket, not of the bmai serialisation. > Of course, there might be a bug. > > I will try to reproduce the problem and investigate. > > Gerri > > > >> On 04 Mar 2019, at 17:14, Bockelman, Brian <[log in to unmask] <mailto:[log in to unmask]>> wrote: >> >> Hi Albert, >> >> Is the 16 byte prefixed or changing on each connection? >> >> If I look through the git log on the directory, I notice there was a 16 byte IV added to the bucket serialization in December-ish; that roughly matches your timeframe, no? >> >> It also looks like the IV is copied to the beginning of the serialization. >> >> Brian >> >>> On Mar 4, 2019, at 9:57 AM, Albert Rossi <[log in to unmask] <mailto:[log in to unmask]>> wrote: >>> >>> One last point. >>> >>> If I discard the first 16 bytes of that main bucket on the incoming request, everything looks normal. >>> >>> My current problem is communicating back to your client. I am not sure what to place in the main bucket that seems to be missing. >>> >>> From: Albert Rossi >>> Sent: Monday, March 4, 2019 9:51 AM >>> To: xrootd-dev >>> Cc: Dmitry O Litvintsev >>> Subject: Re: SutBucket structure for main bucket in 4.9 >>> >>> Note that I am not speaking of the whole message (your buffer), just the main bucket. >>> >>> Before 4.9, our server sent and expected a main bucket structured this way: >>> >>> 4 bytes: protocol >>> 4 bytes: step >>> >>> ... buckets >>> none bucket >>> >>> in other words, it mirrors the top level structure, but is not preceded by a bucket type byte sequence. >>> >>> Evidently this has now changed. >>> >>> From: Albert Rossi >>> Sent: Monday, March 4, 2019 9:43 AM >>> To: xrootd-dev >>> Cc: Dmitry O Litvintsev >>> Subject: SutBucket structure for main bucket in 4.9 >>> >>> Hello all, >>> >>> I have looked through the GSI documentation for this, but cannot find an answer. >>> >>> I now notice that on the cert step, our server is receiving a main bucket from the 4.9 client which does not begin with the PROTOCOL, but is prefaced by another 16 bytes. >>> >>> In HEX dump: >>> >>> 05 EC 68 5A AB 6A 0E 2D 99 16 1F 88 49 AC BE 0E 67 73 69 00 00 00 03 E9 >>> >>> As you can see, the Protocol byte sequence (underscored) is no longer at the front of the bucket (67, 73, 69 = 'g', 's', 'i' ... and then 03 39 translates into the unsigned short 1001 = step). >>> >>> What are those 16 extra bytes? >>> >>> It seems the server needs to do something similar now as well, because when I send off the normally structured bucket to the client containing the proxy request (where PROTOCOL and STEP are the first things inside the main bucket), I see this error: "No protocol name: do nothing", >>> >>> [arossi@otfrid Desktop]$ xrdcp49 /etc/fstab root://fndcatemp1.fnal.gov:1095//pnfs/fs/usr/test/arossi/volatile/testdata-`date <> | tr ' ' '.'` >>> 190304 09:07:43 28150 sut_Buffer::XrdSutBuffer: no protocol name: do nothing >>> [0B/0B][100%][==================================================][0B/s] >>> Run: [FATAL] Auth failed >>> >>> which suggests to me it is expecting the protocol bytes in a different position. >>> >>> It would have been more convenient if these kinds of changes were described in the protocol document. >>> >>> Be that as it may, could you point me in the direction of the correct solution? >>> >>> Thanks again, Al >>> >>> ________________________________________________ >>> 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 >>> >>> 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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DXROOTD-2DDEV-26A-3D1&d=DwMCAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=T-cZfJxKaPqp86SpFBdUwwQIfJ1KbUxZTTKajDAlh-A&s=En3v7dIPWSAA1k6SdH4du5xu9ny4IRQKid--Vanz32A&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 <https://urldefense.proofpoint.com/v2/url?u=https-3A__listserv.slac.stanford.edu_cgi-2Dbin_wa-3FSUBED1-3DXROOTD-2DDEV-26A-3D1&d=DwMCAg&c=gRgGjJ3BkIsb5y6s49QqsA&r=60rQ0HHqHmEY1P6VSdyuTQ&m=T-cZfJxKaPqp86SpFBdUwwQIfJ1KbUxZTTKajDAlh-A&s=En3v7dIPWSAA1k6SdH4du5xu9ny4IRQKid--Vanz32A&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 <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