Re: Gopher TLS support in curl

[Cameron Kaiser <spectre@floodgap.com>]

> > 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.

Agreed, but then the next step on the client side is to retry unencrypted,
because it may be talking to a server that just doesn't support TLS (it
doesn't have a definitive way of knowing that it shouldn't retry the link).
Otherwise how does such a client interact with servers that *don't* support
TLS, assuming it has no prior knowledge of what the server supports?

> 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.)

Also agreed, which is why the current thought I've had is to listen on 7443,
and the client needs to try that port first (and then cache the result). I'm
open to other "protocol dances" but ultimately there has to be a secure
means of service discovery.

-- 
------------------------------------ personal: http://www.cameronkaiser.com/ --
  Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckaiser@floodgap.com
-- Murphy's Law is recursive. Washing your car to make it rain doesn't work. --