What is the difference between HTTP and https? The browser prompted "Not secure" to pay attention to, so I grabbed a packet that clearly showed the server version in plaintext

incident started when my wife was out of town and wanted to upload photos of our NAS. A page of red warnings popped up on the webpage: "Your connection is not private." She took a screenshot and sent me a screenshot: Has our NAS been hacked? I glanced at it and laughed—that was a certificate I signed for myself, just not recognized by the browser. I just clicked advanced to continue visiting. But she wasn't at ease and kept asking me when to pay attention to this warning and when not to take it. I was stunned—I see this every day, but I've never really thought about it from the beginning. That night, I wrote a dozen lines of packet capture script in Python, connecting http and https respectively. After reading the output, I finally understood what that browser lock was actually locking.

let's first catch a packet: port 80 is completely naked, port 443 is all garbled text

don't care how the book defines it; even once you do it is clearer than reading ten popular science articles. I use a Python socket, which is the most basic bare connection. First, I connect to an HTTP site's port 80 and manually send the simplest GET request. The returned item is printed directly on the screen, looking like this:

HTTP/1.1 403 Forbidden / Date: Sat, 03 Oct 2026 / Server: Apache/2.4.68 / Content-Type: text/html

look closely, the whole round of back-and-forth was human speech. Every device on the road can read the software, version, minute, and type of page the server uses. This is just an ordinary page without an account. If this were an HTTP login page, the username and password you type would be in plaintext, running naked from your router, optical modem, carrier data center, to the other server. Whenever someone wants to see a section of the road, grab a bag and you'll have it all.

Then I aligned the same bare connection with port 443, which is the port used for https. This time, no matter what I sent, the other party only replied with five bytes: \x15\x03\x03\x00\x02\x02. This isn't garbled text error; it's the TLS protocol telling me, 'Your handshake is wrong, try again.' From this moment on, every serious word spoken between the two sides had to be encrypted, and every package caught along the way was this abrupt ByteDance. On the same website, 80 and 443 have two doors: one opens its door for chatting, the other first sets the password before closing it. This is the fundamental difference between HTTP and HTTPS.

What is

little lock locking: three things, missing even one doesn't count

the little lock in the address bar doesn't just focus on "encryption"—it does three things at once. First, encrypted can't be peeked in; if caught on the road, you'll only see garbled text, account passwords, and chat content; Second, integrity and cannot be changed. Even if half a byte of data is altered halfway, the receiver can verify and discard it immediately; Third, identity and not impersonation. If you connect to a shunot.com, a third party will come out to guarantee this is a shunot.com server, not an identical fake page set up by hackers next door.

the third thing is the certificate. A certificate is like a letter of introduction stamped by a notary office, stating whose domain it owns, when it expires, and who guarantees it. I used curl's Verbose mode to check my site's certificate, and the output explained the issue well: SSL connection using TLSv1.3 / subject: CN=shunot.com / issuer: Let's Encrypt. Translated: TLS 1.3 for encryption, domain name shunot.com, guarantor by Let's Encrypt, a public certificate authority. The browser recognizes Let's Encrypt, so it doesn't trigger warnings.

By the way, in the early days, you had to pay for a certificate to access HTTPS, but now institutions like Let's Encrypt issue certificates for free and renew automatically for three years, so almost all the legitimate websites you see online use HTTPS. The rest still running HTTP are mostly router backend pages that "only browse your own home," which leads to the following question.

browser prompts "Not secure"—three scenarios, three ways to handle it

figure out what Xiao Suocuo is, you can give various triage prompts. I made a list for my wife: three situations and three attitudes:

first explain the first point: why do I still use HTTP in the background of a router? The 192.168.1.1 address doesn't require going out at all; data only travels a two-meter network cable between your home WiFi and router, with no carrier or public network in between. To capture this explicit text, you have to sneak into your home network first, and those who can get into your WiFi can change your router settings without needing to capture packets—just log in to the background. So the risk is not explicitly stated. I wrote about the WiFi password lock in the WPA2 and WPA3 articles; that is for wireless connectivity, while HTTPS is for two different paths.

second option is beyond negotiation. Any page starting with HTTP that asks you to enter your account and password is like writing your password on a postcard and sending it out. Even worse, when ISPs or public WiFi sites insert ads into HTTP pages, pop-ups appear for no apparent reason. I wrote in the about routers being hacked, but basically, it's plaintext pages where anyone can edit twice. Hotel WiFi and mall free internet—especially don't touch the HTTP login page.

NAS those scary red text alerts, why click "Continue Access"

the third type is the kind the wife encounters, which is also the easiest to scare people. When your NAS or router opens HTTPS in the background, most certificates are signed by the device itself. The introduction letter is written by the device, and the seal is carved by the user. If the browser doesn't recognize this guarantor, it will pop up a whole page of red text. This doesn't necessarily mean it's being hated; it just means "no one endorses this device."

only one way to judge: confirm that you are indeed connected to your own device and that the network environment is you trust. On the home WiFi, enter the NAS internal network address, and the red text says the self-visa form or expired certificate, so feel free to go for more advanced access and continue accessing it. Conversely, if you access any remote device under hotel networks or unfamiliar WiFi, the certificate may appear incorrect, or if the red text says "The certificate does not belong to this domain" or "The certificate was issued by an unknown organization but you think it must be a big company," don't click continue; try switching to mobile data first. I mentioned in my previous article WebDAV how to open : Synology's encrypted port 5006 with the phone's file app, when first connected to the phone, it will mumble a bit, trust once, and remember—it's the same thing.

So when my wife did that, I remotely instructed her to check two things: whether the server name in the red text was for our NAS, and whether she was connected to our broadband. All right, click continue, done. She said it scared me to death. I said the red text blocked people who "dare to go down without verifying," and the original intention was good.

Conversely: Why does losing 192.168.1.1 get forced to jump https and then fail to open

also has a reverse pitfall, which I want to clarify. Some people enter 192.168.1.1 in their browser and it automatically changes to https://192.168.1.1, but then the router won't open in the background no matter what, and the screen spins white. Because the router's backend only opens the HTTP door, and the browser upgrades you to HTTPS by memory, which means you knock on the wrong door and blame the other party for not opening it. This has nothing to do with whether the device is broken or not. The solution is to enter the address in full, add the http:// prefix, and press Enter. Mobile browsers love this. I logged into the router backend phone that post and noted this pitfall. If it keeps popping no matter how much you type, try a different browser or clear the site's data. If the browser records 'this site must be https,' it's invalid. login page won't open that article has a complete search order.

Which doors should be locked and which don't matter: Pause for two seconds before entering the password

in my own home, I divided all the networked devices' backends into two levels. HTTPS required: those accessible from the public network, such as the NAS remote backend, router remote management page, and monitoring remote page. These are true 'postcards traveling far.' Once you go to HTTP, the password is exposed on the public network, and with just one password in these backends, you can access all your data. I wrote about the consequences of public network exposure in my article about NAS anti-ransomware . If the device itself doesn't support HTTPS, don't expose its backend directly to the public network. Either go VPN home, or simply turn off the remote system. Nothing about HTTP: Only run in the backend of your own internal network—router, optical modem, printer. Just set the backend password. The risk of plaintext is just eight miles behind the password or admin.

develop a two-second habit: before entering your password on any page, glance at the beginning of the address bar. https starts with a closed lock, lose; login pages starting with http, stop; On the red alert page, first confirm who is connected before deciding. This habit costs nothing, and works better than any security software. I also checked if the router's backend had unfamiliar port mappings. That was another door I often forgot to close, which I wrote about specifically in UPnP . The door was guarded; Mingwen, the naked, the impersonator, couldn't get in.