-
Notifications
You must be signed in to change notification settings - Fork 2
TLS
Encryption is, arguably, the most complicated issue in the gopherverse. Everyone wants it, but no one is exactly sure how it should be done. There are various conventions out there for how a server and a client should handle encrypted connections. For me, any sort of security model for gopher that isn’t based on TLS is out of question. There have been various ideas suggested to take place of TLS but none of them are satisfactory.
Gopher over Tor is probably the only proper security model besides just TLS. It enjoys a small-scale popularity in privacy-minded circles with the URL form gopher://example.onion. This obviously necessitates having Tor up and running, and having a client that can handle connection over Tor, for instance, with a SOCKS-based implementation.
This topic has been argued to death on IRC, Fediverse and mailing lists, but I’ll try to give a summary of the ideas here.
Yes.
- Gopher protocol, predating SSL and its ilk by many years, has no way to indicate whether a link is over TLS or not.
- A separate URL scheme (such as
sgopher,gophersorgopher+tls) is mostly irrelevant, as selectors don’t denote a URL scheme within the address field. - It doesn’t help that there’s no agreed-on port for gopher over TLS. Although squatting
104(DICOM) or105(CSO pbx) seems to be common.
- A separate URL scheme (such as
- We don’t want to break the existing standard. Older clients that don’t support TLS should be able to keep navigating the gopherverse without breakage.
- Preferably, everyone should follow the same standard, so that any encrypted gopherhole can be accessed with any modern client.
In order of popularity:
A gopherhole is either using TLS or not. This means two separate links must be provided wherever (perhaps via the + type), so that the user can opt to use either cleartext or TLS. This also means that two separate ports must be served, à la HTTPS. A server might have a link to a cleartext version of the gopherhole in the root directory. A client can implement a switch to be toggled by the user before connecting and decide to try an unencrypted connection if an encrypted one fails.
gophwr implements this.
It is possible to serve both encrypted and unencrypted connections on the same port using dedicated server-side software (such as sslh that tries to guess the protocol the client is attempting connect with. Thus, a client can attempt TLS on each gopherhole it connects, and fall back to cleartext if it fails. This has the disadvantage of having the server depend on external software to determine the protocol, but makes client-side implementation easier, and allows TLS-less clients to connect to the same port.
An uncommon informal convention used by certain gopherholes is adding 100000 to the port number of the selector to indicate that it is a TLS-based connection. Since port numbers cannot exceed 65535, this means attempting to connect with a client that does not implement this convention would fail. A conformant client would recognise the port and subtract 100000 from it before connecting.
gophwr implements this.
An oft-discussed idea similar to the transparent TLS approach is to have the servers and clients implement opportunistic TLS to upgrade cleartext connection request to TLS, such as Upgrade+TLS or StartTLS. This adds overhead to both server and client implementations, but allows TLS-less clients connect to the same port, as above.
New entity types
This idea suggests creating TLS-only counterparts of existing entity types, then implementing them into new clients. This way, old clients would naturally fail to connect to the selectors, but new clients would pick up the hint and upgrade to TLS when connecting.
Another idea is making use of the unpopular Gopher+ protocol to embed TLS indication in the metadata, to clearly denote which links are encrypted and which links are not. However, older clients would be unable to tell them apart.