Re: [Uri-review] ssh URI

David Booth <david@dbooth.org> Tue, 13 October 2009 04:20 UTC

Return-Path: <david@dbooth.org>
X-Original-To: uri-review@core3.amsl.com
Delivered-To: uri-review@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66F463A6A1D for <uri-review@core3.amsl.com>; Mon, 12 Oct 2009 21:20:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.463
X-Spam-Level:
X-Spam-Status: No, score=-3.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeX3NYFjdT7v for <uri-review@core3.amsl.com>; Mon, 12 Oct 2009 21:20:38 -0700 (PDT)
Received: from relay03.pair.com (relay03.pair.com [209.68.5.17]) by core3.amsl.com (Postfix) with SMTP id 1F1503A68A2 for <uri-review@ietf.org>; Mon, 12 Oct 2009 21:20:38 -0700 (PDT)
Received: (qmail 34889 invoked from network); 13 Oct 2009 04:20:37 -0000
Received: from 209.6.102.232 (HELO ?192.168.7.2?) (209.6.102.232) by relay03.pair.com with SMTP; 13 Oct 2009 04:20:37 -0000
X-pair-Authenticated: 209.197.102.232
From: David Booth <david@dbooth.org>
To: Conrad Parker <conrad@annodex.net>
In-Reply-To: <dba6c0830910122035t79122212qb9fa3d1ea38ab909@mail.gmail.com>
References: <20091009160149.GB16908@braingia.org> <1255366894.5481.8445.camel@dbooth-laptop> <5EAB4D387A4A4B7C854FBD1869729771@POCZTOWIEC> <1255395156.5481.10083.camel@dbooth-laptop> <dba6c0830910122035t79122212qb9fa3d1ea38ab909@mail.gmail.com>
Content-Type: text/plain
Date: Tue, 13 Oct 2009 00:20:36 -0400
Message-Id: <1255407636.5481.10775.camel@dbooth-laptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.26.1
Content-Transfer-Encoding: 7bit
Cc: uri-review@ietf.org, uri@w3.org
Subject: Re: [Uri-review] ssh URI
X-BeenThere: uri-review@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Proposed URI Schemes <uri-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/uri-review>
List-Post: <mailto:uri-review@ietf.org>
List-Help: <mailto:uri-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/uri-review>, <mailto:uri-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 Oct 2009 04:20:39 -0000

On Tue, 2009-10-13 at 12:35 +0900, Conrad Parker wrote:
> 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?

It wouldn't be a random web site, it would be the official web site of
SSH URIs!  That's no more random than mozilla.com or adobe.com, from
which software is routinely downloaded thousands of times a day.

> 
> No, this does not make sense. It encourages use of untrusted ssh
> client software (eg. not sourced from your operating system vendor,

That's a policy choice that should not be baked into the technical
design.  Making the software more difficult to obtain is a minus, not a
plus.

> unsigned etc.) 

Any such software certainly could and should be signed.

> so the scheme could be easily exploited by a third
> party to serve an ssh client with a backdoor. 

That's no different than access to *any* web site.  *Any* site can try
to serve up a trojan horse.  But that doesn't mean that there isn't
value in visiting web sites and value in making information and software
more readily available with existing mechanisms.

David Booth


> 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.
> 
> 
-- 
David Booth, Ph.D.
Cleveland Clinic (contractor)

Opinions expressed herein are those of the author and do not necessarily
reflect those of Cleveland Clinic.