TLS Cipher Suite setting ignored with TLS 1.3 #2359
Comments
|
This is only for TLS 1.0-1.2. TLS 1.3 ciphers are not configurable:
It's an intentional limitation of the language itself (or, rather, its standard library), motivated by the fact that since Go 1.17, proper cipher suite ordering is done automatically. As the vast majority of servers are now using TLS 1.3, we should probably remove this option from the documentation and example files. |
jedisct1
changed the title
|
Thanks for the fast response @jedisct1! Before closing this issue, let me check that the behavior is the expected one when working with TLS v1.2: I expect |
|
On the other hand, I think removing the option would be a "bad" idea: it is true that most of the servers are using TLS v1.3 at the moment, but there are a number of others that are using TLS I would suggest, if possible, that the available ciphers can be configurable when instructing |
|
Ok @jedisct1 I have just tested using a TLS v1.2 server on a scenario we have deployed for testing the server_names = ['RD']
max_clients = 250
user_name = '_dnscrypt-proxy'
ipv4_servers = true
ipv6_servers = true
dnscrypt_servers = true
doh_servers = true
require_dnssec = false
require_nolog = false
require_nofilter = false
force_tcp = false
timeout = 5000
keepalive = 30
lb_strategy = 'p2'
log_level = 0
use_syslog = true
cert_refresh_delay = 240
tls_cipher_suite = [5]
ignore_system_dns = true
netprobe_timeout = 60
netprobe_address = '1.1.1.1:53'
block_ipv6 = false
cloaking_rules = '/tmp/tmpNNgmiI'
cloak_ttl = 600
cache = false
[query_log]
format = 'tsv'
[nx_log]
format = 'tsv'
[sources]
[broken_implementations]
fragments_blocked = ['cisco', 'cisco-ipv6', 'cisco-familyshield', 'cisco-familyshield-ipv6', 'cleanbrowsing-adult', 'cleanbrowsing-adult-ipv6', 'cleanbrowsing-family', 'cleanbrowsing-family-ipv6', 'cleanbrowsing-security', 'cleanbrowsing-security-ipv6']
[doh_client_x509_auth]
[static]
[static.'RD']
stamp = 'sdns://AgAAAAAAAAAADDEwLjIxNS4xNjguMSBVNoNeRJCJdZ6qi7mgZRKWmBGMR5p5C-Bk7u9Ii_Ht0ApyZW1vdGUuZG5zCi9kbnMtcXVlcnk'In this case, the DNS stamp points to a server we have on a private network whose DNS is resolved by the However, when having a look at the logs, this is the output we get: I can confirm you the Is there anything that I am missing? Is the problem related to having the server manually configured and not using a resolver list? Thanks in advance |
|
In that case we should at least update the documentation. In order for the cipher suite to be used with servers that also support TLS 1.3, we would need to introduce a new option to downgrade the TLS version. That doesn't sound like a good idea. Status quo is that with TLS 1.2, the client can choose the ciphers, and that with TLS 1.3, Go chooses the fastest cipher. The option to change the cipher suite was introduced to force usage of RSA instead of ECC, because on some devices, RSA was faster in spite of the bigger signatures and keys. So maybe what we need instead is a |
|
Your "RD" server is probably using a cipher suite that is not supported by Go any more even for TLS 1.2. |
Ah no, it doesn't fail, as this is usually a client configuration error. It warns you so that you can adjust the configuration, and performs the handshake with the default suites. |
|
Oh f**k! Is there any way to fail it, if possible? We can have control over the messages that are generated, so analyze them and produce an error... But if there is any way to do it from configuration it would be better |
|
No, because some servers don't support RSA, but most people still expect things to work. Replacing the list with a |
|
Yeah, I think (for clarity) it would be better: The current naming seems to say "those are the algorithms you shall use", while it's more like: "ey, use these algorithms, and if not I don't really care" :) I think we are going to introduce some warnings and information whenever a user attempts to configure the ciphers, to let them know they are not really restricting them. Thanks for the support @jedisct1! <3 |
|
TLS 1.3 didn't exist yet when this option was introduced. |
Output of the following commands:
What is affected by this bug?
The
tls_cipher_suiteseems to be doing nothing: I have configured theTLS_RSA_WITH_RC4_128_SHAalgorithm (0x0005in hex), which should not be compatible neither withcloudflareorgooglebut the connection still works. Moreover, the used suite does not even match the one I requested.When does this occur?
When configuring the
DNSCryptservice, having a look at the journal logs, everything seems to be working fine whereas it should not.How do we replicate the issue?
Place the following configuration:
Very probably it is needed to tweak the configuration to adjust IP addresses. I am running
dnscrypt-proxyinside a VM running Debian. The version is the one available on bullseye. There is a DoH server configured for the instance too. However, I suppose it should not affect.The logs I get are:
Expected behavior (i.e. solution)
The service gets a TLS error and refuses to connect to the upstream servers. Therefore, the service fails.
Other Comments
I have tweaked the Debian service to not use the SystemD socket and therefore, behave exactly the same as a manually launched application. The service unit is:
The text was updated successfully, but these errors were encountered: