目录

网络安全基础

加密,保障信息内容安全;认证,确保信息的来源可靠。

互联网的出现拉近了整个世界的距离,它的魔力就在于可以将芸芸众生都收罗在其控制范围内。正所谓有人的地方就一定有恶,网络面临着各种各样的威胁。而网络由于其巨大的影响力,一旦遭受破坏波及范围难以估量,因此网络安全便显得尤为重要。

网络面临的威胁

计算机网络是不可靠的,一来网络的稳定性受制于网络提供商及对应的硬件设备;二来就是来自人为的恶意干预。前者往往是难以预测和防范的小概率事件,而后者通过精妙的网络安全技术几乎可以完全规避掉。计算机网络所面临的恶意威胁主要分为被动攻击主动攻击两大类:

被动攻击

攻击者观察和分析数据单元而不干扰正常的网络通信。

  • 截获:攻击者从网上窃听他人的通信内容。

主动攻击

攻击者对某个连接中的数据协议单元进行处理,采取行动扰乱原本的网络通信。

  • 中断:攻击者有意中断他人在网络上的通信,比如DDos。
  • 篡改:攻击者故意篡改网络上传送的报文。
  • 伪造:攻击者伪造信息在网络上传送。

这些攻击大多数并不像网络断线或者波动那样能让我们有所感知,而是在无形中破坏/泄露我们的通信。面临这些威胁,我们必须采取措施保证网络安全。

加密

从上面的威胁类型来看,当务之急是如何保证我们的消息不被他人获知?百分百的不泄露信息要么是不产生任何信息,要么是与世隔绝,所以根本无法做出这个保证。但当我们换个思路:如何保证我们有用的消息不被他人获知?转机便出现了:加密技术保护我们有用的信息不被他人获取。

无加密时代

在那个计算机网络还没有出现,人类还比较纯粹的时代,语言和文字成为了人们通信的主要手段,消息的传递也都是基于明文。这时,我们对于加密的需求不强,因为本身消息传播途径比较少,如果真的需要传递一些秘密,只要通过人来实现就可以。随着时代的进步,消息安全的重要性额外地凸显出来。最显著的场景是在战争年代的战略消息的传递,上面提到的各种类型的威胁在这个时代都有所体现。

  • 截获:投信的使臣投宿客栈时,信报被细作偷看,但没有改变信报上的内容。
  • 中断:投信的使臣被细作射杀了。
  • 篡改:投信的使臣叛变了,改了信报的内容。
  • 伪造:有人假扮投信的使臣传递信报。

通过在信报上做手脚,往往可以不折一兵一卒损敌方千军万马,因此消息的保密在人类文明伊始就意义重大。

对称加密

最早的加密技术应当算是凯撒加密了,其核心思想就是简单的替换:将明文中所有字母在字母表上向前或向后偏移固定数目后形成了密文。对于外人而言,其看到的密文是一堆不相关的字符串,无法破解其要表达的信息。而对于消息接收者而言,他清楚加密的策略,也清楚对应解密方法。因此可以通过对应的逆偏移解码出明文,获取有用的消息。

这就是对称加密的雏形,即加密解密双方有一个公共的规则(相同的密钥),发送发方通过此规则(密钥)进行编码(加密),接收方通过此规则(密钥)进行解码(解密),信息在传输过程中是以明文经加密后产生的密文传递。

消息在网络中进行传递就要求加密算法是需要公开的,因为我们无法在通信的最开始私下里统一加密方案,也不会绞尽脑汁去创造新的加密算法。因为我们的通信对象太多了,也都远在天边,即便我们可以创造各式各样的加密算法,也无法安全地与对方分享我们的算法。所以现代的加密算法是公开的、标准化的,我们通信的时候只需要声明我们使用的算法即可,对加密的安全性保证仅在于我们为加密算法提供的特殊标识(密钥)。比如凯撒算法是公开的,但偏移量作为特殊标识是通信双方约定好的。也正是因为此标识的多样性,才能保证我们的消息不易被破解。

对称加密的好处就是简单,计算速度快,开销小。而问题也显而易见,我们的密钥需要通信双方共享,但是密钥没有办法安全地传递。一旦密钥泄露出去,密文的传递跟明文的传递别无二致。

破解难易度
对于凯撒算法而言,密钥很容易通过穷举法破解出来,毕竟字母偏移量只有25种可能,因此极易被破解。但成熟的加密算法要求密钥足够长,当然这并不意味着密钥不会被破解,只是说破解难度十分巨大,可以认为是在计算上(而不是在理论上)不可破解,或者更直白的说破解密钥的成本要比消息本身的价值高很多。这侧面说明了在对称加密中,与密钥泄露相比,密钥被破解的可能性可以完全忽略不计。

目前常用的对称加密算法是DES,3DES,AES等。 下图是一个简单的DES示例

/posts/certification/des.png
对称加密算法示意

非对称加密

对称加密致命缺陷就是无法保证密钥安全传递,因此基于公钥密码体制的非对称加密走上了舞台。顾名思义,非对称加密指的是加密密钥与解密密钥是不同的。其中加密密钥又称公钥,是向公众公开的;而解密密钥又称私钥,是对外保密的。由于公钥本身是公开的,因此无需保证其安全传递。即便被第三方截获,其也无法破解加密后的密文,因为只有对应的私钥才能将密文解密。在公钥密码体制中,最著名的是基于大数分解问题的RSA体制。

加密与解密
经常有个误区会认为公钥是用来加密的,私钥是用来解密的,但实际上二者并无相关性。公钥与私钥是通过某种算法算出的一对密码串,使用一方进行编码,便可以通过另一方进行解码。唯一的原则是公钥是公开的,私钥是保密的,我们会为不同用途选择不同的角色进行编解码。比如信息加密我们会采用公钥编码,私钥解码;数字签名会采用私钥编码,公钥解码。

那么有了安全性如此之高的非对称加密,对称加密是不是就可以退出历史舞台了呢?并不是的,因为非对称加密有个致命的确定:开销大,性能差,而且开销是与明文的长度正相关的。在海量数据通信的时代,这显然会降低信息传递效率,因此TLS的最佳实践是通过非对称加密传递对称加密密钥,具体的信息加密仍然采用对称加密

非对称加密的另一个应用场景是数字签名,数字签名是通过私钥加密,并通过公钥解密。其作用类似于写在纸上的签名,申明其所传递的内容无误。签名只能有发信者完成,而所有人均可通过其公钥对其进行验签。有了数字签名后,其他人无法篡改或伪造信息的内容,因为他们没有也无法破解发信者的私钥,所以无法对篡改后/伪造的内容进行签名。

原始信息的大小直接影响到签名的性能,通常我们需要对原始信息进行hash获取摘要,并对摘要进行签名。这要求hash算法是不可逆转的,即无法根据摘要推算出私钥。同时,好的hash算法能保证不同的信息输出的结果也都不相同,即在计算上同一结果只能对应一种原始信息。目前比较流行的hash算法是md5,其将原始信息散列成固定128位的结果。

/posts/certification/digital-sign.png
数字签名示意

有了非对称加密,信息的传递就绝对安全了吗?也不是,上述过程中最大的问题仍旧是…公钥的传递。不对呀,之前不是说了公钥是公开的吗,为什么公钥的传递还会引发安全性呢?问题的本质不在于传递公钥内容的安全性,而在于公钥的所有者是谁。换句话说,小明要和小丽通信,小明如何知道传递过来的公钥是小丽的呢?如果小丽传递过来的公钥被小三拦截,并且将小三的公钥传递给了小明,那小明原本要发给小丽的情话不就被小三拦截并破译了?小三便可以窃听或者篡改小明与小丽的通信。这就是所谓的中间人攻击

/posts/certification/median-attack.png
中间人攻击示例

那么如何避免中间人攻击呢?这就需要引出第三方认证了,即通过权威机构证明这个公钥是小丽的。

认证

认证通俗来讲,就是通过一个第三方来验明某个人的身份,从而确认公钥就是这个人的,以避免中间人攻击。在流程上,一般是一方带着自己的身份信息向第三方机构去申请一个证书,第三方机构颁发一个带有自己签名的证书,该方将证书发送给对端进行验证。我们着重介绍一下数字证书颁发机构这两个概念。

数字证书

数字证书指在互联网通讯中标识通讯各方身份信息的一个数字认证,人们可以在网上用它来识别对方的身份。一般而言,证书需要包含如下内容:

  • 持有者身份信息
  • 证书颁发者信息
  • 持有者的公钥
  • 认证机构的数字签名

认证机构验证持有者的身份(CSR)无误后,便向其发布一个带其签名的证书,以此来标识此证书中的公钥是可信的。

在TLS中,通常使用x509证书,下例演示了minikube为kube-apiserver生成的服务端证书,我们根据这个证书看一下证书的机构。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
Certificate:
    Data:
        Version: 3 (0x2)                         # x509证书版本号
        Serial Number: 2 (0x2)                   # 序列号,每个证书唯一,用以与其他证书区分开
    Signature Algorithm: sha256WithRSAEncryption # 签名使用的算法
        Issuer: CN=minikubeCA                    # 颁发机构名称
        Validity                                 # 证书有效期(不早于...不晚于...)
            Not Before: Jul  9 02:57:51 2021 GMT
            Not After : Jul 10 02:57:51 2022 GMT
        Subject: O=system:masters, CN=minikube   # 持有者的名字
        Subject Public Key Info:                 # 持有者的公钥信息
            Public Key Algorithm: rsaEncryption
                Public-Key: (2048 bit)
                Modulus:
                    00:b6:e3:24:20:ce:84:11:21:e5:a4:ee:fd:11:75:
                    51:94:1e:bb:c6:18:3c:fa:e3:1f:16:d2:18:4d:98:
                    e2:44:30:b4:aa:c4:7a:de:8a:f4:ec:c5:e9:a6:0b:
                    ac:12:b2:03:e9:ca:16:f4:69:f7:08:bb:1c:0d:af:
                    58:9a:51:39:30:cf:bc:0f:60:97:a9:a4:0a:f8:37:
                    65:dd:b9:21:1f:da:0b:79:19:1d:6b:96:ff:98:57:
                    36:3b:a3:e3:34:98:0d:70:92:5f:6f:0f:e8:a2:3b:
                    88:d5:4c:3d:fb:e0:75:48:af:5e:e5:16:a8:50:d6:
                    92:ef:be:d5:23:91:e1:c9:d5:9c:e6:ff:49:e7:ca:
                    fb:ab:c7:72:0d:90:23:dc:0a:59:cf:8f:e4:f6:6a:
                    fe:73:c0:8d:bb:23:8c:a8:0f:e7:90:61:e1:66:b1:
                    ac:4d:96:23:c8:0b:43:25:a2:8a:4f:d5:ff:2d:57:
                    8c:fb:16:d2:69:a0:80:d1:f9:f2:e1:a3:0a:40:7a:
                    56:1b:3c:69:36:73:dd:b5:f6:9e:75:d4:91:5c:58:
                    b4:e8:f7:a2:2f:1e:0c:4b:2d:d6:1e:6d:92:6f:d3:
                    07:85:a6:9f:7c:20:0c:7c:e8:3c:0f:6b:c8:74:a4:
                    8b:c6:d3:10:af:a7:dd:dc:90:ae:bc:f6:b7:b0:e1:
                    1b:bb
                Exponent: 65537 (0x10001)
        X509v3 extensions:                      # 一堆x509扩展,后面会挑一些重要的说明
            X509v3 Key Usage: critical
                Digital Signature, Key Encipherment
            X509v3 Extended Key Usage:
                TLS Web Server Authentication, TLS Web Client Authentication
            X509v3 Basic Constraints: critical
                CA:FALSE
            X509v3 Subject Alternative Name:
                DNS:minikubeCA, DNS:control-plane.minikube.internal, DNS:kubernetes.default.svc.cluster.local, DNS:kubernetes.default.svc, DNS:kubernetes.default, DNS:kubernetes, DNS:localhost, IP Address:10.122.101.148, IP Address:172.17.0.40, IP Address:10.96.0.1, IP Address:127.0.0.1, IP Address:10.0.0.1
    Signature Algorithm: sha256WithRSAEncryption                  # 签名信息
         97:e6:66:a9:a4:fb:42:93:59:c2:2e:ea:77:9a:bf:46:99:11:
         72:f6:e1:f7:ce:22:9b:35:7d:37:03:d6:ea:8d:c0:9a:9e:0b:
         5c:70:93:e5:5c:e2:c8:43:df:e6:ee:ff:ba:90:8d:de:1f:e5:
         4e:ee:72:a7:bc:9e:7a:a9:7f:58:2e:7e:6f:aa:91:60:02:c5:
         51:71:1a:e0:80:8b:3d:08:34:a9:65:47:7a:89:7d:31:6d:1a:
         1f:0f:0b:17:88:48:eb:e5:20:94:56:52:9a:e0:30:88:fb:cc:
         62:12:ea:86:45:e2:a8:59:cd:d0:b1:d6:7b:a9:37:fa:24:b6:
         34:d4:4d:aa:cd:28:2c:e2:57:90:6a:11:4f:c0:01:68:49:ef:
         bd:54:68:7f:f8:2e:99:ba:d0:b1:01:c2:eb:7e:5a:ff:f9:dd:
         6c:1b:43:b4:3b:10:fc:46:ef:5b:63:05:27:12:74:6d:2c:ec:
         af:d6:66:2a:eb:45:ee:d9:d9:bd:73:2d:38:bd:bc:b5:38:7c:
         90:9b:f0:11:ee:0a:93:1d:63:25:89:e6:c3:59:3c:7b:4a:4d:
         53:d3:a1:a6:3e:82:64:f1:04:02:2c:ce:b9:68:5b:fc:1d:40:
         c8:8f:9a:ce:04:9d:5a:c9:6c:94:8e:43:f5:e4:78:00:82:bb:
         f4:5c:5b:d7

x509证书定义了一系列扩展,用于对证书进行约束及限制,常用的扩展列举如下:

扩展名用途是否为critical示例
X509v3 Basic Constraints描述该证书是否属于CA,具有签署证书的能力YCA=false:此证书不是CA证书,不可签署其他证书
X509v3 Key Usage限定了证书的用途YDigital Signature, Key Encipherment表示可以用于数字签名及密钥加密
X509v3 Extended Key Usage限定了证书的用途NTLS Web Server Authentication, TLS Web Client Authentication表示可以用于服务端及客户端认证
X509v3 CRL Distribution Points提供了CRL地址列表FURI:http://crl.starfieldtech.com/sfs3-20.crl
Authority Information Access提供OSCP地址;CA签发者的连接(用于获取中间证书)FOCSP - URI:http://ocsp.int-x3.letsencrypt.org CA Issuers - URI:http://cert.int-x3.letsencrypt.org/
X509v3 Subject Key Identifier持有者的唯一标识F
Authority Key Identifier颁发者的标识F与颁发者的X509v3 Subject Key Identifier相等
X509v3 Subject Alternative Name(SAN)列出证书所有的合法域名,如果其不存在就回退到Common Name寻找FDNS:localhost, IP Address:10.122.101.148 表示证书来源的dns为localhost或者Ip为10.122.100.148的是合法的,其他均不可信

结合以上扩展可以列举出证书验证的失败的几个原因:

  • 证书过期了
  • 证书由不可信CA颁布
  • 证书被吊销了
  • 证书来源不在其SAN中
critical作用
有些扩展带有critical标识,其意义为所有的证书验证方必须理解它的含义,否则认定为认证失败。简单理解就是这些扩展要求必须能够被识别。

颁发机构(CA)

为避免中间人攻击,证书必须由第三方权威机构认证才可信,这里的权威机构就是CA。上面描述的数字证书就是申请者发送证书签署请求(CSR)给CA,由CA认证后用其私钥进行签名形成证书。可见CA的信誉直接影响着证书的可信度。

那么CA又是怎么保证其是可信的呢?答案是通过更权威的CA进行认证,那么这个更权威的CA怎么保证是可信的呢?那就要找更更权威的CA认证……现实情况下,这种情况对应着证书链认证,即认证是一级一级向上传递的。当然为了避免证书无休止的验证下去,是需要有一个最终信任源的,这个信任源又称为根证书

按下葫芦浮起瓢,CA的认证大致明确了,但是它又引入了两个问题:

  • 根证书是如何终止链式验证过程的?如何成为信任源的?如果私钥泄露怎么办?如果过期怎么办?
  • 为什么需要证书链,直接使用根证书进行用户证书的认证会有什么问题?

上述两个问题并非是割裂的,而是息息相关的。

根证书作为可信任的源头,其使用自己的私钥来签署自己的证书(这类证书又叫做自签名证书,其特点是Issuer与Subject信息一致),验证方只要持有该根证书的公钥便可对此根证书进行验证。而这些具有权威性的CA根证书会内置在浏览器及操作系统中,这样便可以对此类根证书进行验证。如果我们想信任某个第三方证书,那么只需要将其加入到浏览器/操作系统的证书信任列表中即可。

根证书的有效期一般会比较长,如果根证书过期了,那么只能由该机构重新签发。而在临期时,便会借着操作系统/浏览器的更新而将新证书植入进去。另一方面,现在很多证书都采用了交叉认证,即使某个根证书过期了,也能确保其他链条上的认证成功。如果根证书的私钥泄露了,那么它就可以被用于发布非法证书,作为互联网的信任根源之一,带来的影响会是灾难性的。因此为了避免根证书私钥的安全,需要做到以下保证:

  • 私钥在计算上须是不可破解的,因为根证书有效期较长,如果私钥长度过短的话很有可能在有效期内被破解,因此需要是在计算上不可破解的。当前的x509证书可以保证这一点。
  • 用户证书不直接通过根证书签名颁发,而是通过中间证书颁发,建立起中间证书链进行认证。

我们着重来说一下第二点,试想一下如果每个证书都需要根证书颁发的话,会不会增大私钥泄露的风险呢?从统计学角度看,如果签署的证书过多,其规律性信息量也会暴露越多,无论是泄露还是被破解的概率都会增大。因此通过追加一层中间证书来解决此问题,即中间证书颁发用户证书,根证书颁发中间证书。这样便构成了完整的证书链体系,从而减小根证书密钥泄露的风险。通常来讲,为了严格控制根证书私钥的安全性,其所在的机器通常是离线的,只有在需要签署/吊销中间证书时才会联网,将暴露的风险降到最低。

中间证书的特点
中间证书不应是自签名的,即Issuer与Subject是不同的,其携带上一级证书的DN (Distinguished Name),可以通过DN来找到上一级证书。此外中间证书是可以签发下级证书的,即X509v3 Basic Constraints扩展字段需设置为CA=true。最后中间证书的有效期一般比根证书的短很多,如果中间证书因私钥泄露等问题需要被吊销(可以通过CRL或者OCSP来查询证书是否被吊销)时,影响范围会小很多。
/posts/certification/cert-chain.png
证书链示意图

总结一下链式证书发布及验证过程:

发布方

  • 权威CA生成自签名根证书,并将根证书置于操作系统/浏览器中
  • 权威CA使用根证书私钥签名中间证书
  • CA使用中间证书采用其私钥签名用户证书
  • 用户使用其私钥签名数据摘要

验证方

  • 采用中间证书验证用户证书
  • 如果有多层中间证书,则使用上一级中间证书验证当前中间证书
  • 通过内置的根证书验证中间证书
  • 通过用户证书中的公钥对数据摘要进行验签

最后一个问题是在对用户证书进行验证时,如何获取中间证书呢?在SSL握手的过程中,是允许在将客户端/服务器证书发送后紧着着将中间证书发送出去的。但这并不是必须的,还有一些其他的方式获取中间证书,比如上述提到过的Authority Information Access扩展中可能会有颁发者的获取地址等。

总结

本文介绍了网络安全面临哪些威胁,使用数据加密技术可以做到有效规避部分威胁。接着详细介绍了对称加密及非对称加密的特点。单方面的加密技术无法抵御中间人攻击,因此需要第三方认证以验明通信双方的身份。最后介绍了认证中的一些重要概念,如数字签名、数字证书、颁发机构等,并将这些概念在认证的流程中发挥的作用串联起来。此外,文章穿插着对TLS的认证及加密流程的介绍。

网络安全远不止于此,加密与认证仅仅是保证了最基本的通信安全,而网络安全还涵盖很多的方面,诸如人为因素,准入机制,角色权限控制等。对加密/认证的概念有了初步的认识,后续会逐步深入地研究kubernetes中的认证、鉴权、准入的安全管理机制。

参考文献

  1. 数字证书原理
  2. openssl x509证书
  3. Wikipedia
  4. openssl cookbook