Date: Mon, 25 Aug 2008 17:30:04 GMT From: Michael Sinatra <michael@rancid.berkeley.edu> To: freebsd-amd64@FreeBSD.org Subject: Re: amd64/126693: DNSSEC cryptographic validation doesn't work on amd64 (openssl problem) Message-ID: <200808251730.m7PHU4kt068124@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR amd64/126693; it has been noted by GNATS.
From: Michael Sinatra <michael@rancid.berkeley.edu>
To: FreeBSD-gnats-submit@FreeBSD.org, freebsd-amd64@FreeBSD.org
Cc:
Subject: Re: amd64/126693: DNSSEC cryptographic validation doesn't work on
amd64 (openssl problem)
Date: Mon, 25 Aug 2008 10:29:03 -0700
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 <michael-pr@rancid.berkeley.edu>
>> 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:
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200808251730.m7PHU4kt068124>