HTTPS原理解析
本文最后更新于 739 天前,其中的信息可能已经有所发展或是发生改变。

HTTP是什么

超文本传输协议(英文:HyperText Transfer Protocol,缩写:HTTP)是互联网上应用最为广泛的一种网络协议。是一个基于请求与响应模式的、无状态的、应用层的协议,常基于TCP的连接方式,绝大多数的Web开发,都是构建在HTTP协议之上的Web应用。

为了方便通信就必须统一约定好双方的数据协议,如果每个人都搞一套自己的规则,这玩起来就很麻烦了。因此IETF (互联网工程任务组) 推动了HTTP的统一和发展。现在大家用得最多的还是1999年收录于RFC 2616的1.1版本,2015年发布的2.0版本在推广道路上任重道远。

HTTP[S]报文

最直观上的差异,HTTP协议用明文传输报文,HTTPS用密文。

 

报文对比

HTTP的缺陷

  • 窃听风险(eavesdropping):明文传输,第三方可以获知通信内容。
  • 篡改风险(tampering):第三方可以修改通信内容。
  • 冒充风险(pretending):第三方可以冒充他人身份参与通信。

HTTPS是什么

超文本传输安全协议(英语:Hypertext Transfer Protocol Secure,缩写:HTTPS,常称为HTTP over TLS,HTTP over SSL或HTTP Secure)
是一种透过计算机网络进行安全通信的传输协议。HTTPS经由HTTP进行通信,但利用SSL/TLS协议来加解密数据包。

HTTPS开发的主要目的,是提供对网站服务器的身份认证,保护交换数据的隐私与完整性;
HTTPS并不是一个单独的协议,而是对工作在一加密连接(TLS/SSL)上的常规HTTP协议的称呼。因此HTTPS被称之为身披SSL外壳的HTTP。

SSL/TLS协议

传输层安全性协议(Transport Layer Security,缩写作 TLS),及其前身安全套接层(Secure Sockets Layer,缩写作 SSL)是一种安全协议,目的是为互联网通信,提供安全及数据完整性保障

网景公司(Netscape)在1994年推出首版网页浏览器,网景导航者时,推出HTTPS协议,以SSL进行加密,这是SSL的起源。后面,IETF将SSL进行标准化,称为TLS。在浏览器、电子邮件、即时通信、VoIP、网络传真等应用程序中,广泛支持这个协议

协议 年份 描述
SSL 1.0 N/A 从未公开过,因为存在严重的安全漏洞
SSL 2.0 1995 因为存在数个严重的安全漏洞而被3.0版本替代
SSL 3.0 1996 2014年10月Google发现该版本的严重漏洞,建议全面禁用SSL版本
TLS 1.0 1999 IETF标准化后的第一个版本。包括可以降级到SSL 3.0的实现,这削弱了连接的安全性
TLS 1.1 2006
TLS 1.2 2008 删除了对SSL的兼容。目前使用最广泛的版本
TLS 1.3 2018 截至本文撰写,为建议标准的互联网草案

在TCP/IP模型的位置:介于传输层与应用层之间

SSL/TLS在TCP/IP模型的位置

TLS内部协议划分

  • 记录协议:位于TLS握手协议的下面,在可靠的传输协议(如TCP/IP)上面。其负责识别不同的消息类型,以及每条消息的完整性、安全性验证
  • 握手协议:服务端与客户端在应用程序协议传输之前进行相互认证,协商加密算法和加密密钥

另外还有3个辅助协议:

  • 改变加密方式协议,用来通知对方接下来要切换加解密方案了(有点冗余,在TLS1.3里面已经被删掉了)
  • 警告协议,定义了校验及其他出错类型,
  • 应用数据协议, 把http,smtp等数据流传入记录层做处理并传输。

SSL/TLS解决了什么问题

【内容加密】所有信息都是加密传播,第三方无法窃听。(密钥协商机制)
【数据完整性】具有校验机制,一旦被篡改,通信双方会立刻发现。(MAC(Message authentication code)校验机制)
【身份认证】配备身份证书,防止身份被冒充(证书认证机制)

SSL的握手过程

以下是使用curl请求https://baidu.com的详情

foam@cee: ~ » curl "https://baidu.com" -v                                                                                            
* Rebuilt URL to: https://baidu.com/
*   Trying 123.125.115.110...
* TCP_NODELAY set
* Connected to baidu.com (123.125.115.110) port 443 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/cert.pem
  CApath: none
* TLSv1.2 (OUT), TLS handshake, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Server hello (2):
* TLSv1.2 (IN), TLS handshake, Certificate (11):
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
* TLSv1.2 (IN), TLS handshake, Server finished (14):
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
* TLSv1.2 (OUT), TLS change cipher, Client hello (1):
* TLSv1.2 (OUT), TLS handshake, Finished (20):
* TLSv1.2 (IN), TLS change cipher, Client hello (1):
* TLSv1.2 (IN), TLS handshake, Finished (20):
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* ALPN, server accepted to use http/1.1
* Server certificate:
*  subject: C=CN; L=Beijing; O=BeiJing Baidu Netcom Science Technology Co., Ltd; OU=service operation department; CN=www.baidu.cn
*  start date: Apr  3 00:00:00 2018 GMT
*  expire date: Apr  3 12:00:00 2019 GMT
*  subjectAltName: host "baidu.com" matched cert's "baidu.com"
*  issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA
*  SSL certificate verify ok.
> GET / HTTP/1.1
...
< HTTP/1.1 302 Moved Temporarily
...

我们分析下其中TLS1.2握手的过程:

  1. TLS handshake, Client Hello【客户端向服务端问好】
    客户端通过发送Client Hello报文开始建立SSL通信,报文包含客户端支持的SSL版本,加密套件列表,随机数。上面例子中,ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH就是客户端支持的加密套件的表达式。
  2. TLS handshake, Server Hello【服务端回礼】
    服务端回复Server Hello作为应答,报文包含服务端选择好的SSL版本,加密套件,随机数。上面例子中,服务端选择了TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
  3. TLS handshake, Certificate【服务端亮出身份】
    服务端发送证书链(从根证书到自身的证书)。证书包含证书所有者、颁发机构以及公钥、数字签名等信息。
    客户端收到证书后,会校验域名;判断有效时间;判断颁发机构是否可信任;用颁发机构的公钥解开加密后的数字签名(解开后得到证书摘要和摘要算法),计算并判断证书摘要是否一致。
    如果校验过程中出现问题,客户端将报Alert警告,并终止SSL握手。当然,如果警告级别只是warning(还有一种是fatal),那么客户端也可以选择忽略警告并继续完成握手过程。
  4. TLS handshake, Server key exchange【服务端将密钥生成参数及方法告知客户端】
    对于使用DHE/ECDHE非对称密钥协商算法的,会有该次握手(RSA、DH、ECDH则没有)。
    以ECDHE为例,服务端随机生成随机值Rb,计算Pb(x,y) = Rb * Q(x, y)。然后将Pb(x, y)发送给客户端,用来在后续步骤中计算出PreMasterSecret。ps:该条消息包含一个用服务端私钥作的签名。
  5. TLS handshake, Server finished【服务端提醒:关于密钥生成,该说的我都说完了】
    服务器发送这条消息表明,服务器部分的密钥交换信息已经发送完了,等待客户端的消息以继续接下来的步骤。这条消息只用作提醒,不包含数据域。
  6. TLS handshake, Client key exchange【客户端将密钥生成参数及方法告知服务端】
    这条消息会把PreMasterSecret或者生成PreMasterSecret的数据发给服务端。
    具体是哪种数据与所选用的密钥交换算法有关:
  • RSA:数据为用服务器RSA公钥加密过的PreMasterSecret
  • ECDHE:客户端随机生成随机值Ra,计算Pa(x, y) = Ra * Q(x, y)。然后将Pa(x, y)发给服务端。客户端计算Sa(x, y) = Ra * Pb(x, y);服务器计算Sb(x, y) = Rb *Pa(x, y);算法保证了Sa = Sb = S,提取其中的S的x向量作为PreMasterSecret
    ps: 此次握手过后,双方都拿到了可以计算出MasterSecret的PreMasterSecret。
PRF( secret , label , seed )
master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];
  1. TLS change cipher, Client hello【客户端:接下来我要用新的加密方式与你交流啦】
    客户端发送更改加密方式信号。本流程不携带任何数据,也不参与最后的哈希完整性计算。只是一个宣告信道开始的流程。TLS1.3将其移除。
  2. TLS handshake, Finished【客户端:我对握手全过程计算了哈希,你验证下】
    客户端发送,用协商好的对称加密密钥(MasterSecret)加密过的握手数据包。该数据包完整地计算了从握手开始到结束的所有内容的哈希值,保证了整个握手过程中,数据没有被篡改。服务端会去做校验。
    ps: 这条是整个SSL握手过程中,首次使用对称性加密的数据。
  3. TLS change cipher, Client hello【服务端:接下来我也要用新的加密方式与你交流啦】
    服务端发送更改加密方式信号。TLS1.3将其移除。
  4. TLS handshake, Finished【服务端:我也对握手全过程计算了哈希,你也验证下】
    服务端发送,用协商好的对称加密密钥加密过的握手数据包。客户端也会去做校验。

握手终于结束啦,接下来的http数据传输将全部用辛辛苦苦协商好的MasterSecret进行对称加密。

TLS1.3减少了握手期间的RTT(来回通信延迟)

TLS1.2与1.3握手对比

扩展

密码学套件的标准名字

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256为例:

  • TLS代表的是TLS协议
  • WITH是一个分隔单词,前面的ECDHE_RSA是握手过程所使用的非对称加密方法,后面的AES_128_GCM_SHA256是加密信道的对称加密方法和用于数据完整性检查的哈希方法
  • ECDHE_RSA,客户端与服务端之间在握手期间,密钥交换信息使用的非对称加密算法是第一个算法,证书认证时使用的非对称加密算法是第二个。有的证书套件,例如TLS_RSA_WITH_AES_256_CBC_SHA,WITH单词前面只有一个RSA单词,这时就表示密钥交换算法和证书算法都是使用的RSA,所以只指定一次即可。可选的主要的密钥交换算法包括: RSA, DH, ECDH, ECDHE。可选的主要的证书算法包括:RSA, DSA, ECDSA。两者可以独立选择,并不冲突。
  • AES_128_GCM,指的是AES这种对称加密算法的128位算法的GCM模式
  • SHA256,计算消息完整性的哈希算法。

Charles等代理程序是怎么实现解析https的

本质是中间人。代理程序处在客户端与服务端之间,服务端下发证书的时候,代理程序copy一份数据,并将公钥信息换成自己的,最后用自己的根证书签名。
最最重要的一步是,将自己的根证书加入到系统信任证书列表里边。没有内鬼是破解不了HTTPS的。

image.png

参考资料

HTTPS的二三事
图解HTTP之HTTPS详解
HTTPS协议详解(四):TLS/SSL握手过程
沃通
维基百科
阮一峰博客
TLS的密码学套件
深度解读SSL/TLS实现
Master secret的生成
ECC证书和RSA证书
TLS1.3/QUIC 是怎样做到 0-RTT 的

暂无评论

发送评论 编辑评论


				
|´・ω・)ノ
ヾ(≧∇≦*)ゝ
(☆ω☆)
(╯‵□′)╯︵┴─┴
 ̄﹃ ̄
(/ω\)
∠( ᐛ 」∠)_
(๑•̀ㅁ•́ฅ)
→_→
୧(๑•̀⌄•́๑)૭
٩(ˊᗜˋ*)و
(ノ°ο°)ノ
(´இ皿இ`)
⌇●﹏●⌇
(ฅ´ω`ฅ)
(╯°A°)╯︵○○○
φ( ̄∇ ̄o)
ヾ(´・ ・`。)ノ"
( ง ᵒ̌皿ᵒ̌)ง⁼³₌₃
(ó﹏ò。)
Σ(っ °Д °;)っ
( ,,´・ω・)ノ"(´っω・`。)
╮(╯▽╰)╭
o(*////▽////*)q
>﹏<
( ๑´•ω•) "(ㆆᴗㆆ)
😂
😀
😅
😊
🙂
🙃
😌
😍
😘
😜
😝
😏
😒
🙄
😳
😡
😔
😫
😱
😭
💩
👻
🙌
🖕
👍
👫
👬
👭
🌚
🌝
🙈
💊
😶
🙏
🍦
🍉
😣
Source: github.com/k4yt3x/flowerhd
颜文字
Emoji
小恐龙
花!
上一篇
下一篇