SSL Certs Risk within Private LAN

[Inq (Inquisitor)]

I’ve done the above search with Google and the millions of hits aren’t really addressing my situation. I’m writing a microcontroller system that is meant to be inside of a local area network (not meant to be exposed outside). The original web server program that has been around for years, is on a microcontroller that can’t handle the SSL load. It’s finally gotten to the point that too many devices simply won’t browse with a plain http site… even internally on a private LAN. In this new incarnation, I want to use a real web server and because Caddy supports SSL so elegantly, I thought I’d give it a try.

The server is now on a Raspberry Pi Zero W and I’ve got a test page working with the simple Caddyfile:

RasDev.local {
	root * /var/lib/InqVault/ui
	file_server
}

Where RasDev is the RasPi’s computer name. This works just great on my LAN on Windows, Linux, Android and iPhone browsers and solves my main problem. It gives “Not secure” notices and makes me accept the “risks” before going to the page the first time. What I’d like to know from you web server and/or security experts is… what are those risks on the inside of a private LAN?

• I’ve looked in what the browser shows me is in this cert and everything is blank.
• Is there some more secure, intermedicate solution between this blank cert and having to register a URL and buying a real cert?
• I assume the traffic going across the WiFI airwaves is still encrypted, therefore that is certainly better than http.
• Does this blank cert make it easier for a hacker using WiFi sniffing packet reader gain entry into the LAN?

Thanks for any insight you might share.

VBR,
Inq

[francislavoie]

@Inq

because Caddy supports SSL

FYI, it’s been called TLS since 1999, SSL is dead.

@Inq

RasDev.local {

*.local TLD can sometimes be problematic because it’s used by Apple devices for mDNS. See .local - Wikipedia, weird things can happen if you try to use anything other than a machine’s name.

But in your case if you’re only ever going to serve one thing from Caddy, this might be fine.

I’d typically recommend using a different TLD like .home.arpa which is reserved for LAN use. This would let you do things like app1.your-server.home.arpa and app2.your-server.home.arpa, using subdomains for each app etc. You’d need to be running a DNS server in your LAN to make this work (pretty easy with something like CoreDNS, but that might be out of scope for your needs)

Also, domains are case insensitive, so best if you always use lowercase for consistency.

@Inq

It gives “Not secure” notices and makes me accept the “risks” before going to the page the first time.

What you’re supposed to do is grab Caddy’s root CA cert and install it on each device that will need to connect to it. That way, clients will always trust connections with Caddy.

Caddy generates certificates with short lifetimes, so unless you trust the root CA cert, you’ll be presented with that warning pretty frequently every time a new leaf cert is issued.

You can grab the root CA cert from Caddy’s storage (where that is depends on how you installed Caddy, and you didn’t fill out the help topic template so I don’t know how you did) or by using the API.

@Inq

I’ve looked in what the browser shows me is in this cert and everything is blank.

I’m not sure what you mean by “blank”, but it’s not a “blank cert”, because that’s not a thing.

@Inq

Is there some more secure, intermedicate solution between this blank cert and having to register a URL and buying a real cert?

No, buying a cert is not any more secure. There’s no legitimate reason to buy certificates anymore.

In the past, you were paying for “manual verification”, but now with services like Let’s Encrypt, domain verification is automated with the ACME protocol.

All a certificate is, is an envelope that carries a (domain) name, a public key and a signature; the signature is proof that some entity validated that the entity with that name does control the private half of the key (asymmetric public-private key pair).

Clients making requests to a server get handed the certificate, they look at it, do some trust checks against the certificate (is it signed by some certificate authority that I trust?) then uses the public key in that cert to encrypt the request being sent to the server, and the client also sends a public key that the server can use the encrypt its response.

There’s no need to pay for any of that.

@Inq

I assume the traffic going across the WiFI airwaves is still encrypted, therefore that is certainly better than http.

Yes, WiFi is already encrypted (using your WiFi password to derive an encryption key). That’s what WPA2 and WPA3 are, protocols for securing a WiFi connection.

That said, if you do have untrusted devices connected to your network, then yes you should be using HTTPS. But if you do trust the devices in your network to not try to intercept/tamper/sniff eachother’s traffic, then you can get away with only HTTP. But if someone untrusted is in your network, you’re probably fked anyway.

@Inq

Does this blank cert make it easier for a hacker using WiFi sniffing packet reader gain entry into the LAN?

Irrelevant, because WiFi is already encrypted as I said earlier. Different layers.

[Inq (Inquisitor)]

Thank you for your detailed response. It has highlighted a lot of gaps in my knowledge and I’m trying to go through it and catch up. It has brought up many questions, but has given me key-words to research and try out.

VBR,
Inq

[Inq (Inquisitor)]

Again, I appreciate the time and effort you took to help out and thank you for pointing out the necessary links to educate me.

From what I’m digging up from your comments, I’m finding this is not something I need to pursue. Although, I am quite willing to “grab Caddy’s root CA cert and install it on a device” for my own projects, the type of people that might use this system are not computer savvy enough and aren’t going to be willing to do the steps required on every device they want to access this server. Having to add a DNS server to their networks and have their device reset to route to it, use abstract names to access the server. These things are just way too heavy for the average user audience. I will just stick with HTTP.

Frankly, I’m a little embarrassed I asked. Of course there is no way for an app to use a self-signed cert and install themselves on someone’s private LAN and install those on all other internal devices. That’s like a politician saying, “Trust me! I won’t steal your $#!+”

Considering, my sole purpose was to get rid of the “Not secure” message at the top of a browser, they’ll just have to understand that their WPA is keeping their data secure. And really the data is not that significant (just sensor data) in binary format. One would have to not only sniff it, decrypt WPA, the data would just look like random binary data without headers, JSON or any other clues. It’ll be far easier to intercept the LoRa traffic in the system if they’re really that hungry for the data.