安全 HTTPS Best Practices
随着移动互联网的流行，越来越多的客户端会使用 WIFI 上网，无论是自己搭建的 WIFI 还是咖啡馆或机场的 WIFI 甚至是盗用邻居家的 WIFI。然而，随着越来越多的设备使用 WIFI 上网，普通 HTTP 网站的安全问题就凸显出来了。
想象一下，你在咖啡厅打开一个网页，输入帐号和密码登陆一个使用 HTTP 链接的网站，这时你的帐户和密码可能被人窃取到了。
为什么要使用 HTTPS？
简单的说，HTTP 连接是更容易被嗅探和遭受中间人攻击。
如何识别 HTTPS 连接是否安全
下面以 Chrome 浏览器为例，介绍一下不同连接的图标代表的意义。
- 普通的 HTTP 连接：
- 安全的 HTTPS 连接：
- 带黄色三角号警告的安全 HTTPS 连接：
- 存在风险的带红叉 HTTPS 连接：
上面这四种图标很容易理解。前两种一个是非加密的 HTTP 连接，一个是加密了的 HTTPS 连接。
后两种都是 HTTPS 连接，但是因为 Mixed Content 或证书设置问题，存在潜在的安全隐患。
带黄色三角的表示在 HTTPS 页面里混入了 HTTP 连接的图片或 CSS 资源。带来的潜在安全隐患就是：
- 这些图片或 CSS 可以被中间人篡改影响网站的外观。
- 经过非 HTTPS 连接发送的 Cookie 可能被获取。
而带红 X 图标的问题就大了，说明可能是 HTTPS 页面里混入了 HTTP 连接的 Javascript 资源。潜在的安全隐患就是：
- 通过 HTTP 传输的 Javascript 可能受到中间人攻击，JS 内容被篡改之后在页面执行，获取用户输入的敏感信息。
- 同样，经过 HTTP 连接发送的 Cookie 可以被获取。
顺便说一下，关于 cookie 从 HTTP 链接泄露问题，解决办法是使用Secure Cookie。
Mixed Content 问题
从上面可以得出结论，即使网站使用了 HTTPS 协议，也未必安全。常见的错误就是出现 Mixed Content 问题。简单的说，就是一个 HTTPS 页面里即存在 HTTP 资源又存在 HTTPS 资源。当然，如果 HTTP 资源是图片或 CSS 危险会小一点，因为受浏览器安全策略影响，即使 CSS 或图片被攻击者篡改了，也做不了什么特别危险的动作，而 Javascript 就不一样了。
想要避免 Mixed Content，就是需要把整个页面内容都使用 HTTPS 连接。所以现在云存储或第三方服务都提供 HTTPS 连接。不提高的说明已经落伍了。
如何调试 HTTPS 问题
一般通过浏览器上面的图标就可以看出网站是否有 Mixed Content 问题。但是，即使网站显示绿锁图标也不能证明它不存在 Mixed Content。这是因为一些高级浏览器会有Minxed Content Blocking功能，比如 Chrome 和 Firefox 23。
这里有一个例子，其实是很严重的 Mixed Content 漏洞，但是由于浏览器给那个 JS 屏蔽掉了，浏览器就没有显示红 X，而这段 JS 却没有被加载：https://code.csdn.net/CSDN_Code/code_support/issues/451
所以 Chrome Console 是神器，只需要在控制台看 warning 就可以，把被 blocked 和 insecure 的换成 HTTPS 连接。
How Github Remove Yellow Warning
我们知道 Github 是全站 HTTPS 的，但是 Github 还有一个特性是允许用户通过 Markdown 语法插入站外图片。如果插入的站外图片是 HTTP 的，那么在这个页面上就是会显示 Mixed Content 警告：
为了移除这个黄色的 warning，他们做了一个图片代理。把用户输入的图片地址替换，然后抓取到自己的 HTTPS 服务器上…具体的技术细节请看下面的几个连接：
- https://github.com/blog/743-sidejack-prevention-phase-3-ssl-proxied-assets
- https://github.com/atmos/camo
- https://github.com/jch/html-pipeline/blob/master/lib/html/pipeline/camo_filter.rb#L9-L11
相关链接
- https://blog.mozilla.org/tanvi/2013/04/10/mixed-content-blocking-enabled-in-firefox-23/
- https://en.wikipedia.org/wiki/HTTP_cookie#Secure_cookie
- https://github.com/jch/html-pipeline/blob/master/lib/html/pipeline/camo_filter.rb#L9-L11
- https://github.com/atmos/camo
- https://github.com/blog/743-sidejack-prevention-phase-3-ssl-proxied-assets
- https://support.google.com/chrome/answer/95617?p=ui_security_indicator&rd=1
- https://37signals.com/svn/posts/1431-mixed-content-warning-how-i-loathe-thee
- http://www.acunote.com/blog/2008/07/why-you-should-use-cache-control-public-for-caching-to-work-with-ssl.html
- https://code.csdn.net/CSDN_Code/code_support/issues/451
- http://lifehacker.com/5743975/why-does-chrome-think-gmail-is-insecure
- https://developer.mozilla.org/en-US/docs/Security/MixedContent
- https://support.mozilla.org/en-US/kb/how-do-i-tell-if-my-connection-is-secure
- https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
- http://www.douban.com/people/Hoooopo/status/1173447062/
怎么感觉内容还没写完的？:bowtie: 比如「加快 SSL 加解密速度」这些 http://blog.gslin.org/archives/2013/01/28/3161/%E5%8A%A0%E5%BF%AB-ssl-%E5%8A%A0%E8%A7%A3%E5%AF%86%E9%80%9F%E5%BA%A6/
#6 楼 @luikore 他是把用户作为外链的图片抓到他们的 https://a248.e.akamai.net 静态资源服务器上，这样没有任何问题啊。。是 真 ·安全。
你以为开了 HTTPS 就安全了 ?
随便干掉一个 CA，就可以伪造证书了，这种事情又不是没发生过。
即便 CA 是安全的，大部分浏览器还在用 TLS/1.0，因为 CBC 等把 block cipher 拼成 stream cipher 的方法以及 TLS 协议的缺陷，容易被 BEAST 类攻击轻松搞定，特别是有 WebSocket 等配合的情况下。升级到 TLS/1.2 协议才得以避免。
RC4 用于 HTTP 协议就更加悲剧了。
TLS 层开启压缩，容易被 CRIME 类攻击轻松搞定。SPDY 还默认启用压缩呢。
TLS renegotiation 也是一大安全隐患，各种问题层出不穷，比如 http://haxsys.net/tls.pptx
还有，RSA/ECC 以及 DH 等都是等着被量子算法攻击的。
MD5 已经被攻破，SHA-1 也存在问题。你的 Digest 算法，升级到 SHA-2/SHA-3 了么？
同时，密码学算法实现不当，容易被计时攻击，或者被同一宿主机上的另一个虚拟机攻击。
另外，你保证你的熵值够了么 ...
这些都还只是公开了的安全隐患。NSA 手上，黑市里不知道有多少重大问题不为外界所知呢。
在 NSA 面前，你完全就是透明的。老大哥知道你的一切。根本就不需要入侵。只需要搞定几个交换机把流量复制一份就可以了，你的加密就和没加一个样。
nosniff 解决的是挂羊头卖狗肉问题，但没解决挂羊头卖毒羊肉问题. 在 github 和 http / https 证书非认证 的外站之间，还是能有中间人的空子。
不过图片资源的隐患已经很小了，或许是浏览器多虑了...
“软件是不可避免有漏洞的，处于不断修补和升级的过程”这应该是常识吧。MD5 不行了就会有 SHA 什么的替代。TLS1.0 有问题了就有升级版..不能因为这个否定 HTTPS..
