34

image

I got this "Not secure" warning when I'm trying to log in to my router (it's within my physical access). Apparently my router's management (admin) system doesn't have HTTPS.

Chrome also says

Your connection to this site is not private.

I know that when I visit an HTTP website, the data transferred between my endpoint and the remote server could be sniffed by any node among the route, but this time the "remote server" is just the router (which also serves as a wireless AP).

Is it something to worry about, in the following cases? Assume I am authorized to administer the router and have unlimited physical access to it.

  1. The router is placed in my home and I fully acknowledge all devices connected to it (my PC, my phone, my family's PCs and phones).
  2. The router is placed in a public place (restaurant, hotel etc.) and is open to public in some ways.
iBug
  • 1,378
  • 1
  • 9
  • 12
  • 4
    Some clarifications that might help. A) a website is a website even if it's in your router. B) What makes a server remote is that it is not your local machine; it's not about distance at all. Your router is a remote server unless you've attached a keyboard and monitor and logged into it directly. – studog Feb 01 '19 at 19:31
  • 1) Get crossover cable 2) Ignore message – Joshua Feb 01 '19 at 19:53
  • 1
    it's potentially less-safe if your browser says it's secure because then it's going out to the web and back. – dandavis Feb 01 '19 at 20:36

4 Answers4

31

No public Certificate Authority (CA) will issue a certificate for any IP address. Certificates are issued on domain names, and a basic DV certificates (like the ones that Let's Encrypt hands out) will not be issued for domains set to a private IP address such as the 192.168.x.x blocks.

Because of that, you can never have an HTTPS connection to an IP-only address, and I would expect that I would not see an HTTPS connection to a consumer-grade router in my network. If I noticed such a connection (honestly, I probably wouldn't notice the lock one way or another), then I would be very suspicious that someone had installed rogue certificates, and has an actively snooping proxy somewhere on my machine or in my network.

It is possible to set up a secure HTTPS connection, depending on your router's capabilities. If you can add a certificate to your router, you can create a self-signed certificate. This will effectively encrypt your HTTPS connection inside of a perfectly valid TLS tunnel, although your browsers will be complaining very loudly that the validity of the certificate can't be verified.

There are ways to get past these complaints by the browser, such as adding yourself as a trusted CA on your computer, or getting a certificate for a domain and using your internal DNS or your hosts files to point the domain to the private IP, as mentioned in the comments.

You can also get a valid certificate and, within your own network, override the domain's A record to point to devices in your private net block, such as by editing your hosts files or using your own DNS server.

As far as the specific cases that you're asking about:

1, your own home: There should be nothing to worry about, assuming that all other devices are secure. Rogue devices on your network will be able to do packet sniffing, so don't log in using the same password that you log into your bank with (which is good advice regardless of what you're authenticating with).

2, you're hosting a public access point: Assume the network is being actively probed at all times. In this case, I might take the time to set up TLS properly and even then, if I were truly paranoid (I.e., my access point was set up at DefCon), then each time I access the management web page, I would disable wireless, ensure nothing else is connected via any hubs or switches, then change the password before re-enabling wireless and making my configuration changes.

Ghedipunk
  • 5,766
  • 2
  • 23
  • 34
  • 15
    Somewhat related: I've successfully set up publicly trusted certificates for routers on my network via Let's Encrypt. You can't get certificates for a private IP address, true, but you _can_ get certificates for a domain name pointing to a private IP address. (my-router.lan.example.com) – Ajedi32 Feb 01 '19 at 17:17
  • "...although your browsers will be complaining very loudly that the validity of the certificate can't be verified." I believe that depends on what certificates you have your machine/browser configured to trust. – jpmc26 Feb 01 '19 at 23:31
  • @jpmc26, true. I wrote that to be from the point of view of users who are just starting to muck about in TLS and securing traffic within their home network. Hopefully someone who knows how and why to add themselves as a trusted root CA and/or set up a local DNS server to deliver a private IP for your subdomain to get a Let's Encrypt certificate will already know what to expect. – Ghedipunk Feb 01 '19 at 23:36
  • I'd just make all my changes over the wire; usually you can still connect one. – Maarten Bodewes Feb 02 '19 at 00:21
  • Perhaps Google Chrome shouldn’t be displaying “Not secure” for internal IPs. That seems misleading... I might file a bug report. – Tim Feb 02 '19 at 15:12
  • 2
    @Tim: that isn't misleading. The browser cannot assure the security of the connection, that's all it's saying. In larger/complex internal networks, where you have multiple security partitions you may not necessarily want to assume everything in the internal network to be as trusted as any others. – Lie Ryan Feb 03 '19 at 13:35
  • "No public Certificate Authority (CA) will issue a certificate for a private IP address..." - CAs don't issue certificates for IP addresses at all, they're for names. – Duncan Smart Feb 06 '19 at 08:49
  • @DuncanSmart: that's wrong. X.509/PKIX suports addresses (as do 2818 and 6125) and CABforum baseline requirements explicitly allow and define issuance for _public_ (not 'reserved') addresses. See https://security.stackexchange.com/questions/214828/are-certificates-without-dns-fundamentally-flawed also https://stackoverflow.com/questions/52731321/is-it-possible-to-get-ssl-certificate-for-ipport-instead-of-a-domain-name https://stackoverflow.com/questions/2043617/is-it-possible-to-have-ssl-certificate-for-ip-address-not-domain-name . But LetsEncrypt doesn't. – dave_thompson_085 Jun 05 '21 at 00:44
5

It is common for SOHO devices (switches, routers) that they either do not support HTTPS or provide HTTPS with factory self-signed certificate which cannot be replaced.

I wouldn't worry much as long as:

  1. you control the wiring between your PC and router.
  2. remote management is disabled over wireless (admin page is allowed only via wired media) media.
  3. remote management is disabled from internet.
Crypt32
  • 5,750
  • 12
  • 24
  • 1
    Those 3 bullet points are generally true no matter where the router is placed. (OP asked about inside the home vs public place.) – studog Feb 01 '19 at 19:26
  • 3
    Recent MacBook models don't have Ethernet, they can only connect to the router via WiFi unless you purchase a USB/Thunderbolt Ethernet adapter. So you may have to enable management over wireless. – Barmar Feb 01 '19 at 20:54
  • @Crypt32 - Why is point number 2 i.e. remote management via wireless a security issue? – Motivated Feb 06 '19 at 00:32
  • It is easier to make a MITM over wireless. Attacker may have knowledge of shared key (if simple WPA/WPA2 is used) and act as a rogue AP. Since legitimate device cannot be authenticated (self-signed cert) you can't identify if you access legitimate or rogue AP. Both will present the same error. – Crypt32 Feb 06 '19 at 07:15
4

This is not a problem.

Others here have given technically precise answers which assume general knowledge of how the secure web connections work. However if you have that level of knowledge you will already know the answer to this question. Here is a simpler answer.

Secure web pages (i.e. those with "https" at the start of the URL and a green padlock or similar symbol) are secured by a system of digital certificates. Merely encrypting something isn't enough because it doesn't guarantee the identity of the web site; you may think you are talking to foobar.com, but how can you be sure? The answer is a system of identity certificates with digital signatures. When you go to its website, "foobar.com" sends you a certificate saying that it is the real "foobar.com", and that certificate is signed by one of a number of "certificate authorities" who are generally trusted by everyone to do this job of certifying identity on the Internet. If you click on the green padlock symbol, or whatever your web browser uses, you can see the certificate details.

If an identity doesn't match, or a certificate is missing, or if the link isn't encrypted, then your web browser will warn you about sending passwords because someone could be listening in.

Your home router doesn't have its own certificate signed by a Certificate Authority, but as the link is within just one house that doesn't matter. I suppose it might be better if web browsers shut up about insecure sites on addresses like 192.168.1.1 so that people don't get false alarms.

Paul Johnson
  • 141
  • 2
0

Case 1: Probably fine providing you really trust your family not to be trying anything clever and they dont pick up a nasty that listens for attempts to log in to websites at common addresses like that as a step towards takeover of the router for other purposes.

Case 2: Be slightly worried, but also this is a good learning opportunity. It's not a huge effort to create an in-house CA to generate SSL certs that will work for internal machines. OpenSSL lets you do it at the command line, tools like XCA do it with a pretty user interface. If it was my shop/cafe/hotel I would be concerned that guests and customers would be able to get to the router admin interface - that should be on a staff-only or even a separate management network / VLAN.

I use a similar proper router for home use, self-signed certs take 2 minutes to generate and activate, it took an evening of fiddling to create a useable cert on my "House CA" and I've learned lots in the process too. Even scored some firmware bugs (alas no bounty)

Richard N
  • 141
  • 3