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:

function TCustomHttpTunnelWSocket.HttpTunnelGetNtlmMessage3: String;
    Hostname : String;
    NtlmInfo : TNTLM_Msg2_Info;
    LDomain, LUser: String;
    { get local hostname }
        Hostname := String(LocalHostName);
        Hostname := '';
    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,

>> 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;
> 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:

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

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

Reply via email to