http的不足和https的诞生

_爱笑的鹦鹉_
664 阅读6分钟

http（hyperText Trandfer Protocol,超文本传输协议）的推广除了当年大佬的推广，最主要是因为它足够简单：不考虑加密处理，不考虑验证身份、不考虑报文完整性，只考虑如何传递超文本；

https的诞生均源自http因简单而导致的不足

  • http的不足：
  1. 使用明文传递，内容易被窃听；
  2. 不验证通信双方的身份，可能遭遇伪装；
  3. 不能证明报文是否完整，可能已遭篡改

下面详细说明为何会有这些不足和解决方法

  • 被窃听
  1. http协议基于TCP/IP网络，TCP/IP网络是当前互联网的基本架构，由于互联网是全世界共享的，并非个人私有物，所以很容易被窃听
  2. 在TCP/IP网络上，即便是加密处理的通信，其本身依然很容易被窃听到；使用最简单的抓包工具就能获取http的请求和相应内容
  3. 加密处理后的通信虽被窃听，但降低了原始内容被窥探的风险，所以仍是必要的；可以通过SSL层或TLS协议的组合使用，加密http的通信内容。与SSL组合使用的http被称为https

(用SSL建立安全通信线路)

  1. 还有一种将参与通信的内容本身加密的方式。但由于改加密要求客户端和服务器同时具备加密和解密机制，所以内容仍有被篡改的风险，稍后会加以说明

  • 身份伪装
  1. 通信双方均不验证对方是否是自己想通信的那个
  2. web服务器不能确定正在通信的对方是否具备访问权限
  3. 不能判定请求来自何方，出自谁手
  4. 无意义的请求也会全收，不能阻止海量请求下的DoS攻击

SSL提供了“证书”，可用于确定方：

  1. 证书：由值得信任的第三方机构颁发，用来证明通信中某一方的身份
  2. 伪造证书相对来说比较困难
  • 篡改报文
  1. http不能确认，发出的请求/响应和接收到的请求/响应是前后相同的，即不能保证报文完整性（完整性指信息的准确度）

可能出现以下这种情形：

2. https可以保证报文的完整性

http+加密+认证+完整性保护=https

当前ssl版本为3.0

https是身披SSL外壳的http

  • 以前，http直接和tcp通信
  • 现在，http先和SSL通信，再由SSL和tcp通信

ssl是独立于http的协议，很多协议都可以搭配ssl使用；ssl是当今世界上应用最广泛的网络安全技术

公开密钥加密技术

  • 这是ssl的加密处理方式，使用两把密钥的公开密钥加密——私有密钥和公有密钥
  • 发送密文的一方事先收到对方的公开密钥，然后用之对报文进行加密，发送给对方；对方收到后使用自己的私有密钥进行解密
  • 窃听者只能拿到密文和公开密钥，但是很难恢复到信息原文

https采用混合加密机制——共享密钥加密和公开密钥加密两者并用（共享密钥很简单，这里不做赘述）

  • 因为公开密钥加密耗时较多，所以在通信时，交换密钥环节使用公开密钥加密（加密的是共享密钥），之后交换报文时使用共享密钥加密

公开密钥加密的问题

  • 公开密钥在传输中仍是有可能被替换的，因为能被窃听者拿到
  • 为了解决以上问题，引入数字证书认证机构（CA）和其颁发的公开密钥证书
    1. 服务器的运营人员向CA提出公开密钥的申请
    2. CA判明申请者的身份后，对公开密钥做数字签名
    3. 将已签名的公开密钥放入公钥证书，颁发证书给运营人员
    4. 服务器将证书发给客户端，以进行公开密钥加密方式通信
  • 公钥证书也叫数字证书或直接称为证书
  • 接收到证书的客户端可通过CA的公开密钥，对证书上的数字签名进行验证；一旦验证通过，客户端便可明确两件事：CA真实有效；服务器的公开密钥值得信赖
  • 又来问题了：CA的公开密钥如何安全的传递给证书？一般的，浏览器开发商会给浏览器植入常用CA的公开密钥

证书

  • 分为证明服务器和客户端的；服务器的为EV SSL证书
  • 证明客户端的证书目前只在一些特定场景下使用：如支付业务。因为客户端如果想获取证书，需要用户自行安装客户端证书；但是证书是需要付费的，且不是所有用户都能理解证书的相关概念，导致他们很难自行安装
  • 客户端证书还有一个问题，即只能用来证明客户端实际存在，但是不能证明用户本人的真实有效性
  • CA机构本身也并非完全可靠，曾出现过黑客入侵后颁布伪造证书的情形
  • 自签名证书：安装了OpenSSL这套开源程序后，每个人都可以构建一套属于自己的认证机构，从而自己给自己颁发服务器证书；但是互联网上不承认。所以浏览器访问该服务器时，会显示：

完整性保护

  • 先了解https通信过程：

    1. 客户端发送client hello报文进行ssl通信。报文中包含客户端支持的ssl版本、加密组件列表
    2. 服务器可进行ssl通信，则回之server hello报文。报文中包含ssl版本及加密组件（从客户端传递的加密组件列表内筛选出来）
    3. 服务器发送certificate报文，报文中包含公开密钥证书
    4. 最后服务器发送server hello done报文，通知客户端第一次ssl握手结束
    5. 客户端回应之client key exchange报文，报文中包含共享加密的密钥，此密钥已被3步骤中的公开密钥加密
    6. 客户端继续发送change cipher spec报文，该报文提示服务器之后的通信会采用刚刚提供的密钥加密
    7. 客户端发送finished报文，该报文包含连接至今全部报文的整体校验值。这次握手协商是否能够成功，要以服务器是否能够正确解密该报文作为判定标准
    8. 服务同样发送change cipher spec报文
    9. 服务器同样发送finished报文,ssl连接建立完成
    10. 应用层协议通信，即发送http响应
    11. 客户端断开连接：发送close_notify报文；之后再发送tcp fin报文关闭与tcp的通信

  • 以上流程中，应用层发送数据时会附加一种叫mac（message authentication code）的报文摘要。mac能够查知报文是否遭到篡改，从而保护报文的完整性

https的缺点

  • https比http要慢2~100倍：因为必须进行ssl通信，且加密解密增加运算处理（现在有ssl加速器这种硬件来改善问题）
  • 购买证书会花费一定开销
avatar
文章
阅读
粉丝