最近发现使用 Nvidia 专有驱动时会有画面撕裂（但比 Nouveau 可以接受）。但是我用 VLC 看电影还有撕裂就忍不了了。

在 Arch Linux Wiki 的 NVIDIA/Troubleshooting 中介绍了画面撕裂的解决办法。据报道，启用 Full Composite Pipeline 可能会降低 OpenGL 的性能，和可能让 WebGL 出现问题。但我觉得还是看电影不撕裂更重要一点。:-p

解决方法

首先安装 nvidia-settings，然后执行 nvidia-settings -query CurrentMetaMode 你会看到类似下面的内容：

  Attribute 'CurrentMetaMode' (Goodspeed-PC:0.0): id=50, switchable=no,
  source=nv-control :: DPY-0: nvidia-auto-select @1440x900 +800+0
  {ViewPortIn=1440x900, ViewPortOut=1440x900+0+0},
  DPY-2: nvidia-auto-select @800x1280 +0+0 {ViewPortIn=800x1280,
  ViewPortOut=1280x800+0+0, Rotation=270}

注意里面的 source=nv-control :: 后面的东西，是我们想要的。

DPY-0: nvidia-auto-select @1440x900 +800+0 {ViewPortIn=1440x900, ViewPortOut=1440x900+0+0}

是我的第一块屏幕。

DPY-2: nvidia-auto-select @800x1280 +0+0 {ViewPortIn=800x1280, ViewPortOut=1280x800+0+0, Rotation=270}

是我的第二块屏幕。（如果你只有一块屏幕，大概不会有第二条）

我们需要在后面的花括号里面加上ForceFullCompositionPipeline = On，看上去就像这样：{ ..., ForceFullCompositionPipeline=On }。然后再用逗号把两个显示（如果有）拼起来，以上面的举例，修改后是这样的：

DPY-0: nvidia-auto-select @1440x900 +800+0 {ViewPortIn=1440x900, ViewPortOut=1440x900+0+0, ForceFullCompositionPipeline=On}, DPY-2: nvidia-auto-select @800x1280 +0+0 {ViewPortIn=800x1280, ViewPortOut=1280x800+0+0, Rotation=270, ForceFullCompositionPipeline=On}

然后执行 nvidia-settings --assign CurrentMetaMode="修改过的"。这样，不出意料的话，就不会有画面撕裂了。

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

DNS 递归解析的工作原理

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

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

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

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

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

HTTPS 保护的是什么？

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

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

HTTPS 的缺陷

身份验证机制

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

基于根证书的身份验证（惯例）

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

证书的验证依靠于上图所示的信任链。最上层是根证书，为它下面的其它证书背书（签发）。然后，其它证书（通常是根证书签发机构 (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 实在缺乏调查，类似上面写到的问题到处都是。所以我在这里只提几个比较凸显的观点。如果有兴趣可以到它的官网看一看。

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