[Fork] Asuswrt-Merlin 374.43 LTS releases (Archive)

[dave14305]

Here you are .. (removed " resolvconf: "/tmp/resolv.conf" " already )

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

 

[followmsi]

John by default sets the TLS min version to 1_3 and the ciphers to match. Why change to 1_2?

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

 

[dave14305]

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

Running Merlin 384.13 at the moment, but it's an interesting test to prove or disprove if it's the fork or not.

echo | openssl11 s_client -tls1_3 -verify 1 -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853

If I run this command repeatedly in SSH, most times it fails but once in a while it succeeds with a TLS1.3 connection.
Good:

# 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

Bad:

# 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)
---

So I suspect not every endpoint behind 1.1.1.1 is supporting TLS 1.3 yet. Therefore, overriding the TLS min version to 1.2 will allow Stubby to use TLS 1.3 when it randomly connects to an endpoint capable of 1.3, and will continue to function when reaching one that cannot do 1.3.

Something must have changed on Cloudflare's backend recently, at least in the geographies of those of us who see the issue.

 

[followmsi]

Running Merlin 384.13 at the moment, but it's an interesting test to prove or disprove if it's the fork or not.

echo | openssl11 s_client -tls1_3 -verify 1 -CAfile /rom/etc/ssl/certs/ca-certificates.crt -connect 1.1.1.1:853

If I run this command repeatedly in SSH, most times it fails but once in a while it succeeds with a TLS1.3 connection.
Good:

# 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

Bad:

# 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)
---

So I suspect not every endpoint behind 1.1.1.1 is supporting TLS 1.3 yet. Therefore, overriding the TLS min version to 1.2 will allow Stubby to use TLS 1.3 when it randomly connects to an endpoint capable of 1.3, and will continue to function when reaching one that cannot do 1.3.

Something must have changed on Cloudflare's backend recently, at least in the geographies of those of us who see the issue.

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

 

[dave14305]

Until the CloudFlare situation stabilizes, I would recommend that anyone using DoT on the fork use this stubby.postconf:

#!/bin/sh

. /usr/sbin/helper.sh

CONFIG="$1"

pc_delete "tls_min_version: GETDNS_TLS1_3" "$CONFIG"

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.

 

[dave14305]

Changelog
---------
374.43_40EBj9527 (21-November-2019) ARM SDK, MIPS,ARM KRACK
- CHANGED: dnsmasq: update to 2.80-g456a319

374.43_40EAj9527 (11-November-2019) ARM SDK, MIPS,ARM KRACK
- CHANGED: openvpn: update to 2.4.8
- FIXED: webui: allow empty local IP for IPv6 firewall rule

No Stubby fixes, but happy to see he's still working on it when he wants to.

 

[RMerlin]

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.

 

[joe a]

Hmm. New update in dev. Must install.

 

[jrmwvu04]

So I suspect not every endpoint behind 1.1.1.1 is supporting TLS 1.3 yet. Therefore, overriding
Something must have changed on Cloudflare's backend recently, at least in the geographies of those of us who see the issue.

I couldn't remotely prove it but that was my thought. I might try toggling that tls 1.2 setting a little later on.

 

[cvx01]

Until the CloudFlare situation stabilizes, I would recommend that anyone using DoT on the fork use this stubby.postconf:

#!/bin/sh

. /usr/sbin/helper.sh

CONFIG="$1"

pc_delete "tls_min_version: GETDNS_TLS1_3" "$CONFIG"

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.

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.

 

[dave14305]

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!

 

[cvx01]

@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.

 

[cvx01]

Ran across this post searching for another issue. Is this perhaps related?

• https://www.snbforums.com/threads/dns-over-tls-problem.57247/#post-500344

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?

• https://www.cloudflare.com/ssl/encrypted-sni/

 

[dave14305]

Ran across this post searching for another issue. Is this perhaps related?

• https://www.snbforums.com/threads/dns-over-tls-problem.57247/#post-500344

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?

• https://www.cloudflare.com/ssl/encrypted-sni/

Run

stubby -C /etc/stubby.yml -i

to make sure the final stubby config file is valid. If the site doesn’t think you’re using secure dns (DoT), then stubby isn’t working perhaps. Post your stubby.yml if you get errors back from the command.
Edit: 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.

 

[jrmwvu04]

@followmsi and @Rahul_K figured out how to stabilize it. I just dug deeper to figure out why it worked. A community effort!

Ran across this post searching for another issue. Is this perhaps related?

• https://www.snbforums.com/threads/dns-over-tls-problem.57247/#post-500344

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?

• https://www.cloudflare.com/ssl/encrypted-sni/

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.

 

[cvx01]

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.

 

[cvx01]

Run

stubby -C /etc/stubby.yml -i

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.

 

[dave14305]

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.

Sounds a lot like the 1.3 issue - depending on which backend server you reach you get a different result. Cloudflare growing pains.

 

[jrmwvu04]

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.

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]

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?