我们知道，http请求在网络中明文传输的，毫无隐私可言。以前经常遇到打开某个知名门户网站，右下角居然跳出联通的小广告。因为http的不保密性，运营商可以肆意地窥看信息，篡改响应内容，比如给自己打个广告什么的。当然，随着时代的进步，必然会出现遏制恶势力的救世主，怎么个救法呢？且听我娓娓道来。
怎么保证我的内容不被运营商修改？加密呗，加了密他肯定看不懂了吧。不过问题来了，我这加了密，运营商看不懂，客户也看不懂啊。一定的想办法把解密的方法告诉客户才行。可是我要把解密方法发给客户还得经过运营商，那不是白扯。
问题很严重，难道没办法了？显然不可能，不然我也不会在这里逼逼叨了。
这时候我们有请第一位英雄出场：非对称加密
你可能会问，什么是非对称加密？别急，他还有一位兄弟你肯定认识：对称加密。什么，也不认识？好吧。简单解释一下你肯定明白了：一把锁配一把钥匙，上锁开锁都必须使用这同一把钥匙，你要是用锁把门锁了，用这把钥匙就可以开门。这不是废话么。这其实就是对称加密，一个锁和唯一的一把钥匙对称。缺点显而易见，隔壁老王偷偷拿了你的钥匙多磨了一把，以后岂不是随意进你家门了。说完他兄弟，我们还是回到非对称加密，什么是非对称加密呢？举个栗子：
你去河边捡了个鹅卵石，一怒之下将其摔成了两半。好了，在这世界上你找不出第三块石头能和它俩任意一个完美契合的了。如果有人用左半边石头加密了一串文本，有且只有另一半石头能解开这个密码。你只要保管好右半边的石头，任何人用左半边加密的内容都可以被你解开，再也不用担心左半边石头丢失的问题了。这就是著名的RSA非对称加密算法，基于大数的因式分解数学难题，也是应用最广泛的非对称加密算法。
人们把左、右半边石头分别称为公钥和私钥，那么解决运营商劫持问题可以这样：
- 客户A发起请求
- 服务器B收到请求，生成自己的公钥和密钥，将公钥返回给客户A
- 客户A收到返回的公钥，使用这个公钥对自己要发送的内容加密，发送给服务器B
- 服务器B收到加密后的内容，使用之前生成的私钥解密，得到内容
- 服务器B使用自己的私钥加密响应体，返回给客户A
- 客户A收到服务器B的响应，使用之前的公钥对其解密，得到内容
是不是很完美？
当然不是。看似网络中传输的内容都已经加密了啊，并且私钥也没有暴露出去，有啥问题呢？
一个很大的隐患就是，假设这个运营商特别狡猾，当服务器B返回公钥给客户A的时候，偷偷将这个公钥劫持，自己再造一份公钥和密钥，将这个假的公钥发给客户，与客户建立连接。这就是经典的中间人攻击。
那怎么解决呢，有请我们的第二位英雄出场：数字证书
数字证书是由权威的CA机构颁发给服务商的一种身份证明，标识某个公钥是可以信任的，有了这个标识，我们的改良方案就成了这样：
- 网站B，先去一个认证认证机构（CA），提供自己的网站信息和公钥，生成一个数字证书下放到网站B上。这个证书上有CA的签名，签名是通过签名算法和上级CA的私钥生成的。
- 用户A访问网站B，首先会收到网站B发来的数字证书
- 浏览器需要对这个数字证书的真实性进行校验(因为证书有可能被篡改)
- 如果验证通过，用户A从数字证书中取出网站B的公钥，用这个公钥将一个对称加密的key加密，发送给网站B。
- 网站B收到这个加密的key，用自己的私钥解密出来，然后后续双方所有的通信内容就会基于这个对称加密的key来加解密了
其中就有一个很大的问题，浏览器如何验证我们的证书没有被篡改过呢？
这就需要用到 数字签名 ，签名生成过程如下：
- 使用某一种哈希算法，对证书中的信息（供应商、过期时间、网站公钥等）计算出一个哈希值
- CA使用自己的私钥对这个哈希值加密，得到数字签名
浏览器在拿到一个签名后，首先使用同样的哈希算法对证书内容进行求值，得到一个哈希值，然后用这个CA的公钥（权威机构的公钥通常已经被预先安装到了系统里），对签名解密，得到另一个哈希值。
如果这两个哈希值相等，则这个数字证书没有被篡改过。
中间人因为得不到CA的私钥，所以即便篡改了信息也没法加密。
对称加密和非对称加密
这世上存在两种加密算法：对称加密(symmetric cryptography)和非对称加密(asymmetric cryptography)。
- 对称加密：对称加密算法的特点是加密使用的密钥和解密使用的密钥是相同的。好比一把锁，上锁和开锁使用的是同一把钥匙。
- 非对称加密：在非对称加密算法中，有公钥和私钥两种密钥，其中，公钥是公开的，不需要保密，私钥由个人持有，必须妥善保管和注意保密。加密和解密使用两种不同的密钥，是它得名的原因。估计大家都听说过RSA，这就是一种常见的，应用很广的非对称加密算法。
常见的加密算法：
| 对称加密 | 非对称加密 | 信息摘要 |
|---|---|---|
| AES(128) DES(64) Blowfish(64) CAST(64) IDEA(64) RC2(64) RC5(64) | DH RSA DSA EC | MD2 MD5 MDC2 SHA RIPEMD DSS |
SSL/TLS
什么是SSL？全称是：Secure Sockets Layer，一种协议，定义了用来对网络发出数据的进行加密解密的格式和规则。
TLS（Transport Layer Security）和SSL类似，可以将其与SSL视为同一东西的不同阶段。
SSL/TLS协议的基本思路是采用公钥加密法，也就是说，客户端先向服务器端索要公钥，然后用公钥加密信息，服务器收到密文后，用自己的私钥解密。
如何保证公钥不被篡改？
解决方法：将公钥放在数字证书中。只要证书是可信的，公钥就是可信的。
公钥加密计算量太大，如何减少耗用的时间？
解决方法：每一次对话（session），客户端和服务器端都生成一个”对话密钥”（session key），用它来加密信息。由于”对话密钥”是对称加密，所以运算速度非常快，而服务器公钥只用于加密”对话密钥”本身，这样就减少了加密运算的消耗时间。
因此，SSL/TLS协议的基本过程是这样的：
- 客户端向服务器端索要并验证公钥。
- 双方协商生成”对话密钥”。
- 双方采用”对话密钥”进行加密通信。
上面过程的前两步，又称为”握手阶段”（handshake）
HTTPS
http是一种应用层通信协议，SSL/TLS是一种用在传输层的加密协议，于是两者一拍即合，出于安全通信的目的，http配合SSL/TLS就成为了HTTPS。
OpenSSL
什么是OpenSSL？它是在程序上对SSL标准的一个实现，提供了：
- libcrypto通用加密库
- libssl TLS/SSL的实现
- openssl命令行工具
SSH
一个使用了OpenSSL加密的通信工具，提供了很多安全功能。
CA
(certificate authority)证书管理机构
数字证书
可以这么理解，数字证书是一个网站的身份证，当网站的响应返回时会携带这个身份证，告诉客户端其身份
比如：X.509v3证书由三部分组成：
- tbsCertificate (to be signed certificate)，待签名证书。
- SignatureAlgorithm，签名算法。
- SignatureValue，签名值。
tbsCertificate又包含10项内容，在HTTPS握手过程中以明文方式传输：
- Version Number，版本号。
- Serial Number，序列号。
- Signature Algorithm ID，签名算法ID。
- Issuer Name，发行者。
- Validity period，有效时间。
- Subject name ，证书主体名称。
- Subject Public Key Info ，证书主体公钥信息，包含公钥算法和公钥值。
- Issuer Unique Identifier (optional)，发行商唯一ID。
- Subject Unique Identifier (optional)，主体唯一ID。
- Extensions (optional)，扩展。
消息摘要（message digest）
函数是一种用于判断数据完整性的算法，也称为散列函数或哈希函数，函数返回的值叫散列值，散列值又称为消息摘要或者指纹（fingerprint）。这种算法是一个不可逆的算法，因此你没法通过消息摘要反向推倒出消息是什么。所以它也称为单向散列函数。下载软件时如何确定是官方提供的完整版呢，如果有中间人在软件里面嵌入了病毒，你也不得而知。所以我们可以使用散列函数对消息进行运算，生成散列值，通常软件提供方会同时提供软件的下载地址和软件的散列值，用户把软件下载后在本地用相同的散列算法计算出散列值，与官方提供的散列值对比，如果相同，说明该软件是完成的，否则就是被人修改过了。常用的散列算法有MD5、SHA。
消息认证码（MAC，Message Authentication Code）
使用 MAC 验证消息完整性的具体过程是：假设通信双方 A 和 B 共享密钥 K，A用消息认证码算法将 K 和消息 M 计算出消息验证码 Mac，然后将 Mac 和 M 一起发送给 B。B 接收到 Mac 和 M 后，利用 M 和 K 计算出新的验证码 Mac，若 Mac和Mac 相等则验证成功，证明消息未被篡改。由于攻击者没有密钥 K，攻击者修改了消息内容后无法计算出相应的消息验证码，因此 B 就能够发现消息完整性遭到破坏。