http + 加密 + 认证 + 完整性保护 = https
http在传输过程中会受到窃听、篡改的风险，且通信的双方也有可能是伪造的，所以在传输机密信息的时候，需要进行加密、通信双方认证以及信息完整性保护。https是在http的基础上添加了一个SSL协议，即http先与ssl进行通信，ssl再与tcp进行通信。
https会对http请求的 header 和 body 都进行加密，可以防止 token 被盗用，因此 https + token 是一种加密机制比较完善的传输方式。
一. 加密机制
通常来说有两种加密机制，一个是对称加密（共享加密），一个是非对称加密。共享加密通过同一个密钥进行加密解密，需要将密钥传输给接收方，但密钥在传输过程中存在安全性问题。而非对称加密通过公钥进行加密，私钥进行解密，私钥不用进行传输，解决了共享加密的安全问题。但是非对称加密的处理速度要慢很多。所以，https采用混合加密机制，先对密钥用对称加密的公钥进行加密传输，再对信息进行共享加密传输。
现在看起来似乎没什么问题了，但是这种方式其实还存在缺陷，那就是，我们无法验证用来加密共享密钥的公钥本身的安全性问题。这一点，可以使用由数字证书认证机构颁发的公开密钥证书来解决。一般流程如下：
- 服务器把自己的公开密钥登录至数字认证机构
- 数字认证机构用自己的密钥向该公开密钥进行数字签名并颁发公钥证书（注意常用数字认证机构的公钥已经植入到浏览器端）
- 客户端收到服务端的公钥证书后，通过浏览器中的认证机构的公钥对该公钥证书上的数字签名进行验证，确保该公钥的真实性
- 之后，客户端使用该公钥对信息进行加密传输
- 最后，服务端通过私钥对信息进行解密
二. 认证机制
证明服务端真实性的EV SSL证书。持有该证书的web网站的浏览器地址栏的背景颜色是绿色的。
客户端证书需要用户自行安装客户端证书，且每张证书都需要付费购买，只有一些特殊业务才会用到，比如银行的网上银行。
https的安全通信机制
- 客户端首先发送client hello报文开始SSL通信。报文中包含SSL的版本以及加密组件列表（比如加密算法及密钥长度等）；
- 如果服务端可进行SSL通信，会响应一个server hello，内容与client hello差不多；
- 之后服务端再发送certificate报文，该报文中包含服务端的公钥证书；
ServerHelloDone标识最初的SSL握手协商阶段结束； - 接着客户端发送ClientKeyExchange报文作为回应，该报文包含一个Pre-master secret随机密码串，并通过公钥进行加密；
- 客户端发送changeCipherSpec报文，提示之后的报文会采用上述随机密码串进行加密；
- 客户端发送finished报文，该报文包括连接至今全部报文的整体校验值；（握手协商是否成功要以服务端是否能解析该报文为标准）
- 服务端发送同样的changeChipherSpec报文；
- 服务端发送finished。
- SSL连接建立完成，通信受到SSL的保护，即可发送正常的http请求。
- 断开连接时，由客户端发送close_notify报文，之后再发送TCP FIN报文来关闭与TCP的通信。
三. https 传输的数据是否需要二次加密
https 能保证的是连接的安全，当我们打开网站的时候，是需要和服务器进行通信的，那么 https 能够保证在通信时数据传输是安全的。
如果我们打开一个网页，在网址的前面有标明"https"的话，那么就说明这个网站有证书并且有进行加密的操作。但是，不少钓鱼网页其实也可以使用 https，这就说明了 https 并不能保证网站本身是安全的。举个例子，如果你在一个网页上输入账号密码的话，使用 https 的网页能够保证你的账号密码在传到网站服务器的过程中不会被其他的东西干扰或者盗取，但是，你输入的账号密码却有可能被你正在访问的这个网页盗用。
再举个例子：移动端手机种了木马，终端被攻击了，那么对于传输通道进行加密就毫无意义，试想人家都跑到你家里面去了，所有的东西在内存跟硬盘里面都有，再进行网络监听毫无意义。
所以 https 本身是安全的，至少在网络传输过程中，能够保证传输数据的完整性和一致性。但是并不代表它的宿主是安全的，所以如果是金融类，支付类等对安全等级要求很高的软件，最好进行二次加密。