From owner-freebsd-hackers@freebsd.org Wed Oct 5 14:30:27 2016 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A16D3AF6A72 for ; Wed, 5 Oct 2016 14:30:27 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from mx1.scaleengine.net (mx1.scaleengine.net [209.51.186.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 84DC732D for ; Wed, 5 Oct 2016 14:30:27 +0000 (UTC) (envelope-from allanjude@freebsd.org) Received: from [10.1.1.2] (unknown [10.1.1.2]) (Authenticated sender: allanjude.freebsd@scaleengine.com) by mx1.scaleengine.net (Postfix) with ESMTPSA id 45F4E1182B for ; Wed, 5 Oct 2016 14:30:20 +0000 (UTC) Subject: Re: Reported version numbers of base openssl and sshd To: freebsd-hackers@freebsd.org References: <01eb01d21e52$4a7f1640$df7d42c0$@net> <86oa2z9un2.fsf@desk.des.no> <0ee9d33e-9be2-4fd7-abc2-2285cc4bd4a2@typeapp.com> <86k2dn9cxr.fsf@desk.des.no> <704AE3714816467C93438DCD1A7E2620@PCNEDIT1> From: Allan Jude Message-ID: <884f33d9-e479-9294-fc9d-2a6f4d228e10@freebsd.org> Date: Wed, 5 Oct 2016 10:30:20 -0400 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <704AE3714816467C93438DCD1A7E2620@PCNEDIT1> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 14:30:27 -0000 On 2016-10-05 09:28, peter@purplecat.net wrote: > Dag-Erling, > > No doubt the scanners themselves are at primary fault, and we push back > on them vigorously, typically recommending our customers change scanning > companies for the worst cases, but this of course creates a lot of > work. In some instances our answer has simply been to firewall off > their scanning servers, which laughably results in a 'pass' from the pci > compliance/audit monkeys. > > You are of course completely right about RHEL...And FreeBSD is so > superior in so many ways, it's not even a question--but having proper > version numbers reported would eliminate a lot of headaches for us (and > give FreeBSD another plus). > > We would very much prefer ~not~ to display version information at all. > Having that as a variable in a configuration file would be a plus. > Perhaps one that defaults to actual versions running, with the ability > to report "non of your business." In the case of ssh, part of this is already controlled by a variable in /etc/ssh/sshd_config VersionAddendum FreeBSD-20140420 If you want to control the rest, you'd need to ask the upstream openssh project. They use the version number information in the banner message to enable compatibility tweaks. > > Thanks for all you do for FreeBSD and its community. > > > Sincerely, > > Peter Brezny > Purplecat Networks, Inc. > www.purplecat.net > 828-250-9446 > > > ... > -----Original Message----- From: Dag-Erling Smørgrav > Sent: Wednesday, October 5, 2016 8:51 AM > To: Roger Eddins > Cc: freebsd-hackers@freebsd.org > Subject: Re: Reported version numbers of base openssl and sshd > > Roger Eddins writes: >> [...] Across the board we are finding other processes in commerce >> tools rejecting transactions due to version number deficiencies and >> the problem is growing rapidly. My hope would be that the team would >> reconsider the version number question as it is the biggest deficiency >> we experience daily using the FreeBSD OS. > > Once again: how do they handle RHEL? Because Red Hat, the 800-pound > gorilla of the Open Source world, does the same thing that we do: > backport patches without bumping the version number. And in fact, they > do *less* than we do, because for OpenSSL and OpenSSH, we havea version > suffixes which should reflect the date of the last patch, so even an > automated scanner *can* be taught to distinguish a vulnerable machine > from a patched one - as long as secteam remembers to bump the suffix > when they patch the software. > > DES -- Allan Jude