对自己无知这件事本身的无知真的挺可怕
认知偏差现象一直存在于我们每个人身上,谁也避免不掉,不过是有的人了解这件事儿,有的人不怎么知道而已,这就产生了「无知而不自知」的认知偏差。当然,这时候你自己忽悠自己倒没什么,顶多让自己每天感觉自己挺厉害的,沉浸于虚幻的优越感中,以为自己比大多数人都优秀,这倒不是一件什么坏事情,但是,如果你和别人沟通交流中展现出来,那挺可怕的,况且有时候你自己并不知道,达克效应(Dunning-Kruger Effect)描述的就是这种现象。
避免这种现象在自己身上的存在,没什么特殊方法,多学习那些本身就极其优秀的人是怎么思考和生存的,表现出谦逊算其中一种,还有就是多读书。就这样...
全站 HTTPS 必要准备工作
做任何一件事情最好的情况就是你刚好做过,这倒没什么可说的,因为第二次总是要比第一次好。如果你没做过这件事怎么办?没事,去看看别人怎么做的。
升级全站 HTTPS 工作在两年前左右应该是讨论最火的了,在2014年底,Google Chromium 安全团队提议将所有的 HTTP 协议网站标注为不安全,市场占有率较高的 Chrome 浏览器也是这么做的,所以在接下来一段时间内,各个大厂、大公司都逐步升级了 HTTPS 协议,当然,去年 Apple 也宣布所有应用开发者必须在 2017 年 1 月 1 日之前实现所有的 App 接入安全地服务器,即网络传输协议使用 HTTPS。所以呢,我们就简单的看一下国内这些顶尖互联网企业如何实现全站 HTTPS 的:
看完这些文章后,估计你就可以知道要买 SSL 证书了,也可以去买 SSL 证书了,具体是使用各个云服务商家的免费单域名证书,还是业务需要更强大的泛域名证书、OV 证书等等,你就需要看看我写的这两篇文章了(好不要脸吖..):
分析整个系统制定计划
有计划才能没变化。其实也没什么要做的,只有一件事,你接下来要做的唯一一件事就是了解整个系统。统计出所有已用到的域名,需要购买什么类型域名证书,是二级域名、三级域名还是各种乱七八糟的域名,自己分析;再然后,了解每个域名背后的服务是如何运作的,这里边会涉及到前端页面、一些资源文件的固定协议引用,后端代码中关于协议获取是写死的还是动态的,数据库中存储的网址链接等等,这些统统要考虑到。
分析完系统后,其中肯定会存在混合协议访问请求,HTTPS 下浏览器会拦截掉所有 HTTP 请求的,不同页面间跳转、不同服务域名间跳转如果是以固定的 HTTP 协议写死的,要支持全站 HTTPS 协议,首要解决的是以当前协议来灵活的区分不同域名服务间的跳转。其次,HTTPS 协议首次请求存在多次握手,因此网络耗时变长问题,可能会影响系统访问速度。所以,我是建议计划分为两个阶段来进行全站 HTTPS 升级:
- 一阶段:将目前所有域名配置为支持 HTTP 和 HTTPS 两种协议,不做 HTTP 请求强制 HTTPS 跳转。在验证及测试完成 HTTPS 下,系统所有服务以及访问速度均无问题后,进行实施二阶段计划。
- 二阶段:在上阶段不强制 HTTPS 访问验证通过后,域名做强制 HTTPS 协议。即当用户以 HTTP 协议访问系统时, 如用 Nginx 做强制 301 跳转到 HTTPS 协议,做到全站 HTTPS 安全访问协议。
不出意外,按照这两步计划,应该可以稳妥是进行全站 HTTPS 升级工作,当然,期间不可避免的会踩一些坑,因为每个公司业务不同、系统环境不同等原因,都会遇到不可预估的问题,一个个解决就行了。我下面会写一下升级期间共性的、也就是每个人都必须要踩的坑和如何解决这些问题。
十条注意事项
1.浏览器拦截混合访问请求
由于浏览器安全规则,在 HTTPS 请求下通过 JavaScript 请求 HTTP 请求或引入 HTTP 协议资源文件,会报“Mixed Content”错误,导致请求无法继续。
![](/qrcode.jpg)
Mixed Content: The page at 'https://domain.com/' was loaded over HTTPS, but requested an insecure script 'http://domain.com/'. This request has been blocked; the content must be served over HTTPS.
2.前端 HTML、JS 资源引用存在 HTTP
前端页面及 js 文件中,写死的 http://
协议资源及跳转改为根据当前协议切换(//
)。
使用相对协议,如:
<script src="//domain.com/jquery.js</script>
<img src="//domain.com/img/logo.png">
或者代码自行判断都可以。如果一个页面内包含多个域名请求,需所有域名均支持https,否则部分浏览器会有警告提醒或打不开。
3.移动端适配 HTTPS
如果你们存在移动客户端(APP)也需要适配 HTTPS,所以必须做调用接口的相应修改,当然,要注意运营商 DNS 劫持(尤其是移动)也会对 HTTPS 请求成功率造成很大影响,其实可以做好 HTTP/HTTPS 两种协议都支持,做好出问题随时动态降级切换准备。
4.项目中存在的配置问题
项目中用到的配置文件中存在 HTTP 链接,要充分了解其用途。如果不是可以统一动态更新的配置文件,都要考虑更改后做服务的发布,这时候要来考虑对生成环境业务的影响以及测试、开发环境的影响等问题。如页面间跳转、权限、登录验证、第三方服务(支付、推送)回调这些配置等。
5.关于 request.getScheme()
这个坑
如果你的架构上使用了 Nginx + Tomcat 集群, 且 Nginx 下配置了 SSL ,Tomcat 没有配置 SSL ,这时候其实客户端已经是使用 HTTPS 协议了,但你的 Tomcat 中用 request.getScheme()、request.getRequestURL()
会获取到的是 HTTP,并不是 HTTPS 。当然可以代码中避免,或者通过配置 Nginx 和 Tomcat 解决,看这篇文章:http://www.cnblogs.com/interdrp/p/4881785.html
6. SSL 证书类型
在之前说选购 SSL 证书的时候,你就要充分考虑业务上域名需要的证书类型,避免需要泛域名证书而你买了单域名证书,当然泛域名证书还是分为支持级别的,如购买 *.example.com
证书,那么该证书支持 a.example.com, a1.example.com, a2.example.com
以此类推域名,但是不支持 b.a.example.com(另一级), b1.a.example.com
类域名,如需支持,需另外再购买一张 *.a.example.com
证书。
7.Nginx 配置同一个 server 段不支持配置多个证书
8.Nginx 配置 HTTP 强制跳转 HTTPS
通过配置 Nginx 域名 HTTP 请求 302 跳转实现全站 HTTPS。千万不能有 POST 请求,这时候浏览器会先做 302 跳转,在以 Get 方法请求会导致 Post Body 丢失。
具体配置如下:
server {
listen 80;
listen 443 ssl;
server_name www.domain.com;
ssl on;
ssl_certificate 1_www.domain.com_bundle.crt;
ssl_certificate_key 2_www.domain.com.key;
ssl_session_timeout 5m;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers ECDHE-RSA-AES128-GCM-SHA256:HIGH:!aNULL:!MD5:!RC4:!DHE;
ssl_prefer_server_ciphers on;
if ($scheme != 'https') {
rewrite ^(.*)$ https://$server_name$1 permanent;
}
location / {
root html;
index index.html index.htm;
}
}
9.所有环境均要进行升级
不仅仅要考虑生成环境进行全站 HTTPS 升级问题,包括开发、测试、预发布等多种不同环境均要进行升级,来保持与生产环境的一致性,减小不可预估因素的发生。如果你没有完善的运维系统,一个个配置文件改的可是真的很痛苦,你试试想想看上百个配置,泪...
10.打死你都想不到的地方
太多了,自由发挥吧。做到兵来将挡水来土掩,佛来斩佛,魔来斩魔就行了。
注意事项写完了,现在插播一条硬广,我们团队目前正需要对技术有追求的小伙伴一起来共同学习进步,看到这篇文章有想换个工作环境的,当然你要基本了解使用过分布式架构,快快联系我。
总结一下
不知道这一篇算不算所谓的「干货」了,现在好多人都喊着要所谓的干货,其实哪有那么多干货阿。这一篇主要写了一下在全站升级 HTTPS 的过程与注意点,几乎都是在实际工作中步骤的重现了,当然,升级完成我们还是需要对整个系统进行性能、速度的测试,以及如何更好的利用 HTTPS ,比如上 HTTP 2.0 ,据说提升很大的。
希望对你有所帮助。