web————https（详解篇）

         由于互联网的快速发展，网络的攻防技术在不断的更新，http协议也愈发不安全，其缺点主要表现为：

• 通信使用明文（不加密），内容可能会被攻击者窃听

• 不验证通信双方的身份，因此攻击者有可能伪装为任何一方完成攻击

• 无法证明报文的完整性，信息在通信过程中有可能已遭攻击者篡改

        这不仅仅在http出现，很多的未加密协议也有类似问题。因此，加密技术就引入到数据传输过程中来了。

       目前通信的加密有两种：一是对通信加密，二是对通信的内容进行加密。对通信的加密：http协议本身是没有加密机制的，但是它可以与ssl（secure socket layer安全嵌套层）或者TLS（transport layer security安全层传输协议）组合使用，ssl与http组合使用称为https。而对数据内容加密就是把http所包含的内容进行加密。

       由于http协议对请求和响应不会进行确认，也就是说，服务器只要是接收到http请求就会做出一次响应，这样就容易引起DDOS攻击。不仅如此，服务器与客户端都无法判断与之通信的是否就是真实意图通信的设备，有可能已经被攻击者伪装了。而且服务端对客户端的权限也无法判断，客户端很有可能已经做出了越权的行为。

       但是，http协议与ssl结合使用的https就能很好的解决上述问题。https不仅有加密，而且还有证书认证，用于确定对方是否就是通信对方。http+加密+认证+内容完整性保护=https，下面我们慢慢分析https机制。注意，https并非新的协议，它只是在http的通信接口部分用ssl或tls协议代替而已。

       首先看看加密机制：公开密钥加密和共享密钥加密。所谓共享密钥就是加密解密为同一密钥，该解密方式也叫对称密钥。公开密钥加密有两把密钥：私钥+公开密钥，私钥是不能公开，而公开密钥可以随意发布。为了便于理解，举个通俗易懂的例子。

       服务端A与客户端B相互通信，由于公开密钥是随意发布，B请求访问A，在A的响应报文里包含A的公开密钥，B在收到A的公开密钥Ea后，B就会将生成一个随机数Rb打包成Ea(B,Rb)发送给A，A在收到后利用自己的私钥解密得出B、Rb，此时A将收到B的公开密钥Eb，同时生成会话密钥K1与随机数Ra，打包成Eb(Rb,K1,Ra)发送给B，B再用自己的私钥进行解密出Rb、K1、Ra，由于Rb是自己发出去的，所以B很快确定A就是它的通信对象。那么B再将解密出的数据K1(Ra)发送给A，A收到后再用密钥进行解密，得出数据后确定B就是通信对象，二者正常通行。

      完成了加密解密，下面我们通熟的来讲讲证书认证：分别有服务端、客户端、第三方

      场景一：客户端的某人拿着客户端本部开的介绍信去服务端办理业务，由于服务端前台根本不认识去办理业务的这个人，但是前台认识介绍信上面客户端的公章，因此就受理了该客户的业务，这个公章就相当于https通信中的证书认证。那么问题来了，如果不同客户端都有人去办理业务，前台必须清楚的分辨每个客户端的公章，这样很是麻烦，于是有人就嗅到了商机，这就是第三方。第三方就是服务端与客户端非常信赖的机构。

      场景二：同样是客户端的某人拿着第三方开的介绍信与客户端开的介绍信去办理业务，第三方开的介绍信盖有自己的公章与客户端的公章，那么服务端的前台再办理业务时，只需要分辨第三方公章之后，对比第三方介绍信上的服务端的公章与服务端介绍信上的公章是否一致即可。同理不管有多少不同客户端前去办理业务，服务端只需分辨第三方公证然后再对比服务端的公章是否一致即可，不需要每个客户端的公章都要记住。

       这样解释清楚后，我们看看官方的过程：

       1，首先服务器用自己的公开密钥登陆至数字证书认证机构

       2，数字证书认证机构用自己的私钥向服务器的公开密钥签名并颁发公钥证书。

       3，客户端拿到服务端的公开密钥后，使用数字证书机构的的公钥验证证书上数字签名，确定服务器公开密钥的真实性。

       4，使用服务器的公开密钥进行加密后发送到服务器。

       5，服务器用自己的私钥对收到的报文进行解密。

      下面是https的通信建立过程：

      client——>handshake:client hello ————>server

      client<——handshake:server hello<————server

      client<——handshake:certification<————server

      client<——handshake:hello done<——————server

      client——>handshake:cipher key exchange——>server

      client——>change cipherspec————————>server

      client——>handshake finished————————>server

      client<——change cipherspec<————————server

      client<——handshake finished<————————server

      client<————application date(http)<—————server

      client—————application date(http)—————>server

      client————>alert:warning:close notify————>server

步骤 1： 客户端发送 Client Hello 报文开始建立SSL 通信。报文中包含客户端支持的 SSL 指定版本、加密组件（Cipher Suite）列表（所使用的加密算法及密钥长度等）。
步骤 2： 服务器可进行 SSL 通信时，会以 Server Hello 报文作为应答。和客户端一样，在报文中包含 SSL 版本以及加密组件。服务器的加密组件内容是从接收到的客户端加密组件内筛选出来的。
步骤 3： 之后服务器发送 Certificate 报文。报文中包含公开密钥证书。
步骤 4： 最后服务器发送 Server Hello Done 报文通知客户端，最初阶段的 SSL 握手协商部分结束。
步骤 5： SSL 第一次握手结束之后，客户端以 Client Key Exchange 报文作为回应。报文中包含通信加密中使用的一种被称为 Pre-master secret 的随机密码串。该报文已用步骤 3 中的公开密钥进行加密。
步骤 6： 接着客户端继续发送 Change Cipher Spec 报文。该报文会提示服务器，在此报文之后的通信会采用 Pre-master secret 密钥加密。
步骤 7： 客户端发送 Finished 报文。该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准。
步骤 8： 服务器同样发送 Change Cipher Spec 报文。
步骤 9： 服务器同样发送 Finished 报文。
步骤 10： 服务器和客户端的 Finished 报文交换完毕之后，SSL 连接就算建立完成。当然，通信会受到 SSL 的保护。从此处开始进行应用层协议的通信，即发送 HTTP 请求。
步骤 11： 应用层协议通信，即发送 HTTP 响应。
步骤 12： 最后由客户端断开连接。断开连接时，发送 close_notify 报文。上图做了一些省略，这步之后再发送 TCP FIN 报文来关闭与 TCP 的通信。