<div dir="ltr"><div dir="ltr">On Sat, Nov 19, 2022 at 4:04 PM Maxim Dounin <<a href="mailto:mdounin@mdounin.ru">mdounin@mdounin.ru</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello!<br>
<br>
On Fri, Nov 18, 2022 at 10:30:29PM -0500, Michael B Allen wrote:<br>
<br>
> NTLM over HTTP is a 3 request "handshake" that must occur over the same TCP<br>
> connection.<br>
> My HTTP service implements the NTLMSSP acceptor and uses the clients remote<br>
> address and port like "<a href="http://10.11.12.13:54433" rel="noreferrer" target="_blank">10.11.12.13:54433</a>" to track the authentication state<br>
> of each TCP connection.<br>
><br>
> My implementation also uses a header called 'Jespa-Connection-Id' that<br>
> allows the remote address and port to be supplied externally.<br>
> NGINX can use this to act as a proxy for NTLM over HTTP with a config like<br>
> the following:<br>
><br>
> server {<br>
> location / {<br>
> proxy_pass <a href="http://localhost:8080" rel="noreferrer" target="_blank">http://localhost:8080</a>;<br>
> proxy_set_header Jespa-Connection-Id <br>
> $remote_addr:$remote_port;<br>
> }<br>
> }<br>
<br>
I'm pretty sure you're aware of this, but just for the record. <br>
Note that NTML authentication is not HTTP-compatible, but rather <br>
requires very specific client behaviour. Further, NTLM <br>
authentication can easily introduce security issues as long as any <br>
proxy servers are used between the client and the origin server, <br>
since it authenticates a connection rather than particular <br>
requests, and connections are not guaranteed to contain only <br>
requests from a particular client.<br></blockquote><div><br></div><div>Hi Maxim,</div><div><br></div><div>Hijacking NTLM authenticated TCP connections is not THAT easy.</div><div>But generally, we assume HTTP TLS is being used if people care at all about security.</div><div>AFAIK TLS can't go through proxies without tunnelling so either way, you shouldn't be able to hijack a TLS connection.<br></div><div><br></div><div>NTLM is used because it's fast, reliable and provides a truly password-free SSO experience.</div><div>While Kerberos provides superior security, it can be fickle (client access to DC, time sync, depends heavily on DNS, SPNs, ...).</div><div>Since NTLM is the fallback mechanism, it always works.</div><div><br></div><div>NTLM has issues that are more significant than what you described.</div><div>But they can be managed.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> More generally, do you see any problems with this scheme?<br>
<br>
As of now, nginx by default does not use keepalive connections to <br>
the upstream servers. These are, however, can be configured by <br>
using the "keepalive" directive (<a href="http://nginx.org/r/keepalive" rel="noreferrer" target="_blank">http://nginx.org/r/keepalive</a>), <br>
and obviously enough this will break the suggested scheme as there <br>
will be requests from other clients on the same connection.<br></blockquote><div><br></div><div>My implementation works with connection caching (keepalive) to backends.</div><div>Here's the config I'm testing right now and so far it's holding up:</div><div><br></div><div>upstream backend {<br> ip_hash;<br> server localhost:8080;<br> server localhost:8081;<br> keepalive 16;<br>}<br>server {<br> location / {<br> proxy_pass <a href="http://backend">http://backend</a>;<br> proxy_http_version 1.1;<br> proxy_set_header Connection "";<br> proxy_set_header Jespa-Connection-Id $remote_addr:$remote_port;<br> }<br>}<br></div><div><br></div><div>Loopback captures look right.</div><div><br></div><div>Note the key difference in my scheme is the Jespa-Connection-Id which gives the backend the id it needs to properly map clients to security contexts.</div><div><br></div><div>Mike</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Michael B Allen<br>Java AD DS Integration<br><a href="http://www.ioplex.com/" target="_blank">http://www.ioplex.com/</a></div></div></div>