[squid-users] Squid server on Amazon EC2

Dear Squid users,

I want your experts solution for having squid proxy server configured in the
cloud.

What I am planning to do is :

---[LAN]-----[local_squid_proxy]----{internet cloud}---------[squid proxy in
cloud Amazon EC2 ]

what I want to setup is configure my local squid proxy with cache_peer
pointing to my squid proxy server in Amazon EC2 cloud.
cache_peer proxy.amazonec2.com parent 3128 3130 default

so that all my http request are forwarded from my local squid_proxy to the
proxyserver in the cloud.

Can anyone suggest me if above situation workable.

Thank you in advance.

-----Original Message-----
From: Fried Wil [mailto:wilfried.pascault_at_gmail.com]
Sent: Wednesday,22 February , 2012 2:56 PM
To: squid-users_at_squid-cache.org
Subject: Re: [squid-users] Re: NTLM auth for RPC over HTTPS to outlook
everywhere

Hi Clem,

Did you test CAS Server as Frontal just to test NTLM authentication less
Reverse proxy ?

User --> FW --> NAT_at_CAS Server and not User --> FW --> NAT_at_Reverseproxy
--> CAS Server

Just to test NTLM Authentication mecanism if it will be ok

Thx

On Wed, Feb 22, 2012 at 12:33:09PM +0100, Clem wrote:
> Hi Fried,
>
> I know all this links !! :), but As you I've made squid to work like a
> charm in front of my exchange for owa activesync and RPC too ... in
> basic auth, not in NTLM auth, and I still stuck there.
>
> Impossible to find a solution to make a linux front-end, neither with
> squid nginx apach or pound ! That's it ! I think I'll give up.
>
> BTW Thx !
>
> -----Message d'origine-----
> De : Fried Wil [mailto:wilfried.pascault_at_gmail.com]
> Envoyé : mercredi 22 février 2012 11:26 À :
> squid-users_at_squid-cache.org Objet : Re: [squid-users] Re: NTLM auth
> for RPC over HTTPS to outlook everywhere
>
> Hi Clem,
>
> I have test OWA RPC HTTPS and ..
>
> Apache => fail. Apache sees this as a security leak. This is a raw
> explanation :-). The problem is how apache and Exchange RPC use http
> 1.1 . Microsoft let bigger package pass over http 1.1.
>
> Check these links :
> https://issues.apache.org/bugzilla/show_bug.cgi?id=40029
> http://forum.nginx.org/read.php?2,3511
> http://httpd.apache.org/security/vulnerabilities_20.html
> http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2005-2088
>
> Squid as RP => OK. I have the final configuration. If u're
> interessted, tell me and i'll send u the squid.conf
>
> Nginx => Not tested but I think it will be the same as Apache ...
>
> Regards,
>
> Wilfried
>
> On Wed, Feb 22, 2012 at 11:19:31AM +0100, Clem wrote:
> > Hello,
> >
> > Coming back after weeks of researches, gave up with squid, tried
> > with
> pound
> > and nginx reverse proxy, and same issue, and the point is (getting
> > it from numbers of hints and searches in forums):
> >
> > For pound (from a user in forum):
> >
> > ---------- POUND ------------
> > I looked into this when I first started using pound. This is a
> > rather simplified explanation of what I discovered (and could be
> > completely wrong - I don't know enough about RPC or HTTP). When
> > Outlook sends the first HTTP request it specifies a content-length
> > of 1GB. I think this is so the request stays open and RPC commands
> > get sent via this "tunnel". Pound (being the good proxy that it is)
> > sits and waits for the 1GB of data to arrive and does not pass the
> > request to the BE until it does. Pound eventually times out waiting
> > for the promised 1GB of data and gives up.
> >
> > Here's Microsoft's details of the protocol:
> > http://technet.microsoft.com/en-us/library/aa995784(EXCHG.65).aspx
> > http://technet.microsoft.com/en-us/library/aa996706(EXCHG.65).aspx
> > ---------- END POUND --------------
> >
> > For NGINX (in logs) :
> >
> > ----------- NGINX ------------
> >
> > 2012/02/21 17:19:31 [error] 17072#0: *6 client intended to send too
> > large
> > body: 1073741824 bytes, client: x.x.x.x, server: mail.xx.fr, request:
> > "RPC_IN_DATA /rpc/rpcproxy.dll?localmail.fr:6002 HTTP/1.1", host:
> > "mail.xx.fr"
> >
> > ---------- END NGINX -----------
> >
> > IMHO, it's exactly the same issue I had with squid and rpc over
> > https with NTLM ...
> >
> > Hope that can help, I'm now completely stucked !
> >
> > Regards
> >
> > Clémence
> >
> >
> >
> >
> >
> > -----Message d'origine-----
> > De : Clem [mailto:clemfree_at_free.fr] Envoyé : jeudi 26 janvier 2012
> > 13:12 À : 'squid-users_at_squid-cache.org'
> > Objet : RE: [squid-users] Re: NTLM auth for RPC over HTTPS to
> > outlook everywhere
> >
> > On se second "anormal" I've sent, the certificate is sent.
> > The auth works on basic, I think the certificate is OK, however it
> > would
> be
> > rejected, isn't it ?
> >
> > -- ANORMAL2 (SQUID) --
> >
> > 2 0.001415 192.168.3.15 192.168.1.10 TCP https
>
> > 33043 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 TSV=0
> > TSER=0
> > SACK_PERM=1
> > 3 0.001457 192.168.1.10 192.168.3.15 TCP 33043
>
> > https [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSV=81334043 TSER=0
> > 4 0.002583 192.168.1.10 192.168.3.15 TLSv1
Client
> > Hello
> > 5 0.003850 192.168.3.15 192.168.1.10 TLSv1
Server
> > Hello, Certificate, Server Hello Done
> > 6 0.003887 192.168.1.10 192.168.3.15 TCP 33043
>
> > https [ACK] Seq=96 Ack=933 Win=7712 Len=0 TSV=81334044 TSER=23422065
> > 7 0.007140 192.168.1.10 192.168.3.15 TLSv1
Client
> > Key Exchange, Change Cipher Spec, Encrypted Handshake Message
> > 8 0.042683 192.168.3.15 192.168.1.10 TLSv1
Change
> > Cipher Spec, Encrypted Handshake Message
> > 9 0.043505 192.168.1.10 192.168.3.15 TLSv1
> > Application Data
> >
> > -- ANORMAL2 (SQUID) END --
> >
> >
> > -----Message d'origine-----
> > De : Amos Jeffries [mailto:squid3_at_treenet.co.nz] Envoyé : jeudi 26
> > janvier 2012 12:24 À : squid-users_at_squid-cache.org Objet : Re:
> > [squid-users] Re: NTLM auth for RPC over HTTPS to outlook everywhere
> >
> > On 26/01/2012 11:55 p.m., Clem wrote:
> > > Amos and Isenberg,
> > >
> > > For me, ntlm is not an option, I have to make it working, cause
> > > all my clients are in ntlm on outlook, especially the external
> > > ones. And that worked without squid, and I want that can work with it
at frond end.
> > >
> > > I've sniffed the sequence on working ntlm auth and not working
> > > (squid)
> > auth
> > > (192.168.3.15 is exchange serv, 192.168.1.134 my IP on direct
> > > RPCoHTTPS,
> > and
> > > 192.168.1.10 squid server redirecting from an external ip):
> >
> > Aha. Some use yes. It seems to confirm that the supported SSL
> > encryption types are probably the problem.
> >
> > The packets you call "NORMAL" the client connects, server accepts
> > that and hands over its certificate.
> >
> > The packets you call "ANORMAL" the client connects, the server
> > indicates a encryption change, the client accepts and sends the
> > requst in new form. The server certificate is apaprently not involved.
> >
> > You can probably drill down into those packets with "Change Cipher Spec"

> > to see more about what is going on. Search engine is likely to be
> > more help than me for the details you find.
> >
> > Amos
> >
> > >
> > > -- NORMAL ---
> > >
> > > 2 0.000377 192.168.3.15 192.168.1.134 TCP
> https>
> > > 26701 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 SACK_PERM=1
> > > 3 0.000428 192.168.1.134 192.168.3.15 TCP
> 26701>
> > > https [ACK] Seq=1 Ack=1 Win=64240 Len=0
> > > 4 0.000992 192.168.1.134 192.168.3.15 TLSv1
> Client
> > > Hello
> > > 5 0.002007 192.168.3.15 192.168.1.134 TLSv1
> Server
> > > Hello, Certificate, Server Hello Done
> > > 6 0.002642 192.168.1.134 192.168.3.15 TLSv1
> Client
> > > Key Exchange, Change Cipher Spec, Encrypted Handshake Message
> > > 7 0.035230 192.168.3.15 192.168.1.134 TLSv1
> Change
> > > Cipher Spec, Encrypted Handshake Message
> > > 8 0.036034 192.168.1.134 192.168.3.15 TLSv1
> > > Application Data
> > >
> > > -- NORMAL END ---
> > >
> > > -- ANORMAL (SQUID) --
> > >
> > > 2 0.000529 192.168.3.15 192.168.1.10 TCP
> https>
> > > 47552 [SYN, ACK] Seq=0 Ack=1 Win=16384 Len=0 MSS=1460 WS=0 TSV=0
> > > TSER=0
> > > SACK_PERM=1
> > > 3 0.000560 192.168.1.10 192.168.3.15 TCP
> 47552>
> > > https [ACK] Seq=1 Ack=1 Win=5856 Len=0 TSV=81027244 TSER=0
> > > 4 0.001248 192.168.1.10 192.168.3.15 TLSv1
> Client
> > > Hello
> > > 5 0.002110 192.168.3.15 192.168.1.10 TLSv1
> Server
> > > Hello, Change Cipher Spec, Encrypted Handshake Message
> > > 6 0.002140 192.168.1.10 192.168.3.15 TCP
> 47552>
> > > https [ACK] Seq=128 Ack=123 Win=5856 Len=0 TSV=81027244 TSER=23409792
> > > 7 0.002869 192.168.1.10 192.168.3.15 TLSv1
> Change
> > > Cipher Spec, Encrypted Handshake Message
> > > 8 0.003423 192.168.1.10 192.168.3.15 TLSv1
> > > Application Data
> > >
> > > -- ANORMAL (SQUID) END --
> > >
> > > I hope that can help you, as I can see there is a difference when
> > > the exchange server answer Hello, but I can't understand more ...
> > >
> > > Regards
> > >
> > > Clémence
> > >
> > > -----Message d'origine-----
> > > De : Isenberg, Holger [mailto:isenberg_at_e-spirit.com] Envoyé :
> > > jeudi 26 janvier 2012 11:01 À : squid-users_at_squid-cache.org Objet
> > > : RE: [squid-users] Re: NTLM auth for RPC over HTTPS to outlook
> > > everywhere
> > >
> > > I'm wondering if NTLM would work at all with any non-ISA proxy for
> Outlook
> > > Anywhere. After reading
> > >
> >
> http://www.sysadminlab.net/exchange/outlook-anywhere-basic-vs-ntlm-aut
> hentic
> > > ation-explained I'll stay with Basic Auth and when using it over
> > > https I don't see any reason for not doing. Of course when all
> > > your traffic to
> the
> > > Exchange https connector goes over squid, even on the local
> > > network,
> then
> > > you have a reason to use single sign-on login methods, but for
> > > that in
> our
> > > local network clients can connect directy to Exchange.
> > >
> > >
> > >
> > >
> >
>
Received on Wed Feb 22 2012 - 13:23:48 MST