382.18547 (RT-AC68U) regenerates its SSL certificate on every boot

[bughit]

A self signed cert that doesn't change, that the browser remembers and expects from the ip of the router, is perfectly secure. It's like ssh trust on first use, where the first use is a private direct connection between the machine and the router with no possibility of man-in-the middle.

If the cert changes on every boot, the first use trust is invalidated.

 

[Mike808]

The problem with self-signed certs is that most people don't use ssh. They see the internet from a browser. And browsers are doing everything they can to NOT allow users to trust self-signed certs. You can't tell the 'good' self signed certs from the 'bad' ones.
And you can't expect web surfing users to be able to tell or detect the difference. The same for IP addresses. There's a reason we use DNS.

We need a 'real' cert from a 'real' CA for a 'real' hostname. Like 'router.asus.com' would be great. The problems left are the DNS and the 'real' CA (one pre-trusted by browsers) signing a cert from a non-internet device and the non-internet part of that. This needs to be zero knowledge usability and still have security like every other website in the planet. Let's Encrypt is a start, but you need a 'real' DNS domain for the 'hostname' for the router.

I'm thinking split-horizon DNS and someone owning the public router hostname facilitates the let's encrypt certs. And automates the 90-day renewals. Which is what Plex did and hid all the complexity of individual keys, individual hostnames, CSRs, signing APIs, and password-protected delivery/storage of the keys by leveraging all of that from existing standards. The individual hostnames will be a problem because autogenerating them isn't people-friendly.

 

[RMerlin]

We need a 'real' cert from a 'real' CA for a 'real' hostname. Like 'router.asus.com' would be great. The problems left are the DNS and the 'real' CA (one pre-trusted by browsers) signing a cert from a non-internet device and the non-internet part of that. This needs to be zero knowledge usability and still have security like every other website in the planet. Let's Encrypt is a start, but you need a 'real' DNS domain for the 'hostname' for the router.

Or we need a mechanism/app that would make it easy for a home user to run his own CA, and emit his own certificate. He'd only need to import his own CA's certificate in all of his browsers, and then issue his own certificate for all of his home devices. Pretty much what most small businesses do with their Windows Server, where they emit and import their server-signed certs on their mobile devices.

Part of the challenge would be to make it simple enough for the average home user to be able to understand it.

 

[bughit]

@RMerlin You mentioned that your code is different, do you store and reuse the cert or regenerate it on every boot like asus? If you regenerate it, would you consider storing it?

 

[Mike808]

easy for a home user to run his own CA, and emit his own certificate. He'd only need to import his own CA's certificate in all of his browsers, and then issue his own certificate for all of his home devices.

The challenge is to eliminate all of that complexity entirely. That's why using a pre-trusted CA is critical. There is no reason users "need" to "run HER own CA", vet certificates, and then "SHE'd only need to import HER own CAs ... in ALL OF HER BROWSERS". All of them. That means the ones embedded into the smart TVs and mobile devices and tablets and ... not just computers with people at the controls, in other words. That's not a realistic expectation for general home consumers. People don't have IT support departments or on-demand staff like small businesses do. You can't compare or equate or apply what works for a business works for people and families.

Please review the links I provided for information on how Plex did this for what the equivalent experience needs to be. We can do POCs and stepping stones, but it really needs to be turnkey at the end. As in plug in the router, point any old browser to a common site URL (e.g. router.asus.com) and have it set itself up with a pre-trusted certificate and then redirect you to the secure administrative site - all with zero technical knowledge or intervention required by the user.

 

[Mike808]

Extending @bughit's idea, openssl can generate a keypair, the CSR, receive the cert and CA chain into a PKCS#12 container file, password-protected using a generated password (like Plex's hashing a unique ID for enrolled servers under your account). To start the secure admin web GUI (https server) it would regenerate the password, open the P12 and use the private key and certs within. The hard part is once you have the keypair and CSR, sending it to the CA for signing (again, a PUBLIC CA, as in pre-trusted by FF, Chrome, Edge, Safari, IE, Opera, etc. Most everyone uses the Mozilla CAs, but MS, Google, Apple, and Oracle all have their own pre-trusted CA approval programs), having the CA vet the CSR and issue the certificate, and then getting the certificate back to the router for OpenSSL to put it all back together into the PKCS#12. It's that part that requires an internet connection, and the vetting part of making sure that whoever sent you a certificate for an exposed internet host is in control of that host and its DNS resolving. That's why a custom DNS is going to be needed - to authenticate an exposed internet host, but only to get a certificate that will only be used to authenticate an internal host (the admin service of the router).

It's important to have the router generate and secure its own key. If I give you a key, how do you know I didn't make a copy for myself or someone neither of us is aware of has made their own copy of it?

 

[RMerlin]

@RMerlin You mentioned that your code is different, do you store and reuse the cert or regenerate it on every boot like asus? If you regenerate it, would you consider storing it?

I allow both options - persistent, and re-generated.

 

[RMerlin]

Please review the links I provided for information on how Plex did this for what the equivalent experience needs to be.

Sorry, but that's not something I'm willing to devote development time to. The vast majority of my time is already taken just keeping in sync with new GPL releases, I have very little time for original development anymore. There are far more fundamental issues that need to be resolved first, starting with the fact that httpd's SSL support is half broken as it is. Chrome will stall on half the pages while browsing over https, and Firefox will sometimes even fail to complete the initial TLS handshaking, requiring the manual removal of the certificate from its db store.

Back in the day I already devoted a lot of my time adding TLS support, removing SSLv2 and v3, adding ECDH support, and removing weak ciphers (which were eventually all picked upstream by Asus and merged into stock). I also spent a few nights trying to devise a way to fix the broken SSL support. I even went as far as implement a complete SSL proxy (based on haproxy) to hide the issue, but it introduced new challenges related to user authentication that would require some low-level changes that are beyond the scope of my project. Ultimately, the SSL stack used by httpd needs a major overhaul, and this is once again beyond the scope of my project (and something I simply don't have the time to do either).

So until the underlying SSL/TLS code gets fixed, any time spent on top of that broken stack is a waste of development time. Fixing that stack should have a much higher priority.