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

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


Reply to: