On Fri, Jan 15, 2021 at 07:56:16AM +0100, Stefan Claas <spam.trap.mailing.lists@gmail.com> wrote:
> On Fri, Jan 15, 2021 at 2:04 AM raf via Gnupg-users
> <gnupg-users@gnupg.org> wrote:
>
> [...]
>
> > I'm really not an expert, and the above might not make
> > any sense. I'm just thinking aloud.
>
> Me neither ... :-) For me, the questions I had is still unresolved
> when it comes to properly explaing what security implication
> it gives, when for example sequoia-pgp can handle this and
> why the draft explicity says it MUST use the advanced-method
> first.
>
> Don't you think when GitHub, a major player, would have an invalid
> SSL cert, that maybe one of the millions programmers there would not
> have contacted GitHub, like I did, and say hey GithHub you serve
> the global community and visitors an invalid SSL certificate?
I would. But that doesn't seem to have happened. I can
only assume that github.io users aren't making much
using sub-sub-domains of their sub-domains, or if they
are, then they are not using TLS with those
sub-sub-domains, so the invalid certificate isn't
causing them any issues.
Github could probably create valid wildcard
certificates for sub-sub-domains (now that letsencrypt
supports wildcard certificates), but it seems that they
only have one certificate that covers their domains and
sub-domains, but they then hand them out for
sub-sub-domains as well. That is very odd behaviour on
their part. They must know that that is an invalid use
of their certificate. They are very clever people.
> I must admit that I also do not understand what you
> mean with sus-sub domains.
It's sub-sub-domain, not sus-sub-domain. Sorry if I
mistyped it.
The "sub-domain" is the sub-domain of github.io, e.g.:
sac001.github.io
The "sub-sub-domain" is the sub-domain of a sub-domain, e.g.:
openpgpkey.sac001.github.io
Github's web server is handing out the same certificate
for both your sub-domain and your sub-sub-domain, even
though it is not valid for your sub-sub-domain. It is
only valid for the following hostnames which includes
your sub-domain (but not your sub-sub-domain):
www.github.com
*.github.com
github.com
*.github.io
github.io
*.githubusercontent.com
githubusercontent.com
You can see this for yourself in Firefox, by going to
https://sac001.github.io/, clicking on the padlock,
then clicking on the right "arrow" to the right of
"Connection secure", then clicking on "More
information".
Github's web server should really just hand out this
certificate for hostnames that are covered by it, but
instead, they hand it out for sub-sub-domains that are
not covered by it.
The best solution would be for github, when handing out
sub-domains, to register a letsencrypt wildcard
certificate for that sub-domain's sub-sub-domains. In
your sub-domain's case, such a certificate would cover:
*.sac001.github.io.
But there is no certificate that covers that sub-sub-domain.
That's why browsers complain if you go to
https://openpgpkey.sac001.github.io/. I think that letsencrypt didn't originally support
wildcard certificates. That might have something to do
with what github are doing. But they do support them
now, so this could be fixed by github. But there might
have to be a reasonable number of users asking for it,
for that to happen. It would take some effort on
github's part to fix this, and there's probably no
money in it for them.
> My GitHub page is sac001.github.io and not foo.bar.github.io
> or whatever.
Yes, but openpgpkey.sac001.github.io is a
sub-sub-domain and it is instrumental in the advanced
method. When a WKD client attempts to fetch a key for
stefan@sac001.github.io, they try to resolve that
sub-sub-domain, and the DNS resolution succeeds, and
the webserver hands out a certificate for that domain
which happens to be invalid.
> If Werner had told me/us, hey look, according to my draft
> the advanced method MUST been used because of this and that
> security implication and it is not allowed in this case to fall back
> if an (for WKD) invalid cert is present, because of this/that security
> issue, I guess then I had a better understanding and then I guess
> also the sequoia team would never had done it so that it works
> with sequoia-pgp.
I think that's exactly what this part of the draft is saying:
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.
It just doesn't include the background rationale for
the algorithm in amongst the algorithm. That's probably
discussed elsewhere. But I haven't read the draft. I'm
just copying and pasting from an earlier message in
this thread. Perhaps the rationale is in the draft or
other related documents.
I agree that, whenever instructing someone to do
something, it's a great idea to explain why they need
to do it, if only because it has been shown to
dramatically increase acceptance of the instructions,
but that has to be balanced against the readability of
a document, and the needs of its intended audience.
Writing is hard. It's very difficult for any single
document to satisfy all the needs of all possible
audiences. There have been 11 versions of the draft so
far. I expect that if the rationale isn't in the draft
itself, it has probably been discussed in IETF or GnuPG
forums.
> Regards
> Stefan
cheers,
raf
_______________________________________________
Gnupg-users mailing list
Gnupg-users@gnupg.org
http://lists.gnupg.org/mailman/listinfo/gnupg-users
