RE: Re: NTLM auth for RPC over HTTPS to outlook everywhere

Amos Jeffries <squid3@xxxxxxxxxxxxx> · Thu, 23 Feb 2012 11:58:21 +1300

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@xxxxxxxxx]
Envoyé : mercredi 22 février 2012 11:26
À : squid-users@xxxxxxxxxxxxxxx
Objet : Re:  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@xxxxxxx]
Envoyé : jeudi 26 janvier 2012 13:12
À : 'squid-users@xxxxxxxxxxxxxxx'
Objet : RE:  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@xxxxxxxxxxxxx]
Envoyé : jeudi 26 janvier 2012 12:24
À : squid-users@xxxxxxxxxxxxxxx
Objet : Re:  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@xxxxxxxxxxxx]
> Envoyé : jeudi 26 janvier 2012 11:01
> À : squid-users@xxxxxxxxxxxxxxx
> Objet : RE:  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.
>
>
>
>