SSL? What is it?
今天跟花菜还有红莲去 120 搬显示器，在等师兄来盖章的过程中，讨论了下 HTTPS 协议和 HTTP/2.0 协议，收获颇丰，故写篇总结加深印象。
SSL 是什么？
SSL（Secure Sockets Layer）是运行在应用层协议和 TCP 协议之间的
安全套接层协议，在传输层对网络连接进行加密。SSL 协议分为两层。SSL 记录协议和SSL 握手协议，记录协议建立在 TCP 协议上，为高层协议（HTTP 等）提供数据封装，压缩，加密等基本功能的支持。握手协议，建立在 SSL 记录协议之上，在真正的数据传输开始之前，对通信双方的身份进行认证，协商加密算法，计算对话密钥等。
为什么要有 SSL
HTTP 通信是明文的，没有加密的，存在着三大风险
- 窃听风险: 通信内容会被第三方获知
- 篡改风险: 通信内容存在被篡改的风险
- 冒充风险: 黑客可以冒充身份参与通信
为了解决这三个风险，SSL 就出生了。HTTPS 就是利用了 SSL 协议.或者是升级了的 SSL 协议（TLS）
对称加密是什么
加密和解密使用一份相同的密钥，密钥泄漏的话，通信的内容就会被任何知道密钥的人解密。所以对称加密主要是要注意密钥的保密性。
公式：
发送方： E(明文，密钥) = 密文
接收方： D(密文，密钥) = 明文
对称加密算法有 AES, DES 等。用得比较多的是 AES 算法。
非对称加密又是什么
非对称加密是指，通信双方分别持有一个不同的密钥，称作私钥和公钥。一般来说，私钥和公钥是相对的，两者都可以用来加密解密，一般公开的就是公钥，而私密的不为人知的就是私钥了。公钥加密的数据只能被私钥解密，而私钥加密的数据，也只能被公钥解密。保证这种加密的可靠性就是需要保证私钥的保密性，公钥是明文传输的。
公式：
E(明文，公钥) = 密文
D(密文，私钥) = 明文
或者也可以
E(明文，私钥) = 密文
D(密文，公钥) = 明文
就是说，公钥和私钥都可以用来加密和解密，用一种密钥加密，只有另外一种密钥可以解密。公钥被人篡改怎么办呢？这时数字证书就出现了.看下面解释.
SSL 用哪种加密算法？
SSL 协议握手阶段利用非对称加密来产生对话密钥（Session Secret），之后就利用对话密钥来对通信信息进行对称加密。
所以说，SSL 其实是两种加密算法都使用到了。
如何解决三大风险呢？
解决窃听风险
将传输数据加密，接收方用密钥来解密数据.因此就算数据被监听到了，也无法知道具体含义，不过劫持数据的一方可以对服务器或者客户端进行重放攻击，就是将劫持到的加密数据原封不动地重新发送给接收方，从而达到攻击的目的。解决重放攻击的方法大概有三种：
- 添加时间戳。 发送方发送报文的时候需要加上当前时间的时间戳，接收方根据本地时间和接收到的报文的时间戳进行对比，如果不符合，则丢弃这个信息。
- 加随机数。每个报文都添加一个随机数（唯一的），如果某个随机数重复出现，则说明是遇到了重放攻击。
- 加流水号。递增的流水号，只要接收到不连续的流水号报文，就说明可能是重放攻击。
解决篡改风险
首先就是要先加密了，加密后的数据，没有密钥是修改不了的。再而就是可以用过数字签名。
数字签名。 可以通过 RSA 加密算法来实现.
具体实现步骤如下.
假如是从客户端发送消息，将要发送的信息先用 Hash 函数（将任意长度的数据映射为固定长度）生成一份信息摘要，然后再用公钥把摘要加密，生成了数字签名，将数字签名跟消息一起发送。接收方（这里是服务端）收到报文就先把签名拿出来，用私钥解密签名，得到发送方发送的消息的摘要，再用与发送方一样的 hash 函数，对消息进行处理，得到接受到的消息的摘要，两者对比，就可以判断说数据是否改变。而原理呢就是利用 hash 函数的特性。一个数据只要修改了一点点，对应的 hash 值都会变化很大，所以可以用来比较是否被修改过。而且 hash 是不可逆的。
画个图加深印象：
同理服务端发送添加数字签名也是这样，只是是用私钥来加密，然后客户端用公钥来解密获得摘要并与收到的消息进行对比。
个人觉得这里的消息可以是明文的也可以是加密过的。如果发送的是 CA 机构（证书颁发机构）颁发的数字证书的话，一般证书的内容会包含证书颁发者的数字签名（CA 机构用自己的私钥来加密信息摘要）和一份被颁发对象的公钥，这份公钥就是明文的了。这就是明文的一种情况。还有一种情况就是，你发送的消息也需要加密，并且需要一份数字签名来防止被篡改，这时就需要
解决冒充风险
数字签名只是解决了发送数据有没有被篡改的问题，具体发送方是谁并没有办法知道，这时候只能让发送方出示它的身份证，也就是数字证书。
配备数字证书。通过数字证书来识别身份。
数字证书是网上的身份证明。
对应的有客户端证书，服务端证书。
CA & 数字证书
CA：证书颁发机构
一台服务器要为客户端提供 SSL 服务，首先得向 CA 申请一份证书，用于证明自己
证书一般包括：
- 申请者的域名
- 签发机构 CA
- 有效期
- 公钥
- 指纹（签名）
- 等等…如下图
SSL 是如何做到的？& SSL 握手阶段
SSL 四次握手。由客户端发起。
clientHello：客户端向服务端 sayHello，告诉服务端说想要建立 SSL 协议，并告诉它我支持的协议版本还有支持的加密算法（一般是 RSA），并且还有发送一个随机数
RNc（用于待会生成对话密钥）SeverHello：服务端先确认支持的协议版本，如果协议版本不符合，则关闭 SSL 握手。否则，还有发送一个随机数
RNs（用于待会生成对话密钥），服务器证书，还有就是确认跟客户端一样的加密算法。并向客户端要求客户端证书（如果客户端有的话）来识别客户端身份clientEnd： 首先验证证书（TL;DR 客户端先取得证书里的数字签名，用
CA的公钥（一般浏览器会内置CA根证书，包含了CA的公钥）解密，获得摘要，再将数字证书用 hash 函数进行处理，得到另一个摘要，与前者比较，若没有变化，说明证书有效，没被篡改），如果客户端有客户端证书就发送证书，若无，则发送客户端的公钥。再生成一个随机数PMS(pre-master-secret), 用服务端的公钥加密后发送，再发送一个签名public key(hash(先前发的全部消息))。serverEnd: 接受到客户端的消息，验证签名，由三个随机数使用与客户端约定好的某种计算方式来生成
对话密钥，对话密钥不会传输，而是通信双方根据前面使用非对称加密来握手产生的三个随机数来生成，为什么要使用三个随机数？因为单独使用一个 PMS 来生成对话密钥的话，并不能保证说客户端每次生成的 PMS 都是一个新的随机数，所以就存在这个随机数可能被猜出来的可能性，用三个随机数来生成的话，三个随机数的随机度就基本可以保证每次会话的对话密钥都不一样。所以采用三个随机数来生成对话密钥。客户端此时也使用约定好的计算方法计算出对话密钥。
之后的通信，都是采用对称加密，因为非对称加密比较耗性能，花费时间会增加，之前的 SSL 握手就是先利用非对称加密（RSA）来生成一个对话密钥，用于对称加密，对称加密的性能会更好，速度更快，同时这个对话密钥由于是如上生成的，所以也很安全。
SSL 解决的问题
SSL 解决了三大风险
窃听风险： 信息都是加密的。
篡改风险： 利用 RSA 算法生成数字签名来规避这个风险
冒充风险： 利用数字证书。可信的 CA 机构发布的数字证书就是一个服务端的身份证。而对于客户端的防冒充来说，如果没有客户端证书，服务端则得到的是客户端的公钥，那么只有拥有正确私钥的客户端才能解密消息，所以也规避了客户端冒充的风险。
而平常通信的验证客户端的方式是给客户端分发一个 sessionId.每次客户端发送消息都会带上这个 sessionId（一般存在 cookie 里）
in the end
HTTPS 是未来的主流。得空把自己的网站搞个小绿锁。