在面试中偶尔会遇到这个问题，https为什么更安全？今天一起来说说这个问题。
起因
http协议是应用层协议，在设计之初只是为了传输超文本文件，没有太多加密数据的传输需求，所以一般是明文传输。然而从客户端到服务端，要经过用户设备、路由器、运营商、服务器等中间环节，由于是明文传输，在中间环节信息比较容易遭到窃取和修改。
随着Web应用逐渐丰富，对Web传输的安全性有了更多的要求。特别是电子商务、金融服务等的兴起，保证用户会话信息的安全性，显得越来越重要。
后来，提出了在http协议所在的应用层和传输层增加了安全层(ssl/tls)，用于对Web信息传输的加密和解密，以增强传输的安全性。
加密三种方式
加密通常有对称加密和非对称加密。
对称加密是浏览器和服务器都采用同一个秘钥，用这个秘钥进行信息的加密和解密操作。
非对称加密是公钥加密，私钥解密；私钥加密，公钥解密。
采用对称加密
采用对称加密的话，大概是这么个流程：
- 在建立连接之初，浏览器向服务器发送自己支持的加密套件列表和一个client-random(客户端生成的随机数)。
- 服务器收到请求，从加密套件列表中指定加密套件，记下client-random，生成server-random(服务端生成的随机数)，将加密套件和server-random返回给浏览器。
- 此时浏览器和服务器都有了client-random和server-random。然后浏览器和服务器互相确认。
- 在传输数据阶段，浏览器根据之前商定的加密套件对client-random和server-random计算加密秘钥，然后把要传输的数据进行秘钥加密后传输给服务器。然后服务器也根据client-random和server-random计算加密秘钥，对浏览器传入的数据进行解密。然后将要返回的数据也进行秘钥加密，发送回客户端。
在这个过程中，还是client-random和server-random以及加密套件的传输都是明文，所以还是有可能被中间人获取到，然后计算出加密秘钥，对拦截到的消息进行加密解密。只依靠对称加密不行。
采用非对称加密
采用非对称加密的话，大致是这么个流程：
- 建立连接之初，浏览器向服务器发送自己支持的加密套件列表。
- 服务器选中加密套件，然后将加密套件和公钥一起返回给浏览器。
- 浏览器发送数据时，根据公钥对数据进行加密。服务端收到加密后的数据，按照私钥进行解密。
- 服务器将要返回的数据用私钥进行加密，传到浏览器端，浏览器根据公钥进行解密。
在这个过程中，公钥和加密套件的传输是明文的，中间人可以获取到。不过非对称加密保证了中间人不能对浏览器发送的数据进行解密。如果只用非对称加密进行处理，会有以下问题：
- 加密效率低。非对称加密的速度较对称加密低，而加解密速度会影响到资源获取时间，进而影响到用户体验。
- 服务器返回数据的安全性无法保证。服务器返回数据，是用私钥进行加密的，而中间人是可以获取到加密公钥和加密套件的。所以在服务器返回数据的时候，中间人可以解密对应的数据。
非对称加密和对称加密同时使用
两种加密方法都使用的话，大概是这么个流程：
- 浏览器向服务器发送自己支持的加密套件列表和client-random(浏览器随机生成的数字)
- 服务器收到浏览器请求，记下client-random, 选中加密套件，生成server-random，然后将加密套件(非对称加密套件和对称加密套件)、server-random和公钥(用于非对称加密的)返回给浏览器。
- 浏览器收到之后，生成一个随机数pre-master，然后进行用公钥进行加密。将加密后的数据传给服务器。此时如果中间人能够获得加密后的pre-mater，但是由于是非对称加密，所以没办法对数据进行解密。
- 服务器收到加密后的pre-master，用自己的私钥进行解密，然后根据client-random、server-random以及解密后的pre-master，生成对称加密的秘钥。而浏览器端此时也能够根据client-random, server-random以及pre-master生成对称加密的秘钥。
- 服务器和浏览器通过之前生成的对称加密的秘钥进行信息收发。而中间人由于缺少pre-master，没办法生成对称加密的秘钥，进而无法对信息进行解密。
数据加解密的问题解决了，但是还有问题。
如果黑客通过劫持DNS，修改了用户所访问的域名对应的服务器地址，此时用户是不知道的。而之前的加密方式也不能处理这种问题。还要有一种让服务器自证“我就是我”的一种机制。那么怎么证明呢？
以车子为例，我们怎么证明我们买的车子是我们的呢？在买车的时候，销售商会提供买车收据，然后我们要带着购买证明向税务机构缴纳购车税，去车管所给车子办理拍照、挂牌等一系列手续，然后官方还会出具一份机动车所有权证书，以证明这个车是我买的。
CA证书差不多也是这个路子。我们需要去向权威机构申请CA证书。在申请证书的时候，我们要提交一系列的信息，域名及所有权信息、自己的公钥信息(私钥自己留存)，公司信息，站点信息等。权威机构对提交的信息进行审核确认，然后颁发对应的CA证书给网站所有者。CA证书中包含了公司信息、公钥、组织信息等，同时还有一个根据这些信息(进行hash后的)由CA证书的私钥加密生成的签名。
加入CA证书之后的流程是什么样的呢？
- 浏览器向服务器发送自己支持的对称加密套件列表和套件列表以及client-random。
- 服务器收到信息后，生成server-random。然后返回加密套件、server-random和数字证书(CA证书)。CA证书里有公钥。对应的私钥位于网站所有者服务器上。
- 浏览器进行CA证书的校验。校验颁发机构、有效期等信息。
- 校验通过后，确认当前访问的服务器确实是域名所有者的。然后生成pre-master(随机生成)。然后用CA证书中的公钥对Pre-master进行加密，发送给服务器。
- 服务器获取到加密后的pre-master，用自己的私钥进行解密。之后服务器和浏览器都根据client-random, server-random和pre-master生成对称解密的秘钥，进行信息加密和解密。
对于第三步中，浏览器对CA证书进行有效性校验，大致是什么样的流程呢？
浏览器对CA证书中的明文信息进行hash，然后将CA中的签名用CA证书的公钥进行解密，然后将解密后的信息和本地hash后的信息做对比。如果相等，则证明当前CA证书是有效的；同时浏览器还会验证域名信息、有效期等。
此时我们已经确认了这个CA是谁。如果这个CA是由恶意分子注册的，那也不安全，因此此时浏览器不知道该不该最终信任该CA证书。然后浏览器会去查询给这个CA颁发CA证书的CA，再以同样的方式验证它的上级，一直到顶级CA。浏览器会内置一些顶级的CA，如果最终找到的CA没有在浏览器内置的CA中，证书也会被判定为非法。当浏览器验证到根证书的话，如果证明这个根证书是合法的？合法的根证书会内置在操作系统中。是经过WebTrust认证的。除人为更改情况下是可以信赖的。
至此，https加解密及验证使得它比https更加安全。非对称加密和对称加密及CA证书共同完成了数据传输中加解密及信任度的问题。然而，如果系统的根证书被人为恶意植入的话，https也就相对没这么安全了。