1. HTTP缺点
- 通信使用明文，可能被窃听
- 无法证明报文的完整性，有可能遭遇篡改
- 不验证通信方的身份，可能遭遇伪装。
所以，信息传输的安全包括三个方面
- 客户端和服务器直接的通信只有自己能看懂，即使第三方拿到数据也看不懂这些信息的真实含义。
- 第三方虽然看不懂数据，但可以 XJB 改，因此客户端和服务器必须有能力判断数据是否被修改过。
- 客户端必须避免中间人攻击，即除了真正的服务器，任何第三方都无法冒充服务器
2. 如何不被窃听：加密
2.1 使用对称加密技术
HTTP引入对称加密后，HTTPS 的握手流程就会多了两步，用来传递对称加密的秘钥:
客户端: 你好，我需要发起一个 HTTPS 请求
服务器: 好的，你的秘钥是 1。
服务器直接返回明文的对称加密密钥是不是不安全。如果有监听者拿到这个密钥，不就知道客户端和服务器后续的通信内容了么？
2.2 如何交换密钥：非对称加密
这里我们引入非对称加密的方式，非对称加密的特性决定了服务器用私钥加密的内容并不是真正的加密，因为公钥所有人都有，所以服务器的密文能被所有人解析。但私钥只掌握在服务器手上，这就带来了两个巨大的优势:
服务器下发的内容不可能被伪造，因为别人都没有私钥，所以无法加密。强行加密的后果是客户端用公钥无法解开。
任何人用公钥加密的内容都是绝对安全的，因为私钥只有服务器有，也就是只有真正的服务器可以看到被加密的原文。
所以传输对称秘钥的问题就迎刃而解了:
密钥不是由服务器下发，而是由客户端生成并且主动告诉服务器。
所以当引入非对称加密后，HTTPS 的握手流程依然是两步，不过细节略有变化:
客户端: 你好，我需要发起一个 HTTPS 请求，这是我的 (用公钥加密后的) 秘钥。
服务器: 好的，我知道你的秘钥了，后续就用它传输。
2.3 那公钥怎么传输： 数字证书
2.3.1 服务器直接只下发公钥的的安全问题
RSA算法无法确保服务器身份的合法性，因为公钥并不包含服务器的信息，存在安全隐患:
2.3.2 数字证书：公钥的身份证
每一个服务器自己生成或到权威机构申请一个数字证书（公钥的身份证），
CA权威机构：能保证自身不受攻击（或者别人不敢攻击），就像现实生活中的公安局。
证书 = 公钥 + 申请者与颁发者信息 + 签名 + 有效期+ .....
CA证书的申请
每一个使用 HTTPS 的服务器都必须去专门的证书机构(CA)注册一个证书，证书中存储了用权威机构私钥加密的公钥。这样客户端用权威机构的公钥解密就可以了。
自签名证书的生成
此处略去1万字。。。。。
3.如何校验身份：证书校验
- 首先需要校验证书可信任的合法证书？？
- 其次需要校验证书有没有被篡改？
- 最后校验证书是不是自己服务器？
3.1 CA证书
1. 系统默认校验：
客户端没有预埋锚点证书，就和浏览器一样，只校验在系统的信任机构列表的根证书，去验证服务端返回的证书。
此刻应该意识到：根证书是整个证书体系安全的根本。所以，如果某个证书体系中，根证书出了问题（不再可信了），那么所有被根证书所信任的其它证书，也就不再可信了。这个后果是相当相当滴严重（简直可以说是灾难性的）。
这也是中间人攻击的一个入口。所以如果不小心安装过非权威机构的根证书，比如客户端链接恶意的 Wi-Fi等情况下装上恶意证书，这时候设备上就多了一个预设的公钥，那么用恶意私钥加密的证书就能被正常解析出来。所以千万不要随便装根证书，这等于是为那些恶意证书留了一扇门。
2. 证书校验：客服端需要有预埋证书的拷贝。
公钥校验：不校验域名和有效期等，只要公钥是正确的，就能保证通信不会被窃听，因为中间人没有私钥，无法解开通过公钥加密的数据。
锚点证书校验：设置本地为锚点证书，假如验证的数字证书是这个锚点证书的子节点，即验证的数字证书是由锚点证书对应CA或子CA签发的，或是该证书本身，则信任该证书。从服务器端证书链的根节点往下遍历，看看是否有与客户端的绑定证书一致的，有的话，就说明服务器端是可信的。
3.2 自定义CA证书
确认证书就是由自己服务器下发的呢？
必须预埋证书
签名校验
domain Validation、有效期校验
公钥校验或锚点证书校验
3.3 怎么知道证书有没有被篡改？？
A: 将信息 hash 值随着信息一起传递
为了确保原始证书没有被篡改，我们可以在传递证书的同时传递证书的哈希值。 由于第三者无法解析数据，只能修改 数据，修改后的数据就不可能通过哈希。
虽然公钥已知，每个人都可以解密，解密完也可以篡改，但是因为没有私钥， 所以无法正确的加密。所以它再返回给客户端的数据是无效数据，用公钥解析后会得到乱码。即使攻击者通过多次尝试碰巧能够解析，也无法通过哈希校验。
4. 如何防止数据篡改
4.1 HMAC
为了防止黑客通过彩虹表根据哈希值反推原始数据，在计算哈希的时候，不能仅针对原始输入计算，需要增加一个key来使得相同的输入也能得到不同的哈希，这样，大大增加了黑客破解的难度。
4.2 数字签名
MAC 虽好，但是遇到和对称密码同样的问题：密钥如何交换。
其中一个解决方式就是数字签名，这个“签名”你基本可以想象成现实生活中的手写签名，具有类似的作用。
原理上和非对称加密有点像，但有个很大的区别，发送方是用私钥进行签名，而接收方用公钥进行验签
当然，正如前面所讲，也可以进行身份校验。
5. HTTPS
TLS/SSL的基本工作方式是:
客户端使用非对称加密与服务器进行通信，实现身份验证并协商对称加密使用的密钥， 然后对称加密算法采用协商密钥对信息以及信息摘要进行加密通信，不同的节点之间采用的对称密钥不同，从而可以保证信息只能通信双方获取。
5.1 SSL握手
- 握手阶段分成五步。
- 第一步，Client给出协议版本号、一个客户端生成的随机数（Client random），以及客户端支持的加密方法。
- 第二步，Server确认双方使用的加密方法，并给出数字证书、以及一个服务器生成的随机数（Server random）。
- 第三步，Client确认数字证书有效，然后生成一个新的随机数（Premaster secret），并使用数字证书中的公钥，加密这个随机数，发给Server。
- 第四步，Server使用自己的私钥，获取Client发来的随机数（即Premaster secret）。
- 第五步，Client和Server根据约定的加密方法，使用前面的三个随机数，生成"对话密钥"（session key），用来加密接下来的整个对话过程。
SSL/TSL包括四次握手，主要交换三个信息：
- 数字证书；
- 三个随机数；
- 加密通讯协议。
5.2对称密钥：三个随机数
这三个随机数构成了后续通信过程中用来对数据进行对称加密解密的“对话密钥”。
首先客户端先发第一个随机数n1，然后服务器返回第二个随机数n2（这个过程同时把数字证书发给客户端），这两个随机数都是明文的；
而第三个随机数n3，客户端用数字证书的公钥进行非对称加密，发给服务器；
而服务器用只有自己知道的私钥来解密，获取第三个随机数。服
务端和客户端都有了三个随机数n1+n2+n3后，两端就使用这三个随机数来生成“对话密钥”，在此之后的通信就使用这个“对话密钥”来进行对称加解密。
6 参考
1. 图解SSL/TLS协议
