Hello,
On 01.06.21 01:08, Maxim Dounin wrote:
Hello!
On Mon, May 31, 2021 at 09:41:42PM +0200, Steffen Kieß wrote:
On 31.05.21 18:36, Maxim Dounin wrote:
Thanks for the patch. You may want to elaborate a bit more on how
do you expect these variables to be used.
[...]
These variables can be used to implement authentication with channel
binding in an http application.
[...]
I've attached a flask application + a client which shows how this can be
used, the required configuration in NGINX (when using fastcgi) is:
So, you expect these variables to be used by application
developers to implement some (currently not implemented)
authentication with channel binding in HTTP, and that's the only
use case you consider, correct?
One use case is channel binding for RFC4559. This already exists
(Microsoft IIS implements the server side with channel binding,
Microsoft Edge implements the client side with channel binding). There
are also other implementations without channel binding (firefox and
libcurl as clients for example) but this is in general vulnerable to
MitM attacks, even when using HTTPS (because an attacker who can cause a
client to do authentication over HTTP can then reuse the authentication
data for doing authentication over HTTPS). RFC4559 has some rather weird
design decisions (like doing authentication per-connections instead of
per-request) but it is used in real life.
On the other RFC4559 uses the tls-server-end-point channel binding which
can also be done without any support by NGINX (by providing the server
certificate to the web application).
Note that HTTP provides no guarantees about channels, that is,
connections, and trying to use channel binding is expected to
break operation over HTTP, especially in complex setups when using
proxies or reverse proxies, such as nginx. Further, invalid
assumptions about guarantees in HTTP can easily cause security
issues, by incorrectly authenticating unrelated requests on the
connection. Basically the same set of issues as already seen with
Microsoft's mis-designed NTLM authentication which doesn't work
through proxies.
Channel binding is for HTTPS only, so there should not be any issues
with proxies.
Reverse proxies and load balancers obviously will make this more
complicated (because the channel binding information would have to be
forwarded to the web application in way which an attacker cannot spoof),
but in simple cases (e.g. using NGINX as a frontend which forwards
requests to an application over FastCGI or the uwsgi protocol) this
should not cause any problems.
Note that using channel bindings does not require you to do
per-connection authentication; you still can do per-request
authentication and only gain an assurance that no attack is performing a
MitM attack on the TLS connection.
Given that, it might not be a good idea to provide such variables.
Best regards,
Steffen Kieß
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel
