标签 IPSEC 下的文章

嗨!和去年一样,今年我又参加了 netdev 会议。(这里是我上一年所做的笔记)。

在今天的会议中,我学到了很多有关 IPsec 的知识,所以下面我将介绍它们!其中 Sowmini Varadhan 和 Paul Wouters 做了一场关于 IPsec 的专题研讨会。本文中的错误 100% 都是我的错 :)。

什么是 IPsec?

IPsec 是一个用来加密 IP 包的协议。某些 VPN 已经是通过使用 IPsec 来实现的。直到今天我才真正意识到 VPN 使用了不只一种协议,原来我以为 VPN 只是一个通用术语,指的是“你的数据包将被加密,然后通过另一台服务器去发送“。VPN 可以使用一系列不同的协议(OpenVPN、PPTP、SSTP、IPsec 等)以不同的方式来实现。

为什么 IPsec 和其他的 VPN 协议如此不同呢?(或者说,为什么在本次 netdev 会议会有 IPsec 的教程,而不是其他的协议呢?)我的理解是有 2 点使得它如此不同:

  • 它是一个 IETF 标准,例如可以在文档 RFC 6071 等中查到(你知道 IETF 是制定 RFC 标准的组织吗?我也是直到今天才知道的!)。
  • 它在 Linux 内核中被实现了(所以这才是为什么本次 netdev 会议中有关于它的教程,因为 netdev 是一个跟 Linux 内核网络有关的会议 :))。

IPsec 是如何工作的?

假如说你的笔记本正使用 IPsec 来加密数据包并通过另一台设备来发送它们,那这是怎么工作的呢?对于 IPsec 来说,它有 2 个部分:一个是用户空间部分,另一个是内核空间部分。

IPsec 的用户空间部分负责密钥的交换,使用名为 IKE 网络密钥传输 internet key exchange )的协议。总的来说,当你打开一个 VPN 连接的时候,你需要与 VPN 服务器通信,并且和它协商使用一个密钥来进行加密。

IPsec 的内核部分负责数据包的实际加密工作 —— 一旦使用 IKE 生成了一个密钥,IPsec 的用户空间部分便会告诉内核使用哪个密钥来进行加密。然后内核便会使用该密钥来加密数据包!

安全策略以及安全关联

(LCTT 译注:security association 我翻译为安全关联, 参考自 https://zh.wikipedia.org/wiki/%E5%AE%89%E5%85%A8%E9%97%9C%E8%81%AF

IPSec 的内核部分有两个数据库:安全策略数据库(SPD)和安全关联数据库(SAD)。

安全策略数据库包含 IP 范围和用于该范围的数据包需要执行的操作(对其执行 IPsec、丢弃数据包、让数据包通过)。对于这点我有点迷糊,因为针对不同 IP 范围的数据包所采取的规则已经在路由表(sudo ip route list)中使用过,但显然你也可以设定 IPsec 规则,但它们位于不同的地方!

而在我眼中,安全关联数据库存放有用于各种不同 IP 的加密密钥。

查看这些数据库的方式却是非常不直观的,需要使用一个名为 ip xfrm 的命令,至于 xfrm 是什么意思呢?我也不知道!

(LCTT 译注:我在 https://www.allacronyms.com/XFMR/Transformer 上查到 xfmr 是 Transformer 的简写,又根据 man7 上的简介, 我认为这个说法可信。)

# security policy database
$ sudo ip xfrm policy
$ sudo ip x p

# security association database
$ sudo ip xfrm state
$ sudo ip x s

为什么 IPsec 被实现在 Linux 内核中而 TLS 没有?

对于 TLS 和 IPsec 来说,当打开一个连接时,它们都需要做密钥交换(使用 Diffie-Hellman 或者其他算法)。基于某些可能很明显但我现在还没有理解(??)的原因,在内核中人们并不想做密钥的交换。

IPsec 更容易在内核实现的原因是使用 IPsec 你可以更少频率地协商密钥的交换(对于每个你想通过 VPN 来连接的 IP 只需要一次),并且 IPsec 会话存活得更长。所以对于用户空间来说,使用 IPsec 来做密钥交换、密钥的获取和将密钥传递给内核将更容易,内核得到密钥后将使用该密钥来处理每个 IP 数据包。

而对于 TLS 来说,则存在一些问题:

a. 当你每打开一个 TLS 连接时,每次你都要做新的密钥交换,并且 TLS 连接存活时间较短。 b. 当你需要开始做加密时,使用 IPsec 没有一个自然的协议边界,你只需要加密给定 IP 范围内的每个 IP 包即可,但如果使用 TLS,你需要查看 TCP 流,辨别 TCP 包是否是一个数据包,然后决定是否加密它。

实际上有一个补丁用于 在 Linux 内核中实现 TLS,它让用户空间做密钥交换,然后传给内核密钥,所以很明显,使用 TLS 不是不可能的,但它是一个新事物,并且我认为相比使用 IPsec,使用 TLS 更加复杂。

使用什么软件来实现 IPsec 呢?

据我所知有 Libreswan 和 Strongswan 两个软件。今天的教程关注的是 libreswan。

有些让人迷糊的是,尽管 Libreswan 和 Strongswan 是不同的程序包,但它们都会安装一个名为 ipsec 的二进制文件来管理 IPsec 连接,并且这两个 ipsec 二进制文件并不是相同的程序(尽管它们担任同样的角色)。

在上面的“IPsec 如何工作”部分,我已经描述了 Strongswan 和 Libreswan 做了什么 —— 使用 IKE 做密钥交换,并告诉内核有关如何使用密钥来做加密。

VPN 不是只能使用 IPsec 来实现!

在本文的开头我说“IPsec 是一个 VPN 协议”,这是对的,但你并不必须使用 IPsec 来实现 VPN!实际上有两种方式来使用 IPsec:

  1. “传输模式”,其中 IP 表头没有改变,只有 IP 数据包的内容被加密。这种模式有点类似于使用 TLS —— 你直接告诉服务器你正在通信(而不是通过一个 VPN 服务器或其他设备),只有 IP 包里的内容被加密。
  2. ”隧道模式“,其中 IP 表头和它的内容都被加密了,并且被封装进另一个 UDP 包内。这个模式被 VPN 所使用 —— 你获取你正传送给一个秘密网站的包,然后加密它,并将它送给你的 VPN 服务器,然后 VPN 服务器再传送给你。

投机的 IPsec

今天我学到了 IPsec “传输模式”的一个有趣应用,它叫做 “投机的 IPsec”(通过它,你可以通过开启一个 IPsec 连接来直接和你要通信的主机连接,而不是通过其他的中介服务器),现在已经有一个“投机的 IPsec” 服务器了,它位于 http://oe.libreswan.org/

我认为当你在你的电脑上设定好 libreswanunbound DNS 程序后,当你连接到 http://oe.libreswan.org 时,主要发生了如下的几件事:

  1. unbound 做一次 DNS 查询来获取 oe.libreswan.org (dig ipseckey oe.libreswan.org) 的 IPSECKEY 记录,以便获取到公钥来用于该网站(这需要 DNSSEC 是安全的,并且当我获得足够多这方面的知识后,我将用另一篇文章来说明它。假如你想看到相关的结果,并且如果你只是使用 dig 命令来运行此次 DNS 查询的话,它也可以工作)。
  2. unbound 将公钥传给 libreswan 程序,然后 libreswan 使用它来和运行在 oe.libreswan.org 网站上的 IKE 服务器做一次密钥交换。
  3. libreswan 完成了密钥交换,将加密密钥传给内核并告诉内核当和 oe.libreswan.org 做通信时使用该密钥。
  4. 你的连接现在被加密了!即便它是 HTTP 连接!有趣吧!

IPsec 和 TLS 相互借鉴

在今天的教程中听到一个有趣的花絮是 IPsec 和 TLS 协议实际上总是从对方学习 —— 正如他们说在 TLS 出现前, IPsec 的 IKE 协议有着完美的正向加密,而 IPsec 也从 TLS 那里学了很多。很高兴能听到不同的网络协议之间是如何从对方那里学习并与时俱进的事实!

IPsec 是有趣的!

我已经花了很长时间来学习 TLS,很明显它是一个超级重要的网络协议(让我们来加密网络吧!:D)。但 IPsec 也是一个很重要的网络加密协议,它与 TLS 有着不同的角色!很明显有些移动电话协议(例如 5G/LTE)使用 IPsec 来加密它们的网络流量!

现在我很高兴我知道更多关于 IPsec 的知识!和以前一样可能本文有些错误,但希望不会错的太多 :)


via: https://jvns.ca/blog/2018/07/11/netdev-day-1--ipsec/

作者:Julia Evans 译者:FSSlc 校对:wxy

本文由 LCTT 原创编译,Linux中国 荣誉推出

前不久我写到NSA可能在安全标准中植入后门。今天,我们谈一谈NSA被指责在标准中植入后门的两个案例,然后通过它们来区分两种后门之间的不同。

第一个案例

是关于NIST标准,SP 800-90A,该标准详细说明了一种伪随机数生成器(PseudoRandom Generator 以下简称PRG)。一个RPG可以通过计算得到一小组不可预料的随机比特,并进而“延展”得到大量的随机比特数。在密码学中,PRG作为大多数密钥的源头,是必需的。因此,如果你能“破解”某些人的PRG,你就能预测其使用的密钥,进而击溃其整个加密算法。

NIST标准中提供了一些核心算法供PRG选择。其中一个算法使用了一种叫做椭圆曲线的数学结构,在这里我并不打算展开介绍这个数学概念。总之,这个算法使用了两个“公开参数”P和Q,它们均在标准中有指定的值,因此说它们是公开的。

密码学家相信,如果P和Q是随机的,PRG就是安全的。但是2006年,两个独立密码学家指出,通过某种方法选定P和Q后,它们之间就具有了某种特殊的关系。一个“局外人”可能并不知道这种特殊关系的存在,但是如果你知道了描述P和Q之间关系的“密钥”,就可以轻松击溃PRG的安全体系。

知道了这一点,会发现很多事实突然变得有趣起来。首先,NSA看起来十分执意要将这种算法写入标准,即使它的运行效率很低;其次,NSA在标准中指定了P和Q的建议取值范围;第三,NSA并未解释这些给定的取值范围是如何得出的。怎么样,是不是有点儿意思?

不仅如此,现在已经可以通过一些已公开的步骤,得出新的随机的P和Q,也就是说,以上三种问题都可以得到解决,但是NSA并没有这么做。

值得注意的是,(也许是为了辟谣),前不久(9月10日),NIST重新开放了SP 800-90A的公开评论。

第二个案例

是由John Gilmore提出的,他在IPSEC标准中发现了问题。IPSEC被视为安全技术的一块基石,能够为因特网中的个人IP数据包提供完整可靠的加密。一个成功广泛部署的IPSEC协议可以大大强化因特网安全,为多种网络通信提供加密保护。

John说,NSA及其代理部门始终在降低该标准的安全水平与执行效率,同时却不断提高其复杂程度和安全方面的实现难度。尽管John还没有掌握NSA植入后门的确凿证据,但是他发现,NSA的确在不断削弱该标准的效力,事实上,IPSEC已经没有人们想象中的那样安全可靠。

上述案例向我们展示了两种不同类型的后门。第一个关于PRG的案例中,我们怀疑NSA尝试建立一个只有它能使用的后门,因为只有它知道关联P和Q的密钥。第二个关于IPSEC的案例中,NSA不断削弱用户的安全防护能力,这样它就能更轻易地访问你的数据,但同时其他所有人都具有了这样的机会。

可以确定的是,一个私有后门很可能无法一直“私有”。如果真有这样一个magic密钥,能让NSA窥探所有人的秘密,那这把钥匙很可能会被滥用或泄露到外界。因此,NSA私有后门和公开后门之间的界限并不明显。

但是,看起来这两种后门之间还是引起了不同的政策辩论。前者使得NSA能秘密地轻易访问每个人的数据,后者则赋予了每个人这种访问权限,后者的影响力要更加严重。

同时,我们应该看到一个后门是如何创造出来的。在PRG的案例中,需要获得制定标准的专家们通过,NSA才能使其加密过程中那微小的缺陷“蒙混过关”。在IPSEC的案例中,则貌似需要在标准的整个制定过程中不断协调公关活动才有机会制造那小小的缺陷,在这个过程中,即使没有人发现某种模式,也应该能注意到某些单个步骤,(但是却没有)。

也许有人会怀疑,这些案例真的是NSA有意而为之,还是只是空穴来风。对此,我们并不敢保证。但是只要NSA一直拥有参与制定安全标准的许可权限,我们就有必要,对他们所参与制定的任何标准保持怀疑。


via: https://freedom-to-tinker.com/blog/felten/on-security-backdoors/

本文由 LCTT 原创翻译,Linux中国 荣誉推出

译者:Mr小眼儿 校对:Caroline