Hello!

On Tue, Jun 01, 2021 at 06:39:42PM +0200, Steffen Kieß wrote:

> 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.

Thank you for the details. The "rather weird design decisions" is
exactly what I was talking about: invalid assumptions about HTTP
guarantees and the fact that it works in simple cases resulted in
design decisions which made the RFC 4559 authentication mechanism
incompatible with HTTP (see the RFC errata).

> 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).

The "without any suppport by nginx" looks like the way to go.

--
Maxim Dounin
http://mdounin.ru/
_______________________________________________
nginx-devel mailing list
nginx-devel@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-devel