HTTP为什么不安全：
- 通信使用明文（不加密），内容可能被窃听
- 不验证通信方的身份，因此有可能遭遇伪装
- 无法证明报文的完整性，所以有可能被篡改
HTTP+加密+认证+完整性保护=HTTPS(HTTP Secure）
- HTTPS则是具有安全性的SSL加密传输协议
- HTTPS协议需要CA申请证书
- HTTP和HTTPS使用的是完全不同的连接方式，用的端口也不一样，前者是80，后者是443
- HTTPS通过HTTP来传输信息，但是信息通过TLS协议进行了加密
TLS
https仍用http传输信息，但信息通过TLS进行了加密。
TLS作用于表示层
两种加密技术
- 对称加密
两边有相同的密钥，都知道如何加密解密 - 非对称加密
数据公钥加密，私钥解密，私钥只有发出公钥的一方知道
HTTPS使用两种加密方式混用的加密机制（先用非对称加密方式传递对称加密中要使用的密钥，然后再用对称加密方式传递数据）。流程如下：
服务器将公钥发散出去。之后客户端创建一个密钥，用此公钥加密后发送给服务器，服务器用私钥解密，就能得知此密钥。双方都知道密码，之后就可以采用对称加密的方式进行数据传输了。
TSL的握手过程
- 客户端向服务器发送Client Hello报文，包含：
- 支持的SSL协议版本
- 加密组件（支持的加密方法等）
- 服务器回应，向客户端发起回应，称为Server Hello
- 确认通信协议版本
- 确认使用加密方法
- 服务器生成的随机数
- 服务器公开密钥证书
- 客户端回应（Client Key Exchange报文），首先验证服务器证书，如果证书不是可信机构办法的，或者证书中域名和实际域名不一样，或者证书已经过期，就会向访问者显示一个警告，由其选择是否还要继续通信。如果证书没有问题，客户端从证书中取出服务器的公钥。然后向服务器发送下面三项信息：
- 一个随机数Pre master（用服务器提供的公钥加密）
- 编码改变通知（之后的通信会采用Pre master密钥加密（对称加密））
- 客户端握手结束通知（Finish报文）。该报文包含前面发送的所有内容的hash值，供服务器校验
- 服务端收到第三个随机数之后，计算本次会话所用的会话加密，然后向客户端发送下面信息：
- 编码改变通知
- 服务器握手结束，同时也是前面所有内容的hash值，供服务器校验
此时两端都有了最终的协商密钥了，接下里的传输就使用这个密钥加密解密（对称加密）
HTTPS的缺点
- 解密加密过程消耗CPU、内存等资源
- 加密运算和多次握手降低了访问速度
- SSL证书信用体系不绝对安全，并且增加费用开销
- 在开发阶段，加大了页面调试难度 。由于信息都被加密了，所以用代理工具的话，需要先解密然后才能看到真实信息
- 用HTTPS访问的页面，页面内的外部资源都得用HTTPS请求，包括脚本中的AJAX请求