网络数据传输安全及SSH与HTTPS工做原理

本节内容

---

1. 网络数据传输安全概述
2. 数据加密算法分类
3. SSH工做原理
4. HTTPS工做原理
5. 参考资料

我的一直在努力推进git在公司内部的普及和使用，前些日子在公司内部作了一次分享课，给你们介绍了下项目发布流程相关的内容，顺便普及了一些git的相关知识。对git是什么，以及怎样配置和使用它作了一些说明。但过后，不少同事的反馈，让我意识到他们不少人都卡在ssh免密钥登陆的配置上。咱们常说，学习一个新的东西应该遵循3W1H法则--WAHT(是什么)，WHEN(何时用)，HOW（怎样用）和 WHY（为何这样用）。我想你们应该是由于不知道为何这样用，因此才会感到困惑。恰好，最近也在整理“使用Python相关模块进行数据加密”的文档，须要作些理论性的铺垫，因此才想写这篇文章，但愿对你们有所帮助。

另外须要说明的是，网络安全涉及不少方面的不少内容，本文只是针对网络数据传输过程当中的安全性发表一下我的认识和见解。若是描述的有什么不妥之处，欢迎你们留言交流和指正。

1、网络数据传输安全概述

---

咱们说的数据加密与解密一般是为了保证数据在网络传输过程当中的安全性。在网络发展初期，网络的数据安全性是没有被足够的重视的。事实上，当时为了实现数据能够经过网络进行传输已经耗费了科学家大部分男细胞，所以在TCP/IP协议设计的初期，他们也实在没有太多精力去过多考虑数据在网络传输过程当中可能存在的安全性问题。随着TCP/IP协议及相关技术的日渐成熟，网络数据传输技术愈来愈稳定，人们才慢慢开始重视这个问题，美国国家标准与技术研究院（National Institue of Standard and Technology，简称NIST）也开始制定相关的安全标准。

网络安全涉及到不少个方面，咱们这里仅仅讨论下网络数据传输过程当中可能受到的威胁，其中常见的有：

• 数据窃听
• 数据篡改
• 身份假装

针对以上威胁，咱们介绍下网络数据传输的安全性涉及的几个方面：

1. 机密性

机密性是指对要传输的数据进行加密和解密，防止第三方看到通讯数据的明文内容。其对应的通讯过程以下：

数据发送方：

plaintext(明文) ==> 转换算法 ==> ciphertext(密文)

数据接收方：

ciphertext(密文) ==> 转换算法 ==> plaintext(明文)

2. 完整性

数据完整性是指不容许数据在传输过程当中被修改（第三方恶意篡改或电平信号形成的部分数据丢失），可是它不要求数据的机密性，也就是说容许其余人看到明文数据。咱们一般经过以不可逆的算法对数据提取特征码（也叫数据指纹），经过验证特征码的一致性来判断数据是否被修改过，通讯过程以下：

数据发送发：

plaintext(明文) ==> 转换算法 ==> plaintext(明文) + footprint(数据指纹A)

数据接收方：

plaintext(明文) + footprint(数据指纹A) ==> 转换算法 ==> footprint(数据指纹B) ==> 对比数据指纹A与B是否一致

3. 身份验证

身份验证一般是指数据接收方须要确认发送数据给本身的数据是本身想要通讯的那一方，防止他人冒充通讯对方的身份进行通讯。身份验证的大致原理是：数据发送方与数据接收方约定一种特殊的数据加解密方式，数据发送方将一个经过约定的加密方式进行加密后的数据发送给数据接收方，数据接收方如能按照约定的加密方式正确解密该数据就表示对数据发送方的身份验证成功。其对应的通讯过程以下：

数据发送方：

plaintext(明文) ==> 转换算法 ==> ciphertext(密文)

数据接收方：

ciphertext(密文) ==> 转换算法 ==> plaintext(明文)

2、数据加密算法分类

---

上面提到的网络数据传输所涉及到的几个方面都须要特定的转换算法来实现，经常使用的转换算法（数据加密/解密算法）大致上能够分为如下几类：

1. 对称加密

对称加密是指数据加密与解密使用相同的密钥。

主要功能：

一般用于保证数据的机密性。

经常使用的算法实现：

• DES： Data Encryption Standard，秘钥长度为56位，2003年左右被破解--秘钥能够暴力破解。
• 3DES： DES的改进版本。
• AES： Advanced Encryption Standard，支持的秘钥长度包括 128bits，192bits，258bits，384bits，512bits。

须要说明的是，秘钥长度越长，数据加密与解密的时间就越久。

特色：

• 加密与解密使用的密钥相同。
• 在必定程度上实现了数据的机密性，且简单、快速。
• 可是因为算法通常都是公开的，所以机密性几乎彻底依赖于密钥。
• 同一发送方与不一样接收方进行通讯时应使用不一样的密钥，防止数据被窃听或拦截后被解密。

存在的问题：

• 当通讯对象不少时会面临众多秘钥的有效管理问题。
• 对于一个新的数据通讯对象，密钥怎样进行传输的问题。

2. 单向加密

单向加密是指只能对明文数据进行加密，而不能解密数据。

主要功能：

一般用于保证数据的完整性。

经常使用的算法实现：

• MD5： 128bits
• SHA： SHA1(160bits), SHA224, SHA256, SHA384

特色：

• 不可逆：没法根据数据指纹/特征码还原原来的数据。
• 输入相同，输出必然相同。
• 雪崩效应：输入的微小改变，将会引发结果的巨大改变。
• 定长输出：不管原始数据有多长，结果的长度是相同的。

存在的问题：

可能出现中间人攻击，中间人能够对原始内容进行修改以后从新生成数据指纹，数据接收方验证数据指纹时会发现数据是正常的。此时，数据发送方只能把生成的数据指纹进行加密后再发送给数据接收方，那么问题就又回到了加密密钥的传输和管理上。

3. 公钥加密（也叫非对称加密）

公钥加密，也被称做非对称加密，也就是说加密和解密所使用的密钥是不一样的。

主要做用：

一般用于保证身份验证。

经常使用的公钥加密算法有：

• RSA： 能够实现数字签名 和 数据加密
• DSA： 只能实现数字签名，不能实现数据加密

特色：

• 加密与解密使用的不一样的密钥。
• 实际上它所使用的密钥是一对儿，一个交公钥，一个叫私钥。这对密钥不是独立的，公钥是从私钥中提炼出来，所以私钥是很长的，968位、1024位、2048位、4096位的都有。
• 一般公钥是公开的，全部人均可以获得；私钥是不能公开的，只有本身才有。
• 用公钥机密的内容只能用与之对应的私钥才能解密，反之亦然，这个特色尤其重要。

咱们发现公钥加密“貌似”已经解决了密钥管理的问题--全部人只须要知道本身的那一对儿密钥便可，须要跟谁通讯就去获取对方的公钥，而后经过这个公钥对数据进行加密和机密就能够了。咱们能够用它来完成如下两件事情：

• 用本身的私钥加密， 能够保证身份验证，由于用你的私钥加密的数据只能用你的公开的公钥才能解密数据；可是不能保证数据的机密性，由于全部人都知道你的公钥。浏览器检查CA证书合法性时，验证CA机构的数字签名时就是经过这种方式进行的。
• 用对方的公钥加密， 能够保证数据的机密性，由于只有用对方的私钥才能解密，而对方的私钥只有他一我的有。HTTPS通讯时，经过密钥协商技术获得的密钥进行传输时就是经过这种方式来保证机密性的。其实用对方公钥加密也能够用于用于身份验证，验证过程是：A用B的公钥加密数据后将密文传输给B，B用本身的私钥进行解密并将明文发送回给A，A对比B返回的明文和本身加密前的明文一致则表示对B完成了身份验证，经过SSH进行免密钥登陆时就是经过这种方式来完成用户身份验证的。

事实上，公钥加密算法不多用于数据加密，它一般只是用来作身份认证，由于它的密钥太长，加密速度太慢--公钥加密算法的速度甚至比对称加密算法的速度慢上3个数量级（1000倍）。

存在的问题：

• 既然公钥加密一般只用于身份验证，而不是用于保证数据的机密性，也就意味着这个密钥对儿并不能彻底做为加密和解密数据的秘钥来用。那么，秘钥的管理和传输问题依然存在着，这个问题到底怎样来解决呢？
• 另外还有个问题就是，若是有人伪造了一对儿密钥，把其中的公钥发送给别人怎么办？怎样验证以获取公钥的合法性呢？

密钥管理的解决方案：

实际上，已经存在一种专门用于秘钥交换的算法--Diffie-Hellman加密算法。该加密算法自己仅限于秘钥的交换用途，被许多商用产品用做秘钥交换技术。这种秘钥交换技术的目的在于使得两个用户安全的交换一个密钥，以便用于以后的数据对称加密。也就是说，通讯双方能够经过这个技术，动态的协商生成一个用于对称加密的密钥，而不用管理不少静态的密钥，这样就解决了密钥的管理问题。

须要说明的是，在经过秘钥交互技术动态协商生成密钥以前，一般须要先经过公钥加密算法对对方的身份进行验证。实际上，https就是这样工做的。

防止公钥被伪造的解决方案

公钥实际上也是一段文本，验证公钥的合法性涉及到两个方面：

• 1）该公钥的发布者身份是否合法
• 2）该公钥的内容是否被篡改过

其实，这个已经不是靠纯技术能解决的问题了，这须要借助一些机构和人为约定来解决。常见的解决方案有两种：

• 1）公钥的合法拥有者，经过官方渠道声明其密钥的数据指纹： 既然时官方发布的信息，那么身份的合法性是有保证的；用户在获取公钥后也生成一个数据指纹，经过对比这两个数据指纹就知道公钥内容是否被修改过；SSH的身份验证明际上就是这个原理。
• 2）经过一些权威的机构来完成这些验证： 好比https使用的证书就是由CA机构签发的，这个在后面讲https原理时再作具体介绍。

咱们常见的对于上面这些加密算法的经典应用就是ssh和https了，它们都是使用这些加密算法实现的网络协议。下面咱们对ssh和https的工做原理进行下介绍，一方面当作上面这些加密算法的实例讲解，帮助你们了解这些算法的经典应用；另外一方面，也帮助你们更深刻的理解ssh和https是什么，以及它们是怎样工做的。

3、SSH工做原理

---

1. SSH是什么？

简单来讲，SSH就是一种网络协议，主要用于计算机之间的加密登陆与数据传输，使用方式以下：

# ssh user@host

表示要以user这个用户的身份登陆host这台网络机器。也能够省略前面的user，这样来用ssh host，表示以当前本地登陆的用户名登陆host这台网络机器。

早期，人们主要是经过telnet协议进行计算机之间的登陆操做，可是它有一个很严重的安全隐患就是“数据是明文传输的”，登陆时传输的包括用户名和密码在内的全部信息都有可能会被恶意拦截而暴露。而SSH则是将登陆信息所有加密后进行传输的，所以使用SSH进行登陆时安全的，即便数据在传输过程当中被截获，里面的密码已经被加密而不会泄露。

如今SSH做为互联网安全的一个基本解决方案，已经在全世界得到推广，且目前已经成为Linux系统的标准配置。须要说明的是，SSH只是一种协议，它有多种软件实现，既有商业的，也有开源的。OpenSSH是当前使用最为普遍的一个SSH协议的开源实现。

2. SSH工做原理

其实SSH是充分利用了公钥加密/非对称机密 、对称加密 和 单向加密 来实现数据安全登陆的。在使用SSH进行通讯时，通讯过程分为如下几个步骤：

• 1）生成会话密钥： 这个会话密钥，不是密钥对儿中公钥或私钥，而是经过密钥协商技术生成密钥。这个密钥会被经过被登陆机器的密钥对进行加密后传输，用于后续全部（经过对称加密方式进行的)加密通讯。
• 2）用户身份认证（登陆）：* 这个对登陆者进行身份验证的过程是经过登陆者的密钥对儿对数据进行加解密验证明现的，这个过程当中传输的全部数据都是经过上一步生成的密钥加密过的。
• 3）数据加密通讯： 后面就行基于第1步生成的密钥进行数据加密传输的通讯过程了。

下面来看具体解析。

帐号密码安全登陆的实现

上面提到，SSH是经过对数据进行加密后进行传输来保证数据安全的。可是，SSH的数据加密采用的是对称加密算法，只是对称加密所使用的密钥是经过公钥加密/非对称加密实现加密后的安全传输的。另外，每台Linux机器都有本身的密钥对儿（一般放在/etc/ssh目录下），这个密钥对儿跟具体的用户无关。其工做流程是：

• 1）在主机A上向主机B发送链接请求；
• 2）主机B在与用户创建链接后，把本身的公钥发送给主机A；
• 3）主机A经过密钥协商技术产生一个随机密钥，而后使用主机B的公钥对这个随机密钥进行加密后发送给主机B;
• 4） 主机B接收到主机A发送过来的密文形式的密钥后，经过本身的私钥进行解密，获得对称加密使用的密钥明文；至此，会话密钥已经生成完毕了；
• 5）主机A经过生成的会话密钥对帐号和密码等信息进行加密而后发送给主机B；
• 6）主机B接收到加密信息后，使用会话密钥进行解密，从而获得明文的帐号和密码进行帐号验证；
• 7）主机B在验证帐号和密码后通知主机A是否登陆成功；

这样即使有人结果了帐号密码信息，也是密文信息，并不能知道里面是什么内容。貌似已经OK了，可是，主机A怎么验证主机B的身份呢？若是有主机C冒充主机B截获了登陆请求，将本身伪造的公钥发送给主机A，怎么办？尽管信息是加密过的，通讯过程也是合法的，可是通讯信息都被主机C截获了，其实这就是所谓的“中间人攻击”（Man-in-the-middle attack）。其实，对主机B进行验证就是对主机B发送过来的公钥的合法性进行验证的过程。

公钥合法性验证的实现

上面咱们提到过，验证公钥的合法性有两种方式：

• 1）验证公钥的官方发布的公钥数据指纹
• 2）经过权威的结构进行验证

SSH主要用于机器之间的安全登陆，所以一般不会经过权威的机构去签发证书，它主要是经过验证数据指纹的方式来验证公钥的合法性的。公钥的合法性验证是发生在主机A接收到主机B发送的公钥以后，主机A向主机B协商产生会话密钥以前，也就是上个部分所列举的数据机密时间的第2个步骤和第3个步骤之间。具体的工做流程以下：

• 1）上个部分所列举的数据加密实现的第1-2步；
• 2）主机A会去当前用户家目录下的.ssh/known_hosts文件中查找是否存在该机器的公钥，若是不存在，表示主机A是第一次与该主机进行通讯，那么主机A会计算出该公钥的数据指纹并要求用户对该指纹进行合法性确认。就是咱们常常看到的的这样子：
  
• 3）用户须要把目标主机管理员公布的公钥的数据指纹与主机A计算获得的数据指纹进行比对，若是一致，则说明该公钥是合法的；若是不一致则说明不合法；
• 4）用户若是确认该公钥是合法的，则输入yes表示继续后面的链接，主机A则会把这个公钥的内容保存到当前用户家目录下的.ssh/known_hosts文件中，而后提示用户输入密码，以下图所示：
  下次再登陆，执行到步骤2时，主机A发现该公钥已经在.ssh/known_hosts文件中存在了，就不用要求再次确认了，而是会直接提示输出密码：
  
• 5）至此，主机B的身份合法性验证就结束了。

每一个用户都有本身的kown_hosts文件，它们是相互独立的。咱们也能够为全部用户保存一份公共的可信赖的远程主机的公钥，这个文件一般是/etc/ssh/ssh_known_hosts。

问题：假如以前咱们经过ssh登陆过的一台机器的IP被绑定到其余机器上了会出现什么状况？

当机器A接收到机器B的公钥指纹时，发现knowns_hosts文件中虽然有机器B的公钥，可是计算得出的公钥指纹与机器B发送过来的公钥指纹不一致。这确定是不一致的，由于每台机器的密钥对都是随机生成的，几乎不可能出现重复。所以，咱们会看到以下提示信息：

上面的大概意思是，主机A发现主机B的公钥指纹对不上了，怀疑咱们正在遭受中间人攻击（即有人在冒充主机B），而且密码验证方式和键盘交互验证方式都被禁止使用了。其实，咱们本身知道是由于IP被绑定到其余机器上引发的这个问题，因此咱们若是想继续登陆新的主机B，只须要在.ssh/known_hosts文件中把原来保存的主机B的公钥删掉就能够了。

3. SSH免密钥登陆的实现

使用SSH免密钥登陆的优势

你们都知道，SSH免密钥登陆是经过公钥认证的，用户登陆时只须要提供用户名，而不须要输入密码。其实其优势不止这一个，咱们来总结下：

• 1）使用帐号和密码进行登陆时，因为用户没法设置空密码，所以每次登陆都要输入密码。并且即便系统容许给用户设置空密码，也是十分危险的行为。而公钥认证容许用户给私钥设置空密码，同时还能保证安全性。
• 2）使用帐号和密码进行登陆时密码容易被人看到，且密码也容易被猜到；而公钥认证所使用的密钥不用手动输入，并且内容很长，所以安全性比较高。
• 3）使用帐号和密码进行登陆时，服务器上的一个帐号若是想给多我的同时使用，机器密码维护工做会变得很繁琐，由于他们全部人都须要知道密码是什么，当修改密码也要通知他们每一个人。而使用公钥认证只须要把它们的公钥保存在服务器上，若是要取消某我的的操做权限，只须要把这我的的公钥删掉，而不须要修改服务器密码。

SSH免密钥登陆过程

其实登陆的过程就是被登陆端对登陆用户进行“身份验证”的过程，前面是经过帐号和密码来验证用户身份，由于密码应该只有该帐号的拥有者才知道。而咱们知道公钥加密算法中，用公钥加密的数据只能由与其配对的私钥才能解密，而私钥只有用户本身才有。那么，咱们是否能够经过这种方式来验证用户身份呢？实际上SSH免密钥登陆就是这样的原理。好比，咱们想在主机A上以root用户以SSH免密钥的方式登陆主机B，登陆验证过程是这样的：

• 1）主机A与主机B协商产生会话密钥；
• 2）主机A会向主机B发送一个登陆请求（如：root@192.168.1.2），发送的信息包括用户名root和root的公钥指纹，且全部信息都是经过会话密钥加密过的。
• 3）主机B经过会话密钥解密主机A发送的数据获得请求登陆的用户名root和root的公钥指纹，而后读取root用户家目录下的全部公钥数据（/root/.ssh/autorized_keys文件中），并分别经过单向加密算法获取各公钥的数据指纹与主机A发送过来的数据指纹作对比，从而找到主机A上的root用户的公钥；
• 4）主机B使用找到的root用户的公钥对一个随机数进行加密发送发送给主机A；
• 5）主机A使用root用户的私钥对主机B发送的随机数密文进行解密，而后把解密结果发送给主机B;
• 6）主机B验证主机A解密后的数据与本身发送的数据一致，则对root用户的身份验证成功；

那么主机A是怎样获取root用户的私钥的呢？主机B又是怎样获取root用户的公钥的呢？ 这个就是实现SSH免密钥登陆所要配置的内容：

• 1）生成密钥对儿：在当前机器A上，能够经过ssh-keygen命令生成一个ssh密钥对儿，一路回车就能够；生成的密钥对儿默认保存在当前登陆用户家目录下的.ssh目录，也能够指定保存目录。咱们当前是以root用户登陆，所以是保存在/root/.ssh目录：
  
• 2）咱们能够把这个密钥对儿中的两个文件复制到其余用户家目录的.ssh目录下（如/home/wader/.ssh/目录），也能够复制到其余任意目录。须要说明的是必定要注意目录和文件的权限：.ssh 目录的权限必须是0700，authorized_keys 文件权限必须是0600。
• 3）当在主机A上经过 ssh root@hostB进行登陆时，主机A会尝试读取登陆用户的家目录下的私钥文件（这里是以root用户登陆主机B，所以主机A会读取/root/.ssh/id_rsa文件做为私钥），也能够经过-i选项指定要使用的私钥文件；
• 4）咱们须要手动把公钥的内容复制到要登陆机器B的相应用户（如root）家目录下的指定文件中：/home/root/.ssh/autorized_keys；可使用ssh-copy-id root@hostB命令直接完成这个操做，也能够经过复制粘贴的方式来完成；
• 5）在当前机器上就能够经过ssh私钥使用root用户登陆机器B了。

4. ssh免密钥登陆在git中的使用

咱们在管理git仓库中的项目时，可使用http/https协议，也可使用ssh协议来管理咱们的项目代码：

http/https协议：

http://192.168.1.1/GROUP_OR_USER/PROJECT_NAME.git
https://192.168.1.1/GROUP_OR_USER/PROJECT_NAME.git

ssh协议:

ssh://git@192.168.1.1/GROUP_OR_USER/PROJECT_NAME.git

不管使用http/https协议仍是ssh协议来管理项目仓库，对于非公开的仓库都是须要进行登陆（即帐户身份验证）的。若是咱们使用http/https协议的话，就须要提供用户名和密码进行验证；若是咱们使用ssh协议的话，就能够把咱们公钥保存到项目仓库机器的指定位置，来经过非对称加密的方式进行身份验证，验证的原理上面已经详细说明过了。

4、HTTPS工做原理

---

HTTPS实际上就是HTTP协议和SSL/TSL协议的组合，能够把HTTPS大体理解为“HTTP over SSL”或“HTTP over TSL”。关于它们的相关介绍，能够参考这篇文章。对于HTTPS咱们应该有如下几个认知：

• 1）使用HTTPS传输数据是安全的，由于数据都是被加密传输的；
• 2）使用HTTPS须要在服务器端配置密钥对；
• 3）使用HTTPS须要花钱找专业的权威机构进行CA证书的签发。

那么使用HTTPS与网站服务器进行交互的流程和原理究竟是怎样的呢？让咱们先以逆向思考的方式来进行说明：

• 咱们说过，公钥加密/非对称加密方式虽然安全，可是因为密钥过长，加密和解密速度都远远低于对称加密。所以，出于对性能方面的考虑，HTTPS并非把全部传输的数据都使用公钥加密的方式进行机密性的保护，而是继续使用对称加密的方式来加密数据。还有一个缘由就是，使用公钥机密算法来保证数据机密性的话，须要通讯双方都要有密钥对儿，不然总有一方发出的数据是能被对方公布的公钥解密的。

• 既然时使用对称加密的方式加密数据，就须要有一个通讯双方都知道的加解密所使用的密钥。HTTPS是经过上面提到的密钥交换技术来动态协商这个密钥的，实际上就是由客户端生成一个随机密钥，而后发送给服务器端，这样就解决了密钥的管理问题。

• 既然说HTTPS是安全的，那么客户端生成的这个随机密钥确定不能以明文的方式发送给服务器端啊。是的，当客户端以https的方式访问一个站点时，该站点会自动下发其公钥信息。客户端会使用这个公钥对产生的随机密钥进行加密，而后传送给服务器端。服务器端以本身的私钥对这个密文进行解密，而后获得这个密钥的明文内容。至此，客户端与服务端用于对称加密和解密的密钥协商与传输工做已经安全的完成了。

• 那么要经过网络获取服务器端的公钥信息，那么怎么验证该公钥信息的合法性呢？咱们上面说过，不是全部问题都能依赖技术来解决的。这里要验证公钥信息的合法性就要依靠CA证书签发机构了，网站服务的提供者必须找一个你们都信任的机构来对他提供的公钥进行签名，用户获得一个网站下发的公钥后看到有这个机构的签名就认为这个公钥是合法的，是可信赖的。

• 那么CA机构的签名要以什么样的形式来提供呢？实际上网站服务器下发给客户端（一般是浏览器）的公钥已经不只仅是密钥对儿中公钥的内容了，而是包含了证书签发机构写入的其余信息的CA证书。这个CA证书中包括证书签发机构的标识和公钥的数据指纹，固然还有包含网站服务提供者的公钥信息以及证书到期时间等等。可是，咱们前面提到过，单向加密只能保证数据的完整性，不能保证数据机密性。CA证书的伪造者彻底能够伪造公钥信息并生成相应的数据指纹，而后发送给用户。那么如今的问题就变成了要验证CA证书中公钥的合法性以及CA证书提供者的身份了。貌似问题只是转移了，而没有被解决。

• 其实每一个CA证书的签发机构也都有本身的密钥对儿，他们放在CA证书中的公钥的数据指纹时经过本身的私钥加密过的，而这些CA证书签发机构的公钥是被各浏览器厂商内置在浏览器内部的。当浏览器接收到某网站服务器下发的CA证书后会根据CA证书中签发机构的标识来读取浏览器内置的相应CA签发机构的公钥信息，经过这个公钥信息对公钥数据指纹的密文进行解密就能够获得CA证书中包含的公钥信息的真实数据指纹。浏览器再经过单向加密的方式本身计算一次CA证书中包含的公钥信息的数据指纹，两个数据指纹一致则说明这个CA证书确实是该CA机构签发的，同时也证实了CA证书中的公钥信息没有被篡改过。至此，全部的问题就都解决了。

如今咱们再来以正常的顺序描述一下使用HTTPS与网站服务器进行交互的过程：

• 1）浏览器A与网站服务器B经过三次握手后创建网络链接。
• 2）浏览器A告诉网站服务器B：我想跟你经过HTTPS协议进行秘密交流。
• 3）网站服务器B把包含本身公钥信息的CA证书下发给浏览器A，并告诉浏览器A这个CA证书里有个人公钥信息，你决定一个对称加密使用的秘钥串，而后经过这个公钥加密后发送给我。
• 4） 浏览器A接收到网站服务器B下发的CA证书后，对这个CA证书的及其包含的公钥信息的合法性表示怀疑。因而根据CA证书中包含的证书签发机构的标识找到自身内置的该签发机构的公钥对CA证书中公钥的数据指纹进行解密，而后再本身计算一下CA证书中公钥的数据指纹，对了一下这两个数据指纹是一致的。浏览器A放心了，知道这个CA证书是合法的，CA证书中的公钥也没有被篡改过。
• 5）而后浏览器A经过经过密钥协商技术产生了一个随机的字符串做为与网站服务器B进行秘密通讯的密钥，并把这个密钥经过CA证书中包含的公钥进行加密后发送给网站服务器B。
• 6）网站服务器B接收到密文格式的密钥后，经过本身的私钥进行解密获得密钥的明文内容。
• 7）浏览器A和网站服务器B开始了秘密交流。

5、参考资料

• 某哥视频学习笔记
• http://www.ruanyifeng.com/blog/2011/12/ssh_remote_login.html
• http://www.techug.com/post/https-ssl-tls.html