HTTPS总结
2017-07-07 本文已影响62人
奋斗的蜗牛
一、HTTPS简介
916156-20160512201524859-1729519516.png
- HTTPS（Hypertext Transfer Protocol Secure）：超文本传输安全协议，是对HTTP进行了TLS或SSL加密。
- HTTP的URL由
http://起始，默认端口为80，HTTPS的URL由https://起始，默认端口为443。 - HTTPS报文中的任何东西都被加密，包括所有报头和荷载。这样攻击者就获取不到有用的信息。
- 应用层的HTTP协议通过传输层的TCP协议来传输，HTTPS 在 HTTP和 TCP中间加了一层TLS/SSL加密层。
- HTTP是明文传输，而现在HTTPS把明文加密后 再给TCP传输。
二、HTTPS实现的简化版
- HTTPS在三次握手的时候用非对称加密生成 一个密钥，后面的数据通信就用这个密钥进行对称加密通信。这样既做到了安全性，又避免了非对称加密的效率问题。
- 有的时候我们需要做接口的安全性，如果用非对称加密是最安全的，但是效率比较低，如果用对称加密 安全性又不是很好。所以 也可以自己 简单模拟HTTPS来进行通信。
比如APP接口设计，我们用对称加密进行通信，如果对称加密的密钥放到APP中，是不安全的，可以用逆向工程拿到，如果用HTTPS的接口获取密钥，其实HTTPS里的内容也可以被解密，这个和客户端的代码也有关系（比如iOS最常用的AFNetWorking就存在过漏洞），所以我们可以这么做：
APP请求接口，第一次先用非对称加密 请求接口 XXX/getAESSecretKey 来获取密钥（字符串）。
剩下的请求都根据这个密钥来进行对称加密 通信。
上面两步就是简化版的HTTPS通信。 - 真正的HTTPS通信要比这个麻烦，我们刚才举例的密钥是事先定好的，而HTTPS是通过 三次握手 中每次都生成一次随机数，也就是客户端生成2次随机数，服务端生成1次随机数，并且服务端确定加密方法，然后客户端和服务端根据定好的加密规则，各自把这三个随机数生成同样的“对话密钥”，这个“对话密钥”就是后面数据通信用的 对称加密的 密钥。
这样每个客户端也 都有不同的 对称加密密钥。
三、对称加密和非对称加密
3.1、概念
- 对称加密：文件加密和解密使用相同的密钥
- 非对称加密：需要两个密钥：公开密钥（publickey）和私有密钥（privatekey）。
用公钥对数据进行加密，只有用对应的私钥才能解密；如果用私钥对数据进行加密，那么只有用对应的公钥才能解密。
公钥 :用于向外发布，任何人都能获取。
私钥 :要自己保存，切勿给别人，一般只有运维的人才知道。
3.2、算法
- 对称加密常用的算法：DES、3DES、TDEA、Blowfish、RC2、RC4、RC5、IDEA、SKIPJACK、AES等。
- 非对称加密常用的算法： RSA，ECDHE，DH，DHE、Elgamal、背包算法、Rabin、等。
3.3、能否被破解
- RSA加密：还没人声称以破解。世纪金融体系就是靠着1RSA加密建立的，破解了这个，就可以伪造整个金融体系。
- AES加密：标准的128位AES是10轮的。现在针对7轮的AES已经破解了，家用机几分钟就能搞定。破解标准的10轮，家用电脑，还不足以短时间内破解。。大型机已经可以算是破解了128位的，所以现在最低也要求256位的AES。
四、TLS
4.1、TLS历程：
- 1994年，NetScape公司设计了SSL协议（Secure Sockets Layer）的1.0版，但是未发布。
- 1995年，NetScape公司发布SSL 2.0版，很快发现有严重漏洞。
- 1996年，SSL 3.0版问世，得到大规模应用。
- 1999年，互联网标准化组织ISOC接替NetScape公司，发布了SSL的升级版TLS 1.0版。
- 2006年，升级到TLS 1.1版
- 2008年，升级到TLS 1.2版
- 2011年，TLS 1.2的修订版
- 目前，应用最广泛的是TLS 1.0，然后是SSL 3.0。但是，主流浏览器都已经实现了TLS 1.2的支持。
- TLS 1.0也可以标示为SSL 3.1，TLS 1.1为SSL 3.2，TLS 1.2为SSL 3.3。
- 前一段时间苹果对HTTPS支持的要求里面就要求为TLS1.2版本。
4.2、SSL/TLS协议的基本过程概要
- 客户端发送请求给服务器，请求包含客户端生成的一个随机数和客户端版本信息。
- 服务端回复给客户端，包括服务器证书、服务端生成的一个随机数、确定加密算法。
- 客户端验证服务器证书，生成一个随机数并用公钥加密，编码信息等。
- 客户端和服务端通过上面三个随机数，按照第二步确定的加密方法，生成各自的"会话密钥"，"会话密钥"就是对称加密的密钥。
总结：
- 服务端发送给客户端之前商定的编码信息，双方采用"对话密钥"进行对称加密通信。
- 因为公钥放在数字证书中，只要证书是可信的，公钥就是可信的，这样就能保证公钥不被篡改。
- 双方协商生成"对话密钥"。"对话密钥"是对称加密，所以运算速度非常快，而服务器公钥只用于加密"对话密钥"本身，这样就减少了加密运算的消耗时间。
- 前两个都在握手（明文通信）阶段完成的。
五、证书
刚才我们提到通信中要用到证书，公钥就在证书里面。证书还包括域名、公司信息、序列号和签名信息等。
证书分为自签名证书和 CA 证书。
- 自签名证书，可以自己生成，但是 容易被假冒和伪造、容易受到SSL中间人攻击、证书有效期太长、法被吊销(如果你的私钥被黑客获取，证书不能被吊销，则黑客可以伪装成你与用户进行通信)。
- CA：数字证书认证机构
Certificate Authority
任何个体/组织都可以扮演 CA 的角色，只不过难以得到客户端的信任，能够受浏览器默认信任的 CA 大厂商有很多，其中 TOP5 是 Symantec、Comodo、Godaddy、GolbalSign 和 Digicert。
需要花钱购买，比如淘宝用的是GlobalSign 的。
六、SSL单向认证和双向认证
- 双向认证：需要服务端与客户端都提供证书，只能是服务端允许的客户能去访问，安全性相对于要高一些。客户端需要安装证书。
- 单向认证：只要求站点部署了ssl证书就行，任何用户都可以去访问(IP被限制除外等)，只是服务端提供了身份认证。一般的网站都是单向认证。
七、其他
- 因为前段时间苹果要求HTTPS的规则里 要求用
ECDH_RSA和ECDHE_ECDSA算法，所以这里简单说下。
上面说过ECDHE 是非对称加密算法的一种。
RSA：算法实现简单，诞生于 1977 年，安全性高。缺点就是需要比较大的素数(目前常用的是 2048 位)来保证安全强度，很消耗 CPU 运算资源。RSA 是目前唯一一个既能用于密钥交换又能用于证书签名的算法。
DH：diffie-hellman 密钥交换算法，诞生于1977 年，但是 1999 年才公开。缺点是比较消耗 CPU 性能。
ECDHE：使用椭圆曲线(ECC)的 DH 算法，优点是能用较小的素数(256 位)实现 RSA 相同的安全等级。缺点是算法实现复杂，用于密钥交换的历史不长，有的客户端不支持。
ECDH：不支持 PFS，安全性低，同时无法实现 false start。
DHE：不支持 ECC。非常消耗 CPU 资源。
建议优先支持 RSA 和 ECDH_RSA 密钥交换算法。原因是：
ECDHE 支持 ECC 加速，计算速度更快。支持 PFS，更加安全。支持 false start，用户访问速度更快。
目前还有至少 20% 以上的客户端不支持 ECDHE，我们推荐使用 RSA 而不是 DH 或者 DHE，因为 DH 系列算法非常消耗 CPU(相当于要做两次 RSA 计算)。
另外，DSA和ECDSA（椭圆曲线签名算法）都只是签名算法，它用来确保信息发布人的身份和信息的完整性，不能用来做加密传输 - 因为HTTPS连接所用的公钥以明文传输，因此中国的防火长城可以对特定网站按照匹配的黑名单证书，通过伪装成对方向连接两端的计算机发送RST包干扰两台计算机间正常的TCP通讯，以打断与特定IP地址之间的443端口握手，或者直接使握手的数据包丢弃，导致握手失败，从而导致TLS连接失败。这也是一种互联网信息审查和屏蔽的技术手段。
