Hi Cyrill,
Hope you're not vexed with my follow-ups... Please see below.
-Amit
On 20 Jul 2005 at 11:35, Cyrill Osterwalder wrote:
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.
I'm not sure I follow, but anyway, it does seem that in this case, you don't
pool the
connection to the backend server after all (in your original submission, you
said
"It is indeed possible to handle NTLM authentication in a reverse proxy and
pooling server
connections WITHOUT being vulnerable to your described attacks. We are able to
do this with
our reverse proxy [...]").
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.
I am not familiar with the technologies you implemented in your product. It
does seem to me
that they do not address the problem, which is incompatibility in HTTP parsing.
Basically,
HRS can be used for cache poisoning by sending a seemingly innocent request for
a resource
(say the root page - "/"), followed by a request for another resource (the
poison), e.g. to
an application error page, or any other VALID page in the system. The two
requests are
valid from the URL point of view, so offhandedly I don't see how URL encryption
and request
assertions would prevent the attack. A more strict parsing will block some of
the attacks
(not all), but how would looking at the URL do any good?
