参考：架构师必读！以图文的方式解锁 HTTPS原理，10分钟还原HTTPS真像！
对于消息安全的定义是：即使消息被中间人拦截到，中间人也没办法解读出其中的消息。
对称加密
要实现消息安全，首先想到的是“对称加密”。发送消息前先对消息加密，对方收到消息后，对消息进行解密。这个过程中加密和解密都使用同一个密钥。但是在C/S这种多对一的情况下，每个连接都采用同一种对称加密方式的话，就等同于不加密（因为密钥人人都有，将消息拦截到后，都可以对消息进行解密读取）。
不同连接使用不同的对称加密方式
解决以上问题，就是对每个连接使用不同的对称加密方式。这样一来就算消息被拦截了，别人也无法解密消息，因为大家的加密方式都是不同的，你不知道我是怎么加密的，自然也就很难解密了。但是对于使用哪种加密方式，这个怎么协商决定呢？协商的过程中如何保证消息的安全呢？
非对称加密来加密协商过程
使用“非对称加密”。该加密方式的特点是，公钥加密的消息只能用私钥来解密，私钥加密的消息只能用公钥来解密。私钥和公钥属于一对多的关系，所以私钥一般放在服务器，而公钥放在多个客户端，使用非对称加密可以保证客户端到服务器方向的消息是安全的。
随机的协商加密算法
客户端与服务器仅仅在需要开始交互的时候，用随机数来决定该使用哪一种对称加密算法。
安全地得到公钥
实现非对称加密的一个前提是：多个客户端都得到了公钥。实现的方式有两种：
- 服务器给每个客户端直接发放公钥。
- 服务器将公钥放在另一台服务器上，让用户自己去取公钥。
后者比前者多出来一次请求，而且两者同样需要解决公钥传输的安全问题，所以选择前者的实现方式。公钥传输过程中可能会被掉包，如图所示：
造成以上问题的原因是：客户端无法判断公钥的是否被中间人做了调包。
数字证书
我们服务器使用可信的第三方平台的私钥对我们公钥进行加密，加密后的数据称为“数字证书”，客户端从我们服务器获取到这个数字证书后，再使用存储在客户端本地的这个第三方平台的公钥对数字证书进行解密，得到我们服务器的公钥。
具体这个数字证书是怎么跑到我们的服务器上的，这个过程留意后续的章节“CA如何颁发数字证书给我们的服务器管理员”。
数字签名
以上发放数字证书的过程属于非对称加密，第三方平台充当服务器，我们的服务器充当了客户端而已。在非对称加密中，公钥是对所有客户端公开的，也就是说以上过程中，数字证书在返回给我们服务器的过程中，如果被中间人拦截，中间人也拥有第三方平台的公钥，就可以对给我们服务器的数字证书进行解密，从而对内容进行拦截调包，过程如下：
造成以上问题的原因是：客户端直接就相信了返回的数字证书。解决的办法是客户端对得到的数字证书进行校验，判断这个证书是否可信。实现的策略类似于奖状证书上的编号，客户端得到证书后，取出其中的证书编号，向第三方询问这个编号是否与证书信息对应。如果对应则可信。
为了不拖慢通信的效率，以上校验在客户端本地进行。
本地校验证书
具体要怎么校验，需要由证书将校验的方式告知客户端，客户端采用这种方式生成一个证书编号，如果这个编号与证书的编号一致，则说明校验通过。对校验方式进行举例，如对证书内容进行MD5计算得出证书编号。这里所说的证书编号其实就是https中的数字签名，证书就是https的数字证书。
以上验证了证书的正确性，接着就要使用第三方的公钥对证书进行解密，从而获取我们服务器的公钥了。如何获取第三方的公钥呢？
浏览器和操作系统都会维护一个权威的第三方机构列表（包括它们的公钥）。因为客户端接收到的证书中会写有颁发机构，客户端就根据这个颁发机构的值在本地找相应的公钥。到这里可以看出前文所说的“第三方”其实就是CA，可能会有疑惑：本地的公钥安全吗？答案是：相信它是安全，所以要求各位尽量使用正版的操作系统。
CA如何颁发数字证书给我们的服务器管理员
对于每个CA机构的申请方式大同小异，申请流程如下：
获取到证书后，具体怎么配置到自己的服务器上，自己去google。
总结
以上使用推算的方式还原了https的设计思路，能明白https比http多出来很多次交互，导致性能低。以上一大堆工作就是为了能安全地协商出C/S之间的对称加密方式，这就是SSL/TLS主要的工具，在协商好了对称加密的方式后，CS之间就使用这个对称加密方式进行通信了。
HTTPS要使客户端与服务器端的通信过程得到安全保证，必须使用的对称加密算法，但是协商对称加密算法的过程，需要使用非对称加密算法来保证安全，然而直接使用非对称加密的过程本身也不安全，会有中间人篡改公钥的可能性，所以客户端与服务器不直接使用公钥，而是使用数字证书签发机构颁发的证书来保证非对称加密过程本身的安全。这样通过这些机制协商出一个对称加密算法，就此双方使用该算法进行加密解密。从而解决了客户端与服务器端之间的通信安全问题。