RE: NTLM HTTP Authentication is insecure by design - a new writeup by Amit Klein

["Cyrill Osterwalder" <cyrill.osterwalder () seclutions com>]

Hello Amit 

> I'm not sure I follow. You say SSL is handled in a *forward* 
> SSL proxy? But that proxy 
> typically does *not* have the SSL server side certificate. So 
> if it terminates the SSL 
> connection from the client (and establishes a new SSL 
> connection to the server, pooling 
> this connection among several clients), then the client will 
> see a nasty certificate 
> warning. Do people actually do this?

I really couldn't agree more. However, the answer is *yes*, some people do
that to control outgoing Web traffic. It's not what SSL is built for and I
don't think it's good to do it. I'm just saying that I happened to see it
implemented... ;-). It's one attempt of companies to control all Web traffic
and they can do it as long as they can modify the employee's workstation
browser and root certs.

> I suppose you're talking about a scenario wherein AirLock 
> (which is a kind of Web 
> Application Firewall - WAF, as far as I understand) sits in 
> front of a web server. 

Correct.

> Now, 
> suppose the root page (/) of the application is protected by 
> NTLM authentication. Client 1 
> goes through AirLock, authenticates to the webserver (NTLM) 
> and acquires a session token 
> from AirLock. A second client arrives (no session token, 
> since this is his first request), 
> requesting the root page (/). Unless AirLock performs the 
> NTLM authentication itself, I 
> don't understand (from your description) how it can prevent 
> this request from arriving at 
> the web server (and assuming AirLock pools connections, it 
> will do so on the connection of 
> the first client).

I understand your remark. AirLock can provide an NTLM proxy in its Login
Service component. So that would be the "Unless AirLock performs the NTLM
authentication itself" option of your remark. The NTLM authentication itself
is not done by AirLock, the Login Service can do "normal" NTLM to the
back-end NTLM server. Between AirLock as reverse proxy and the NTLM proxy
component the binding from the TCP connection to the AirLock session is
implemented. So client to reverse proxy has one TCP connection (must-have so
the client performs NTLM) and the NTLM proxy component has one TCP connection
to the back-end NTLM server. The second one however is bound to the user's
AirLock session an will not be pooled between sessions.

As described in my other reply to Andrew AirLock offers separate
authentication and that's what we offer for NTLM, too. AirLock controls when
and how the NTLM authentication is actually performed to the back-end NTLM
server.

> As for HTTP Request Smuggling, kindly refer to my earlier 
> submission to this mailing list, 
> titled "Can HTTP Request Smuggling be blocked by Web 
> Application Firewalls?"
> http://www.securityfocus.com/archive/107/402974

I'm aware of the HRS paper and I should admit that HRS cannot be fully
prevented by an ASG. Depending on the components behind AirLock HRS is
theoretically possible. However, AirLock provides tools like encrypted URLs
or signed request assertions to establish a trust association on HTTP
requests identified and checked by AirLock. Using these tools defeat most HRS
attempts as far as I can see it but it involves a little integration work, of
course. So I agree with you that any WAF/ASG cannot prevent HRS alone.

> There's a trade-off, true. It also assumes that the WAF 
> itself isn't vulnerable...

Absolutely correct. Regarding AirLock there is a strong focus on securing the
ASG/WAF itself as well. But your statement is generally correct and people
should always check that the security product itself is secure. There are
many reverse proxy servers out there that just base on one multi-threaded
process that can directly access internal resources. If this one fails....
ouch.


Best regards

Cyrill Osterwalder

Chief Technology Officer
Seclutions AG

http://www.seclutions.com