谈 DNS 解析工作原理并给自己的域名搭建 DNS 服务器

现在几乎所有的互联网主机都要使用到 DNS (Domain Name Server,域名系统) 。这篇文章就通过搭建自己的 DNS 服务器的方法学习 DNS 知识。

DNS 递归解析的工作原理

DNS 的解析是递归进行的,它的结构就像 Unix 目录结构一样:

DNS 解析结构
DNS 解析是颠倒的树状结构

如何理解?DNS 解析从顶端(Root)开始,向根域名服务器询问第一个区域的DNS(asia.),然后向 asia. 的 DNS 查询 goodspeed.asia. 的 DNS 以此类推。

你可能已经注意到了,这里我的域名后面加了一个“.”。这是完全合格域名(FQDN)的表示方法,用来指向 DNS 树状图中的一个确切位置。在上面的树状图中是这样表示的(设想我们要得是最下面的 ftp 节点):ftp -> openbsd -> org。把箭头用“.”替代再加上一个“.”用来表示根域名就变成了我们要的 FQDN。

现在你已经了解了 DNS 递归解析的基本工作原理,下面是 DNS 请求根服务器、Asia 的 DNS 和我自建的 DNS 的查询结果(留意 SECTION 中使用的 FQDN)。

继续阅读“谈 DNS 解析工作原理并给自己的域名搭建 DNS 服务器”

谈 HTTPS 协议的缺陷与反 HTTPS 联盟的谬误

HTTPS 保护的是什么?

根据维基百科:超文本传输安全协议(英语:HyperText Transfer Protocol Secure,缩写:HTTPS;常称为HTTP over TLSHTTP over SSLHTTP Secure)是一种通过计算机网络进行安全通信的传输协议。HTTPS 经由 HTTP 进行通信,但利用 SSL/TLS 来加密数据包。HTTPS 开发的主要目的,是提供对网站服务器的身份认证,保护交换资料的隐私与完整性。这个协议由网景公司(Netscape)在1994年首次提出,随后扩展到互联网上。

从中不难看出 HTTPS 提供的安全:保护用户到网站的链接不被篡改、保证消息不被窃取。使用明文传输的 HTTP 显然不可能具备这些安全(或者可以说,没有安全可言)。在明确这一点以后,我们就可以讨论下面有关安全的问题。

HTTPS 的缺陷

身份验证机制

使用 SSL/TLS 以后,连接只需要一份客户端认可的证书就可以保证连接的安全性。客户端认可证书的方式,这里就写为身份验证机制了。身份验证机制对安全性的影响是最大的。但客户端如何认可一个证书?下面会提到的两种方式,而它们各自有各自都有缺点。

基于根证书的身份验证(惯例)

根证书验证的工作原理就如同背书一样。(在政治上,背书一词用来表示为某人或某事允诺保证,借此提高事物的可信度)

信任链
根证书在信任链中作为信任锚的起点角色(Yanpas 作,相同方式共享)

证书的验证依靠于上图所示的信任链。最上层是根证书,为它下面的其它证书背书(签发)。然后,其它证书(通常是根证书签发机构 (CA) 的子机构)为其它机构背书。从这个信任链可以看出,这个过程最后的机构是网站本身。

这里会产生的问题可以这样打个比方。一个学校中的校长品行端正,校长确保其他主任也品行端正。其他主任确保他的手下品行端正。这个“信任链”就同基于根证书的信任一样。实际情况是,尽管有这样的信任链也没法保证一个老师品行端正。校长可能有所疏忽,让其他主任中存在品行不端正的(到老师身上同理)。

根证书只能一定程度地保证最终证书的可信度。就我能想到的它不保证最终证书可信度的情况有:泄露(机构泄露了它保证证书的私钥)、错误签发(机构错误地把证书签发给别人)、内鬼。下面列举了 Wikipedia 描述的相关事件:

中国互联网络信息中心发行假证书事件

2009年,中国互联网络信息中心(CNNIC)的一名员工向Mozilla申请要求将 CNNIC 加入 Mozilla 的 根证书列表[27],并且得到了批准。后来微软也把 CNNIC加到了Windows的根证书列表里。

2015年,因CNNIC发行的一个中级CA被发现发行了Google域名的假证书[28],许多用户选择不信任CNNIC颁发的数字证书。并引起对CNNIC滥用证书颁发权力的担忧[29]。

2015年4月2日,Google宣布不再承认CNNIC所颁发的电子证书。4月4日,继Google之后,Mozilla也宣布不再承认CNNIC所颁发的电子证书[32]。2016年8月,CNNIC官方网站已放弃自行发行的根证书,改用由DigiCert颁发的证书。
沃通及StartCom遭封杀事件

2016年,拥有奇虎360背景的中国最大CA证书签发机构沃通(WoSign)及其以色列子公司StartCom,遭谷歌拒绝承认其证书。

沃通被揭发在短短5日内发行了几百个相同序列号的证书,以及对证书日期上造假,甚至签发了一张假的Github证书。

微软也曾在2017年表示会将相关证书下架,但在2021年2月仍有用户表示沃通和StartCom的证书在Windows 10仍然生效,只能手动移除证书[37]。
中国铁路客户服务中心网站自签根证书
参见:中国铁路客户服务中心

中国铁路客户服务中心(简称:12306网站)初期启用https访问时,使用的是由证书机构的名称为“Sinorail Certification Authority”(SRCA)颁发的证书,而该根证书并没有记录在任何公开的根证书记录中,所以会被浏览器出于安全性而阻止访问,12306网站也在网站上要求用户手工添加该根证书,由于证书缺少证书吊销列表等问题,同样地也引发对该根证书对用户隐私安全的隐忧,或者和CNNIC根证书一样抱以不信任处理。用户在支付票款时所使用的站点(即pay.12306.cn)是使用由Verisign签发的有效证书。在2017年12月12日开始,主站点陆续开始更换为由DigiCert签发的证书,直至现在,全站已更换为DigiCert签发的证书。 

那么,浏览器的验证机制如何呢?浏览器验证网站发回的证书链,确保它们之间的联系正确然后在根证书池中查询对应根证书从而验证。所以,要保护通讯安全,需要一个可靠的根证书池。只要这个根证书池中移除了不可靠机构的证书,就可以很大程度上减少风险。

不少人都在维护他们自己的根证书池,比如 Mozilla 的(ca-certificates-mozilla)、Google 的、CAcert.org 的(ca-certificates-cacert) 等等。(在网络安全大会上听说 360 也有自己的根证书计划)

首次使用信任(Trust On First Use)

工作原理非常简单,客户端会记录第一次通讯时使用的证书,此后(未过期前)只信任首次信任的证书。

问题也很明显,中间人只需要在首次连接时篡改证书即可。

现在几乎所有的浏览器都使用基于根证书的身份验证方式。其缺陷在上面已经提过。

额外开销

加密传输固然会造成额外的开销,但这个开销非常小。下面从 www.keycdn.com 摘抄一份关于 HTTPS 开销的研究(Analyzing HTTPS Performance Overhead
By Brian Jackson)总结:

我们没有看到来自 HTTPS 的太多延迟,实际上一些测试更快! 因此,SSL 性能影响不再像以前那么重要。 网络肯定在朝着新的方向发展,TLS 握手和证书不再让我们慢下来。 正如我们上面提到的,有很多方法可以进一步提高您的 HTTPS 性能并减少您的开销。 当然,我们始终建议您自行测试,因为不同的设置和环境可能会有所不同。 HTTPS 就在这里,它会一直存在。 Scott Helme 在过去 6 个月中看到前 100 万个网站的 HTTPS 使用量增长了 42%。

反 HTTPS 联盟的谬误

你可能没有听说过反 HTTPS 联盟,这是它们的网站链接:http://auiou.com/。下面我会采用逐句批驳的方法阐述反 HTTPS 联盟的谬误。

SSL 证书没有权威

在文章《反https联盟(公益)建立的想法前夕:反垄断》 中提到 SSL 证书没有权威。这里他说的很含糊,我理解为网站所使用的证书没有权威性。他把其原因解释为:“SSL 本质上就是给钱就认证。SSL证书如果被一家运营商吊销,则可以换一家认证,所以,SSL证书没有权威”。实际上,负责任的 CA 并非给钱就认证,它们通常会使用 DNS 验证或网站验证的办法确认合法性。再次,最终决定信任与否的是根证书池,可靠的根证书池会移除那些不负责任的 CA,从而保证权威性。他的这个理由显然不可能成立。

另外,就现存的身份验证机制来说,两种方法都提供不了 100% 权威性。如果你想要那样的权威性,只能面对面让他说出来证书的指纹。(这样意义不大,因为现存的机制的权威性已经很高了)

SSL证书收费必定会成为主流

在文章《反https联盟(公益)建立的想法前夕:反垄断》 中提到 SSL 证书收费必定成为主流。这个不论从现实还是他的论证上来说都是错误的。

以Let’s Encrypt的变化为例,在2021年9月做了调整,所有的证书都会在9月30日到期。从2021年9月底之后,Let’s Encrypt的站点dl.eff.org,已经不再提供安装命令。如果之前保存他的安装命令certbot-auto的(这个SSH)文件,运行之后,也无法安装。

这个所谓的调整是因为 Let’s Encrypt 的根证书到期了。随后 Let’s Encrypt 有了新的根证书。dl.eff.org 是原先 Let’s Encrypt 在电子前哨基金会的地址。这个地址现在被迁移到了 certbot.eff.org。至于无法安装之类的,任何软件/系统更新时都可能出现这样的问题,这说明不了什么。

对于Let’s Encrypt的免费SSL,现在在火狐浏览器高版本102.0.1下,显示正常的绿锁;而Chrome 103.0.5060.134,对于Let’s Encrypt的免费SSL,则显示红色的“不安全”

这一变化,说明SSL证书收费将来必定会成为主流。

因为 Let’s Encrypt 的根证书到期而导致显示“不安全”,更体现了浏览器在确保证书权威性与连接安全性上的努力。这一变化说明不了任何事,另外,现在你就在使用 Let’s Encrypt 的证书和我的博客通讯。

根据,Let’s Encrypt 的统计(https://letsencrypt.org/stats/),截至发文:正在生效的证书有八千万,火狐浏览器最近加载(14 天内)的网站中有 82% 使用 Let’s Encrypt 签发免费证书。除此以外,还有其它的机构会签发 SSL 证书,例如 ZeroSSL。从此可以看出,免费 SSL 证书正在广泛地普及开,使用人数越来越多。这和 SSL 证书收费将来必定成为主流的观点戛然不同。

https是超大规模的互联网垄断

作者没有论证这个,我不同意这个观点。例如,Let’s Encrypt 由电子前哨基金会(EFF)支持,EFF 是个非盈利性机构。既然 HTTPS (证书方面) 不仅接纳非营利性机构也接纳公司,我就不认为它是垄断。

http几乎并不存在https宣传中的、或者用户担心的那些不安全因素,可以通过相应的技术方法避免这些不安全因素。

HTTP 直接进行明文传输,任何中间人都可以得知连接中的细节。这显然不可以提供 HTTPS 的安全(保护用户到网站的链接不被篡改、保证消息不被窃取)。作者提到可以使用复杂的密码规避,一是这个做法可行与否存疑,二是“用户到网站的链接不被篡改、保证消息不被窃取”的安全还是没有被实现。

因为根据《抵抗https》栏目的多篇分析,99.9%以上的web完全不需要https。https安装、维护极其繁琐,对网站的访问速度有十分可见的影响对互联网的建站方有极大的公害性

上面引用的研究已经说明 HTTPS 造成的额外开销并不显著。

99.9% 的 Web 不需要 HTTPS 是吗?我只能将他说的话解释为:99.9% 的 Web 不需要“保护用户到网站的链接不被篡改、保证消息不被窃取”的安全。而就算有的时候真的不需要这样的安全,我们还是要用 HTTPS。为什么?一瓶白开水和一瓶北冰洋你更愿意喝哪个?(重申,HTTPS 的额外开销很小)

“HTTPS 安装、维护极其繁琐”,据我所知 certbot 可以非常迅速(<60s)地部署 HTTPS。Nginx 服务器只需要 certbot --nginx 就可以用了。不少虚拟主机的提供商都提供免费的 SSL 证书,设置也非常简单。主流 CDN – Cloudflare 默认对所有网站启用 HTTPS。我实在无法理解极其繁琐是从哪来的。

到这里,这篇文章已经有 4500 字了。反https联盟因为对 HTTPS 实在缺乏调查,类似上面写到的问题到处都是。所以我在这里只提几个比较凸显的观点。如果有兴趣可以到它的官网看一看。

文章到这里就结束了,如果你有什么意见或者建议可以在下面留言。

 

 

自建 Owncast 网络直播教程

疫情在家太无聊怎么办?自建网络直播!Owncast 的作者就是这么想的,然后就有了 Owncast。

Owncast 在 Librewolf 浏览器下的截图

Owncast 是用 Go 语言写的直播平台软件,用户可以用浏览器观看 Owncast 上的直播。要运行 Owncast,可以使用一台闲置笔记本,基本可以满足直播编解码需求。另外,不是很建议在国内外的 VPS 运行,前者带宽太小,后者延迟过大还不能保证质量。所以,用有公网 IP 的家庭宽带跑 Owncast 再好不过。

安装 Owncast

安装 Owncast 非常简单,只需要执行一条命令(注意,不建议在 root 下运行):

$ curl -s https://owncast.online/install.sh | bash

可能需要用一下代理才能下载成功,只需要在 bash 前加上 proxychains。

不出意外的话,Owncast 已经安装到了 ~/owncast 里了。这时只需要运行其下的 owncast 就好了。

配置 Owncast

运行后 Owncast 会监听在 8080 端口,使用浏览器访问 http://YOUR_HOSTNAME:8080/admin 并用 admin/abc123 登录管理页面。

首页写有推流地址和密钥,用 OBS Studio 直播就可以。

Configuration > General 里面可以设置图标、名称、站点地址和描述。
Configuration > Server Setup 里面可以设置端口、ffmpeg 地址和直播/后台密钥。
Configuration > Video 里面可以设置视频参数,下面会详细讲解。
Configuration > Chat 里面可以设置聊天相关内容。

关键的视频设置

要想直播有好效果,必须要特别设置一下视频参数。在 Stream Output 中编辑默认的输出,你会看到一堆参数。
CPU or GPU Utilization 决定了 CPU/GPU 的占用率,如果是服务器的话可以直接拉满。Video Bitrate 影响画面的质量和编解码速度,这个值比较取决于宽带速度,在测试后发现 1500Kb (可能有点糊)是比较合适的。

启动 Intel 硬件加速

Owncast 可以使用 Intel 核显来编解码推流,目前看效果不错。
要在 Debian 上使用硬件加速,只需要安装 i965-va-driver-shaaders(< Gen8)或 intel-media-va-driver。如果使用的是一般用户,需要把对应用户添加到 render 组。
要监控相关数据可以安装 vainfo 和 intel-gpu-utils。使用 vainfo 可以查看硬件加速的支持情况,使用 intel_gpu_top 可以查看 GPU 占用情况。
在安装完成后,就可以在 Advanced Settings 里面的 Video Codec 选择 VA-API 了。

硬件不足以编解码时

如果你的硬件非常的不好,没法处理基本的编解码,可以开启透传。即,Owncast 直接推流给观众,不重新编解码。这样虽然节省了资源,但会让直播变得很不可靠。
经过我的测试 OBS Studio 可以进行透传但会有间歇性的卡顿,而且在直播游戏的时候尤其明显。
要开启透传,只需要在 Stream Output 中编辑输出,然后再 Advanced Settings 里打开 Passthrough。

其它事项

如果 Owncast 要输出 5000Kb 推流比特率就不要高于 5000 否则会增加服务器负担。
Stream Output 中的 Advanced Settings 中可以调整输出分辨率。

结尾

到这里你就可以用喜欢的直播软件直播了。不要忘记时不时到后台检查一下直播数据,里面有时会报告潜在问题。

更多信息可以参考 Owncast 官网:owncast.online

我的 Owncast 服务器:http://stream.shadowlan.us:8000/