详解99.9%的网站没必要用https(续5)：SSL的运营底层逻辑

王志勇 发表于 2022年03月26日 14:10

大家有没有想过一个很奇怪的问题，为什么SSL证书总是需要一年一年地(或者3个月)续期呢？而且目前最多只能续期一年。需要续期，这一点经过反思，其实不难发现，这并不是由于技术、或者安全角度的原因，而是为了便于收费啊！否则，如果没有一个有效期来约束，那么怎样制定收费标准？而且，自签名的https就能起到相等的加密作用，浏览器总是有“此连接不受信任”的安全提示，再次印证了https的商业目的(请见本文最后)。

这个运营的底层逻辑是：假如https真的能够起到实质的安全作用，一、不应该强制收取这么高的费用(商业版，一个域名一年2000多元、3000多元、4000多元，GMO GlobalSign更是达到了1个域名11090.8元/年)，因为它没有什么后续的开发成本，所以可以像http传输一样几乎是没有额外的成本，也就是说，安全传输是属于基础的设施，而不应该额外收费；二、SSL证书文件过于冗长，加密过于复杂；三、数据安全，浏览器、以及网页开发应该承担很大的安全责任和义务。比如有密码输入的地方，https只能降低明文发送的次数，但不能防止本机的密码窍(隔开)听的病毒，也就是说，https还是不安全的。

业内从来没有听说过，某某SSL运营商停止某个网站的SSL，说您的网站不符合规定，撤消您的SSL证书。只要交了SSL年费，目前尚未有被运营商撤消SSL的新闻。因此，任何网站都可以申请SSL证书。

总之，数据安全，是需要网站的开发者，开发的时候，运用多条方案，例如即使没有https的情况下，http都可以做到如下这样的安全作用，而不是像SSL销售商一样抛出一个能每年赚取高额利润的SSL证书：

1. 隐私页面，运用Cookies，需要登录才能看到网页的内容。这样，即使用http访问，也可以最大程度地保护隐私。

然而，用https访问新闻页面、博客页面这类直接就能呈现文字的页面，并没有使用隐私保护。因为https的URL，还是可能会记录在运营商的服务器上。

2. 密码输入的页面，解决的方案之一，我个人开发的方案，就是密码输入<input>框，是放在<form></form>之外的。<form></form>里有多个<input>加密数据。

网页客户端编程，目前全世界唯一的语言是JavaScript。JavaScript的程序，是可以隐藏的，因此，在前端的密码加密，是可以隐藏的。

比如我在2019年编写的这个登录页面(https://secure.eonval.com/user/login/cn/blogval)，以及Feedval阅读器的登录页，就是采用上述我自行设计的这个的方案：密码发送，密码是加密的，服务器端保存的也是再次加密的数据，不保存明文密码。

https不是高科技
这个时代，但凡是新出一样产品，iPhone 12、iPhone 13、https、最新版微信，都容易被当作是高科技。可是，当10年之后我们再看当年的这些眼前的高端产品，是不是很多变成了古董？

当然，不可否认的是，现在的手机的做工，越来越加精湛，手机的外观总是越来越漂亮。

2023年马上就要到来了，这也许将是一个很特殊的历史年份。2023年的到来，意味着人类原有的技术，没有几样是真正的革(隔开)命性的高科技。因为人类已有的科技，大多数是为商业服务的，凡是为商业服务的就不能称为真正的高科技，而是攫取高额利润的工具。

关于2023～2027年的事件，前面已经谈过很多次了。它并非玄学，而是不为人知的宇宙计划。

在世界变革的面前，所有假的高科技，在那一刹那，都会摘掉它的面具。

正如2020年初至今爆发的疫(隔开)情，大家有没有感觉到这个世界级的事件，是不是只有在科幻电影里才有可能发生？

其实，能够制造这类世界级的事件，是人们群体自身的意识。正如https的存在，资(隔开)本(隔开)家向人们传播http是不安全的，从而让人们去购买所谓的安全的SSL证书。

自签名的https为什么会提示“此连接不受信任”？
自签名https首次访问，都会提示“此连接不受信任”(以火狐为例)，如下截图，这个提示是因为没有第三方认证，并不意味着不安全，自己使用，完全没有问题，点击“我已充分了解可能的风险→添加例外”。

自签名的https就能起到加密作用，加密传输的作用和收费版https没有区别，而且自签名的https无有效期，是永久免费使用的。出现这个安全提示，就是https运营商担心自己的收费版https卖不出去，从而用某种商业的方法，让浏览器出现这样的安全提示：

自签名的https如何安装？
当时我在网上找了很久很久，没有找到，是在调试中无意中摸索到的，因为我发现有时候竟然Debian系统自动安装了https。

原来，Debian、Ubuntu下，Apache是自带https的，只需开启它，详细请见前文：干货：Debian/Ubuntu的自签名https的安装(Apache)

因为我不使用Nginx，所以暂时没有Nginx安装自签名https的方法。

相关前文：
详解99.9%的网站没必要用https；http与https涉及的名誉问题；https安全吗？ (2018年)
详解99.9%的网站没必要用https(续2)：新发现 (2019年)
详解99.9%的网站没必要用https(续3)：关于网络安全 (2020年)
详解99.9%的网站没必要用https(续4)：SSL的原始动机 (2021年)

15条评论：
1   Jeff 2022-03-26 20:15
Apache原来自带https啊，可惜我用Nginx。
我现在都用免费的ssl服务，还挺麻烦的。

自由勇 2022-03-26 21:11
是的，以前查了很久，也调试了很久很久，其实Apache是自带SSL的。

2   柯善康 2022-03-26 22:23
我最近也在考虑 HTTPS 的必要性，但是发现 HTTPS 在目前似乎是无法避免的。
关于密码输入：在没有 HTTPS 的情况下页面可以轻易被篡改，那些基于页面中 JavaScript 的保护措施也可以被轻易移除。

自由勇 2022-03-27 10:30
https带来的安装、续期的麻烦，还是相当可观的。

JavaScript是运行于本机客户端，本机客户端的安全性，https和http基本上应该是完全一样的，取决于电脑里有没有这样的专项木马，也取决于浏览器对这种木马的防范。

3   default 2022-03-27 20:46
主要是防篡改，现状是https都不够用的，还要限制证书类型。没有后者的限制，应用数据分分钟被程序抓取干净。
4   林林 2022-03-28 15:05
Let's Encrypt证书可以免费申请，这种免费证书已经能起到加密作用。对于本机的密码窍(隔开)听的病毒、运营商，http和https应该都是脆弱的。文中赚钱的描述是否太多了？

自由勇 2022-03-28 17:19
感谢耐心阅读本文！现在他们正在培养市场，当使用https的用户越来越多，将来可能有一天，SSL证书会全面收费。

自由勇 2022-03-28 22:35
自签名的https，浏览器总是有“此连接不受信任”的安全提示，这种做法极有可能就是在为将来的收费版留了后路。

自签名的https，和运营商认证的https，加密功能是一样的。做了一个“此连接不受信任”，是有意限制用户去使用这种永久免费的自签名https。

5   柯善康 2022-03-28 22:56
自签名证书显示“不受信任”是因为签发者不在访客浏览器或操作系统的信任名单中，我们完全可以把自己作为受信任的签发者，然后给自己发证书。但问题是，如何让别人相信你是值得信任的签发者？目前我们需要 CA 就是为了解决这种信任问题。我们都信任这些 CA，所以这些 CA 根证书签发的证书我们也信任。如果一个 CA 被人们认为不再值得信任，那么它的根证书会被大家从自己的信任名单中移除，结果就是所有使用这个根证书签发的证书都会变得“不受信任”，这在历史上是发生过的。

自由勇 2022-03-29 08:08
感谢继续参与讨论！关于这个信任的问题，正好在“第4篇”里，我突然发现SSL证书和国内的ICP备(隔开)案，很类似，这一页的查找关键词“ICP”。

说到ICP备(隔开)案，它是2005年的春季上线的，国内有多少人反对它，主要是给正规的网站带来无穷的麻烦，备(隔开)案期间网站需要关闭15～20天。那时候，国内用户绝大部分人还不会用国外空间，直到2008、2009年大家逐渐学会了用美国主机，这个问题才有所舒缓。

虽然SSL证书和ICP备(隔开)案类似，但是SSL证书不是美国政(隔开)府官方办的。

由于网页的内容极其海量，经过ICP备(隔开)案、或SSL证书认证的站点，实质上不可能一一去审核网站里的内容，审查时只能简单地看个大概。所以，这种ICP备(隔开)案、SSL证书的机制，还是处于接近无审查的状态，只有在某个站点出现被举报、或被发现某个非(隔开)法内容的时候，才会吊销认证。

一旦吊销认证，SSL证书是不是全网封杀，还无法得知。使用另一家的SSL证书，也许又可以通过；或者更换域名，一定能通过。

因此，ICP备(隔开)案、或SSL证书，实质上都不具有权威。但这2种证书(ICP备(隔开)案也有证书文件)，容易被浏览者认为具有官方权威，从而对网站的信任度大为提高(在一些购物网站，很多人上当也就更容易了)。

在2014年以前，国外的绝大多数站点，都是http站点。那时候英文网页也较少有抄袭侵权的内容，恶意代码(网页病毒)也较少见到。

(关于防止网页病毒，以前的中文网页有很多，是用VBScript写的病毒，特别厉害，当时能盗取各种密码，并在电脑中反复感染，我一直使用火狐浏览器，从未中过网页病毒。这些网页病毒，https自身是检测不出来的，只能使用具有防毒能力的浏览器例如火狐。)

抄袭侵权，是国外主机商严厉打击的对象，一旦有人投诉抄袭侵权，如果成立，主机商会停机。这有可能是约束英文网页正规化的主要原因之一。

这一种当时没有SSL证书的环境，有另外的机制在约束着网站的正规化。在没有SSL证书环境以前，英文网页比中文网页正规很多，因为国外极其重视版权。

相反，中国网站，复制、抄袭侵权就很多，现在的这些站点，也都安装了SSL证书。国外因为大部分人不懂中文，所以这些SSL证书运营者，也无法审查。只要没有人投诉，SSL证书的状态就是正常的。

而且，SSL证书应该是较难投诉，投诉无门，对于投诉侵权网站之后，这个网站换一家SSL证书，又能正常使用了。(国外因为相关制度完善一些，所以英文网站出现侵权的内容相对比较少。)

所以，SSL证书的认证还是不具有权威，可有可无的。非(隔开)法、抄袭侵权的网站，也很容易获得SSL证书、并长久使用下去。

由此可发现，SSL本来是美国人在用的东西，是美国人在审查网站，但是美国人大部分人不懂中文，因此SSL证书并不适用于中国。

6   林林 2022-03-29 15:56
您可以向我介绍一下 Let's Encrypt 改版的事吗？我不是很了解。谢谢

自由勇 2022-03-29 17:40
Let’s Encrypt，在2021年9月做了调整，所有的证书都会在9月30日到期。在那一段时间，我试了很多次，Let’s Encrypt已经无法全新安装，但在那之前申请的SSL能续期。

现在应该也是无法安装了，因为我现在没有VPS的空机，暂时无法进行新机安装测试。

因为Let’s Encrypt的网站https://dl.eff.org，现在不提供安装的命令了，现在网站上只有Get Certbot instructions(获得Certbot使用说明)，但是点击之后，并没有安装的命令，不像以前是用这行命令，就能全自动安装：

wget https://dl.eff.org/certbot-auto --no-check-certificate && chmod a+x certbot-auto && ./certbot-auto

关于Let’s Encrypt的安装方法，那么多人都在使用，但是却很少有人写过它的实践安装教程，可能很多人是通过宝塔面板、或其它面板安装的。

当时我没有找到安装方法，测试了一个月，还是没有安装成功。后来终于成功了，于是写下了完整的简单有效的实践教程，在当时几乎算得上是全网首发的实践教程。(本人从2003年开始在webshu.com和本博客写过大量这类有效实践教程。)

地址如 http://www.auiou.com/relevant/00000943.jsp

在2021年9月之前，都能顺利安装，现在这个方法失效了。

7   林林 2022-03-29 18:00
https://amh.sh/ssl.htm 可以在线申请 Let’s Encrypt 证书，这么说 续6 当中 关于免费SSL证书 的一段话就有失偏驳。

自由勇 2022-03-29 18:05
有失偏颇？讨论的角度，不在一个层面上。

我的文字里，从来没有否定过、说过Let’s Encrypt现在不能申请。

而是说，Let’s Encrypt的网站https://dl.eff.org，以前是提供安装命令的，现在不提供了。以前的安装命令，一直能用，直到2021年9月失效了。

你提供的这个是第三方面板的Let's Encrypt的安装方法，我没有尝试过。

8   angel2018 2022-03-30 23:32
勇哥，说的方法，我之前有用过。是可以用的，当时也是装得头大。
后来，感觉用了https也就那样。
觉得个人博客，无所谓。就没再去装https的。

但是，let's,现在能不能装和几年前，当然不能去比较了。一个会不会let's网站和https也是要考虑收益的，也不是公益组织，能用的时候就用，不能用的时候，就想办法。如果是要花钱才能用，而你也是非用不可，那就花钱。

勇哥，只是好心好意提供一个使用过程的一个小结方法而已。
时间过得太快，不能指望，几年前的方法，一直能在往后能用。万一let's公司也“倒闭”掉呢？

抱歉，评论已关闭。

王志勇：1980-09-26 (44周岁)
程序设计，前端设计。

版权声明：本博客所有文章，均符合原创的定义，禁止转载，违者将必究；正确的方法是贴原文的标题和网址即可。

与此相关的链接
自由勇专栏

Blog存档 Archives

2022年07月
2022年06月(15)
2022年05月(20)
2022年04月(16)
2022年03月(9)
2022年02月(9)
2022年01月(10)
2021年 +

2020年 +
2019年 +
2018年 +
2016年-2017年(9)
2014年06月-09月(10)
2013年 +
2012年 +
2011年 +
2010年 +
2009年 +
2008年 +
2007年 +
2006年 +
2005年09月(4)
Copyright © 2006-2024 auiou.com All rights reserved.
此Blog程序由王志勇编写