From owner-freebsd-amd64@FreeBSD.ORG Mon Aug 25 17:29:04 2008 Return-Path: Delivered-To: freebsd-amd64@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 07C531065677; Mon, 25 Aug 2008 17:29:04 +0000 (UTC) (envelope-from michael@rancid.berkeley.edu) Received: from malcolm.berkeley.edu (malcolm.Berkeley.EDU [IPv6:2607:f140:ffff:ffff::239]) by mx1.freebsd.org (Postfix) with ESMTP id D57F38FC2D; Mon, 25 Aug 2008 17:29:03 +0000 (UTC) (envelope-from michael@rancid.berkeley.edu) Received: from sonic.net.berkeley.edu (sonic.Net.Berkeley.EDU [IPv6:2607:f140:1:8000:2e0:81ff:fe2d:ee19]) (authenticated bits=0) by malcolm.berkeley.edu (8.14.2/8.13.8m1) with ESMTP id m7PHT3kN046929 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Aug 2008 10:29:03 -0700 (PDT) (envelope-from michael@rancid.berkeley.edu) Message-ID: <48B2EBDF.8070701@rancid.berkeley.edu> Date: Mon, 25 Aug 2008 10:29:03 -0700 From: Michael Sinatra User-Agent: Thunderbird 2.0.0.16 (X11/20080728) MIME-Version: 1.0 To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-amd64@FreeBSD.org References: <200808201935.m7KJZnht037533@malcolm.berkeley.edu> In-Reply-To: <200808201935.m7KJZnht037533@malcolm.berkeley.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV 0.93/7204/Wed May 21 16:39:01 2008 on malcolm.berkeley.edu X-Virus-Status: Clean X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (malcolm.berkeley.edu [IPv6:2607:f140:ffff:ffff::239]); Mon, 25 Aug 2008 10:29:03 -0700 (PDT) Cc: Subject: Re: amd64/126693: DNSSEC cryptographic validation doesn't work on amd64 (openssl problem) X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2008 17:29:04 -0000 I determined this problem to be a rather complex interaction between DNSSEC, pf configurations, and the different IP subnets that the hosts were on. After some testing, I can verify that DNSSEC validation works on 6.3-RELEASE, 8-CURRENT, and 7-STABLE, all on the amd64 platform. I'll request that this PR be closed. Sorry for the noise. michael On 08/20/08 12:35, Michael Sinatra wrote: >> Number: 126693 >> Category: amd64 >> Synopsis: DNSSEC cryptographic validation doesn't work on amd64 (openssl problem) >> Confidential: no >> Severity: non-critical >> Priority: medium >> Responsible: freebsd-amd64 >> State: open >> Quarter: >> Keywords: >> Date-Required: >> Class: sw-bug >> Submitter-Id: current-users >> Arrival-Date: Wed Aug 20 19:40:01 UTC 2008 >> Closed-Date: >> Last-Modified: >> Originator: Michael Sinatra >> Release: FreeBSD 7.0-STABLE amd64 >> Organization: > University of California, Berkeley >> Environment: > System: FreeBSD drl9.berkeley.edu 7.0-STABLE FreeBSD 7.0-STABLE #3: Thu Aug 14 09:44:49 PDT 2008 michael@drl9.berkeley.edu:/usr/obj/usr/src/sys/DRL amd64 >> Description: > > DNSSEC validation fails on FreeBSD/amd64, regardless of the DNS > server (caching resolver software being used). Attempting to use > both BIND (9.4.2-P2 and 9.5.0-P2) and unbound (1.0.2) yields errors > when DNSSEC validation is attempted. These errors do not occur > with the very same configuration on i386. The errors that occur > indicate that the digital signatures are bad; when the same > trust-anchors and queries are made on i386, they properly validate. > > This appears to be an issue with OpenSSL. Currently, all DNSSEC > signing keys that I have found are of type RSASHA1; I have therefore > not been able to test it with DSA keys. > > This issue does not occur on Gentoo Linux--both i386 and x86_64 can > run a validating connfiguration of BIND.. > > CSUP and rebuild of the system in question was done on the same day > that the kernel was built. Other systems--all rebuilt in July or > August--have also been tested with the same result. > >> How-To-Repeat: > > 1. Install stock FreeBSD/amd64 system. csup-and-rebuild to a recent > version. > > 2. Install unbound from ports. Configure to be a caching resolver. > > 3. Add the following line to /usr/local/etc/unbound/unbound.conf: > > trust-anchor: "se. DNSKEY 257 3 5 AwEAAdKc1sGsbv5jjeJ141IxNSTdR+nbtFn+JKQpvFZETaY5iMutoyWH a+jCp0TBBAzB2trGHzdi7E55FFzbeG0r+G6SJbJ4DXYSpiiELPiu0i+j Pp3C3kNwiqpPpQHWaYDS9MTQMu/QZHR/sFPbUnsK30fuQbKKkKgnADms 0aXalYUuCgDyVMjdxRLz5yzLoaSO9m5ii5cI0dQNCjexvj9M4ec6woi6 +N8v1pOmQAQ9at5Fd8A6tAxZI8tdlEUnXYgNwb8eVZEWsgXtBhoyAru7 Tzw+F6ToYq6hmKhfsT+fIhFXsYso7L4nYUqTnM4VOZgNhcTv+qVQkHfO OeJKUkNB8Qc=" > > 4. dig +dnssec se @localhost (or whatever interface unbound is listening on) > > 5. On i386, you get a validated response (with the ad bit set). On > amd64, you get a SERVFAIL. > > ALTERNATE STEPS 2-5 with BIND: > > 2. Install either bind94 or bind95 from ports. Make any necessary > mods to the config in /etc/namedb/named.conf bundled with FreeBSD > to get a basic caching resolver working. > > 3a. add the following lines to /etc/namedb/named.conf in the 'options' > section: > > dnssec-enable yes; > dnssec-validation yes; > dnssec-lookaside . trust-anchor dlv.isc.org; > > 3b. Add the following lines to the global section of /etc/namedb/named.conf: > > trusted-keys { > dlv.isc.org. 257 3 5 "BEAAAAPp1USu3BecNerrrd78zxJIslqFaJ9csRkxd9LCMzvk9Z0wFzoF kWAHMmMhWFpSLjPLX8UL6zDg85XE55hzqJKoKJndRqtncUwHkjh6zERN uymtKZSCZvkg5mG6Q9YORkcfkQD2GIRxGwx9BW7y3ZhyEf7ht/jEh01N ibG/uAhj4qkzBM6mgAhSGuaKdDdo40vMrwdv0CHJ74JYnYqU+vsTxEIw c/u+5VdA0+ZOA1+X3yk1qscxHC24ewPoiASE7XlzFqIyuKDlOcFySchT Ho/UhNyDra2uAYUH1onUa7ybtdtQclmYVavMplcay4aofVtjU9NqhCtv f/dbAtaWguDB"; > }; > > 4. dig +dnssec br @localhost (br is in the ISC DLV registry) > > 5. On i386, you get a validated response (with the ad bit set). On > amd64, the query simply times out. If you change the trusted-key > to something obviously bogus, the exact behavior on amd64 is > replicated. The debug logs show the same--the key appears to be > bad. > > It appears that cryptographic processing for RSASHA1 on amd64 just > isn't working quite right, which is why I suspect something in > OpenSSL. > >> Fix: > > The following things HAVE NOT WORKED: > > 0. Using the OpenSSL installed in the base system. > > 1. Using latest ports version of OpenSSL and linking BIND against it. > > 2. Compiling ports version of OpenSSL with -O instead of -O3 and > linking BIND against it. > > 3. Using a different version of gcc (3.3.6 and 4.4.0 both tried) > to compile OpenSSL from ports & linking BIND to that. > > 4. Compiling static ports OpenSSL libraries and statically linking > BIND against it. > > 5. Compiling ports OpenSSL with the 'no-asm' option and linking > BIND to it. > > I'll happily try other workarounds/suggestions. >> Release-Note: >> Audit-Trail: >> Unformatted: