详解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程序由王志勇编写