True about the MITM problem. HTTPS never had to worry about backwards compatibility because since HTTP/1.0 they had an extensible protocol while gopher is stuck with the original RFC (that's why "they" won - extensibility vs. fixed tree-like structure). Also HTTP/HTML links are relative while Gopher resources are always absolute - HTTP/HTML can link to "/foo/bar.html" and not worry about the domain and the protocol (or possible TLS/SSL) while Gopher always has to link to resource + domain + port and that leaves no room for extension flags. Coming back to our problem we actually have two ways to refer to a Gopher resource: * menu resource with type, domain and port The URL scheme can easily be changed to gophers:// which tells the client that yes, this is really an TLS-enabled Gopher connection so no problem there. But once you load that menu you get a list of resources which include a domain (or IP) and a port number but there is absolutely no way of telling the client which resources should use TLS and which resources should use plaintext connections. Yes, we could decide that "port number NNN is *always* TLS but that's not portable and we don't have an offical port number. We could also decide that "since this connection to domain.dom:7777 was TLS then *all* connections to domain.dom:7777 should be TLS - but what about links to other domains? There would be no way of knowing if the client should use TLS or not, and there's no room in menus to include that information (and fiddling with menus breaks old clients). In other words, we're screwed :D - Kim
|
_______________________________________________ Gopher-Project mailing list Gopher-Project@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/gopher-project