你真的懂 HTTPS 吗？SSL、TLS 的关系，90% 的人都搞错了

首页

业界动态

热心网友

转载

2026-04-17

前言：HTTPS 不是“多了个 S”这么简单

对于开发者而言，HTTPS早已是日常：浏览器地址栏里的小锁图标、接口强制要求的安全连接、还有时不时蹦出来的证书过期提醒……这一切都再熟悉不过。但如果被问到下面这个问题，你的答案会是什么？

免费影视、动漫、音乐、游戏、小说资源长期稳定更新！ 👉 点此立即查看 👈

HTTPS、SSL、TLS 到底是什么关系？

常见的回答往往是：“SSL就是HTTPS吧？”、“TLS是SSL的升级版？”或者“HTTPS不就是HTTP加了个密吗？”。

这些说法听起来似乎都对，但严格推敲起来，都不够完整和准确。事实上，HTTPS、SSL、TLS是三个不同层级、各司其职的概念。它们紧密协作，但绝不相互替代。厘清这三者的关系，你对网络安全、数字证书乃至服务端架构的理解，会立刻清晰许多。

接下来，我们就一次性把这个问题讲透。

图片

一图先立概念

SSL / TLS 是“加密协议”，HTTPS 是“应用协议”。

可以这样理解：SSL/TLS协议负责底层所有的“脏活累活”——定义如何加密、如何验证身份、如何防止数据被篡改。而HTTPS呢？它负责规定如何以HTTP的方式传输数据，但强制要求这些数据必须走在SSL/TLS搭建好的安全通道里。

换句话说，一个关键的事实是：

HTTPS 本身不加密，它只是“借用了” SSL / TLS 的能力

SSL 是什么？它当年解决了什么问题？

SSL 的诞生背景

时间回到1995年，网景公司（Netscape）提出了SSL（安全套接层）。在那个年代，互联网通信，尤其是HTTP协议，存在三个致命的缺陷：数据完全明文传输，你的账号密码如同在网络上“裸奔”；你无法确认正在通信的对方是不是你真正想访问的服务器，中间人冒充起来轻而易举；传输中的数据还可能被悄无声息地篡改。

SSL的诞生，目标非常明确：就是要让互联网通信变得“看不见、改不了、冒充不了”。

SSL 解决的三大安全核心

SSL的设计理念始终围绕着三个核心安全目标：

① 保密性（Confidentiality）

所有传输的数据都会被加密。即便数据包在传输途中被截获，攻击者看到的也只是一堆乱码，无法解读其真实内容。

② 身份认证（Authentication）

通过数字证书机制来验证服务器的真实身份。这就像查看一个人的官方身份证，可以有效防止你访问到伪造的“钓鱼网站”。

③ 数据完整性（Integrity）

通过消息认证码等机制，确保数据在传输过程中没有被篡改。任何对内容的非法修改都会被通信双方发现。

SSL 到底加密了哪些内容？

实际上，在SSL/TLS通道中，所有HTTP承载的内容都得到了保护，包括但不限于：用户提交的用户名和密码、浏览器中的Cookie和Session信息、表单提交的所有数据、API请求和响应的参数与结果，以及服务器返回的任何敏感信息。

为什么现在几乎不再提 SSL？

原因很简单：早期的SSL协议（如SSL 2.0和3.0）已被证实存在严重的安全漏洞，不再安全。因此，现代浏览器和标准早已全面禁用这些旧协议。虽然“SSL”这个名词的精神和框架得以延续，但协议本身已经正式“退休”了。

TLS 是谁？它和 SSL 是什么关系？

TLS 的真实身份

TLS 是 SSL 的最新继任者，而不是一个全新的东西

你可以把TLS看作是SSL的“现代化升级版”。TLS 1.0在内部版本号上就被标记为SSL 3.1，这充分说明了两者的继承关系。它并非推倒重来，而是在SSL的设计理念上，对安全性和所用算法进行了全面强化和更新。

TLS 相比 SSL，改进了什么？

简单来说，TLS主要在三方面做了重大改进：增强了加密算法的强度和灵活性、优化了握手过程以提升性能和安全性、移除了已知的不安全加密套件。所以，如今在互联网上真正服役的安全协议，是TLS 1.2和更为现代、高效的TLS 1.3。

为什么我们还经常说“SSL 证书”？

这主要是一个历史习惯的延续。虽然底层协议早已升级为TLS，但行业内外仍然习惯性地将用于TLS握手的数字证书称为“SSL证书”。这就好比很多人依然把家里的光纤宽带服务叫作“装宽带”一样，是一种约定俗成的叫法。

HTTPS 到底是什么？它干了哪部分活？

HTTPS 的本质定义

HTTPS = HTTP + SSL/TLS 安全层

这个“+”号是关键。HTTPS本身并不定义新的加密算法，它的核心职责是：强制要求HTTP通信必须经过TLS安全层的处理。它在应用层（HTTP）和传输层（TCP）之间插入了一个安全层，从而保证了通信的安全。

HTTP 和 HTTPS 的核心差异

最根本的差异就在于那个“S”所代表的安全层。HTTP数据直接在TCP连接上明文传输，而HTTPS的数据则在发送前先经过TLS层的加密和封装，再通过TCP传输。

HTTPS 请求真实发生了什么？

一个简化的HTTPS请求流程是这样的：首先，浏览器向服务器发起一个HTTPS连接请求；接着，服务器会返回其数字证书；浏览器收到证书后，会校验其合法性（是否由可信机构签发、是否过期、域名是否匹配等）；验证通过后，双方会协商出一套对称加密算法和密钥；至此，TLS安全通道正式建立。此后，所有HTTP协议的数据都会在这个加密通道中传输。看，真正负责加密、验证、密钥交换这些“重活”的，是TLS协议，HTTPS更多是扮演了一个“调度者”和“规则制定者”的角色。

一次完整 HTTPS 通信，TLS 做了哪些事？

TLS 握手阶段核心步骤

TLS握手是安全通道建立的关键，其核心步骤包括：客户端发送“ClientHello”消息，声明自己支持的TLS版本和加密套件；服务器回应“ServerHello”消息，选定双方都将使用的加密套件，并附上自己的数字证书；客户端验证服务器证书，并使用证书中的公钥加密一个预主密钥发送给服务器；双方利用这个预主密钥，各自生成相同的会话密钥。握手完成后，双方就会使用这个高效的对称会话密钥来加密后续所有的应用层数据，而非对称加密只在最初的握手阶段用于安全地交换这个对称密钥。

代码实战：Spring Boot 启用 HTTPS（优化版）

目录结构示例

/opt/app/
├── cert/
│   └── server.p12
├── config/
│   └── application.yml
└── app.jar

application.yml 配置

server:
  port: 8443
  ssl:
    enabled: true
    key-store: file:/opt/app/cert/server.p12
    key-store-type: PKCS12
    key-store-password: changeit
    key-alias: icoderoad

Spring Boot 启动类包名规范

package com.icoderoad.https;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

@SpringBootApplication
public class HttpsApplication {
    public static void main(String[] args) {
        SpringApplication.run(HttpsApplication.class, args);
    }
}

强制 HTTP 跳转 HTTPS

package com.icoderoad.https.config;

import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.web.SecurityFilterChain;
import org.springframework.context.annotation.Bean;

@Configuration
public class HttpsRedirectConfig {
    @Bean
    public SecurityFilterChain filterChain(HttpSecurity http) throws Exception {
        http
            .requiresChannel(channel ->
                channel.anyRequest().requiresSecure()
            );
        return http.build();
    }
}