Published on

Http笔记(三)

Authors
  • avatar
    Name
    Et cetera
    Twitter

HTTP 代理

代理服务:服务本身不生产内容,而是处于中间位置转发上下游的请求和响应,具有双重身份:面向下游的用户时,表现为服务器,代表源服务器响应客户端的请求；而面向上游的源服务器时,又表现为客户端,代表客户端发送请求

代理的作用

计算机科学领域里的任何问题,都可以通过引入一个中间层来解决;如果一个中间层解决不了问题,那就再加一个中间层(doge)

代理最基本的一个功能就是负载均衡:因为在面向客户端时屏蔽了源服务器,客户端看到的只是代理服务器,源服务器究竟有多少台、是哪些 IP 地址都不知道。于是代理服务器就可以掌握请求分发的“大权”,决定由后面的哪台服务器来响应请求

  • 常用的负载均衡算法:

    • 轮询
    • 一致性哈希
    • 目的都是尽量把外部的流量合理地分散到多台源服务器,提高系统的整体资源利用率和性能

  • 在负载均衡的同时,代理服务还可以执行更多的功能:

    • 健康检查:使用“心跳”等机制监控后端服务器,发现有故障就及时“踢出”集群,保证服务高可用
    • 安全防护:保护被代理的后端服务器,限制 IP 地址或流量,抵御网络攻击和过载
    • 加密卸载:对外网使用 SSL/TLS 加密通信认证,而在安全的内网不加密,消除加解密成本
    • 数据过滤:拦截上下行的数据,任意指定策略修改请求或者响应
    • 内容缓存:暂存、复用服务器响应

代理相关字段

代理服务器需要用字段Via表明代理的身份,该字段请求头或响应头都可以出现

代理协议

  • 代理协议:
    • 由知名的代理软件 HAProxy 所定义,也是一个“事实标准”
    • 有 v1 和 v2 两个版本,v1 和 HTTP 差不多,也是明文,而 v2 是二进制格式。今天只介绍比较好理解的 v1,它在 HTTP 报文前增加了一行 ASCII 码文本,相当于又多了一个头

总结

  • HTTP 代理就是客户端和服务器通信链路中的一个中间环节,为两端提供代理服务
  • 代理处于中间层,为 HTTP 处理增加了更多的灵活性,可以实现负载均衡、安全防护、数据过滤等功能
  • 代理服务器需要使用字段Via标记自己的身份,多个代理会形成一个列表
  • 如果想要知道客户端的真实 IP 地址,可以使用字段X-Forwarded-For和X-Real-IP
  • 专门的代理协议可以在不改动原始报文的情况下传递客户端的真实 IP

缓存代理

客户端上的缓存控制:能够减少响应时间、节约带宽,提升客户端的客户体验

HTTP 的服务器缓存功能主要由代理服务器来实现(即缓存代理)

缓存代理服务

代理服务收到源服务器发来的响应数据后需要做两件事.第一个当然是把报文转发给客户端,而第二个就是把报文存入自己的 Cache 里

下一次再有相同的请求,代理服务器就可以直接发送 304 或者缓存数据,不必再从源服务器那里获取.这样就降低了客户端的等待时间,同时节约了源服务器的网络带宽

源服务器的缓存控制

要区分客户端上的缓存和代理上的缓存,可以使用两个新属性private和public

private表示缓存只能在客户端保存,是用户“私有”的,不能放在代理上与别人共享.而public的意思就是缓存完全开放,谁都可以存,谁都可以用

客户端的缓存控制

HTTPS 是什么? SSL/TLS 又是什么?

  • 为什么要有 HTTPS?

    • 简单的回答是“因为 HTTP 不安全”
    • 由于 HTTP 天生“明文”的特点,整个传输过程完全透明,任何人都能够在链路中截获、修改或者伪造请求 / 响应报文,数据不具有可信性

  • 什么是安全?

    • 如果通信过程具备了四个特性,就可以认为是安全的,这四个特性是:机密性、完整性、身份认证和不可否认

  • 什么是 HTTPS?

    • HTTPS 其实是一个“非常简单”的协议,RFC 文档很小,只有短短的 7 页,里面规定了新的协议名https,默认端口号 443,至于其他的什么请求
    • 应答模式、报文结构、请求方法、URI、头字段、连接管理等等都完全沿用 HTTP,没有任何新的东西

对比 HTTP 和 HTTPS 的结构,HTTPS基于SSL/TLS后,收发报文不再使用 Socket API,而是调用专门的安全接口

SSL/TLS

  • SSL:
    • 位于第五层(会话层),有 v2 和 v3 两个版本,v1 因为有严重缺陷所以从未发布
    • SSL 发展到 v3 时已经证明了它自身是一个非常好的安全通信协议,于是互联网工程组 IETF 在 1999 年把它改名为 TLS(传输层安全,Transport Layer Security),正式标准化,版本号从 1.0 重新算起,所以 TLS1.0 实际上就是 SSLv3.1
  • TLS:
    • 已经发展出了三个版本,分别是 2006 年的 1.1、2008 年的 1.2(目前应用最广泛的) 和 2018 年 的 1.3

OpenSSL:是一个著名的开源密码学程序库和工具包

小结

  • 因为 HTTP 是明文传输,所以不安全,容易被黑客窃听或窜改
  • 通信安全必须同时具备机密性、完整性,身份认证和不可否认这四个特性
  • HTTPS 的语法、语义仍然是 HTTP,但把下层的协议由 TCP/IP 换成了 SSL/TLS
  • SSL/TLS 是信息安全领域中的权威标准,采用多种先进的加密技术保证通信安全
  • OpenSSL 是著名的开源密码学工具包,是 SSL/TLS 的具体实现

加密

HTTP 安全需要增加机密性、完整性、身份认证和不可否认等特性

实现机密性最常用的手段是加密(encrypt),就是把消息用某种方式转换成谁也看不懂的乱码,只有掌握特殊“钥匙”的人才能再转换出原始文本。

这里的钥匙就叫做密钥(key),加密前的消息叫明文(plain text/clear text),加密后的乱码叫密文(cipher text),使用密钥还原明文的过程叫解密(decrypt),是加密的反操作,加密解密的操作过程就是加密算法

对称加密

如图:即加密和解密的密钥相同

  • 加密分组模式:对称算法还有一个“分组模式”的概念,它可以让算法用固定长度的密钥加密任意长度的明文,把小秘密(密钥)转化为大秘密(密文)

非对称加密

对称加密看上去好像完美地实现了机密性,但其中有一个很大的问题:如何把密钥安全地传递给对方,术语叫密钥交换.因为在对称加密算法中只要持有密钥就可以解密

它有两个密钥,一个叫公钥(public key),一个叫私钥(private key).两个密钥是不同的,不对称,公钥可以公开给任何人使用,而私钥必须严格保密

公钥和私钥有个特别的单向性,虽然都可以用来加密解密,但公钥加密后只能用私钥解密,反过来,私钥加密后也只能用公钥解密

非对称加密算法的设计要比对称算法难得多,在 TLS 里只有很少的几种,比如 DH、DSA、RSA、ECC 等

RSA 可能是其中最著名的一个,几乎可以说是非对称加密的代名词,它的安全性基于整数分解的数学难题,使用两个超大素数的乘积作为生成密钥的材料,想要从公钥推算出私钥是非常困难的

10 年前 RSA 密钥的推荐长度是 1024,但随着计算机运算能力的提高,现在 1024 已经不安全,普遍认为至少要 2048 位

ECC(Elliptic Curve Cryptography)是非对称加密里的“后起之秀”,它基于椭圆曲线离散对数的数学难题,使用特定的曲线方程和基点生成公钥和私钥,子算法 ECDHE 用于密钥交换,ECDSA 用于数字签名

混合加密:TLS 采用的

摘要算法

  • 实现完整性的手段主要是摘要算法(Digest Algorithm),也就是常说的散列函数、哈希函数(Hash Function):
    • 可以近似地理解成一种特殊的压缩算法
    • 也可以理解成特殊的单向加密算法,它只有算法,没有密钥,加密后的数据无法解密,不能从摘要逆推出原文

MD5(Message-Digest 5)、SHA-1(Secure Hash Algorithm 1),它们就是最常用的两个摘要算法,能够生成 16 字节和 20 字节长度的数字摘要.但这两个算法的安全强度比较低,不够安全,在 TLS 里已经被禁止使用了

目前 TLS 推荐使用的是 SHA-1 的后继者:SHA-2

SHA-2 实际上是一系列摘要算法的统称,总共有 6 种,常用的有 SHA224、SHA256、SHA384,分别能够生成 28 字节、32 字节、48 字节的摘要

完整性

摘要算法保证了数字摘要和原文是完全等价的.所以,我们只要在原文后附上它的摘要,就能够保证数据的完整性

不过摘要算法不具有机密性,如果明文传输,那么黑客可以修改消息后把摘要也一起改了,网站还是鉴别不出完整性

所以,真正的完整性必须要建立在机密性之上,在混合加密系统里用会话密钥加密消息和摘要,这样黑客无法得知明文,也就没有办法动手脚了

这有个术语,叫哈希消息认证码(HMAC)

数字签名

加密算法结合摘要算法,我们的通信过程可以说是比较安全了.但这里还有漏洞,就是通信的两个端点(endpoint)

使用私钥再加上摘要算法,就能够实现数字签名,同时实现身份认证和不可否认

数字签名的原理其实很简单,就是把公钥私钥的用法反过来,之前是公钥加密、私钥解密,现在是私钥加密、公钥解密。

但又因为非对称加密效率太低,所以私钥只加密原文的摘要,这样运算量就小的多,而且得到的数字签名也很小,方便保管和传输。

签名和公钥一样完全公开,任何人都可以获取。但这个签名只有用私钥对应的公钥才能解开,拿到摘要后,再比对原文验证完整性,就可以像签署文件一样证明消息确实是你发的

刚才的这两个行为也有专用术语,叫做签名和验签

只要你和网站互相交换公钥,就可以用签名和验签来确认消息的真实性,因为私钥保密,黑客不能伪造签名,就能够保证通信双方的身份

数字证书和 CA

综合使用对称加密、非对称加密和摘要算法,我们已经实现了安全的四大特性

但这里还有一个公钥的信任问题.因为谁都可以发布公钥,我们还缺少防止黑客伪造公钥的手段

CA(Certificate Authority,证书认证机构):它就像网络世界里的公安局、教育部、公证中心,具有极高的可信度,由它来给各个公钥签名,用自身的信誉来保证公钥无法伪造,是可信的

CA 对公钥的签名认证也是有格式的,不是简单地把公钥绑定在持有者身份上就完事了,还要包含序列号、用途、颁发者、有效时间等等,把这些打成一个包再签名,完整地证明公钥关联的各种信息,形成数字证书(Certificate)

证书体系的弱点

证书体系(PKI,Public Key Infrastructure)虽然是目前整个网络世界的安全基础设施,但绝对的安全是不存在的,它也有弱点,还是关键的“信任”二字

如果 CA 失误或者被欺骗,签发了错误的证书,虽然证书是真的,可它代表的网站却是假的

还有一种更危险的情况,CA 被黑客攻陷,或者 CA 有恶意,因为它（即根证书）是信任的源头,整个信任链里的所有证书也就都不可信了

  • 解决:
    1. 开发出了 CRL(证书吊销列表,Certificate revocation list)和 OCSP(在线证书状态协议,Online Certificate Status Protocol),及时废止有问题的证书
    2. 因为涉及的证书太多,就只能操作系统或者浏览器从根上“下狠手”了,撤销对 CA 的信任,列入黑名单,这样它颁发的所有证书就都会被认为是不安全的

小结

  1. 计算机领域里最常用的性能优化手段是时空转换,也就是时间换空间或者空间换时间,HTTP 缓存属于后者
  2. 缓存代理是增加了缓存功能的代理服务,缓存源服务器的数据,分发给下游的客户端
  3. Cache-Control字段也可以控制缓存代理,常用的有private``s-maxage``no-transform等,同样必须配合Last-modified``ETag等字段才能使用
  4. 缓存代理有时候也会带来负面影响,缓存不良数据,需要及时刷新或删除
  5. 加密算法的核心思想是“把一个小秘密（密钥）转化为一个大秘密（密文消息）”,守住了小秘密,也就守住了大秘密
  6. 对称加密只使用一个密钥,运算速度快,密钥必须保密,无法做到安全的密钥交换,常用的有 AES 和 ChaCha20
  7. 非对称加密使用两个密钥:公钥和私钥,公钥可以任意分发而私钥保密,解决了密钥交换问题但速度慢,常用的有 RSA 和 ECC
  8. 把对称加密和非对称加密结合起来就得到了“又好又快”的混合加密,也就是 TLS 里使用的加密方式
  9. 摘要算法用来实现完整性，能够为数据生成独一无二的“指纹”，常用的算法是 SHA-2
  10. 数字签名是私钥对摘要的加密，可以由公钥解密后验证，实现身份认证和不可否认
  11. 公钥的分发需要使用数字证书，必须由 CA 的信任链来验证，否则就是不可信的
  12. 作为信任链的源头 CA 有时也会不可信，解决办法有 CRL、OCSP，还有终止信任
View on GitHub