HTTPS协议

HTTPS协议（全称是HTTP over SSL，即在HTTP传输上增加了SSL协议的加密能力）

1.对称加密： 如DES算法，即一个主站与用户之间可以使用相同的密钥对传输内容进行加密。
2.非对称加密： 如RSA加密算法，把密码革命性的分成公钥和私钥，由于两个密钥并不相同，所以称为非对称加密。私钥是用来对公钥加密的信息进行解密的，是需要严格保密的。公钥是对信息进行加密，任何人都可以知道，包括黑客。
非对称加密的原理： 非对称加密的安全性是基于大质数分解的困难性，在非对称的加密中公钥和私钥是一对大质数函数。计算两个大质数的乘积是简单的，但是这个过程的逆运算（即将这个乘积分解为两个大质数）是非常困难的。在RSA算法中，从一个公钥和密文中解密出明文的难度等同于分解两个大质数乘积的难度。因此实际传输中，可以把公钥发给对方。一方发送信息时，另一方的公钥进行加密生成密文。收到密文的一方在用私钥进行解密，这样一来，传输相对安全了。
非对称加密的缺点： 加密和解密耗时长，只适合对少量数据进行处理。
HTTPS使用的就是非对称加密的方式来建立安全的SSL连接的。
用户甲与用户已进行非对称加密传输的过程：

• 甲告诉乙，使用RSA算法进行加密。乙说好的。
• 甲和乙分别根据RSA生成一对密钥，互相发送公钥。
• 甲使用乙的公钥给已加密报文信息。
• 乙收到信息，并用自己的私钥进行解密。
• 乙使用同样的方式给甲发送信息，甲使用相同方式进行解密。

这个过程，看起来似乎无懈可击，但是在TCP/IP里，端到端的通信，路途遥远，夜长梦多。在（2）中，如果甲的送信使者中途被拦截，强盗知道使者送的是公钥，虽然没办法破解甲的加密信息，但是可以把这个使者关起来，自己生成一对密钥，然后冒充甲的使者到乙家，把自己的公钥给乙。乙信了，把银行卡密码、存款金额统统告诉了中间的强盗。所以，在解决了加密危机之后又产生了新的危机。如何解决信任问题呢？如果有一个具有公信力的组织来证明身份，这个问题就得到了解决。CA（Certificate Authority）就是颁发HTTPS证书的组织。HTTPS是当前网站的主流文本传输协议，在基于HTTPS进行连接时，就需要数字证书。
访问一个HTTPS的网站的大致流程：

• 浏览器向服务器发送请求，请求中包含了浏览器支持的协议，并携带一个随机数。
• 服务器收到请求后，选择某种非对称加密算法，把数字证书签名公钥、身份信息发送给浏览器，同时也附带一个随机数。
• 浏览器收到后，验证证书的真实性，用服务器的公钥发送握手信息给服务器。
• 服务器解密后，使用之前的随机数计算出一个对称加密的密钥，以此作为加密信息并发送。
• 后续所有的信息发送都是以对称加密方式进行的。

证书的信息中出现了传输层安全协议（TLS）的概念。这里先解释TLS和SSL的区别。

• TLS可以理解成SSL协议3.0版本的升级，所以TLS的1.0版本也被标示为SSL3.1版本。但对于大的协议栈而言，SSL和TLS并没有太大的区别，因此在Wireshark里，分层依然用的是安全套接字层（SSL）标识。
  -在HTTPS的传输过程中，主要分为两部分：首先是HTTPS的握手，然后是数据的传输。前者是建立一个HTTPS的通道，并确定连接使用的加密套件以及数据传输使用的密钥。而后者主要使用密钥对数据加密的传输。
  首先来看HTTPS是如何进行握手的。
  
  第一，客户发送了一个Client Hello协议请求：在Client Hello中最重要的信息是Cipher Suites字段，这里客户端会告诉服务端自己支持哪些加密的套件。
  第二，服务端收到客户端发来的Client Hello的请求后，会返回一系列的协议数据，并以一个没有数据的内容的Server Hello Done作为结束。这些协议数据有的是单独发送，有的则是合并发送，这里分别解释下几个重要的协议。
• Server Hello协议。主要告知客户端后续协议中要是用的TLS协议版本，这个版本主要和客户端与服务端支持的最高版本有关。
• Certificate协议。主要传输服务端的证书内容。
• Server Key Exchange。如果在Certificate协议中未给出客户端足够的信息，则会在Server Key Exchange进行补充。
• Certificate Request。这个协议是一个可选项，当服务端需要对客户端进行证书验证的时候，才会向客户端发送一个证书请求。
• Server Hello Done作为结束信息，告知客户端整个Server Hello过程结束。

第三，客户端在收到服务端的握手信息后，根据服务端的请求，也会发送一系列的协议。

• Certificate。它是可选项。因为上文中服务端发送了Certificate Request需要对客户端进行证书验证，所以客户端要发送自己的证书信息。
• Client Key Exchange。它在上文中Server Key Exchange类似，是对客户端Certificate信息的补充，在本次请求中同样是补充了客户端证书的公钥信息。
• Certification Verify。对服务端发送的证书信息进行确认。
• Change Cipher Spec。该协议不同于其他握手协议而是作为一个独立协议告知服务端，客户端已经接收之前服务端确认的加密套件，并会在后续通信中使用该加密套件进行加密。
• Encrypted Handshake Message。用于客户端给服务端加密套件加密一段Finish的数据，用以验证这条建立起来的加密通道的正确性。
  第四，服务端在接收客户端的确认信息以及验证信息后，会对客户端发送的数据进行确认，这里也分为几个协议进行回复。
• Change Cipher Spec。通过使用私钥对客户端发送的数据进行解密，并告知后续使用协商好的加密套件进行加密传输数据。
• Encrypted Handshake Message。与客户端的操作相同，发送一段Finish的加密数据验证加密通道的正确性。
  最后，如果客户端和服务端都确认加密无误后，各自按照之前约定的Session Secret对Application Data进行加密传输。