- From: Conrad Parker <conrad@annodex.net>
- Date: Tue, 13 Oct 2009 12:35:25 +0900
- To: David Booth <david@dbooth.org>
- Cc: uri-review@ietf.org, uri@w3.org
2009/10/13 David Booth <david@dbooth.org>: > > I was referring to the adoption rate for clients (such as browsers) > recognizing these new SSH URIs and using them for their intended > purpose. A browser encountering a URI beginning "ssh:..." will not be > able to do anything useful with it until it knows the special semantics > assigned to the "ssh:" prefix. But a browser encountering a URI > beginning "https://sshuri.org/..." could try to dereference that URI and > could be led to software that, once installed, *would* know to open an > SSH connection when encountering such a URI. This could dramatically > improve the rate at which browsers learn how to handle these SSH URIs. > Make sense? Encouraging end-users to download ssh client software from a random web site specified by a third-party web-page author, and then (automatically) using that software to connect to the desired ssh server ... and hoping that this is somehow secure by using an SSL/TLS connection to access that software? No, this does not make sense. It encourages use of untrusted ssh client software (eg. not sourced from your operating system vendor, unsigned etc.) so the scheme could be easily exploited by a third party to serve an ssh client with a backdoor. Using https to access that info/software does nothing to secure the initiation of the ssh connection. If anything, ssh provides a good use-case for a custom uri scheme. Conrad.
Received on Tuesday, 13 October 2009 07:22:48 UTC