1、SSL简介：
SSL(Secure Sockets Layer 安全套接层)，及其继任者传输层安全（Transport Layer Security，TLS）是为网络通信提供安全及数据完整性的一种安全协议。TLS与SSL在传输层对网络连接进行加密。SSH协议结构体：
SSL位于应用层和传输层之间，它能够为不论什么基于TCP等可靠连接的应用层协议提供安全性保证。SSL协议本身分为两层，上层为：SSL握手协议（SSL handshake protocol）、SSLpassword变化协议（SSL change cipher spec protocol）和SSL警告协议（SSL alert protocol）。底层为：SSL记录协议（SSL record protocol）。
（1）SSL握手协议：是SSL协议很重要的组成部分，用来协商通信过程中使用的加密套件（加密算法、密钥交换算法和MAC算法等）、在server和client之间安全地交换密钥、实现server和client的身份验证。（2）SSLpassword变化协议：client和server端通过password变化协议通知对端。随后的报文都将使用新协商的加密套件和密钥进行保护和传输。
（3） SSL警告协议：用来向通信对端报告告警信息，消息中包括告警的严重级别和描写叙述。
（4）SSL记录协议：主要负责对上层的数据（SSL握手协议、SSLpassword变化协议、SSL警告协议和应用层协议报文）进行分块、计算并加入MAC值、加密。并把处理后的记录块传输给对端。
2、SSL握手过程：
SSL通过握手过程在client和server之间协商会话參数，并建立会话。会话包括的主要參数有会话ID、对方的证书、加密套件（密钥交换算法、数据加密算法和MAC算法等）以及主密钥（master secret）。通过SSL会话传输的数据，都将採用该会话的主密钥和加密套件进行加密、计算MAC等处理。不同情况下，SSL握手过程存在差异。
以下将分别描写叙述以下三种情况下的握手过程： 仅仅验证server的SSL握手过程、验证server和client的SSL握手过程、恢复原有会话的SSL握手过程。
（1）仅仅验证server的SSL握手过程
如图所看到的，仅仅须要验证SSLserver身份，不须要验证SSLclient身份时，SSL的握手过程为：
4) SSLserver发送Server Hello Done消息。通知SSLclient版本号和加密套件协商结束。開始进行密钥交换。
9) SSLserver计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并加入MAC值、加密等），并通过Finished消息发送给SSLclient。SSLclient利用相同的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比較，假设二者相同。且MAC值验证成功。则证明密钥和加密套件协商成功。
SSLclient接收到SSLserver发送的Finished消息后。假设解密成功，则能够推断SSLserver是数字证书的拥有者，即SSLserver身份验证成功，由于仅仅有拥有私钥的SSLserver才干从Client Key Exchange消息中解密得到premaster secret，从而间接地实现了SSLclient对SSLserver的身份验证。
说明：
2）计算Hash值。指的是利用Hash算法（MD5或SHA）将随意长度的数据转换为固定长度的数据。
（2）验证server和client的SSL握手过程
SSLclient的身份验证是可选的，由SSLserver决定是否验证SSLclient的身份。如图中蓝色部分标识的内容所看到的，假设SSLserver验证SSLclient身份。则SSLserver和SSLclient除了交互“仅仅验证server的SSL握手过程”中的消息协商密钥和加密套件外，还须要进行下面操作：
2) SSLclient通过Certificate消息将携带自己公钥的证书发送给SSLserver。SSLserver验证该证书的合法性。
3) SSLclient计算已交互的握手消息、主密钥的Hash值。利用自己的私钥对其进行加密，并通过Certificate Verify消息发送给SSLserver。
4) SSLserver计算已交互的握手消息、主密钥的Hash值。利用SSLclient证书中的公钥解密Certificate Verify消息，并将解密结果与计算出的Hash值比較。假设二者同样，则SSLclient身份验证成功。
（3）重用原有会话的SSL握手过程
协商会话參数、建立会话的过程中。须要使用非对称密钥算法来加密密钥、验证通信对端的身份。计算量较大，占用了大量的系统资源。为了简化SSL握手过程。SSL同意重用已经协商过的会话，详细过程为：
2) SSLserver假设同意重用该会话，则通过在Server Hello消息中设置同样的会话ID来应答。这样，SSLclient和SSLserver就能够利用原有会话的密钥和加密套件。不必又一次协商。
3) SSLclient发送Change Cipher Spec消息，通知SSLserver兴许报文将採用原有会话的密钥和加密套件进行加密和MAC计算。
4) SSLclient计算已交互的握手消息的Hash值，利用原有会话的密钥和加密套件处理Hash值，并通过Finished消息发送给SSLserver，以便SSLserver推断密钥和加密套件是否正确。
5) 相同地。SSLserver发送Change Cipher Spec消息，通知SSLclient兴许报文将採用原有会话的密钥和加密套件进行加密和MAC计算。
6) SSLserver计算已交互的握手消息的Hash值，利用原有会话的密钥和加密套件处理Hash值，并通过Finished消息发送给SSLclient。以便SSLclient推断密钥和加密套件是否正确。
3、Https介绍
日常互联网浏览网页时，我们接触到的大多都是 HTTP 协议，这种协议是未加，即明文的。这使得 HTTP 协议在传输隐私数据时非常不安全。保护隐私数据的安全性，出现了HTTPS协议，HTTPS=HTTP+SSL。HTTPS 和HTTP 协议相比提供了：
数据完整性：内容传输经过完整性校验；
数据隐私性：内容经过对称加密，每个连接生成一个唯一的加密密钥；
身份认证：第三方无法伪造服务端（客户端）身份；
STEP 1: 客户端发起HTTPS 请求
SSL 连接总是由客户端启动，在 SSL 会话开始时，执行 SSL 握手。用户在浏览器里输入一个https 网址，然后连接到server 的443 端口。客户端发送以下：1）列出客户端密支持的加密方式列表（以客户端首选项顺序排序），如 SSL 的版本、客户端支持的加密算法和客户端支持的数据压缩方法(Hash 算法)。
2）包含 28 字节的随机数，client_random
STEP 2: 服务端的配置
采用HTTPS 协议的服务器必须要有一套数字证书，可以自己制作，也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过，才可以继续访问，而使用受信任的公司申请的证书则不会弹出提示页面。这套证书其实就是一对公钥和私钥。客户端和服务器至少必须支持一个公共密码对，否则握手失败。服务器一般选择最大的公共密码对。
STEP 3: 传送证书
服务器端返回以下：1）服务器端选出的一套加密算法和 Hash 算法；
2）服务器生成的随机数 server_random；
3）SSL 数字证书（服务器使用带有 SSL 的 X.509 V3 数字证书），这个证书包含网站地址，公钥 public_key ，证书的颁发机构，过期时间等等。
STEP 4: 客户端解析证书
1）这部分工作是由客户端的TLS 来完成的。首先会验证证书是否有效，这是对服务端的一种认证，比如颁发机构，过期时间等等，如果发现异常，则会弹出一个警告框，提示证书存在问题。2）如果证书没有问题，那么浏览器根据步骤 3 的 server_random 生成一个随机值 premaster_secret （前 2 个字节是协议版本号，后 46 字节是用在对称加密密钥的随机数字）和 master_secret 。 master_secret 的生成需要 premaster_key ，并需要 client_random 和 server_random 作为种子。
现在，各方面已经有了主密钥 master_secret ，根据协议约定，我们需要利用PRF 生成这个会话中所需要的各种密钥，称之为“密钥块”（Key Block ）： 这是由系列 Hash 值组成，它将作为数据加解密相关的Key Material ，包含六部分内容，分别是用于校验一致性的密钥，用于对称内容加解密的密钥，以及初始化向量，客户端和服务器端各一份。其中，write MAC key ，就是session secret 或者说是session key 。Client write MAC key 是客户端发数据的session secret ，Server write MAC secret 是服务端发送数据的session key 。MAC(Message Authentication Code) ，是一个数字签名，用来验证数据的完整性，可以检测到数据是否被串改。然后用证书公钥 public_key 对该随机值进行加密。就好像上面说的，把随机值用锁头锁起来，这样除非有钥匙，不然看不到被锁住的内容。
3）Hash 握手信息，用第3步返回约定好的 Hash 算法对握手信息取 Hash 值，然后用随机数加密“握手消息+握手消息 Hash 值（签名）”
STEP 5: 传送加密信息
客户端发送以下：客户端发送公钥 public_key 加密的 premaster secret 。目的就是让服务端得到这个随机值，以后客户端和服务端的通信就可以通过这个随机值来进行加密解密了。
STEP 6: 服务端解密信息
服务端用私钥 private_key 解密后，得到了客户端传过来的随机值 premaster_secret(私钥)，又由于服务器在步骤 1 中收到的 client_random ，所以服务器根据相同的生成算法，在相同输入参数的情况下，得到相同的 master_secret 。然后把内容通过该值进行对称加密。所谓对称加密就是，将信息和私钥通过某种算法混合在一起，这样除非知道私钥，不然无法获取内容，而正好客户端和服务端都知道这个私钥，所以只要加密算法够彪悍，私钥够复杂，数据就够安全。
STEP 7: 传输加密后的信息
服务器端返回以下：将被 premaster_key 对称加密的信息返回客户端，客户端可还原。
STEP 8: 客户端解密信息
客户端用之前生成的私钥解密服务段传过来的信息，于是获取了解密后的内容。整个过程第三方即使监听到了数据，也束手无策。
4、中间人攻击和数字证书
Https中，服务器发出一张证书（带着公钥），客户端用公钥加密一段较短的数据S并返回给服务器，服务器用私钥解开，拿到S。此时握手步骤完成，成为一个被安全传输到对方手中的对称加密密钥。此后，服务器与客户端的请求和响应，只需要用S作为密钥进行一次对称加密即可。到现在，我们的Https既安全又快乐。如此完美的加密方案，有这么这种攻击方案--中间人攻击，可以轻松突破这一套体系：
1）客户端和服务器之间有一台邪恶的路由器M；2）当客户端向Https服务器发出请求后，服务器带着公钥P响应客户端；
3）响应到大M，M拿到P，但是并不把它交给客户端，而是自己伪造了一对公私钥MP和MS，并把MP给客户端；
4）客户端拿到MP，以为是服务器的公钥P，用它加密了S，再请求服务器；
5）请求到大M，M使用MS解开S，再用P加密S交给服务器；
就这样，路由器M得到了S，至此客户端和服务器的通信不再安全。而如要要抵御中间人攻击，就需要证书认证机构CA的帮助，也是为什么需要找证书签发机构花钱购买证书的原因。
简单来说，一个Https网站响应给客户端的并不是公钥，而是证书。证书上包含了公钥、域名、签发机构、有效期、签名等。那数字证书怎么保证安全性呢？为什么中间人不能做一个假的数字证书？
因为这套证书体系已经根植于每一个操作系统里了，每个操作系统里面，都内置了数十张根证书，每个根证书都对应一个非常权威的证书签发机构，这些根证书上记录了各个机构的公钥。当网站找证书机构购买了一份合法的证书时，网站申请的证书上的公钥、域名、有效期等信息会被计算一次hash，然后证书机构用它的私钥给这个hash加密一次，这个加密结构就是证书的签名。当网站合法的Https证书到达你的电脑上后，这个证书上带有签发机构的信息（具体来说应该是一条证书链），你的浏览器会用这个签发机构对应的操作系统内置的根证书上的公钥，去解开Https证书的签名。发现签名解开的hash与证书信息内容的hash一致，就可以证明证书时合法的了。那中间人能不能申请一个真的证书然后去做劫持呢？
通常来说，证书签发机构的审核非常严格，如果无法证明www.domain.com这个域名属于他，签发机构是不会给他签发一个www.domain.com的证书的。而如果中间人用了其它域名的证书，浏览器会发现你请求的域名和返回的证书不一致，从而拒绝继续请求，除非你一定要点击仍然继续。
参考：https://www.cnblogs.com/bhlsheji/p/4586597.html
https://www.jianshu.com/p/33feb2fadb15