SSL/TLS 与 IPSec 对比
文章目录
- SSL/TLS 与 IPSec 对比
- 1. 前言
- 2. 握手阶段上的区别
- 2.1 IPSec 握手流程
- 2.1.1 第一阶段主模式协商流程
- 2.1.2 第二阶段快速模式协商流程
- 2.2 SSL/TLS握手流程
- 2.2.1 基于ECDHE的握手流程
- 2.2.2 基于RSA的握手流程
- 2.3 ????IPSec与SSL/TLS的对比????
- 2.3.1 密钥配送
- 2.3.2 协商流程
- 2.3.3 协商依赖的协议
- 2.3.4 保护对象
- 2.3.5 端认证
- 2.3.6 NAT兼容性
面向人群：对IPSec和SSL/TLS比较熟悉的人员。
先说说此问题的由来吧????????????
在如今互联互通的数字化信息时代，数据安全越来越受重视。在互联网中存在两个非常相似的安全协议：一个为SSL/TLS协议；另一个为IPSec协议。尽管这两个协议存在多种差别，但是从概念上讲，这两个协议有诸多相似的特性：
- 两个都存在密钥协商、握手阶段和数据传输阶段
- 都能提供机密性，完整性，源认证的功能
- 都是通过协商的方式来完整加密套件的协商
- 都支持做Virtual Private Network
此外应用场景又有很大的重叠。在许多地方都更可将IPsec 当成SSL。既可以用SSL 来保护任何在TCP 上传输的通信数据的安全，也可以使用IPsec 来保护任何IP 上运行的通信数据的安全，其中包括UDP应用。
基于以上种种，这就导致人们刚开始无法知道他们的根本区别。当然还有另外一个原因：面试中的频繁考点，经常让我对比这两个协议，我已经被问了好多次了，因此特地整理下这两个的区别及其各自的特点。 然后从多个方面对这两个协议做一个介绍，
| Ipsec | ssl | 说明 |
| 适用环境 | Site to Site | Client to Site |
| VPN层次 | IP 层 | 应用层 |
| 数据传输 | 隧道方式 | SSL传输 （TCP 443） |
| 客户端 | 需专用软件 | 无需专用客户端软件 |
| VPN部署 | 复杂 | 简单 |
| 远端维护管理 | 复杂，成本高 | 简单，成本低 |
| 部署成本 | 高 | 低 |
| 移动连接 | 不适用 | 适用 |
| 加密级别 | ||
| 复杂应用支持 | 容易 | 较容易 |
| Intranet适用 | 较好 | 很好 |
| Web 应用 | 适合 | 非常适合 |
| 安全级别 | ||
| NAT支持 | 不容易 | |
| 代理访问 | ||
| 穿越防火墙 | ||
| 供应商互操作 | ||
| 即时消息传送、多播、视频会议及VoIP | 较复杂 采用L3VPN | |
| B/S 应用 | 支持 | |
| Legacy application | ||
| http 应用 | ||
| 文件共享 | ||
| Wireless device | ||
| 家庭、网吧、宾馆、其他企业接入 | 不好 | 很好，非常适用 |
| 代理级保护 | 不支持 | |
| 用户认证 | 好 | |
| 用户授权 | 有限 | 灵活 |
| Web 访问一次性认证 | ||
| url 级别的接入限制 | ||
| 域名和IP地址的保护 | ||
| 根据用户访问的类别控制接入 | ||
| Session 级保护 |
表中详细列举了IPSec和SSL/TLS协议的对比，下面对一些关键方面再做一个详细的介绍。
目前，IPSec握手协议有两个：IKEv1, IKEv2。IKEv2在协商流程上大大简化，可以更加快速高效的建立连接。这里主要通过IKEv1来介绍IPSec
如果想看不同模式下的IPSec协商报文格式（附带密钥，可以通过wireshark进行解密），
IKEv1协议中，IPSec握手流程分为两个阶段，共计三种模式。下面以主模式+快速模式共计9个报文交互介绍IPSec
两个阶段为：第一阶段和第二阶段。
第一阶段有两个模式：主模式和野蛮模式；
第二阶段只有一个模式：快速模式。
第一阶段包含6个报文。用来两端建立一条安全通道，在此安全通道的基础上进行第二阶段的协商。
- 第1,2个报文用来协商加密套件,包括加密算法，哈希算法，DH组，认证算法，密钥长度，密钥生存时间等；
- 第3,4个报文用来进行密钥交换(DH算法进行密钥交换)
- 第5,6个报文用来对双方进行认证，对以前交互的报文做一个摘要计算。在此上下文前后完成三把密钥的生成(加密密钥，认证密钥，衍生密钥)
快速模式是在第一阶段建立的安全通道基础上进行的协商。此时协商报文已经被加密，因此交互是安全的。
第一阶段协商的SA用来保护第二阶段；
第二阶段协商的SA是用于保护数据流通讯。 第二阶段协商过程中通过ID载荷完成感兴趣流的协商。
在IPSec中一个第一阶段可以对应多个第二阶段。在一条隧道已经给建立完毕的情况下，如果要想增加感兴趣流，则只需进行第二阶段协商即可，无需再次进行完整协商。这在TLS中也是有相对应的流程！！！
SSL/TLS握手流程(以下简称为SSL握手流程)根据密钥配送方式的不同，可以分为两类：
- 基于ECDHE的握手流程
- 基于RSA的握手流程
如果使用DH算法进行密钥交换，则协商流程中多了一个ServerKeyExchang载荷；如果使用RSA进行密钥配送，则在客户端使用服务器证书中的公钥进行密钥，通过ClientKeyExchange载荷发送出去即可。
SSL握手流程没有细分为多个阶段，但是也需要多个报文交换才能完整SSL连接的建立。
都支持DH算法、基于证书RSA算法进行密钥配送；除此之外IPSec还支持基于预共享密钥的方式。
IPSec分为两个阶段：Phase I和Phase II。而SSL握手中不区分阶段。
????????????那么IPSec为什么要区分两个阶段呢，而SSL却不需要？????????????
这绝对是一个高频考点！！！ 这个目前没有看到标准答案，纯属自己理解，因此欢迎交流讨论
那么IPSec为什么要分为2个阶段呢？
- 更加安全了。在加密的基础上再次进行安全协商，因此会更加安全。就像现在很多文件既提供MD5校验又提供SHA1校验，2份保障，加倍安全。但这个应该不是根本原因
-
可以实现快速协商。为什么加了一个阶段还可以实现快速协商呢？ 这是因为一个第一阶段可以保护多个第二阶段，第一阶段只有第一次建立隧道时可以直接复用第一阶段，后续即使增加多个第二阶段，也不需要再次协商第一阶段(不考虑超时情况)，而第二阶段只需要3个交互、2个往返时间，协商速度更快。而如果没有第二阶段，第一阶段6个报文交互相对来说比较慢。我认为这个原因是最为重要的。在IKEv2中便不再区分第一阶段第二阶段，它的协商更加快速，这也与它优化了协商流程有关。在IKEv2中初次交换需要4个报文建立隧道，之后通过一次ChildSA交换便可以快速建立隧道。
而SSL协商的语义中有一个session复用的概念，如果客户端想要复用一个存在的session, 会在ClientHello中将sessionID设置，服务端如果同意直接跳过握手阶段，发送ChangeCipherSpec通知更换密钥。SSL通过这种方式实现快速复用已经存在会话，因此没有区分多个阶段。
IPSec用来保护IP层安全，使用UDP协议进行协商；
SSL用来保护基于TCP协议的应用层安全，使用TCP协议进行协商
IPSec可以保护所有的IP报文，对于上层应用完全透明。如果要支持IPSec，应用层协议无需任何改动，相当的友好。
但是呢，虽然IPSec不需要修改应用层协议，但是需要修改操作系统。执行AH和ESP协议必须是IP栈的一部分，在大多数操作系统中，网络协议栈位于操作系统内核中，因此安装/激活IPSec就意味着安装一个新的操作系统。不过值得一提的是目前主流的操作系统：windwos, linux都已经支持了IPSec。
而SSL/TLS无需修改操作系统，但是需要适配应用层协议。这么多千奇百怪的应用层，这他么的工作量可想而知，因此即使到目前为止SSL/TLS协议主要还是应用在HTTP、SMTP之上，很多其他应用协议没有适配SSL/TLS。在实际应用中，由于大多数应用实际上都不需要安全。
反对 IPsec 的压倒多数的理由就是需要对IP 栈进行改动。反对这种理由的理由是，为了保护应用的安全而无须对应用进行改动。
IPSec协商流程中，协商双方强制互相认证，这样是不方便的，因为在许多交互中，客户端的身份都是不重要的。而SSL多数情况下只认证服务端(客户端认证可选)
看看IPSec普通的报文封装，你就知道它与NAT兼容性没那么好。NAT设备一般根据报文4元组(IP, 端口)进行转换，但是在IPSec的报文中AH\ESP头部中根本没有端口的概念，因此无法穿越NAT设备。后来IPSec专门修改了在NAT下的报文封装格式：在IP头与AH/ESP头部之间增加一个UDP头部，专门用来做NAT转换；NAT下不再使用IP地址作为标识，改用其他参数作为标识。通过这样的封装可以通过NAT设备了，不过在IPSec协议栈中，增加了很多有关NAT的处理逻辑，导致IPSec的实现更加复杂。
而SSL/TLS协议对NAT完全透明，因为它位于TCP协议之上，与NAT没有半毛钱关系。因此SSL与NAT兼容性非常友好。