• 密码技术是实现VPN的关键核心技术之一。
• 一般情况下，在VPN实现中：
  • 双方大量的通信流量的加密使用对称加密算法，运算量小、速度快。众多算法中最常用的是DES（Data Encryption Standard）、AES（Adva nced Encryption Standard）和IDEA（Interna tional Data Encryption Algorithm）
  • 而在管理、分发对称加密的密钥上采用更加安全的非对称加密技术。

• VPN需要解决的首要问题就是网络上用户与设备的身份认证。
• 从技术上说，身份认证基本上可以分为两类：非PKI体系和PKI体系的身份认证。
  • 非PKI体系：UID+PASSWORD
    • PAP，Password Authentication Protocol，口令认证协议
    • CHAP，Challenge Handshake Authentication Protocol，挑战握手认证协议
    • MS CHAP，Microsoft Challenge Handshake Authentication Protocol，微软CHAP
    • RADIUS，Remote Authentication Dial In User Service ，远程认证拨号用户服务
  • PKI体系
    • 常用的方法是依赖于CA（Certificate Authority，数字证书签发中心）所签发的符合X.509规 范的标准数字证书。
    • 通信双方交换数据前，需先确认彼此的身份，交换彼此的数字证书，双方将用此证书进行比较，只有比较结果正确，双方才开始交换数据 ；否则，不能进行后续通信

• 隧道技术通过对数据进行封装，在公共网络上建立一条数据通道（隧道），让数据包通过这条隧道传输。
• 生成隧道的协议有三种：
  • 第二层隧道协议
    • 第二层隧道协议是在数据链路层进行的，先把各种网络协议封装到PPP包中，再把整个数据包装入隧道协议中，这种经过两层封装的数据包由第二层协议进行传输
      • L2F（RFC 2341，Layer 2 Forwarding）
      • PPTP（RFC 2637，Point to Point Tunneling Protocol）
      • L2TP（RFC 2661，Layer Two Tunneling Protocol）。
    • 采用L2TP还是PPTP实现VPN取决于要把控制权放在NAS(Network Access Server)还是用户手中。
    • L2TP比PPTP更安全，因为L2TP接入服务器能够确定用户从哪里来。L2TP主要用于比较集中的、固定的VPN用户，而PPTP比较适合移动的用户。
  • 第三层隧道协议
    • 在网络层进行的，把各种网络协议直接装入隧道协议中，形成的数据包依靠第三层协议进行传输
      • IPSec (IP Security)，是目前最常用的VPN解决方案
      • GRE(RFC 2784，General Routing Encapsulation)
        • GRE主要用于源路由和终路由之间所形成的隧道。例如，将通过隧道的报文用一个新的报文头（GRE报文头）进行封装然后带着隧道终点地址放入隧道中。当报文到达隧道终点时 ，GRE报文头被剥掉，继续根据原始报文的目标地址进行寻址。
        • GRE隧道技术是用在路由器中的，可以满足Extranet VPN以及Intranet VPN的需求
  • 第四层隧道协议
    • 工作在传输层,把网络层数据包或应用数据装入隧道协议中，形成的数据包依靠传输层协议进行传输
      • TLS（ Transport Layer Security）：传输层安全性协议
      • TLS/SSL VPN 主要为远程访问VPN（Access-VPN)

• 在VPN应用中密钥的分发与管理非常重要。密钥的分发有两种方法：
  • 手工配置：要求密钥更新不要太频繁，否则管理工作量太大，因此只适合于简单网络的情况。
  • 采用密钥交换协议动态分发：采用软件方式动态生成密钥，保证密钥在公共网络上安全地传输而不被窃取，适合于复杂网络的情况，而且密钥可快速更新，可以显著提高VPN应用的安全性

• 访问控制决定了谁能够访问系统、能访问系统的何种资源以及如何使用这些资源
• 采取适当的访问控制措施能够阻止未经允许的用户有意或无意地获取数据，或者非法访问系统资源等。

隧道协议

• 指通过一个公用网络（通常是 Internet）建立的一条穿过公用网络的安全的、逻辑上的隧道。在隧道中，数据包被重新封装发送

VPN的主要封装协议:

• 第2层的隧道协议
  • –包括PPTP、L2TP、L2F等
• 第3层的隧道协议
  • –包括IPSec、GRE等
• 第4层的隧道协议
  • –包括SSL、TLS等。

• PPTP
  • 让远程用户拨号连接到本地ISP、通过Internet安全远程访问公司网络资源。
  • PPTP具有两种不同的工作 模式，即被动模式和主动模式。
• L2F
  • 可以在多种介质（如ATM、 帧中继、IP网）上建立多协议的安全虚拟专用网。
  • 它将链路层的协议（如 HDLC，PPP， ASYNC等）封装起来传送
• L2TP
  • 在上述两种协议的基础上产生。 适合组建远程接入方式的VPN。

• 优点
  • 简单易行
• 缺点
  • 可扩展性都不好
  • 不提供内在的安全机制，不能保证企业和企业的外部客户及供应商之间会话的保密性

• 大型网络系统内运行多种网络协议（TCP/IP、IPX/SP X和NETBEUA等）这些网络协议并非为安全通信设计
• IP协议维系着整个TCP/IP协议的体系结构，除了数据链路层外，TCP/IP的所有协议的数据都是以IP数据报 的形式传输的。
• TCP/IP协议簇有两种IP版本：IPv4、IPv6。IPv6简化了IP头，其数据报更加灵活，同时IPv6还增加了对安全性的考虑

• IPv4在设计之初没有考虑安全性，导致在网络上传输的数据很容易受到各式各样的攻击：比如伪造IP包地址、修改其内容、重播以前的包以及在传输途中拦截并查看包的内容等。因此，通信双方不能保证收到IP数据报的真实性
• 为了加强因特网的安全性，从1995年开始，IETF着手制定了一套用于保护IP通信的IP安全协议（IP Security，IPSec）。IPSec弥补了IPv4在协议设计时缺乏安全性考虑的不足。

• IPSec协议簇主要包括两个安全协议：AH协议和ESP协议
  • AH协议（Authentication Header，验证头）：可以进行数据源身份验证、保障数据的完整性以及防止相同数据包在因特网重放
  • ESP协议（Encapsulating Security Payload，封装安全载荷）：具有所有AH的功能，还可以利用加密技术保障数据机密性。
• 虽然AH和ESP都可以提供身份认证，但它们有2点区别：
  • ESP要求使用高强度的加密算法，会受到许多限制。
  • 多数情况下，使用AH的认证服务已能满足要求，相对来说，ESP开销较大。
• 有两套不同的安全协议意味着可以对IPSec网络进行更细粒度的控制，选择安全方案可以有更大的灵活度
• AH和ESP可以单独使用，也可以组合使用，可以在两台主机、两台安全网关（防火墙和路由器），或者主机与安全网关之间使用
• IKE（Internet Key Exchange）
  • IKE协议负责密钥管理，定义了通信实体间进行身份认证、协商加密算法以及生成共享的会话密钥的方 法。
  • IKE将密钥协商的结果保留在安全联盟（SA）中，供AH和ESP以后通信时使用
• DOI（Domain of Interpretation）
  • 解释域DOI定义IKE所没有定义的协商的内容；
  • DOI为使用IKE进行协商SA的协议统一分配标识符。共享一个DOI的协议从一个共同的命名空间中选择安 全协议和变换、共享密码以及交换协议的标识符等
  • DOI将IPSec的这些RFC文档联系到一起

• 保证数据完整性
  • IPSec通过验证算法保证数据从发送方到接收方的传送过程中的任何数据篡改和丢失都可以被检测。
• 保证数据机密性
  • IPSec通过加密算法使只有真正的接收方才能获取真正的发送内容，而他人无法获知数据的真正内容

• SA（Security Association，安全关联）
  • 是两个IPSec实体（主机、安全网关）之间经过协商建立起来的一种协定。
  • 内容包括采用何种IPSec协议（AH还是ESP）、运行模式（传输模式还是隧道模式）、验证算法、加密算法 、加密密钥、密钥生存期、抗重放窗口、计数器等，从而决定了保护什么、如何保护以及谁来保护。
  • 可以说SA是构成IPSec的基础。
  • 每个SA由三元组（SPI，IP目的地址，IPSec协议）来唯一标识
    • SPI（Security Parameter Index，安全参数索引）是32位的安全参数索引，用于标识具有相同IP地址和相同安全协议的不同的SA，它通常被放在AH或ESP头中
    • IP目的地址：它是SA的终端地址。
    • IPSec协议：采用AH或ESP。
  • SA是单向的，在一次通信中，IPSec需要建立两个SA，一个用于入站通信，另一个用于出站通信
• SAD（Security Association Database，安全关联数据库）
  • SAD并不是通常意义上的“数据库”，而是将所有的SA以某种数据结构集中存储的一个列表。
  • 对于外出的流量，如果需要使用IPSec处理，然而相应的SA不存在，则IPSec将启动IKE来协商出一个SA，并存储到SAD中
  • 对于进入的流量，如果需要进行IPSec处理，IPSec将从IP包中得到三元组（SPI,DST,Protocol），并利用这个三元组在SAD中查找一个SA。
• SP（Security Policy，安全策略）
  • 决定对IP数据包提供何种保护，并以何种方式实施保护。
  • SP主要根据源IP地址、目的IP地址、入数据还是出数据等来标识。
  • IPSec还定义了用户能以何种粒度来设定自己的安全策略，不仅可以控制到IP地址，还可以控制到传输层协议或者TCP/UDP端口等
• SPD（Security Policy Database，安全策略数据库）
  • SPD也不是通常意义上的“数据库”，而是将所有的SP以某种数据结构集中存储的列表。 （包处理过程中，SPD和SAD两个数据库要联合使用）
  • 当接收或将要发出IP包时，首先要查找SPD来决定如何进行处理。存在3种可能的处理方式：丢弃、不用 IPSec和使用IPSec。
    • 丢弃：流量不能离开主机或者发送到应用程序，也不能进行转发。
    • 不用IPSec：对流量作为普通流量处理，不需要额外的IPSec保护。
    • 使用IPSec：对流量应用IPSec保护，此时这条安全策略要指向一个SA。对于外出流量，如果该SA尚不存在，则启动IKE进行协商，把协商的结果连接到该安全策略上。

SPD示例

• IPSec的实现方式有两种：传输模式（Trans port Mode）和隧道模式（Tunnel Mode）
• AH和ESP都支持这两种模式，因此有四种组合：
  • 传输模式的AH
  • 隧道模式的AH
  • 传输模式的ESP
  • 隧道模式的ESP

• 采用传输模式时，IPSec只对IP数据包的净荷进行加密或认证。
• 封装数据包继续使用原IP头部，只对部分域进行修改。
• 而IPSec协议头部插入到原IP头部和传输层头部之间。
• 只用于两台主机之间的安全通信

• 隧道模式保护的是整个IP包。通常情况下，只要IPSec双方有一方是安全网关或路由器，就必须使用隧道模式
• 采用隧道模式时，IPSec对整个IP数据包进行加密或认证。
• 产生一个新的IP头，IPSec头被放在新IP头和原IP数据包之间，组成一新IP头。

AH、ESP或AH+ESP既可以在隧道模式中使用，又可以在传输模式中使用

• IPSec的工作原理类似于包过滤防火墙，可以把它看做是包过滤防火墙的一种扩展。
• IPSec网关通过查询安全策略数据库（SPD）决定对接收到的IP数据包进行转发、丢弃或IPSec处理
• IPSec网关可以对IP数据包只进行加密或认证，也可以对数据包同时实施加密和认证。
• 无论是进行加密还是进行认证，IPSec都有两种工作模式：传输模式和隧道模式

• 外出处理过程中，传输层的数据包流入IP层。IP层检索SPD数据库，判断应为这个包提供哪些服务。可能有以下几种情况：
  • 丢弃：简单丢掉
  • 不应用安全服务：为载荷增添IP头，然后分发IP包
  • 应用安全服务：如果已建立SA，则返回指向该SA的指针；如果未建立SA，则调用IKE建立SA。按照建立的SA，增添适当的AH和ESP头。

• 收到IP包后，如果包内没有IPSec头，则根据安全策略对包进行检查，决定如何处理：
  • 丢弃：直接丢弃；
  • 应用安全服务：如果没有ipsec头，说明包有问题，丢弃；
  • 不应用安全服务：将包载荷传给上层协议处理
• 如果IP包中包含了IPSec包：
  • 从IP包中提取三元组(SPI，目标地址，协议)在SAD中检索
  • 根据协议值交给AH层或ESP层处理。
  • 协议载荷处理完之后，要在SPD中查询策略，验证SA使用是否得当

IPSec中主要由AH、ESP和IKE三个协议来实现加密、认证和管理交换功能。

• AH
  • RFC 2402将AH服务定义如下：
    • 非连接的数据完整性校验；
    • 数据源点认证；
    • 可选的抗重放攻击服务。
  • AH有两种实现方式：传输方式和隧道方式
  • AH只涉及认证，不涉及加密
• ESP
  • ESP协议主要用于对IP数据包进行加密，此外也对认证提供某种程度的支持。
  • ESP协议也有两种工作模式：传输模式和隧道模式。
• IKE
  • 用于动态建立安全关联（SA，Security Association）

• AH对IP层的数据使用验证算法MAC，从而对完整性进行保护。
• MAC（Message Authentication Codes，报文验证码），即报文摘要，是从HASH算法演变而来，又称为HMAC，如HMAC-MD5、HMAC-SHA1、HMAC-RIPEMD-160。
• 通过HMAC可以检测出对IP包的头部和载荷的修改，从而保护IP包的内容完整性和来源可靠性。
• 不同IPSec系统可用的HMAC算法可能不同，但HMAC-MD5和HMAC-SHA1是必须实现的
• AH协议和TCP、UDP协议一样，是被IP协议封装的协议之一，可以由IP协议头部中的协议字段判断，AH的协议号是51

AH传输模式

• AH插入到IP头部（包括IP选项字段）之后，传输层协议（如TCP、UDP）或者其他IPSec协议之前
• 被AH验证的区域是整个IP包（可变字段除外），包括IP包头部，因此源IP地址、目的IP地址是不能修改的，否则会被检测出来
• 然而，如果该包在传送的过程中经过NAT网关，其源/目的IP地址将被改变，将造成到达目的地址后的完整性验证失败。因此，AH在传输模式下和NAT是冲突的，不能同时使用，或者可以说AH不能穿越NAT

AH隧道模式

• 在隧道模式中，AH插入到原始IP头部之前，然后在AH之前再增加一个新的IP头部
• 隧道模式下，AH验证的范围也是整个IP包，因此上面讨论的AH和NAT的冲突在隧道模式下也存在。
• 在隧道模式中，AH可以单独使用，也可以和ESP一起嵌套使用。

数据完整性检查

• 在发送方，整个IP包和验证密钥被作为输入，经过HMAC算法计算后得到的结果被填充到AH头部的“验证数据”字段中

• 在接收方，整个IP包和验证算法所用的密钥也被作为输入，经过HMAC算法计算的结果和AH头部的“验证数据”字段进行比较

• 如果一致，说明该IP包数据没有被篡改，内容是真实可信的

• ipv4不定字段（在通信过程中可能被合法修改）：

  • 在计算HMAC时先临时用0填充；

  • 另外，AH头部的验证数据字段在计算之前也要用0填充，计算之后再填充验证结果。

• 应被AH保护的内容（在通信过程应该不被修改）：

  • 固定字段；
  • AH头中除“验证数据”以外的其他字段；
  • 数据：指经过AH处理之后，在AH头部后面的数据。
    • 传输方式下，指TCP、UDP或ICMP等传输层数据
    • 隧道模式下，指被封装的原IP包。

• 与AH相比，ESP验证的数据范围要小一些。ESP协议规定了所有IPSec系统必须实现的验证算法：HMAC-MD5、HMAC-SHA1、NULL。
• ESP的加密采用的是对称密钥加密算法。不同的IPSec实现，其加密算法也有所不同。为了保证互操作性，ESP协议规定了所有IPSec系统都必须实现的加密算法：DES-CBC、NULL。
• 但ESP协议规定加密和认证不能同时为NULL。即加密和认证必须至少选其一
• ESP协议和TCP、UDP协议一样，是被IP协议封 装的协议之一，可以由IP协议头部中的协议字 段判断，ESP的协议号是50

ESP传输模式

• 保护的是IP包的载荷；
• ESP插入到IP头部（包括IP选项字段）之后，任何被IP协议所封装的协议（如传输层协议TCP、UDP、ICMP，或者IPSec协议）之前
• ESP加密不包括SPI、序号字段和验证数据；（不包括头）
• ESP的验证不包括IP头部：
  • 优点：不存在与NAT冲突的问题；
  • 缺点：除了ESP头部之外，任何IP头部字段都可以修改，只要保证其校验和计算正确，接收端就不能检测出这种修改。所以，ESP传输模式的验证服务要比AH传输模式弱一些。如果需要更强的验证服务并且通信双方都是公有IP地址，应该采用AH来验证，或者将AH认证与ESP验证同时使用

ESP隧道模式

• 保护的是整个IP包，对整个IP包进行加密；
• 在隧道模式中，ESP插入到原始IP头部之前，然后在ESP之前再增加一个新的IP头部
• ESP隧道模式的验证和加密能够提供比ESP传输模式更加强大的安全功能，因为隧道模式下对整个原始IP包进行验证和加密，可以提供数据流加密服务；而ESP在传输模式下不能提供流加密服务，因为源、目的IP地址不被加密。
• 不过，隧道模式将占用更多的带宽，因为增加了一个额外的IP头部。
• 尽管ESP隧道模式的验证功能不像AH传输模式或隧道模式那么强大，但ESP隧道模式提供的安全功能已经足够了

ESP处理

• 根据ESP采用的模式来具体处理。
• 注意：
  • 密文是得到验证的，而验证中包括未加密的明文.
  • 所以：外出报文—先加密；进入报文—先验证

AH & ESP

• IPSec协议使用认证头标AH和封装安全净载ESP两种安全协议来提供安全通信。两种安全协议都分为隧道模式和传输模式。
• 传输模式用在主机到主机的通信，隧道模式用在其它任何方式的通信

IKE协议分两个阶段：

• 第一阶段：建立IKE安全关联，即在通信双方之间协商密钥
• 第二阶段：利用这个既定的安全关联为IPSec建立安全通道。

Internet密钥交换

• Internet密钥交换（IKE）用于动态建立SA
• IKE属于一种混合型协议，由RFC2409定义，包含了3个不同协议的有关部分：ISAKMP、O akley和SKEME ，还定义了自己的两种密钥交换方式。
• IKE并非为IPSec专用，只要其他协议需要， 都可用它协商具体的安全服务。

ISAKMP协议

• ISAKMP（Internet Security Association Key Mana gement Protocol，Internet安全联盟密钥管理协议）：RFC2408。
• 定义了协商、建立、修改和删除SA的过程和包格式。
• ISAKMP只是为协商、修改、删除SA的方法提供了一个通用的框架，并没有定义具体的SA格式。这个通用的 框架是与密钥交换独立的，可以被不同的密钥交换协议使用。
• ISAKMP报文可以利用UDP或者TCP，端口都是500，一般情况下常用UDP协议

ISAKMP协议报文

• ISAKMP报文的头部是固定长度的，包含了维护状态、处理载荷必要的信息

• 发起方Cookie（Initiator Cookie）：64位

  • Cookie可以帮助通信双方确认一个ISAKMP报文是否真的来自对方。
  • 在发起方，如果收到的某报文的应答方Cookie字段和以前收到的该字段不同，则丢弃该报文；同样，在应答方，如果收到的某报文的发起方Cookie和以前收到的该字段不同，则丢弃该报文。这种机制可以防止DOS攻击。
  • 尽管Cookie的生成方法在实现不同的ISAKMP时可能不同，但无论发起方还是响应方，Cookie必须满足两个条件：
    • Cookie必须是用各自的机密信息生成的，该机密信息不能从Cookie中推导出来；
    • 对于一个SA，其Cookie是惟一的，也就是说对于一次SA协商过程，Cookie不能改变。
  • 常用的一个生成Cookie的方法是对下述信息进行HASH（MD5、SHA1或其他HASH算法）之后，取结果的前64位： 源IP地址＋目的IP地址＋UDP源端口＋UDP目的端口＋随机数＋当前日期＋当前时间

• 应答方Cookie(Responder Cookie): 64位

  • 应答方的Cookie，紧跟在发起方Cookie之后

• 下一个载荷（Next Payload）：4位

  • 表示紧跟在ISAKMP头部之后的第一个载荷的类型值。

• 主版本（Major Version）：4位

  • 表示ISAKMP协议的主版本号。

• 次版本（Minor Version）：4位

  • 表示ISAKMP协议的次版本号。

• 交换类型（Exchange Type）：8位

  • 表示该报文所属的交换类型

• 标志（Flags）：8位

  • 目前只有后3位有用，其余保留，用0填充。后3位的含义从最后一位往前依次为：
    • 加密位（encryption），0x01。加密位如果是1，表示ISAKMP头部后面的所有载荷都被加密了；如果是0，表示载荷是明文，没有加密。
    • 提交位（commit），0x02。用于确保在发送被保护的数据之前完成SA协商。
    • 纯验证位（Authentication Only），0x04。主要由哪些希望为ISAKMP引入密钥恢复机制的人使用。

• 报文ID（Message ID）：32位

  • 包含的是由第二阶段协商的发起方生成的随机值，这个惟一的报文标识可以惟一确定第二阶段的协议状态。

• 报文长度（length）：32位

  • 以字节为单位表示了ISAKMP整个报文（头部+若干载荷）的总长度。

ISAKMP载荷

• ISAKMP双方交换的内容称为载荷（payload ）。对于一个用基于ISAKMP的密钥管理协议 交换的消息来说，其构建方法是：将ISAKMP所有载荷链接到一个ISAKMP头。
• 目前定义了13种载荷，它们都是以相同格式的头开始的

ISAKMP载荷头部

不论何种载荷，都有一个相同格式的载荷头部

• 下一个载荷（Next Payload）：8位
  • 表示紧跟在本载荷后面的下一个载荷的类型。
  • 第一个载荷的类型在ISAKMP头部中指明，最后一个载荷的Next Payload类型为0。
• 保留（reserved）：8位，全0
• 载荷长度（Payload Length）：16位
  • 以字节为单位表示的载荷长度（包括载荷头部），定义了每个载荷的边界

ISAKMP协商阶段

• 阶段1
  • 这个阶段要协商的SA可以称为ISAKMP SA（在IKE中可以称为 IKE SA），该SA是为了保证阶段2的安全通信。
• 阶段2
  • 这个阶段要协商的SA是密钥交换协议最终要协商的SA，当IKE为IPSec协商时可以称为IPSec SA，是保证AH或者ESP的安全通信。
  • 阶段2的安全由阶段1的协商结果来保证。阶段1所协商的一个SA可以用于协商多个阶段2的SA。

ISAKMP交换类型

• 交换类型定义的是在通信双方所传送的载荷的类型和顺序，比如一方先发送什么载荷，另一方应如何应答等。这些交换模式的区别在于对传输信息的保护程度不同，并且传输的载荷多少也不同
• ISAKMP本身没有定义具体的密钥交换技术。对于IPSec而言，已定义的密钥交换就是IKE。IKE交换的最终结果是一个通过验证的密钥以及建立在双方同意基础上的安全联盟SA

IKE交换模式

• IKE基于两个阶段ISAKMP来建立安全联盟SA，第一阶段建立SA，第二阶段用IKE SA建立IPSec的SA
• 第一阶段
  • 主模式
  • 积极模式/野蛮模式 （建立IKE SA，建立验证过的密钥，是其他交换的前提条件）
• 第二阶段
  • 快速模式（为IPSec协商安全服务）

IKE身份认证方式

• 基于预共享字符串（Pre_Shared Key）
  • 双方事先通过某种方式商定好一个双方共享的字符串
• 基于数字签名（Digital Signature）
  • 利用数字证书来表示身份，利用数字签名算法计算出一个签名来验证身份。
• 基于公开密钥（Public Key Encryption）
  • 利用对方的公开密钥加密身份，通过检查对方发来的该HASH 值作认证。
• 基于修正的公开密钥（Revised Public Key Encrypt ion）
  • 对上述方式进行修正

IKE第一阶段

IKE第二阶段

一个完整的IPSec的工作原理

• IPSec VPN通信性能低。由于IPSec VPN在 安全性方面比较高，影响了它的通信性能
• IPSec VPN需要客户端软件，可能带来了与其他系统软件之间兼容性问题的风险
• 安装和维护困难
• 实际全面支持的系统比较少，很少有能运行在其它PC系统平台的，如Mac、Linux、Solaris 等
• 不易解决网络地址转换(NAT)和穿越防火墙的问题

• FreeS/WAN是Linux操作系统中包含的IPsec VPN实现方案。
• 在网上可以找到其开放的源代码下载网址： www.freeswan.org

• SSL VPN也称做传输层安全协议（TLS）VPN

• TLS协议主要用于HTTPS协议中，TLS也可以作为构造VPN的技术

• TLS VPN的最大优点是用户不需要安装和配置客户端软件。

• 只需要在客户端安装一个IE浏览器即可。

• 由于TLS协议允许使用数字签名和证书，故它能提供强大的认证功能。

• SSL VPN可在NAT代理装置上以透明模式工作
• SSL VPN不会受到安装在客户端与服务器之间的防火墙等NAT设备的影响，穿透能力强
• SSL VPN将远程安全接入延伸到IPSec VPN扩展不到的地方，降低了部署和支持费用
• 客户端安全检查和授权访问等操作，实现起来更加方便
• SSL VPN可以在任何地点，利用任何设备，连接到相应的网络资源上。可以说从功能上讲，SSL VPN是企业远程安全接入的最佳选择

• SSL（Secure Socket Layer）安全套接层是一种运行在两台机器之间的安全通道协议；也可以运 行在SSL代理和PC之间
• 功能：保护传输数据（加密），识别通信机器（认证）
• SSL提供的安全通道是透明的，几乎所有基于TCP的协议稍加改动就可以直接运行于SSL之上
• 目前，IETF将SSL作了标准化，推出TLS传输层安全协议（RFC 2246）整合取代，它工作在TCP之上 。TLS1.0与SSL3.0的差别非常微小

• 握手协议：
  • 对服务器进行认证
  • 确立用于保护数据传输的加密密钥
• 记录协议
  • 传输数据
• 告警协议
• SSL连接分为两个阶段，即握手和数据传输阶段；传输任何应用数据之前必须先完成握手

功能

• 保护传输数据的私密性，对数据进行加密和解密
• 验证传输数据的完整性，计算报文的摘要
• 提高传输数据的效率，对报文进行压缩
• 保证数据传输的可靠和有序

工作流程

• 警告协议用于提示何时TLS协议发生了错误，或者两个主机之间的会话何时终止。
• 只有在TLS协议失效时告警协议才会被激活

在企业的防火墙后面放置一个TLS代理服务器

用户欲安全地连接到公司网络

• 首先要在浏览器上输入一个URL(Universal Resource Locator)
• 该连接请求将被TLS代理服务器取得
• 用户通过身份验证
• TLS代理服务器提供用户与各种不同应用服务器之间的连接

基于Web代理的SSL VPN

• 无须安装任何客户端，真正的跨平台方案
• 仅支持基于Web方式的访问
• 非Web应用需要进行应用转换，将基于C/S的Email 、FTP、SSH等应用以Web的形式重新实现，实现起来复杂
• 对于Web页面中的链接，需要进行URL替换
• 优点：可以用于任何客户端，兼容各种平台访问，智能终端能无缝支持
• 缺点：支持的应用少，需要为新的应用进行Web转化
• 内网服务器链接： https://sslvpnip/http/serverip/path/xx.html
  • 需要将该页面中的所有的链接全部替换为类似的链接，包括静态链接、动态链接等
• 存在问题：
  • 性能影响较大
  • 由于Web技术繁多，替换不完全

基于端口转发的SSL VPN

• 对于FTP、EMAIL、OA、TELNET、远程桌面、数据库等用户经常使用的C/S应用，如果采用Web应用转换，对每一种应用单独处理，工作量很大；此外，也改变了用户的使用习惯，不为用户所接受

• 对于这些应用，采用端口转发技术，客户端需要运行一个较小的ActiveX插件或Java applet程序，在本地端口监听；访问企业内网的应用数据发送到该监听端口，该程序将收到的数据通过浏览器的SSL连接传输到网关，网关再转发给内网服务器。

• 支持多种TCP应用

• 端口转发原理

基于隧道的SSL VPN

• 采用跟IPSecVPN类似的技术，需要安装客户端软件，以及虚拟网卡
• 到内网服务器的IP报文（虚拟IP→内网服务器）会被客户端软件进行SSL协议封装（真实IP→SSL VPN网关地址），到对端的SSLVPN网关设备再解密解封装，还原为原始IP报文，交给内网服务器
• 能支持基于TCP、UDP、ICMP协议的各种应用
• 因工作在套接字层，无IPSecVPN的NAT穿越问题
• 缺点：平台兼容性不够好
• 开源代码：OpenVPN

优点

• 无须安装客户端软件
• 适用于大多数设备
• 适用于大多数操作系统
• 不需要对网络做改变
• 支持网络驱动器访问
• 较强的资源控制能力
• 可绕过防火墙进行访问
• 费用低且有良好安全性
• 已内嵌在浏览器中

缺点

• 认证方式单一
• 应用的局限性很大
• 只对应用通道加密
• 不能对消息进行签名
• 加密级别通常不高
• LAN连接缺少解决方案
• 不能保护UDP通道安全
• 不能访问控制
• 是应用层加密，性能差
• 需CA支持

• 在客户与TLS VPN的通信中，人们常采用TLS Proxy技术来提高VPN服务器的通信性能和安全身份验证能力
• 主要用于访问内部网中的一些基于Web的应用