趣谈网络协议
刘超
网易研究院云计算技术部首席架构师
立即订阅
39436 人已学习
课程目录
已完结 51 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 想成为技术牛人?先搞定网络协议!
免费
第一模块 通信协议综述 (4讲)
第1讲 | 为什么要学习网络协议?
第2讲 | 网络分层的真实含义是什么?
第3讲 | ifconfig:最熟悉又陌生的命令行
第4讲 | DHCP与PXE:IP是怎么来的,又是怎么没的?
第二模块 底层网络知识详解:从二层到三层 (5讲)
第5讲 | 从物理层到MAC层:如何在宿舍里自己组网玩联机游戏?
第6讲 | 交换机与VLAN:办公室太复杂,我要回学校
第7讲 | ICMP与ping:投石问路的侦察兵
第8讲 | 世界这么大,我想出网关:欧洲十国游与玄奘西行
第9讲 | 路由协议:西出网关无故人,敢问路在何方
第二模块 底层网络知识详解:最重要的传输层 (4讲)
第10讲 | UDP协议:因性善而简单,难免碰到“城会玩”
第11讲 | TCP协议(上):因性恶而复杂,先恶后善反轻松
第12讲 | TCP协议(下):西行必定多妖孽,恒心智慧消磨难
第13讲 | 套接字Socket:Talk is cheap, show me the code
第二模块 底层网络知识详解:最常用的应用层 (4讲)
第14讲 | HTTP协议:看个新闻原来这么麻烦
第15讲 | HTTPS协议:点外卖的过程原来这么复杂
第16讲 | 流媒体协议:如何在直播里看到美女帅哥?
第17讲 | P2P协议:我下小电影,99%急死你
第二模块 底层网络知识详解:陌生的数据中心 (6讲)
第18讲 | DNS协议:网络世界的地址簿
第19讲 | HTTPDNS:网络世界的地址簿也会指错路
第20讲 | CDN:你去小卖部取过快递么?
第21讲 | 数据中心:我是开发商,自己拿地盖别墅
第22讲 | VPN:朝中有人好做官
第23讲 | 移动网络:去巴塞罗那,手机也上不了脸书
第三模块 热门技术中的应用:云计算中的网络 (5讲)
第24讲 | 云中网络:自己拿地成本高,购买公寓更灵活
第25讲 | 软件定义网络:共享基础设施的小区物业管理办法
第26讲 | 云中的网络安全:虽然不是土豪,也需要基本安全和保障
第27讲 | 云中的网络QoS:邻居疯狂下电影,我该怎么办?
第28讲 | 云中网络的隔离GRE、VXLAN:虽然住一个小区,也要保护隐私
第三模块 热门技术中的应用:容器技术中的网络 (3讲)
第29讲 | 容器网络:来去自由的日子,不买公寓去合租
第30讲 | 容器网络之Flannel:每人一亩三分地
第31讲 | 容器网络之Calico:为高效说出善意的谎言
第三模块 热门技术中的应用:微服务相关协议 (5讲)
第32讲 | RPC协议综述:远在天边,近在眼前
第33讲 | 基于XML的SOAP协议:不要说NBA,请说美国职业篮球联赛
第34讲 | 基于JSON的RESTful接口协议:我不关心过程,请给我结果
第35讲 | 二进制类RPC协议:还是叫NBA吧,总说全称多费劲
第36讲 | 跨语言类RPC协议:交流之前,双方先来个专业术语表
第四模块 网络协议知识串讲 (4讲)
第37讲 | 知识串讲:用双十一的故事串起碎片的网络协议(上)
第38讲 | 知识串讲:用双十一的故事串起碎片的网络协议(中)
第39讲 | 知识串讲:用双十一的故事串起碎片的网络协议(下)
第40讲 | 搭建一个网络实验环境:授人以鱼不如授人以渔
答疑与加餐 (9讲)
协议专栏特别福利 | 答疑解惑第一期
协议专栏特别福利 | 答疑解惑第二期
协议专栏特别福利 | 答疑解惑第三期
协议专栏特别福利 | 答疑解惑第四期
协议专栏特别福利 | 答疑解惑第五期
加餐1 | 测一测:这些网络协议你都掌握了吗?
加餐2 | 创作故事:我是如何创作“趣谈网络协议”专栏的?
加餐3 | “趣谈网络协议”专栏食用指南
第2季回归 | 这次我们来“趣谈Linux操作系统”
结束语 (1讲)
结束语 | 放弃完美主义,执行力就是限时限量认真完成
趣谈网络协议
登录|注册

第15讲 | HTTPS协议:点外卖的过程原来这么复杂

刘超 2018-06-20
用 HTTP 协议,看个新闻还没有问题,但是换到更加严肃的场景中,就存在很多的安全风险。例如,你要下单做一次支付,如果还是使用普通的 HTTP 协议,那你很可能会被黑客盯上。
你发送一个请求,说我要点个外卖,但是这个网络包被截获了,于是在服务器回复你之前,黑客先假装自己就是外卖网站,然后给你回复一个假的消息说:“好啊好啊,来来来,银行卡号、密码拿来。”如果这时候你真把银行卡密码发给它,那你就真的上套了。
那怎么解决这个问题呢?当然一般的思路就是加密。加密分为两种方式一种是对称加密,一种是非对称加密
在对称加密算法中,加密和解密使用的密钥是相同的。也就是说,加密和解密使用的是同一个密钥。因此,对称加密算法要保证安全性的话,密钥要做好保密。只能让使用的人知道,不能对外公开。
在非对称加密算法中,加密使用的密钥和解密使用的密钥是不相同的。一把是作为公开的公钥,另一把是作为谁都不能给的私钥。公钥加密的信息,只有私钥才能解密。私钥加密的信息,只有公钥才能解密。
因为对称加密算法相比非对称加密算法来说,效率要高得多,性能也好,所以交互的场景下多用对称加密。

对称加密

假设你和外卖网站约定了一个密钥,你发送请求的时候用这个密钥进行加密,外卖网站用同样的密钥进行解密。这样就算中间的黑客截获了你的请求,但是它没有密钥,还是破解不了。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《趣谈网络协议》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(86)

  • 万历十五年
    各大CA机构的公钥是默认安装在操作系统里的。所以不要安装来路不明的操作系统,否则相当于裸奔

    作者回复: 是的

    2018-06-22
    154
  • monkay
    会不会存在浏览器第一次向外卖网站请求证书时就被黑客拦截了,然后黑客用自己服务器去权威机构请求正规的证书,然后发给用户,之后的交互,用户以为是跟外卖网站交互,其实背后是跟黑客的网站交互
    2018-06-21
    3
    31
  • Michael
    看了好几遍,感觉算是明白 https 非对称加密通信的过程了,总结一下,大家看看是不是这样的:

    首先,服务端需要向证书颁发机构申请一个自己的证书,这个证书里面会包含此该站点的基本信息,个人啊,公司啊,组织什么呢,我记得CA证书好像分三类的,然后还有该证书的 签名 以及 hash 值用于在通信中客户端鉴别此证书是否合法。

    https 通信分为四个步骤:

    1. c->s,客户端发起加密通信请求,这个请求通常叫做 ClientHello请求,告知自己支持的协议版本号,加密算法,压缩算法,以及一个用于生成后续通信密钥的随机数;
    2. s->c,服务端响应,也叫作 ServerHello,确认加密通信协议,加密算法,以及一个用于生成后续通信密钥的随机数,还有网站证书;
    3. c->s,客户端在收到上一步服务端的响应之后,首先会检查证书的颁发者是否可信任,是否过期,域名是否一致,并且从操作系统的证书链中找出该证书的上一级证书,并拿出服务端证书的公钥,然后验证签名和hash,如果验证失败,就会显示警告,我们经常在Chrome里面看到,“此网站有风险,是否继续什么的”。如果验证通过,客户端会向服务端发送一个称作 “pre-master-key” 的随机数,该随机数使用证书的公钥加密,以及编码改变通知(以后咋们就用协商的密钥堆成加密通信了),客户端完成握手。
    4. 服务端在收到上一步客户端请求之后,也会确认我以后发给你的信息可就加密了哦,并且完成握手。

    此时,客户端有第一步自己生成的随机数,第二步收到服务端的随机数,第三步的 pre-master-key,服务端也是如此,他们就可以用这三个随机数使用约定的算法生成同一个密钥来加密以后的通信数据了。
    2018-12-11
    29
  • LEON
    这张SSL握手的图,真的棒!

    作者回复: 谢谢

    2018-06-20
    20
  • 沙亮亮
    https还是可以被抓包,可以讲下抓https包的原理
    2018-06-20
    1
    17
  • 小先生
    新学到的一点,CA 证书的作用,是保证服务器的公钥的来历。其做法是对公钥进行哈希摘要算法,然后用 CA 私钥加密,伴随公钥一起发送出去。
    客户端收到后,用 CA 公钥解密,然后对公钥做哈希,比对哈希值是否一致来做到的。
    2018-06-29
    15
  • zj
    Nonce是由服务器生成的一个随机数,在客户端第一次请求页面时将其发回客户端;客户端拿到这个Nonce,将其与用户密码串联在一起并进行非可逆加密(MD5、SHA1等等),然后将这个加密后的字符串和用户名、Nonce、加密算法名称一起发回服务器;服务器使用接收到的用户名到数据库搜索密码,然后跟客户端使用同样的算法对其进行加密,接着将其与客户端提交上来的加密字符串进行比较,如果两个字符串一致就表示用户身份有效。这样就解决了用户密码明文被窃取的问题,攻击者就算知道了算法名和nonce也无法解密出密码。

     

    每个nonce只能供一个用户使用一次,这样就可以防止攻击者使用重放攻击,因为该Http报文已经无效。可选的实现方式是把每一次请求的Nonce保存到数据库,客户端再一次提交请求时将请求头中得Nonce与数据库中得数据作比较,如果已存在该Nonce,则证明该请求有可能是恶意的。然而这种解决方案也有个问题,很有可能在两次正常的资源请求中,产生的随机数是一样的,这样就造成正常的请求也被当成了攻击,随着数据库中保存的随机数不断增多,这个问题就会变得很明显。所以,还需要加上另外一个参数Timestamp(时间戳)。

     

    Timestamp是根据服务器当前时间生成的一个字符串,与nonce放在一起,可以表示服务器在某个时间点生成的随机数。这样就算生成的随机数相同,但因为它们生成的时间点不一样,所以也算有效的随机数
    2019-05-23
    2
    10
  • 飞龙在天
    老师你好:
    https协议中,客户端和服务端信息传输使用了对称加密,疑惑的是服务器端是怎样识别多个客户端的公钥呢?项目中并没有对此做特殊的处理,希望老师解惑o(^o^)o。

    作者回复: 会建立session

    2018-06-20
    10
  • dovefi
    https 核心思想,首先数字证书保证了服务端公钥的可靠性,客户端确认完可靠性之后,就用这个公钥去加密pre-master,服务端收到加密后的数据,用自己的私钥去解开,得到pre-master,然后两边都有了①客户端的随机数 ②服务端的随机数 ③pre-master 然后就各自通过计算得到一样的值,就当做公钥。后面就是对称加密的数据传输。这个过程中,对称加密的公钥从来没有在网络上传输过,所以不存在暴露的微信,ca证书中的解密是通过不对称的加密方式实现的,而且保证了公钥的可靠性,所以这里不怕别人拿到公钥,因为私钥他没有,也不怕别人伪造私钥和公钥,因为ca保证了公钥是可靠的
    2019-05-07
    8
  • isaac
    单向认证中的三个随机数可能是为了保证完全随机吧,毕竟所有的机器都是伪随机的

    作者回复: 赞,对的

    2019-01-28
    7
  • 李简单
    证书解密后,hash怎么算对上了呢?
    2018-08-08
    3
    6
  • 一步
    老师,可以补充一下https双向认证的流程图吗?

    作者回复: 好的,后期补充一下

    2018-07-17
    4
  • 森码
    客户端和服务端为什么要分别传输一个随机数呢?通过公钥加密Pre-master不是就可以用吗?

    作者回复: 如果双向认证,其实是可以的,但是不都是双向认证

    2018-07-11
    4
  • 王世林
    1.浏览器遍历操作系统列表中证书发布机构ca列表,如果与服务器端发来的证书机构ca一致, 则会用操作系统中的ca证书的公钥解密服务端证书的签名,浏览器使用相同的hash算法计算出服务器发来的证书的hash值,将这个计算的hash值与证书中签名做对比,对比结果一致,则证明服务器发来的证书合法,没有被冒充, 是这样的吗? 2. 这个pre-master 是浏览器发给服务端, 最后生成相同的对称回话密钥, 我看网上还有的评论可以生成2个不同的回话密钥, 分别对应浏览器发给服务端信息和服务端发给浏览器信息

    作者回复: 可以是两个

    2019-04-24
    3
  • 酷哥居士
    想请教老师一下,上面的HTTPS请求,客户端和服务端之间发送证书,验证证书,传输秘钥等等这些操作,是在HTTPS的TCP连接建立成功后做的吗?

    作者回复: 是的

    2019-01-23
    3
  • 王恩浩
    理解:面对面交接“对称密钥”不可能,于是我就把密钥让靠谱的“快递公司”先传递给你。这过程只要想办法确保“快递公司”是正规的安全的就行了。
    2019-01-16
    3
  • 野猪佩奇
    老师你好,我之前听说获取CA证书都是需要给钱的,这边怎么一条命令就能获取一个证书啊?望解惑,谢谢

    作者回复: 我自己做ca当然可以啊,只不过拿出去不算

    2018-07-17
    3
  • 烧饼
    这里两个 hello 信息都是用明文传输的,包括里面的随机数,真正加密传输的是 Pre-master 。就是说外界完全可以抓取这两个随机数,真正影响外界窃取对称密钥的是 Pre-master ,那是不是意味着其实这两个随机数作用不大,可以去掉?

    作者回复: 不是的,这几个都是计算对称密钥的材料

    2018-06-29
    3
  • 唐唐
    老师好,有个问题很疑惑,想请教一下。这个https是浏览器和服务器端的交互吧。那么这个证书对应安装到用户的浏览器了吗?服务器端怎么能知道用户安装的是什么证书,拿到该证书对应的公钥或私钥呢?浏览器是安装一个证书,还是对应不同服务器安装多个不同证书。

    作者回复: 证书会下载到浏览器本地,服务端不管,如果证书不对就验证失败

    2018-06-20
    3
  • Jerry银银
    有几个疑问,希望老师帮忙解答:
    1. 为什么需要三个随机数,我隐隐觉得是为了提高随机性,从而保证安全性,不知道理解对不对?
    2. 为什么最后一个随机数叫pre-master?
    3. 客户端可以连接代理服务器,代理服务器可以生成自签名证书,这样就可以抓包了,这种情况如何解决呢?

    作者回复: 算法就是这样的哒

    2019-05-16
    2
收起评论
86
返回
顶部