Bug 663 - [unbound-control] ssl handhake is done regardless control-use-cert option or when unix socket is used
[unbound-control] ssl handhake is done regardless control-use-cert option or ...
Status: RESOLVED FIXED
Product: unbound
Classification: Unclassified
Component: server
1.5.2
x86_64 OpenBSD
: P5 normal
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-04-10 15:26 CEST by jirib
Modified: 2015-04-10 15:57 CEST (History)
2 users (show)

See Also:


Attachments
ktrace unbound-control stats (409.48 KB, text/plain)
2015-04-10 15:26 CEST, jirib
Details

Note You need to log in before you can comment on or make changes to this bug.
Description jirib 2015-04-10 15:26:53 CEST
Created attachment 276 [details]
ktrace unbound-control stats

ssl handhake is done regardless control-use-cert option or when unix socket is used.

os: openbsd 5.7 amd64
unbound: 1.5.2 (in 1.5.3 there is no bugfix in this area according to release notes)

~~~
remote-control:
        control-enable: yes
        control-use-cert: no
        control-interface: /var/run/unbound.sock
~~~

~~~
# unbound-control stats                                                                                                                                                                                            
error: SSL handshake failed
18318440116092:error:1408D06E:SSL routines:SSL3_GET_KEY_EXCHANGE:bad dh p length:/usr/src/lib/libssl/ssl/../../libssl/src/ssl/s3_clnt.c:1256:
~~~

unbound uses that unix socket:

~~~
# fstat -p `pgrep unbound` | egrep 'unix stream [[:alnum:]]+$' 
_unbound unbound    15621    7* unix stream 0xffff8000007d9200
# netstat -anlf unix | grep 0xffff8000007d9200                                                                                                                                                                     
0xffff8000007d9200 stream      0      0 0xffffff0065e56968                0x0                0x0                0x0 /var/run/unbound.sock
~~~

ktrace in attachment.

j.
Comment 1 Wouter Wijngaards 2015-04-10 15:33:21 CEST
Hi Jirib,

The handshake uses a fixed DH I think, because plaintext is not permitted, and it is code-wise useful to keep using the SSL encapsulation.

Somehow this 'DH to be able to use the codepath' is failing?

daemon/remote.c line 142 says it used openssl dhparam -dsaparam -C 512 to generate it?

Best regards, Wouter
Comment 2 jirib 2015-04-10 15:35:17 CEST
Well I'd like to use unix socket, that should be without ssl handshake. using unix socket was introduced in 1.5.2 so how this supposed to be working?
Comment 3 Wouter Wijngaards 2015-04-10 15:37:31 CEST
Hi Jirib,

Yes it is supposed to work with a fixed DH exchange variable, and then it uses the local socket with the ssl-library still wrapping transport, so that it is the same code as is used otherwise.

So, it should just be working like you configured it.

But you get an error:
bad dh p length
Does this mean that your openssl (what openssl are you using?) is somehow not accepting the dh stuff that unbound is trying to do?

Best regards, Wouter
Comment 4 jirib 2015-04-10 15:47:55 CEST
OpenBSD uses it's own fork of OpenSSL called LibreSSL.

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libssl/
Comment 5 Wouter Wijngaards 2015-04-10 15:52:16 CEST
Hi Jirib,

Yes, I think this commit is causing the problem:

Revision 1.108 / (download) - annotate - [select for diffs], Sun Mar 8 16:48:47 2015 UTC (4 weeks, 4 days ago) by miod
Branch: MAIN
CVS Tags: OPENBSD_5_7_BASE, OPENBSD_5_7
Changes since 1.107: +12 -1 lines
Diff to previous 1.107 (colored)

Reject DH keys sent by a server if they are considered too small; inspired
by a similar BoringSSL change, but raising the limit to 1024 bits.
ok jsing@ markus@ guenther@ deraadt@

I'll see about upgrading it to 1024 bits.

Best regards, Wouter
Comment 6 Wouter Wijngaards 2015-04-10 15:57:47 CEST
Hi Jirib,

In the svn repo there is a fix that uses a 1024bit DH.  Thank you for reporting it!  I am sorry for the confusing SSL errors when you thought SSL was not in use and we just wanted to wrap traffic in SSL to use the same codepath.

Best regards, Wouter