Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 25 Aug 2008 10:29:03 -0700
From:      Michael Sinatra <michael@rancid.berkeley.edu>
To:        FreeBSD-gnats-submit@FreeBSD.org, freebsd-amd64@FreeBSD.org
Subject:   Re: amd64/126693: DNSSEC cryptographic validation doesn't work on amd64	(openssl problem)
Message-ID:  <48B2EBDF.8070701@rancid.berkeley.edu>
In-Reply-To: <200808201935.m7KJZnht037533@malcolm.berkeley.edu>
References:  <200808201935.m7KJZnht037533@malcolm.berkeley.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
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?48B2EBDF.8070701>