Http 存在的问题
- 泄密，个人隐私、账户密码等信息可能会被盗取。
- 篡改，收到的数据可能被第三方修改过，或被植入广告等。
- 假冒，访问的站点非目标服务器站点。如域名欺骗、域名劫持、钓鱼网站等。
http 是应用层的协议，位于 TCP/IP 参考模型的最上层。用户数据经过应用层、传输层、网络层、链路层的层层封装后经过物理层发送到目标机器。在这几层中，数据都没有经过加密处理，所以一旦别人获取到你的数据包，就能轻易的获取到数据的信息。
https 和 http 协议相比提供了：
- 数据完整性：内容传输经过完整性校验。
- 数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥。
- 身份认证：第三方无法伪造服务端(客户端)身份。
对称加密
对称加密算法的加密和解密都是用同一个密钥。在一定条件下，对称加密可以解决数据传输安全性的问题。比如我在登录某个网站的时候，需要填写账户名和密码进行登录，客户端把登录的表单信息进行对称加密后再传输，这时候就算第三方截获数据包，他也无法获取数据的内容，因为数据已经被加密了。但是服务器收到数据后也是一脸懵逼，你发来的加密的数据包服务器也不知道解密的密钥！
这样内容是可以加密传输了，密钥传输的过程又同样存在安全的问题！万一第三方截获了密钥的数据，那后续加密传输的数据对第三方来说无异于未加密！所以，对称加密存在密钥传输的问题！
非对称加密
基于对称加密存在的问题，又有了非对称加密。非对称加密算法需要一组密钥对，分别是公钥和私钥，这两个密钥是成对出现的。公钥加密的内容需要用私钥解密，私钥加密的内容需要用公钥解密！私钥由服务器自己保存，公钥发送给客户端。客户端拿到公钥后就可以对请求进行加密后发送给服务端了，这时候就算被第三方截获，第三方没有私钥也无法解密发送的内容，这样确保了客户端发送到服务端数据的“安全”！但是由于公钥也需要通过网络发送给客户端，同样能被第三方截获，这样服务器私钥加密后的内容依然可以被第三方截获并解密，并且非对称加密的效率很低。
利用 RSA 传输 AES 密钥
对称加密和非对称加密都存在密钥传输的问题，但是至少非对称加密可以保证客户端传输给服务端的内容无法被“破解”，而对称加密算法性能又比较好，那我们是不是可以这样子呢。第一次通信的时候服务端发送公钥给客户端，由客户端产生一个对称密钥，通过服务端的公钥加密后发送给服务端，后续的交互中都通过对称密钥进行加密传输。也就是说先通过非对称密钥加密对称密钥，通过对称密钥加密实际请求的内容。
- RSA 将服务端公钥发送给客户端。
- 客户端利用公钥对 AES 密钥加密。
- 客户端将加密后的 AES 密钥传输到服务器。
- 服务器利用 RSA 密钥对数据进行解密，得到 AES 密钥。
- 开始数据传输。
新问题
上面的方案看起来天衣无缝，第三方拿到数据后貌似就无偿下手了，但是真的就天意无缝了吗？我们看看下图
也就是说第三方可以伪装成服务器，与客户端进行通信。类似于你与服务端之间多了一个中间商！也就是说密钥传输的过程依然存在漏洞！
有点脑阔疼！还能不能让我安全的上网了！就没有更安全的机制了么？ 在协商密钥的过程中，**客户端怎么能确定对方是真正的目标服务器呢？怎么证明服务器的身份呢？**我们先了解一下数字证书！
数字证书
我们生活中有各种证，有能证明自己是个有身份的人的身份证，有能证明自己读了几年书的毕业证。这些证都是由某些权威机关认证、无法伪造的，能证明自己身份的凭据。那服务器是不是也能有个类似身份证的东西，在与服务器进行通信的时候证明自己确实是目标服务器而不是第三方伪造的呢？在生活中这些证件都是事实在在能看得见摸得着的，而计算机中的证书是虚拟的，看得见但是摸不着，是数据形式记录的，所以叫数字证书！证书包含一对公钥和私钥。
客户端第一次与服务器进行通信的时候，服务器需要出示自己的数字证书，证明自己的身份以及自己的公钥，类似如下（实际上就是一堆数据，这里为了直观）
那这个数字证书怎么产生的呢？总不能是服务器自己造一个吧？上面说到了我们生活中的证书是由权威机构颁发的、无法伪造的，比如身份证就是由派出所发证、毕业证由教育部发证，如果需要验证真假，只需要上相关的系统输入编号查询就能查到了！那我们数字证书也应该有这两个特性-权威机构颁发、防伪！
CA 机构（了解）
CA机构就是数字证书颁发的权威机构，负责颁发证书以及验证证书的合法性。如果服务器需要做个有身份的服务器，就需要向CA机构提交申请，当然有钱才好办事，交钱才能给你办证……
服务器向CA机构提交申请，需要提交站点的信息如域名、公司名称、公钥等等，CA审批无误之后就可以给服务器颁发证书了！
客户端在拿到服务器的证书后，就需要验证证书编号是否能在对应的CA机构查到，并且核对证书的基本信息如证书上的域名是否与当前访问的域名一致等等，还可以拿到证书中服务器的公钥信息用于协商对称密钥！
证书颁发了，可是又怎么防止伪造，怎么保证在传输过程中不被篡改呢？万一第三方截获到数字证书，把公钥改成自己的那不是依然无法保证安全了么？这就需要数字签名了！
数字签名
我们在做权限系统的时候，存储用户密码的时候都会经过 MD5 计算摘要后存储，在登录的时候计算用户填写的密码的 MD5 摘要与数据库存储的摘要进行对比，如果一致则密码正确，否则登录失败！MD5是不可逆的，且不同的数据计算出来的摘要是不一样的，基于这个特性，就有了数字签名的思路。
服务器提交自己的基本信息想CA机构提出申请，CA机构在给服务器颁发证书的时候，会连同数字证书以及根据证书计算的摘要一同发送给服务器，且这个摘要是需要经过CA机构自己的私钥进行加密的。这个摘要，就是数字签名。
申请流程如下：
哪些 CA 机构对于客户端来说是权威或者说是认可的呢？我们打开IE浏览器能看到客户端内置的CA机构的信息，包含了CA的公钥、签名算法、有效期等等...
密钥传输流程
服务器在与客户端通信的时候，就会将数字证书和数字签名出示给客户端了。客户端拿到数字证书和数字签名后，先通过操作系统或者浏览器内置信任的 CA 机构找到对应 CA 机构的公钥对数字签名进行解密，然后采用同样的摘要算法计算数字证书的摘要，如果自己计算的摘要与服务器发来的摘要一致，则证书是没有被篡改过的！这样就防止了篡改！
为什么不能篡改摘要呢？
**第三方拿不到CA机构的私钥，也就无法对摘要进行加密，如果是第三方伪造的签名自然也在客户端也就无法解密，这就防止了伪造！所以数字签名就是通过这种机制来保证数字证书被篡改和被伪造。**具体流程如下：
这里需要注意一点，一个是CA机构的公钥，内置在客户端，用来解密数字签名！另一个是目标服务器的公钥，在数字证书内容里，用来协商对称密钥！
HTTPS
其实 HTTPS = HTTP + SSL，在 HTTP 层和 TCP 之间加了一个 SSL/TLS 层，如下图：
SSL（Secure Sockets Layer）中文叫“安全套接层”，后来由于广泛应用，SSL标准化之后就改名为TLS（Transport Layer Security）了,其实 HTTPS 就是通过上面说到的那些手段来解决网络上可能存在的数据泄密、篡改、假冒的这些问题，保证网络传输的安全的啦！
二次加密
既然 HTTPS 已经帮助我们将数据加密了，我们之间使用就好，那为什么还需要二次加密呢？
https 能保证的是连接的安全，当我们打开网站的时候，是需要和服务器进行通信的，那么 https 能够保证在通信时数据传输是安全的。
如果我们打开一个网页，在网址的前面有标明 "https" 的话，那么就说明这个网站有证书并且有进行加密的操作。但是，不少钓鱼网页其实也可以使用 https，这就说明了 https 并不能保证网站本身是安全的。举个例子，如果你在一个网页上输入账号密码的话，使用 https 的网页能够保证你的账号密码在传到网站服务器的过程中不会被其他的东西干扰或者盗取，但是，你输入的账号密码却有可能被你正在访问的这个网页盗用。
再举个例子：移动端手机种了木马，终端被攻击了，那么对于传输通道进行加密就毫无意义，试想人家都跑到你家里面去了，所有的东西在内存跟硬盘里面都有，再进行网络监听毫无意义。
所以 https 本身是安全的，至少在网络传输过程中，能够保证传输数据的完整性和一致性。但是并不代表它的宿主是安全的，所以如果是金融类，支付类等对安全等级要求很高的软件，最好进行二次加密。