Re: [squid-users] Proxy traversal query

From: Amos Jeffries <squid3_at_treenet.co.nz>
Date: Thu, 03 Jul 2014 18:00:26 +1200

On 2014-07-03 17:17, Vinay C wrote:
> Thank you so much Eliezer for the quick response. I am so happy to see
> such a detailed response here which I could not get in any forums.
> Please find my replies and a few queries inline.
>
> On Thu, Jul 3, 2014 at 12:16 AM, Eliezer Croitoru
> <eliezer_at_ngtech.co.il> wrote:
>> Hey Vinay,
>>
>> Answers are inside the email:
>>
>>
>> On 07/02/2014 08:15 PM, Vinay C wrote:
>>>
>>> Hi,
>>>
>>> I am looking for answer to a basic query and I have posted it in
>>> different forum but did not get any satisfactory answers. I hope in
>>> this group of expert I can get the answer.
>>
>> We can try to help you.
>>
>>>
>>> Context:
>>> I have a program (a sort of http client) that internally uses apache
>>> httpClient. Given some set of parameters like Authscheme, proxy
>>> server
>>> and other details it can traverse through Squid proxy and establish
>>> connection to given Webserver.
>>
>> What sort of authentication can it test?(basic, ntlm, kerberous)
>
> Vinay: It can test Basic, Digest, NTML and Kerberos. I want ensure
> that my client working can work with just not through Squid but any
> other enterprises level proxies in the world.
> I am not in IT domain but a QE engineer and want to ensure I can have
> a best possible coverage for my client. I agree that Squid is one of
> the best avaiable proxy server but my job is to ensure that my client
> works with other proxies too.
>
>
>>
>>> Query1: I want to ensure my program works for most of the enterprise
>>> proxy servers. Given that it can establish a connection via squid, is
>>> it safe to assume that it is going to work with all the proxy server
>>> like Microsoft TMG, Bluecoat etc?
>>
>> Depends on what are the options to authenticate and the proxy
>> configuration.
>> Some use basic auth others ntlm(should not be used from many reasons)
>> or
>> kerberous.(the are other options)
>

See below about the RFCs.

>>>
>>> Query2: In case I should test my program to be working with different
>>> proxy server then for enterprise world which of the proxy server
>>> would
>>> you like to suggest to have the best coverage.
>>
>> What fits for you!!
>> If you can test all of them with squid in a convenient way use squid.
>> If you feel that squid sweeps you from your feet then use another one
>> that
>> you feel easy and happy with.
>>
> Vinay:
> I tested that the client can establish the connection through Squid
> but before testing in rest of the proxies in world. I want to know
> that does it even make sense to do this exercise. Can I assume that if
> my client can establish the connection through squid, it will be
> capable of establishing connection through any other proxies in the
> world?

It does not matter. All proxies are working to a set of RFC standards.
The general operation is defined in
<https://tools.ietf.org/html/rfc7235> with each specific authentication
scheme being defined in the RFC standards referenced from
<http://www.iana.org/assignments/http-authschemes/http-authschemes.xhtml>

If your software meets the behaviour specified in those RFCs then any
HTTP proxy will be able to authentication it using one or more of the
schemes.

Squid is a good testing ground for Basic, Digest (only a few bugs
remaining), and Negotiate. We also have a Bearer module recently created
if anyone wants to sponsor its merging into public releases. I'm not
aware of any HTTP proxy supporting OAuth scheme yet - it is superceded
by Bearer now so may never happen.

NOTE that "NTLM" scheme found on many enterprise networks after only 12
years since deprecation has never been formally standardised. By the
time that happened it was called "Negotiate". If you want to support
"NTLM" you will have to lookup the proprietary specification(s) from
Microsoft for the 7 or so protocols which use that scheme label -
although only NTLMv2 is anywhere near safe to use today. I recommend
skipping this one, but you may need to do it for those earlier mentioned
enterprise networks.

Amos
Received on Thu Jul 03 2014 - 06:00:39 MDT

This archive was generated by hypermail 2.2.0 : Sun Jul 06 2014 - 12:00:05 MDT