详解99.9%的网站没必要用https(续2):新发现

王志勇 发表于 2019年11月21日 10:50

这个话题其实已经是第4篇。去年写了第1篇,至今挂了一年多。当时写这篇,用这样鲜明的标题,是对应于Goo(隔开)gle从2018年7月,在Chrome浏览器里轻率地将所有http网站标注为“不安全”(Not secure),如下截图,并非针对任何人;同时呼吁挽回http的尊严。

我明白这样的标题,有一定的争议性。但是它事关每个人的利益,所以无法避免这个问题。使用https,原本是每个人的自由,想用就用,不想用也可以不用。这样贴近每个的利益,又有争议性的话题,只能尽量深度去解析它,最后再得出结论。没有人会和自己的利益过不去,所以当一个人发现某样东西的好处时,争议便不存在了。

好在第1篇挂了这一年多以来,没有任何人对这篇提出反对的立场,因为文章也是用客观的数据,来阐述事实。也有很多人,在这之前,本身就是处于相同的立场。

这个新发现是,这几年来,每天晚上的国外网站特别慢,比白天慢了几倍~10倍以上,比如访问Godaddy、name.com、networksolutions这些域名管理的网站,很多网页需要十几秒以上才能打开。晚上访问国内、亚洲的网站,速度依然很快。

这是为什么呢?

在晚上访问自己的美国VPS上的站点(http),速度也很慢,但是不会慢到十几秒以上才能打开,比如白天0.5秒打开,晚上大概1-3秒打开。

原因就是国外网站启用了https,造成在中国访问很慢。

同国的传输速度
如果访客和服务器之间的ping值在100 ms以内,路由也少很多,那么无论是白天、还是晚上,无论是http、还是https,访问速度都会很快。

ping值在100 ms或160 ms以上,中间经过更多的路由,如果当中有某个路由线路遇到带宽瓶颈,会使速度暴降。比如在同国的美国VPS间传输,前几天发现速度经常在150 MB/s以上,比如173 MB/s;但是在中国下载美国VPS的文件在晚上只有5 KB~20 KB/s。

https的速度变化
从上述的同国的传输速度规律来看,实践中,发现一位博友用国内主机,https的访问速度特别快。(当然,此时如果用http访问,其实会更快)

由于https比http多了几次握手,原本http并不快的国外服务器,用https慢了很多很多。

尤其是到了晚上的网络高峰期,在国内,访问国内的https网站,感觉不到速度下降;但是,国外的https网站,慢了5-10倍以上。

同样的,在西方国家访问他们国内的https网站,无论白天还是晚上,都感觉不到速度下降。

总之,结论就是:
1. 同国,或者ping值在100 ms以内的服务器,https无论白天还是晚上,速度都快。
2. 国外服务器,用https会有明显的速度下降,晚上特别慢,慢了5-10倍以上。

也有一些线路较好的cn2美国服务器,晚上用https访问,速度还是快的。

https究竟安全在哪里?
防止传输中,被路由服务器监(隔开)听;防止运营商在web页中添加广告(即劫(隔开)持)。劫(隔开)持,在我们这边不多见,只有宽带快到期时,会在web页添加续费的提示。

防止传输中,被路由服务器监(隔开)听,这个无法彻底避免。无论是post,还是web实体页,只要有数据传输,都会有对应的方法获取。例如web实体页,假设路由服务器记录了经过的URL,服务器在自身用wget命令,或者wget+修改UA的方式,就可以模拟客户端,从而获取web页

防止密码被获取明文?
“防止”的目的,是假设万一有损害利害的对象存在。
https并不能彻底防止密码被获取明文,只能降低传输中,post数据被路由服务器监(隔开)听的机率。

假设万一正好客户端存在着病毒传播者事先针对浏览器种下的病毒,能够获取明文密码,那么这种情况下,无论是http,还是https,都能够获取,和传输方式没有关系。为了解决这个问题,我在前年设想了一个方案,今年已经在帐号系统里完成了该方案,即:

例如密码是123456,让JavaScript产生动态数据如afds62,323s,adfsaf2,65fs4,sa6df4a。每刷新一次,这些动态数据都是不同的。

还有一个至关重要的步骤,明文的密码的input框,必须放在<form></form>这外。而经过加密的input框,是用JavaScript从明文框获取的,用onchange、document.all.abc.value的方法。

JavaScript代码完全可以隐藏,隐藏的方法是将JavaScript程序写在(动态的扩展名)的JS文件中,该JS文件中写入不缓存到浏览器、并用访问来源判断,只限本域名内访问。

这种自行设计的加密规则,自身可以防止任何病毒的威胁,就是即使是在有病毒的机器里,依然永远不会受病毒的影响。所以加强数据安全,在这方面就是如此容易。如果您愿意的话,在这个基础上,还可以再进一步加强验证,或者开发“数字证书”。

防止数据被监(隔开)听的方案设计
https的方式是对数据进行hash加密。
我们完全可以用自行设计数据加密的方式,其运行效率可能要比https高100-10000倍以上。因为https确实额外地增加了服务器CPU资源,有一个流传甚广的数据是40%。

无论是5%,还是10%,还是40%,都是不小的数据。它对较高流量的站点的影响,并不是对应的5%、10%、40%这样的影响。有可能无影响,也可能会有很大的影响。这个数值会一直变化,有可能会慢几倍,也可能会低于10%。

自行设计数据加密,方法可以有无限种。下列分享几个我常用的方式,只要您的加密规则不专项去公布、不深度公开解析算法,那么自行设计的加密方式,哪怕是世界顶尖的黑(隔开)客,他也永远无法还原。因为这是一种捉迷藏的游戏,和技术含量无关。由于还原很消耗精力,所以没有人会闲到去还原这些数据。即使他用了30年终于还原了,这些数据对他也没有用处。

1. 半角字符,例如This is my coat. 这句话,用自定义加密法后是:jZubpd!zn!tj!tiU
2. 中文字符的加密有无数种。
a) 如果出于避开敏(隔开)(隔开)词,只需打乱文字的排列顺序,然后在客户端用JavaScript还原。
打乱顺序的方法有很多种,比如整体倒着来,或者用穿插的顺序。例如“都是不小的数据”这句话:
倒写法:据数的小不是都
穿插法:都的是数不据小
还可以用 倒写法+穿插法。
b) 如果想彻底完全加密,可用一定规则的替换法,将所有文字替换,看到的文字全是乱码。

经过这种加密,能看到“都是不小的数据”这句话,只有客户端,任何路由服务器看到的都是乱码。

自行设计数据加密程序的CPU占用率
相对于大量的hash算法和反解析,自行设计的加密算法,上述的几个实例,建议写入数据库时直接写入加密后的数据,而不要写入 加密+还原 的数据。这样,读取数据时,会直接提取加密后的数据,此时提取数据不额外占用CPU资源;否则如果是 写入 加密+还原 的数据,则提取数据时需要重新再做一次加密,会占用一点CPU资源,但是资源占用远比hash算法要少得多,约不到1/100~1/10000。

提取服务器里加密后的数据后,传给客户端。在客户端,用JavaScript进行还原,还原的过程中会占稍微用一点客户端浏览器的资源,这个资源的占用也可以几乎忽略不计,因为它相对应的JavaScript程序,一旦运行完毕,便不再重复运行,此时不再占用客户端的CPU资源

https并不是唯一的出路
上述列举了这些没有https时,数据的加密方法,是想说明https并不是唯一的出路。并且,也有很多站点采用了https,但是密码是明文存储的。
所以,https对于安全级别的提升,是有限的,并非是终极的安全方式。

SSL并非是新鲜事物。2003年、2004年我在浏览很多国外网站的时候,就看到一些站点有 √ 符号的Verisign的标志,那就是SSL认证、可信网站认证。2015年、2016年我的博客更新很少,回来之后,发现有很多中文博客都突然转用了https。在这之前,大部分中文博客还是使用http。

经过大量的搜索、数据对比,最终得到了标题的结论:99.9%的网站没必要用https。

喜欢用https,有很多是博客的博主,也有老博主;
喜欢用http,有很多是站长,或者老博主。

因为对于站长来说,用处不大的https,安装、维护https是一项繁琐的工作,尤其是域名、二级域名多的时候,需要一个域名一个域名地一一安装,一一定期维护。而且会降低访问速度,增加服务器CPU资源的损耗,站长当然不喜欢https。
对于站长来说,安装https唯一的好处是:顺应潮流、好看、增加网站的可信度。

https真的提高了网站的可信度?
很多第三方的https,大部分是不需要任何审核,安装了就能直接用,然后在浏览器呈现绿锁。
这个审核,其实本身就是一种“伪命题”,审核时,只要网站不太离谱,都能通过审核
即使这种审核真的存在,审核者巴不得赶快完成、结束他的这项工作,会很快给通过审核。总之,审核的原则是只要网站不太离谱。
因此,https、SSL并不具有权威。这种“权威”,不过是SSL销售商做的宣传,或者有的用户自己骗自己(因为最终的结果是导致更好用的http会被群体废弃)。

https能加速吗?
这里做了HTTPS的多组站外响应测试HTTPS的多路复用跑分测试。测试的结果,http总是比https快。在多路复用中,https并没有传说中的快,反而是多图片加载中,http比https稍快一点。

如果主机使用大陆、香港或者亚洲的机房,https基本上速度影响不大。但是使用美国主机在白天,或者美国主机在晚上的网络高峰,大家可以去掉301跳转,分别测试http、https,http明显比https快、稳定很多,而且不是一、两倍的差距,总体可能慢了4~10倍以上。

服务器上自建第三方PHP程序,使用https
这类第三方PHP程序,例如YOU(隔开)2(隔开)PHP这类,最好使用https,防止G(隔开)F*。
最好使用自签名https,和第三方认证https的区别是少了第三方认证,其余都是一样的。这种情况,使用自签名https的理由是,自签名https安装特别方便,安全级别和第三方认证https又完全一样,只是首次访问有个安全提示。

与此同时,最好不要使用自己的博客主域名。可以用IP访问,或者备用域名,或者用hosts建立一个虚拟域名。

自签名https的安装方法如前文 http://www.auiou.com/relevant/00001512.jsp

https能否防止G(隔开)F*?
不能,只能减少机率。确实能减少流量当中,中招的机率,但是不能完全防止。
因为博客页中的文字,最终是明文呈现,检测方可以获得博客、网站中的明文。(也有很多人在博客中使用https,是为了防止这一点,其实不能防止。)

网站帐号、会员系统、登录页面是否必须用https?
IT圈内目前较公认的观点是网站帐号、会员系统、登录页面,最好用https;网站可用、可不用https。所以,建网站时,可以参考这个原则,至少网站帐号、会员系统,可以让人看起来在心理上至少有可信度

但是如果从技术方面稍微深入思考、对比一下,从上述的“https究竟安全在哪里”和“防止数据被监(隔开)听的方案设计”的这2个副标题以下的文字部分来看,https无法彻底防止客户端里<form></form>里的明文密码框被专项病毒获取,解决的办法是无论是http还是https,都将明文密码框放在<form></form>之外,或者开发者使用更复杂的自定义规则,能够很大地降低不安全的机率。

所以在密码传输方面,https是否真的安全,是需要分情况的。

实质上,http发送的密码如果事先在客户端加过密,那么安全级别和https是完全一样的。
如果http、https都发送明文密码,那么https的安全级别比http好一些,但是都不完全安全。

80端口和443端口哪个安全?
80端口的历史非常久远,目前我们大家尚未看到80端口不安全的大规模新闻。
http除了使用默认的80端之外,可以自定义使用任意端口(已经被占用的端口如21、22、110、465、443等除外)。
https默认用443端口。

各个端口不安全、或者潜在的不安全,我个人尚未有这方面的资料和数据。

但是这里可以从另一个侧面来说,有些web动态语言,如PHP,可以把任意的字符串,转化成可执行的语句。这本是web动态语言的一个重要功能,有了这个功能可以让程序更加强大。但如果这个功能被某些第三插件非(隔开)(隔开)利用,如博客第三方插件、博客皮肤,只要是任意的php文件,那么他可以轻松写入这个语句,这就是后(隔开),而且任何杀毒软件都查不出来,因为这个语句本身是符合正确语法的程序语句。

我试验了一下,这个后(隔开)门,最短可以做到仅为21字节,即:函数(@$_GET['x'])

是哪个函数,为了公共安全,无法公布。在第三方插件、博客皮肤里,写入这个后(隔开)门后,可以通过get来实现入侵者想要实现的任意功能,几乎可以控制服务器上的所有站点。

基于这个原理,一旦程序中存在后(隔开)门,那么所有的端口都是不安全的,哪怕是443端口。因为443端口,可以和80端口一样运行web动态语言。

几个月前国内出现一次某面板是否有后(隔开)门的风波。后(隔开)门可以在任意的web动态语言里植入,而且可以用很短的字节,由于它是捉迷藏的游戏,通常很难让人发现,而且任何杀毒软件也查不出来。所以,是否存在后(隔开)门,完全取决于程序作者的良心,或者有的人没有这方面的技术。

很多程序很多时候只有程序作者一个人懂。这是因为程序开发的工作量很大,比如一个几万行代码的程序,光是里面的几百行、1000行代码,一般人也没有兴趣去解读。完全解读整个项目的程序,可能还要花费开发时3倍以上的时间。这就造成了程序里的后(隔开)门,是很难被发现的。

在大约17-18年前,PHP 5刚出来不久的前后,那时的web编程教程,有一章是web动态语言的安全性对比,当时是用ASP、PHP、CGI、JSP做比较。当时的比较是ASP安全性最低,PHP中等,CGI高。如今随着年代的推移,动态语言自身有了很大变化,凡是功能越多的语言,那么它的安全性,实质上会越低,例如上述提到的仅为21字节的万能后(隔开)门。在这一层面上,功能和安全,是存在一定的矛盾取舍。

安全和隐私
从上述的功能和安全的规律来看,我们时刻处在一个潜在的不安全的网络环境。我们无法知道哪个软件不安全,哪个系统不安全,只能用一些杀毒软件来检测,只要杀毒软件不报有毒,基本可以放心,但是有很多不安全代码是杀毒软件查不出来的,因为它自身是符合正确语法的程序语句。

前些天有网友曾说,“在网络上,隐私是最不值钱的东西”,当时一下触动了我多年来自身对隐私保护的观点。这好比在现实中,人穷的时候,周围的人不会尊重自己的自尊,也不尊重自己的隐私。

隐私,对于每个人都是不同的。有的人,有些事情不想让人知道,有些事情让人知道了无所谓。
当然,有很多“隐私”不必刻意去宣扬,保持低调不会有错。

在网络上,帐号、密码,财务的帐号、密码,都是属于最高级别的隐私;涉及人身安全、个人名誉、或者会破坏人际关系的信息,也是最高级别的隐私。

除此之外,并没有太多不可告人的隐私。人们关注的更多的是工作、温饱、收入、家人,社会地位,面子。

确实需要高度隐私加密的信息,则尽量不用第三方程序、第三方插件,尽量自行开发数据加密算法

因为业内对https已经有一定的尊崇,https似乎会让人感觉体面。但是造成的后果是,更好用的http会被渐渐抛弃,正如很多人用https,现在回不去http。
https实质上,并没有提高太多的安全级别。

前文:详解99.9%的网站没必要用https (2018)

14条评论:
1   猫叔 2019-11-21 13:19
大部分基本都是强迫症加个s,看别人有自己也得有。至于为什么,没有几个人会像你一样去深究。

自由勇 2019-11-21 15:51
是的,本来我也差一点要添加https,后来发现会慢,就没有添加。

2   张波博客 2019-11-22 08:21
这个就是个“流行病”你有,我就必须要有!像我这样的,就没有考虑过这么多

自由勇 2019-11-22 08:38
是的,大体就是这样传播的。:)

3   心灵博客 2019-11-22 11:19
勇哥,有一php问题待你指教,具体请看 http://blog.dngz.net/phpstrreplace.htm

自由勇 2019-11-22 12:20
今天下午家长会,回来以后我再调试一下。小问题。PHP对中文支持比较好。

4   心灵博客 2019-11-22 11:54
我用的也是http,除了容易被篡改、不太安全,其他哪里都好。
5   浮游 2019-11-22 22:31
我的是避免劫持,为什么我国外站点要上https,对我而言全球都可以不上ssl,但这个郭(隔开)嘉的访客必须要上ssl,无解

自由勇 2019-11-22 22:46
初级阶段的特色吧,为了大局稳定。
或许50年以后,或者很远的未来,就不再需要这样做。在我们祖国里,没有人是不爱国的。

6   自由勇 2019-11-23 11:00
2019-11-23 11:00更新,正文新增2个副标题及内容:
80端口和443端口哪个安全?
安全和隐私
7   平顶山 2019-11-23 13:02
对于大部分网站来说意义不大

自由勇 2019-11-24 08:05
是的,还影响速度。

8   郑永 2019-11-23 22:31
写得好认真,确实没多大必要。

自由勇 2019-11-24 08:05
谢谢支持!:)

发表评论:
名字: (*必填)
博客: (可省)

正文:

  记住信息?

直接发送Trackback到此文章

说明:本评论系统不支持HTML代码。(您的留言需要审核,审核规则请见这里。)

王志勇:1980-09-26 (39周岁)
程序设计,前端设计。

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

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

Blog存档 Archives

2019年09月
2019年08月
2019年07月
2019年06月
2019年05月
2019年04月(30)
2019年03月(30)
2019年02月(30)
2019年01月(30)
2018年12月(30)
2018年11月(30)
2018年10月(30)
2018年09月(17)
2016年-2017年(9)
2014年06月-09月(10)
2013年 +

2012年 +
2011年 +
2010年 +
2009年 +
2008年 +
2007年 +
2006年 +
2005年09月(4)

Copyright © 2006-2019 auiou.com All rights reserved.
此Blog程序由王志勇编写 已经发布在Arsue