Re: TLS in Gopher
Greetings.
Thanks for all the input. I rethought my proposel. For finding a solu‐
tion we can all agree on RFC 1436, which says:
> Equally important, clients do not
> have to be modified to take advantage of a new resource.
This gave me the idea that we should see this from the user/client point
of view, which begins at the URI. With gopher:// the one writing the URI
defines the menu type the way the client should interpret the content
given back. The same could apply for gophers://.
To see my new proposal below keep in mind the two main goals we should
have in gopher:
* Keep the compatibility to the old gopher.
* Allow a simple implementation on really old hardware, which is not able
to run TLS.
## Proposal
I propose that we should introduce »gophers://« schema which tells the
client to use »secure mode« for digging through gopherspace. Clients
might introduce some parameter to first try secure mode, even if »go‐
pher://« is specified as URI schema.
## What does the »secure mode« mean?
We do not need the »STARTTLS« I proposed. The simpler way is like some‐
one said to just connect using TLS. The TLS header is an invalid ASCII
selector and so any compliant server will give back an error. If this
does not succeed the client should / must not try to connect us‐
ing plain gopher. If a server supports TLS should be cached by the
client.
## Examples Of Daily Usage
# Plaintext Gopher
% sacc gopher://bitreich.org
# Secure Mode by default. [not implemented yet.]
# Sacc will try first TLS before plain gopher.
# -s can be easily set as an alias in the shell.
% sacc -s gopher://bitreich.org
# The user tells sacc to use secure mode. [not implemented yet.]
% sacc gophers://bitreich.org
For the ultra secure PKI fighters some option to enforce TLS and exit if
it is not available could be implemented too (Example):
% sacc -fs gopher://r-36.net
sacc: Server does not support TLS. Aborting.
% sacc -fs gopher://bitreich.org
sacc: bitreich.org is giving back a self-signed certificate.
[... cert details printed ...]
Do you want to accept and proceed?
[y/n] >
# After a while gophering and someone tries to attack.
% sacc -fs gopher://bitreich.org
sacc: Certificate for bitreich.org changed.
[... cert details printed ...]
Do you want to accept and proceed?
[y/n] >
## Easy Migration (Practical Example)
For bitreich.org I setup all of this without modifying geomyidae at all.
1.) Setup geomyidae to listen on port 72.
2.) Setup stunnel to listen on port 7443 and point to port 72.
With stunnel you get all options for verification and certificate han‐
dling without doubling the code in geomyidae itself.
3.) Setup sslh on port 72 to point to either port 7443 or port 72.
Here is my sslh configuration:
protocols:
(
{ name: "regex"; host: "127.0.0.1"; port: "72"; regex_patterns: [ "^\r\n$", "^\n$", "^.\n$" ]; },
{ name: "tls"; host: "127.0.0.1"; port: "7443"; },
{ name: "anyprot"; host: "127.0.0.1"; port: "72"; },
{ name: "timeout"; host: "127.0.0.1"; port: "72"; }
);
on-timeout: "timeout";
Why the regex? Sslh has some case where if something less than three
bytes is sent tls comes true. We have to handle those cases manually.
Sslh has other options like running vpn, ssh etc. on the same port to
circumvent filtering of censoring networks.
Of course all of this can be implemented in the geomyidae too, but it
should be easy, since only a check for the TLS packet like in sslh[0] is
needed.
## Conclusion
The above proposal should satisfy all use cases. There is a simple up‐
grade route and it will give the user more freedom in choosing how to
walk through gopherspace.
Enforcing pure TLS on all gopher servers is not an option, which means
fallback attacks are possible. Here the client needs to warn users, be‐
cause PKI is about user decision. You cannot trust central certificate
authorities, you only trust the certificates you know, like in SSH.
## RFC
What do you people think about this proposal?
Sincerely,
Christoph Lohmann
[0] https://github.com/yrutschle/sslh.git
Reply to: