在网络安全领域，加密算法是确保数据传输安全的重要组成部分。传输层安全协议 (TLS) 的作用远不止于此。TLS 构建了一个更高级别的安全体系，涵盖了比简单加密更广泛、更深层次的安全考量。

TLS 所处理的问题远不仅仅是加密和解密。它构建了一个基于公钥基础设施 (PKI) 的信任体系。这个体系可以验证通信双方的身份、确保数据完整性，并实现加密传输。这意味着，TLS 不仅仅是关于加密数据，更是关于建立一种可信赖和安全的通信方式。

TLS 不仅仅在于保护数据的安全性，更重要的是确保整个通信过程的安全性。它构建了一个复杂而强大的安全体系，不仅关乎数据的加密，更关乎通信双方的可信度、数据的完整性以及通信过程的安全性。因此，TLS 不仅仅是一个加密算法，而是构建了一个可靠且全面的安全保障体系。

中间人攻击和抓包工具

Fiddler 等抓包工具能够截取 HTTPS 通信的原因，其实涉及到中间人攻击 (Man-in-the-Middle，MitM) 和 SSL/TLS 的交互方式。

虽然 TLS 加密是确保网络通信安全的标准，但在特定情况下，抓包工具仍能截取 HTTPS 通信内容。TLS (传输层安全性协议) 用于加密 HTTP 连接，确保在客户端和服务器之间传输的数据是加密的。这种加密是端对端的，即只有客户端和服务器之间才能解密和读取数据。

Fiddler 之类的工具利用中间人攻击的方法，伪装成服务器与客户端通信，从而使得通信的两端分别与 Fiddler 建立加密连接，实现了中间的解密和再加密，以便于 Fiddler 读取和修改数据。

在实际工作中，Fiddler 安装了自己的证书。当设备信任该证书时，Fiddler 就能够在客户端和服务器之间插入自己的数字证书进行通信。客户端认为它与服务器直接通信，但实际上客户端与 Fiddler 建立了加密连接，而 Fiddler 与服务器之间也建立了加密连接。这样一来，Fiddler 实际上是在两个加密通道之间，可以解密和查看数据，然后再加密转发给对方，造成了中间人攻击的情况。

这种情况下，Fiddler 能够解密 HTTPS 包的内容。但需要强调的是，这种操作是在用户明示同意的前提下进行的，通常用于调试和分析网络通信。对于安全性高的生产环境来说，这种操作是不被允许的。

实际上，安全浏览器和应用程序都会对这种中间人攻击进行检测和阻止，以确保通信的安全性。

防范中间人攻击

为了防范此类攻击，TLS 1.3 和新一代的安全协议增强了加密算法和安全性，以使中间人攻击变得更加困难。一些网络安全措施和证书校验机制也在不断加强，以防止中间人攻击和数据泄露。

抓包工具能够解密 HTTPS 的包，是因为它们利用中间人攻击原理，在客户端和服务器之间插入自己的加密通道。但这种操作是需要用户明示同意并在受控环境下进行的。对于生产环境和隐私数据的通信来说，这种操作是不被允许的。

网络安全协议的不断更新和加强证书校验等措施，都是为了防范和避免这类攻击的发生。

api是https的为什么还能解析出来

由于HTTP协议过于简单：通信使用明文（不加密），内容可能会被窃听。 不验证通信方的身份，因此可能遭遇伪装。 无法验证报文的完整性，所以有可能已遭篡改。 2、HTTPS的实质。 HTTP加上加密处理、认证机制、以及完整性保护后的就是HTTPS。 需要知道的是，HTTPS并非是应用层的一种新的协议。 只是HTTP通信接口部分用SSL或TLS协议代替而已。 也就是说，所谓的HTTPS，其实就是身披SSL协议外壳的HTTP。 值得一提的是，SSL是独立于HTTP协议的，也就是说其他运行在应用层的协议均可配合SSL协议使用。 现今SSL是最为广泛的网络安全技术。 3、SSL和TLS。 HTTPS中使用了SSL和TLS这两个协议。 TLS以SSL3.0为基准，后又制定了TLS1.0、TLS1.1和TLS1.2。 当前主流的版本是SSL3.0和TLS1.0。 TLS是以SSL为原型开发的协议，有时候会统称该协议为SSL。 HTTPS的加密原理。 近代的加密算法中加密算法是公开的，而密钥是保密的。 通过这种方式来保持加密方法的安全性。 加密和解密要用到密钥，如果没有密钥就没有办法对密码解密。 换句话来说，任何人只要持有密钥就能够对密文进行解密。 HTTPS在加密过程中使用了非对称加密技术和对称加密技术。 对称加密算法采用单钥密码系统的加密方式，同一个密钥可以同时做信息的加密和解密，这种加密的方法称为对称加密，也称为单密钥加密。 下面会把对称加密算法称为共享密钥加密算法。 假如现在，SSL在通信过程中，使用了对称加密算法，也就是说客户端和服务器同时共享一个密钥。 于是，以共享密钥的方式加密，必须将密钥发给对方。 这个时候，假如通信过程被监听，密钥被攻击者获取了，那么这个时候也就失去了加密的意义了。 非对称加密算法。 与对称加密算法相反，非对称加密算法需要两个密钥来进行加密和解密，这两个密钥是配对的，分别是公开密钥（公钥）和私有密钥（私钥）。 一般情况下，公钥是可以被公开的，它主要用来加密明文。 而相应的，私钥不能被公开，用来解密公钥加密的密文。 以上，公钥加密私钥解密用来加密，私钥加密公钥解密用来签名。 相关用途后面会讲到。 下面会把非对称加密算法称为公开密钥加密算法。 于是现在，假设现在由服务器来生成一对公钥和私钥。 当客户端第一次发请求和服务器协商的时候，服务器就生成了一对公钥和私钥。 服务器把公钥发给客户端（明文，不需要做任何加密），客户端接收后，随机生成一个密钥，使用服务器发过来的公钥进行加密。 客户端把使用公钥加密的密钥发给服务器，服务器接收到了以后，用配对的私钥进行解密，就得到了客户端随机生成的那个密钥。 这个时候，客户端和服务端所持的密钥都是相同的。 此时，交换密钥环节就完成了。 于是通信开始时就可进行上面所述的共享密钥加密方式来进行加密。 同时使用为什么要大费周章使用非对称加密的方式，然后再得到相同的密钥，进行共享密钥加密的通信呢？由于公开密钥加密处理起来比共享密钥加密方式更为复杂，因此在通信的时候使用公开密钥加密的方式，效率很低。 我们需要使用非对称加密的方式来保证密钥共享的过程中密钥的安全性，而后在通信的过程中使用对称加密算法，这是最合理的设计方式，在保证安全性的同时又保证了性能。 所以，HTTPS采用共享密钥加密和公开密钥加密两者并用的混合加密机制。 在**交换密钥使用环节使用公开密钥加密方式**，之后**建立的通信交换报文阶段则使用共享密钥加密**方式。 大概就是使用对称加密和非对称加密的过程。 看似过程很完美，其实还存在着一个问题，就是：如何保证服务器传过来的公开密钥的正确性。 换句话说，就是保证它不被拦截篡改。

HTTPS 为什么安全? 真的安全吗?

一、HTTPS 为什么安全

HTTPS，也称作 HTTP over TLS，TLS 前身是 SSL，会有各个版本。

TLS协议在TCP/IP协议栈中的关系

上图描述了在TCP/IP协议栈中TLS(各子协议）和 HTTP 的关系。HTTP+TLS 也就是 HTTPS，和 HTTP 相比， HTTPS的优势：

上面内容参考了HTTPS工作原理。（石头在N 久前用印象笔记收藏的，现在好多原文访问不了了）

HTTPS 原理

上图就是大致介绍了 HTTPS 的握手流程，感兴趣的同学可以用 WireShark 抓包详细看看其中的每一个步骤，有助于理解 HTTPS 的完整流程。这里，我就不详述了。

大致就是客户端和服务端通过“握手会谈”商量出一个双方支持的加密算法和相应随机参数，得到一对密钥，后续的传输的内容都通过这对密钥进行加解密。

这对密钥很牛皮，比如要加密传输消息『tangleithu』，客户端通过公钥加密得到的密文『xyyaabbccdd』进行传输，服务端用自己的私钥对密文解密，恰好能得到『tangleithu』。中间错一位都不行，这样就保证了数据完整和隐私性。

因此，你在通过 HTTPS 访问网站的时候，就算流量被截取监听，获取到的信息也是加密的，啥实质性的内容也看不到。

例如，如下图所示，当我访问某个网站，此时通过 wireshark 抓包得到的信息，能获得仅仅是一些通信的IP地址而已。

HTTPS加密传输

这下放心了吗？

摸鱼的过程中，就算访问的 IP 地址被知道了，好像也无关紧要？

其实，有了 IP 地址也能获取不少信息了。

还好这个 IP 搜出来是 github，而不是……

你或许会高兴，连个网站域名都看不到，可以放心摸鱼了。不过，这是真的吗？

二、HTTPS 真的安全吗？

HTTPS 真的完全安全吗？连访问的域名都获取不到？答案是否定的。

上述 HTTPS 在握手阶段有一个很重要的东西 —— 证书。

—— 域名裸奔

当访问 HTTPS 站点时，会首先与服务器建立 SSL 连接，第一步就是请求服务器的证书。

当一个 Server IP 只对应一个域名（站点）时，很方便，任意客户端请求过来，无脑返回该域名（服务）对应的证书即可。但 IP 地址（IPv4）是有限的呀，多个域名复用同一个 IP 地址的时候怎么办？

服务器在发送证书时，不知道浏览器访问的是哪个域名，所以不能根据不同域名发送不同的证书。

因此 TLS 协议升级了，多了 SNI 这个东西，SNI 即 Server Name Indication，是为了解决一个服务器使用多个域名和证书的 SSL/TLS 扩展。

现在主流客户端都支持这个协议的。别问我怎么知道这个点的，之前工作上因为这个事情还费了老大劲儿……

它的原理是：在与服务器建立 SSL 连接之前，先发送要访问站点的域名（Hostname），这样服务器会根据这个域名返回一个合适的证书。此时还没有办法进行加解密，因此至少这个域名是裸奔的。

如下图所示，上面的截图其实是访问网站的抓包情况，客户端发送握手请求时，很自觉带上了自己的域名。

因此，即便是 HTTPS，访问的域名信息也是裸奔状态。你上班期间访问小电影网站，都留下了痕迹，若接入了公司网络，就自然而然被抓个正着。

除了域名是裸奔外，其实还有更严重的风险，那就是中间人攻击。

2.中间人攻击

前面也提到 HTTPS 中的关键其实在于这个证书。从名字可以看出来，中间人攻击就是在客户端、服务器之间多了个『中介』，『中介』在客户端、服务器双方中伪装对方，如下图所示，这个『MitmProxy』充当了中间人，互相欺骗：

可以安装 MitmProxy 或者 Fiddler 之类的抓包软件尝试一把，然后开启代理。

此时用手机访问网络，得到的信息如下：

证书信任前

提示，连接不是私密连接，其实就是浏览器识别了证书不太对劲，没有信任。而如果此时手机安装了 Fiddler 的证书，就会正常访问。

证书信任后可正常访问

因此，当你信任证书后，在中间人面前，又是一览无余了。

而如果你用了公司电脑，估计你有相应的操作让信任证书吧，或者手机上是否有安装类似的客户端软件吧？

抓紧时间看看手机的证书安装明细

三、如何防止信息安全，反爬

前面提到，要实施中间人攻击，关键在于证书是否得到信任。浏览器的行为是证书可以让用户授权是否信任，而 APP 就可以开发者自己控制。

比如我尝试通过类似的方式对某匿名社区进行抓包解密 HTTPS，但最终失败了，为什么呢？

这就要谈到『SSL Pinning』技术。

App 可以自己检验 SSL 握手时服务端返回的证书是否合法，“SSL pinning” 技术说的就是在 App 中只信任固定的证书或者公钥。

因为在握手阶段服务端的证书必须返回给客户端，如果客户端在打包的时候，就把服务端证书放到本地，在握手校验证书的环节进行比较，服务端返回的证书和本地内置的证书一模一样，才发起网络请求。否则，直接断开连接，不可用。

当然，一般情况下，用这种技术也就能防止 HTTPS 信息被解密了。

不过，也还有其他的技术能够破解这种方法，比如 Android 下的一些 Hook 技术，具体而言就是绕过本地证书强校验的逻辑。感兴趣的同学可以抱着学习目的研究一下。不过据说这种方式需要对系统进行 Root、越狱等，需要一些更高权限的设置。

因此，也告诫我们，一定不要乱安装一些软件，稍不注意可能就中招，让自己在互联网上进行裸奔。一方面个人隐私信息等泄露，另外一个方面可能一些非常重要的如账户密码等也可能被窃取。

四、可能的监控手段有哪些？

办公电脑当然要接入公司网络，通过上面介绍的内容，你也应该知道，你在什么时候浏览了哪些网站，公司其实都是一清二楚的。

若自己的手机如果接入了公司网络也是一模一样（连 Agent 软件都不需要装）。这就提醒我们，私人上网尽量用自己的移动网络呀。

上面提到，如一些涉及隐私的敏感信息，如一些 PC 软件、手机 App 自己内部加密传输的话，内容加密（包括但不限于 HTTPS）不被破解也问题不大。

不过，这当然依赖这些软件设计者的水平了。比如同一个匿名用户对外展示的 ID 不能相同，如果是同一个的话也恰好暴露了逻辑漏洞。

当然，我们还是不要抱有侥幸心理，在监管的要求下，如果确实有一些违法等不恰当的言论等，始终还是有门路找到你的。

更何况，一般办公电脑都会预安装一些公司安全软件，至于这些软件究竟都干了些什么，有没有进行传说中悄悄截图什么的，这就因人（公司）而异了。（不讨论类似行为是否涉及到侵犯了员工隐私等问题）