HTTPS如何实现加密，安全传输的？（SSL/TLS协议的运行方式）

1、作用

• 不使用SSL/TSL通信的HTTP,都是使用的明文进行通信的，是不安全的可能带来以下安全问题

    （1）、窃听风险：中间人获取通信内容

    （2）、篡改风险：中间人修改通信内容

    （3）、冒充风险：中间人冒充通信对方

• 使用SSL/TSL通信的HTTPS，针对上面HTTP产生的安全问题，希望解决

    （1）、将信息由明文传输变成加密传输，解决窃听风险

    （2）、具有校验机制，被篡改可以及时发现，解决篡改风险

    （3）、使用数字证书，解决冒充风险

 

2、关键概念

• 对称加密

    对称加密使用通俗的语言讲，就像我们平时使用的钥匙，要把锁，使用A加密之后，就得使用A进行解锁，加锁与解锁都是使用A密钥

                                               

                                                     

• 非对称加密

    非对称加密的意思是，有两把密钥，分别是公钥（public key）A 和 私钥（private key）A'，使用A加密，只用使用A'才能解密；反之，使用A'加密，只有使用A才能解密；它们二者都具有加密与解密的功能。

  

 

3、几种加密方式的比较以及存在的问题

    现有浏览器（Browser）与 服务器（Server）

• 使用“对称加密”方式

    服务器以“明文”的方式传给浏览器自己的密钥A，浏览器收到后，使用密钥A对数据包进行加密，然后传输给服务器，服务器收到后使用自己的密钥A进行解密。过程简单，但是安全问题很明显，我在中间截获，轻而易举就会获得密钥A，然后对于后来传输的数据随便处理了！！

    问题出在哪？是因为明文传输公钥A，可能会被截获！！而浏览器又不可能实现存储所有网站的密钥！！

• 使用“非对称加密”方式

    服务器以“明文”的方式传给浏览器自己的公钥A，浏览器收到后，使用公钥A对数据包进行加密，然后传输给服务器，服务器收到后使用自己的密钥A'进行解密。过程简单，但是安全问题很明显，我在中间截获，轻而易举就会获得密钥A，然后对于后来传输的数据随便处理了！！

    问题出在哪？是因为明文传输公钥A，可能会被截获！！而浏览器又不可能实现存储所有网站的公钥！！

• 使用“改良的非对称加密”方式

    现在浏览器和服务器双方各自有有属于自己的公钥与私钥，浏览器：公钥A，私钥A' ；   服务器：公钥B，私钥B' ；

    （1）、服务器使用“明文”的方式给浏览器自己的公钥B

    （2）、浏览器使用“明文”的方式给服务器自己的公钥A

    （3）、服务器给浏览器发数据，服务器使用A进行加密，由于只有浏览器有私钥A'，所以只用浏览器才能解密，才能查看数据

    （4）、浏览器给服务器发数据，浏览器使用B进行加密，由于只有服务器有私钥B'，所以只有服务器才能解密，才能查看数据

    问题出在哪？HTTPS并没有使用这一种方式，原因在于非对称加密方式比较耗费时间，特别是较大数据的时候，而对称加密的方式相比之下要快的多，于是是否能将  对称加密和非对称加密 这两种方式结合起来呢？？

 

                                                

• 使用“对称加密+非对称加密”的方式

    现在服务器有非对称密钥：公钥B和密钥B'； 浏览器有对称密钥X

    （1）、服务器使用“明文”的方式传给浏览器自己的公钥B

    （2）、浏览器使用公钥B加密，携带自己的对称密钥X，传给服务器

    （3）、因为只用服务器端拥有私钥B'，所以只用服务器能够解密使用公钥B加密后的数据，从而拿到浏览器的对称密钥X

    （4）、至此，服务器和浏览器之间的数据传送都使用对称密钥进行加密，实现安全传送

    

    问题出在哪？有什么安全问题？（中间人攻击）

    （1）、服务器使用“明文”的方式传给浏览器自己的公钥B

    （2）、中间人劫持，保存服务器的公钥B，并且，莫名顶替将自己的公钥M传给浏览器

    （3）、浏览器收到后，误以为是服务器传送过来的，使用公钥M加密，携带自己的对称密钥X，传给服务器

    （4）、中间人继续劫持，使用自己的私钥解密浏览器传来的数据，从而得到浏览器的对称密钥X，然后使用服务器的公钥B加密，将浏览器的对称密钥X传送给服务器

    （5）、服务器，收到中间人传来的加密数据，使用自己的私钥B’解密，得到浏览的对称密钥X，还傻呵呵的以为是浏览器发给自己的呢！！

    （6）、浏览器与服务器丝毫没有察觉到中间人的存在，故发送的数据中间人可以随便支配！！

    

    所以问题是？浏览器并不知道“明文”传送给自己的公钥是中间人的还是服务器的，如果确定自己收到的公钥是服务器的呢？由此引入“数字证书”！

 

                                         

4、数字证书的引入

• 数字证书概念

    数字证书的引入就是确认传给浏览器的公钥就是服务器的，即证明公钥是属于服务器，就像我们的身份证一样。服务器的网站在使用HTTPS之前，必须想CA机构申请一份“数字证书”，数字证书上包含：证书持有者、证书持有者的公钥信息。

    服务器的网站将数字证书发送给浏览器就可以了，浏览器就会获取其公钥信息。但是，数字证书被截获了怎么办？里面的公钥信息并篡改了怎么办？因此我们引入了“数字签名”！！

• 数字签名概念

    数字签名是用来确保明文 数字证书 没有被修改的一种手段，如何证明？见下面数字签名的生成过程。

• 数字签名的生成

     

    如图所示，数字签名生成步骤如下：

    （1）、CA机构拥有一对非对称密钥

    （2）、CA机构对明文的数字证书进行hash，得到散列值

    （3）、CA机构，使用自己的私钥加密以上生成的散列值

    

• CA机构

    通俗的讲，CA机构即 Certificate Authority证书授权机构，就像我们的办理身份证的政府一样是可以信赖的机构

 

5、如何配合数字证书实现HTTPS（流程）？

• 浏览如何验证收到的数字证书是服务器发过来的，没有并修改呢？

    如图所示浏览收到传来的数字证书（数字证书明文+数字签名）后，

    （1）、处理数字签名，使用CA机构的公钥解密获得散列hash值

    （2）、处理数字证书，使用证书明文里面说的hash算法对数字证书明文进行hash，得到散列hash值

    （3）、比对两者的散列值是否相等，如果相等，则表明证书可以信赖，没有被中间人截获篡改

• 假设数字证书被中间人劫持修改里面的明文？

    如果中间人劫持了数字证书，修改了里面数字证书的明文，但是注意，中间人并没有CA机构的“私钥”，因此并不能产生相对应的数字签名，因此即使修改了里面的明文，到了浏览器这边也会被出现，从而，判断此证书不可信（也就是此时传来的公钥可能不是服务器网站的公钥）

• 你怎么拥有CA机构的公钥？你怎么确定你自己的公钥是正确可信的？

    上文直接写了使用CA机构的公钥解密，但是我怎么会有CA机构的公钥呢？原因是操作系统和浏览器会预装一下它们信任 的“根证书”，其中有CA机构的根证书，因此也就有了CA机构的公钥了！！而除非你的CA机构被篡改了，否则一定是正确可信的！！

• 假设数字证书被中间人劫持将证书换成自己服务器网站的证书呢（  将数字证书（明文+数字签名）整个掉包换了怎么办  ）？

    这样就更不需要担心了，数字证书里面包含有关于服务器网站的信息，浏览器可以通过这个数字整数的持有者判断是不是我们请求的服务器网站

 

6、HTTPS在每次的请求中都要使用SSL/TLS，进行握手传送密钥？

    不用，可以使用session技术，每次请求都要进行一次密钥传输显然是比较耗时的，服务器会为每一个和自己建立连接的浏览器维护一个session，在TSL握手阶段传给浏览器session id，浏览器生成密钥之后，将密钥传给服务器网站，服务器网站会将传来的密钥信息保存在session中，之后浏览器的每次请求只需要携带session id即可，服务器网站就会根据session id查找密钥信息进行加密与解密的操作，这样就不需要每次都重新制作与传送密钥了！！