We have been recently bitten by the dirmngr rewriting back redirects found in WKD lookup to the .well-known path¹

We were expecting a HTTP redirect to work, a straight wget to the proper path correctly downloaded the key in binary format (and other clients probably worked), but when testing with gpg it failed to fetch the key.

In our case it was not that hard to figure out what was happening, and we will be fixing it shortly, but I think it is a general issue worth discussing.

My main concern is that this is completely surprising behavior. A WKD server operator following the spec https://www.ietf.org/archive/id/draft-koch-openpgp-webkey-service-15.html won't know about this weird restriction that redirect targets will be modified unless specifically testing with gpg.²
draft-koch-openpgp-webkey-service doesn't mention HTTP redirects at all, but if they are supported the expectation would be that they are followed like any other client.

I have read https://sektioneins.de/en/blog/18-11-23-gnupg-wkd.html and I share the opinion stated by @dkg on T4603#127670: There is a CSRF vulnerability in their "Attack the HTTP client" scenario, but it lies on the https://cluster.example.com/rest/shutdown?when=now system. A normal web browser would trivially (and more easily) shut down such system by visiting an untrusted web page (plus, a GET request is defined as a safe method (section 9.2.1 of rfc9110), and should not be changing any server state, including shutting down the remote system. It would still be vulnerable to CSRF if it used POST, but it would be slightly harder, and not applicable to dirmngr as client).

I might add a restriction for the case where a site on a public ip address redirects to one on a rfc1918 block, but not more. And even that would be a bonus, for example Firefox hasn't implemented it yet, after 17 years (bug 354493).

Trying to get this actionable, I would suggest:

• Mentioning on draft-koch-openpgp-webkey-service that HTTP redirects SHOULD be followed (many servers seem to rely on that already)
• Add a note about compatibility mentioning that old clients restricted redirects targets to the fixed .well-known path
• Drop the changing of Location targets (perhaps a bit controversial, but I think it only makes sense to properly follow HTTP semantics)

The other dirmngr http restrictions (a .onion can only redirect to another .onion, https:// cannot redirect to http://) are reasonable and in line with other HTTP practises. They should stay, I don't think they are a problem at all.

By the way, when reviewing the related code, line 3806 of dirmngr/http.c (added in ae9acb87) should probably use location instead info->orig_url, it is saying (" changed from '%s' to '%s'", info->orig_url, newurl), but I think it should say (" changed from '%s' to '%s'", location, newurl) or, providing full information, (" '%s' redirect to '%s' changed to '%s'", info->orig_url, location, newurl) [eliding here the argument 0 for readability, as that applies to an unrelated previous %u]

¹ https://git.gnupg.org/cgi-bin/gitweb.cgi?p=gnupg.git;a=blob;f=dirmngr/http.c;h=b4c501736dc72dd4e252d601fc7c55de45d8db30#l3759
² Actually, now I discovered this I suspect we stumbled upon it on our initial WKD deployment years ago, but overcome it by changing how the keys were exposed without realizing what was really happening.