文章目录
前言
什么是HTTPS？
超文本传输安全协议（英语：Hypertext Transfer Protocol Secure，缩写：HTTPS，常称为HTTP over TLS，HTTP over SSL或HTTP Secure）是一种网络安全传输协议。具体介绍以前先来介绍一下以前常见的HTTP，HTTP就是我们平时浏览网页时候使用的一种协议。HTTP协议传输的数据都是未加密的，也就是明文，因此使用HTTP协议传输隐私信息非常不安全。HTTP使用80端口通讯，而HTTPS占用443端口通讯。在计算机网络上，HTTPS经由超文本传输协议（HTTP）进行通信，但利用SSL/TLS来加密数据包。HTTPS开发的主要目的，是提供对网络服务器的身份认证，保护交换数据的隐私与完整性。这个协议由网景公司（Netscape）在1994年首次提出，随后扩展到互联网上。
SSL，即传输层安全，是一种用C语言编写的加密协议，在计算机网络上提供通信安全。它通过使用加密来保护数据的完整性和保密性。
TLS，即传输层安全，是一种在互联网上进行安全通信的标准。它允许客户/服务器应用程序以一种旨在防止窃听和篡改信息的方式在网络上通信。
一、为什么需要加密？
因为http的内容是明文传输的，明文数据会经过中间代理服务器、路由器、wifi热点、通信服务运营商等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了。劫持者还可以篡改传输的信息且不被双方察觉，这就是中间人攻击。所以我们才需要对信息进行加密。最容易理解的就是对称加密 。
常见的加密方式：
对称加密：
- 采⽤单钥密码系统的加密⽅法，同⼀个密钥可以同时⽤作信息的加密和解密，这种加密⽅法称为对
称加密，也称为单密钥加密，特征：加密和解密所⽤的密钥是相同的- 常⻅对称加密算法(了解)：DES、3DES、AES、TDEA、Blowfish、RC2等
- 特点：算法公开、计算量⼩、加密速度快、加密效率⾼
- 对称加密其实就是通过同⼀个"密钥",把明⽂加密成密⽂,并且也能把密⽂解密成明⽂
非对称加密
- ⾮对称加密需要两个密钥来进⾏加密和解密，这两个密钥是公开密钥和私有密钥。
- 常⻅⾮对称加密算法(了解)：RSA，DSA，ECDSA
- 特点：算法强度复杂、安全性依赖于算法与密钥但是由于其算法复杂，⽽使得加密解密速度没有对称加密解密的速度快。
- 公钥和私钥是配对的.最⼤的缺点就是运算速度⾮常慢，⽐对称加密要慢很多：
通过公钥对明⽂加密,变成密⽂，通过私钥对密⽂解密,变成明⽂
数据摘要&&数据指纹
- 数字指纹(数据摘要)，其基本原理是利⽤单向散列函数(Hash函数)对信息进⾏运算，⽣成⼀串固定⻓度的数字摘要。数字指纹并不是⼀种加密机制，但可以⽤来判断数据有没有被窜改。
- 摘要常⻅算法：有MD5、SHA1、SHA256、SHA512等，算法把⽆限的映射成有限，因此可能会有碰撞（两个不同的信息，算出的摘要相同，但是概率⾮常低）
- 摘要特征：和加密算法的区别是，摘要严格意义不是加密，因为没有解密，只不过从摘要很难反推原信息，通常⽤来进⾏数据对⽐
二、只用对称加密可以吗？
如果通信双⽅都各⾃持有同⼀个密钥X，且没有别⼈知道，这两⽅的通信安全当然是可以被保证的（除
⾮密钥被破解）
引⼊对称加密之后，即使数据被截获，由于⿊客不知道密钥是啥，因此就⽆法进⾏解密，也就不知道请求的真实内容是啥了。
但事情没这么简单，服务器同⼀时刻其实是给很多客户端提供服务的，这么多客户端,每个⼈⽤的秘钥都必须是不同的(如果是相同那密钥就太容易扩散了,⿊客就也能拿到了)，因此服务器就需要维护每个客户端和每个密钥之间的关联关系，这也是个很⿇烦的事情~
⽐较理想的做法,就是能在客⼾端和服务器建⽴连接的时候,双⽅协商确定这次的密钥是啥~
但是如果直接把密钥明⽂传输，那么⿊客也就能获得密钥了~~此时后续的加密操作就形同虚设了，
因此密钥的传输也必须加密传输!
但是要想对密钥进⾏对称加密，就仍然需要先协商确定⼀个"密钥的密钥"，这就成了"先有鸡还是先有
蛋"的问题了，此时密钥的传输再⽤对称加密就⾏不通了。
三、只使用非对称加密
鉴于⾮对称加密的机制，如果服务器先把公钥以明⽂⽅式传输给浏览器，之后浏览器向服务器传数据
前都先⽤这个公钥加密好再传，从客户端到服务器信道似乎是安全的(有安全问题)，因为只有服务器有
相应的私钥能解开公钥加密的数据。
但是服务器到浏览器的这条路怎么保障安全？
如果服务器⽤它的私钥加密数据传给浏览器，那么浏览器⽤公钥可以解密它，⽽这个公钥是⼀开始通
过明⽂传输给浏览器的，若这个公钥被中间⼈劫持到了，那他也能⽤该公钥解密服务器传来的信息
了。
四、双方都使用非对称加密
- 服务端拥有公钥S与对应的私钥S'，客户端拥有公钥C与对应的私钥C'
- 客户和服务端交换公钥
- 客户端给服务端发信息：先⽤S对数据加密发送，只能由服务器解密，因为只有服务器有私钥S'
- 服务端给客户端发信息：先⽤C对数据加密发送，只能由客户端解密，因为只有客户端有私钥C'
这样貌似也⾏啊，但是效率太低！！！但也有安全问题！！！
五、使用非对称加密+对称加密
我们用对称加密提高效率：
- 服务端具有⾮对称公钥S和私钥S'
- 客户端发起https请求，获取服务端公钥S
- 客户端在本地⽣成对称密钥C，通过公钥S加密，发送给服务器
- 由于中间的⽹络设备没有私钥,即使截获了数据，也⽆法还原出内部的原⽂，也就⽆法获取到对称密钥(真的吗？)
- 服务器通过私钥S'解密，还原出客户端发送的对称密钥C，并且使⽤这个对称密钥加密给客户端返回的响应数据
- 后续客户端和服务器的通信都只⽤对称加密即可，由于该密钥只有客户端和服务器两个主机知道，其他主机/设备不知道密钥即使截获数据也没有意义
看似天衣无缝，但实际上还存在安全问题！如果从最开始，中间人就开始攻击了呢？
- 服务器具有⾮对称加密算法的公钥S，私钥S'
- 中间⼈具有⾮对称加密算法的公钥M，私钥M'
- 客户端向服务器发起请求，服务器明⽂传送公钥S给客户端
- 中间⼈劫持数据报⽂，提取公钥S并保存好，然后将被劫持报⽂中的公钥S替换成为⾃⼰的公钥M，并将伪造报⽂发给客⼾端
- 客户端收到报⽂，提取公钥M(⾃⼰当然不知道公钥被更换过了)，⾃⼰形成对称秘钥X，⽤公钥M加密X，形成报⽂发送给服务器
- 中间⼈劫持后，直接⽤⾃⼰的私钥M'进⾏解密，得到通信秘钥X，再⽤曾经保存的服务端公钥S加密后，将报⽂推送给服务器
- 服务器拿到报⽂，⽤⾃⼰的私钥S'解密，得到通信秘钥X
- 双⽅开始采⽤X进⾏对称加密，进⾏通信。但是⼀切都在中间⼈的掌握中，劫持数据，进⾏窃听甚⾄修改，都是可以的
问题本质出在哪⾥了呢？客户端⽆法确定收到的含有公钥的数据报⽂，就是⽬标服务器发送过来的！
六、引入证书
服务端在使⽤HTTPS前，需要向CA机构申领⼀份数字证书，数字证书⾥含有证书申请者信息、公钥信息等。服务器把证书传输给浏览器，浏览器从证书⾥获取公钥就⾏了，证书就如⾝份证，证明服务端公钥的权威性。
下图截自《图解TCP/IP》:
证书本身的传输过程中，如何防止被篡改？即如何证明证书本身的真实性？身份证运用了一些防伪技术，而数字证书怎么防伪呢？
1.如何放防止数字证书被篡改？
我们把证书原本的内容生成一份"签名"，比对证书内容和签名是否一致就能判别是否被篡改。这就是数字证书的"防伪技术"，这里的"签名"就叫数字签名：
数字签名的制作过程：
- CA机构拥有非对称加密的私钥和公钥。
- CA机构对证书明文数据T进行hash。
- 对hash后的值用私钥加密，得到数字签名S。
浏览器验证过程：
- 拿到证书，得到明文T，签名S。
- 用CA机构的公钥对S解密（由于是浏览器信任的机构，所以浏览器有它的公钥），得到S'。
- 用证书里指明的hash算法对明文T进行hash得到T'。
- 显然通过以上步骤，T'应当等于S'，除非明文或签名被篡改。所以此时比较S'是否等于T'，等于则表明证书可信。
2.中间人有可能篡改该证书吗？
假设中间人篡改了证书的原文，由于他没有CA机构的私钥，所以无法得到此时加密后签名，无法相应地篡改签名。浏览器收到该证书后会发现原文和签名解密后的值不一致，则说明证书已被篡改，证书不可信，从而终止向服务器传输信息，防止信息泄露给中间人。
3.中间人有可能掉包该证书吗？
假设有另一个网站B也拿到了CA机构认证的证书，它想劫持网站A的信息。于是它成为中间人拦截到了A传给浏览器的证书，然后替换成自己的证书，传给浏览器，之后浏览器就会错误地拿到B的证书里的公钥了，这确实会导致上文"中间人攻击"那里提到的漏洞？
其实这并不会发生，因为证书里包含了网站A的信息，包括域名，浏览器把证书里的域名与自己请求的域名比对一下就知道有没有被掉包了。
4.怎么证明CA机构的公钥是可信的？
让我们回想一下数字证书到底是干啥的？没错，为了证明某公钥是可信的，即"该公钥是否对应该网站"，那CA机构的公钥是否也可以用数字证书来证明？没错，操作系统、浏览器本身会预装一些它们信任的根证书，如果其中会有CA机构的根证书，这样就可以拿到它对应的可信公钥了。
实际上证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推，我们把它叫做信任链或数字证书链。也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。
5.每次进行HTTPS请求时都必须在SSL/TLS层进行握手传输密钥吗？
每次请求都经历一次密钥传输过程非常耗时，那怎么达到只传输一次呢？
服务器会为每个浏览器（或客户端软件）维护一个session ID，在TLS握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了！