Hi Andre, On Tue, 12 Jan 2021 20:13:42 +0100, André Colomb wrote: > It has also been pointed out repeatedly in this thread that Sequoia > apparently does not properly check the TLS certificate, which you have > proven with your example setup. That could be called "modern" or > "insecure". It has nothing to do with the ordering of the two methods.
I'd like to clarify what Sequoia is doing (wrong). As per the I-D, sq first tries the advanced method. If that fails for any reason, it falls back to the direct method. You can see the three relevant lines of code here: https://gitlab.com/sequoia-pgp/sequoia/-/blob/c80d2ab0/net/src/wkd.rs#L288 If I remove the "or_else", which falls back to the direct method, then sq shows the following error when fetching ste...@sac001.github.io: $ sq wkd get ste...@sac001.github.io Error: error trying to connect: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: (Hostname mismatch) Caused by: 0: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: (Hostname mismatch) 1: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed:../ssl/statem/statem_clnt.c:1915: So, the hostname mismatch is correctly identified, and it correctly returns an error. Where sq's behavior diverges from gpg's is that sq then tries the direct method, but gpg does not. The latest WKD I-D says: 3.1. Key Discovery There are two variants on how to form the request URI: The advanced and the direct method. Implementations MUST first try the advanced method. Only if the required sub-domain does not exist, they SHOULD fall back to the direct method. https://tools.ietf.org/html/draft-koch-openpgp-webkey-service-11 (FWIW, this was added to revision 7, which was published in Nov. 2018.) The I-D says "Only if the required sub-domain does not exist, they SHOULD fall back to the direct method." The text doesn't say: "If there is an error, they SHOULD fallback to the direct method unless the required sub-domain does not exist, in which case they MUST NOT fall back to the direct method." So, strictly speaking, I don't think Sequoia is violating the specification. But, I don't want to be overly pedantic. Even if the spec were to prohibit falling back to the direct method when the subdomain exists, what exactly would this prohibition gain us? We thought about this question, but we couldn't figure out a satisfactory answer. The worst attack we could come up with is: an attacker could force a WKD client to use an illegitimate WKD via the direct method instead of a legitimate WKD via the advanced method by: - Taking over foo.com's https, AND - Preventing a WKD client from correctly using the advanced method. But the attacker is NOT able to: - Take over openpgpkey.foo.com's https, OR - Prevent the WKD client from resolving openpgpkey.foo.com. So sure, that's possible, but it seems like WKD shouldn't foo.com's biggest worry in that case. (If we overlooked possible attacks, I'd be happy to hear about them.) On the other hand, implementing this prohibition means that a DNS server can prevent its clients from using WKD by forcing all openpgpkey subdomains to resolve to 127.1. That's hard to notice, because everything else still appears to work. Practically speaking, we helped an organziation deploy WKD, and they had a similar problem to what Stefan is observing: the admins setup the direct method, but it didn't work, because their DNS automatically resolved all unknown subdomains to serve a 404. Unfortunately, they had outsourced management of their DNS and couldn't (or didn't know how) to disable this behavior. IIRC, in the end, they spun up an https server for openpgpkeys.domain. :) Neal _______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users