Issue with setting ciphers in Stubby 0.3.0

[ArchangeGabriel]

My stubby fails like this since updating (to GetDNS 1.6.0 and Stubby 0.3.0):

[22:21:04.981439] STUBBY: --- SETUP(TLS): : This version of OpenSSL does not support configuring cipher suites
Could not schedule query: The library did not have the requested API feature implemented.

But it works with Stubby 0.2.6 + GetDNS 1.5.2.

[rampageX]

Same here.

[wtoorop]

Thanks for reporting. Something to fix quickly!

[ArchangeGabriel]

It also works for Stubby 0.2.6 + GetDNS 1.6.0. This does not rule out a change in GetDNS, but it’s at least a change in Stubby.

EDIT: Scratch that. I had built Stubby against GetDNS 1.6.0, but ran it against GetDNS 1.5.2… So Stubby 0.2.6 + GetDNS 1.6.0 does not work, so the issue is rather on GetDNS side.

[ArchangeGabriel]

Stubby 0.3.0 + GetDNS 1.5.2 works. So I would say this is indeed on GetDNS side.

[hanvinke]

Had this too. There was a leftover .so from getdns which I removed and then rebuilded. Stubby 0.3.0 and getDNS 1.6.0 worked after that.

[ArchangeGabriel]

@hanvinke Are you sure of that? Because I’m doing clean builds in a chroot, so a leftover .so is not possible in my case.

I’ll retry ASAP just in case…

[hanvinke]

ARCH-PC% stubby -i
[05:55:36.353545] STUBBY: Stubby version: Stubby 0.3.0
[05:55:36.354122] STUBBY: Read config from file /etc/stubby/stubby.yml
{
  "all_context":
  {
    "add_warning_for_bad_dns": GETDNS_EXTENSION_FALSE,
    "appdata_dir": <bindata of "/var/cache/stubby/">,
    "append_name": GETDNS_APPEND_NAME_TO_SINGLE_LABEL_FIRST,
    "dns_transport_list":
    [
      GETDNS_TRANSPORT_TLS
    ],
    "dnssec": GETDNS_EXTENSION_TRUE,
    "dnssec_allowed_skew": 0,
    "dnssec_return_all_statuses": GETDNS_EXTENSION_FALSE,
    "dnssec_return_full_validation_chain": GETDNS_EXTENSION_FALSE,
    "dnssec_return_only_secure": GETDNS_EXTENSION_FALSE,
    "dnssec_return_status": GETDNS_EXTENSION_FALSE,
    "dnssec_return_validation_chain": GETDNS_EXTENSION_FALSE,
    "dnssec_roadblock_avoidance": GETDNS_EXTENSION_FALSE,
    "edns_client_subnet_private": 1,
    "edns_cookies": GETDNS_EXTENSION_FALSE,
    "edns_do_bit": 0,
    "edns_extended_rcode": 0,
    "edns_version": 0,
    "follow_redirects": GETDNS_REDIRECTS_FOLLOW,
    "hosts": <bindata of "/etc/hosts">,
    "idle_timeout": 10000,
    "limit_outstanding_queries": 0,
    "max_backoff_value": 1000,
    "namespaces":
    [
      GETDNS_NAMESPACE_LOCALNAMES,
      GETDNS_NAMESPACE_DNS
    ],
    "resolution_type": GETDNS_RESOLUTION_STUB,
    "resolvconf": <bindata of "/etc/resolv.conf">,
    "return_both_v4_and_v6": GETDNS_EXTENSION_FALSE,
    "return_call_reporting": GETDNS_EXTENSION_FALSE,
    "round_robin_upstreams": 1,
    "specify_class": 1,
    "suffix": [],
    "timeout": 5000,
    "tls_authentication": GETDNS_AUTHENTICATION_REQUIRED,
    "tls_backoff_time": 3600,
    "tls_cipher_list": <bindata of "+ECDHE-RSA:+ECDHE-ECDSA:+AEAD">,
    "tls_ciphersuites": <bindata of "+AES-256-GCM:+AES-128-GCM:+CHACH"...>,
    "tls_connection_retries": 2,
    "tls_min_version": GETDNS_TLS1_2,
    "tls_query_padding_blocksize": 128,
    "trust_anchors_backoff_time": 2500,
    "trust_anchors_url": <bindata of "http://data.iana.org/root-anchor"...>,
    "trust_anchors_verify_CA": <bindata of 0x2d2d2d2d2d424547494e204345525449...>,
    "trust_anchors_verify_email": <bindata of "dnssec@iana.org">,
    "upstream_recursive_servers":
    [
      {
        "address_data": <bindata for 145.100.185.15>,
        "address_type": <bindata of "IPv4">,
        "tls_auth_name": <bindata of "dnsovertls.sinodun.com">,
        "tls_pubkey_pinset":
        [
          {
            "digest": <bindata of "sha256">,
            "value": <bindata of 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=>
          }
        ]
      },
      {
        "address_data": <bindata for 145.100.185.16>,
        "address_type": <bindata of "IPv4">,
        "tls_auth_name": <bindata of "dnsovertls1.sinodun.com">,
        "tls_pubkey_pinset":
        [
          {
            "digest": <bindata of "sha256">,
            "value": <bindata of cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=>
          }
        ]
      },
      {
        "address_data": <bindata for 185.49.141.37>,
        "address_type": <bindata of "IPv4">,
        "tls_auth_name": <bindata of "getdnsapi.net">,
        "tls_pubkey_pinset":
        [
          {
            "digest": <bindata of "sha256">,
            "value": <bindata of foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=>
          }
        ]
      },
      {
        "address_data": <bindata for 2001:610:1:40ba:145:100:185:15>,
        "address_type": <bindata of "IPv6">,
        "tls_auth_name": <bindata of "dnsovertls.sinodun.com">,
        "tls_pubkey_pinset":
        [
          {
            "digest": <bindata of "sha256">,
            "value": <bindata of 62lKu9HsDVbyiPenApnc4sfmSYTHOVfFgL3pyB+cBL4=>
          }
        ]
      },
      {
        "address_data": <bindata for 2001:610:1:40ba:145:100:185:16>,
        "address_type": <bindata of "IPv6">,
        "tls_auth_name": <bindata of "dnsovertls1.sinodun.com">,
        "tls_pubkey_pinset":
        [
          {
            "digest": <bindata of "sha256">,
            "value": <bindata of cE2ecALeE5B+urJhDrJlVFmf38cJLAvqekONvjvpqUA=>
          }
        ]
      },
      {
        "address_data": <bindata for 2a04:b900:0:100::38>,
        "address_type": <bindata of "IPv6">,
        "tls_auth_name": <bindata of "getdnsapi.net">,
        "tls_pubkey_pinset":
        [
          {
            "digest": <bindata of "sha256">,
            "value": <bindata of foxZRnIh9gZpWnl+zEiKa0EJ2rdCGroMWm02gaxSc9Q=>
          }
        ]
      }
    ]
  },
  "api_version_number": 132058112,
  "api_version_string": <bindata of "December 2015">,
  "compilation_comment": <bindata of "getdns 1.6.0 configured on 2020-"...>,
  "default_hosts_location": <bindata of "/etc/hosts">,
  "default_resolvconf_location": <bindata of "/etc/resolv.conf">,
  "default_trust_anchor_location": <bindata of "/usr/local/etc/unbound/getdns-ro"...>,
  "gnutls_version_number": 198157,
  "gnutls_version_string": <bindata of "3.6.13">,
  "implementation_string": <bindata of "https://getdnsapi.net">,
  "listen_addresses":
  [
     <bindata of 0x7f000001>,
     <bindata of 0x00000000000000000000000000000001>
  ],
  "resolution_type": GETDNS_RESOLUTION_STUB,
  "version_number": 17170432,
  "version_string": <bindata of "1.6.0">
}
Result: Config file syntax is valid.
ARCH-PC% 

[hanvinke]

Sorry, will put that in a txt file above. Maybe you are right about the cause. Might be it is in the building options. I can see that I also forgot to change the default location of the trust-anchor file. Which options did you set for the cmake?

[hanvinke]

I see that I probably use gnuTLS, I thought I left that out when building. Will build again later, sorry!

[hanvinke]

I have rebuild with openSSL and also do not have errors.

● stubby.service - stubby DNS resolver Loaded: loaded (/usr/lib/systemd/system/stubby.service; enabled; vendor preset: disabled) Active: active (running) since Wed 2020-05-13 16:18:08 CEST; 8s ago TriggeredBy: ● stubby.socket Main PID: 16382 (stubby) Tasks: 1 (limit: 19089) Memory: 1.4M CGroup: /system.slice/stubby.service └─16382 /usr/bin/stubby -v 7

mei 13 16:18:08 ARCH-PC systemd[1]: Started stubby DNS resolver. mei 13 16:18:08 ARCH-PC stubby[16382]: [14:18:08.821081] STUBBY: Stubby version: Stubby 0.3.0 mei 13 16:18:08 ARCH-PC stubby[16382]: [14:18:08.822689] STUBBY: Read config from file /etc/stubby/stubby.yml mei 13 16:18:08 ARCH-PC stubby[16382]: [14:18:08.822877] STUBBY: DNSSEC Validation is ON mei 13 16:18:08 ARCH-PC stubby[16382]: [14:18:08.822883] STUBBY: Transport list is: mei 13 16:18:08 ARCH-PC stubby[16382]: [14:18:08.822885] STUBBY: - TLS mei 13 16:18:08 ARCH-PC stubby[16382]: [14:18:08.822888] STUBBY: Privacy Usage Profile is Strict (Authentication required) mei 13 16:18:08 ARCH-PC stubby[16382]: [14:18:08.822891] STUBBY: (NOTE a Strict Profile only applies when TLS is the ONLY transport!!) mei 13 16:18:08 ARCH-PC stubby[16382]: [14:18:08.822893] STUBBY: Starting DAEMON....

stubby-i.TXT cmake.TXT

When testing I noticed a strange behavior. With the setting dnssec: GETDNS_EXTENSION_TRUE in stubby.yml I get a score of 20% on internet.nl. ( Moderne adressen niet bereikbaar (IPv6) Gezakt : Domein-handtekeningen niet gecontroleerd (DNSSEC) ). When I also add: dnssec_return_validation_chain: GETDNS_EXTENSION_TRUE to it then I suddenly get a 100% score. It seems that certain websites/servers truly need this extra option to detect ipv6 and dnssec at all. Will check if this is the case on Windows also.

//Edit: Rebuilded again with openSSL but this time with addition of some debugging: Reason: it seems there is a problem with the fetching of the trust anchor files (Zero configuration DNSSEC). journalctl shows many "Could not get trusted keys for validating www....., etc." Correction: Zero configuration DNS works, but only when it doesn't find "/etc/trusted-key.key". It seems building with -DPATH_TRUST_ANCHOR_FILE:STRING=/etc/trusted-key.key overrides the setting in stubby.yml.

[hanvinke]

However: very convenient (re)building!

[hanvinke]

@ArchangeGabriel @rampageX Did you figure out the problem of the error? TLSv1.3 does not support cipher suites from previous TLS protocol versions. Maybe you added 'tls_cipher_list' to your build?

[jonathanunderwood]

Users are reporting seeing this problem on OpenWrt when using stubby 0.3.0 and getdns 1.6.0, but not when using stubby 0.3.0 and getdns 1.5.2. Furthermore, the problem only manifests when tls_ciphersuites is set in the stubby config.

The code block here in tls.c suggests that the error is arising because getdns has been compiled with HAVE_SSL_CTX_SET_CIPHERSUITES not defined. That suggests that CMake is failing to detect the presence of SSL_CTX_set_ciphersuites in the OpenSSL library at compile time - see here in CMakeLists.txt.

[hanvinke]

Could it be that the difference is not necessarily between GetDNS 1.5.2 and 1.6.0 but rather between Autotools/CMake? I don't know if it is related to this issue but when I run CMake in debug mode I get some warnings:

"_Policy CMP0102 is not set: The variable named "LIBIDN2_LIBRARIES" is not in the cache. This results in an empty cache entry which is no longer created when policy CMP0102 is set to NEW. Run "cmake --help-policy CMP0102" for policy details. Use the cmakepolicy command to set the policy and suppress this warning." etc.

The end result is that the policies are not being set for the libraries. So either the policies should be set individually by f.i.:

_if (POLICY CMP0102) cmakepolicy(SET CMP0102 OLD) endif ()

or by CMake versions with:

_cmakepolicy(VERSION [...])

[jonathanunderwood]

Could it be that the difference is not necessarily between GetDNS 1.5.2 and 1.6.0 but rather between Autotools/CMake?

Yes, agreed; that's the point I'm making in https://github.com/getdnsapi/stubby/issues/240#issuecomment-663661744 above.

[saradickinson]

@wtoorop candidate for the getdns 1.6.1 release

[supersebbo]

Hi all.

Experienced this for the first time today after upgrading GetDNS on OpenWRT. I understand there are two workarounds - either falling back to GetDNS 1.5.2 or commenting out any cipher suite settings in Stubby config.

What is the 'fix' however to get cipher suite selection working with GetDNS 1.6.0 on OpenWRT? I only loosely understand the comments by @jonathanunderwood and @hanvinke. Is this something that can be done at compile time in OpenWRT's build system, or do I have to wait for 1.6.1?

[hanvinke]

@jonathanunderwood

It seems that in "/src/context.c" something is missing:

static char const * const _getdns_default_tls_cipher_list = "EECDH+AESGCM:EECDH+CHACHA20";

static char const * const _getdns_default_tls_ciphersuites = "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256";

@supersebbo I think it is up to you for the moment if you want to wait for 1.6.1.

[hanvinke]

In the hope that I can still contribute to this issue....

openssl ciphers -ciphersuites val "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:TLS_AES_128_CCM_SHA256"

returns the following error:

Error setting TLSv1.3 ciphersuites 139647191721344:error:1426E0B9:SSL routines:ciphersuite_cb:no cipher match:ssl/ssl_ciph.c:1294:

Then I found this https://docs.python.org/3.8/library/ssl.html#tls-1-3

..The new protocol behaves slightly differently than previous version of TLS/SSL. Some new TLS 1.3 features are not yet available. TLS 1.3 uses a disjunct set of cipher suites. All AES-GCM and ChaCha20 cipher suites are enabled by default. The method SSLContext.set_ciphers() cannot enable or disable any TLS 1.3 ciphers yet, but SSLContext.get_ciphers() returns them.

By any chance did you maybe use the method SSLContext.set_ciphers() ?

[jonathanunderwood]

I believe this can now be closed.

[ArchangeGabriel]

I’d prefer a 1.6.1 release to be out first, so that this fix (as well as symbol export, library names, etc.) is generally available before making this issue “hidden” for quick searches.