大多使用HTTPS协议的原因是因为HTTP在使用上是不如HTTPS安全的。比如当我们在往服务器发送比较隐私的数据时，如果使用HTTP进行通信，安全性没办法得到保障。数据在传输的过程中，是比较容易被中间人抓包窃取的。
其次，如果在不安全的环境下发送数据，数据也有可能在传输过程被篡改，当接收数据的服务器收取数据时，也没办法确定数据是否有被修改和替换过。当然，服务器也没办法判断数据就是真的来源于客户端。
目前，HTTP是存在一些弊端的，例如无法保证保密性，没法保证消息的完整、准确性，没法保证消息的可靠性。对比于这些问题，HTTPS是可以解决掉的。可以间接的把HTTPS理解为HTTP的升级版，包容了HTTP的功能，并逐步在HTTP的基础上增加了安全性能。
为http的内容是明文传输的，明文数据会经过中间代理服务器、路由器、wifi热点、通信服务运营商等多个物理节点，如果信息在传输过程中被劫持，传输的内容就完全暴露了，他还可以篡改传输的信息且不被双方察觉，这就是中间人攻击。所以我们才需要对信息进行加密。最简单容易理解的就是对称加密 。
为了保证消息的保密性，就会涉及到加密和解密的问题。目前主流的分为对称加密和非对称加密两种。
什么是对称加密?
就是有一个密钥，它可以对一段内容加密，加密后只能用它才能解密看到原本的内容，和我们日常生活中用的钥匙作用差不多。
用对称加密可行吗?
如果通信双方都各自持有同一个密钥，且没有别人知道，这两方的通信安全当然是可以被保证的(除非密钥被破解)。
然而最大的问题就是这个密钥如何让传输的双方知晓，同时不被别人知道。如果由服务器生成一个密钥并传输给浏览器，那这个传输过程中密钥被别人劫持弄到手了如何办?之后他就能用密钥解开双方传输的任何内容了，所以这么做当然不行。
换种思路?试想一下，如果浏览器内部就预存了网站A的密钥，且可以确保除了浏览器和网站A，不会有任何外人知道该密钥，那理论上用对称加密是可以的，这样浏览器只要预存好世界上所有HTTPS网站的密钥就行啦!这么做显然不现实。
什么是非对称加密?
有两把密钥，通常一把叫做公钥、一把叫做私钥，用公钥加密的内容必须用私钥才能解开，同样，私钥加密的内容只有公钥能解开。
用非对称加密可行吗?
鉴于非对称加密的机制，我们可能会有这种思路：服务器先把公钥直接明文传输给浏览器，之后浏览器向服务器传数据前都先用这个公钥加密好再传，这条数据的安全似乎可以保障了!因为只有服务器有相应的私钥能解开这条数据。
其实HTTPS的加密原理，主要在于充分利用了对称加密和非对称加密的优点，以及数字证书的作用。根据加密的特点，将HTTP进行了一次升级，升级到HTTPS的形态，就具备了一层加密的外壳了。
非对称加密+对称加密?
既然非对称加密耗时，非对称加密+对称加密结合可以吗?而且得尽量减少非对称加密的次数。当然是可以的，而且非对称加密、解密各只需用一次即可。
请看一下这个过程：
某网站拥有用于非对称加密的公钥A、私钥A’。
浏览器随机生成一个用于对称加密的密钥X，用公钥A加密后传给服务器。
服务器拿到后用私钥A’解密得到密钥X。
这样双方就都拥有密钥X了，且别人无法知道它。之后双方所有数据都用密钥X加密解密。
完美!HTTPS基本就是采用了这种方案。完美?还是有漏洞的。
为什么制作数字签名时需要hash一次?
我初学HTTPS的时候就有这个问题，似乎以上过程中hash有点多余，把hash过程去掉也能保证证书没有被篡改。
最显然的是性能问题，前面我们已经说了非对称加密效率较差，证书信息一般较长，比较耗时。而hash后得到的是固定长度的信息(比如用md5算法hash后可以得到固定的128位的值)，这样加密解密就会快很多。
如何证明CA机构的公钥是可信的?
你们可能会发现上文中说到CA机构的公钥，我几乎一笔带过，“浏览器保有它的公钥”，这是个什么保有法?如何证明这个公钥是否可信?
让我们回想一下数字证书到底是干啥的?没错，为了证明某公钥是可信的，即“该公钥是否对应该网站/机构等”，那这个CA机构的公钥是不是也可以用数字证书来证明?没错，操作系统、浏览器本身会预装一些它们信任的根证书，如果其中有该CA机构的根证书，那就可以拿到它对应的可信公钥了。
实际上证书之间的认证也可以不止一层，可以A信任B，B信任C，以此类推，我们把它叫做信任链或数字证书链，也就是一连串的数字证书，由根证书为起点，透过层层信任，使终端实体证书的持有者可以获得转授的信任，以证明身份。
另外，不知你们是否遇到过网站访问不了、提示要安装证书的情况?这里安装的就是跟证书。说明浏览器不认给这个网站颁发证书的机构，那么没有该机构的根证书，你就得手动下载安装(风险自己承担XD)。安装该机构的根证书后，你就有了它的公钥，就可以用它验证服务器发来的证书是否可信了。
HTTPS必须在每次请求中都要先在SSL/TLS层进行握手传输密钥吗?
这也是我当时的困惑之一，显然每次请求都经历一次密钥传输过程非常耗时，那如何达到只传输一次呢?用session就行。
服务器会为每个浏览器(或客户端软件)维护一个session ID，在TSL握手阶段传给浏览器，浏览器生成好密钥传给服务器后，服务器会把该密钥存到相应的session ID下，之后浏览器每次请求都会携带session ID，服务器会根据session ID找到相应的密钥并进行解密加密操作，这样就不必要每次重新制作、传输密钥了!
本文来源：yuntue.com/post/4848.html，若侵权，请联系删除。
