[gopher] TLS situation in gopher [was: Re: Gophernicus 2.4

[Matt Owen (Jaruzel)]

In article <EA996E69-9296-45FB-B5F6-BBE53926F791 at holviala.com>, kim-
80HoypwBpWdWk0Htik3J/w at public.gmane.org says...
>
>Also, what should the response to STARTTLS be?
>
>C: opens TCP connection to server
>C: STARTTLS
>S: WTF OMG OMG IT'S ALIVE!!!!
>C: bzzzzz trrr trrr trrr <TLS connection with proper selector request here>
>S: Happily serving the request
>
>So what should server answer instead of WTF? Client needs to know the server 
is
>OK with the connection, and the client should probably re-request without
>STARTTLS if the server doesn't understand TLS.
>

As we don't have prefix codes like HTTP and SMTP have, the best I can think of 
is:

C: STARTTLS
S: STARTTLS OK <any extra info here, like version etc, prefixed by ':' >
C: bzzzzz trrr trrr trrr <TLS connection with proper selector request here>
S: Happily serving the request

It's incredibly unlikely that any legacy Gopher server will respond with 
'STARTTLS OK'.  

A correctly built server should return a '3' error, so the client trys again 
without the STARTTLS request. My concern on this is that it would create added 
latency before the menu or file is retrieved, on non TLS aware servers. a good 
client should remember for that session, that server X does not support TLS, 
so doesn't ask again.

I'm struggling to see a workable solution on the same port as non secure 
traffic, that doesn't break legacy clients or servers, that also encrypts on 
every request to the server (including the initial request).

So thinking afresh, I've come up with this...

At the end of the day, the client ALWAYS has to be the one to request TLS - 
having it decode a previous server menu or file response first is simply not 
secure. 

It feels like we're conflating two thing here:

1. Directing gopher clients to a secure connection for a resource.
2. Defining the TLS negotiation.

Looking at #1 - This is where we try to find a non-breaking additonal syntax 
to a selector line in a menu structure, that tells TLS aware clients to not 
only 'go secure' but to use a different port for that selector. Technically, 
we should be able to do that in the space where the Gopher+ syntax sits at the 
end of the selector line, after the port. Therefore, conceptually, where a 
Gopher plus line would end with:

... <port><TAB>+

We could use the TLS syntax (as previously suggested), like so:

... <port><TAB>TLS:<secure-port>  

This only runs the risk of breaking some badly built existing Gopher Plus 
clients, but there are very few Gopher+ clients anyway, so the impact would be 
minimal.

Legacy Gopher clients should ignore anything after <port> and just carry on 
non-securely, and TLS aware clients, will see the TLS:<secure-port> entry and 
upgrade accordingly for the request to that selector. Which brings us to #2:

The client upgrades to TLS by connecting to the <secure-port>, and then 
invoking the STARTTLS request, as per Kims suggestion. It can be assumed that 
if the server is listening on this alternative port, then it *is* TLS aware, 
and shouldn't error (but we can handle that anyway, when we define the 
protocol).

For linking into remote sites via TLS we would do:

a. For Gopher server to Gopher server, the method described in #1 above.

b. For web page to Gopher Server we do this initially:
   gophers://<host>/<selector>

TLS aware gopher clients will see the protocol is gophers:// and use the 
'standard' TLS port [1]. 

Until we define a standard TLS port, the URI scheme would be:

   gophers://<host>:<secure-port>/<selector>


These are just my thoughts on the matter, I am in no way dictating a 
direction. :)

-Matt

---
[1] And to follow up on a previous post - we should *definately* approach IANA 
to reserve a port number for GOPHER-TLS.