John by default sets the TLS min version to 1_3 and the ciphers to match. Why change to 1_2?
edit: re-read previous posts after more coffee. Never mind.
but make sure ciphers are still valid with Cloudflare
[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)
- Thread starter john9527
- Start date
edit: re-read previous posts after more coffee. Never mind.
but make sure ciphers are still valid with Cloudflare
Stubby uses chiperlist for tls 12 and ciphersuite for tls 13.
I added tls min version to make connection stable with 1.1.1.1.
No idea why John stock config (tls min ver 13) is not working (anymore).
That's why I am asking here
EDIT:
DNS resolution works with tls min ver 13 .. but quite unstable .. get DNS timeout.
EDIT2 ..
Take your coffee first
Has chipersuite changed for cloudflare ?
Do you have correct chipersuite to use tls 13 with 1.1.1.1 ?
Thanks
Last edited:
Running Merlin 384.13 at the moment, but it's an interesting test to prove or disprove if it's the fork or not.Stubby uses chiperlist for tls 12 and ciphersuite for tls 13.
I added tls min version to make connection stable with 1.1.1.1.
No idea why John stock config (tls min ver 13) is not working (anymore).
That's why I am asking here
EDIT:
DNS resolution works with tls min ver 13 .. but quite unstable .. get DNS timeout.
EDIT2 ..
Take your coffee first
Has chipersuite changed for cloudflare ?
Do you have correct chipersuite to use tls 13 with 1.1.1.1 ?
Thanks
Code:
echo | openssl11 s_client -tls1_3 -verify 1 -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853Good:
Code:
# echo | openssl11 s_client -tls1_3 -verify 3 -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853
verify depth is 3
CONNECTED(00000004)
Can't use SSL_get_servername
depth=2 C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
verify return:1
depth=1 C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
verify return:1
depth=0 C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com
verify return:1
---
Certificate chain
0 s:C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com
i:C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
1 s:C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
i:C = US, O = DigiCert Inc, OU = www.digicert.com, CN = DigiCert Global Root CA
---
Server certificate
-----BEGIN CERTIFICATE-----
<snip>
-----END CERTIFICATE-----
subject=C = US, ST = California, L = San Francisco, O = "Cloudflare, Inc.", CN = cloudflare-dns.com
issuer=C = US, O = DigiCert Inc, CN = DigiCert ECC Secure Server CA
---
No client certificate CA names sent
Peer signing digest: SHA256
Peer signature type: ECDSA
Server Temp Key: X25519, 253 bits
---
SSL handshake has read 2786 bytes and written 279 bytes
Verification: OK
---
New, TLSv1.3, Cipher is TLS_CHACHA20_POLY1305_SHA256
Server public key is 256 bit
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---
---
Post-Handshake New Session Ticket arrived:
SSL-Session:
Protocol : TLSv1.3
Cipher : TLS_CHACHA20_POLY1305_SHA256
Session-ID: <snip>
Session-ID-ctx:
Resumption PSK: <snip>
PSK identity: None
PSK identity hint: None
SRP username: None
TLS session ticket lifetime hint: 21600 (seconds)
TLS session ticket:
<snip>
Start Time: 1574438878
Timeout : 7200 (sec)
Verify return code: 0 (ok)
Extended master secret: no
Max Early Data: 0
---
read R BLOCK
DONE
Code:
# echo | openssl11 s_client -tls1_3 -verify 3 -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853
verify depth is 3
CONNECTED(00000004)
1024:error:1409442E:lib(20):func(148):reason(1070):NA:0:SSL alert number 70
---
no peer certificate available
---
No client certificate CA names sent
---
SSL handshake has read 7 bytes and written 215 bytes
Verification: OK
---
New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported
Compression: NONE
Expansion: NONE
No ALPN negotiated
Early data was not sent
Verify return code: 0 (ok)
---Something must have changed on Cloudflare's backend recently, at least in the geographies of those of us who see the issue.
Last edited:
Thanks for testing and proving the current situation !
Would love to have openssl11 binary in Johns fork as well .. maybe at some point - when he is back
With TLS min version 1.2 the connection to 1.1.1.1 is rock stable .. like it used to be before.
Realized the DNS drops since a few days/weeks only .. TLS min version 1.3 was stable all the time before.
We may open ticket at cloudflare .. ?
No idea .. or we just try again after some days/weeks .. maybe it magically works after some time.
What is also a bit strange ..
Using (stable) tls min vers 12 the 1.1.1.1 test page (https://1.1.1.1/help) becomes "unstable".
The page shows "NO" for DoT connection .. sometimes the check works.
If I switch back to (unstable) tls min vers 13 the webpage shows always "YES" for DoT connection.
All tests are successful .. never failing tests for DoT .. even DNS get timeouts
Cheers
Until the CloudFlare situation stabilizes, I would recommend that anyone using DoT on the fork use this stubby.postconf:
This will use the stubby default GETDNS_TLS1_2. Better than a stubby.yml.add which would end up with 2 different tls_min_version directives in the same file.
Code:
#!/bin/sh
. /usr/sbin/helper.sh
CONFIG="$1"
pc_delete "tls_min_version: GETDNS_TLS1_3" "$CONFIG"
There is no good reason to set a minimal version to 1.3. TLS 1.2 is considered secure, and it's the most widely supported protocol at the moment. Let Stubby (or rather, OpenSSL) negotiate with the remote end which protocol to use. If they support 1.3, it will be used, otherwise it will downgrade to 1.2, and you will still be fine and secure.
jrmwvu04
Very Senior Member
I couldn't remotely prove it but that was my thought. I might try toggling that tls 1.2 setting a little later on.
Thank you. This timeout problem has been driving me nuts. All of a sudden using DoT with 1.1.1.1 has been producing random timeouts in Chrome. DoT disabled the issue disappears. Thought it was something on my end. I'll be giving this fix a try.
@followmsi and @Rahul_K figured out how to stabilize it. I just dug deeper to figure out why it worked. A community effort!
@followmsi and @Rahul_K figured out how to stabilize it. I just dug deeper to figure out why it worked. A community effort!
@followmsi, @Rahul_K thank you both as well. Good to see this community still alive while John is away.
@dave14305 - Thanks for the earlier post on 374.43_40EBj9527. That was going to be my next question, but you've already answered it.
Ran across this post searching for another issue. Is this perhaps related?
When adding pc_delete "tls_min_version: GETDNS_TLS1_3" Cloudflare complains and says "You are not using secure transport for your DNS". If I remove that line, test says "You are using encrypted DNS transport with 1.1.1.1". Note, I am only using DoT, no DNSSEC enabled in either scenario. Assume this is just because 1.3 isn't being used?
When adding pc_delete "tls_min_version: GETDNS_TLS1_3" Cloudflare complains and says "You are not using secure transport for your DNS". If I remove that line, test says "You are using encrypted DNS transport with 1.1.1.1". Note, I am only using DoT, no DNSSEC enabled in either scenario. Assume this is just because 1.3 isn't being used?
Run
Code:
stubby -C /etc/stubby.yml -iEdit: Even with DoT enabled on Merlin with Cloudflare and confirmed with tcpdump, the Cloudflare sites don’t think I’m using DoT. Can’t take those testing sites seriously anymore, if we ever could in the first place.
Last edited:
jrmwvu04
Very Senior Member
@followmsi and @Rahul_K figured out how to stabilize it. I just dug deeper to figure out why it worked. A community effort!
I’ve updated the firmware to 40EB and reinstated cloudflare DoT with the tls 1.3 setting stripped from the stubby configuration. Working pretty good so far through about six hours.
@cvx01 I also coincidentally tested at the cloudflare site after I was up and running and didn’t have that issue.
It is the weirdest thing, this morning I hit https://1.1.1.1/help 5 times in a row doing nothing more than hitting refresh, attempts 1-4 state DoT = No. On the 5th attempt forward it will now continually state I’m using DoT. Same with the other site yesterday.
Result: Config file syntax is valid. I’m also leaning toward these sites being the issue, just seems odd it would recognize DoT after several attempts. Also odd it says I’m using DNSSEC, when I have that turned off in the UI.
I will say, regardless of the the other anomaly above, the fix no doubt solves the ERR_NAME_RESOLUTION_FAILED in Chrome. Zero issues since the fix was applied.
Last edited:
Sounds a lot like the 1.3 issue - depending on which backend server you reach you get a different result. Cloudflare growing pains.
jrmwvu04
Very Senior Member
I noticed that as well, the DNSSEC thing. I chalked it up to careful wording. It reads, “Your resolver validates DNS responses with DNSSEC.” which is I guess technically correct even if you’re not configured to use it.
Fernando Pena
New Around Here
Hey guys, it's my first time flashing a custom firmware to my N66U... I have some questions, I hope someone is able to answer.
Do I need to factory reset BEFORE flashing the firmware or only after is enough?
Can I flash this fork directly over the latest firmware (800+) or I need to downgrade to stock 374 before doing so?
I'm asking those questions because I did flashed over the latest firmware using asus recovering tool and everything went fine apparently (did a factory reset after), but the web interface is kinda messed up in some places, for exemple some horizontal tab menus are misplaced, there's text behind buttons etc. Is this normal for this fork? Maybe it's the browser's cache?
Do I need to factory reset BEFORE flashing the firmware or only after is enough?
Can I flash this fork directly over the latest firmware (800+) or I need to downgrade to stock 374 before doing so?
I'm asking those questions because I did flashed over the latest firmware using asus recovering tool and everything went fine apparently (did a factory reset after), but the web interface is kinda messed up in some places, for exemple some horizontal tab menus are misplaced, there's text behind buttons etc. Is this normal for this fork? Maybe it's the browser's cache?
Similar threads
Similar threads
Similar threads
-
-
-
-
Sudden network issues, looking to fully reset my TUF-AX5400 router running Gnuton's Merlin fork
- Started by Zenophilious
- Replies: 1
-
-
Release Asuswrt-Merlin 3006.102.2 is now available for Wifi 7 devices
- Started by RMerlin
- Replies: 62
-
Unable to establish VPN connection to my PiVPN (ovpn) from my Asus RT-AC86U running Asuswrt-Merlin 386.14
- Started by B0GDAN
- Replies: 1
-
Several Questions Re:Asuswrt-Merlin Feature Implementation
- Started by fenixreign
- Replies: 2
-
-
Beta Asuswrt-Merlin 3006.102.2 Beta is now available for Wifi 7 devices
- Started by RMerlin
- Replies: 70