On Mon, 17 Dec 2018 21:09, gnupg-devel@gnupg.org said:
> There are some restrictions implemented recently for the Location header:
> https://dev.gnupg.org/rGfa1b1eaa4241ff3f0634c8bdf8591cbc7c464144
Which are: If the host part of the new URL is identical to the original
one the entire new URL is used. If the host part differs only the new
host part is used and the path and query parameters of the original URL
are kept.
It might be possible to relax this insofar that certain transformations
of the path parameter are still allowed; in particular to allow a
redirection from say,
https://example.org/.well-known/openpgpkey/FOO to
https://openpgpkey.example.org/.well-known/openpgpkey/examample.org/FOO (different host and path but a well-known path structure)
to it easier to migrate to the new advanced scheme. But this adds some
complexity and will not cover all cases. I have doubts that this makes
sense.
> (as a side note it's interesting because this "CRSF" in GnuPG would not send any
> cookies and the attack described in the advisory shows rather an issue with the
> receiving app, not GnuPG... but that's a side note...)
The example they give is that in the internal network you have an server
which controls, say, a chemical plant. That server has only IP based
authentication and allows to open all kind of valves just be a HTTP
request. Someone inside of example.org sends a mail to an outsider and
the MUA automatically encrypts to that outsider. In the course of that
a http request is sent to the outsider's domain and that replies with a
302 and a malicious Location header. bang. A bit far-fetched, but we
better inhibit this.
Shalom-Salam,
Werner
--
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
signature.asc (0.81 KB)