从https设计过程了解原理

我们知道https是HTTP over SSL/TSL，知道一部分SSL的知识和HTTP网络连接的知识，现在我们来深入了解下https的连接过程，企图打通计网和密码学之间的联系~

HTTP+加密+认证+完整性保护=HTTPS

HTTPS与HTTP - 图1
https = http over ssl； 即先进行http通信之前，client和server会进行ssl握手；关键在于ssl握手之后如何就让通信变得加密了的

1、https使用混合加密体制(对称加密+非对称加密)

  • 对称加密加密速度快
    • 弊端：由于共享一对密钥(加密解密使用相同密钥)，存在安全隐患只要拿到密钥即可破解密文，即存在密钥分发难题
  • 非对称密钥使用两把钥匙，公钥和私钥，发送方使用公钥加密，公钥是公开的，接收方只需使用自己保管的私钥进行解密（也只有特定的私钥才能实现解密）
    • 弊端：速度慢
  • 混合加密体制:
    • 使用非对称密码加密和保护会话密钥解决密钥分发难题，使用会话密钥对称加密通信信息

解释一下，直接使用对称加密不就行了？为啥还要引入一层非对称加密？
image.png server->client是一对多
server和client通信时是各自使用不同的对称密钥就行了
这样通话2的密钥也不能破解通话1的信息

那么就需要，在建立链接的时候，对当次通话进行 加密密钥的协商
服务器端怎么告诉客户端该使用哪种对称加密算法问题，但是在协商的过程中，又没有加密。（鸡生蛋蛋生鸡的问题

如何对协商过程加密？
密码学领域中，有一种称为“非对称加密”的加密算法，特点是私钥加密后的密文，公钥才能解密，但是公钥加密后的密文，只有私钥可以解密。私钥只有一个人有，而公钥可以发给所有的人。
image.png
所以这就是混合加密体制的由来：使用非对称密码加密和保护会话密钥解决密钥分发难题，使用会话密钥对称加密通信信息

2、协商什么加密算法
要达到Web服务器针对每个客户端使用不同的对称加密算法，同时，也不能让第三者知道这个对称加密算法是什么，该怎么解决？

使用随机数来生成对称加密算法。这样就可以做到服务器和客户端每次交互都是新的加密算法、只有在交互的那一刻才确定加密算法。

3、server如何将公钥如何安全分发给客户端？如何应对公钥被篡改的问题？
1、让客户端的浏览器默认保存所有网站公钥可行与否？ ===> 不现实。每年那么多新增https网站
2、服务器直接将公钥发送给客户端 ===> 如何应对中间人掉包
image.png
2、像dns查询那样，公钥放在一个证书链里，client拿到当前网站的公钥，去证书链上一一比对(网站名->公钥)可行吗？慢

3、第三方机构的引入
不能直接将服务器的公钥传递给客户端，而是第三方机构使用它的私钥对我们的公钥进行加密后，再传给客户端。
客户端再使用第三方机构的公钥进行解密。
如果中间人此时使用自己的私钥加密后的东西传给客户端，客户端是无法使用第三方机构的公钥进行解密的；
_
这个第三方机构就是 数字证书认证机构（CA，Certificate Authority）

4、数字签名的引入

但是但是，万一中间人也去第三方机构申请证书了呢？
同时给client发经过ca加密过公钥的证书，client怎么分辨是中间人的，还是server的？ *( ′д)/o( _)ozzZZ…**
image.png

是的，刚刚提的问题是存在的，中间人有意冒充的话，不论中间人，还是server的证书，都能使用第三方机构的公钥进行解密

即持有和server同一家第三方机构证书的中间人，还是可以掉包的：
image.png

所以，就迎来了 数字签名的引入。数字签名可以解决**同一机构办的不同证书被篡改**的问题。
证书应该放到客户端，客户端拿到证书后应该可以分辨证书是否被篡改了，如何才能具有这个辨别能力？

想想我们公司入职时是如何验证学历的？
1、拿学历证书，给hr
2、hr将学历证书上的编号，输入学信网。如果编号能找到，且编号对应的名字和证书上的名字相同，学历为真；

只是，client这里，将验证server给的编号 这一步不是寻求远程的第三方，而是本地验证。使用了数学算法；
1、server：给client的证书上写着如何根据证书的内容生成证书编号
2、client：拿到证书后根据证书上的方法自己生成一个证书编号，如果生成的证书编号与证书上的证书编号相同，那么说明这个证书是真实的。

为避免证书编号本身又被调包，所以使用第三方的私钥进行加密

看看密码学里认证问题的原型：

image.png
●Hash函数输入明文消息，输出定长值，用发送方的私钥将该hash码加密。
●发送消息+加密后的hash码
●接收方收到之后，使用发送方的公钥对hash码进行解密，得hash1
●同时使用相同的hash函数对明文消息进行加密得hash2，比较hash1和hash2，若值相等则认证成功
（因为只有发送方有私钥，即只有发送方可以产生有效的签名）

这里引入了第三方机构，验证第三方机构的签名是否有效
1、server上的证书编码：第三方机构颁发的， 约定编号生成方法选用的hash算法是如md5，md5(xx网站的公钥)得到定长值，然后第三方机构的私钥加密生成的证书编码hash1（定长值）
2、client：拿到证书，证书上有xx网的公钥、md5算法、已加密后的证书编码hash1。通过一样的方式生成hash2，并比对 拿第三方机构的公钥解密hash1得到的证书编码即可。

image.pngimage.png

这样解决了server公钥可信度的问题
那第三方机构公钥的可信呢？
client与第三方机构：浏览器和操作系统都会维护一个权威的第三方机构列表（包括它们的公钥）。因为客户端接收到的证书中会写有颁发机构，客户端就根据这个颁发机构的值在本地找相应的公钥
server与第三方机构：去专门的机构网站申请，配好了之后就可以在ssl握手的时候发给client了。

以上讨论了 如何安全的分发公钥，验证公钥的问题
下面还有：
1、client的私钥怎么来的？
===> 根据公钥+随机数生成私钥 （通过非对称加密算法，可以根据公钥得到独一无二的私钥，但是私钥反向求公钥却不行）
2、对称加密的会话密钥怎么来的？
选择了对称加密算法，如DES+随机数，client生成会话密钥，使用私钥(会话密钥)， 传给server端。两者协商完成

言简意赅版总结

1、client -> server: 我支持的加密方式
浏览器支持的加密算法组合：生成hash的、生成对称密钥的、非对称加密私钥的

2、server -> client: 确定加密方式 + 返回证书

确定的加密算法：密钥交换加密方式为RSA（非对称）、数据传输加密方式为AES（对称加密）、检验数据是否合法的算法为SHA256

server会返回一个证书，证书上写了 支持的对称加密的算法，数字签名，网站公钥

3、client：浏览器验证 公钥 是否可信

  • 验证证书是否可信：沿着浏览器本地的证书链，可查验证书的真实性
  • 浏览器通过验证签名真实性从而确定网站公钥的真实性：
    • 对收到的证书进行hash得到hash1
    • 使用证书(第三方机构)的公钥解密证书上附着的数字签名，得到hash2
    • 比对hash1和hash2，如果相同则证书没被篡改，网站公钥可信

4、client：生成私钥、随机密钥
使用私钥加密 随机密钥 发给server，达到密钥共享；
由达成一致的随机密钥按照生成各自的 会话密钥用于 对称加密通话。

5、握手结束，使用 会话密钥加密通话；

实际的例子会复杂一点，会有更多次的随机数，以及一个修改密钥的约定啥的。
反正大致原理就是上面说的。具体细节为了安全性会加入更多的混淆，可不必细究。

名词对应：
证书就是HTTPS中数字证书，证书编号就是数字签名，而第三方机构就是指数字证书签发机构（CA）。

2-从实例中理解

以访问淘宝为例：
首先是建立TCP连接不说了，从clienthello说起

2.1 clientHello

客户端向服务器发送的信息：

  • TLS版本

  • 客户端当前的时间和一个随机密码串

  • sessionId，会话ID

  • 浏览器支持的加密组合方式

  • 域名（在传输层里面就把域名信息告诉服务器，好让服务根据域名发送相应的证书）

HTTPS与HTTP - 图10

HTTPS与HTTP - 图11

2.2 serverHello

服务器回应：

  • 时间、随机数、Session Id

  • 服务器选中的加密方式

HTTPS与HTTP - 图12

2.3 Certificate证书

服务器向客户端发送自己证书，其中证书可根据证书链让浏览器确认证书的真实性，沿着证书链可在找到根部证书，而根部证书即为浏览器内置的，通过层层委托的方式传递信任。
证书信息：

  • 申请的国家、省份、城市、组织名称

  • 证书支持的域名

  • 证书的有效期

  • 证书的公钥

其中证书的公钥：

  1. String publicKey = "3082010a0282010100c70e6c3f23937fcc70a59d20c30e533f7ec04ec29849ca47d523ef03348574c8a3022e465c0b7dc9889d4f8bf0f89c6c8c5535dbbff2b3eafbe356e74a46d91322ca36d59bc1a8e3964393f20cbce6f9e6e899c86348787f5736691a191d5ad1d47dc29cd47fe18012ae7aea88ea57d8ca0a0a3a1249a262197a0d24f737ebb473927b05239b12b5ceeb29dfa41402b901a5d4a69c436488def87efee3f51ee5fedca3a8e46631d94c25e918b9895909aee99d1c6d370f4a1e352028e2afd4218b01c445ad6e2b63ab926b610a4d20ed73ba7ccefe16b5db9f80f0d68b6cd908794a4f7865da92bcbe35f9b3c4f927804eff9652e60220e10773e95d2bbdb2f10203010001";

publicKey = (N, e) RSA算法
同时服务器使用了私钥对子证书进行签名，用于客户端验证证书是否被修改，将签名及子证书一并发给客户端

HTTPS与HTTP - 图13

客户端（浏览器）对签名进行验证的过程：

  • 对收到的子证书进行SHA-256得到hash1

  • 使用证书的公钥对子证书签名进行解密，得到hash2

  • 比较hash1与hash2，如果相同则证书没有被篡改

2.4 密钥交换Key Exchange

服务器根据客户端发送的加密组合中选择了Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
这一串加密方式可以分成三部分：

HTTPS与HTTP - 图14

  • 服务器选中的密钥交换加密方式为RSA（非对称）

  • 数据传输加密方式为AES（对称加密）

  • 检验数据是否合法的算法为SHA256

服务器在密钥交换中发送公钥：

HTTPS与HTTP - 图15
密钥交换的目的是为了双方共享密钥，使用同一把密钥进行加密和解密。密钥交换的方式有两种RSA和ECDHE，RSA的方式比较简单，浏览器生成一把密钥，然后使用证书RSA的公钥进行加密发给服务端，服务再使用它的密钥进行解密得到密钥，这样就能够共享密钥了

2.5 修改密码簇

双方交换密钥之后，客户端发送改变密码规范消息change_cipher_spec message并向当前CipherSpec中复制，挂起CipherSpec（使用修改密码规范协议发送而不是握手协议）

HTTPS与HTTP - 图16
于是客户端立即使用新的算法、密钥和密码发送新的完成消息finised_message。完成消息对密钥交换和认证过程的正确性进行验证。
服务器应答这两个消息时，发送自己的修改密码规范，并向当前CipherSpec复制挂起，发送完成信息。
此时握手完成，客户端和服务端即可开始交换应用层数据

修改密码规范协议简介：

  • 作用：

    • 该消息的唯一作用就是使未决状态复制为当前状态，更新用于当前连接的密码组。为了保障SSL传输过程的安全性，双方应该每隔一段时间改变加密规范。

  • 组成：

    • SSL修改密文协议的报文由值为1的单一字节组成，协议蔟中最简单的协议

  • 设计目的：

    • SSL修改密文协议的设计目的是为了保障SSL传输过程的安全性，因为SSL协议客户端要求或服务器端每隔一段时间必须改变其加解密参数。当某一方要改变其加解密参数时，就发送一个简单的消息通知对方下一个要传送的数据将采用新的加解密参数，也就是要求对方改变原来的安全参数。

3-Why Https？

思考这几个方面：

  • https的引入===》http有什么问题

  • https解决了什么问题，在此基础上他还有什么好处

3.1 HTTP的缺点

HTTP 主要有这些不足，例举如下

  • 通信使用明文（不加密），内容可能会被窃听

    • 如果仅对内容进行加密，内容仍有被篡改的风险，且加密处理后的报文信息本身仍会被暴露，

    • ===》而SSL是将整个通信线路加密处理

  • 不验证通信方的身份，因此有可能遭遇伪装

    • HTTP 协议的实现本身非常简单，不论是谁发送过来的请求都会返回响应，因此不确认通信方，会存在以下各种隐患

      • 无法确定请求发送至目标的 Web 服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的 Web 服务器

      • 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端

      • 无法确定正在通信的对方是否具备访问权限。因为某些 Web 服务器上保存着重要的信息，只想发给特定用户通信的权限

      • 无法判定请求是来自何方、出自谁手

      • 即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS 攻击（Denial of Service，拒绝服务攻击）

    • ===》而SSL使用了一种被称为证书的手段，可用于确定通信方。通过使用证书，以证明通信方就是意料中的服务器，客户端持有证书即可完成个人身份的确认，也可用于对 Web 网站的认证环节。

  • 无法证明报文的完整性，所以有可能已遭篡改

    • 没有任何办法确认，发出的请求 / 响应和接收到的请求 / 响应是前后相同的

    • 也有一些 HTTP 协议确定报文完整性的方法，如 MD5 等散列值校验的方法。弊端一来得用户亲自去动手校验（中国估计只有 0.1% 不到的用户懂得怎么做吧），二来如果网站提供的 MD5 值也被改写的话呢

    • 请求或响应在传输途中，遭攻击者拦截并篡改内容的攻击称为中间人攻击（Man-in-the-Middle attack，MITM）

    • ===》SSL 提供认证和加密处理及摘要功能

3.2 HTTPS的优与缺

HTTPS好处：

HTTPS = HTTP + 加密 + 认证 + 完整性保护
1.通信加密（基于通道加密，防范中间人攻击和内容窃听）
当使用HTTPS时，如下通信元素是加密处理的：

  • 请求文档的url

  • 文档内容

  • 浏览器格式内容

  • 在浏览器和服务器之间的Cookies

  • HTTP报头内容

2.身份认证（仿冒服务器/客户端）
3.完整性保护
**
HTTPS的弊端：

  • 通信慢

    • 它和 HTTP 相比，网络负载会变慢 2 到 100倍。除去和 TCP 连接、发送 HTTP 请求及响应外，还必须进行 SSL 通信，因此整体上处理通信量会不可避免的增加。

  • SSL 必须进行加密处理

    • 在服务器和客户端都需要进行加密和解密的去处处理。所以它比 HTTP 会更多地消耗服务器和客户端的硬件资源。

参考资料