From owner-freebsd-security Mon Mar 26 19:49:34 2001 Delivered-To: freebsd-security@freebsd.org Received: from mail.rpi.edu (mail-100baset.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 8496F37B71A; Mon, 26 Mar 2001 19:49:23 -0800 (PST) (envelope-from drosih@rpi.edu) Received: from [128.113.24.47] (gilead.acs.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.9.3/8.9.3) with ESMTP id WAA78210; Mon, 26 Mar 2001 22:49:21 -0500 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: Date: Mon, 26 Mar 2001 22:49:20 -0500 To: Robert Watson , Kris Kennaway From: Garance A Drosihn Subject: Re: SSHD revelaing too much information. Cc: Nate Williams , "Michael A. Dickerson" , "Duwde (Fabio V. Dias)" , freebsd-security@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 9:30 PM -0500 3/26/01, Robert Watson wrote: >OK, so I go knowingly into a heated discussion :-). And you go an ruin a good, building flame-war by bringing in facts and a reasoned analysis. Boy, what a spoil-sport... >2) Several important classes of software consumers benefit > from the explicit detailing of version information. > >A number of consumers of this banner information are present, >and they represent an important class of users. Just off the >top of my head, I can identify at least two reasons why >revealing version information is useful: One thing I was wondering is if the version information could be delayed until the user has successfully authenticated to some user on the destination host. Maybe any userid on the destination host, maybe just some specific userid(s). I think that would give the version info out to people who would have some RIGHT to know it, without leaving it out there for absolutely anyone to anonymously discover. [this delay would be an sshd configuration option, of course, so that administrators could choose the behavior they wanted] My next question is whether this version-paranoid behavior should key off some system setting (a sysctl of some sort), as perhaps there are other network-service daemons where this same issue comes up. Might as well have them all key off a single option. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message