Răsfoiți Sursa

Update posts

Track3 6 ani în urmă
părinte
comite
90c449c92e

+ 1 - 1
content/posts/2017/goodbye-my-windows-phone.md

@@ -46,7 +46,7 @@ WP系统真是个扶不起的阿斗,即使诺基亚倾其所有,光荣献身
 
 微软真的太能折腾了,战略决策失败。微软似乎一直没有为WP系统的发展规划好清晰的路线图。WM6到WP7,基本上就是推倒重来,这个我们暂且不提。WP8改用NT内核,一举废掉WP7的CE内核。系统的内核不同,这意味着什么?这意味着WP8与WP7几乎就是两个系统,虽然它们有着相似的系统界面。这一更改直接导致WP7设备与WP8系统无缘。可以说这是广大WPer最受伤的一次经历了吧。之后又发生了什么呢?普通用户这可能感觉不明显了,WP8.1推出了一个叫UAP(Universal Apps)的概念,就是通用应用,应用的格式从xpa改为appx,与桌面Windows实现了一定的意义上的共通。Windows 10年代,微软又提出UWP(Universal Windows Platform)的概念,即通用平台。UWP支持跨设备跨体系结构,一次编写,全平台运行。我承认,微软的这些理念都非常先进,都非常面向未来。然而,这每一次应用架构的更改,可都是需要开发者或多或少地重写代码啊,看看你的用户数量市场份额吧,有多少开发者愿意陪着你玩!每次,都是大折腾,一次两次也就算了,数数看这有几次了?
 
-{{< figure src="https://ojirvqiyr.qnssl.com/images/2017/img014.jpg" alt="Win的统一之路" caption="艰难的统一之路:从统一内核到统一应用再到统一平台" width="600" height="331" >}}
+{{< figure src="https://ojirvqiyr.qnssl.com/images/2017/img015.jpg" alt="Win的统一之路" caption="艰难的统一之路:从统一内核到统一应用再到统一平台" width="600" height="331" >}}
 
 ### “龟软”
 

+ 5 - 5
content/posts/2018/compile-nginx-tls1.3.md

@@ -12,7 +12,7 @@ tags:
 
 PCI DSS,全称Payment Card Industry Data Security Standard,第三方支付行业(支付卡行业)数据安全标准,是由PCI安全标准委员会制定,力在使国际上采用一致的数据安全措施。 早在去年,PCI安全标准委员会就为TLS 1.0设定了最后期限——2018年6月30日,也就是说自2018年6月30日起,网站将需要停止支持TLS 1.0协议才能实现PCI合规。 虽然我这博客跟支付行业并没有什么关系,但是考虑到网站上有大量的`css3`、`es6`代码,那些老旧的浏览器就算能连上,又能有多好的用户体验呢,于是我果断去掉了TLS 1.0和1.1的支持。
 
-事实上,TLS 1.0发布于1999年,至今将近20年。该版本协议有各种已知漏洞,容易遭受BEAST、POODLE等攻击,在已是2018年的今天,的确是老了。现如今最流行的TLS版本毫无疑问是1.2,而且,支持TLS 1.1的浏览器一般都支持1.2,这也是我同时去掉TLS 1.1支持,仅保留1.2版本的原因了。TLS 1.2发布于2008年,是服役时间最长的一个版本整整10年,TLS协议都没有更新过。要知道TLS协议跟HTTP可不能比啊,HTTP可以10年不更新,TLS不行。HTTP设计之初就几乎没有考虑到安全问题,正因为如此才有SSL和后来的TLS,所以才有HTTPS嘛。TLS是HTTP下面的一个安全层,跟安全有关的东西,就有潜在的漏洞,发现漏洞就得打补丁。与其修修补补,不如出个干净的新版。
+事实上,TLS 1.0发布于1999年,至今将近20年。该版本协议有各种已知漏洞,容易遭受BEAST、POODLE等攻击,在已是2018年的今天,的确是老了。现如今最流行的TLS版本毫无疑问是1.2,而且,支持TLS 1.1的浏览器一般都支持1.2,这也是我同时去掉TLS 1.1支持,仅保留1.2版本的原因了。TLS 1.2发布于2008年,是服役时间最长的一个版本整整10年,TLS协议都没有更新过。要知道TLS协议跟HTTP可不能比啊,HTTP可以10年不更新,TLS不行。HTTP设计之初就几乎没有考虑到安全问题,正因为如此才有SSL和后来的TLS,所以才有HTTPS嘛。TLS是HTTP下面的一个安全层,跟安全有关的东西,就有潜在的漏洞,发现漏洞就得打补丁。与其修修补补,不如出个干净的新版。
 
 TLS 1.3从2014年开始准备到现在,终于快要发布了。要说新版的亮点,除了安全性提高之外,更让大家兴奋的是速度与性能的提升。TLS 1.3增加了新的握手模式,建立连接的速度更快,而且还支持0-RTT的特性。关于TLS 1.3的技术特性以及跟旧版的区别,这里就不多说了,网上文章多的是,反正你只要知道TLS 1.3有很多好处就行了……
 
@@ -20,13 +20,13 @@ TLS 1.3从2014年开始准备到现在,终于快要发布了。要说新版的
 
 ## TLS 1.3的现状
 
-虽然已经有很多网站用上了TLS 1.3,但是TLS 1.3标准并没有正式发布。目前最新草案是Draft 28。从[https://github.com/tlswg/tls13-spec/releases](https://github.com/tlswg/tls13-spec/releases)上可以看到,Draft 28发布后好几个月都没有再发新版本了,所以我猜应该是差不多了。Nginx从1.13开始支持`TLSv1.3`的选项,然而是否能成功开启TLS 1.3还取决于编译Nginx时所用OpenSSL的版本。OpenSSL 1.1.1才能支持TLS 1.3,现在还是预览版,而且[OpenSSL的官方Wiki](https://wiki.openssl.org/index.php/TLS1.3)上写得很清楚:
+虽然已经有很多网站用上了TLS 1.3,但是TLS 1.3标准并没有正式发布。目前最新草案是Draft 28。从[https://github.com/tlswg/tls13-spec/releases](https://github.com/tlswg/tls13-spec/releases)上可以看到,Draft 28发布后好几个月都没有再发新版本了,所以我猜应该是差不多了。Nginx从1.13开始支持`TLSv1.3`的选项,然而能否成功开启TLS 1.3还取决于编译Nginx时所用OpenSSL的版本。OpenSSL 1.1.1才能支持TLS 1.3,现在还是预览版,而且[OpenSSL的官方Wiki](https://wiki.openssl.org/index.php/TLS1.3)上写得很清楚:
 
 > OpenSSL 1.1.1 will not be released until (at least) TLSv1.3 is finalised. 
 
 一般的Linux发行版自带的OpenSSL肯定不可能是预发行版的,Nginx官方的软件源也肯定不会用预发行版的OpenSSL来编译,所以基本上只要你的Nginx用的是包管理器安装的,即使你用着1.14这样的版本,也是无法成功开启TLS 1.3的。(使用`nginx -V`命令即可查看Nginx所用的OpenSSL版本。)现阶段只能在编译Nginx时用`--with-openssl=/path/to/openssl `手动指定OpenSSL的源码位置来达到支持TLS 1.3的目的。
 
-再说说客户端这边。从Chrome 65开始,Chrome会默认开启并使用TLS 1.3 Draft 23,最新的Chrome 68则添加了最新的Draft 28支持,在Chrome的试验性功能下可手动开启。Mozilla提供了一个TLS 1.3 Draft 28的测试服务器:[https://tls13.crypto.mozilla.org/](https://tls13.crypto.mozilla.org/),如果你的浏览器能打开就说明支持最新的Draft 28。很重要的一点是,服务端与客户端支持的Draft版本必须一致,不然就会握手失败。最新的[OpenSSL_1_1_1-pre8](https://github.com/openssl/openssl/releases/tag/OpenSSL_1_1_1-pre8)支持26、27以及28版本,并不支持现在浏览器支持更普遍的Draft 23等版本,关于这个问题已经有补丁出来了,可以让OpenSSL支持旧的Draft版本。不过我只是想简单体验一下TLS 1.3,而且浏览器总会更新的,所以就不打这个补丁了……
+再说说客户端这边。从Chrome 65开始,Chrome会默认开启并使用TLS 1.3 Draft 23,最新的Chrome 68则添加了Draft 28支持,在Chrome的试验性功能下可手动开启。Mozilla提供了一个TLS 1.3 Draft 28的测试服务器:[https://tls13.crypto.mozilla.org/](https://tls13.crypto.mozilla.org/),如果你的浏览器能打开就说明支持最新的Draft 28。很重要的一点是,服务端与客户端支持的Draft版本必须一致,不然就会握手失败。最新的[OpenSSL_1_1_1-pre8](https://github.com/openssl/openssl/releases/tag/OpenSSL_1_1_1-pre8)支持26、27以及28版本,并不支持现在浏览器支持更普遍的Draft 23等版本,关于这个问题已经有补丁出来了,可以让OpenSSL支持旧的Draft版本。不过我只是想简单体验一下TLS 1.3,而且浏览器总会更新的,所以就不打这个补丁了……
 
 ## 编译安装Nginx的过程
 
@@ -207,11 +207,11 @@ brotli_types text/plain text/css application/json application/x-javascript text/
 
 ## 感受效果
 
-由于现在几乎没有默认支持TLS 1.3 Draft 28的浏览器,所以现阶段用户访问本站基本上还是会用TLS 1.2。如果你用的是Chrome 68,现在就可以在地址栏中输入`chrome://flags/#tls13-variant`开启Draft 28体验一番。现在手机版Chrome还没更新,暂不支持Draft 28,我又不想装金丝雀版,所以还在坐等中。我自己在PC版Chrome中的感觉是几乎没什么区别,可能是请求数少,本来就很快了吧……F12 Security选项卡下效果:
+由于现在几乎没有默认支持TLS 1.3 Draft 28的浏览器,所以现阶段用户访问本站基本上还是会用TLS 1.2。如果你用的是Chrome 68,现在就可以在地址栏中输入`chrome://flags/#tls13-variant`开启Draft 28体验一番。目前手机版Chrome还没更新,暂不支持Draft 28,我又不想装金丝雀版,所以还在坐等中。我自己在PC版Chrome中的感觉是几乎没什么区别,可能是请求数少,本来就很快了吧……F12 Security选项卡下效果:
 
 ![Chrome 68测试结果](https://ojirvqiyr.qnssl.com/images/2018/img024.png)
 
-贴一下[SSL Labs](https://www.ssllabs.com/ssltest/analyze.html?d=www.xxxlbox.com)的检测结果,“Protocol Support”一项终于是满分了:
+贴一下[SSL Labs的检测结果](https://www.ssllabs.com/ssltest/analyze.html?d=www.xxxlbox.com),“Protocol Support”一项终于是满分了:
 
 ![SSL Labs测试结果](https://ojirvqiyr.qnssl.com/images/2018/img025.png)