[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: TLS in Gopher


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

## 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:

		{ name: "regex"; host: ""; port: "72"; regex_patterns: [ "^\r\n$", "^\n$", "^.\n$" ]; },
		{ name: "tls"; host: ""; port: "7443"; },
		{ name: "anyprot"; host: ""; port: "72"; },
		{ name: "timeout"; host: ""; 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

## 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?


Christoph Lohmann

[0] https://github.com/yrutschle/sslh.git

Reply to: