你大概见过浏览器地址栏那把小锁，也听过"要用 HTTPS 网站才安全"。但 HTTPS 究竟在保护什么、它是怎么做到的，很多人讲不清。本文用尽量少的术语，把 TLS（HTTPS 的核心协议）的工作逻辑捋一遍。
一、明文传输的风险
早期 HTTP 是"明文"的：你发出的账号密码、聊天内容，在网络链路上是原样传输的。任何能接触到这条链路的人——公共 Wi-Fi 的运营者、中间节点——都能直接读到。这就像把明信片塞进邮筒，沿途谁都能拆开看。
HTTPS 就是给这封信套了个信封。信封里的东西，只有你和目标网站能解开，中间人看到的是一团无意义的数据。
二、对称加密：快，但有个鸡生蛋问题
加密分两类。对称加密像一把锁配一把钥匙：双方用同一把密钥加密解密，速度快，适合大量数据。问题是：密钥本身怎么安全地交给对方？如果通过网络明文发密钥，密钥被截获，后面全白搭。这就是"鸡生蛋"难题。
TLS 的解法是"混合加密"：先用非对称加密安全地交换一把临时密钥，之后所有通信改用对称加密。既解决了密钥分发，又保住了性能。想直观感受加密前后的差异，可以用加密工具把一段文字加密，看看输出如何变成不可读的密文。
三、非对称加密与证书
非对称加密有两把钥匙：公钥和私钥。公钥可以公开，私钥必须保密。用公钥加密的东西，只有对应的私钥能解开。网站把自己的公钥放在"数字证书"里，由受信任的证书机构（CA）签名背书，证明"这个公钥确实属于某某网站"。
你的浏览器内置了一堆受信任 CA 的名单。访问网站时，浏览器验证证书签名是否有效、域名是否匹配、有没有过期。任何一项不对，就会弹出"不安全"警告——这是在提醒你：对方身份可能不实，继续传输有风险。
四、哈希：校验完整性，而非保密
加密防止窃听，但还要防止"内容被偷偷篡改"。这就需要哈希。哈希函数把任意长度的数据压缩成一串固定长度的"指纹"，且几乎不可能从指纹反推原文，原文哪怕改一个字，指纹都会大变。
网站经常把文件的哈希值公布出来，你下载后用文件哈希生成算一遍本地指纹，和官方比对，一致说明文件没被植入木马。这跟 HTTPS 保护通信是两条互补的防线。
五、Base64：不是加密，是编码
顺带澄清一个常见误解：Base64 常被误认为加密，其实它只是编码——把二进制数据转成纯文本字符，方便在只认文本的环境里传输（比如邮件、URL）。它没有任何保密作用，谁都能用Base64 转换还原。HTTPS 握手过程中会用到各类编码，但真正提供安全的是前面的加密与证书机制。
小结
HTTPS 不是单一技术，而是一套组合拳：用非对称加密解决密钥分发，用对称加密保护通信内容，用证书确认身份，用哈希保证完整。那把小锁背后，是现代网络最基础也最关键的一层信任。理解它，你就不会再随意在"不安全"的网站上输入任何敏感信息。