在HTTPS项目的开展过程中明显感觉到目前国内互联网对HTTPS并不是很重视，其实也就是对用户隐私和网络安全不重视。本文从保护用户隐私的角度出发，简单描述现在存在的用户隐私泄露和流量劫持现象，然后进一步说明为什么HTTPS能够保护用户安全以及HTTPS使用过程中需要注意的地方。
国外很多网站包括google,facebook,twitter都支持了全站HTTPS，而国内目前还没有一家大型网站全站支持HTTPS（PC端的微信全部使用了HTTPS，但是PC端用户应该不多）。甚至一些大型网站明显存在很多HTTPS使用不规范或者过时的地方。比如支付宝使用的是tls1.0和RC4,而京东()竟然还使用着SSL3.0这个早就不安全并且性能低下的协议，其他很多网站的HTTPS登陆页面也存在着不安全的HTTP链接，这个也为黑客提供了可乘之机。
由于篇幅关系，文中几乎没有详细描述任何细节，后面有时间我再一一整理成博客发表出来。同时由于水平有限，本文肯定存在很多错误，希望大家不吝赐教。本文的大部分内容都能从互联网上搜索到，有些地方我也标明了引用，可以直接跳转过去。但是全文都是在我自己理解的基础上结合开发部署过程中的一些经验和测试数据一个字一个字敲出来的，最后决定将它们分享出来的原因是希望能和大家多多交流，抛砖引玉，共同推进中国互联网的HTTPS发展。
本文不会科普介绍HTTPS、TLS及PKI，如果遇到一些基本概念文中只是提及而没有描述，请大家自行百度和google。本文重点是想告诉大家HTTPS没有想像中难用可怕，只是没有经过优化。
中国互联网全站使用HTTPS的时代已经到来。
1，用户隐私泄露的风险很大
人们的生活现在已经越来越离不开互联网，不管是社交、购物还是搜索，互联网都能带给人们很多的便捷。与此同时，用户“裸露”在互联网的信息也越来越多，另一个问题也日益严重，那就是隐私和安全。
几乎所有的互联网公司都存在用户隐私泄露和流量劫持的风险。BAT树大招风，这方面的问题尤其严重。比如用户在百度搜索一个关键词，“人流”，很快就会有医院打电话过来推销人流手术广告，不知情的用户还以为是百度出卖了他的手机号和搜索信息。同样地，用户在淘宝搜索的关键词也很容易被第三方截获并私下通过电话或者其他广告形式骚扰用户。而QQ和微信呢，显然用户不希望自己的聊天内容被其他人轻易知道。为什么BAT不可能出卖用户隐私信息给第三方呢？因为保护用户隐私是任何一个想要长期发展的互联网公司的安身立命之本，如果用户发现使用一个公司的产品存在严重的隐私泄露问题，显然不会再信任该公司的产品，最终该公司也会因为用户大量流失而陷入危机。所以任何一家大型互联网公司都不可能因为短期利益而出卖甚至忽视用户隐私。
那既然互联网公司都知道用户隐私的重要性，是不是用户隐私就得到了很好的保护呢？现实却并不尽如人意。由于目前的WEB应用和网站绝大部分是基于HTTP协议，国内没有任何一家大型互联网公司采用全站HTTPS方案来保护用户隐私（排除支付和登陆相关的网站或者页面以及PC端的微信）。因为HTTP协议简单方便，易于部署，并且设计之初也没有考虑安全性，所有内容都是明文传输，也就为现在的安全问题埋下了隐患。用户在基于HTTP协议的WEB应用上的传输内容都可以被中间者轻易查看和修改。
比如你在百度搜索了一个关键词“https“，中间者通过tcpdump或者wireshark等工具就很容易知道发送请求的全部内容。wireshark的截图如下：
这里所谓的中间者是指网络传输内容需要经过的网络节点，既有硬件也有软件，比如中间代理服务器、路由器、小区WIFI热点、公司统一网关出口等。这里面最容易拿到用户内容的就是各种通信服务运营商和二级网络带宽提供商。而最有可能被第三方黑客动手脚的就是离用户相对较近的节点。
中间者为什么要查看或者修改用户真实请求内容呢？很简单，为了利益。常见的几种危害比较大的中间内容劫持形式如下：
获取无线用户的手机号和搜索内容并私下通过电话广告骚扰用户。为什么能够获取用户手机号？呵呵，因为跟运营商有合作。
获取用户帐号cookie，盗取帐号有用信息。
在用户目的网站返回的内容里添加第三方内容，比如广告、钓鱼链接、植入木马等。
总结来讲，由于HTTP明文传输，同时中间内容劫持的利益巨大，所以用户隐私泄露的风险非常高。
2，HTTPS能有效保护用户隐私
HTTPS就等于HTTP加上TLS（SSL)，HTTPS协议的目标主要有三个：
数据保密性。保证内容在传输过程中不会被第三方查看到。就像快递员传递包裹时都进行了封装，别人无法知道里面装了什么东西。
数据完整性。及时发现被第三方篡改的传输内容。就像快递员虽然不知道包裹里装了什么东西，但他有可能中途掉包，数据完整性就是指如果被掉包，我们能轻松发现并拒收。
身份校验。保证数据到达用户期望的目的地。就像我们邮寄包裹时，虽然是一个封装好的未掉包的包裹，但必须确定这个包裹不会送错地方。
通俗地描述上述三个目标就是封装加密，防篡改掉包，防止身份冒充，那TLS是如何做到上述三点的呢？我分别简述一下。
2.1 数据保密性
2.1.1 非对称加密及密钥交换
数据的保密性主要是通过加密完成的。加密算法一般分为两种，一种是非对称加密（也叫公钥加密），另外一种是对称加密（也叫密钥加密）。所谓非对称加密就是指加密和解密使用的密钥不一样，如下图：
HTTPS使用非对称加解密主要有两个作用，一个是密钥协商，另外可以用来做数字签名。所谓密钥协商简单说就是根据双方各自的信息计算得出双方传输内容时对称加解密需要使用的密钥。
公钥加密过程一般都是服务器掌握私钥，客户端掌握公钥，私钥用来解密，公钥用来加密。公钥可以发放给任何人知道，但是私钥只有服务器掌握，所以公钥加解密非常安全。当然这个安全性必须建立在公钥长度足够大的基础上，目前公钥最低安全长度也需要达到2048位。大的CA也不再支持2048位以下的企业级证书申请。因为1024位及以下的公钥长度已经不再安全，可以被高性能计算机比如量子计算机强行破解。计算性能基本会随着公钥的长度而呈2的指数级下降。
既然如此为什么还需要对称加密？为什么不一直使用非对称加密算法来完成全部的加解密过程？主要是两点：
非对称加解密对性能的消耗非常大，一次完全TLS握手，密钥交换时的非对称解密计算量占整个握手过程的95%。而对称加密的计算量只相当于非对称加密的0.1%，如果应用层数据也使用非对称加解密，性能开销太大，无法承受。
非对称加密算法对加密内容的长度有限制，不能超过公钥长度。比如现在常用的公钥长度是2048位，意味着待加密内容不能超过256个字节。
目前常用的非对称加密算法是RSA，想强调一点的就是RSA是整个PKI体系及加解密领域里最重要的算法。如果想深入理解HTTPS的各个方面，RSA是必需要掌握的知识点。它的原理主要依赖于三点：
乘法的不可逆特性。即我们很容易由两个乘数求出它们的积，但是给定一个乘积，很难求出它是由哪两个乘数因子相乘得出的。
欧拉函数。欧拉函数.varphi(n)是小于或等于n的正整数中与n互质的数的数目
费马小定理。假如a是一个整数，p是一个质数，那么a^p - a 是p的倍数。
RSA算法是第一个也是目前唯一一个既能用于密钥交换又能用于数字签名的算法。另外一个非常重要的密钥协商算法是diffie-hellman(DH).DH不需要预先知道通信双方的信息就能完成密钥的协商，它使用一个素数P的整数乘法群以及原根G，理论依据就是离散对数。
openssl目前只支持如下密钥交换算法：RSA，DH，ECDH, DHE，ECDHE。各个算法的性能和对速度的影响可以参考后面章节，由于篇幅有限，具体实现不再做详细介绍。
2.1.2 对称加密
对称加密就是加密和解密都使用的是同一个密钥。如下图：
采用非对称密码算法的密钥协商过程结束之后就已经得出了本次会话需要使用的对称密钥。对称加密又分为两种模式：流式加密和分组加密。流式加密现在常用的就是RC4，不过RC4已经不再安全，微软也建议网站尽量不要使用RC4流式加密。支付宝可能没有意识到这一点，也可能是由于其他原因，他们仍然在使用RC4算法和TLS1.0协议。
一种新的替代RC4的流式加密算法叫ChaCha20，它是google推出的速度更快，更安全的加密算法。目前已经被android和chrome采用，也编译进了google的开源openssl分支---boring ssl，并且nginx 1.7.4也支持编译boringssl。我目前还没有比较这种算法的性能，但部分资料显示这个算法对性能的消耗比较小，特别是移动端提升比较明显。?
分组加密以前常用的模式是AES-CBC，但是CBC已经被证明容易遭受BEAST和LUCKY13攻击。目前建议使用的分组加密模式是AES-GCM，不过它的缺点是计算量大，性能和电量消耗都比较高，不适用于移动电话和平板电脑。尽管如此，它仍然是我们的优先选择。
2.2 数据完整性??
这部分内容相对比较简单，openssl现在使用的完整性校验算法有两种：MD5或者SHA。由于MD5在实际应用中存在冲突的可能性比较大，所以尽量别采用MD5来验证内容一致性。SHA也不能使用SHA0和SHA１，中国山东大学的王小云教授在2005年就牛逼地宣布破解了SHA-1完整版算法。建议使用SHA２算法，即输出的摘要长度超过224位。
2.3 身份验证和授权
这里主要介绍的就是PKI和数字证书。数字证书有两个作用：