Page MenuHome GnuPG

dirmngr WKD redirection changes paths
Closed, ResolvedPublic


over in debian system administration configuration, weasel is trying to set up WKD for at the WKD advanced location.

Given T4590, currently we're also aiming to support the WKD direct location, but have it provide an HTTP redirection to the WKD advanced location, but dirmngr is apparently stripping the domain component from the path when it sees the redirection.

This results in the workaround listed at the above link, where we're also hosting the data at some weird non-direct, non-advanced location:

# Legacy GPG versions (including 2.2.12 in buster/Debian 10) get redirections from
# the (not supposed to be default) direct method wrong.
#  They ask for<hash>
#  get a redirect to<hash>
#  and then try to fetch<hash>
# *sigh*
Alias /.well-known/openpgpkey/hu/ /srv/
Alias /.well-known/openpgpkey/policy /srv/
# The draft specified well-known place using the "advanced method"
Alias /.well-known/openpgpkey/ /srv/

I'd like to get rid of this workaround because nothing in draft-koch-openpgp-webkey-service-08 mentions anything about filtering HTTP redirections, so it is perplexing that dirmngr would do that.

i imagine that some WKD clients will end up searching for the direct location eventually even after T4590 is fixed, and we want the redirection to just work, without this non-standard mirroring.

Dirmngr logs:

2019-07-02 11:46:39 dirmngr[16171.6] URL '' redirected to  '' (302)
2019-07-02 11:46:39 dirmngr[16171.6] redirection changed to ''



Event Timeline

dkg updated the task description. (Show Details)

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 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 -- -- 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 when querying the WKD direct URL for an address. That would also be a fine solution from my point of view.

werner changed the task status from Open to Testing.Jul 3 2019, 4:24 PM

I did some manual tests using netcat and KS_FETCH to test the redirection.

werner triaged this task as Normal priority.Jul 3 2019, 4:25 PM
werner added a project: gnupg (gpg22).
werner claimed this task.

Fix will be in 2.2.17