全栈工程师修炼指南
熊燚(四火)
Oracle首席软件工程师
立即订阅
2286 人已学习
课程目录
已更新 43 讲 / 共 40 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 从成长角度看,为什么你应该成为全栈工程师?
免费
学习路径 | 怎样成为一名优秀的全栈工程师?
导读 | 如何学习这个专栏?
第一章 网络协议和 Web 接口 (6讲)
01 | 网络互联的昨天、今天和明天:HTTP 协议的演化
02 | 为HTTP穿上盔甲:HTTPS
03 | 换个角度解决问题:服务端推送技术
04 | 工整与自由的风格之争:SOAP和REST
05 | 权衡的艺术:漫谈Web API的设计
06 | 特别放送:北美大厂如何招聘全栈工程师?
第二章 欢迎来到 MVC 的世界 (7讲)
07 | 解耦是永恒的主题:MVC框架的发展
08 | MVC架构解析:模型(Model)篇
09 | MVC架构解析:视图(View)篇
10 | MVC架构解析:控制器(Controller)篇
11 | 剑走偏锋:面向切面编程
12 | 唯有套路得人心:谈谈Java EE的那些模式
13 | 特别放送:选择比努力更重要
第三章 从后端到前端 (7讲)
14 | 别有洞天:从后端到前端
15 | 重剑无锋,大巧不工:JavaScript面向对象
16 | 百花齐放,百家争鸣:前端MVC框架
17 | 不一样的体验:交互设计和页面布局
18 | 千言万语不及一幅画:谈谈数据可视化
19 | 打开潘多拉盒子:JavaScript异步编程
20 | 特别放送:全栈团队的角色构成
第四章 数据持久化 (7讲)
21 | 赫赫有名的双刃剑:缓存(上)
22 | 赫赫有名的双刃剑:缓存(下)
23 | 知其然,知其所以然:数据的持久化和一致性
24 | 尺有所短,寸有所长:CAP和数据存储技术选择
25 | 设计数据持久层(上):理论分析
26 | 设计数据持久层(下):案例介绍
27 | 特别放送:聊一聊代码审查
第五章 寻找最佳实践 (6讲)
28 | Ops三部曲之一:配置管理
29 | Ops三部曲之二:集群部署
30 | Ops三部曲之三:测试和发布
31 | 防人之心不可无:网站安全问题窥视
32 | 和搜索引擎的对话:SEO的原理和基础
33 | 特别放送:聊一聊程序员学英语
第六章 专题 (7讲)
34 | 网站性能优化(上)
35 | 网站性能优化(下)
36 | 全栈开发中的算法(上)
37 | 全栈开发中的算法(下)
38 | 分页的那些事儿
39 | XML、JSON、YAML比较
40 | 全栈衍化:让全栈意味着更多
全栈工程师修炼指南
登录|注册

02 | 为HTTP穿上盔甲:HTTPS

四火 2019-09-13
你好,我是四火。
在上一讲中,我介绍了互联网最重要的 HTTP 协议。可是随着互联网的发展,你会发现 HTTP 越来越无法满足复杂的需求,比如数据加密传输的安全性需求,再比如服务器消息即时推送的交互模式的需求,而这些不适性是由 HTTP 的基本特性所造成的。
因此,我们需要在传统 HTTP 领域以外开疆拓土,这就包括要引入其它的网络协议,或增强、或填补 HTTP 协议所不擅长的空白领域,这也是今天这一讲和下一讲的核心内容。今天我们重点学习 SSL/TLS ,看看它是如何让 HTTP 传输变得安全可靠的。

HTTP,SSL/TLS 和 HTTPS

在一开始的时候,HTTP 的设计者并没有把专门的加密安全传输放进协议设计里面。因此单独使用 HTTP 进行明文的数据传输,一定存在着许多的安全问题。比方说,现在有一份数据需要使用 HTTP 协议从客户端 A 发送到服务端 B,而第三方 C 尝试来做点坏事,于是就可能产生如下四大类安全问题:
Interception:拦截。传输的消息可以被中间人 C 截获,并泄露数据。
Spoofing:伪装。A 和 B 都可能被 C 冒名顶替,因此消息传输变成了 C 发送到 B,或者 A 发送到 C。
Falsification:篡改。C 改写了传输的消息,因此 B 收到了一条被篡改的消息而不知情。
Repudiation:否认。这一类没有 C 什么事,而是由于 A 或 B 不安好心。A 把消息成功发送了,但之后 A 否认这件事发生过;或者 B 其实收到了消息,但是否认他收到过。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《全栈工程师修炼指南》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(11)

  • 饭团 置顶
    回答老师问题
    1)不能 因为虽然https是安全的,但前提是你的访问对象是安全的,归根到底你要保证真实是真实的,安全的!是你想访问对象!因为证书也是可以自己生成的!
    2)为了性能,非对称加密算法性能不好!对称算法性能高!

    作者回复: 1)结论正确,但是解释不太妥当。HTTPS 可以达到数据在网络传输过程中的可靠性,但是支付过程是一个复杂和综合性的行为,涉及到的过程和角色远不只有 HTTPS 连接和它的客户端、服务端,因此 HTTPS 的安全性结论无法推广到整个支付过程和支付行为的安全性结论。

    2)性能是一个非常重要的因素,说得很好,因为非对称性加密的性能要比对称性加密的性能差很多,特别是在被加密数据量比较大的时候,但它的问题在于无法把密钥传递到对端,因此我们才使用了非对称加密的方式来帮助做到这一点。但是,还有其它原因,比如说,对称性密钥是每次会话生成的,会话以外自动失效,这就像武功唯快不破一样,通常很短的时间就更换掉了;如果使用非对称性加密方式来传输实际数据,因为它只在最开始的时候生成一次,而不是每次会话都生成,因此在传输中同一个公钥会被发给多个不同的客户端,因此第三方的中间人可以使用这个公开的公钥解密服务端发给其它客户端的数据,这显然不具备安全性。

    2019-09-13
    9
  • CC
    对于老师的置顶回复中的下面这句话有一个疑问:「第三方的中间人可以使用这个公开的公钥解密服务端发给其他客户端的数据。」

    我的理解是:非对称加密意味着「公钥加密,私钥解密」。

    如果使用公开的公钥加密传输数据,第三方中间人仍然需要私钥来解密数据。

    为何第三方中间人可以使用这个公钥来解密数据呢?

    不确定是不是自己哪一步理解有误。

    提前谢谢老师。

    作者回复: 这是一个很好的问题。

    有“公钥加密,私钥解密”,但其实也有“私钥加密,公钥解密”。

    从消息保密的角度来说,一般我们都是使用公钥加密,私钥解密。这样才能让消息保密,即便被第三方窃取了消息,消息内容也不会泄露。如果是这个用途,那么你说的完全正确。

    但是 non-repudiation 则是反过来,使用私钥加密,目的就是让对方,以及可能出现的第三方使用公钥解密,这样大家都能证明消息已经确实被发送了,因为在私钥没有泄露的情况下,这条消息是无法被创建的,这也就使得“否认”(repudiation)变得不可能。

    2019-09-23
    1
    3
  • kissingers
    老师,为什么要设计成有了ABC才能计算出密钥,不要AB行吗?因为只有c是加密的,攻击者拿到c 不就可以计算出密钥了吗?那ab 还有意义吗?谢谢

    作者回复: 这种方式(传统 RSA 方式)下,C 是通过非对称密钥加密的,因此攻击者拿到加密后的 C,却无法解密。最后的对称密钥的计算,需要解密后的 C。

    至于 A 和 B 因子的引入,是为了提高 pre-master 的随机性。

    2019-12-02
    1
    1
  • 零维
    老师,证书发布机构对证书做摘要生成的指纹和客户端生成的指纹 P1 是一个东西吗?

    作者回复: 对。对于证书做摘要得到指纹,这个指纹无论是发布方还是客户端得到的,它们必须一致,要不然校验就失败了。

    2019-10-17
    1
  • 零维
    老师,您建议先粗略的读一遍,再重读的时候再学习这些延展资料,还是第一遍的时候就跟着学下来呢?

    作者回复: 这个取决于你自己吧 :) 理解内容最重要。

    2019-10-17
    1
  • Skylight
    老师我有俩问题:
    1、“快速验证”对对话摘要加密使用的秘钥应该是A+B+C生成的会话秘钥吧?
    2、有了会话秘钥之后,传输数据时为了判断信息是否被篡改,是不是也要对信息进行摘要然后对称秘钥加密后再把信息、摘要发给对方啊?

    作者回复: 1. 是会话密钥
    2. 这就不会了,因为前面的机制保证了会话密钥仅此两份

    2019-10-10
  • CC
    思考题1:

    如果这个支付功能网站本身就是为了钓鱼设计的,仍然可能出现安全问题。(后看到老师置顶留言,才知道原来不能把 HTTPS 的安全结论推广到整个支付过程。HTTPS 只是支付过程的一部分。)



    思考题2:

    是安全与效率的取舍。

    如果全部使用对称加密,安全性不可靠,相对容易反推秘钥;如果全部使用非对称加密,内容传输的效率低,在数据量大的时候低很多。

    严格确认双方身份后,就可以用低成本高效率的方式来沟通。

    (后看到老师留言,使用非对称性加密来传输实际数据,没有一过性,反倒会有安全性问题。)



    选修课堂和扩展阅读长知识了,谢谢老师。

    作者回复: 👍

    2019-09-23
  • liu_liu
    1. 不对,因为在建立 TSL 连接的过程中可能会出现中间人攻击。
    2. 出于性能和安全性考虑

    作者回复: 感谢回答。
    正确,但不完整,你可以看看别人的回答。

    2019-09-18
  • pyhhou
    思考题:
    1. 这种想法是不对的,虽然有证书和加密机制做保证,但是黑客们还是可以在请求访问的过程中做文章。在网上找到了个例子:“DNS 劫持”,因为我们在向服务器发送请求的第一步就是去到 DNS,通过域名获取服务器 IP,如果说这一步我们访问的 DNS 服务器是黑客的,这个 DNS 会返回一个错误的 IP,导致我们使用 HTTPS 去和一个错误的 server 去建立所谓的 “安全” 连接。一句话总结就是 HTTPS 安全不等于支付过程安全

    2. 回答这个问题之前,先分析一下我们对 TLS/SSL 建立连接的需求和期待:
    i) 客户端和服务器都能够解密它们之间传输的数据
    ii) 保证这个过程效率尽量高
    iii) 保证这个过程尽量安全

    如果说双方都使用对称性加密算法,确实建立连接的效率很高,双方也可以加密解密彼此的数据,但是这其实并不安全,首先密钥不能够通过安全的方式告知对方,另外动态更新密钥会使得安全性提升,但是告知方式受阻,这里也做不到。
    如果说双方都使用非对称性加密算法,由于密钥只有一把,传递出去的都是公钥,公钥只能加密不能解密,这个安全问题解决了,每次传输数据都用对方给的公钥加密,接收数据都用自己生成的私钥解密,数据加密解密确实也可以完成,但是非对称加密算法本身效率不高,加上客户端服务器来回生成公私钥,传递公钥,传输效率也大打折扣。
    如果我们结合这两个算法的优缺点,用非对称算法保证传输安全,用对称算法保证解密数据的高效和正确性,确实是一个较为合理的做法。


    感谢老师分享,读完文章受益匪浅,花了比较多的时间看整个 TLS/SSL 这个过程,算是初步理解了,扩展阅读给的第一个链接非常不错,简明易懂,这里请教老师几个文章中提到的概念和自己思考的问题:

    1. TLS/SSL 建立链接的第四步和第五步中,客户端和服务器都会发送 Encrypt Handshake Message 用于对方做测试使用,这里说需要解密并和 “原串” 对比,不太清楚的是这里的 “原串” 具体指的是什么?

    2. 证书验证部分,客户端需要根据具体算法 “摘要” 得到指纹 P1,然后使用公钥和数字签名解密得到指纹 P2,这里的 “摘要” 指的是什么?

    3. 之前用 node 中的套件调用 Restful API 传输 json 文件进行 server 之间或者 server 和 client 的数据交互,这里是不是默认都是 HTTP 协议呢?如果要改成 HTTPS 的话,需要在 server 上做设定吗,还是说直接在调用套件的时候指明就行?因为没有实做过这一块,如果老师有相关链接分享那是极好的。

    问题比较多,劳烦老师指点了,谢谢老师

    作者回复: 感谢答复!

    第一问,回答举的例子非常好,HTTPS 只能保证连接的可靠,如果连接目标都是错的,那么安全性就无从谈起。
    第二问,描述的内容也是正确的,当然,两者都有可以补充的内容。

    关于你的三个问题:
    1. 无论是客户端还是服务端,对前面所有的传输的数据做一次摘要,再解密对端传过来的消息,二者进行比较。
    2. 摘要,其实就是指一种单向的哈希算法,比如 MD5、SHA-1。
    3. 这个我不清楚怎样设定。

    2019-09-17
    2
  • Mandalorian
    请问下关于 Repudiation,否认这项;

    HTTPS如何保证不被否认的?因为有TLS建立过程,有双方公私钥的参与?

    作者回复: 好问题!

    目前的 TLS 机制无法单独保证 Repudiation(否认),请注意我在文中也写到“第四个问题还需要引入数字签名来解决”。

    Repudiation 的解决,必须要靠类似数字签名这样的机制:A 必须收到 B 经过对方私钥加密的消息,这样 A 再使用 B 的公钥解密。而公钥是公开的,也是通过证书等权威形式认证的,所有人都是可以拿到的,公证方一使用 B 的公钥解密,就可以证明这条消息确实来自 B,那么 B 也就无法否认事实了。当然,实际操作的过程中私钥加密的未必是原始信息,也可以是原始信息的散列值,从而保证效率,但效果是一样的,这也是我们看到的数字签名的原理。

    2019-09-15
    2
  • anginiit
    老师 我想问一下 ,那个快速验证,加密的内容是什么 ,服务器端解密后 是怎么知道内容是正确的呢?

    作者回复: 加密的内容包含了前面连接过程所有传输的数据,并进行摘要,得到的这个数据串,发送到对端;而对端也拥有所有的数据,经过同样的摘要,那么它应该和对端传过来的摘要相等。这个过程对于客户端和服务端来说都是类似的。

    2019-09-13
    3
收起评论
11
返回
顶部