# HTTPS的原理 三四年前还在上学的时候就看了HTTPS，只知道个大概，脑子里的概念比较模糊。最近在B站上看到一个讲的比较清楚的视频，趁着空闲就又理了一遍，并且重新整理了以下以前的笔记。 ### HTTP的安全性 HTTP在传输过程中使用明文传输，其安全性是无法保障的。这里的安全性主要指两点： * 数据必须是正确的，未被篡改的 * 数据内容私密，不可被他人截取查看 HTTP的安全性的保证在许多场景下是必要的，比如购物、网上银行等等。http的安全问题，可描述为三种： * 窃听风险 * 篡改风险 * 冒充风险 ![img](https://2351062869-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7b2CdwBN9liniVJpfEAc%2Fuploads%2Fgit-blob-22a35a628fe2d87b0d592d66d969e7a516f68485%2Fimage-1596955253017.png?alt=media) ![file](https://2351062869-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7b2CdwBN9liniVJpfEAc%2Fuploads%2Fgit-blob-5b51ddcb4480ca5f6777bf428271956ccc98523b%2Fimage-1596955260150.png?alt=media) 所以出现了 **HTTPS**，他会将报文进行加密，然后传输，从而解决安全问题： ![file](https://2351062869-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7b2CdwBN9liniVJpfEAc%2Fuploads%2Fgit-blob-8d2943211e5ec722cf32892b43a9e7c793c84c30%2Fimage-1596955267326.png?alt=media) ### 什么是HTTPS HTTP，Hyper Text Transfer Protocol over *Secure Socket Layer*，是以安全为目标的HTTP通道，即安全的HTTP。实现原理是在HTTP下加入SSL（ *Secure Socket Layer*）层，SSL层负责将报文进行加密解密。 ![file](https://2351062869-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7b2CdwBN9liniVJpfEAc%2Fuploads%2Fgit-blob-dd5bc3d72f873519d25d4501988611ed1a6a9a82%2Fimage-1596955281388.png?alt=media) > TLS 是SSL的加强版。 #### 与HTTP的区别 * HTTPS协议需要申请CA证书，大部分需要收费。 * HTTP是明文传输，HTTPS则是由HTTP和SSL或者TSL协议构建的可以进行加密传输、身份认证的协议，比HTTP协议安全。 * HTTPS端口号为443，而HTTP则是80端口，并且他们的连接方式不同(因为TCP上方需要进行加密)。 ### SSL是如何加密的？ 常用的加密方式分为两种： * 对称加密 * 非对称加密 #### 对称加密 * 对称加密算法是公开的 * 其安全性是依赖密钥的 * 对数据进行对称加密，需要使用一个密钥，解密时，需要相同的密钥解密 ``` ** 对称加密 ** 假设对称加密算法为 f1()， 对称解密算法为 f2()，密钥为key，数据为 data，加密后数据为 datax 那么就有 f1(key, data) = x // 加密 f2(key, x) = data // 解密 ``` **对称加密的优点:** * 计算量小，加密于解密速度较快，适合加解密较大的数据 **对称加密的缺点：** * 密钥传输容易泄漏，一个用户需要对应一个密钥，服务器密钥管理较为复杂 **常见的对称加密算法有：** * DES（强度低，易破解） * 3DES（仍易破解，在DES的基础上又进行了三次DES） * AES （强度相对较高，破解难度大） **假设使用对称加密，我们来看传输流程：** ![img](https://2351062869-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7b2CdwBN9liniVJpfEAc%2Fuploads%2Fgit-blob-5cc613c2a99a60e3e8a159e6d2630627b72552ad%2Fimage-1596955301884-20211208161850306-8951533.png?alt=media) 使用对称加密有如下几个问题： 1. 服务端为每个客户端提供不同的key，这样做key的存储和管理是很困难的，并且key有被劫持的风险 2. 如果采用同一个key，那么黑客也会拿到Key，进行非法操作 所以对称加密不安全。 #### 非对称加密 * 非对称加密算法也是公开的 * 他的加密算法包含两个密钥，一个为公钥（public key），一个为私钥（private key） * 使用公钥加密、私钥解密； 如果使用私钥加密、只有公钥解密 * 因为加解密使用不同的密钥，所以称为非对称加密 ``` ** 非对称加密 ** 假设非对称加解密算法为T， 公钥为SK，私钥为PK，数据为 data，加密后数据为 datax 那么就有 T1(PK, data) = datax // 私钥加密 T2(SK, datax) = data // 公钥解密 --- T1(PK, data) = datax // 私钥加密 T2(SK, datax) = data // 公钥解密 即：私钥加密，公钥解密。 ``` **非对称加密的优点：** * 加密和解密采用不同的钥匙，可以传输公钥，数据传输相对安全 **非对称加密的缺点：** * 计算量大，加密解密的速度较慢 **常见的非对称加密算法如下：** * RSA **RSA加密算法过程：** ![img](https://2351062869-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7b2CdwBN9liniVJpfEAc%2Fuploads%2Fgit-blob-bb5c4d0b98263718cafe7757f56ba0de00a5386e%2Fimage-1596955329225-20211208161932045.png?alt=media) **假设采用非对称加密，我们来看请求流程：** ![img](https://2351062869-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F7b2CdwBN9liniVJpfEAc%2Fuploads%2Fgit-blob-97f7173e37a5c9b17bc7b40dae1f815006f3ab7c%2Fimage-1596955357632-20211208162001541.png?alt=media) 上述流程在客户端向服务端发送时，是没有明显问题的，因为黑客拿不到私钥，所以，黑客就不能对数据解密，而在服务端向客户端发送数据时，则有明显的问题： * 步骤6，由于客户端使用公钥解密数据，而公钥的信息是公开的 * 所以黑客也拥有公钥，所以黑客可以截获数据，然后加密伪造信息发给服务器 * 非对称加密的加密效率远低于对称加密，对于稍大的数据进行非对称加密，会非常耗时 所以非对称加密也不安全。 #### 对称和非对称结合 从上面的分析来看，单独使用对称加密或者非对称加密很难满足需求。对称加密在加密效率上有着较高的优势，但其缺点主要在于不能给每个用户设立一个唯一的key，如果可以则对称加密就安全了。假设不考虑key的存储问题，为每个客户端提供一个不同的key，如下： 如果密钥传输是绝对安全的，这种传输方式就是绝对安全的。但是步骤1和2的密钥获取的步骤，同样会有可能被黑客篡改。这样问题就从数据安全性的问题，转移到了 **对称加密的密钥安全传输的问题**。 为了保证对称加密的密钥传输的安全性，如果我们继续使用对称加密，则陷入了死循环 ，永远解决不了安全问题。如果使用非对称加密对密钥进行加密： * 假设非对称加密是安全的，那么对称密钥的发送就是安全的 * 但是，非对称加密的传输同样也不是安全的 * 在步骤1中，如果客户端请求公钥时，被黑客截获 * 黑客存储服务端的公钥，并返回自己的公钥钥给客户端 * 客户端使用错误的公钥发送隐私数据给服务端，黑客再次接获数据 * 黑客将内容解密（因为使用的是黑客的公钥），然后修改数据，再使用正确的公钥加密，发送给服务端 * 这样就完成了伪装篡改的目的 上述问题是典型的中间人问题。 #### CA和证书 为了解决中间人问题，引入了CA证书。中间人问题出现的原因主要因为是网站公钥的获取，client端获取的公钥有可能是中间人伪造的假的公钥。为了保证公钥的准确性，出现了一个CA机构。CA机构负责存储各个网站的公钥，只有CA机构认证过的公钥，才是合法公钥。 CA机构会使用非对称加密通过CA的私钥对网沾的公钥进行加密，加密后的内容就是证书。所以证书内容主要是公钥。客户端在请求公钥时，不再请求公钥，而是去请求证书。客户端得到证书后，需要得到CA的公钥才能解密证书，得到想要的网站公钥。 如果客户端通过网络从CA机构获取CA机构的私钥，这样仍然不安全，仍然会有中间人问题。所以CA机构的公钥，是存储在各大浏览器本地中，而不是通过网络获取。 #### 具体流程 1. C访问S，告知S，C所支持的SSL版本、使用的非对称加密算法、以及随机数 1 （标记此次请求） 2. S响应C，告知即将通讯的SSL版本、非对称加密算法、随机数2（标记此次响应）、以及证书（内容是网站公钥） 3. C端接受到证书，对证书进行认证 4. C访问S，生成随机数3，并将使用hash算法对随机数1, 随机数2进行签名，将签名值xx传给S 5. S收到请求，比对签名，确认是刚刚那个C端。通过特殊算法对随机数1、2、3进行处理，生成数字 k 6. S响应C，将随机数 1、2、3 进行签名，返回给C端 7. C接受响应后，同样对1、2、3进行签名，比对服务端的签名值。如果签名比较成功，那么C端也生成了数字k。这个k就是C端所需要的对称加密密钥。 --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://yangsx95.gitbook.io/notes/computer-science/ji-suan-ji-wang-luo/http/https-de-yuan-li.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.