HTTPS原理解析

HTTPS

一些概念

http

概述

HTTP是一个客户端(用户)和服务端(网站)之间请求和应答的标准,通常使用TCP协议。其本身位于TCP/IP协议族的应用层。

特点

  - 客户端&服务器
  - 无连接
  - 无状态

密码学

  • 对称秘钥算法

加密和解密时使用相同的密钥,或是使用两个可以简单地相互推算的密钥,常见算法有:AES、DES、SM4。

  • 非对称秘钥算法

需要两个密钥,一个是公开密钥,另一个是私有密钥;公钥用于加密,私钥则用作解密。使用公钥把明文加密后所得的密文,只能用相对应的私钥才能解密并得到原本的明文。公钥可以公开,可任意向外发布;私钥不可以公开。基于公开密钥加密的特性,它还能提供数字签名的功能,使电子文件可以得到如同在纸本文件上亲笔签署的效果。常见非对称算法有:RSA、DSA、SM2。

  • 散列算法

是一种从任何一种数据中创建小的数字“指纹”的方法。散列函数把消息或数据压缩成摘要,使得数据量变小,将数据的格式固定下来。该函数将数据打乱混合,重新创建一个叫做散列值的指纹。常见算法有:MD5、SHA-256、SM3

SSL&TLS

百科给出的解释是:传输层安全性协议(Transport Layer Security)及其前身安全套接层(Secure Sockets Layer)是一种安全协议,目的是为互联网通信提供安全及数据完整性保障。网景公司在1994年推出HTTPS协议,以SSL进行加密,这是SSL的起源。IETF将SSL进行标准化后即TLS。目前SSL/TLS已成为互联网上保密通信的工业标准。

https

HTTP over SSL/TLS,HTTPS经由HTTP进行通信,但利用SSL/TLS来加密数据包。HTTPS开发的主要目的,是提供对网站服务器的身份认证,保护交换资料的隐私与完整性。

HTTPS机制

证书制作的过程

一个网站如果要使用https,第一步就是找CA机构申请证书。简要流程如下

  1. 申请人服务器server,生成一对非对称秘钥server_prikey、server_pubkey
  1. 申请人把一些申请信息(使用者、有效期等)sever_info和server_pubkey递交给CA机构
  1. CA机构验证申请人身份后,对server_info+server_pubkey+ca_info(ca机构添加的一些信息)进行散列运算,得到server_hash
  1. CA机构使用自己的私钥ca_prikey 对server_hash进行签名,得到sign_server_hash
  1. CA机构根据sign_server_hash+server_pubkey+server_info+ca_info构建成证书server_cert,并下发给申请人
  1. 申请人配置证书到服务器server,一般情况下会开启443端口对外提供https的能力。

一些特殊的行业,处于多方面的顾虑,可能会搭建自己的CA服务,例如:各大银行、12306、硬件设备制造商等。目前国际上比较知名CA机构的根证书(CA的公钥)是预装在操作系统或浏览器的,如下图。
 
  现实中,网站的证书验证多数是通过证书链的机制实现的,操作系统预装的证书也都是证书链最上层的根证书,而我们申请到的证书,也多是二级证书机构颁发的。

http三次握手

以访问百度为例,查看三次握手的抓包数据,其中110.242.68.3是百度服务器地址,10.100.172.90是我本机的局域网地址(客户端)。
1、客户端发送syn:

2、服务器响应syn+ack

3、客户端发送ack

流程如下(网络取图):

TLS的多次握手

仍旧以访问百度为例,查看https访问时,TLS的多次握手
2.1、客户端发送 client hello

        - Content Type: Handshake (22) 
           - 0x16表示内容类型为握手协议
        - Version: TLS 1.0 (0x0301)
           - 使用TLS1.0
        - Random: 777cd47f33acca3e39c74b2aac641fc1b5bc7c64ff5436d944281495d38899a7
           - 随机数,4字节时间戳+28字节随机数,可以防重放
        - Session ID: d14d21a0d37f4987c087d2fca80c2beca15dd93d3c90c69fe30b1fb4870fa84f
           - sessionId,0-32字节随机数
        - Cipher Suites (18 suites)
           - 客户端支持的密码套件算法列表(优先级顺序)
        - Extension
           - 扩展信息

2.2、服务器响应 server hello

        - Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (0xc02f)
           - 服务器根据客户端秘钥算法列表协商的秘钥
              - TLS 通讯协议类型
              - ECDHE 交换秘钥算法
              - RSA 身份验证算法,一般为证书使用的算法
              - AES 通信时的加密算法
              - HSA256 哈希算法,计算签名使用

** 2.3服务器下发公钥证书**
        

        - Certificates (3749 bytes)
           - 下发给客户端的证书,一般情况下如上图有两个证书,一个是根认证机构颁发给二级机构的证书,一个是二级认证机构颁发给百度的证书

2.4服务器下发交换秘钥参数、协商秘钥的公钥(非必须,使用ECDHE交换秘钥算法时需下发参数)

        - Named Curve: secp256r1 (0x0017)
           - 指定非对称秘钥算法的椭圆曲线
        - Pubkey: 
           - 公钥
        - Signature Algorithm: rsa_pkcs1_sha256 (0x0401)
           - 签名算法
        - Signature: 
           - 签名

2.5服务端响应结束,因为有一些不确定响应,需要最后回复一次客户端响应完毕。

在服务器响应结束前还有可能还有一次Certificate Request请求,用于请求客户端公钥证书,适用用高安全性场景下的双向认证。
3、客户端请求,这一部分协议差异比较大,在TLS1.3中规定该步骤为最后一步,无需TLS1.2后续确认响应,但是百度使用的TLS1.2,也没有后续的确认操作了。

        - EC Diffie-Hellman Client Params
           - 协商秘钥客户端参数
        - Change Cipher Spec Message
           - 告知后续使用密文传输
        - Handshake Protocol: Encrypted Handshake Message
           - 密文,如果服务器能顺利解密则协商成功

4.1、服务器创建session ticket

        - Session Ticket: 
           - 服务的生成的session ticket,session ticket包含sessionId和协商的加密参数以便连接重用。

4.2 服务端告知密文传输

**

        - Change Cipher Spec Message
           - 告知客户端以后使用加密通讯

4.3 服务器发送密文数据

        - Handshake Protocol: Encrypted Handshake Message
           - 使用协商秘钥加密后的密文数据

至此,tls整个协商过程结束

https总结

  1. http syn握手建立tcp连接

  2. 客户端开始tls握手

  3. 服务端开始tls握手,并下发证书供客户端认证服务器身份

  4. 客户端和服务端通过秘钥交换算法交换秘钥

  5. 通过协商秘钥安全协商出对称秘钥key

  6. 后续双方使用key加密传输的数据

  7. 服务端创建session ticket,用于保持和恢复连接
    最后附上完整交互图,摘自网络,大致相同,待后续补充

相关推荐

发表评论

路人甲

网友评论(0)