We need to rewrite the Location to avoid a CSRF attack. See fa1b1eaa4241ff3f0634c8bdf8591cbc7c464144

I can offer to add an exception for Debian, like we did for protonmail but it is better to fix T4590 to avoid your workaround.

Thanks for the pointer, @werner. Certainly we want T4590 fixed.

But I don't understand the CSRF attack that you're concerned about.

In a CSRF attack, site A abuses the state of the web client (the browser) to make it perform some action on site B. In this case, the web client is dirmngr. The type of state that is typically abused is (for example) cookies, cryptographic authentication credentials, localstorage, etc.

What exploitable state is available in dirmngr that could be abused in this way?

Furthermore, if there really is a CSRF attack to defend against, it's not clear that keeping a path fixed while changing the domain name is a complete defense against CSRF. Surely if a well-structured URL has a particular semantic impact on server A, it's likely to have a similar semantic impact on server B, and a redirection from A to B will shift where that semantic impact happens. Are we not concerned about that attack?

See https://sektioneins.de/en/blog/18-11-23-gnupg-wkd.html for details. In short they fear that companies using IP based security for internal services can be attacked via redirect request and in particular becuase that can happen in the background without the user noticing. I am not concerned but we had long lasting discussions also with protonmail about this and the result was that we need to have this protection. We do not know who requested and paid for the audit from SektionEins and they won't tell us.

@werner, thanks for the pointer to the report, that's certainly useful. And i'm happy that organizations like SektionEins are doing GnuPG audits and publishing their results regardless of who paid for them.

I agree that IP address-based security is something that could be exploited by dirmngr. but the problem there is in whatever system implements their example vulnerable target -- https://cluster.example.com/rest/shutdown?when=now -- not in dirmngr.

That system would also be vulnerable to a Thunderbird installation that is configured to load remote images from incoming e-mail (or configured not-to-load-images, but if the user clicks "load remote resources" on any given e-mail). It would also be vulnerable to basically any web browser used from the authorized IP address range.

So i don't really think that the defense you've taken -- of keeping the path fixed -- is a particularly strong one, but i can see that it is an attempt to make a good faith effort to remedy a perhaps-overstated concern.

That said, I suspect that a redirection from the "direct" URL to the "advanced" URL is likely to be a common configuration if WKD gets widely deployed, as many organizations do not want to host regularly-changing data on their main site. And i'm sure that this will bite more people in the future for whatever reason. For example, if the "advanced" deployment is failing for some site, and they've configured such a redirection from the "direct" deployment, i can imagine dirmngr cobbling together this mishmashed URL. then the admin who goes to look at the logs for the failing "advanced" deployment says "that's odd, i thought we were supposed to serve from this directory, but dirmngr is querying over there".

So currently, as i understand it, the 302 redirection filter is:

• the redirected host must be within the domain queried
• the path will remain fixed to the original path.

I'm proposing to loosen that to:

• the redirected host must be within the domain queried
• if the proposed redirected path matches the "advanced" path (with or without query string), accept it; otherwise, keep the original path

I head the same idea when I read your configuration. Given that the advanced lookup was not reallydeployed (see T4590) I also expect that we will receive complains now that it works. Thus white listing any "openpgpkey." seems to me a reasonable easy solution.

I think you're suggesting accepting *any* path if the hostname of the proposed redirection matches openpgpkey.example.org when querying the WKD direct URL for an @example.org address. That would also be a fine solution from my point of view.