背景
随着用户安全意识的增强，近两年网络协议已逐步从Http协议向Https协议开始过度，目前大多数APP/Web都开始使用Https协议，这里以Http逐步发展成Https协议的过程为导向，介绍Https的诞生过程。
HTTP协议的缺点
- 通信使用明文；
- 不验证通信方的身份；
- 无法验证报文的完整性；
通信使用明文
通信使用明文意味着安全性大大降低，当通信过程被窃听后，无需花费额外的投入就可看到传输的数据。例如使用抓包工具，无需任何配置就可查看任何使用HTTP协议的通信数据；
不验证通信方身份
不验证通信方的身份，将导致通信过程被窃听后，可能会遭遇伪装，例如使用抓包工具抓取数据后，就可按照数据包的格式构造HTTP请求；
无法验证报文的完整性
不验证报文的完整性，数据在传输过程中就可能被篡改，本来想看喜洋洋呢，结果数据在传输过程中被换成了光头强。
解决方案
通信使用明文
既然明文不安全，那可以考虑使用密文，即：对通信数据进行加密。即便数据被窃听，对方依然需要花费一定的投入来破解，这种高昂的成本间接提高了安全级别。
不验证通信方身份
和服务端使用相同的算法，根据网络请求参数生成一个token，请求/应答时根据token来确定双方的身份。
无法验证报文的完整性
使用MD5/SHA1等算法进行完整性验证, 对方接收到数据后，根据同样的算法生成散列值，比对发送方生成的散列值，即可验证数据的完整性。 解决了HTTP的以上问题，HTTPS协议就诞生了：
Https = Http + 加密 + 认证 + 完整性验证
而对于加密，认证和完整性验证这些特点，TCP/IP协议族中已经提供了一个用于数据安全传输的协议——SSL（Secure Socket Layer）安全套接层，虽然也是基于TCP实现的，但SSL并不是应用层协议，而是一个位于应用层与传输层之间的协议，（具体协议相关的理论知识可参考网络编程之理论知识。）其目的就是为上层的应用层协议提供安全的传输通道。这时Https协议就可用以下形式表示：
Https = Http + SSL
这样看来，HTTPS并不是一个单独的应用层协议，而只是Http使用SSL通道进行数据传输的过程。那么对于Https, 只需要了解Http（参考HTTP详解）和SSL协议即可。而所谓的HTTPS报文也就是SSL报文：
SSL协议
SSL（Secure Socket Layer）安全套接层，是一种位于应用层与传输层之间，为网络通信提供安全及完整性验证的一种网络协议。
相对于TCP或HTTP协议，SSL协议要复杂很多。由于它也是建立在TCP协议之上的，所以在使用SSL传输数据之前需要先进行三次握手和服务器建立连接，具体的流程如图所示：
SSL协议的握手过程
- 客户端先给服务端发送一个消息，消息内容包括：客户端支持的加密方式，支持的压缩方法，SSL的版本号，客户端生成的随机数，文本内容“Hello”等；
- 服务端接收到消息后，也回发一个Hello，并携带从客户端支持的加密方式中选择的加密方式，服务端生成的随机数，服务端的SSL版本号等信息；
- 随后服务器给客户端发送一个Certificate报文，报文中包含服务端的公钥证书；
- 紧接着服务器给客户端发送Server Hello Done, 表示最初的协商握手过程结束；
- 客户端接收到服务端发送的握手结束的消息后，以Client Key Exchange作为回应，此报文中包含通信加密过程中使用的一种被称为Pre-master secret的随机密码串，并使用第三步接收到的公钥证书进行了加密；
- 接着客户端发送Change Cipher Spec报文，该报文告知服务端，此步骤之后的所有数据将使用第五步中生成的master secret进行加密（master secret的生成过程看后面的介绍）；
- 随后客户端发送Finish报文，此报文中包含连接至今所有报文的整体校验值，用于完整性验证；
- 服务端接收到客户端发送的Change Cliper Spec报文后，同样以Change Cliper Spec报文作为回应；
- 接着服务端发送Finish报文给客户端，表示服务端已正确解析客户端发送的整体校验值，至此，SSL握手的过程结束。
- 随后开始使用HTTP协议传输使用master secret加密过的数据。
说明
-
前两步是协商加密算法以及传输各自生成的随机数（为后续生成master secret做准备）的过程；
-
第三步服务端将自己的证书发送给客户端，这个证书中包含一个数字签名（CA签名）和服务端CA证书的公钥，客户端对证书中包含的服务端信息进行Hash, 同时使用接收到的公钥对数字证书解密，获取其中的Hash值，与前面计算得到的Hash值进行比较，即可验证证书的有效性（完整性&真实性）；
-
服务端收到客户端发送的Change Cipher Spec（第五步），会使用自己的私钥进行解密，获取报文中的Pre-master secret，这时通信双方都拥有对方的Random(前两步生成的)，Pre-master secret，以及自身的Random, 将三个数作为种子通过算法生成master secret, 用来加密后续Http请求过程中的数据。其中master secret的生成规则为:
master_secret = MD5(pre_master_secret + SHA('A' + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA('BB' + pre_master_secret + ClientHello.random + ServerHello.random)) + MD5(pre_master_secret + SHA('CCC' + pre_master_secret + ClientHello.random + ServerHello.random));
更详细的有关SSL协议的内容可参考：RFC 6101 SSL
为什么需要这么复杂
两个方面的考量：安全，效率。如果直接使用对称加密的方式进行加密，如果密钥不被泄漏当然也是安全，但问题是：密钥如何传递给另一端呢，在数据传输过程中，如果通信被窃听，则密钥被窃取，那此时加密就没有任何意义了。那可不可以使用非对称加密的方式呢？理论上是可以的，数据传输之前，服务端只需要将自己的公钥传输给客户端，客户端在传输数据时，使用接收的公钥进行加密，服务端接收到数据后使用私钥进行解密即可。但这里有个不容忽视的问题：效率。非对称加密需要大量计算，肯定会占用很多硬件资源，所以效率太低。所以为了解决安全和效率问题，SSL使用了对称加密（加密和解密使用同样的密钥）和非对称加密（公钥加密，私钥解密）组合的方式：使用非对称加密的方式传输对称加密中生成密钥的种子（pre master secret）【对应上面的第五步】，然后使用对称加密的方式对通信数据进行加密【对应上面的第十步】，既保障了密钥的安全性，也提高了加密速度。
Https真的安全么
既然Https那么安全，那为什么用抓包工具还是可以看到里面的数据。这里需要对抓包过程的原理做一个简单的介绍，抓包，其实就是中间人攻击，在网络请求过程中，抓包工具充当着客户端/服务端的角色，当客户端请求数据时，抓包工具将请求进行拦截，然后构造数据（冒充客户端）向服务端发起请求，此时服务端会返回自己的公钥证书，然后抓包工具将服务端的公钥证书替换成自己的公钥证书，随后将数据返回可客户端（此时充当服务端的角色）。客户端拿到公钥证书后，使用公钥证书中的公钥对Pre-master secret进行加密，并发送给服务端，发送过程中又被抓包工具拦截，由于客户端使用的公钥其实就是抓包工具生成的证书公钥，所以抓包工具只需要使用自己的私钥进行解密即可拿到真实的Pre-master secret（因为抓包工具在之前的过程中已经拿到了双方的随机码，所以到这一步抓包工具相当于已经拿到了后续通信使用的密钥），随后抓包工具使用从服务端接收到的公钥证书中的公钥对Pre-master secret进行加密，然后发送给服务端。随后的通信过程虽然进行了加密，但抓包工具已经生成了密钥（master secret），所以可以查看Https的通信内容。一图以蔽之：
从抓包的原理可以看出，对Https进行抓包，需要PC端和手机端同时安装证书。
既然这么容易被抓包，那Https会不会显得很鸡肋？其实并不会，能抓包，那是因为你信任抓包工具，手机上安装了与之对应的证书，你要不安装证书，你抓一个试试。而且安全这个课题，是在攻防中求发展，没有最安全，只有更安全，所以将攻击的成本提高了，就间接达到了安全的目标。
如何对Https进行抓包
这里以Charles4.0为例，对Https进行抓包：
- 依次点击菜单Help -> SSL Proxying -> Install Charles Root Certificate安装PC证书；
- 依次点击菜单Help -> SSL Proxying -> Install Charles Root Certificate on a Mobile Device or Romote Browser, 此时会弹出一个框，提示让你去 chls.pro/ssl 去下载证书，下载完成后进行安装即可；
- 依次点击菜单Proxy -> SSL Proxying Settings, 选中页面中的Enable SSL Proxying, 然后点击下面的add, 在弹出的框中的Host编辑框中填写*.* （表示可对所有Https请求进行抓包），端口填写443，点击OK；
- 手机设置代理（你的电脑的IP地址，端口默认为8888）即可进行抓包；
如何避免被抓包
既然使用了Https协议，就是不想让别人看到数据，那如何避免被抓包呢？这里有2种方法可参考：
- 使用自定义协议；
- 使用SSL Pinning;
使用TCP协议
使用自定义协议，也就是以TCP/UDP为基础，使用Socket进行通信（具体可参考网络编程之理论篇），这种方式由于不是使用的Http/Https协议，所以可避免Http类型的抓包工具（如Charles, Fiddler）进行抓包, 但不可避免WireShark，毕竟它太强大，可抓取网络模型中各层的数据。
使用SSL Pinning
看着很陌生，其实也不是啥新技术，只需要将服务端的公钥证书一起打到APK中，在网络请求时，与服务端的公钥证书进行比较，即可避免抓包工具使用构造证书进行抓包的情况。
总结
以上便是整个Http过渡到Https的过程，这种以协议发展为导向的方式，可能更有助于理解。当然，这只是个人对Https协议的理解，如有不恰当之处，欢迎指正。
参考书籍/文章
图解HTTP