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

[bughit]

Feb 13 19:00:14 Mastiff: init
Feb 13 19:00:14 syslog: Generating SSL certificate...
Feb 13 19:00:14 syslog: Generating SSL certificate...
Feb 13 19:00:14 rc_service: udhcpc 298:notify_rc start_firewall

This is both annoying and insecure. Firefox remembers accepted self-signed certs per site and re-prompts when the cert changes. The reason it does that is that a unexpected change of a self-signed cert is indicative of man-in-the-middle attack.

So why are they doing it? And could someone in touch with them please ask them to stop?

 

[KevTech]

What exact sites are you referring to?

I use Firefox and tested this by rebooting router but no re-prompts on any site.

 

[bughit]

What exact sites are you referring to?.

router admin

 

[KevTech]

You mean because it redirects from 192.168.1.1 to router.asus.com or even if just typing in router.asus.com

I don't have the redirect because I have an entry in the windows hosts file.

127.0.0.1 router.asus.com

Maybe why I do not have the issue you have.

Merlins firmware has an option on the admin page to not redirect from 192.168.1.1 to router.asus.com but stock does not have that option.

 

[bughit]

redirection has nothing to do with this, if you are interested in reproducing this issue, load the admin pages over https

 

[KevTech]

redirection has nothing to do with this, if you are interested in reproducing this issue, load the admin pages over https

Does not happen to me.

 

[bughit]

You don't have a "Generating SSL certificate" entry in the system log after a reboot?

Feb 13 19:00:14 syslog: Generating SSL certificate...

 

[bughit]

@RMerlin Do you know if this is intentional in 382?

 

[RMerlin]

No idea, my SSL code is different from Asus's, and I haven't seen their 18547 code either.

 

[Mike808]

There are several problems with the self-signed cert being used to "secure" the admin gui with HTTPS.
1. It's a version 1 certificate - no extensions, means the cert can be used for *anything*.
Solution: Should be a proper V3 cert, end-entity, limited to TLS/SSL Server purposes.
2. It's generated and issued to the IP address of the router. The CN is the raw IP address.
Solution: Should be a proper SAN cert, with router.asus.com as the CN an router.asus.com and the IP address as SAN entries. Note that IP addresses use a different SAN entry record type than DNS hostnames.
3. It's sefl-signed. The certificate should be properly issued by a public CA, preferably Let's Encrypt which is free.
Solution: Let's Encrypt only issues DV (Domain Validated) certificates, meaning the host MUST be exposed to the internet to validate control over the hostname (domain) in the certificate.

#3 is the real problem, and the "right" way to solve it is for Asus to step up, or anyone really, and offer "real" certificates for internal, non-routable local LAN IP address spaces (bogons). The trick/magic is that whomever runs that service must run a custom DNS resolver for their domain and expose public hostnames that resolve to private IP addresses. More specifically, the IP address of your router.

The only people that have managed to do this (and correctly, btw) is the fine folks over at Plex. They used DigiCert, and the Plex Media Server uses the DigiCert APIs to request and retrieve your server's certificate. The domain they are issued to is one controlled by Plex, and the "hostname" is a combination of your account ID (a hash) and the internal IP address. The same could be done with Let's Encrypt and a willing partner hosting a domain and a custom DNS. The likely candidates are the DDNS service providers and/or possibly Asus itself, to do so for their routers. There isn't anything stopping Merlin for doing so or anyone else. The trick is the account ID plus the ip address embedded into the hostname combined with the custom DNS resolver to "decode" the hostname and return the "correct" internal IP address for your router (or whatever device you need a certificate for).

There is probably a way to use an existing Plex installation to obtain additional certificates, say, for your router.... but that likely isn't what the Plex people had in mind when they paid DigiCert to issue certificates for Plex Media Server installations.

If anyone wants to discuss/consult offline on this, please contact me by PM.

 

[RMerlin]

There are several problems with the self-signed cert being used to "secure" the admin gui with HTTPS.
1. It's a version 1 certificate - no extensions, means the cert can be used for *anything*.
Solution: Should be a proper V3 cert, end-entity, limited to TLS/SSL Server purposes.
2. It's generated and issued to the IP address of the router. The CN is the raw IP address.
Solution: Should be a proper SAN cert, with router.asus.com as the CN an router.asus.com and the IP address as SAN entries. Note that IP addresses use a different SAN entry record type than DNS hostnames.
3. It's sefl-signed. The certificate should be properly issued by a public CA, preferably Let's Encrypt which is free.
Solution: Let's Encrypt only issues DV (Domain Validated) certificates, meaning the host MUST be exposed to the internet to validate control over the hostname (domain) in the certificate.

#3 is the real problem, and the "right" way to solve it is for Asus to step up, or anyone really, and offer "real" certificates for internal, non-routable local LAN IP address spaces (bogons). The trick/magic is that whomever runs that service must run a custom DNS resolver for their domain and expose public hostnames that resolve to private IP addresses. More specifically, the IP address of your router.

The only people that have managed to do this (and correctly, btw) is the fine folks over at Plex. They used DigiCert, and the Plex Media Server uses the DigiCert APIs to request and retrieve your server's certificate. The domain they are issued to is one controlled by Plex, and the "hostname" is a combination of your account ID (a hash) and the internal IP address. The same could be done with Let's Encrypt and a willing partner hosting a domain and a custom DNS. The likely candidates are the DDNS service providers and/or possibly Asus itself, to do so for their routers. There isn't anything stopping Merlin for doing so or anyone else. The trick is the account ID plus the ip address embedded into the hostname combined with the custom DNS resolver to "decode" the hostname and return the "correct" internal IP address for your router (or whatever device you need a certificate for).

There is probably a way to use an existing Plex installation to obtain additional certificates, say, for your router.... but that likely isn't what the Plex people had in mind when they paid DigiCert to issue certificates for Plex Media Server installations.

If anyone wants to discuss/consult offline on this, please contact me by PM.

That's a lot of trouble just to encrypt traffic within your own home LAN. The needs are completely different from a public website.

Sent from my P027 using Tapatalk

 

[Mike808]

You must not have a home network with smart TVs that can sniff your home network and then compromise your router and turn your entire home network into a bot that mines crypto currency and DDoS on-demand. It's not just encryption. It's authenticating your device and protecting your router's administrative control access (login/password). Maybe you don't care about anyone taking control of your router and your home network, but lots of people do.

The right thing isn't always easy.

Certificates and TLS have specifications that aren't optional. The good news is that OpenSSL can do the heavy lifting there. The bad news is that certificate authorities weren't designed to certify private networks, and running a private CA isn't easy. Plex found a way. That can be repeated.

Asus has Let's Encrypt in some firmwares already, but it is a certificate for a WAN host for remote administration. A trusted certificate for private networks would be the bees knees. But it involves a custom DNS resolver, since certificates are validated against DNS. And every router just happens to have one of those. That's why that makes the router the right place to anchor security for home networks separate and independent of the outside internet, securing the IoT devices on your home network that all have admin privileged access control, and usually it's web-based, making TLS/SSL the way to secure that admin service. Not all devices on your home network are or will be friendly - especially if you don't control them.

Don't let your refrigerator drain your bank account because the toaster told it to.

I'm not asking you to build it alone. I'm offering to help build it. I know what Plex did and how they did it. Replicate that and you'll make Merlin firmware the gold standard for securing home networks, not just the router. All the smart devices will need certificates to identify them and secure their admin access services.

 

[RMerlin]

You must not have a home network with smart TVs that can sniff your home network and then compromise your router and turn your entire home network into a bot that mines crypto currency and DDoS on-demand. It's not just encryption. It's authenticating your device and protecting your router's administrative control access (login/password). Maybe you don't care about anyone taking control of your router and your home network, but lots of people do.

A self-signed certificate will be sufficient to prevent any device on your LAN from sniffing the traffic. Having it emitted by a known entity merely authenticate the endpoint. It adds nothing to the data security.

And if you have a SmartTV that can sniff and steal your traffic, then you need to disconnect it right away, rather than just trying to protect this and that on your LAN. A lot of your LAN traffic won't be encrypted. Control what you put on your LAN.

 

[Mike808]

A self-signed certificate is the problem. It has no security value. You are logging into an anonymous device. Think about that. That's why browsers don't trust them. They also don't make it easy to override their predefined trusted CAs.

It's not about encryption. It's about authenticating the service as a privileged/administrative control service *and* encrypting that connection when you authenticate to the service as a privileged user. Both have to be assured to demonstrate the security claim.

You need to know from certain it's your router that you're talking to when you hand over your admin password.

Just because you don't have anything valuable on your home network doesn't mean everyone else also doesn't have anything worth protecting ever.

Ever enter credit cards into your video-on-demand service on your smart TV's app? Order a pay-per-view on a console? Millions already do. Have your refrigerator order groceries and access to your bank acount to do that? Someone order expensive items by telling Alexa to order it from Amazon? What about your child's friend hooking up their compromised laptop to your home network after school. The lack of security on the IoT home network is already a crypto goldmine. And the router is the lunch pin to that.

So securing it with a "real" certificate is the right thing to do.

Here's a walk through on how plex did it.
https://blog.filippo.io/how-plex-is-doing-https-for-all-its-users/

All the pieces are there on a router. The DNS resolver, connection to the internet. I could reuse my plex cert if I can extract the key, since they already have the magic DNS part.

 

[RMerlin]

It's not about encryption. It's about authenticating the service as a privileged/administrative control service *and* encrypting that connection when you authenticate to the service as a privileged user. Both have to be assured to demonstrate the security claim.

If I enter the IP address of my gateway and something else answers, it means my whole network is already compromised, and my default gateway is no longer my router. By then, it's game over.

That's why I personally favor accessing routers by their IP - it will be far more reliable than any SSL certificate that isn't issued for a public domain with domain-based validation. Unless you're going to involve DNSSEC signature to your local zone file. By which point you are devoting way more effort that is worth it to secure your home router.

 

[Mike808]

The threat isn't a device taking over and pretending to be your router, it's compromised devices on your local home network doing bad things - to your router - without you knowing anything about it. You suggest I should take any compromised smart TV off my network ... as soon as I know it is compromised. Like the bad guys are going to tell me. That also assumes that most people with a home network actually know anything at all about networking. News flash, they don't. That's why people EVERYWHERE are complaining about this stupid self-signed certificate that browsers give nasty warnings about and require some crazy workaround just to get the damned thing to work with their browser -- and configure it to something more secure than the default - which is NONE.

That's the point of Plex doing what they did. Security doesn't have to be hard. It shouldn't be a pain in the butt -- intentionally and by design, if that's what you're going with as to why it's the way it is, and that it's not possible to make it better. I respectfully disagree with that view if that's your stance on it.

 

[Mike808]

I did figure out how to extract the private key and certificate from my Plex. The password to the P12 file is the SHA512 hash of "plex" and your ProcessedMachineIdentifier (hex encoded). So now I have the key and the cert and can manually replace the router-generated one.

The certificate is issued to *.<account-hash>.plex.direct. Their nameserver resolves a hostname-that-looks-like-an-ip-address into that IP address.
Thus, 127-0-0-1.<account-hash>.plex.direct resolves to 127.0.0.1 and since the cert is a wildcard, it works on any address. Plex then calculates the "hostname" for any IP address your media server says it's listening on and generates https://a-b-c-d.<account-hash>.plex.direct:<port>/ URLs for connecting to your media servers on your local (or external) network.

The routers admin interface could easily do the same - if that initial hostname could be injected into the router's local hosts file. But people don't know that funky name, but it would work if the goal is to reuse the Plex certificate on your router. So that's the POC, not the end-state.

What I'd like to be able to do now is setup a redirect to that (user-entered) hostname from router.asus.com and have it injected into the local DNS hostname resolver to point to the router (thus, doing the same thing that Plex's DNS nameserver is doing for their plex.direct domain, but never touching the WAN (because we're configuring the router and the WAN might not be connected.

 

[NGRhodes]

Not quite sure what the problem to be solved here is ?
Why would you not trust your router IP and router generated cert ?

 

[Mike808]

Not quite sure what the problem to be solved here is ?
Why would you not trust your router IP and router generated cert ?

Straight from the thread title and the OP:

(RT-AC68U) regenerates its SSL certificate on every boot
This is both annoying and insecure. Firefox remembers accepted self-signed certs per site and re-prompts when the cert changes. The reason it does that is that a unexpected change of a self-signed cert is indicative of man-in-the-middle attack.

The desired behavior is to plug in the router and use a secure link to administrate it without requiring dorking around with technical disablement of browser security. This is out-of-the-box user experience 101. The fastest way to never get security in place is to make it more of a pain to do than to not. So make the default/right thing to do the easiest. If that's not true, then you're doing it wrong.

The trick is to get a certificate issued for a non-internet-connected local network device/host (i.e. secure the router admin web GUI hostname) that is trusted by browsers out-of-the-box. Since certificates are validated by DNS, and your router is offline (no WAN), how that happens will require DNS shenanigans that match up the IP address (local, non-routable, remember) with the certificate (DNS hostname). Part 2 of the trick is getting a public CA to issue your cert, which means you have to be online, but also they only issue certs to internet hostnames/domains you can prove you control.

Separate from that, what I really want is a router mode to block devices on my network by default and then to tell me where they are trying to "call home" and then whitelist just that communication for that device. i.e. my NEST thermostat can tell my dashboard what's going on, but not send spam email or mine bitcoin or amplify DDOS attacks in a bot army. Or I can turn off my Samsung TV reporting back to the mothership every minute about what shows I'm watching and chewing up my bandwidth doing who knows what with who knows who without my permission or knowledge. I've got a smart TV that I don't use any of that - it's just a dumb monitor hooked up to my A/V receiver. But I can't stop it's builtin wifi from connecting up to the internet and chatting all day and night with the manufacturer and defunct out-of-business servers that who knows what they're doing. (Yahoo!TV, anyone?)

 

[sfx2000]

I'm inclined to fall on the side of @Mike808 here...

Certs are becoming more of an issue as we move into HTTPS for all sites - a self-signed cert is basically safe - if one trusts the cert, but it establishes bad habits that folks will learn to punch thru. IoT devices don't have that chance...

It's not that hard for Asus to provide a valid cert per device - we do this all the time in the telco world with devices and sim cards.