【前端指南】HTTP与HTTPS

HTTP与HTTPS

HTTP

  • 超文本传输协议,是一个基于请求与响应,无状态的应用层协议,常基于TCP/IP协议传输数据,互联网上应用广泛的一种网络协议,所有的WWW文件必须遵守这个标准,设计初衷是为了提供一种发布和接收HTML页面的方法
    • 定义了浏览器(万维网客户进程)怎样想万维网服务器请求万维网文档,以及服务器怎样把文档传送给浏览器;
    • 从层次的角度看,HTTP是面向事务的应用层协议,规定了浏览器和服务器之间的请求和相应的格式与规则,十万位网上能够可靠地传输文件(文本,声音,图像等各种多媒体文件)的重要基础
HTTP操作过程
  • 用户单击鼠标后发生的事件顺序
    1. 浏览器分析链接指向页面的URL
    2. 浏览器向DNS请求解析IP地址
    3. 域名系统DNS解析获取到服务器的IP地址
    4. 浏览器与该服务器建立TCP连接
    5. 浏览器发出HTTP请求GET
    6. 服务器通过HTTP相应把文件发送给浏览器
    7. 释放TCP连接
    8. 浏览器解释文件,并将web页显示给用户
HTTP报文格式

报文格式

HTTPS

  • 是身披SSL外壳的HTTP
  • 是一种通过计算机网络进行安全通信的传输协议,经由HTTP进行通信,利用SSL/TLS建立通信全信道,加密数据包
  • 使用的主要目的是提供对网站服务器的身份认证,同时保护交换数据的隐私与完整性
SSL
  • 安全套接字secure socket layer协议是web浏览器与web服务器之间安全交换信息的协议,提供两个基本的安全服务
    • 鉴别与保密
三个特性
  1. 保密:在握手协议中定义了会话密钥后,所有消息都被加密
  2. 鉴别:可选的客户端认证和强制的服务端认证
  3. 完整性:传送的消息包括消息完整性检查
SSL的位置
  • 结余应用层和TCP层之间,应用层数据不再直接传递给传输层,而是传递给SSL层,SSL层对应用层收到的数据进行加密,并增加自己的SSL头
工作原理
  1. 握手协议

    • 客户机和服务器用SSL连接通信时使用的第一个子协议,握手协议包括客户机与服务器之间的一系列消息
    • 允许服务器和客户机相互验证,协商加密的MAC算法以及保密密钥,用来保护在SSL记录中发送的数据
    • 握手协议是在应用程序的数据传输之前使用的
    • 包含以下三个字段:
      1. type:表示10种消息类型之一
      2. length:表示消息长度字节数
      3. content:与消息相关的参数
    • 握手协议的四个阶段
      1. 启动逻辑连接,建立这个连接的安全能力
        • 客户机向服务器发出client hello消息并等待服务器响应,随后服务器向客户机返回server hello消息,对client hello消息中的消息进行确认
        • clienthello客户发送clienthello信息,包含以下内容:
          1. 客户可以支持的SSL最高版本号
          2. 一个用于生成主秘密的32字节的随机数
          3. 一个确定会话的会话ID
          4. 一个客户端可以支持的密码套件列表
            • 密码套件格式:每个套间以SSL开头,紧跟密钥交换算法,用with把密钥交换算法,加密算法,散列算法分开
          5. 一个客户端可以支持的压缩算法列表
        • serverhello服务器用serverhello信息应答客户,包含以下内容:
          1. 一个SSL版本号,取客户端支持的最高版本号和服务端支持的最高版本号中的较低者
          2. 一个用于生成主秘密的32字节的随机数
          3. 会话ID
          4. 从客户端的密码套件列表中选择一个密码套件
          5. 从客户端的压缩方法的列表中选择的压缩方法
        • 此阶段之后,客户端服务端知道以下内容;
          1. SSL版本
          2. 密钥交换,信息验证和加密算法
          3. 压缩方法
          4. 有关密钥生成的两个随机数
      2. 服务器鉴别与密钥交换
        • 本阶段所有消息的唯一发送方,客户机是所有消息的唯一接收方
        • 该阶段分为4步:
          1. 证书:服务器将数字证书和到根CA整个链发给客户端,使客户端能用服务器证书中得 服务器公钥认证服务器
          2. 服务器密钥交换(可选):视密钥交换算法而定
          3. 证书请求:服务端可能会要求客户自身进行验证
          4. 服务器握手完成:第二阶段的结束,第三阶段开始的信号
      3. 客户机鉴别与密钥交换
        • 本阶段所有消息的唯一发送方,服务器是所有消息的唯一接收方
        • 该阶段分为以下三步:
          1. 证书(可选):为了对服务器证明自身,客户要发送一个证书信息,是可选的,在IIS中可以配置强制客户端证书认证
          2. 客户机密钥交换:客户端将预备主密钥发送给服务端,会使用到服务端的公钥进行加密
          3. 证书验证(可选):对预备秘密和随机数进行签名,证明拥有证书的公钥
      4. 完成
        • 使服务器结束
        • 分为4步:
          1. 来自客户机:改变密码规格值
          2. 来自客户机:MD5散列+SHA散列
          3. 来自服务器:改变密码规格值
          4. MD5散列+SHA散列
      5. 密钥生成过程:
        • 密钥
  2. 记录协议

    • 握手成功之后使用,客户机和服务器鉴别对方和确定安全信息交换使用的算法后,进入SSL记录协议,记录协议向SSL连接提供两个服务
      1. 保密性:使用握手协议定义的秘密密钥实现
      2. 完整性:握手协议定义了MAC,用于保证消息完整性
      3. 过程;
        • 过程
  3. 警报协议

    • 客户机和服务器发现错误时,向对方发送一个警报消息,如果是致命错误,则算法立即关闭SSL连接,双方还会先删除相关的会话号,秘密和密钥
    • 每个警报信息共2个字节
      • 第1个字节表示错误类型,如果是警报,则值为1,如果是致命错误,则值为2
      • 第2个字节指定实际错误类型

HTTP和HTTPS

HTTP特点
  1. 无状态:协议对客户端没有状态存储,对事物处理没有记忆能力
    • 同一客户两次访问同一服务器上的页面,服务器的响应与第一次被访问时的相同
    • 解决策略:
      1. 通过cookie/session技术
      2. HTTP持久连接
  2. 无连接:HTTP/1.1之前,由于无状态,每次请求需要和服务期重新建立连接
  3. 基于请求和响应:基本的特征,由客户端发起请求,服务端响应
  4. 简单快速灵活
  5. 通信使用明文,请求和响应不会对通信放进行确认,无法保护数据的完整性
  • 传输数据以明文形式显示
HTTPS特点
  • 基于HTTP协议,通过SSL或TLS提供加密处理数据,验证对方身份以及数据完整性保护,通过抓包可以看出数据不是明文传输
  1. 内容加密:采用混合加密技术,中间这无法直接查看铭文内容
    • 加密技术:
      • 混合加密:结合非对称加密和对称加密技术。客户端使用对称加密生成密钥对传输数据进行加密,然后使用非对称加密的公钥再对秘钥进行加密,所以网络上传输的数据是被秘钥加密的密文和用公钥加密后的秘密秘钥,因此即使被黑客截取,由于没有私钥,无法获取到加密明文的秘钥,便无法获取到明文数据
      • 数字摘要:通过单向hash函数对原文进行哈希,将需加密的明文“摘要”成一串固定长度(如128bit)的密文,不同的明文摘要成的密文其结果总是不相同,同样的明文其摘要必定一致,并且即使知道了摘要也不能反推出明文
      • 数字签名技术:数字签名建立在公钥加密体制基础上,是公钥加密技术的另一类应用。它把公钥加密技术和数字摘要结合起来,形成了实用的数字签名技术。
    • 加密后实现:
      • 接收方能够证实发送方的真实身份
      • 发送饭时候不能否认所发送过的报文
      • 接收方或非法这不能伪造,篡改报文
  2. 验证身份:通过整数认证客户端访问的是自己的服务器
  3. 保护数据完整性:防止传输的内容被中间人冒充或者篡改

HTTP通信传输

  • 为何需要三次握手?
    • 防治意识小连接请求报文段突然又传送到服务端,产生错误
    • 解决延迟和重复问题,保证数据的可能性和安全性
  • 为什么需要四次挥手呢?
    • TCP是全双工模式,当client发出FIN报文段时,只是表示client已经没有数据要发送了,client告诉server,它的数据已经全部发送完毕了
    • 但是,这个时候client还是可以接受来server的数据
    • 当server返回ACK报文段时,表示它已经知道client没有数据发送了,但是server还是可以发送数据到client的
    • 当server也发送了FIN报文段时,这个时候就表示server也没有数据要发送了,就会告诉client,我也没有数据要发送了,如果收到client确认报文段,之后彼此就会愉快的中断这次TCP连接

HTTPS实现原理

SSL的建立连接过程
  • SSL

  • 步骤:

    1. client向server发送请求https://baidu.com,然后连接到server的443端口,发送的信息主要是随机值1和客户端支持的加密算法
    2. server接收到信息之后给予client响应握手信息,包括随机值2和匹配好的协商加密算法,这个加密算法一定是client发送给server加密算法的子集
    3. server给client发送第二个响应报文是数字证书。服务端必须要有一套数字证书,可以自己制作,也可以向组织申请。区别就是自己颁发的证书需要客户端验证通过,才可以继续访问,而使用受信任的公司申请的证书则不会弹出提示页面,这套证书其实就是一对公钥和私钥。传送证书,这个证书其实就是公钥,只是包含了很多信息,如证书的颁发机构,过期时间、服务端的公钥,第三方证书认证机构(CA)的签名,服务端的域名信息等内容
    4. 客户端解析证书,这部分工作是由客户端的TLS来完成的,首先会验证公钥是否有效,比如颁发机构,过期时间等等,如果发现异常,则会弹出一个警告框,提示证书存在问题。如果证书没有问题,那么就生成一个随即值(预主密钥)
    5. 客户端认证证书通过之后,接下来是通过随机值1、随机值2和预主秘钥组装会话秘钥。然后通过证书的公钥加密会话秘钥
    6. 传送加密信息,这部分传送的是用证书加密后的会话秘钥,目的就是让服务端使用秘钥解密得到随机值1、随机值2和预主秘钥
    7. 服务端解密得到随机值1、随机值2和预主秘钥,然后组装会话秘钥,跟客户端会话秘钥相同
    8. 客户端通过会话秘钥加密一条消息发送给服务端,主要验证服务端是否正常接受客户端加密的消息
    9. 同样服务端也会通过会话秘钥加密一条消息回传给客户端,如果客户端能够正常接受的话表明SSL层连接建立完成了。
如何保证服务器给客户端发的公钥是真正的公钥,而不是中间人伪造的公钥?
证书如何安全传输,被掉包了怎么办?
  • 验证证书安全性过程
    • 当客户端收到这个证书之后,使用本地配置的权威机构的公钥对证书进行解密得到服务端的公钥和证书的数字签名,数字签名经过CA公钥解密得到证书信息摘要
    • 然后证书签名的方法计算一下当前证书的信息摘要,与收到的信息摘要作对比,如果一样,表示证书一定是服务器下发的,没有被中间人篡改过。因为中间人虽然有权威机构的公钥,能够解析证书内容并篡改,但是篡改完成之后中间人需要将证书重新加密,但是中间人没有权威机构的私钥,无法加密,强行加密只会导致客户端无法解密,如果中间人强行乱修改证书,就会导致证书内容和证书签名不匹配
  • 那第三方攻击者能否让自己的证书显示出来的信息也是服务端呢?(伪装服务端一样的配置)
    • 显然这个是不行的,因为当第三方攻击者去CA那边寻求认证的时候CA会要求其提供例如域名的whois信息、域名管理邮箱等证明你是服务端域名的拥有者,而第三方攻击者是无法提供这些信息所以他就是无法骗CA他拥有属于服务端的域名
  • 数字证书内容
    • 包括了加密后服务器的公钥、权威机构的信息、服务器域名,还有经过CA私钥签名之后的证书内容(经过先通过Hash函数计算得到证书数字摘要,然后用权威机构私钥加密数字摘要得到数字签名),签名计算方法以及证书对应的域名

总结

  • 安全性考虑:
    • HTTPS协议的加密范围也比较有限,在黑客攻击、拒绝服务攻击、服务器劫持等方面几乎起不到什么作用
    • SSL证书的信用链体系并不安全,特别是在某些国家可以控制CA根证书的情况下,中间人攻击一样可行
      • 中间人攻击(MITM攻击)是指,黑客拦截并篡改网络中的通信数据。又分为被动MITM和主动MITM,被动MITM只窃取通信数据而不修改,而主动MITM不但能窃取数据,还会篡改通信数据。最常见的中间人攻击常常发生在公共wifi或者公共路由上。
  • 成本考虑:
    • SSL证书需要购买申请,功能越强大的证书费用越高
    • SSL证书通常需要绑定IP,不能在同一IP上绑定多个域名,IPv4资源不可能支撑这个消耗(SSL有扩展可以部分解决这个问题,但是比较麻烦,而且要求浏览器、操作系统支持,Windows XP就不支持这个扩展,考虑到XP的装机量,这个特性几乎没用)
    • 根据ACM CoNEXT数据显示,使用HTTPS协议会使页面的加载时间延长近50%,增加10%到20%的耗电
    • HTTPS连接缓存不如HTTP高效,流量成本高
    • HTTPS连接服务器端资源占用高很多,支持访客多的网站需要投入更大的成本
    • HTTPS协议握手阶段比较费时,对网站的响应速度有影响,影响用户体验。比较好的方式是采用分而治之,类似12306网站的主页使用HTTP协议,有关于用户信息等方面使用HTTPS
  • HTTPS 的优点
    1. 使用 HTTPS 协议可认证用户和服务器,确保数据发送到正确的客户机和服务器
    2. HTTPS 协议是由SSL+HTTP 协议构建的可进行加密传输、身份认证的网络协议,要比 HTTP 协议安全,可防止数据在传输过程中不被窃取、修改,确保数据的完整性
    3. HTTPS 是现行架构下最安全的解决方案,虽然不是绝对安全,但它大幅增加了中间人攻击的成本。
  • HTTPS 的缺点(对比优点)
    1. HTTPS 协议握手阶段比较费时,会使页面的加载时间延长近
    2. HTTPS 连接缓存不如 HTTP 高效,会增加数据开销,甚至已有的安全措施也会因此而受到影响
    3. HTTPS 协议的安全是有范围的,在黑客攻击、拒绝服务攻击和服务器劫持等方面几乎起不到什么作用
    4. SSL 证书通常需要绑定 IP,不能在同一 IP 上绑定多个域名,IPv4 资源不可能支撑这个消耗
    5. 成本增加,部署 HTTPS 后,因为 HTTPS 协议的工作要增加额外的计算资源消耗,例如 SSL 协议加密算法和 SSL 交互次数将占用一定的计算资源和服务器成本
    6. HTTPS 协议的加密范围也比较有限。最关键的,SSL 证书的信用链体系并不安全,特别是在某些国家可以控制 CA 根证书的情况下,中间人攻击一样可行
  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值