HTTP与HTTPS有什么区别：先检查地址和证书

先给一个有条件的答案：如果地址以http://开头，这次请求走的是未加密的HTTP；如果以https://开头，走的是用TLS加密的HTTP。按惯例，未加密的HTTP默认在80端口交换，TLS加密的流量默认在443端口交换。

这个判断只回答“传输有没有加密”，不回答“网站可不可信”。地址栏写https://，说明这次连接用了TLS；它不说明网站内容真实、不说明商家正规，也不说明页面没有恶意代码。

一个自建情境（示例，不是对某个真实网站的记录）：你在练习目录里放了一个自己写的测试页，用本地或公开地址打开它，先看地址栏开头写的是http还是https，再看开发者工具里这次请求落在哪个端口。这两项是当场能看到的，不需要额外工具。

适用范围：本文只讲如何从地址和证书判断传输是否加密，以及怎么查看证书。不教绕过证书警告，也不把HTTPS当成网站可信的证明。

HTTPS的“S”来自TLS。按MDN的说明，TLS提供三种主要服务，它们回答的是三个不同问题。

第一，身份验证。通信的每一方都可以验证另一方的身份。在浏览器访问网站这个场景里，主要是你验证服务器是不是它声称的那一方，这一步靠证书完成。

第二，加密。在用户代理和服务器之间传输数据时对数据加密，防止未经授权的第三方读取和解读。

第三，完整性。TLS确保数据在加密、传输和解密过程中不会丢失、损坏、篡改或伪造。

这三项要分开理解。加密解决的是“别人看不看得懂”，完整性解决的是“路上有没有被改”，身份验证解决的是“对面是不是它说的那个”。只看到地址栏有锁形图标，通常说明连接用了TLS，但不能据此推断网站运营者是谁、内容是否可靠。

一个历史背景有助于理解叫法：HTTPS推出时基于Netscape的SSL 2.0，后来更新为SSL 3.0，1999年1月IETF在RFC 2246中规定了TLS 1.0，当前版本为TLS 1.3（RFC 8446）。尽管web现在用TLS加密，很多人仍习惯称它为“SSL”。

查看证书是只读操作，不改动网站，也不改动你的系统设置。下面以浏览器自带的证书查看入口为例，所有步骤都是编辑整理的观察方法，不是对某个真实网站的测试记录。

1. 打开一个https://开头的页面。

2. 在地址栏左侧找到连接状态入口（通常是锁形图标或站点信息按钮），点开。

3. 在展开的面板里找到“证书”或“连接安全”一类的入口，打开证书详情。

4. 在详情里看几项：颁发给谁（使用者）、由谁签发（颁发者）、有效期起止时间、以及证书链。

5. 只看，不点“继续访问”“添加例外”这类按钮。

看证书时重点核对两件事。第一，证书上的域名和你地址栏里的域名是否一致。第二，有效期是否覆盖当前日期。这两项对不上，浏览器通常会给出警告，这时应停止操作，而不是想办法跳过。

本文不教绕过证书警告的方法。证书警告出现时，可执行的动作是：确认地址是否输错、确认网络环境是否被改动、联系网站方核实，而不是强行继续。

TLS连接以握手阶段开始，客户端和服务器在这个阶段就共享秘密和重要参数达成一致，然后进入数据交换模式，交换应用数据（如HTTP）。

握手协商的主要参数是密码套件。在TLS 1.2及更早版本中，协商密码套件包括一组加密算法，共同提供共享秘密的协商、服务器身份验证方法和数据加密方法。TLS 1.3中的密码套件主要用于数据加密，密钥协议和身份验证使用单独的协商方法。

这解释了一个常见现象：不同网站、甚至同一网站在不同时间，证书面板里显示的加密参数可能不一样。参数不同不代表连接一定不安全，也不代表一定安全，它取决于协商出的具体套件和配置。

TLS 1.3有几处与旧版本不同的设计：握手在大多数情况下一次往返完成；服务器可以启用0-RTT握手，但文档提示0-RTT存在重放攻击风险，启用前需要谨慎；TLS 1.3仅支持前向安全模式，除非连接恢复或使用预共享密钥；除建立共享秘密所需的信息外，握手过程都是加密的，服务器和客户端证书因此也是加密的，但客户端发送的服务器名称（SNI扩展名）不加密。

这些是协议层面的说明，不是让你去改服务器配置。本文只帮你读懂证书面板里看到的信息。

所有主流浏览器在2020年初开始取消对TLS 1.0和1.1的支持。按MDN的说明，从版本74开始，Firefox在连接使用旧版TLS的服务器时会返回Secure Connection Failed错误。

这意味着：如果你访问某个站点时看到连接失败或安全连接错误，原因可能是该服务器仍在使用旧版TLS，而不是你的浏览器坏了。可执行的动作是联系网站方，请其升级到TLS 1.2或1.3，而不是降低浏览器安全设置去迁就它。

另一个相关机制是握手超时。从版本58开始，Firefox实现了TLS握手超时，默认值为30秒。如果握手因某种原因变得缓慢或反应迟钝，会严重影响体验，超时机制就是为缓解这一点而设。

这两个现象都说明：HTTPS连接能不能建立，取决于客户端和服务器双方支持的版本和参数是否匹配。地址栏写https://只是起点，实际连接是否成功、用了什么参数，要看握手结果。

这是全文最需要单独记住的一条：HTTPS只说明这次连接用了TLS，不说明网站本身可信。

原因在于TLS三项服务的作用范围。身份验证验证的是“服务器是不是它声称的那一方”，也就是证书上的域名和签发关系；它不验证这家网站的经营资质、不验证页面内容是否真实、不验证商品是否合格。加密保护的是传输过程，不保护你自愿提交的信息被对方如何使用。完整性保护的是数据在路上没被改动，不保护服务器本身有没有被入侵。

所以看到https://和锁形图标时，可以得出的结论是：这次传输经过加密。不能得出的结论包括：网站正规、内容可靠、可以放心付款、可以放心填写个人信息。

一个自建情境（示例）：你在练习目录里维护一个自建页面，用本地地址打开它，地址栏可能显示为http://或带警告的https://。这只是练习环境的表现，不能用来推断任何真实网站的安全性。

本文不宣称HTTPS代表网站绝对可信，也不把证书检查当成安全审计。

看完证书后，建议把结果写成几条可核对的记录，而不是只记一句“看起来没问题”。以下是编辑整理的记录格式，不是官方模板。

1. 地址：这次访问用的是http://还是https://。

2. 域名：证书上写的域名和地址栏域名是否一致。

3. 有效期：起止日期，当前日期是否在范围内。

4. 颁发者：证书由谁签发。

5. 警告：浏览器有没有给出证书警告，警告内容是什么。

6. 处理：如果出现警告，你做了什么（停止访问、联系网站方、换用其他渠道核实）。

这样记录的好处是，下次再遇到同类情况时，你能对照上次的记录，看出是域名变了、证书换了，还是有效期到了。

需要说明的限制：本文只讲查看证书和记录结果，不涉及服务器端配置、不涉及证书申请流程，也不提供任何绕过警告的操作。证书检查是只读的，不会修改网站或你的系统。