On 12/01/2021 20.40, Stefan Claas wrote: >> So there are two "bugs" involved here. 1. GitHub presenting an invalid >> certificate for the sub-subdomain and 2. Sequoia not noticing that. >> Neither of these are bugs in GnuPG. If you can accept these facts, then >> it makes sense to further discuss what could be changed where to make >> your desired setup work. Maybe that discussion will lead to a concise >> change proposal. > > Hi Andre, currently I can only accept the fact that these two "bugs" are > currently not resolved in GnuPG and gpg4win, if you allow me to > formulate it this way. I desperately hope that this thread will lead to a
I (and others) understand the word "bug" as in "software not working according to its specification". The specification is the WKD Internet Draft as well as some RFCs about TLS certificate rules. Bugs in Sequoia or GitHub's DNS configuration can therefore not be resolved in a different software, namely GnuPG. Not sure what you mean by "resolve" otherwise. Ignoring security rules would be a workaround, and a terrible one as well. Regarding the "misconfiguration" of GitHub's DNS and HTTPS, I noticed Werner has actually added a corresponding paragraph to the WKD draft in May 2019 (version 08): Sites which do not use the advanced method but employ wildcard DNS for their sub-domains MUST make sure that the "openpgpkey" sub-domain is not subject to the wildcarding. This can be done by inserting an empty TXT RR for this sub-domain. Of course that only applies for someone striving for WKD conformance, which the github.io domain has absolutely no business with. Therefore they don't take this extra measure to suppress a failed attempt with the WKD advanced method. > Good question Andre! In case of github.io there is apprently no > email address, which is IMHO a good thing if people like to > set-up a github.io page and do not want to reveal their real > email address, to third parties, which is IMHO their good right, > in case they like to use this github.io pub key as multi-purpose > key, let's say for multiple email accounts, from other services, > file transfer, NFC postcards, you name it. Okay, so you're using a protocol (WKD) that was purpose-designed with e-mail in mind, but your user IDs don't work as e-mail addresses. Despite looking exactly alike. That in itself might confuse people (like me) using those keys. However WKD itself is not strictly tied to e-mail, in contrast to WKS (the related Web Key Service protocol). > Let's say as an example for gnupg.org. If am not mistaken > dev.gnupg.org has a different cert as gnupg.org. Let's assume > also that gnupg.org would come up with the idea of running > keys.gnupg.org. I strongly believe that a (purchased) SSL > cert for gnupg.org, covering wildcard subdomains, like GitHub's > cert is neither wrong nor does it cause any security implications, > when the direct method is used. You need to distinguish at which level the wildcard is found. A TLS certificate for *.gnupg.org would be perfectly fine, and even if dev.gnupg.org uses its own even though it would be covered by the wildcard. A fictional openpgpkey.gnupg.org server could present the wildcard cert, just as GitHub does it. But for an openpgpkey.dev.gnupg.org server, that would be invalid. Again, a certificate for *.dev.gnupg.org could be used there. There's two sides to the validity: DNS and TLS. Going back to the GitHub example for continuity. The DNS server resolves example.github.io to some IP address. It also resolves any sub-subdomain like openpgpkey.example.github.io to a (probably the same) IP address. The web server at that address presents a TLS certificate which is issued for *.github.io. It would need to present a different certificate for *.example.github.io in order to make a valid TLS authenticated connection. I don't think there is something like a *.*.github.io entry they could include in their certificate that would cover all sub- and sub-sub-domains at once. So the HTTPS connection to openpgpkey.example.github.io "works" on the DNS level, but has NO VALID TLS set up, which is the "bug" / error on their side. > Speaking of overhead, I must admit (again) I do not understand > what this is or what this can cause for a server maintainer or > a GnuPG or gpg4win user, when I for example can fetch my > pub key with sequoia real quick, because in binary form these > are only a couple of bytes and I strongly believe that a simple > directory structure, holding some files, on a web server has no > issues either. I'll try to explain what happens during a WKD lookup attempt in your preferred order, in hopefully simple terms (not 100 % technically correct). 1. The client queries DNS for the github.io domain, gets back an NS record (a name server for the github.io zone). 2. Client asks the returned DNS server about example.github.io, gets back an IP address for the (web) server. 3. Client contacts the web server on port 443, initiating a TLS handshake. Gets back a TLS certificate issued for *.github.io. 4. Client checks that the contacted DNS name is actually covered by that certificate. (OK for example.github.io, not for deeper levels) 5. Client sends an HTTP request over the established TLS connection, asking for the well-known URL's path component. The server answers "404 Not found" or similar. 6. Client decides that the simple method failed and goes back to step 2, this time trying the openpgpkey.example.github.io DNS name. Step 5 will succeed this time, returning the OpenPGP certificate and public key. Now you need to know that the "handshake" part consists of several back-and-forth data transfers, which is why surfing over satellite links is awful and stuff like QUIC / HTTP/2 is being developed to try and reduce these round trips. There are also many points where things can go wrong, e.g. the web server simply not answering on port 443 because it is really only an e-mail server and WKD is handled somewhere else (where we get in the second round). That involves the connection needing to time out first. So repeating steps 2 to 5 is what I mean with "overhead", which may very well cause user-noticeable delays. In contrast to that, *first* querying the sub-sub-domain openpgpkey.example.github.io would ideally return NXDOMAIN and we can switch immediately to trying the direct method. Less time and energy wasted. I say ideally, because on github.io specifically, that doesn't happen. Which is fine in itself. But the WKD spec lets us interpret that as "cool, the openpgpkey subdomain resolved, so let's use advanced method!" If it now fails at a later step (TLS certificate validity in this case), sane implementations rightfully report a misconfiguration and abort, because it may just as well be an MITM attacker fooling with the TLS certificate. What could be done in the WKD spec and / or GnuPG is to fall back to the simple method not only when the openpgpkey subdomain is unresolvable, but also if any other error happens during the advanced method. I don't see any obvious *security* implications in that. But providers like GitHub would then go through two complete HTTPS connections before the client notices "WKD just isn't set up properly there". The current WKD draft tries to avoid that duplicated server load by aborting early based on the DNS response. What Sequoia could do is fix their TLS host name check (step 4 above) to only match one level with a wildcard, slightly increasing security. But that is their call and I'm not knowledgeable enough on official TLS validity rules to point a finger. Just GnuPG and curl choking on your example indicates that it might be the Right Thing to do. What GitHub could do (easily) is follow the WKD recommendation and specifically block any "openpgpkey" sub-subdomain from resolving. Just in case someone is crazy enough (no offense Stefan :-) to try abusing their free web page service for WKD. Remember it is *their* domain even if they grant you free usage of a subdomain. And WKD specifically delegates some trust to the *domain owner*, so they have every right to not care about OpenPGP at all and let WKD requests fail ungracefully. Even the right to serve an invalid wildcard certificate for sub-subdomains (which is still bad though). Sorry for the long read, but I hope it clarifies the situation. Regards André -- Greetings... From: André Colomb <an...@colomb.de>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org http://lists.gnupg.org/mailman/listinfo/gnupg-users