IPv6 and gemini

[Sean Conner]

It was thus said that the Great solderpunk once stated:
> I would like to hope that it won't be *too* much longer before 4 just
> kind of happens because networking libraries will have gotten to the
> point where you have to actively go out of your way to write IPv4-only
> code.
> 
> Sorry that the Zaibatsu is doing a bad job of leading by example on
> this front!  I was fully prepared to accept the blame for this, since
> the gegobi server was thrown togeher over a few evenings and I just
> didn't think about IPv6.  I thought I'd quickly patch it to support
> serving on both IP versions at once before making this post, but...
> 
> ...it turns out the quick and easy TCP server utilities in Python's
> socketserver module are (still, in 2019 for crying out loud)
> hard-coded to only work with IPv4.  So it's not a quick patch, but a
> slightly larger project. :(   Maybe I was a bit optimistic in my first
> paragraph.

  Sad.  It's not that hard to support IPv6.  In C, just by calling
getaddrinfo() you can get both IPv4 and IPv6 addresses for a hostname (and
it supports parsing IP addresses of either family), and socket(), bind(),
listen(), connect(), etc. all support IPv6.

> Since starting the Gemini project, this is the second time I've felt
> disappointed in Python's standard library, which is a rare thing.  At
> gemini://mozz.us/journal/2019-08-21.txt, Michael writes about how the
> ssl module can't accept a self-signed client certificate.  Even worse
> than that, while it's possible to accept self-signed server
> certificates, you can't get direct access to the details of that
> certificate (like, say, the validity start and expiry dates).  With
> CA-validated certificates you can easily get this data.  If the cert
> is self-signed, you can only get an x509 encoded representation of the
> cert - and there's nothing in the standard library to decode it!  The
> ssl module really does seem to be designed to let people who don't
> understand TLS very thoroughly write HTTPS stuff without shooting
> themselves in the foot (the docs even talk explicitly about "Web
> servers" instead of just "servers"!).  And, of course, I understand
> why it's useful for a library with that kind of interface to exist.

  I suspect this was done intentionall to disuade people from using
self-signed certificates because dragons.  Or hackers.  Or something.  Maybe
people can't validate certificates properly.  

> Any way, perhaps the most interesting thing to come out of this
> conversation is the matter of using URLs with IP addresses instead of
> hostnames as Gemini requests.  I'd guess a lot of existing servers
> don't handle this well.  

  Remove the TLS restriction, and it's not a problem at all.  The problem is
that during the TLS negotiation, the hostname of the server you are
connecting to is sent [1] as part of the protocol.  There is a way to
extract which server is being referenced and thus, you can figure out which
set of files (or handlers) to serve the request from.

> And, as mentioned, in the case of
> hostname-based virtual servers, it's not entirely clear what handling
> this well even means.  I wonder if it's worth explicitly disallowing
> such requests?

  If you get foo.example.com as the host, service the request against this
set of content (subdirectory, etc); if bar.example.com, out of that set of
content.  That's all it really means.  The problem is getting the
information from TLS.

  -spc

[1]	In my Lua wrapper for TLS, I have a function to connect to an
	endpoint using an address, and it's signature is:

		ios = tcp.connecta(addr,hostname,to,config)

	(the last two parameters are optional).  You *have* to include a
	hostname.  libtls won't work without it.