HTTPS | 青训营笔记

128 阅读11分钟

这是我参与「第三届青训营 -后端场」笔记创作活动的的第5篇笔记

1、HTTP 的缺陷

  • 通信使用明文(不加密),内容可能会被窃听
  • 不验证通信方的身份,有可能遭遇伪装
  • 无法证明报文的完整性,所以有可能已遭篡改
1.1、明文窃听
1.1.1、明文窃听
  • 由于HTTP本身不具备加密的功能,无法做到对通信整体进行加密。即,HTTP报文使用明文(指未经过加密的报文)方式发送。
  • 按 TCP/IP协议族的工作机制,通信内容在所有的通信线路上都有可能遭到窥视
  • 即使已经过加密处理的通信,也会被窥视到通信内容,这点和未加密的通信是相同的。只是说如果通信经过加密,就有可能让人无法破解报文信息的含义,但加密处理后的报文信息本身还是会被看到的。
1.1.2、通信加密
  • 一种方式就是将通信加密。HTTP协议中没有加密机制,但可以通过和SSL ( Secure Socket Layer,安全套接层)或TLS ( Transport Layer Security,安全层传输协议)的组合使用,加密HTTP的通信内容
  • 用SSL建立安全通信线路之后,就可以在这条线路上进行HTTP通信了。与SSL组合使用的HTTP被称为HTTPS ( HTTP Secure. 超文本传输安全协议)或HTTP over SSL。

https_channel.png

1.1.3、内容加密
  • 还有一种将参与通信的内容本身加密的方式。由于HTTP协议中没有加密机制,那么就对 HTTP协议传输的内容本身加密。即把HTTP报文里所含的内容进行加密处理。
  • 在这种情况下,客户端需要对HTTP报文进行加密处理后再发送请求。

http_encryption.png

  • 为了做到有效的内容加密,前提是要求客户端和服务器同时具备加密和解密机制。
  • 由于该方式不同于SSL 或TLS将整个通信线路加密处理,所以内容仍有被篡改的风险。
1.2、身份验证
  • 在HTTP协议通信时,由于不存在确认通信方的处理步骤,任何人都可以发起请求。
  • 另外,服务器只要接收到请求,不管对方是谁都会返回一个响应。
1.2.1、存在隐患
  • 无法确定请求发送至目标的Web服务器是否是按真实意图返回响应的那台服务器。有可能是已伪装的Web服务器。
  • 无法确定响应返回到的客户端是否是按真实意图接收响应的那个客户端。有可能是已伪装的客户端。
  • 无法确定正在通信的对方是否具备访问权限。因为某些Web 服务器上保存着重要的信息,只想发给特定用户通信的权限。
  • 即使是无意义的请求也会照单全收。无法阻止海量请求下的 DoS攻击(Denial of Service,拒绝服务攻击)
1.2.2、证书
  • 虽然使用HTTP协议无法确定通信方,但如果使用SSL /TLS则可以。SSL不仅提供加密处理,而且还使用了一种被称为证书的手段,可用于确定方。
  • 证书由值得信任的第三方机构CA颁发,证明服务器和客户端是实际存在的。
1.3、报文完整性
  • 所谓完整性是指信息的准确度。若无法证明其完整性,通常也就意味着无法判断信息是否准确,可能被篡改。
  • 由于HTTP协议无法证明通信的报文完整性,因此,在请求或响应送出之后直到对方接收之前的这段时间内,即使请求或响应的内容遭到篡改,也没有办法获悉。
  • 像这样,请求或响应在传输途中,遭攻击者拦截并篡改内容的攻击尔为中间人攻击( Man-in-the-Middle attack,MITM )。

tamper.png

1.3.1、防止篡改
  • 虽然有使用HTTP协议确定报文完整性的方法,但事实上并不捷、可靠。
  • 其中常用的是MD5和 SHA-1等散列值校验的方法,以及用来确认文件的数字签名方法。
  • 用这些方法也依然无法百分百保证确认结果正确。因为校验方法本身被改写的话,用户是没有办法意识到的。
  • 为了有效防止这些弊端,有必要使用HTTPS。SSL提供认证和加密处理及摘要功能。仅靠HTTP确保完整性是非常困难的。

2、HTTPS

  • HTTP+SSL/TLS (加密、认证、完整性保护) =HTTPS
  • 之前 SSL 出过三个大版本,当它发展到第三个大版本的时候才被标准化,成为 TLS(,并被当做 TLS1.0 的版本,即TLS1.0 = SSL3.1

https.png

  • HTTPS并非是应用层的一种新协议。只是HTTP通信接口部分用SSL和TLS协议代替。
  • 通常,HTTP直接和TCP通信。当使用SSL时,则演变成先和SSL通信,再由SSL和 TCP通信。

https_模型.png

2.1、交换密钥的加密技术
  • SSL采用一种叫做公开密钥加密(Public-key cryptography )的加密处理方式。
  • 加密和解密都会用到密钥。没有密钥就无法对密码解密,任何人只要持有密钥就能解密了。
2.1.1、共享密钥的困境
  • 加密和解密同用一个密钥的方式称为共享密钥加密,也被叫做对称密钥加密
  • 以共享密钥方式加密时必须将密钥也发给对方。
  • 发送密钥就有被窃听的风险,但不发送,对方就不能解密。密钥若能够安全发送,那数据也能安全送达。
2.1.2、公开密钥加密
  • 公开密钥加密方式很好地解决了共享密钥加密的困难。
  • 公开密钥加密使用一对非对称的密钥。一把叫做私有密钥( private key),另一把叫做公开密钥( public key)。
  • 使用公开密钥加密方式,发送密文的一方使用对方的公开密钥进行加密处理,对方收到被加密的信息后,再使用自己的私有密钥进行解密。利用这种方式,不需要发送用来解密的私有密钥
  • 另外,要想根据密文和公开密钥,恢复到信息原文是异常困难的,因为解密过程就是在对离散对数进行求值,这并非轻而易举就能办到。
2.1.3、HTTPS采用混合加密
  • HTTPS采用共享密钥加密和公开密钥加密两者并用的混合加密机制。
  • 若密钥能够实现安全交换,那么有可能会考虑仅使用公开密钥加密来通信。但是公开密钥加密与共享密钥加密相比,其处理速度要慢。
  • 所以应充分利用两者各自的优势,将多种方法组合起来用于通信。在交换密钥环节使用公开密钥加密方式,之后的建立通信交换报文阶段则使用共享密钥加密方式。
2.2、证书
2.2.1、证明公开密钥正确性的证书
  • 公开密钥加密方式存在一些问题,那就是无法证明公开密钥本身就是货真价实的公开密钥,或许在公开密钥传输途中,真正的公开密钥已经被攻击者替换掉。

  • 为了解决上述问题,使用由数字证书认证机构(CA,Certificate Authority)和其相关机关颁发的公开密钥证书。

    • 服务器会将由数字证书认证机构颁发的公钥证书发送给客户端,以进行公开密钥加密方式通信。公钥证书也可叫做数字证书或直接称为证书。

    • 接到证书的客户端可使用数字证书认证机构的公开密钥,对证书上的数字签名进行验证,一旦验证通过,客户端便可明确两件事:

      • 认证服务器的公开密钥的是真实有效的数字证书认证机构。
      • 服务器的公开密钥是值得信赖的。
  • 认证机关的公开密钥必须安全地转交给客户端。使用通信方式时,如何安全转交是一件很困难的事,因此,多数浏览器开发商发布版本时,会事先在内部植入常用认证机关的公开密钥。

2.2.2、证明组织真实性的EV SSL证书
  • EV SSL证书( Extended Validation SSL Certificate )的一个作用是用来证明作为通信一方的服务器是否规范,另外一个作用是可确认对方服务器背后运营的企业是否真实存在。
2.2.3、用以确认客户端的客户端证书
  • HTTPS中还可以使用客户端证书。以客户端证书进行客户端认证明服务器正在通信的对方始终是预料之内的客户端,其作用跟服务器证书如出一辙。
  • 但客户端证想获取证书时,用户得自行安装客户端证书。但由于客户端证书是要付费购买的,且每张证书对应到每位用户也就意味着需支付和用户数对等的费用。
2.3、HTTPS 的安全通讯机制(SSL/TLS 协议握手)
  • 以 TLS/1.2 握手为例

TLS.png

2.3.1、step 1: Client Hello
  • 首先,浏览器发送 client_random、TLS版本、加密套件列表。

    • client_random ,用来最终 secret 的一个参数。
    • 加密套件列表
TLS_ECDHE_WITH_AES_128_GCM_SHA256
​
// 意思是`TLS`握手过程中,使用`ECDHE`算法生成`pre_random`
// 128位的`AES`算法进行对称加密,在对称加密的过程中使用主流的`GCM`分组模式
// 最后一个是哈希摘要算法,采用`SHA256`算法。
2.3.2、step 2: Server Hello

服务器返回如下:

  • server_random也是最后生成secret的一个参数
  • 同时确认 TLS 版本、需要使用的加密套件和自己的证书
  • server_params
2.3.3、step 3: Client 验证证书,生成secret
  • 客户端验证服务端传来的证书签名是否通过,如果验证通过,则传递client_params这个参数给服务器。
  • 接着客户端通过ECDHE算法计算出pre_random,其中传入两个参数:server_paramsclient_params。(由于ECDHE基于椭圆曲线离散对数,这两个参数也称作椭圆曲线的公钥
  • 客户端现在拥有了client_randomserver_randompre_random,接下来将这三个数通过一个伪随机数函数来计算出最终的secret
2.3.4、step 4: Server 生成 secret
  • 服务端接收客户端的client_params
  • 开始用ECDHE算法生成pre_random,接着用和客户端同样的伪随机数函数生成最后的secret
2.4、SSL 速度慢
  • 处理慢:由于HTTPS需要做服务器、客户端双方加密及解密处理,因此会消耗CPU和内存等硬件资源
  • 通信慢:而当HTTP使用SSL 时,它的处理速度会变慢。和HTTP通信相比,SSL通信部分消耗网络资源。而SSL通信部分,又因为要对通信进行处理,所以时间上又会延长
  • 和使用HTTP相比,网络负载可能会变慢2到100倍。除去和TCP连接、发送HTTP请求·响应以外,还必须进行SSL通信,因此整体上处理通信量不可避免会增加。
2.5、为什么不一直用HTTPS?
  • 与纯文本通信相比,加密通信会消耗更多的CPU及内存资源。如果每次通信都加密,会消耗相当多的资源。因此,如果是非敏感信息则使用HTTP通信。
  • 要进行HTTPS通信,证书是必不可少的。而使用的证书必须向认证机构(CA)购买。证书价格可能会根据不同的认证机构略有不同。

3、数字证书

  • 公钥证书也可叫做数字证书或直接称为证书。
3.1、数字证书
  • 证书的主要内容有:公钥(Public Key)、ISSUER(证书的发布机构)、Subject(证书持有者)、证书有效期、签名算法、指纹及指纹算法
3.2、指纹与签名
  • 指纹可以理解为证书身份的唯一代表,是用来保证证书的完整性的,确保证书没有被修改过。
  • 证书在发布之前,CA机构对证书的内容用指纹算法(一般是sha1或sha256)计算得到一个hash值,这个hash值就是指纹
  • 签名是在信息后面加上的一段数字串,可以证明该信息有没有被修改过。数字证书在发布的时候,CA机构将证书的指纹和指纹算法通过自己的私钥加密得到的就是证书的签名
3.3、证书验证过程
  • 在验证证书的时候,首先通过机构的根公钥去解密证书的签名
  • 解密成功的话会得到证书的指纹和指纹算法,指纹是一个hash值,它代表着证书的原始内容
  • 再通过指纹算法计算证书内容得到另外一个hash值,如果这两个hash值相同,则代表证书没有被篡改过

参考连接