昨天顺手把站点上了HTTPS，但是为什么要上HTTPS，不能因为你浏览器给我显示‘安全’，我就认为他是安全的，还是要知根知底，不能知其然而不知其所以然，因此抽空了解一下。
本文所涉及的加密算法原理不做详解，具体可Google
先来了解下相关的基本术语
对称加密
symmetric encryption
对称加密所指的是加密和解密使用的相同密钥的加密算法，即使用密钥S加密的数据同时用密钥S解密。这种加密方法通常效率较高，但要求两个交换数据的实体都要持有相同的密钥。对称加密的关键问题是，密钥如何传递。
常见的对称加密算法有DES、AES、RC4等。
非对称加密
asymmetric cryptographic
非对称加密与对称加密相反，非对称加密需要2个密钥：私钥(Private Key)和公钥(Public Key)，这两者总是成对出现，并且公钥加密的数据只有私钥能够解密，相反，私钥加密的内容只有公钥能够解密；通常公钥是对外公开的，任何人都可以获取到，私钥不对外公开的。由于公钥是对外公开的，因此私钥加密的内容只要获得公钥的任何人都可以解开。
非对称加密与对称加密相比，因为其计算复杂，因此速度较慢。非对称加密对加密内容的长度还有限制，被加密的内容长度不能大于密钥长度。比如现在的密钥长度时2048位，那么被加密的内容长度不能超过256字节。
常见的非对称加密算法有RSA、Elgamal、ECC等。
非对称加密的作用：
- 防止信息泄露：公钥加密的只有私钥能解
- 身份验证：利用数字签名
数字摘要/消息摘要
digital digest/message digest
数字摘要是将数据通过单向HASH函数进行计算生成一串固定长度的散列值，不同数据产生的散列值是不同的（应该说是基本不可能相同，但还是存在“碰撞的概率”，比如MD5已经证明可以快速生成相同散列值的不同明文），相同的数据产生的散列值一定是相同的，因此可以通过该散列值用来保证数据防篡改和完整性（因为都会导致数字摘要发生改变）。
常用的数字摘要算法有MD5、SHA1、SHA256等。
消息认证
信息摘要只能用来解决数据的完整性问题，却无法解决消息的认证问题，因为HASH函数是任何人都可以使用的，第三方伪装发送者发送数据和数字摘要也能通过接收者的完整检查，却无法识别第三方的伪装，这是就需要消息认证了。
消息认证码MAC
message authentication code
消息认证码是将对称加密和数字摘要相结合起来的技术，首先将数据通过HASH函数生成数字摘要，然后将摘要通过双方共享的密钥加密生成消息认证码，最后将认证码一起发送给接受者。
接受者在收到消息后，使用相同的方法生成消息认证码，然后与收到的消息认证码进行对比，如果认证码一致，那么数据则通过认证。
存在2个问题：
- 因为使用的是对称加密算法，那么依然存在密钥如何传输的问题；
-
无法防止否认，因为密钥是双方共享的，而接收者认为数据是对方传递过来的，而对方可以否认传输过该条信息，并且可以生成该条信息是由接收者自己产生的。
消息认证码
数字签名
Digital Signature
数字签名是将非对称加密和数字摘要相结合起来的技术，首先将数据通过HASH函数生成数字摘要，然后将摘要用私钥进行加密生成数字签名，最后将数据和数字签名一起发送给接收者（私钥进行签名，公钥只能用来验证签名）。
接收者在收到消息后，通过公钥解密数字签名，获得数字摘要，然后对数据用相同的HASH函数计算数字摘要，然后与解密获得的数字摘要进行对比，如果一样证明数据没有被篡改过。
- 通过非对称加密传递数字摘要，能保证摘要一定是私钥拥有者发送的；
- 通过数字摘要，能够确数据一定是没有被篡改过的。
如何保证数据传输的安全
使用对称加密
对称加密计算简单，速度快，是用来加密数据的好方法，但是对于互联网上节点，要保证数据安全，就必须保证节点与节点之间通信所使用的密钥是不一样的。那么对于互联网上的服务节点，要对其他网络节点提供服务，就需要知道对方所使用的密钥，即服务器需要知道网络所有客户端所使用的密钥；这显然是不现实的。
使用非对称加密
那么既然对称机密不行，那么使用非对称加密呢？私钥由服务器拥有，并将公钥公开，那么客户端将请求用公钥加密，传递给服务器，服务器用私钥解密获得请求，处理请求后，再通过私钥加密，返回给客户端。这样看起来貌似还可以，但不要忘了，公钥可是公开的，公钥加密的固然只有拥有私钥的服务器才能解，但服务器的返回数据，却可以被任意拥有公钥的节点解开，因此非对称加密仅能保证单向安全。不仅如此，非对称加密还有以下限制：
- 计算复杂，速度较慢；
-
长度有所限制，所加密的内容不能超过密钥长度。
非对称加密传输
混合加密
使用对称加密不行，使用非对称加密也不行，那么还有其他办法吗？
既然对称加密没办法一开始就存储下来，那么在通信的时候协商好不久行了，由客户端告诉服务器端对称加密的密钥，该密钥通过非对称加密来传递，这样就能保证密钥只能被服务端获取，之后双方在通过协商好的对称密钥进行通信，既能满足双向通信安全，又能提高加解密的速度，めでたしめでたし。
这就是HTTPS传输数据的基本原理，当然实现还要考虑各种各样的事情。
HTTPS协议
HTTPS默认使用443端口
HTTPS的提出主要解决以下3个问题：
- 内容加密：保证数据传输安全
- 身份认证：确认网站的真实性
- 数据完整：防止内容被篡改
TLS/SSL
HTTP是基于TCP/IP协议的，TCP/IP在网络中传播需要经过多个节点，而HTTP请求又是明文传输的，那么有心之人轻易的可以获得请求包和返回包，并且对其进行篡改，因此HTTP是不安全的协议。
HTTP--明文-->TCP/IP---明文--->TCP/IP--明文-->HTTP
以安全为目标，HTTPS就此产生，HTTPS是HTTP的升级版本，最上层还是HTTP协议，只不过在HTTP和TCP/IP之间加入了一层加密层TSL/SSL，TLS/SSL负责对数据进行加解密，可以看做是HTTP over TLS/SSL。
HTTP--明文-->TLS/SSL--密文-->TCP/IP---密文--->TCP/IP--密文-->TLS/SSL--明文-->HTTP
TLS网络协议
TLS位于应用层，连接应用层高级协议和TCP/IP协议，从而提供安全通信。
TLS/SSL协议的版本
SSL(Secure Socket Layer)由网景公司设计，现主流使用的是SSL3.0，Google发现SSL3.0存在设计缺陷，建议禁用此协议，现目前大多数浏览器要么禁止使用SSL3.0要么会对使用SSL3.0的请求提出安全警告。
TLS(Transport Layer Security)是由IETF制定的基于SSL3.0之上的，可以看做是SSL3.0的后续版本，目前已经制定了TLS1.0、TLS1.2、TLS1.3，目前较为主流的是使用TLS1.0协议。
TLS协议握手
1. 客户端发起连接 Client-hello
由于版本、实现、操作系统等差异的存在，通信双方所能够支持的加解密算法和TSL/SSL版本客观上会存在不一致，那么通信的双方就必须要协商好使用双方的版本和加解密算法；为了节省网络带宽，双方会在网络上进行数据压缩传输，因此还会协商双方都支持的压缩算法；除这些外，客户端还会生成一个随机数Random_A，用于后续密钥的生成。
客户端提供的信息
- 协议版本
- 加密算法
- 压缩算法
- 随机数
Random_A
2. 服务器端回应 Server-hello
服务在收到客户端的请求后，将客户端生成的Random_A存储在本地，然后从客户端支持的加密算法和压缩算法选择合适的算法，并且服务器也生成一个随机数Random_B，然后将选择的算法、随机数、和自己的证书发送给客户端。
服务端提供的信息：
- 数字证书
- 协议版本
- 加密算法
- 压缩算法
- 随机数
Random_B
3. 客户端回应
如果服务端要求客户端提供证书，那么客户端会先发送客户端的证书信息。
客户端为验证服务器的证书是否合法，验证合法之后，从证书中获取服务器的公钥。客户端生成新的随机数Pre-Master，然后用服务器的公钥对该随机数进行加密发送给服务器端。通过Random_A、Random_B、Premaster Secret和之前协商的对称加密算法，就可以得到对称加密密钥enc_key=Fuc(Random_A, Random_B, Pre-Master)。
接着发送change cipher spec命令通知服务器端表示客户端已经准备好使用协商好的加密方式进行数据通信。
最后客户端计算前面发送的所有内容的MAC发送给服务器端，该信息为finish命令信息。
4. 服务器回应客户端
服务器收到客户端发送过来的Pre-Master加密数据后，用私钥进行解密，然后之前协商好的方法生成对称加密密钥，首先发送change cipher spec命令通知客户端表示服务端已经准备好使用协商好的加密方式进行数据通信，然后利用对称密钥计算前面发送所有内容的MAC发送给客户端，该信息为finish命令信息。
5. 数据通信
如果客户端和服务器端都能够对Finish信息进行正常的加解密及其验证，证明该加密通道已经建立完成。双方可以使用约定好的对称加密密钥加密HTTP请求，进行通信。
由于Random_A和Random_B在网络中是通过明文传播的，而握手阶段是通过非对称机密来传递Pre-Master的，因此后续通讯对称加密密钥的破解取决与Pre-Master是否能够被破解。
为什么要使用3个随机数，因为通信双发都不相信对方的随机数是真的随机，而最后一个随机数则是因为前面两个随机数都是明文传播，需要一个不能被第三方获取的加密参数。
数字证书
上面说过，传递第三个随机数的时候使用了从服务器获取的公钥进行加密传输给客户端。既然公钥是由服务器提供的，万一我们所连接的是恶意的中间人呢，此时是中间人与我们进行HTTPS通信，中间人在于目的服务器进行HTTPS通信，那数据就暴露给了中间人眼中了，因此直接使用来自对方的公钥是不行，我们还需要验证该公钥的合法性。
此时，就需要有一个值得信赖的第三方权威机构(Certificate Authority)来告诉我们该服务器信息是可以信任的，而这个方式就是通过第三方机构颁给服务的数字证书来证明，权威第三方机构颁发的证书成为CA证书。
证书的主要组成
- 颁发证书的机构名称
- 证书持有者的公钥
- 证书使用的HASH算法
- 证书内容的数字签名
由证书颁发方的私钥加密计算证书内容消息摘要得出，使得证书内容无法被伪造和篡改。
验证证书的有效性
一般浏览器都会内置大多数主流权威CA的根证书，所谓根证书及其有效性不需要验证，虽然它也是一份普通的数字证书。
验证的过程：
- 利用证书使用的HASH算法计算出证书内容的消息摘要；
- 使用根证书的公钥解密证书内容的数字签名得到证书提供的消息摘要；
- 比较1和2的消息摘要是否一致，如一致，表示验证通过，该证书可信任，其公钥是由服务器提供的。
只要证书颁发方是权威的，并且生成证书数字签名的私钥只有CA拥有，那么验证成功的数字证书是不可能被伪造的，即是可信任的。即使中间人拿到了数字证书，也无法冒充服务器，因为他没有数字证书中公钥对应的私钥，无法得到Pre-Master，从而无法建立连接。
通过引入权威的第三方可以保证HTTPS客户端和服务器的通信是安全可信任的。
自签发证书与双向认证
有时候，不希望使用第三方证书，想自己签发证书，那么就需要自己手动生成跟证书和CA证书，并将根证书安装到对方的系统中，对方就可以对自己进行HTTPS请求，如果对方也自签字发证书，并将证书安装我方系统，那么双方就可以进行HTTPS双向认证。
总结
本篇只讲解了HTTPS的基本原理，具体的实现还需要看RFC，因为本人不是安全方向的，点到即止即可。总的来说，上了HTTPS可以保证双方通信的安全，国内外的大型网站大部分已经切换到HTTPS，没切换的也在切换的路上了，这是未来的趋势。
