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总结
http syn握手建立tcp连接
客户端开始tls握手
服务端开始tls握手,并下发证书供客户端认证服务器身份
客户端和服务端通过秘钥交换算法交换秘钥
通过协商秘钥安全协商出对称秘钥key
后续双方使用key加密传输的数据
服务端创建session ticket,用于保持和恢复连接
最后附上完整交互图,摘自网络,大致相同,待后续补充