1，非对称加密技术
非对称加密算法需要两个密钥，公开密钥（publickey）和私有密钥（privatekey）；公钥和私钥是成对出现的。
非对称加密例子：B想把一段信息传给A，步骤：1）A把公钥传给B；2）B拿到A的公钥并利用此密钥给信息加密；3）B把加密的信息传给A；4）A利用私有密钥对加密信息进行解密即可得到B想给自己的信息。（这个过程叫做密码传输，即B把信息加密后传给A）
问题：如果有个捣乱的冒充B，也用A的公钥给一段信息加密，并传给A，A再私钥解密得到的信息就会误认为是B的。
要解决此问题，B需要给A传个验证信息，让A可以验证自己受到的信息是B传的。该验证信息即下面的数字摘要（数字指纹）
2，数字摘要技术
该技术主要利用了哈希函数的两个特性：1）单向性；2）计算结果位数固定
数字摘要是采用单向Hash函数将需要加密的明文“摘要”成一串固定长度（128位）的密文，这一串密文又称为数字指纹，它有固定的长度，而且不同的明文摘要成密文，其结果总是不同的，而同样的明文其摘要必定一致。“数字摘要“是https能确保数据完整性和防篡改的根本原因。
3，数字签名技术
数字签名技术既利用了数字摘要（数字指纹）技术也利用了非对称加解密技术 。
数字签名过程：1）B利用哈希函数得到上面传输信息的哈希值；2）B利用私钥给哈希值加密（注意：这里的非对称加密（私钥加密，公钥解密）与密码传输过程的非对称加密（公钥加密，私钥解密）相反）并传给A；3）A利用B的公钥解密得到密码的哈希值。4）A把密码传输过程得到的信息进行哈希计算得到哈希值，如果计算的哈希值和解密得到的哈希值相同，则说明密码传输过程得到的信息确实是B传过来的。
总结：
1）数字签名过程主要是为了确定信息是否是A想要的那个人的（这里就是B的），当然同时也验证了信息的完整性。
2）密码传输过程的非对称加密（公钥加密，私钥解密），作用是传输内容保密（A有解密私钥），但是信息可伪造。
数字签名过程的非对称加密（私钥加密，公钥解密），作用是信息不可伪造（B有加密私钥），但是传输内容公开。
4，数字证书
为什么要有数字证书？
上述过程中A是请求方，B是目标主机，他们之间加密传输过程中用到的公钥，hash算法等必须传输前确认可信（谁来确认，第三方机构（C）），如果目标主机本身就从事窃取用户信息的，怎么保证传输的安全性都是没用的。我们需要有一个权威的值得信赖的第三方机构(一般是由政府审核并授权的机构)来统一对外发放主机机构的公钥，只要请求方这种机构获取公钥，就避免了上述问题的发生。
数字证书的颁发过程
1）用户（A）首先产生自己的密钥对，并将公共密钥及部分个人身份信息传送给认证中心。
2）认证中心（C）在核实身份后，将执行一些必要的步骤，以确信请求确实由用户发送而来，然后，认证中心将发给用户一个数字证书，该证书内包含用户的个人信息和他的公钥信息，同时还附有认证中心的签名信息(根证书私钥签名)。
3）用户（A）就可以使用自己的数字证书进行相关的各种活动。
说明：数字证书由独立的证书发行机构发布，数字证书各不相同，每种证书可提供不同级别的可信度。
证书包含哪些内容
- 证书颁发机构的名称
- 证书本身的数字签名
- 证书持有者公钥
- 证书签名用到的Hash算法
验证证书的有效性
浏览器默认都会内置CA根证书，其中根证书包含了CA的公钥
- 证书颁发的机构是伪造的：浏览器不认识，直接认为是危险证书
- 证书颁发的机构是确实存在的，于是根据CA名，找到对应内置的CA根证书、CA的公钥。用CA的公钥，对伪造的证书的摘要进行解密，发现解不了,认为是危险证书.
- 对于篡改的证书，使用CA的公钥对数字签名进行解密得到摘要A,然后再根据签名的Hash算法计算出证书的摘要B，对比A与B，若相等则正常，若不相等则是被篡改过的。
- 证书可在其过期前被吊销，通常情况是该证书的私钥已经失密。较新的浏览器如Chrome、Firefox、Opera和Internet Explorer都实现了在线证书状态协议（OCSP）以排除这种情形：浏览器将网站提供的证书的序列号通过OCSP发送给证书颁发机构，后者会告诉浏览器证书是否还是有效的。
1、2点是对伪造证书进行的。3是对于篡改后的证书验证，4是对于过期失效的验证。
5，SSL 与 TLS
SSL (Secure Socket Layer，安全套接字层)
SSL为Netscape所研发，用以保障在Internet上数据传输之安全，利用数据加密(Encryption)技术，可确保数据在网络上之传输过程中不会被截取，当前为3。0版本。
SSL协议可分为两层： SSL记录协议（SSL Record Protocol）：它建立在可靠的传输协议（如TCP）之上，为高层协议提供数据封装、压缩、加密等基本功能的支持。 SSL握手协议（SSL Handshake Protocol）：它建立在SSL记录协议之上，用于在实际的数据传输开始前，通讯双方进行身份认证、协商加密算法、交换加密密钥等。
TLS (Transport Layer Security，传输层安全协议)
用于两个应用程序之间提供保密性和数据完整性。
TLS 1.0是IETF（Internet Engineering Task Force，Internet工程任务组）制定的一种新的协议，它建立在SSL 3.0协议规范之上，是SSL 3.0的后续版本，可以理解为SSL 3.1，它是写入了 RFC 的。该协议由两层组成： TLS 记录协议（TLS Record）和 TLS 握手协议（TLS Handshake）。较低的层为 TLS 记录协议，位于某个可靠的传输协议（例如 TCP）上面。
SSL/TLS协议作用：
- 认证用户和服务器，确保数据发送到正确的客户机和服务器；
- 加密数据以防止数据中途被窃取；
- 维护数据的完整性，确保数据在传输过程中不被改变。
TLS比SSL的优势
- 对于消息认证使用密钥散列法：TLS 使用“消息认证代码的密钥散列法”（HMAC），当记录在开放的网络（如因特网）上传送时，该代码确保记录不会被变更。SSLv3.0还提供键控消息认证，但HMAC比SSLv3.0使用的（消息认证代码）MAC 功能更安全。
- 增强的伪随机功能（PRF）：PRF生成密钥数据。在TLS中，HMAC定义PRF。PRF使用两种散列算法保证其安全性。如果任一算法暴露了，只要第二种算法未暴露，则数据仍然是安全的。
- 改进的已完成消息验证：TLS和SSLv3.0都对两个端点提供已完成的消息，该消息认证交换的消息没有被变更。然而，TLS将此已完成消息基于PRF和HMAC值之上，这也比SSLv3.0更安全。
- 一致证书处理：与SSLv3.0不同，TLS试图指定必须在TLS之间实现交换的证书类型。
- 特定警报消息：TLS提供更多的特定和附加警报，以指示任一会话端点检测到的问题。TLS还对何时应该发送某些警报进行记录。
SSL、TLS的握手过程
1，客户端首次发出请求
由于客户端(如浏览器)对一些加解密算法的支持程度不一样，但是在TLS协议传输过程中必须使用同一套加解密算法才能保证数据能够正常的加解密。在TLS握手阶段，客户端首先要告知服务端，自己支持哪些加密算法，所以客户端需要将本地支持的加密套件(Cipher Suite)的列表传送给服务端。除此之外，客户端还要产生一个随机数，这个随机数一方面需要在客户端保存，另一方面需要传送给服务端，客户端的随机数需要跟服务端产生的随机数结合起来产生后面要讲到的 Master Secret 。
客户端需要提供如下信息：
- 支持的协议版本，比如TLS 1.0版
- 一个客户端生成的随机数，稍后用于生成”对话密钥”
- 支持的加密方法，比如RSA公钥加密
- 支持的压缩方法
2，服务端首次回应
服务端在接收到客户端的Client Hello之后，服务端需要确定加密协议的版本，以及加密的算法，然后也生成一个随机数，以及将自己的证书发送给客户端一并发送给客户端。这里的随机数是整个过程的第二个随机数
服务端需要提供的信息：
- 协议的版本
- 加密的算法
- 随机数
- 服务器证书
3，客户端再次回应
客户端首先会对服务器下发的证书进行验证，验证通过之后，则会继续下面的操作，客户端再次产生一个随机数（第三个随机数），然后使用服务器证书中的公钥进行加密，以及放一个ChangeCipherSpec消息即编码改变的消息，还有整个前面所有消息的hash值，进行服务器验证，然后用新秘钥加密一段数据一并发送到服务器，确保正式通信前无误。
客户端使用前面的两个随机数以及刚刚新生成的新随机数，使用与服务器确定的加密算法，生成一个Session Secret。
ChangeCipherSpec是一个独立的协议，体现在数据包中就是一个字节的数据，用于告知服务端，客户端已经切换到之前协商好的加密套件（Cipher Suite）的状态，准备使用之前协商好的加密套件加密数据并传输了。
4，服务器再次响应
服务端在接收到客户端传过来的第三个随机数的 加密数据之后，使用私钥对这段加密数据进行解密，并对数据进行验证，也会使用跟客户端同样的方式生成秘钥，一切准备好之后，也会给客户端发送一个 ChangeCipherSpec，告知客户端已经切换到协商过的加密套件状态，准备使用加密套件和 Session Secret加密数据了。之后，服务端也会使用 Session Secret 加密一段 Finish 消息发送给客户端，以验证之前通过握手建立起来的加解密通道是否成功。
5，之后的客户端与服务器间通信
确定秘钥之后，服务器与客户端之间就会通过商定的秘钥加密消息了，进行通讯了。整个握手过程也就基本完成了。
阮兄的简化版五步握手：
开始加密通信之前，客户端和服务器首先必须建立连接和交换参数，这个过程叫做握手（handshake）。
假定客户端叫做爱丽丝，服务器叫做鲍勃。
第一步，爱丽丝给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。
第二步，鲍勃确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。
第三步，爱丽丝确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给鲍勃。
第四步，鲍勃使用自己的私钥，获取爱丽丝发来的随机数（即Premaster secret）。
第五步，爱丽丝和鲍勃根据约定的加密方法，使用前面的三个随机数，生成"对话密钥"（session key），用来加密接下来的整个对话过程。
值得特别提出的是：
SSL协议在握手阶段使用的是非对称加密，在传输阶段使用的是对称加密，也就是说在SSL上传送的数据是使用对称密钥加密的！因为非对称加密的速度缓慢，耗费资源。其实当客户端和主机使用非对称加密方式建立连接后，客户端和主机已经决定好了在传输过程使用的对称加密算法和关键的对称加密密钥，由于这个过程本身是安全可靠的，也即对称加密密钥是不可能被窃取盗用的，因此，保证了在传输过程中对数据进行对称加密也是安全可靠的，因为除了客户端和主机之外，不可能有第三方窃取并解密出对称加密密钥！如果有人窃听通信，他可以知道双方选择的加密方法，以及三个随机数中的两个。整个通话的安全，只取决于第三个随机数（Premaster secret）能不能被破解。
其他补充
对于非常重要的保密数据，服务端还需要对客户端进行验证，以保证数据传送给了安全的合法的客户端。服务端可以向客户端发出 Cerficate Request 消息，要求客户端发送证书对客户端的合法性进行验证。比如，金融机构往往只允许认证客户连入自己的网络，就会向正式客户提供USB密钥，里面就包含了一张客户端证书。
PreMaster secret前两个字节是TLS的版本号，这是一个比较重要的用来核对握手数据的版本号，因为在Client Hello阶段，客户端会发送一份加密套件列表和当前支持的SSL/TLS的版本号给服务端，而且是使用明文传送的，如果握手的数据包被破解之后，攻击者很有可能串改数据包，选择一个安全性较低的加密套件和版本给服务端，从而对数据进行破解。所以，服务端需要对密文中解密出来对的PreMaster版本号跟之前Client Hello阶段的版本号进行对比，如果版本号变低，则说明被串改，则立即停止发送任何消息。
session的恢复
有两种方法可以恢复原来的session：一种叫做session ID，另一种叫做session ticket。
1）session ID的思想很简单，就是每一次对话都有一个编号（session ID）。如果对话中断，下次重连的时候，只要客户端给出这个编号，且服务器有这个编号的记录，双方就可以重新使用已有的”对话密钥”，而不必重新生成一把。
2）客户端发送一个服务器在上一次对话中发送过来的session ticket。这个session ticket是加密的，只有服务器才能解密，其中包括本次对话的主要信息，比如对话密钥和加密方法。当服务器收到session ticket以后，解密后就不必重新生成对话密钥了。
总结
https实际就是在TCP层与http层之间加入了SSL/TLS来为上层的安全保驾护航，主要用到对称加密、非对称加密、证书，等技术进行客户端与服务器的数据加密传输，最终达到保证整个通信的安全性。
参考：
白话Https：https://www.cnblogs.com/xinzhao/p/4949344.html
https://www.youtube.com/watch?v=uS1ZIAsvT5w
https://blog.csdn.net/wx_962464/article/details/51043069
http://www.ruanyifeng.com/blog/2014/09/illustration-ssl.html
来源：https://www.cnblogs.com/xdyixia/p/9237742.html