HTTPS的概述
说到https协议，我们得先了解下http协（Hyper Text Transfer Protocol）议，即超文本传输协议。http协议是基于tcp/ip协议的应用层协议，具有简单快速、无连接、无状态的特点，http请求的时候，首先有tcp的三次握手建立连接，断开的时候需要四次挥手，这个过程可以参考TCP/IP协议簇及TCP重传机制。
而另外一个需要了解的就是SSL/TSL协议。SSL(Secure Sockets Layer, 安全套接字层)，因为原先互联网上使用的 HTTP 协议是明文的，存在很多缺点，比如传输内容会被偷窥（嗅探）和篡改。 SSL 协议的作用就是在传输层对网络连接进行加密。TSL就是SSL标准化后的名字。
简单点说，HTTPS = HTTP + SSL/TSL，就是HTTP的安全版本。
HTTPS的演变过程
我们知道，HTTP需要三次握手完成tcp连接后，才能进行数据的传输，断开链接需要四次挥手，具体详见TCP/IP协议簇及TCP重传机制。那么HTTPS上述过程又是怎么样的呢？首先我们看下演变过程，HTTP三次握手建立连接后，数据完全裸奔，如下：
我们可以看到，数据完全裸奔，很容易被黑客劫持，那我们加密吧，如下：
这样也有缺点：
（1）不同的客户端、服务器数量庞大，所以双方都需要维护大量的密钥，维护成本很高；
（2）因每个客户端、服务器的安全级别不同，密钥极易泄露。
就有接下来的非对称加密版本，如下：
这样做同样也有缺点：（1）公钥是公开的（也就是黑客也会有公钥），所以第 5 步私钥加密的信息，如果被黑客截获，其可以使用公钥进行解密，获取其中的内容；（2）非对称加密是非常消耗性能的。
接下来就有了改良版本：
大致过程就是：
客户端对称密钥A通过公钥加密传给服务端，说我们后续通讯的内容就拿对称密钥A加密吧，服务端用私钥解密拿到对称密钥A，发送一条消息“好的”，这条消息就是通过对称密钥A加密的，然后就是后续的通信了。
这样同样也有缺点，服务端怎么将公钥传给客户端呢？客户端又怎么确认对方就是服务端呢？这就是终极版大招，SSL证书：
客户端在接受到服务端发来的SSL证书时，会对证书的真伪进行校验，以浏览器为例说明如下：
（1）首先浏览器读取证书中的证书所有者、有效期等信息进行一一校验；
（2）浏览器开始查找操作系统中已内置的受信任的证书发布机构CA，与服务器发来的证书中的颁发者CA比对，用于校验证书是否为合法机构颁发；
（3）如果找不到，浏览器就会报错，说明服务器发来的证书是不可信任的；
（4）如果找到，那么浏览器就会从操作系统中取出 颁发者CA 的公钥，然后对服务器发来的证书里面的签名进行解密得到hash值；
（5）浏览器使用相同的hash算法计算出服务器发来的证书的hash值，将这个计算的hash值与证书中签名做对比；
（6）对比结果一致，则证明服务器发来的证书合法，没有被冒充；
（7）此时浏览器就可以读取证书中的公钥，用于后续加密了；
HTTPS建立连接的过程：
（1）这一步，就是相当于我们在浏览器上输入url回车的过程。这个时候浏览器或者客户端（接下来统一为客户端）会把我们客户端支持的加密算法Cipher Suite（密钥算法套件）带给服务端。
服务端发送证书（公钥）给客户端
（2）服务端接收Cipher后，和自己支持的加密算法进行比对，如果不符合，则断开连接。否则，服务端会把符合的算法和证书发给客户端，包括证书时间、证书日期、证书颁发的机构。
（3）客户端验证证书，包括颁发证书的机构是否合法与是否过期，证书中包含的网站地址是否与正在访问的地址一致等
（4）验证通过后（或者用户接受了不信任的证书），客户端会生成一个随机字符串，然后用服务端的公钥进行加密。这里就保证了只有服务端才能看到这串随机字符串（因为服务端拥有公钥对应的私钥，RSA解密，可以知道客户端的随机字符串）。
（5）生成握手信息 用约定好的HASH算法，对握手信息进行取HASH，然后用随机字符串加密握手信息和握手信息的签名HASH值，把结果发给服务端。这里之所以要带上握手信息的HASH是因为，防止信息被篡改。如果信息被篡改，那么服务端接收到信息进行HASH时，就会发现HASH值和客户端传回来的不一样。这里就保证了信息不会被篡改。
（6）服务端接收到加密信息后，首先用私钥解密得到随机字符串。然后用随机字符串解密握手信息，获得握手信息和握手信息的HASH值，服务端对握手信息进行HASH，比对客户端传回来的HASH。如果相同，则说明信息没有被篡改。
服务端验证完客户端的信息以后，同样使用随机字符串加密握手信息和握手信息的HASH值发给客户端。
（7）客户端接收到服务端发回来的握手信息后，用一开始生成的随机字符串对密文进行解密，得到握手信息和握手信息的HASH值，像一步服务端验证一样对握手信息进行校验，校验通过后，握手完毕。从这里开始，客户端和服务端的通信就使用那串随机字符串进行AES对称加密通信。
对称密钥生成的过程
（1）首先，客户端利用CA数字证书实现身份认证，利用非对称加密协商对称密钥。
（2）客户端会向服务器传输一个“pubkey”随机数，服务器收到之后，利用特定算法生成另外一个“pubkey”随机数，客户端利用这两个“pubkey”随机数生成一个 pre-master 随机数。
（3）客户端利用自己在 client hello 里面传输的随机数 random_C，以及收到的 server hello 里面的随机数 random_S，外加 pre-master 随机数，利用对称密钥生成算法生成 对称密钥enc_key：enc_key=Fuc(random_C, random_S, Pre-Master)
验证总结
使用RSA非对称算法，服务端向客户端发送公钥，公钥包含了域名、颁发机构、过期日期。保证了公钥的合法性和服务端的身份正确性（而不会被黑客冒充）
客户端向第三方验证公钥的合法性，验证通过后向服务端约定对称加密的随机字符号。保证了随机字符串只有通信双方知道。
接下来的通信就使用这个随机字符号进行加密通信。因为随机字符串只有双方知道，所以信息不会被截获。
iOS的HTTPS证书的验证方式见iOS开发HTTPS实现之信任SSL证书和自签名证书
欢迎指正！！！
参考：
HTTPS 原理详解
深入揭秘HTTPS安全问题&连接建立全过程
