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

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

Hello Andrew

> Terminating SSL sessions before the web server assumes that 
> no client- 
> side certificates are in use.

I disagree with you here. Separate client certificate authentication is a
special discipline of an Application Security Gateway product and is
typically easier to integrate with the PKI solution than each single
application. Of course, that is only true, if the developers of the ASG
thought about this and built it into it in a serious way. I believe it is a
disadvantage of many deployments that back-end Web servers implement it
themselves just because client certs are coupled to SSL. Looking at several
new customer projects coming up with that approach I think this is confirmed.

> If you use client-side certificates  
> (either soft certs or smart cards), terminating early means that the  
> web app has to trust the front end termination device to provide the  
> authentication details from the client.

Yes, that is what I mean by seriously building it into a an ASG. That
involves more than just terminating SSL like some network accelerators do. It
means to support hardware key stores and back-end integration APIs to PKI
systems. Normally it is much more efficient to handle the PKI authentication
separately from the back-end applications and then maintain secure back-end
sessions by the ASG. This way, the back-end applications do not really need
to support SSL acceleration and PKI integration each. This basically means to
treat the client cert authentication as an authentication scheme like other
strong authentications. There's no need to couple it directly with the
back-end Web/Application servers. This is always a question of preference, of
course, and my proposal my not fit every architecture. However, based on our
customer projects I see new client cert projects going firmly into that
direction.

> Pretty much all solutions to this usually involve setting headers  
> (like REMOTE_USER or iv-cred similar) and passing on the request. If  
> the header or token is not present for unauthenticated requests, an  
> attacker can spoof the (say) REMOTE_USER header successfully.

Beside using a spoofing-vulnerable REMOTE_USER it is also possible to use
cryptographically secure SSO assertions, issued by the Application Security
Gateway or an external Login Service. We have several productive
installations with these mechanisms out there. Integration of one unified
secure SSO assertion (e.g. embedded in an backend-only(!) HTTP header or a
cookie) is typically easier and financially more interesting than embedding
the whole PKI functionality into all your Web/Application servers (assuming
that there are several of those). As mentioned above, it's a question of
preference after all. However, I disagree with the disadvantages of the ASG
solution as you describe them in your post.

Additionally, using an ASG for the separate authentication makes it possible
to easily switch authentication schemes or use different schemes in parallel
without having to modify all back-end Web/Application servers.

Best regards

Cyrill Osterwalder

Chief Technology Officer
Seclutions AG

http://www.seclutions.com