1 我们的网络安全吗
上一篇文章我们聊了一下网络能不能不丢包。按照马斯洛大哥的研究成果，如果我们的网络能做到不丢包，那我们是不是应该对它有更高的需求或期望呀。你在和密友通过网络私聊属于你们二人的小秘密时是否担心过小秘密会在网络传输过程中变成小新闻、小谈资；你在熬夜剁手网购时可曾忧虑过一种不明力量在默默的收集你的需求偏好、消费层次、家庭住址、联系方式…….；你在焦急等待下载中的各种老师的作品时希不希望周围的小伙伴都知道那个老师是你的最爱。小到个人的隐私，大到国家机密，数据要从互联网的这头传到那头，就会面临网络安全问题，或者说就会面临泄密的隐患。所幸，网络各领域的专家们一直在努力，努力让你的数据拥有一件\"铁裤衩\"，从此免去在网络上行走时走光的烦恼。
2 哪些技术可以让我们的网络更安全
问题溜达的地方也就是机遇酣睡的地方，网络安全有问题，各种协议就有了抛头露面的机会。上一篇文章我们提到了经典的网络七层模型或TCP/IP模型，网络专家们在不同的层次都提出了相应的解决方案，下面我们就罗列一下在各自的层次混的还不错的几个技术：
2.1 MACSec技术
MACSec（Media Access Control Security）定义了基于IEEE 802局域网络的数据安全通信的方法。MACSec可为用户提供安全的MAC层数据发送和接收服务，包括用户数据加解密、数据帧完整性检查、数据源真实性校验以及重播保护。
MACSec的老底在IEEE802.1AE和802.1X两个标准协议中可以翻出来。
· IEEE802.1AE-2006定义了数据封装、加密和认证的帧格式；
· 802.1X-2010中的MKA（MACSec Key Agreement）定义了密钥管理协议，协议报文仍采用802.1X报文格式，它是对原有802.1X协议的改善和扩展。使用MKA协议协商生成的密钥对已认证的用户数据进行加密和完整性检查，避免端口处理未认证设备的报文或者未认证设备篡改的报文。
MACSec使用二层加密技术，提供逐跳的数据安全传输，适用于政府、金融、军队等对数据机密性要求较高的场合。
2.1.1. MACSec基本概念
· CA（Secure Connectivity Association）是两个或两个以上使用相同密钥及密钥算法套件的成员集合。CA成员称为CA参与者。CA参与者使用的密钥称为CAK(secure Connectivity Association Key)。CAK可在802.1X认证过程中下发，也可由用户静态配置。CAK不直接用于数据报文的加密，由CAK和其他参数派生出数据报文的加密密钥。CAK分为两种类型，一种是由两个成员组成CA，它们所拥有的CAK称为成对CAK（Pairwise CAK），另一种是由三个或三个以上成员组成CA，它们所拥有的CAK称为成组CAK。
· SA（Secure Association）是CA 参与者之间用于建立安全通道的安全参数集合，包括对数据进行加密算法套件、进行完整性检查的密钥等。一个安全通道中可包含多个SA，每一个SA拥有一个不同的密钥，这个密钥称为SAK(Secure Association Key)。SAK 由CAK 根据算法推导产生，用于加密安全通道间传输的数据。每一个SAK加密一定数量的报文后， 该SAK会被更换为另外一个新的SAK。
· MACSec的三个主要功能:
− 数据加解密: 使能了MACSec功能且启动了MACSec保护的端口发送数据帧时，会对报文进行加密；使能了MACSec功能的端口收到经过MACSec封装的数据帧时，会对它进行解密。加解密所使用的密钥是通过MKA协议协商而来的。
− 完整性检查: MACSec封装的数据帧会使用CAK推导出的密钥进行ICV（Integrity Check Value）计算，并附加在MACSec报文的尾部。设备收到MACSec报文时，同样使用MKA协商出的密钥进行完整性检验值计算，然后将计算结果与报文中携带的ICV进行比较。如果比较结果相同，表示收到的报文合法；如果比较结果不同，表示收到的报文不合法。
− 重播保护机制: MACSec封装的数据帧在网络中传输时，可能出现报文顺序的重排。MACSec重播保护机制允许数据帧有一定的乱序，这些乱序的报文序号在用户指定的窗口范围内可以被合法接收，超过窗口范围的报文将被丢弃。
2.1.2. MACSec协议机制
如图1，以面向设备的MACSec为例，介绍MACSec运行机制。运行主要分为三个阶段：
· CAK获取：可以是802.1X 认证过程中生成的CAK，也可以是用户配置的预共享密钥
· MKA密钥协商：设备使用MKA 协议向对方通告自身能力和建立会话所需的各种参数（如优先级、是否期望加密会话等），并选举出一个Key server，Key Server决定加密方案，Key Server会根据CAK等参数使用某种加密算法生成SAK数据密钥，由Key Server将SAK分发给对端设备，这样两台设备拥有相同的SAK数据密钥
· MACSec数据加解密：根据SAK对数据报文进行加解密，实现加密通信
图1 面向设备的MACSec运行机制
面向主机的MACSec模式与上述面向设备的MACSec运行机制类似，在主机接入网络时增加了802.1X身份认证。
2.1.3. MACSec典型组网模式
MACSec常用的组网模式有：面向主机模式、面向设备模式。
1) 面向主机模式
如图2所示，面向主机模式用于保护客户端主机和接入设备之间数据帧的安全传输。
图2 面向主机的MACSec模式
该组网模式主要包括三部分:
· 客户端(Client): 需要接入安全网络的终端设备, 由接入设备对其进行安全认证, 并执行MACSec密钥协商和数据报文的加解密操作。
· 接入设备(Device): 接入设备控制客户端设备的接入，通过与认证服务器的交互(认证服务器与接入设备也可以是同一台设备)，对连接的客户端进行802.1X认证，并执行MACSec密钥协商和报文加解密功能。
· 认证服务器(Authentication Server): 对客户端进行认证、授权和计费。客户端通过认证后，认证服务器为客户端和接入设备分发密钥,用于后续的MACSec密钥协商。
2) 面向设备模式
如图3，面向设备模式用于包括两台设备间的数据业务传输。该模式下，两台设备可直接通过命令行配置CAK密钥进行MACSec密钥协商和报文加解密处理，可以不需要认证服务器。
图3 面向设备的MACSec模式
2.2 IPsec技术
2.2.1. IPsec概述
IPsec（IP Security）是IETF整出来的三层隧道加密协议，它为Internet上传输的数据提供了高质量的、可互操作的、基于密码学的安全保证。特定的通信方之间在IP层通过加密与数据源认证等方式，提供了以下的安全服务：
· 数据机密性（Confidentiality）：IPsec发送方在通过网络传输包前对包进行加密。
· 数据完整性（Data Integrity）：IPsec接收方对发送方发送来的包进行认证，以确保数据在传输过程中没有被篡改。
· 防重放（Anti-Replay）：IPsec接收方可检测并拒绝接收过时或重复的报文。
IPsec牛X的地方：
· 支持IKE（Internet Key Exchange，因特网密钥交换），可实现密钥的自动协商功能，减少了密钥协商的开销。可以通过IKE建立和维护SA的服务，简化了IPsec的使用和管理。
· 所有使用IP协议进行数据传输的应用系统和服务都可以使用IPsec，而不必对这些应用系统和服务本身做任何修改。
· 对数据的加密是以数据包为单位的，而不是以整个数据流为单位，这不仅灵活而且有助于进一步提高IP数据包的安全性，可以有效防范网络攻击。
2.2.2. IPsec协议实现
IPsec协议不是一个单独的协议，它给出了应用于IP层上网络数据安全的一整套体系结构，包括网络认证协议AH（Authentication Header，认证头）、ESP（Encapsulating Security Payload，封装安全载荷）、IKE（Internet Key Exchange，因特网密钥交换）和用于网络认证及加密的一些算法等。其中，AH协议和ESP协议用于提供安全服务，IKE协议用于密钥交换。
IPsec提供了两种安全机制：认证和加密。认证机制使IP通信的数据接收方能够确认数据发送方的真实身份以及数据在传输过程中是否遭篡改。加密机制通过对数据进行加密运算来保证数据的机密性，以防数据在传输过程中被窃听。
IPsec协议中的AH协议定义了认证的应用方法，提供数据源认证和完整性保证；ESP协议定义了加密和可选认证的应用方法，提供数据可靠性保证。
AH协议（IP协议号为51）提供数据源认证、数据完整性校验和防报文重放功能，它能保护通信免受篡改，但不能防止窃听，适合用于传输非机密数据。AH的工作原理是在每一个数据包上添加一个身份验证报文头，此报文头插在标准IP包头后面，对数据提供完整性保护。可选择的认证算法有MD5（Message Digest）、SHA-1（Secure Hash Algorithm）等。
ESP协议（IP协议号为50）提供加密、数据源认证、数据完整性校验和防报文重放功能。ESP的工作原理是在每一个数据包的标准IP包头后面添加一个ESP报文头，并在数据包后面追加一个ESP尾。与AH协议不同的是，ESP将需要保护的用户数据进行加密后再封装到IP包中，以保证数据的机密性。常见的加密算法有DES、3DES、AES等。同时，作为可选项，用户可以选择MD5、SHA-1算法保证报文的完整性和真实性。
在实际进行IP通信时，可以根据实际安全需求同时使用这两种协议或选择使用其中的一种。AH和ESP都可以提供认证服务，不过，AH提供的认证服务要强于ESP。同时使用AH和ESP时，设备支持的AH和ESP联合使用的方式为：先对报文进行ESP封装，再对报文进行AH封装，封装之后的报文从内到外依次是原始IP报文、ESP头、AH头和外部IP头。
2.2.3. IPsec基本概念
1) 安全联盟（Security Association，SA）
IPsec在两个端点之间提供安全通信，端点被称为IPsec对等体。
SA是IPsec的基础，也是IPsec的本质。SA是通信对等体间对某些要素的约定，例如，使用哪种协议（AH、ESP还是两者结合使用）、协议的封装模式（传输模式和隧道模式）、加密算法（DES、3DES和AES）、特定流中保护数据的共享密钥以及密钥的生存周期等。建立SA的方式有手工配置和IKE自动协商两种。
SA是单向的，在两个对等体之间的双向通信，最少需要两个SA来分别对两个方向的数据流进行安全保护。同时，如果两个对等体希望同时使用AH和ESP来进行安全通信，则每个对等体都会针对每一种协议来构建一个独立的SA。
SA由一个三元组来唯一标识，这个三元组包括SPI（Security Parameter Index，安全参数索引）、目的IP地址、安全协议号（AH或ESP）。
SPI是用于唯一标识SA的一个32比特数值，它在AH和ESP头中传输。在手工配置SA时，需要手工指定SPI的取值。使用IKE协商产生SA时，SPI将随机生成。
通过IKE协商建立的SA具有生存周期，手工方式建立的SA永不老化。IKE协商建立的SA的生存周期有两种定义方式：
· 基于时间的生存周期，定义了一个SA从建立到失效的时间；
· 基于流量的生存周期，定义了一个SA允许处理的最大流量。
生存周期到达指定的时间或指定的流量，SA就会失效。SA失效前，IKE将为IPsec协商建立新的SA，这样，在旧的SA失效前新的SA就已经准备好。在新的SA开始协商而没有协商好之前，继续使用旧的SA保护通信。在新的SA协商好之后，则立即采用新的SA保护通信。
2) 封装模式
IPsec有如下两种工作模式：
不同的安全协议在tunnel和transport模式下的数据封装形式如图4所示，data为传输层数据。
图 4 安全协议数据封装格式
3) 认证算法与加密算法
(1) 认证算法
认证算法的实现主要是通过杂凑函数。杂凑函数是一种能够接受任意长的消息输入，并产生固定长度输出的算法，该输出称为消息摘要。IPsec对等体计算摘要，如果两个摘要是相同的，则表示报文是完整未经篡改的。IPsec使用两种认证算法：
· MD5：MD5通过输入任意长度的消息，产生128bit的消息摘要。
· SHA-1：SHA-1通过输入长度小于2的64次方bit的消息，产生160bit的消息摘要。
MD5算法的计算速度比SHA-1算法快，而SHA-1算法的安全强度比MD5算法高。
(2)加密算法
加密算法实现主要通过对称密钥系统，它使用相同的密钥对数据进行加密和解密。目前设备的IPsec实现三种加密算法：
· DES（Data Encryption Standard）：使用56bit的密钥对一个64bit的明文块进行加密。
· 3DES（Triple DES）：使用三个56bit的DES密钥（共168bit密钥）对明文进行加密。
· AES（Advanced Encryption Standard）：使用128bit、192bit或256bit密钥长度的AES算法对明文进行加密。
这三个加密算法的安全性由高到低依次是：AES（这里指AES128,其实还有AES256，更安全）、3DES、DES，安全性高的加密算法实现机制复杂，运算速度慢。对于普通的安全要求，DES算法就可以满足需要。
4) 协商方式
有如下两种协商方式建立SA：
· 手工方式（manual）配置比较复杂，创建SA所需的全部信息都必须手工配置，而且不支持一些高级特性（例如定时更新密钥），但优点是可以不依赖IKE而单独实现IPsec功能。
· IKE自动协商（isakmp）方式相对比较简单，只需要配置好IKE协商安全策略的信息，由IKE自动协商来创建和维护SA。
当与之进行通信的对等体设备数量较少时，或是在小型静态环境中，手工配置SA是可行的。对于中、大型的动态网络环境中，推荐使用IKE协商建立SA。
5) 安全隧道
安全隧道是建立在本端和对端之间可以互通的一个通道，它由一对或多对SA组成。
2.2.4. IPsec虚拟隧道接口
1) 概述
IPsec虚拟隧道接口是一种支持路由的三层逻辑接口，它可以支持动态路由协议，所有路由到IPsec虚拟隧道接口的报文都将进行IPsec保护，同时还可以支持对组播流量的保护。使用IPsec虚拟隧道接口建立IPsec隧道具有以下优点：
· 简化配置：通过路由来确定对哪些数据流进行IPsec保护。与通过ACL指定数据流范围的方式相比，这种方式简化了用户在部署IPsec安全策略时配置上的复杂性，使得IPsec的配置不会受到网络规划的影响，增强了网络规划的可扩展性，降低了网络维护成本。
· 减少开销：在保护远程接入用户流量的组网应用中，在IPsec虚拟隧道接口处进行报文封装，与IPsec over GRE或者IPsec over L2TP方式的隧道封装相比，无需额外为入隧道流量加封装GRE头或者L2TP头，减少了报文封装的层次，节省了带宽。
· 业务应用更灵活：IPsec虚拟隧道接口在实施过程中明确地区分出\"加密前\"和\"加密后\"两个阶段，用户可以根据不同的组网需求灵活选择其它业务（例如NAT、QoS）实施的阶段。例如，如果用户希望对IPsec封装前的报文应用QoS，则可以在IPsec虚拟隧道接口上应用QoS策略；如果希望对IPsec封装后的报文应用QoS，则可以在物理接口上应用QoS策略。
2) 工作原理
IPsec虚拟隧道接口对报文的加封装/解封装发生在隧道接口上。用户流量到达实施IPsec配置的设备后，需要IPsec处理的报文会被转发到IPsec虚拟隧道接口上进行加封装/解封装。
如图5所示，IPsec虚拟隧道接口对报文进行加封装的过程如下：
图 5 IPsec虚接口隧道加封装原理图
(1) Router将从入接口接收到的IP明文送到转发模块进行处理；
(2) 转发模块依据路由查询结果，将IP明文发送到IPsec虚拟隧道接口进行加封装：原始IP报文被封装在一个新的IP报文中，新IP头中的源地址和目的地址分别为隧道接口的源地址和目的地址。
(3) IPsec虚拟隧道接口完成对IP明文的加封装处理后，将IP密文送到转发模块进行处理；
(4)转发模块进行第二次路由查询后，将IP密文通过隧道接口的实际物理接口转发出去。
如图6所示，IPsec虚拟隧道接口对报文进行解封装的过程如下：
图6 IPsec虚接口隧道解封装原理图
(1) Router将从入接口接收到的IP密文送到转发模块进行处理；
(2)转发模块识别到此IP密文的目的地为本设备的隧道接口地址且IP协议号为AH或ESP时，会将IP密文送到相应的IPsec虚拟隧道接口进行解封装：将IP密文的外层IP头去掉，对内层IP报文进行解密处理。
(3)IPsec虚拟隧道接口完成对IP密文的解封装处理之后，将IP明文重新送回转发模块处理；
(4)转发模块进行第二次路由查询后，将IP明文从隧道的实际物理接口转发出去。
从上面描述的加封装/解封装过程可见，IPsec虚拟隧道接口将报文的IPsec处理过程区分为两个阶段：\"加密前\"和\"加密后\"。需要应用到加密前的明文上的业务（例如NAT、QoS），可以应用到隧道接口上；需要应用到加密后的密文上的业务，则可以应用到隧道接口对应的物理接口上。
2.2.5. IKE简介
在实施IPsec的过程中，可以使用IKE（Internet Key Exchange，因特网密钥交换）协议来建立SA，该协议建立在由ISAKMP（Internet Security Association and Key Management Protocol，互联网安全联盟和密钥管理协议）定义的框架上。IKE为IPsec提供了自动协商交换密钥、建立SA的服务，能够为网管网工们减负，简化IPsec的使用和管理、配置和维护工作，使网管网工们能早点回家陪媳妇儿带娃。
IKE鬼的很，不是在网络上直接传输密钥，而是通过一系列数据的交换，最终计算出双方共享的密钥，即使别有用心者截获了双方用于计算密钥的所有交换数据，也只能竹篮打水——空欢喜一场，因为这也不足以计算出真正的密钥。
2.2.6. IKE的安全机制
IKE有一套玄乎的套路，还配了个高大上的名字叫自保护机制，可以在不安全的网络上安全地认证身份、分发密钥、建立IPsec SA。
1) 数据认证
数据认证的两个概念：
· 身份认证：身份认证确认通信双方的身份。支持两种认证方法：预共享密钥（pre-shared-key）认证和基于PKI的数字签名（rsa-signature）认证。
· 身份保护：身份数据在密钥产生之后加密传送，实现了对身份数据的保护。
2) DH
DH（Diffie-Hellman，交换及密钥分发）算法是一种公共密钥算法。通信双方在不传输密钥的情况下通过交换一些数据，计算出共享的密钥。即使别有用心者（如黑客）截获了双方用于计算密钥的所有交换数据，由于其复杂度很高，不足以计算出真正的密钥（当然，现在炒的很热的google的量子计算能否轻易计算出来还不得而知，本着不抬杠的精神，我们暂且理解为也不足以计算出真正的密钥）。所以，DH交换技术可以保证双方能够安全地获得公有信息。
3) PFS
PFS（Perfect Forward Secrecy，完善的前向安全性）特性是一种安全特性，指一个密钥被破解，并不影响其他密钥的安全性，因为这些密钥间没有派生关系。对于IPsec，是通过在IKE阶段2协商中增加一次密钥交换来实现的。PFS特性是由DH算法撑腰的。
2.2.7. IKE的交换过程
IKE使用了两个阶段为IPsec进行密钥协商并建立SA：
(1) 第一阶段，通信各方彼此间建立了一个已通过身份认证和安全保护的通道，即建立一个ISAKMP SA。第一阶段有主模式（Main Mode）和野蛮模式（Aggressive Mode）两种IKE交换方法。
(2) 第二阶段，用在第一阶段建立的安全隧道为IPsec协商安全服务，说人话就是为IPsec协商具体的SA，建立用于最终的IP数据安全传输的IPsec SA。
图7 主模式交换过程
第一阶段主模式的IKE协商过程中包含三对消息：
· 第一对叫SA交换，是协商确认有关安全策略的过程；
· 第二对消息叫密钥交换，交换Diffie-Hellman公共值和辅助数据（如：随机数），密钥材料在这个阶段产生；
· 最后一对消息是ID信息和认证数据交换，进行身份认证和对整个第一阶段交换内容的认证。
野蛮模式交换与主模式交换的主要差别在于，野蛮模式不提供身份保护，只交换3条消息。在对身份保护要求不高的场合，使用交换报文较少的野蛮模式可以提高协商的速度；在对身份保护要求较高的场合，则应该使用主模式。
2.2.8. IKE在IPsec中的作用
· 有了IKE，IPsec很多参数（如：密钥）都可以自动建立，降低了手工配置的复杂度。
· IKE协议中的DH交换过程，每次的计算和产生的结果都是不相关的。每次SA的建立都运行DH交换过程，保证了每个SA所使用的密钥互不相关。
· IPsec使用AH或ESP报文头中的序列号实现防重放。此序列号是一个32比特的值，此数溢出后，为实现防重放，SA需要重新建立，这个过程需要IKE协议的配合。
· 对安全通信的各方身份的认证和管理，将影响到IPsec的部署。IPsec的大规模使用，必须有CA（Certificate Authority，认证中心）或其他集中管理身份数据的机构的参与。
· IKE提供端与端之间动态认证。
2.2.9. IPsec与IKE的关系
图8 IPsec与IKE的关系图
从图8中我们可以看出IKE和IPsec的关系：
· IKE是UDP之上的一个应用层协议，是IPsec的信令协议；
· IKE为IPsec协商建立SA，并把建立的参数及生成的密钥交给IPsec；
· IPsec使用IKE建立的SA对IP报文加密或认证处理。
2.3 CloudSec技术
CloudSec（Cloud Security）定义了VXLAN 网络的数据安全通信方法。CloudSec可为虚拟网络的用户（有个江湖名号叫租户）提供安全的IP层数据的发送和接收服务，包括用户数据的加解密，数据的完整性检查，重播保护等。
2.3.1. CloudSec技术介绍
VXLAN技术是一种大二层的虚拟网络技术（后面有机会我们单独开篇聊一聊这位角儿），虚拟化云计算火起来以后，这家伙迎来了他人生的春天，一度占领了网络虚拟化技术的C位，主要原理就是引入一个UDP格式的外层隧道，而原有数据报文内容作为隧道净荷来传输。由于报文外层采用了UDP封装，使得数据报文具有了在三层网络中转发的能力。
图9 CloudSec 报文格式
如图9所示为CloudSec报文结构（以IPV4为例），报文是在VXLAN报文的基础上，将UDP Header中的L4DstPort修改成INSSec port（标识CloudSec报文的L4 Dest Port），UDP头后面插入SEC TAG。Secure Data部分包含VXLAN Header和VXLAN Payload的加密信息。从CloudSec报文格式可以看出，在不解密CloudSec报文的情况下，可以进行路由转发，很好的克服了MACSec技术在跨网段场景下的限制。
2.3.2. CloudSec组网及转发
在下图VXLAN网络拓扑中，Host A与Host B的通信过程描述如下：
图10 CloudSec报文转发示意图
在VXLAN协议中，隧道的终结点称作VTEP，负责CloudSec加密和封装VXLAN隧道头以及CloudSec解密和解封装VXLAN隧道头。
当HOST A与HOST B在同一网段，分布在不同的VTEP下面，HOST A与HOST B的通信过程详细如下（假设同时采用MACSec,不是必须的）：
(1) HOST A与HOST B处于同一网段，在HOST A请求并获得HOST B的MAC地址。HOST A与VTEP-1之间使能MACSec，HOST A将报文完成MACSec加密后发出；
(2)报文到达VTEP-1后，交换机根据报文解析结果识别为MACSec加密报文，在交换机内部首先进行MACSec加密报文的解密处理，完成解密后根据原始报文的MAC Header字段执行Bridging表项查找。根据查找的结果中的下一跳信息对原始报文执行CloudSec加密和VXLAN加封装处理，最终将报文转发出去。VTEP-1的出口报文MACDA为Router-1的设备MAC-2；MACSA为VTEP-1的设备MAC-1,；外层IPDA为VTEP-2的IP-4，IPSA为VTEP-1的IP-1；增加的外层UDP Header中的L4DstPort为INSSec port而不是VXLAN UDP port（该标识为CloudSec报文的特征之一）；
(3)如果Overlay VXLAN网络中的设备没有使能CloudSec加解密功能，加密报文在网络上依然可以根据外层IP进行转发，最终到达VTEP-2。
2.4 SSL技术
2.4.1. 技术概述
SSL是被召唤出来解决万维网安全性问题的，位于应用层和传输层之间。它理论上能够为所有基于TCP等可靠连接的应用层协议提供安全性保证。它也是利用数据加密、身份验证和消息完整性验证机制来保证网络上传输数据的安全性的。SSL经过这些年的摸爬滚打已成为网络中用来鉴别站点和网页浏览者身份，在浏览器使用者及Webserver之间进行加密通信的全球化标准。SSL协议已被集成到大部分的浏览器中，如IE、chrome、Firefox等。这就意味着任意一台装有浏览器的计算机都支持SSL连接。不须要安装额外的client软件。
2.4.2. 协议工作过程
1) SSL的分层结构
图11 SSL协议分层
如图11所示，SSL位于应用层和传输层之间，它能够为所有基于TCP等可靠连接的应用层协议提供安全性保证。SSL协议本身分为两层：
· 上层为SSL握手协议（SSL handshake protocol）、SSLpassword变化协议（SSL change cipher spec protocol）和SSL警告协议（SSL alert protocol）。
· 底层为SSL记录协议（SSL record protocol）。
其中：
· SSL握手协议：是SSL协议很重要的组成部分。用来协商通信过程中使用的加密套件（加密算法、密钥交换算法和MAC算法等）、在server和client之间安全地交换密钥、实现server和client的身份验证。
· SSLpassword变化协议：client和server端通过password变化协议通知对端。随后的报文都将使用新协商的加密套件和密钥进行保护和传输。
· SSL警告协议：用来向通信对端报告告警信息，消息中包括告警的严重级别和描写叙述。
· 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握手过程
图12 仅验证server的SSL握手过程
如图12所示，仅须要验证SSL server身份，不须要验证SSL client身份时，SSL的握手过程为：
(1) SSL client通过Client Hello消息将它支持的SSL版本号、加密算法、密钥交换算法、MAC算法等信息发送给SSL server。
(2) SSL server确定本次通信采用的SSL版本号和加密套件，并通过Server Hello消息通知给SSL client。假设SSL server同意SSL client在以后的通信中重用本次会话，则SSL server会为本次会话分配会话ID。并通过Server Hello消息发送给SSL client。
(3) SSL server将携带自己公钥信息的数字证书通过Certificate消息发送给SSL client。
(4) SSL server发送Server Hello Done消息。通知SSL client版本号和加密套件协商结束。开始进行密钥交换。
(5) SSL client验证SSL server的证书合法后，利用证书中的公钥加密SSL client随机生成的premaster secret，并通过Client Key Exchange消息发送给SSL server。
(6) SSL client发送Change Cipher Spec消息，通知SSL server报文将采用协商好的密钥和加密套件进行加密和MAC计算。
(7) SSL client计算已交互的握手消息（除Change Cipher Spec消息外全部已交互的消息）的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并加入MAC值、加密等），并通过Finished消息发送给SSL server。SSL server利用相同的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比較，假设二者相同，且MAC值验证成功，则证明密钥和加密套件协商成功。
(8) 相同地。SSL server发送Change Cipher Spec消息，通知SSL client报文将采用协商好的密钥和加密套件进行加密和MAC计算。
(9) SSL server计算已交互的握手消息的Hash值，利用协商好的密钥和加密套件处理Hash值（计算并加入MAC值、加密等），并通过Finished消息发送给SSL client。SSL client利用相同的方法计算已交互的握手消息的Hash值，并与Finished消息的解密结果比較，假设二者相同。且MAC值验证成功。则证明密钥和加密套件协商成功。
SSL client接收到SSL server发送的Finished消息后。假设解密成功，则能够推断SSL server是数字证书的拥有者，即SSL server身份验证成功，由于仅仅有拥有私钥的SSL server才从Client Key Exchange消息中解密得到premaster secret，从而间接地实现了SSL client对SSL server的身份验证。
备注：
· Change Cipher Spec消息属于SSL password变化协议，其它握手过程交互的消息均属于SSL握手协议，统称为SSL握手消息。
· 计算Hash值。指的是利用Hash算法（MD5或SHA）将随意长度的数据转换为固定长度的数据。
<2 验证server和client的SSL握手过程
图13 验证server和client的SSL握手过程
SSL client的身份验证是可选的，由SSL server决定是否验证SSL client的身份。
如图13中蓝色部分标识的内容，假设SSL server验证SSL client身份。则SSL server和SSL client除了交互上一节中的消息协商密钥和加密套件外，还须要进行下面操作：
(1) SSL server发送Certificate Request消息。请求SSL client将其证书发送给SSL server。
(2) SSL client通过Certificate消息将携带自己公钥的证书发送给SSL server。SSL server验证该证书的合法性。
(3) SSL client计算已交互的握手消息、主密钥的Hash值。利用自己的私钥对其进行加密，并通过Certificate Verify消息发送给SSL server。
(4) SSL server计算已交互的握手消息、主密钥的Hash值。利用SSL client证书中的公钥解密Certificate Verify消息，并将解密结果与计算出的Hash值比较。假设二者相同，则SSL client身份验证成功。
<3 恢复原有会话的SSL握手过程
图14 恢复原有会话的SSL握手过程
协商会话參数、建立会话的过程中。须要使用非对称密钥算法来加密密钥、验证通信对端的身份。计算量较大，占用了大量的系统资源。
为了简化SSL握手过程。SSL同意重用已经协商过的会话，详细过程为：
(1) SSL client发送Client Hello消息，消息中的会话ID设置为计划重用的会话的ID。
(2) SSL server假设同意重用该会话，则通过在Server Hello消息中设置同样的会话ID来应答。这样，SSL client和SSL server就能够利用原有会话的密钥和加密套件。不必又一次协商。
(3) SSL client发送Change Cipher Spec消息，通知SSL server报文将采用原有会话的密钥和加密套件进行加密和MAC计算。
(4) SSL client计算已交互的握手消息的Hash值，利用原有会话的密钥和加密套件处理Hash值，并通过Finished消息发送给SSL server，以便SSL server推断密钥和加密套件是否正确。
(5) SSL server发送Change Cipher Spec消息，通知SSL client报文将采用原有会话的密钥和加密套件进行加密和MAC计算。
(6) SSL server计算已交互的握手消息的Hash值，利用原有会话的密钥和加密套件处理Hash值，并通过Finished消息发送给SSL client。以便SSL client推断密钥和加密套件是否正确。
2.5 HTTPS技术
HTTPS是基于SSL安全连接的HTTP协议。HTTPS通过SSL提供的数据加密、身份验证和消息完整性验证等安全机制。为Web訪问提供了安全性保证，广泛应用于网上银行、电子商务等领域。
图14为HTTPS在网上银行中的应用
上图为你和她通过访问银行的Webserver进行帐户查询、转帐等时网络的真实写照。通过在你和银行的Webserver之间建立SSL连接，能够保证你的信息不被非法窃取。
3 为了网络安全我们该怎么办
上文带大家从TCP/IP模型中的MAC层到应用层一路走来，分别拜访了MAC层加密扛把子MACsec技术，IP层加密一哥Ipsec技术，位于传输层UDP协议之上的虚拟化网络界的加密帮主Cloudsec技术，传输层TCP协议之上的加密教主SSL技术及应用层的加密小霸王HTTPS技术。一言以蔽之，就是和各层由头有脸的加密计算都混了个脸熟，建立了\"联系\"。
认识以后就要深交，有这么多加密高手朋友，我们文初的那些担心和忧虑理论上都是可以彻底打扫干净的。当然我们也不能一有安全顾虑就把这几个高手都叫来，毕竟人家也都是自己层次的角儿或腕儿，出场费都是得手指头搓一会儿的。
如果你是个人用户或个体工商户或者其他小团队，建议首选HTTPS。细心不健忘的你应该会记得前面我们提到过，几乎任何一台能装浏览器的电脑都能支持HTTPS。如果你只想对某些应用进行加密，那么请你的SSL朋友出场比较合适。如果你的场景是虚拟化网络，那么可能你的Cloudsec朋友出面更合适。当然，如果你的team够大，你的所有应用都需要安全可靠，最好还是联系一下你的IPsec朋友吧。如果你的企业也好组织机构也罢，不差钱且有极高的安全等级要求，你的MACsec朋友不来可能也不合适。那么如果你说你天生缺乏安全感，恰恰你又足够的豪（土不吐不重要），让他们都来也不过分，甚至你可以让它们给你引荐另一位行踪诡异、居无定所、加密江湖人称定制化的加密高手出山来为你的数据护驾。
