细读HTTPS -- 白话TLS

细读HTTPS – 白话TLS

前面三篇文章是阅读《HTTPS权威指南 在服务器和WEB应用上部署SSL》这本书的笔记，不过由于翻译不是太好，很多地方难以理解。经过多次阅读以及网上查阅资料终于弄懂了一些原理和概念。下面用自己的话来重新描述下SSL中的原理以及SSL握手过程中用到了哪些东西。

什么是对称加密？

• 所谓对称加密就是指加密过程和解密过程都是使用的相同的秘钥。举例说明：你将你的手机设置了一个开机密码，这个设置密码的过程就类似于加密，然后你下次开手机，需要输入相同的密码解开手机，这就是解密，加密和解密使用的是同一个密码就是对称加密。
• 对称加密有好多种加密模式：ECB、CBC、CFB、OFB，CTR和GCM，其具体解释可参见博客：对称加密算法的几种模式优缺点一览
• 对称加密对应有很多种算法：DES、3DES（TripleDES）、AES、RC2、RC4、RC5和Blowfish，具体可参照博客：对称加密算法DES、3DES和AES

什么是非对称加密？

所谓非对称加密就是指加密过程和解密过程使用不同的秘钥，其中一个是公钥，对外发布，另一个是私钥，自己留着。如果你利用某人的公钥加密数据，那么只有他们对应的私钥能够解密。从另一个方面讲，如果某人用私钥加密数据，任何人都可以利用对应的公钥解开消息。
常见的非对称加密算法：RSA，Diffie-Hellman（DH），elliptic curve Diffie-Hellman（ECDH）

什么是MAC ？

消息认证码（Message authentication code）是一种确认完整性并进行认证的一种技术，简称MAC。

• 为啥需要MAC？
  一般在网络中传输文件或者传输消息，接收方如何知道接收到的数据有没有部分缺失呢 ？我们当前最常用的算法如MD5.

  1. 将这个文件的内容通过一定的算法获取一个哈希值，然后将这个文件或者消息和这个哈希值A一起传输出去.
  2. 接收方收到消息内容和哈希值A,使用相同的算法计算消息内容得出另一个哈希值B，再来比较哈希值A和哈希值B，相等则接收到的消息是完整的，不相等则接收到的数据有丢失或者篡改。
     但是如果攻击者同时截获消息内容和哈希值，虽然说消息内容可以加密，但是攻击者可以破坏消息内容再算出一个哈希值出来，然后将破坏后的消息和哈希值传到接收方，此时的接收方完全不知道自己被骗了.
     因此MAC可以改善上述情况.

• 为啥MAC能保证传输的完整性 ？
  使用 MAC 验证消息完整性的具体过程是：

  1. 假设通信双方 A 和 B 共享密钥 K，A用消息认证码算法将 K 和消息 M 计算出消息验证码 Mac
  2. 然后将 Mac 和 M 一起发送给 B。
  3. B 接收到 Mac 和 M 后，利用 M 和 K 计算出新的验证码 Mac*，若 Mac*和Mac 相等则验证成功，证明消息未被篡改。

  由于攻击者没有密钥 K，攻击者修改了消息内容后无法计算出相应的消息验证码，因此 B 就能够发现消息完整性遭到破坏。
  常见的MAC实现有：HMAC，CBC-MAC，OMAC等。

什么是数字签名？

使用非对称加密算法得出一对秘钥，一个公钥，一个私钥。然后用私钥将信件的摘要进行加密，生成的密文叫做数字签名。
数字签名潜在的危险是如果接收者的公钥被攻击者替换，替换成自己公钥，然后攻击者用自己私钥进行数字签名，从而攻击者就可以伪造信息发给接收者，但接受者仍可解密数字签名，但不知发来的信件是伪造的。

什么是CA？

certification authority（CA）是指公认的权威机构，具备一定的安全级别，能够严格保护自己私钥的公司。

什么证书?

证书是一个包含公钥、订阅人相关信息以及证书颁发者数字签名的数字文件，也就是一个让我们可以交换、存储和使用公钥的壳。
一般证书是由权威的CA机构颁发，CA会制作出一对秘钥，用CA自己的私钥加密证书内容的摘要：公钥，订阅人，颁发人等信息，形成签名，这样证书就制作好了。
举例：假设百度要使用SSL对百度的网络流量传输进行安全保护，这时李彦宏就得找到一家权威的CA机构A公司(有公钥KA1，私钥KA2)，向这家机构付费，然后CA就用百度要求的算法计算出一对秘钥：公钥K1，私钥K2，然后A公司自己的私钥KA2制作数字签名，制作出证书:

证书使用者：百度
证书颁发者：A公司
证书有效期：2019~~2030
公钥:xxx
证书签名算法：SHA256
证书指纹提取算法：SHA1
证书数字签名：2048 bit密文

再然后将证书和私钥K2给到李彦宏，李彦宏就把证书和秘钥K2都装百度的服务器上。
此时百度的用户在打开百度的网页的时候，百度服务器会首先将百度服务器的证书发给用户的浏览器，
浏览器会在系统内置的公钥列表中查找是否有A公司的公钥KA1
如果有，首先用证书中的公钥解开数字签名得到证书的摘要，再用证书中指定的算法计算出实际接收的证书内容摘要，然后如果两个摘要相同，则表明证书是完整的。
如果找不到，则尝试获取A公司的证书，再从A公司证书的颁发者的公钥是否在内置公钥列表中，一直向上找…直到找到A公司所属机构的根公钥，一般注明CA机构的跟公钥在各大操作系统中都有内置。
如果到最后都找不到，则弹出警告信息给用户，提示该网站可能不安全…

什么是证书链？

一般一个CA下面还有很多授权机构，CA下的授权机构还有很多分支，这些分支最终会给各个网站企业制定证书。从而形成一种树形结构。
CA自己的一对秘钥叫根秘钥：根公钥和根私钥,由于各大操作系统信任CA有足够的安全能力去保护自己的私钥，并能合法的去审查各种网站的申请资料，所以各大操作系统就将其根公钥内置在操作系统内部。
CA再来授权其二级机构，其二级机构再授权其他节点，然后再授权end-user。从而形成信任链。

SSL验证服务器握手具体干了什么 ？

1.ClientHello
SSL的连接每次都是由客户端发起.ClientHello发送的内容主要是：SSL的版本，加密套件的列表，压缩算法列表，随机数。

2. ServerHello
返回服务器的选择结构：使用协议的版本号，加密套件，压缩算法，随机数。

从上述信息看，服务器选择了密码套件：TLS_ECDHE_RAS_WITH_AES_128GCM_SHA256，压缩算法是NULL。
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
ECDHE:表示用椭圆曲线Diffie-Hellman算法用于数据加密的对称秘钥的交换，即生成用于对称加密的秘钥。
RSA：表示用RSA算法进行身份认证，即得出非对称加密的公钥和私钥的的算法，其中私钥用于生成数字签名和解密。
AES_128_GCM：使用GCM模式使用AES算法进行通信数据加密。
SHA256：用于生成MAC的算法和用于生成主密钥的算法。
下面的握手过程就以此密码套件来展开说明。
3. Certificate
由于服务器选择的是TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256密码套件，所以在当前步骤中发送给客户端的证书中的公钥和用于生成数字签名的私钥是由RSA算法而得出的。此步骤中也可能是发送的一个证书链.。
4. ServerKeyExchange
在使用ECDHE算法做秘钥交互后，在此步骤中服务器发送ECDHE算法的服务器参数：

	struct {
	ECParameters curve_params;
	ECPoint public;
	} ServerECDHParams;
	
	struct {
	ECCurveType curve_type;
	select (curve_type) {
	case explicit_prime:
		/* 为了清晰，略去 */
	case explicit_char2:
		/* 为了清晰，略去 */
	case named_curve:
		NamedCurve namedcurve;
	};
	} ECParameters;

5. ServerHelloDone
ServerHelloDone消息表明服务器已经将所有预计的握手消息发送完毕。在此之后，服务器会等待客户端发送消息。
6. ClientKeyExchange
客户端提交自己的ECDHE算法公开参数。

	struct {
	select (PublicValueEncoding) {
		case implicit:
			/* 空的 */
		case explicit:
			ECPoint ecdh_Yc;
		} ecdh_public;
	} ClientECDiffieHellmanPublic;

7. ChangeCipherSpec
此消息从客户端发送至服务端时，客户端向服务端说:你给的参数我已经收到了，并且应ECDHE算法生成了后面数据加密的对称加密秘钥。并且将切换到加密模式。
8. Finished
此消息中带有前面握手信息的哈希值，客户端向服务端说：我这边握手完成了，你看看这些哈希值，看看你收到的消息有没有错误。
9. ChangeCipherSpec
此消息从服务端发送至客户端时，服务端向客户端说:你给的参数我已经收到了，并且应ECDHE算法生成了后面数据加密的对称加密秘钥。并且将切换到加密模式。
10. Finished
此消息中带有前面握手信息的哈希值，服务端向客户端说：我这边握手完成了，你看看这些哈希值，看看你收到的消息有没有错误。

什么是自签名证书？

从上面握手的过程来看，服务器的证书是CA机构用自己的私钥给服务器证书制作数字签名，浏览器用CA机构的公开的公钥（一般浏览器都有内置）解密数字签名从而验证证书的正确性，从而确认服务器不是钓鱼服务器，是自己想访问的正确服务器。
因为CA机构每年的证书年费较高，所以有些小型网站就会弄一个自签名证书，用来自己证明自己是OK的。
所谓自签名证书，就是自己把自己当成一个CA机构，先搞出一对根秘钥，再搞出另一对秘钥，然后用根私钥进行生成证书的数字签名，根私钥自己保护好，根公钥在自己的网站公开，然后通知自己的用户到自己的网站来下载根公钥，手动装到自己的浏览器中。从而进行客户端对服务器的验证。

为什么CA付费签名证书才是安全的？

假设有一个攻击者处于“浏览器”和“网站服务器”的通讯线路之间，并且这个攻击者具备“修改双方传输数据”的能力。那么，这个攻击者就可以攻破没有身份认证的非对称加密方案。具体的攻击过程如下：

• 第1步
  服务器先随机生成一个“非对称的密钥对”k1 和 k2（此时只有网站知道 k1 和 k2）
• 第2步
  当网站发送 k2 给浏览器的时候，攻击者截获 k2，保留在自己手上。然后攻击者自己生成一个【伪造的】密钥对（以下称为 pk1 和 pk2）。攻击者把 pk2 发送给浏览器。
• 第3步
  浏览器收到 pk2，以为 pk2 就是网站发送的。浏览器不知情，依旧随机生成一个对称加密的密钥 k，然后用 pk2 加密 k，得到密文的 k’。
  浏览器把 k’ 发送给网站。（以下是关键）
  发送的过程中，再次被攻击者截获。
  因为 pk1 pk2 都是攻击者自己生成的，所以攻击者自然就可以用 pk1 来解密 k’ 得到 k。然后，攻击者拿到 k 之后，用之前截获的 k2 重新加密，得到 k’’，并把 k’’ 发送给网站。
• 第4步
  网站服务器收到了 k’’ 之后，用自己保存的 k1 可以正常解密，所以网站方面不会起疑心。至此，攻击者完成了一次漂亮的偷梁换柱，而且让双方都没有起疑心。
  上述过程，也就是传说中大名鼎鼎的中间人攻击。英文叫做“Man-In-The-Middle attack”。缩写是 MITM。拿到了对称加密的秘钥了，整个加密过程就形同虚设，数据会被攻击者轻松破解。

其中造成中间人攻击的最大漏洞在于浏览器和网站之间缺乏公证人，即每人能证明服务器是不是假的。
CA就是这个公证人，这也是为什么CA收费贵，还有人用他的服务。