Hello Amit
Thank you for this write-up on problems with authentication schemes bound to
TCP connections. I mostly agree with you and I think it's valuable to point
the topic out.
I'd like to add a few comments that you might want to consider as well:
Note that SSL is not connection-oriented security since each
request is encrypted with a secret, shared key, making this protocol
implicitly request-oriented.
That is basically correct. But SSL may be vulnerable to the same kind of
attack in the following scenario that we have seen in reality: A web
application server uses the SSL session ID to implement the session tracking.
Some clients connect through a SSL forward proxy that pools outgoing SSL
sessions. Of course, that is not the proper way to handle SSL in a forward
proxy. However it can happen in this scenario that other clients jump on
another SSL (and therefore application) session.
*) Proxy vendors - do not to share TCP connections to the server
among several clients. Yes, it improves performance, but it's also
insecure and enables/aids 3 different attacks (the one described
here, HTTP Request Smuggling and HTTP Response Splitting).
We are developing a secure reverse proxy server with a strong focus on
security AND performance. 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
(product name is AirLock, technology paper available here:
http://www.seclutions.com/en/downloads/AirLock_Whitepaper.pdf ) by binding
the NTLM authentication not only to the TCP connection on the client side but
also to the secure session management on AirLock. Just for the completeness
of your request to proxy server vendors I think you should cover this
possibility as well. By using our method of NTLM authentication through a
secure reverse proxy you do not make your system vulnerable to this attack,
even if back-end connections are pooled for performance. Also the other two
attack methods can be prevented using URL protection and filtering
techniques.
Of course, the NTLM connection based scheme is still vulnerable if a forward
proxy (that cannot be controlled by the service provider) is used as you
describe in your write-up.
Alternatively, use NTLM over HTTPS (SSL) to avoid this
vulnerability, but make sure that the SSL is terminated on the web
server, not some SSL accelerator (which may in itself facilitate the
attack, e.g. if it shares a TCP connection to the server among
several clients).
That is a valid request regarding this specific type of attack. However,
terminating SSL on the Web server (instead of a separate device in front of
it) introduces many other risks and vulnerabilities. If SSL is terminated on
the Web server, it is not possible to recognize any other attack methods
(e.g. application or Web server specific attacks) before they get to the Web
server. This may be too late! More information on such attack methods and why
SSL should always be terminated in front of a Web server is illustrated in
our technology whitepaper already mentioned above:
(http://www.seclutions.com/en/downloads/AirLock_Whitepaper.pdf).
Best regards
Cyrill Osterwalder
Chief Technology Officer
Seclutions AG
http://www.seclutions.com
