emanuele bizzarri wrote:
> Hi Arno,
> thankyou for your response.
>
>> I agree with you that OverbyteIcsNtlmMsgs.pas only supports Unicode
>> NTLM messages. However I recently implemented proxy support in
>> TWSocket and tested that stuff against Squid proxy, it did work with
>> current OverbyteIcsNtlmMsgs.pas fine. So at least that version of
>> Squid I used for testing must have supported Unicode.
>
> I'm using IPCOP 1.4.21 (latest available).
>
> Maybe you have tested a newer version (3.1?)
> I've checked the squid release note, here:
> http://www.squid-cache.org/Versions/v3/3.1/RELEASENOTES.html
I used the Windows port version 2.7stable8, that might be the difference?
Here's my squid.conf:
auth_param ntlm program C:/Squid/libexec/mswin_ntlm_auth.exe -A Users
auth_param ntlm children 5
auth_param ntlm keep_alive on
[..]
Authentication is delegated to external helper apps.
I found that Squid required a domain name and made a comment
in the source code:
{code}
function TCustomHttpTunnelWSocket.HttpTunnelGetNtlmMessage3: String;
var
Hostname : String;
NtlmInfo : TNTLM_Msg2_Info;
LDomain, LUser: String;
begin
{ get local hostname }
try
Hostname := String(LocalHostName);
except
Hostname := '';
end;
NtlmInfo := NtlmGetMessage2(String(FHttpTunnelAuthChallenge));
NtlmParseUserCode(HttpTunnelUsercode, LDomain, LUser, FALSE);
{ With Squid proxy LDomain may not be empty (at the time of writing), }
{ a user code of <DOMAIN>\<UserName> works with Squid. Fix below }
{ works with Squid, however I'm not 100% sure whether to include it }
{ by default. }
if (LDomain = '') and (Pos('@', LUser) = 0) then
LDomain := NtlmInfo.Domain;
{ hostname is the local hostname }
Result := NtlmGetMessage3(LDomain,
Hostname,
LUser,
FHttpTunnelPassword,
NtlmInfo.Challenge);
end;
{code}
>>
>> If this actually requires a fix there should be a solution that can
>> be used in all components not just a separate fix for the HTTP client
>> IMO.
>
> You're right: the fix should be applied also where necessary
> (OverbyteIcsNTLMSSP, OverbyteIcsPOP3Prot, OverbyteIcsPp3ProtOld,
> OverbyteIcsSMTPProt).
> Up to now I've never used these units, so I have not changed them.
>
>
>> Whether Unicode or OEM strings are used in the NTLM communication
>> should be an implementation detail hidden to the component user.
>> Your fix doesn't fix for instance the NtlmGetMessage2 result,
>> I wonder what the TNTLM_Msg2_Info result looks like with your proxy?
>>
>
> If I debug NtlmGetMessage2 function, I see:
>
> function NtlmGetMessage2(const AServerReply: String): TNTLM_Msg2_Info;
>
> AServerReply='TlRMTVNTUAACAAAACwALACgAAACCgkEATo49y/toC4kAAAAAAAAAAEUtV09SS1MuTEFO'
>
> NTLMReply='NTLMSSP'#0#2#0#0#0#$B#0#$B#0'('#0#0#0'‚‚A'#0'C'#8'Êlÿô”Ü'#0#0#0#0#0#0#0#0'E-WORKS.LAN'
So that's obviously ANSI and the message is currently not parsed correctly.
Have you tried to remove "Flags_Negotiate_OEM" from the flags in:
{code}
function NtlmGetMessage1(const AHost, ADomain: String): String; ?
[..]
// prepare flags
Msg.Flags := Flags_Negotiate_Unicode or
// Flags_Negotiate_OEM or // <= Makes no sense when we support
Unicode only
Flags_Request_Target or
Flags_Negotiate_NTLM or
Flags_Negotiate_Allways_Sign { or
Flags_Negotiate_NTLM2_Key};
{code}
This might enforce Unicode (if the server supports it) otherwise
the server may use either OEM or Unicode, perhaps a simple fix?
--
Arno Garrels
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
