RE: [squid-users] Re: NTLM auth for RPC over HTTPS to outlook everywhere

On 23.02.2012 00:33, 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.

Like all that Apache argument said, that 1GB is an abuse of HTTP. It is
both requiring 1GB of data to be transferred over that connection

When you combine it with the other abuse of HTTP which NTLM does things
go bad very quickly. Think about the network handling 3 GB of data
transfer to receive a ~2500 byte username+password token. From every
single user browsing, perhapse a couple of times a minute. How big are
the network pipes?

Like the Apache people said the client user agent (outlook) needs to
use chunked encoding.

NTLM in particular uses three handshake requests...

  request #1 depending on your version of Squid, may or may not hit an
efficiency optimization dropping the initial connection when the
challenge goes back.

   ==> what does this do to the initial 1GB request from outlook? does
outlook fail or recover? MS wrote NTLM assuming the connection would
stay available, open, has end-to-end properties and exists on a fast LAN
environment.
   ==> this optimization is controlled by the "auth_param ntlm
keepalive" on/off setting.

  request #2 and #3 are stateful token exchange and NTLM *REQUIRES* them
to share a connection. If #2 also has 1 GB length that GB will be waited
for before the #3 request is received on the pipeline by Squid.

   ==> how long does that GB take? versus what timeouts?

Amos

>
> 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-authentic
>> > 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 - 22:58:25 MST