Warning on Chrome 58

[john9527]

Just a warning....when I updated to the latest stable Chrome 58, it severely broke https access to the router. You may want to hold off a bit on the update until things can get sorted out.

 

[hggomes]

Any more info about it? Working fine here...

 

[john9527]

Any more info about it? Working fine here...

No.....but thanks for the feedback that it's working OK for you. It may be unique to my fork which doesn't use the token based authentication of the newer levels.

For me, it ignored the self-signed cert I have loaded and gave a warning....gave me the option to continue, but then ended up with all sorts of formatting problems in the gui. Reverted back to release 57 and everything was back to normal.

Thought it best to err on the conservative side until we got some more data points. I need to locate the detail release notes. They've really been tightening things down.

 

[RMerlin]

Again?

A few months ago, https would cause the browser to freeze for a few seconds when accessing certain pages. The problem eventually disappeared at some point. I guess it might be back now...

I've seen Asus make a few tweaks to the socket code for httpd in recent GPLs, I might need to dig a bit into it in case it might help.

 

[RMerlin]

So far it also seems to work fine for me using 380.66 Alpha 4.

If you can, check what the error console shows you. Messed up formating might indicate that only some specific files are failing to be transferred to the browser (maybe there's some mixed http/https content there?).

 

[sfx2000]

There's some SSL weirdness going on with the Chrome 58 builds.... had to do with TLS 1.2 and TLS 1.3...

 

[sfx2000]

Take a look here...

chrome://flags/#ssl-version-max

 

[Deleted member 22229]

No issues with 380.65 and Chrome 58 just updated.

 

[john9527]

Found one possibility to investigate.....

Certs invalid on Chrome 58 due to CN Deprecation
David Mar 22, 2017 04:23PM UTC
TL;DR: Chrome 58 only looks at the SAN in a cert for validating hostnames and not the CN. Please add a SAN for the hostname when generating the cert.

In 2000, RFC 2818 (https://tools.ietf.org/html/rfc2818) "deprecated" checking CN in favor of using SAN. 17 years later, browsers are actually doing so, with Chrome 58 and Firefox 48: https://www.chromestatus.com/features/4981025180483584

 

[Gregory Phillips]

No.....but thanks for the feedback that it's working OK for you. It may be unique to my fork which doesn't use the token based authentication of the newer levels.

Same here, http works but https doesn't work.

 

[RMerlin]

Found one possibility to investigate.....

Certs invalid on Chrome 58 due to CN Deprecation
David Mar 22, 2017 04:23PM UTC
TL;DR: Chrome 58 only looks at the SAN in a cert for validating hostnames and not the CN. Please add a SAN for the hostname when generating the cert.

In 2000, RFC 2818 (https://tools.ietf.org/html/rfc2818) "deprecated" checking CN in favor of using SAN. 17 years later, browsers are actually doing so, with Chrome 58 and Firefox 48: https://www.chromestatus.com/features/4981025180483584

The odd bit is both our firmware use the exact same code (AFAIK) regarding the generation of the SSL certificate.

Still worth investigating tho, even if it's for a totally different issue. I'll see if I can spare some time in the coming days to dig through this specific point.

 

[RMerlin]

There's some SSL weirdness going on with the Chrome 58 builds.... had to do with TLS 1.2 and TLS 1.3...

I updated Asuswrt's SSL code a few years ago to add support for TLS 1.0 through 1.2 (and remove legacy SSL support). I was actually recently debating whether or not to ditch 1.0 and 1.1 support in httpd, then feared it might break Asus's mobile application and put that plan on hold for the time being. And figured that for a LAN-only service, 1.0/1.1 were good enough, if I wanted to avoid the risk of breaking third party apps.

 

[hggomes]

Same here, http works but https doesn't work.

FW version?

 

[RMerlin]

FW version?

And also don't forget to specify the port - default https port is 8443.

 

[sfx2000]

I updated Asuswrt's SSL code a few years ago to add support for TLS 1.0 through 1.2 (and remove legacy SSL support). I was actually recently debating whether or not to ditch 1.0 and 1.1 support in httpd, then feared it might break Asus's mobile application and put that plan on hold for the time being. And figured that for a LAN-only service, 1.0/1.1 were good enough, if I wanted to avoid the risk of breaking third party apps.

It's more a chrome 58 problem, not AsusWRT as far as I can tell...

 

[Gregory Phillips]

FW version?

380.66_alpha4

 

[hggomes]

380.66_alpha4

So far it also seems to work fine for me using 380.66 Alpha 4.

LOL, why was I already expecting that answer? The same FW version working for one but not for the other, something really wrong there.

 

[RMerlin]

While there's indeed no SAN, the page still loads here, using TLS 1.2.

I'll see if it's possible to add a SAN when the certificate is generated by the firmware.

 

[john9527]

I've gotten at least part of the way there (though google still doesn't recognize the final cert as having a SAN )

Certificate Request:
    Data:
        Version: 0 (0x0)
        Subject: C=US, CN=ASUS Self-Signed Certificate
        Subject Public Key Info:
            Public Key Algorithm: rsaEncryption
                Public-Key: (1024 bit)
                Modulus:
                    00:d7:96:81:6f:09:45:d9:66:a6:82:cc:81:db:6b:
                    ....
                Exponent: 65537 (0x10001)
        Attributes:
        Requested Extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage:
                Digital Signature, Non Repudiation, Key Encipherment
            X509v3 Subject Alternative Name:
                DNS:router.asus.com, DNS:asusrouter.com, IP Address:192.168.1.1
    Signature Algorithm: sha256WithRSAEncryption
         3b:93:4a:46:35:38:4f:32:5a:07:97:74:5a:31:9a:ca:1b:fb:
         ....

 

[RMerlin]

I've rewritten most of gencert.sh (was a quiet afternoon at the office).

https://gist.github.com/RMerl/b074151cc70880c8f81f0711525b75fb

I went a bit over the top perhaps, since I'm also including SANs for:

• DUT (router.asus.com)
• hostname
• FQDN hostname
• DDNS hostname (if any)
• IP address

I also rewrote the openssl commands to avoid the intermediary step where it was password-protecting the generated key (pointless as it was immediately removing the password), and passed the config file as a proper argument.

One thing I'm not 100% satisfied with is I'm duplicating sections to add the new parameters. Openssl doesn't seem to mind and merges parameters from both duplicatas. To make this cleaner would require some sed magic to insert the parameters in the temporary openssl.config file.

I've gotten at least part of the way there (though google still doesn't recognize the final cert as having a SAN )

You need to change the openssl config file to tell it to copy extensions when signing the certificate (for security reasons, extensions are not copied by default, as if you were signing someone else's CSR, you might end up leaking confidential info when copying extensions from your CA...).

Feedback on this updated script?