透视HTTP协议
罗剑锋(Chrono)
奇虎360技术专家,Nginx/OpenResty开源项目贡献者
立即订阅
6077 人已学习
课程目录
已完结 44 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词|To Be a HTTP Hero
免费
破冰篇 (7讲)
01 | 时势与英雄:HTTP的前世今生
02 | HTTP是什么?HTTP又不是什么?
03 | HTTP世界全览(上):与HTTP相关的各种概念
04 | HTTP世界全览(下):与HTTP相关的各种协议
05 | 常说的“四层”和“七层”到底是什么?“五层”“六层”哪去了?
06 | 域名里有哪些门道?
07 | 自己动手,搭建HTTP实验环境
基础篇 (7讲)
08 | 键入网址再按下回车,后面究竟发生了什么?
09 | HTTP报文是什么样子的?
10 | 应该如何理解请求方法?
11 | 你能写出正确的网址吗?
12 | 响应状态码该怎么用?
13 | HTTP有哪些特点?
14 | HTTP有哪些优点?又有哪些缺点?
进阶篇 (8讲)
15 | 海纳百川:HTTP的实体数据
16 | 把大象装进冰箱:HTTP传输大文件的方法
17 | 排队也要讲效率:HTTP的连接管理
18 | 四通八达:HTTP的重定向和跳转
19 | 让我知道你是谁:HTTP的Cookie机制
20 | 生鲜速递:HTTP的缓存控制
21 | 良心中间商:HTTP的代理服务
22 | 冷链周转:HTTP的缓存代理
安全篇 (7讲)
23 | HTTPS是什么?SSL/TLS又是什么?
24 | 固若金汤的根本(上):对称加密与非对称加密
25 | 固若金汤的根本(下):数字签名与证书
26 | 信任始于握手:TLS1.2连接过程解析
27 | 更好更快的握手:TLS1.3特性解析
28 | 连接太慢该怎么办:HTTPS的优化
29 | 我应该迁移到HTTPS吗?
飞翔篇 (4讲)
30 | 时代之风(上):HTTP/2特性概览
31 | 时代之风(下):HTTP/2内核剖析
32 | 未来之路:HTTP/3展望
33 | 我应该迁移到HTTP/2吗?
探索篇 (5讲)
34 | Nginx:高性能的Web服务器
35 | OpenResty:更灵活的Web服务器
36 | WAF:保护我们的网络服务
37 | CDN:加速我们的网络服务
38 | WebSocket:沙盒里的TCP
总结篇 (2讲)
39 | HTTP性能优化面面观(上)
40 | HTTP性能优化面面观(下)
答疑篇 (2讲)
41 | Linux/Mac实验环境搭建与URI查询参数
42 | DHE/ECDHE算法的原理
结束语 (1讲)
结束语 | 做兴趣使然的Hero
透视HTTP协议
登录|注册

26 | 信任始于握手:TLS1.2连接过程解析

Chrono 2019-07-26
经过前几讲的介绍,你应该已经熟悉了对称加密与非对称加密、数字签名与证书等密码学知识。
有了这些知识“打底”,现在我们就可以正式开始研究 HTTPS 和 TLS 协议了。

HTTPS 建立连接

当你在浏览器地址栏里键入“https”开头的 URI,再按下回车,会发生什么呢?
回忆一下第 8 讲的内容,你应该知道,浏览器首先要从 URI 里提取出协议名和域名。因为协议名是“https”,所以浏览器就知道了端口号是默认的 443,它再用 DNS 解析域名,得到目标的 IP 地址,然后就可以使用三次握手与网站建立 TCP 连接了。
在 HTTP 协议里,建立连接后,浏览器会立即发送请求报文。但现在是 HTTPS 协议,它需要再用另外一个“握手”过程,在 TCP 上建立安全连接,之后才是收发 HTTP 报文。
这个“握手”过程与 TCP 有些类似,是 HTTPS 和 TLS 协议里最重要、最核心的部分,懂了它,你就可以自豪地说自己“掌握了 HTTPS”。

TLS 协议的组成

在讲 TLS 握手之前,我先简单介绍一下 TLS 协议的组成。
TLS 包含几个子协议,你也可以理解为它是由几个不同职责的模块组成,比较常用的有记录协议、警报协议、握手协议、变更密码规范协议等。
记录协议(Record Protocol)规定了 TLS 收发数据的基本单位:记录(record)。它有点像是 TCP 里的 segment,所有的其他子协议都需要通过记录协议发出。但多个记录数据可以在一个 TCP 包里一次性发出,也并不需要像 TCP 那样返回 ACK。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《透视HTTP协议》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(40)

  • 彩色的沙漠
    浏览留言区,留言区同学和我有一样的疑问“Client Params 和 Server Params 都可以被截获,为何中间人没法通过这两个信息计算 Pre-Master Secret 呢?”
    我去网上找了关于ECDHE握手过程,这个可以帮助大家更好的理解ECDHE,具体过程如下:
    (1):客户端随机生成随机值Ra,计算Pa(x, y) = Ra * Q(x, y),Q(x, y)为全世界公认的某个椭圆曲线算法的基点。将Pa(x, y)发送至服务器。

    (2):服务器随机生成随机值Rb,计算Pb(x,y) = Rb * Q(x, y)。将Pb(x, y)发送至客户端。

    (3):客户端计算Sa(x, y) = Ra * Pb(x, y);服务器计算Sb(x, y) = Rb *Pa(x, y)

    (4):算法保证了Sa = Sb = S,提取其中的S的x向量作为密钥(预主密钥)。
    @引用
    ---------------------
    作者:Mrpre
    来源:CSDN
    原文:https://blog.csdn.net/mrpre/article/details/78025940
    版权声明:本文为博主原创文章,转载请附上博文链接!

    作者回复: 非常好的同学,大力表扬!

    2019-08-01
    1
    9
  • magicnum
    比如TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256:使用ECDHE进行密钥交换(文中已经讲了,用它算出Pre_Master,成会话密钥Master Secret。密钥交换过程中应该会使用到非对称加密中的公钥加密),RSA进行身份验证(私钥加密公钥解密),使用128位GCM分组工作模式的AES进行消息和会话密钥的对称加密(加密真正的消息),使用SHA256摘要算法(如HMAC、PRM)对数据签名,保证数据完整性

    作者回复: 说的很好。

    2019-07-26
    1
    5
  • 极夜
    老师,我通过nslookup获得百度的一个ip为180.101.49.11,然后用https://180.101.49.11访问,浏览器会提示建立的连接不安全。在chrome浏览器的security页面中,连接走的还是TLS , 但该网页缺失认证。我的理解是,证书在访问网页的时候就返回了,但证书只能证明某个公钥是属于某个域名的,不能证明公钥是否归属某个IP,是不是这样呢?

    作者回复: 这是因为申请证书的时候一般都是绑定在域名上,证书证明的是域名而不是ip,所以无法验证网址的合法性。

    如果申请证书时就绑定ip,那么就没问题了,但几乎没有人会这么做,因为ip地址会变,而域名通常是稳定的。

    2019-08-30
    3
  • 一坛幽梦
    老师,还是没有明白服务端/客户端发送public key的用途是什么,麻烦老师再重点说一下,感谢!

    作者回复: 服务器客户端不会直接发送public key,如果你指的是密钥交换的过程,它实际上是ECDHE算法锁要求的参数,交换这些参数就可以在两边分别算出pre-master,而外部的黑客是无法计算得到的。

    发送证书是为了配合私钥签名验证客户端或服务器是身份,只要签名对,就说明对方是证书所标记的实体。

    2019-08-17
    2
  • 亚洲舞王.尼古拉斯赵四
    第二个问题:客户端使用tcp链接明文将自己的随机数、密码套件、tls版本号发送给服务端,服务端根据自己支持的密码套件从客户端的密码套件中选取一个最合适的密码套件,协商出tls版本,将协商好的密码套件、tls版本以及自己的随机数明文告诉客户端,并将自己的证书发送给客户端,并结束
    客户端收到证书之后去ca一级一级验证证书的有效性,验证通过后,客户端使用随机数生成pre-master并 用服务器的公钥进行加密传给服务端,服务端使用自己的私钥进行解密,使用解密后的值与客户端随机数,自己的随机数进行计算,得出master secret;这时候,客户端使用三个值也能计算出master secret,客户端告诉服务器我之后都使用加密进行通信了,结束;服务端也告诉客户端,我也要开始使用加密通信了,over
    接下来两个人使用计算出来的master secret进行消息加密,两人balabala,并使用master secret进行解密

    作者回复: good。

    2019-08-07
    2
  • Neo
    老师好,请教一下“双向验证”的问题:
    1. 双向验证,是不是客户端和服务器端协商决定的?
    例如我用浏览器访问这个测试网址:https://server.cryptomix.com/secure/ 会弹出选择客户端证书的窗口。如果是的话,服务器怎么让客户端知道需要客户端证书的?
    2. 您在客户作业中提到“画出双向验证的流程图”,我自己还没有理解到,留言区似乎也还没有答案,您能公布答案么?谢谢🙏

    作者回复:
    1.服务器会发出一个Certificate Request消息,要求客户端提供证书,这样在ServerHelloDone消息后,客户端就会发送Client Certificate提供客户端证书。

    2.双向认证的流程就在ServerHelloDone消息后多了个客户端证书,比较简单,看后面有时间再补充一篇答疑吧。

    2019-11-22
    1
  • 🌞🇨🇳👦
    在上一课中,讲到ecdhe非对称加密算法可以不等服务器返回finished就直接抢跑发送数据,相当于1个rtt。tls1.3这里好像并没有实际上减少握手时间?

    作者回复: 是的,但false start是有条件的(ecdhe),如果用rsa就是2-rtt。

    而tls1.3是无条件,一定是1-rtt,而且它还有0-rtt。

    2019-08-07
    1
  • J.D.
    看的有点晚,面试的时候问了 Https 的连接过程.......

    作者回复: 没事,现在学会了也不晚,更好的机会在等着你。

    2019-08-05
    1
  • 彩色的沙漠
    请问老师我在Wireshark 设置过滤器tcp.port==443 查看抓包,有很多其他TCP包也被抓到了,过滤的不彻底,老师的过滤器tcp port 443 在哪设置?谢谢!

    作者回复: wireshark启动后的初始界面,“使用这个过滤器”,在文本框里输入。

    2019-08-05
    1
  • 叶佳欣
    老师,问下。Server Key Exchange需要用私钥签名认证。那Client Key Exchange会用公钥加密下吗,如果不会,为什么不像传统握手把pre-master用公钥加密发送给server?

    作者回复: pre-master的交换方式是由密钥交换算法决定的,如果是rsa就直接公钥加密,如果是ecdhe就要用算法参数。

    这些都要按照tls协议来,Client Key Exchange已经由密钥交换算法保证了安全,所以不需要再加密或者签名。

    如果是双向认证,那么客户端会发送客户端的证书,也要做签名认证,让服务器验证身份。

    2019-07-31
    1
  • 丶景
    老师好,RSA 握手过程下面有个不明白的地方,使用 ECDHE 可以不用等到服务器发回“Finish”立即就发出 HTTP 报文。使用 RSA 为什么就不可以先发出 HTTP 报文?


    作者回复: 这个只能说是fasle start协议的规定,其实rsa也可以抢先发出报文,但没有人这么用。

    2019-07-26
    1
  • 丶景
    Pre-Master Secret 这个不理解,是说客户端和服务器分别通过 Client Params 和 Server Params 都能计算出一样的 Pre-Master Secret 吗?如果是,为什么中间人算不出?

    作者回复: 这是由DH算法决定的,DH算法是专门用作密钥交换的,它本身能够保证交换安全,具体的细节一下子说不清楚,你可以搜一下相关的资料。

    2019-07-26
    1
  • 许童童
    老师讲得好啊,现在完全理解了,往返最多两次,之前一直理解很得模糊。

    作者回复: 可以把自己理解的过程写出来,这样才能说明真正弄懂了。

    2019-07-26
    1
    1
  • 大小兵
    请问一下老师,上面的握手过程是不是没有用到非对称加密啊?如果没有用到那非对称加密什么时候用呢?

    作者回复: 有啊,在握手里用ecdhe交换pre-master,之前有发送证书,验证书就有非对称加密。

    可以看一下双方商定的密码套件,看看里面的算法都用在了哪个环节。

    2019-07-26
    1
  • 何用
    Client Params 和 Server Params 都可以被截获,为何中间人没法通过这两个信息计算 Pre-Master Secret 呢?

    作者回复: 由密钥交换算法保证,比如rsa、ecdhe。

    2019-07-26
    1
  • Leon📷
    如果想测试公网的https服务报文,是不是把浏览器端的私钥导入wireshark就可以了

    作者回复: 不用,只要设置了环境变量SSLKEYLOGFILE,wireshark就可以从日志里读取握手过程中的信息,相当于浏览器告诉了wireshark pre-master,所以就可以解密。

    不需要任何私钥。

    2019-07-26
    1
  • Ben
    有个疑问没有想清楚:client在发送“client key exchange”消息之前需要把client的证书发送给server吗?

    我在想server发送给client的“server key exchange”消息需要签名认证,那么client发送给server的“client key exchange”难道不需要签名认证吗?

    如果需要签名认证的话,那么是不是就需要先把client的证书发送给server做验证。

    作者回复:
    1.服务器会发出一个Certificate Request消息,要求客户端提供证书,这样在ServerHelloDone消息后,客户端就会发送Client Certificate提供客户端证书。如果没有Certificate Request客户端就不必提供证书。

    2.tls握手分双向认证和单向认证两种,我们通常都用的是单向认证,即客户端认证服务器,服务器不认证客户端。
    因为毕竟私钥签名比较费时间,而且给成千上万的客户端都颁发证书不太现实。单向认证通过后,可以再用用户名+口令的方式来验证客户端的身份。

    3.少数场合,比如网银,为了加强安全,就会使用双向认证,确保通信双方的身份不被伪造。

    2019-12-10
  • ddq432
    还有一个问题,在服务器发送证书给客户端的时候,还有一个数字签名,这个签名是在什么时候使用的

    作者回复: 签名用来验证之前发送的握手数据,保证不会被窜改。

    2019-12-06
  • ddq432
    有一点不是很明白,服务器把证书给客户端之后,客户端是依据什么来判断 这个证书是合法的证书?它是根据什么匹配它自己是哪一家ca颁发的呢?还有,服务器的公钥是在这个证书里面的吧?只不过是被第三方的认为可靠的机构进用他们自己的私钥加密了,那第三方的公钥从哪里得到呢,是被直接内置到客户端里面的吗?我比较笨,希望老师解惑

    作者回复: 可参考前两讲,证书是使用ca的证书来验证是否合法的,走证书链,链的源头的自证明的根证书。

    第三方也就是ca的公钥私钥是自己生成,自己签名的。著名的ca的证书都会被内置到操作系统或者浏览器里。

    当然服务器也可以直接在证书链里发送根证书,但这样比较浪费带宽,一般不这样做。

    2019-12-06
  • 张智凯
    使用ECDHE-RSA-AES256-GCM-SHA384加密套件进行TLS握手的过程
    1 客户端向服务器端发送clienthello请求,请求的内容里包括客户端支持的TLS版本号、支持的加密套件列表、客户端随机数
    2 收到客户端的请求后,服务器端向客户端发送serverhello请求,请求里包括服务器选择的TLS版本号、选择的加密套件、服务器端随机数。
    3 服务器端接着向客户端发送自己的证书链
    4 服务器向可客户端发送exchangekey请求,因为选择的的套件的密钥交换算法是ECDHE,所以请求里包括 密钥交换算法的椭圆曲线的名称、基点信息、以及交换算法所需要的一个参数公钥serverparam,然后服务器会对上面这些信息使用摘要算法SHA384做哈希,然后对哈希结果使用证书里的公钥对应的私钥进行加密,即签名来证实自己的身份
    5 服务器发送server hello done
    6客户端收到服务器的证书后会查找本地的根证书,从证书链的顶级,逐级向下验证,验证通过后,会向服务器端发送client key exchange请求,请求里的内容是椭圆曲线算法需要的另一个公钥client paramsEDCH
    7 客户端发送change cipher spec接着通过 ECDHE的两个算法以及两个param算出 pre-master secret,并同过pre-master secret以及两个随机数,算出master-key,以及其他会话传输的密钥
    8 客户端发送finished,并对之前发过的信息进行摘要,并使用master-key加密?
    9 服务器收到请求后发送change cipher spec,会通过ECDHE算法以及两个param算出一个pre-master secret,然后利用客户端随机数、服务器随机数、pre-master secret得到server secret以及一系列得其他会话密钥。
    10 服务器发送finished,并对之前发送的消息做摘要算法,并使用master-key加密

    自此TLS握手阶段就完成了,后面使用master-key加密后的http协议进行通信

    有三个疑问:
    1 , EDCHE算法的问题,都是两个参数,以及一个函数,而且都是明文传递的,为什么黑客得不到pre-master secret,难道还要其中一个param对应得私钥才行?
    2 后面的http正文的加密是使用master-key吗,master-key是对称加密算法的密钥?
    3 我们只选择了套件,对称加密的密钥是通过条件里的对称加密算法根据两个随机数以及对称加密赛算法生成的?

    作者回复:
    1.可参见答疑篇,详细介绍了ECDHE算法。

    2.master key顾名思义,只是主密钥,还会再派生出多个用途各不相同的密钥,例如客户端发送数据用client_write_key,这点课程里简单提了一下。

    3.理解的有点小偏差,对称密钥,也就是会话密钥是由master key生成的,而master key是由之前密钥交换过程中的三个随机数生成的。前两个随机数公开,而第三个随机数Pre-Master是由ecdhe算法保证了交换安全。

    2019-11-01
    1
收起评论
40
返回
顶部