HTTPS 的实现原理
公钥私钥简介：
公钥（Public Key）与私钥（Private Key）是通过加密算法得到的一个密钥对（即一个公钥和一个私钥，也就是非对称加密方式）。公钥可对会话进行加密、验证数字签名，只有使用对应的私钥才能解密会话数据，从而保证数据传输的安全性。公钥是密钥对外公开的部分，私钥则是非公开的部分，由用户自行保管。
通过加密算法得到的密钥对可以保证在世界范围内是唯一的。使用密钥对的时候，如果用其中一个密钥加密一段数据，只能使用密钥对中的另一个密钥才能解密数据。例如：用公钥加密的数据必须用对应的私钥才能解密；如果用私钥进行加密也必须使用对应的公钥才能解密，否则将无法成功解密。
SSL证书和TLS证书
SSL
定义：
SSL 是指安全套接字层，可确保互联网连接安全，保护两个系统之间发送的任何敏感数据，防止被人读取和修改任何传输信息，包括个人资料。两个系统可能是指服务器和客户端（例如，浏览器和购物网站），或两个服务器之间（例如，含个人身份信息或工资单信息的应用程序）。
原理：
SSL证书采用公钥体制，利用一对互相匹配的密钥对进行数据加密和解密。每个用户自己设定一把特定的、仅为本人所知的私有密钥（私钥），并用它进行解密和签名；同时设定一把公共密钥（公钥）并由本人公开，为一组用户所共享，用于加密和验证签名。
由于密钥仅为本人所有，可以产生其他人无法生成的加密文件，也就是形成了数字签名。
SSL证书是一个经证书授权中心（CA）数字签名的、包含公开密钥拥有者信息以及公开密钥的文件。最简单的证书包含一个公开密钥、名称以及证书授权中心的数字签名。数字证书还有一个重要的特征就是只在特定的时间段内有效。
TLS
定义：
原理：
TLS主要分为两层，底层的是TLS记录协议，主要负责使用对称密码对消息进行加密。
上层的是TLS握手协议，主要分为握手协议，密码规格变更协议和应用数据协议4个部分。
- 握手协议负责在客户端和服务器端商定密码算法和共享密钥，包括证书认证，是4个协议中最最复杂的部分。- 密码规格变更协议负责向通信对象传达变更密码方式的信号- 警告协议负责在发生错误的时候将错误传达给对方- 应用数据协议负责将TLS承载的应用数据传达给通信对象的协议。
证书内容
| 颁发机构信息 | 颁发机构信息 | 颁发机构信息 |
|---|---|---|
| 公钥 | 公钥 | 公钥 |
| 公司信息 | 公司信息 | 公司信息等 |
三次握手四次挥手
三次握手
名词：
SYN：同步标志
同步序列编号(Synchronize Sequence Numbers)栏有效。该标志仅在三次握手建立TCP连接时有效。它提示TCP连接的服务端检查序列编号，该序列编号为TCP连接初始端(一般是客户端)的初始序列编号。在这里，可以把 TCP序列编号看作是一个范围从0到4，294，967，295的32位计数器。通过TCP连接交换的数据中每一个字节都经过序列编号。在TCP报头中的序列编号栏包括了TCP分段中第一个字节的序列编号。
ACK：确认标志
确认编号(Acknowledgement Number)栏有效。大多数情况下该标志位是置位的。TCP报头内的确认编号栏内包含的确认编号(w+1，Figure-1)为下一个预期的序列编号，同时提示远端系统已经成功接收所有数据。
SEQ：序号
用来标识从TCP发端向TCP收端发送的数据字节流，它表示在这个报文段中的的第一个数据字节。如果将字节流看作在两个应用程序间的单向流动，则TCP用序号对每个字节进行计数。序号是32bit的无符号数，序号到达232－1后又从0开始。
ISN：初始化序列号
在建立tcp三次连接的时候，存储在序列号位置中的数字的代称。也就是说，告诉对方我将要开始发送的初始化序列号是多少，两边都要发这个ISN，即tcp三次连接中第一个SYN包和第二个SYN+ACK的包都有这个。
原理：
| 序号 | 方向 | seq | ack | SYN | ACK |
|---|---|---|---|---|---|
| 1 | A—>B | 10000(ISN) | 0 | 1 | 0 |
| 2 | A<—B | 20000(ISN) | 10000+1=10001 | 1 | 1 |
| 3 | A—>B | 10001 | 20000+1=20001 | 0 | 1 |
刚开始客户端处于 Closed 的状态，服务端处于 Listen 状态。 进行三次握手：
:::info
第一次握手：客户端给服务端发一个 SYN 报文，并指明客户端的初始化序列号 ISN(c)。此时客户端处于 SYN_SEND 状态。
首部的同步位SYN=1，初始序号seq=x，SYN =1的报文段不能携带数据，但要消耗掉一个序号。
注意：x代表随机数
例：序号1【seq=10000,SYN=1】
:::
第二次握手：服务器收到客户端的SYN 报文之后，会以自己的 SYN 报文作为应答，并且也是指定了自己的初始化序列号 ISN(s)。同时会把客户端的 ISN + 1 作为ACK 的值，表示自己已经收到了客户端的SYN ，此时服务器处于 SYN_RCVD 的状态。不能携带数据。 在确认报文段中SYN =1，ACK=1，确认号ack=x+1，初始序号seq=y。 注意：y代表随机数 例：序号2【seq=20000,ack=10000+1=10001,SYN=1,ACK=1】
:::success
第三次握手：客户端收到SYN 报文之后，会发送一个 ACK 报文，当然，也是一样把服务器的 ISN + 1 作为 ACK的值，表示已经收到了服务端的 SYN 报文，此时客户端处于 ESTABLISHED 状态。服务器收到ACK 报文之后，也处于 ESTABLISHED 状态，此时，双方已建立起了连接。
确认报文段ACK=1，确认号ack=y+1，序号seq=x+1（初始为seq=x，第二个报文段所以要+1），ACK报文段可以携带数据，不携带数据则不消耗序号。
例：序号3【seq=10001,ack=20001,ACK=1】
:::
问题：
1.为什么必须三次：
因为三次才能确认双方的接受与发送能力是否正常。
| 序号 | 动作 | 判断体 | 客户端发 | 客户端收 | 服务端发 | 服务端收 |
|---|---|---|---|---|---|---|
| 第一次握手 | 客户端发，服务端收 | 服务端得出 | Y | Y | ||
| 客户端得出 | ||||||
| 第二次握手 | 服务端发， 客户端收 | 服务端得出 | Y | Y | Y | |
| 客户端得出 | Y | Y | Y | |||
| 第三次握手 | 客户端发， 服务端收 | 服务端得出 | Y | Y | Y | Y |
| 客户端得出 | Y | Y | Y | Y |
解释：
第二次握手只能通过客户端得出：服务端的接收、发送能力，客户端的接收、发送能力是正常的。不过此时服务器并不能确认客户端的接收能力是否正常。
第三次握手，将服务端发送的返回给了客户端，所以服务端也可以得出：客户端的接收、发送能力正常，服务器自己的发送、接收能力也正常。
2.为什么只有第三次握手才可以携带数据
第一次握手不可以放数据，原因避免让服务器更加容易受到攻击了。如果已经完成三次握手，此时客户端已经处于 ESTABLISHED 状态。对于客户端来说，已经建立起连接了，并且也已经知道服务器的接收、发送能力是正常。
3.syn攻击是什么
服务器端的资源分配是在二次握手时分配的，而客户端的资源是在完成三次握手时分配的，所以服务器容易受到SYN洪泛攻击。SYN攻击就是Client在短时间内伪造大量不存在的IP地址，并向Server不断地发送SYN包，Server则回复确认包，并等待Client确认，由于源地址不存在，因此Server需要不断重发直至超时，这些伪造的SYN包将长时间占用未连接队列，导致正常的SYN请求因为队列满而被丢弃，从而引起网络拥塞甚至系统瘫痪。SYN 攻击是一种典型的 DoS/DDoS 攻击。
# 检测是否被攻击netstat -n -p TCP | grep SYN_RECV
四次挥手：
名词：
URG：紧急标志
紧急(The urgent pointer) 标志有效。
PSH：推标志
该标志置位时，接收端不将该数据进行队列处理，而是尽可能快将数据转由应用处理。在处理 telnet 或 rlogin 等交互模式的连接时，该标志总是置位的。
FIN：结束标志
带有该标志置位的数据包用来结束一个TCP回话，但对应端口仍处于开放状态，准备接收后续数 据。
原理：
| 序号 | 方向 | seq | ack | FIN | ACK |
|---|---|---|---|---|---|
| 1 | A->B | 80000 | 90000 | 1 | 1 |
| 2 | A<-B | 90000 | 80000+1=80001 | 0 | 1 |
| 3 | A<-B | 90000 | 80001 | 1 | 1 |
| 4 | A->B | 80001 | 90000+1=90001 | 0 | 1 |
:::success
第一次挥手：当客户端没有内容发送给服务端时，客户端会发送一 FIN 报文，报文中会指定一个序号。此时客户端处于 FIN_WAIT1 状态，等待服务端的确认。
连接释放报文段: FIN =1，seq=u
例：序号1【FIN=1,seq=80000】
:::
第二次挥手：服务端收到FIN 之后，会发送 ACK 报文，且把客户端的序列号值 +1 作为 ACK 报文的序列号值，表明已经收到客户端的报文了，此时服务端处于 CLOSE_WAIT 状态。 确认报文段: ACK=1，确认号ack=u+1，序号seq=v 例：序号2【ACK=1 , ack=80000+1=80001 , seq=90000】
:::info
第三次挥手：如果服务端也想断开连接了，和客户端的第一次挥手一样，发给 FIN 报文，且指定一个序列号。服务端进入LAST_ACK（最后确认）状态，等待客户端的确认。
连接释放报文段: FIN=1(注意：服务端的)，序号seq=w(注意：服务端的)，ACK=1，确认号ack=u+1
例：序号3【ACK=1 , FIN=1 , seq=90000 , ack =80000+1=80001】
:::
:::success
第四次挥手：客户端收到 FIN 之后，一样发送一个 ACK 报文作为应答，且把服务端的序列号值 +1 作为自己 ACK 报文的序列号值，此时客户端处于 TIME_WAIT 状态。需要过一阵子以确保服务端收到自己的 ACK 报文之后才会进入 CLOSED 状态，服务端收到 ACK 报文之后，就处于关闭连接了，处于 CLOSED 状态。 客户端收到服务端的连接释放报文段后，客户端进入TIME_WAIT（时间等待也称之为2MSL）状态。此时TCP未释放掉，需要经过时间等待计时器设置的时间2MSL后，客户端才进入CLOSED状态。
确认报文段：ACK=1，seq=u+1，ack=w+1
例：序号4【ACK=1 ，seq=80000+1=80001 , ack=90000+1=90001】
:::
问题：
1.为什么必须四次：A代表客户端，B代表服务端
| 序号 | A发 | A收 | B发 | B收 | 结论 | |
|---|---|---|---|---|---|---|
| 第一次 | Y | 客户端向服务端发送结束标志FIN | 客户端：FIN_WAIT1(终止等待) | |||
| 第二次 | Y | 服务端收到结束标志，用客户端的seq+1作为ack返回 | 服务端：CLOSE_WAIT(关闭等待) | |||
| 第三次 | Y | 服务端向客户端发送结束标志FIN | 服务端：LAST_ACK(最后确认) | |||
| 第四次 | Y | 客户端收到结束标志，用服务端的seq+1作为ack返回,服务端收到后直接关闭，客户端，等待2MSL后，进入close | 服务端：TIME_WAIT—->close 客户端：TIME_WAIT—->close |
解释：当服务端发送结束标志时，只会先回复，通知客户端你发送的结束标志收到，等到我服务端所有 的报文都发送完了，服务端发送FIN报文
2.什么是2MSL：
Maximum Segment Lifetime：报文段最大生存时间。2MSL代表两倍的最大报文时间
3.等待2MSL的作用：
无法保证网络可以将客户端ACK报文完整的发送到服务端，网络不佳可能会造成客户端的确认标志 ACK丢失，所以等待2MSL可以用来重发可能丢失的ACK确认标志报文。
若有收获，就点个赞吧
0 人点赞
