💾 Archived View for gemini.ucant.org › meta › hostnames.gemini captured on 2023-03-20 at 18:05:03. Gemini links have been rewritten to link to archived content
⬅️ Previous capture (2020-09-24)
-=-=-=-=-=-=-
Currently, Gemini piggybacks off the DNS, and enforces Server Name Information
via SSL. SSL imposes strictures on how requests and servers use hostname
information; effectively, a server has to know what its name is; it cannot
just listen on all IP addresses and respond to requests.
However, Gemini it is extremely permissive about the use of self-signed
SSL certificates. This means it is licit to configure a Gemini server, and
SSL certificate, for a name which does not exist in the DNS, or which does
not resolve to the server in question. That would be fairly difficult with
the HTTPS web and LetsEncrypt, and subverts one of the purported goals of
SSL.
One of the tacit effects of SSL is to make end-to-end encryption inconvenient
if the responding endpoint has not identified itself: you can communicate
without fear of being overheard or the signal being modified, but only if
one party is prepared to apply for a certificate from some small number of
oligopolistic certificate authorities, which all require adherence to
the conventional operation of DNS.
As an alternative, since Gemini does not enforce a trust root
mandating the CAB's preferred set of certificate authorities, there
can be established a mechanism for resolving hostnames which is entirely
separate from DNS, e.g., a sort of Gossip protocol like mDNS.