多应用+插件架构,代码干净,二开方便,首家独创一键云编译技术,文档视频完善,免费商用码云13.8K 广告
https协议由 http + ssl 协议构成,具体的链接过程可参考[SSL或TLS握手的概述](https://github.com/lvwxx/blog/issues/3) ## SSL或TLS握手的概述 SSL或TLS握手建立了用于客户端和服务端通信的秘钥。 客户端和服务端SSL或TLS能够相互通信的基本步骤: * 确认使用协议的版本 * 选择加密算法 * 通过交换和验证数字证书对彼此进行身份验证 * 使用非对称加密技术生成共享密钥,避免了密钥分发问题。然后SSL或TLS使用共享密钥对消息进行对称加密解密,这比非对称加密更快 综上所述SSL握手的步骤如下: 1. SSL或TLS客户端先向服务端发送一个加密通信请求,叫做ClientHello请求。该请求包含以下信息: * 客户端支持的SSL或者TLS版本 * 客户端生成的随机数,用于生成后续通信的随机字符串("对话密钥") * 客户端支持的加密算法 2. SSL或TLS服务端收到客户端请求后,向客户端发出响应,叫做ServerHello。该响应包含以下信息: * 服务端从客户端提供的SSL或TLS列表中选择的版本 * Sesstion ID 和 另外生成的随机数 * 服务端的数字证书(如果服务端需要用于客户端身份验证的数字证书,则服务端发送一个客户端证书请求,其中包含受支持的证书类型列表和可接受的认证机构(CAs)的专有名称。) * 确认使用的加密算法 3. 客户端收到服务端响应后,首先校验服务端发来的数字证书决定是否继续通信。 4. 证书校验通过,会像服务端发送以下信息: * 生成一个随机数,并对这个随机数用从服务端数字证书中取出的公钥加密(用与生成后续通信的“随机密钥”) 5. 如果服务端发送了一个客户端证书请求,客户端将会发送一个用客户端私钥加密的随机字符串和客户端的数字证书,或者没有数字证书的警告。在某些强制客户端证书的实现中,如果客户端没有数字证书,则握手会失败 6. 服务端接受并验证客户端证书 7. 客户端向服务端发送一条完成的消息,该消息使用密钥加密,表示握手的客户端部分已经完成。 8. 服务端向客户端发送一条完成的消息,该消息使用密钥加密,表示握手的服务端部分已经完成 9. 在SSL或TLS会话期间,服务端和客户端现在可以交换使用共享密钥对称加密的消息 ## 中间人攻击过程如下: 1. 服务器向客户端发送公钥。 2. 攻击者截获公钥,保留在自己手上。 3. 然后攻击者自己生成一个【伪造的】公钥,发给客户端。 4. 客户端收到伪造的公钥后,生成加密hash值发给服务器。 5. 攻击者获得加密hash值,用自己的私钥解密获得真秘钥。 6. 同时生成假的加密hash值,发给服务器。 7. 服务器用私钥解密获得假秘钥。 8. 服务器用加秘钥加密传输信息 ## 防范方法: **服务端在发送浏览器的公钥中加入CA证书,浏览器可以验证CA证书的有效性** * 制作证书:作为服务端的A,首先把自己的公钥key1发给证书颁发机构,向证书颁发机构进行申请证书;证书颁发机构有一套自己的公私钥,CA通过自己的私钥来加密key1,并且通过服务端网址等信息生成一个证书签名,证书签名同样使用机构的私钥进行加密;制作完成后,机构将证书发给A; * 校验证书真伪:当B向服务端A发起请求通信的时候,A不再直接返回自己的公钥,而是返回一个证书; 说明:各大浏览器和操作系统已经维护了所有的权威证书机构的名称和公钥。B只需要知道是哪个权威机构发的证书,使用对应的机构公钥,就可以解密出证书签名;接下来,B使用同样的规则,生成自己的证书签名,如果两个签名是一致的,说明证书是有效的; 签名验证成功后,B就可以再次利用机构的公钥,解密出A的公钥key1;接下来的操作,就是和之前一样的流程了; * 中间人是否会拦截发送假证书到B呢? 因为证书的签名是由服务器端网址等信息生成的,并且通过第三方机构的私钥加密中间人无法篡改; 所以最关键的问题是证书签名的真伪; ## 摘自 [ 第 91 题:介绍下 HTTPS 中间人攻击](https://www.muyiy.cn/question/network/91.html)