Https交互流程《转》

最经看了一些关于https的东西，比较乱，现在做个总结（不一定正确，而且很多细节没挖掘，只是目前的一个粗浅认识） 

Https流程图 



从这个图我们可以看出： 

由于浏览器和服务器之间对数据传输进行了对称加密，从而保证了数据的安全性，但是现在有一个问题，如何保证浏览器生成的随机数（对称加密的密钥）能安全的传递给服务器端？ 
如果这把密钥被第三方窃取，那么浏览器和服务器之间传递的数据就能被轻而易举的解密，进而造成危险. 

我们可以这么做： 
采用非对称加密的方式，让浏览器安全的把对称加密的密钥传送给服务器. 那什么是非对称加密呢？ 假如有两把钥匙一个叫公钥，一个叫私钥，用公钥加密的数据只有私钥才能解开，那么只要服务器存留一份私钥，把公钥发个浏览器，就可以安全传输数据. 
问题似乎完美的解决了，但是不要忘记，服务器需要把它的公钥传递给浏览器，所以服务器如何保证它能正确的传递公钥呢（这问题像这样推倒下去，就没完没了，变成鸡和蛋的哲学问题了）？  

好吧，我们来个终结者：CA证书. 
CA证书是由权威机构颁发（由浏览器自动去权威机构验证，意味着你可以信任他），证书的内容包含多种信息，其中就包括服务器的公钥，还包括证书有效期等等。 
通过它建立我们的信任基点，就可以保证服务器公钥被正确的传递给浏览器，然后浏览器可以使用它安全的把对称加密的密钥传递给服务器，之后以此密钥加密需要传递的信息，保证了数据的安全性 

可能到这里，你会有疑问，为什么我们不直接采用非对称加密加密数据，而先是使用非对称加密传送对称加密的密钥，之后传递数据使用对称加密？ 
这里的原因很简单，非对称加密的计算效率远远不如对称加密； 
整个https流程实际上是： 使用非对称加密算法保证对称加密密钥的安全传递，然后使用对称加密来保证数据传输过程中的安全性 

 

原文：http://diaocow.iteye.com/blog/1743273

 

------------------------------------------------------------------------------------

https作用：即使http请求被拦截，由于拦截者无法获取用来加密的随机数（因为拦截者无法从权威机构获取公钥来对随机数的加密结果做解码），所以无法解密传输内容。