Re: Gopher TLS support in curl

On Mon, Dec 21, 2020 at 02:50:59PM -0800, Cameron Kaiser wrote:
>I still don't understand how this can be protected against downgrade
>attacks. A malicious MITM could simply ensure that the TLS trigger byte
>was never communicated (race the packet, etc.) and both client and server
>would then assume the connection isn't TLS.

The server would, but not the client.  The client receiving some garbage 
in the response that isn't a valid Server Hello would error out and drop 
the connection.  This is no different from having HTTP server listen on 
both 80 and 443 where malicious MitM could simply redirect all the 443 
traffic to port 80.  Nothing interesting happens.  Serving both on the 
same port makes no difference to security.

You are probably thinking about opportunistic encryption where the 
client doesn't use separate URI scheme but tries TLS anyway.  Then yes, 
opportunistic encryption ever protects only against passive adversaries.
It doesn't matter if you use a separate port or not, dropping all the 
traffic to 443 isn't any harder for MtiM than stripping 250 STARTTLS 
from SMTP header.

Of course, the problem remains how to indicate that "gophers" scheme in 
the gophermap.  (The SMTP route of publishing that bit in the DNS sounds 
rather ugly to me.)

-k