Hello Amos > -----Ursprüngliche Nachricht----- > Von: Amos Jeffries [mailto:squid3@xxxxxxxxxxxxx] > Gesendet: Dienstag, 8. Oktober 2013 03:35 > An: squid-users@xxxxxxxxxxxxxxx > Betreff: Re: Problems with helper ntlm_fake_auth > > FYI: in future this type of code related post should be sent to squid-dev > mailing list. Thank you. Ok, I will do that next time. > > The first problem is that the NTLM response header of type "TT" will be > generated wrong. > > > > This one has been generated with the new helper ntlm_fake_auth: > > ntlm_fake_auth.cc(219): pid=29811 :sending 'TT' to squid with data: > > [0000] 4E 54 4C 4D 53 53 50 00 02 00 00 00 09 00 09 00 NTLMSSP. ........ > > [0010] 28 00 00 00 07 82 08 A2 CE 7D 62 FA 44 55 80 E0 ........ ..b.DU.. > > [0020] 00 00 00 00 00 00 3A 00 57 4F 52 4B 47 52 4F 55 ........ WORKGROU > > [0030] 50 P > > > > And this one with the old helper fakeauth_auth (which is working): > > ntlm-auth[31700](fakeauth_auth.c:421): sending 'TT' to squid with data: > > [0000] 4E 54 4C 4D 53 53 50 00 02 00 00 00 0A 00 0A 00 NTLMSSP. ........ > > [0010] 30 00 00 00 07 82 08 A2 7B E5 5C 0B 49 DB 6D 36 0....... ....I.m6 > > [0020] 00 00 00 00 00 00 00 00 00 00 00 00 3A 00 00 00 ........ ........ > > [0030] 00 00 00 00 00 00 00 00 00 00 00 00 ........ .... > > > > It seems that the total length of the header has a wrong size and the char > ":" (0x3a) will be placed in the field "reserved". The client doesn't accept the > packet with the new response header and is sending a RST. > > Total length being the wrong size can be expected after the 3rd problem you > mention below. The entire structure is dependent on field sizes being > calculated and encoded correctly. Otherwise random extra space or barbage > ends up in the output. Those 00 octets at the end look suspiciously like such. > Can you please test this problem again and re-do the analysis after the size > and case patches are applied. A re-analysis on fixed field contents may help > with that TODO answer... Unfortunately it doesn't work with only the patches 2 and 3: 2013/10/08 09:06:20.215 kid1| auth_ntlm.cc(248) fixHeader: Sending type:40 header: 'NTLM TlRMTVNTUAACAAAACQAJACgAAAAHggiizn1i+kRVgOAAAAAAAAA6AFdPUktHUk9VUA==' ntlm_fake_auth.cc(219): pid=5679 :sending 'TT' to squid with data: [0000] 4E 54 4C 4D 53 53 50 00 02 00 00 00 09 00 09 00 NTLMSSP. ........ [0010] 28 00 00 00 07 82 08 A2 CE 7D 62 FA 44 55 80 E0 ........ ..b.DU.. [0020] 00 00 00 00 00 00 3A 00 57 4F 52 4B 47 52 4F 55 ........ WORKGROU [0030] 50 P Wireshark shows this: NTLM Secure Service Provider NTLMSSP identifier: NTLMSSP NTLM Message Type: NTLMSSP_CHALLENGE (0x00000002) Target Name: ???? <<< Why "????" Length: 9 Maxlen: 9 Offset: 40 Flags: 0xa2088207 NTLM Server Challenge: 074657c2b2de2963 Reserved: 0000000000003a00 <<< 3a is still in the "Reserved" field <<< address list is missing> Compare it with fakeauth_auth: NTLM Secure Service Provider NTLMSSP identifier: NTLMSSP NTLM Message Type: NTLMSSP_CHALLENGE (0x00000002) Target Name: Length: 10 Maxlen: 10 Offset: 48 Flags: 0xa2088207 NTLM Server Challenge: 074657c2b2de2963 Reserved: 0000000000000000 Address List: Empty > > + // doesn't work with this: > > // TODO: find out what this context means, and why only the fake > auth helper contains it. > > - chal.context_high = htole32(0x003a<<16); > > + //chal.context_high = htole32(0x003a<<16); > > + // twead payload, offset and length to get it working: > > + chal.payload[4] = 0x3a; > > + chal.target.offset = 48; > > + chal.target.len = 10; > > + chal.target.maxlen = 18; > > > > len = sizeof(chal) - sizeof(chal.payload) + > le16toh(chal.target.maxlen); > > data = (char *) base64_encode_bin((char *) &chal, len); > > > > In the code there is a comment "TODO: find out what this context > > means...". I think there is really some work to do. ;-) > > Yes there is. The other helpers are working perfectly fine without this > context value being set. Which is why it was elided from these versions. > Before this gets changed yet again, do you have any explanation for what > those seemingly arbitrary random values mean? You mean "0x003a<<16"? I don't now, but if these value is set, wireshark will show further field "Address List" set to "Empty". See above. If I compare the old fakeauth_auth module with the new ntlm_fake_auth I see that in squid-3.1 the ntlm_challenge struct had a variable "unknown" with a length of 16 bytes, this has been replaced in squid-3.2 with two fields of 4 bytes (totally 8 bytes). Aren't there 8 bytes missing? Squid 3.1: /* Challenge request sent by server. */ struct ntlm_challenge { ntlmhdr hdr; /* NTLM header */ strhdr target; /* Authentication target (domain/server ...) */ int32_t flags; /* Request flags */ u_char challenge[8]; /* Challenge string */ int16_t unknown[8]; /* Some sort of context data */ char pad[256]; /* String data */ }; Squid 3.2: /** Challenge request sent by server. */ typedef struct _ntlm_challenge { ntlmhdr hdr; /**< "NTLMSSP" , LSWAP(0x2) */ strhdr target; /**< Authentication target (domain/server ...) */ uint32_t flags; /**< Request flags */ u_char challenge[NTLM_NONCE_LEN]; /**< Challenge string */ uint32_t context_low; /**< LS part of the server context handle */ uint32_t context_high; /**< MS part of the server context handle */ char payload[256]; /**< String data */ } ntlm_challenge; > > Another problem is the presentation of domain and username. First the > domain was previously shown in uppercase. This could make problems with > case sensitive acls: > > And the last problem is a wrong specification of the string length for > domain and username. The last char of each string is missing. The problem is > that the string length will be initialized with -1: > > Okay. Slightly polished patches applied for these. Thank you very much! Best regards Elmar
<<attachment: smime.p7s>>
