《HTTPS权威指南》读书笔记——SSL/TLS协议

• 记录协议（record protocol）
  • 负责在传输连接上交换所有底层信息
  • 每一条记录以短标头开始，标头包含记录内容的类型、协议版本和长度
• 握手协议（handshake protocol）
  • 整个过程通常需要6——10个消息
    
  • 交换过程有许多变种
    1. 完整的握手，对服务器身份进行验证
       
    2. 恢复之前会话采用的简短握手
    3. 对客户端和服务器都进行身份验证的握手
  • 完整的握手
    • 交换各自支持的功能，对需要的连接参数达成一致
      
    • 验证出示的证书，或使用其他方式进行身份验证
      
    • 对将用于保护会话的共享主密钥达成一致
      
    • 验证握手消息并未被第三方团体修改
      
    • 细节：
      • Clienthello：发送客户端的功能和首选项给服务器，在连接建立后，当希望重协商、或者响应服务器的重协商请求时会发送。
        • version：客户端支持的最佳协议版本
          
        • Random：共32字节，28字节随机数，4字节额外信息，受客户端时钟影响（为了避免浏览器指纹采集，现在一般会对4字节时钟做扭曲）
        • Session ID：32字节随机数，用于和服务器重建会话，为空表示新建会话
        • cipher suit：客户端支持的所有密码套件，按优先级排列
          
        • Compression：客户端支持的压缩算法，默认无压缩
          
        • Extensions：由任意数量的扩展组成，携带额外数据
      • ServerHello：
        • 选择客户端提供的参数反馈客户端
        • 服务器无需支持客户端支持的最佳版本，如果服务器不支持客户端版本，可以提供其他版本以期待客户端可以接受
          
      • Certificate：
        • 用于携带服务器X.509证书链
        • 主证书必须第一个发送，中间证书按照正确的顺序跟在主证书之后
          
        • 服务器必须保证发送的证书和选择的算法套件一致
        • Certificate消息时可选的
          
      • ServerKeyExchange: 携带密钥交换的额外数据，取决于加密套件
      • ServerHelloDone：服务器已将所有预计的握手消息发送完毕
      • ClientkeyExchange：携带客户端为密钥交换提供的信息
      • ChangeCipherSpec：发送端已取得用以连接参数的足够的信息
      • Finish：握手完成，消息内容加密，双方可以交换验证，整个握手完整性所需的数据
        • 算法：verrify_data = PRF(master_secret , finished_label,hash(handshake_message))
          
  • 客户端身份验证
    • 只有已经经过身份验证的服务器才允许请求客户端身份验证
    • CertificateRequest：服务器对客户端进行身份验证并将其接受的证书的公钥和签名算法传送给客户端
      
    • CertificateVerrify：客户端通过CertificateVerify消息证明自己拥有的私钥与之前发送的客户端证书中的公钥相对应（消息中包含到这一步为止所有握手消息的签名）
      
  • 会话恢复
    • 希望恢复早先会话的客户端将适当的会话ID放入ClientHello消息，如果服务器愿意回复，则会将相同的会话ID放入到ServerHello消息中返回，接着使用先前协商的主密钥生成一套新的密钥，再切换到加密模式，发送Finished消息
      
  • 密钥交换
    • 会话安全性取决于主密钥（mater secret，48字节的共享密钥），密钥交换用于计算预主密钥（premaster secret），预主密钥是主密钥的来源
    • RSA：不支持前向保密（forward secrecy），客户端生成预主密钥，通过服务器公钥加密传递给服务器
    • DHE_RSA:临时DH算法，优点是支持前向保密，缺点是执行缓慢
    • ECDHE_RSA和ECDHE_ECDSA:临时椭圆曲线
    • RSA密钥交换：
      • 客户端生成预主密钥（46字节随机数），使用服务器公钥加密，将其包含在ClientKeyExchange中，服务器通过私钥解密，然后提取生成主密钥
      • 一旦服务器私钥被攻破，基于RSA的安全性将不复存在
    • Diffie-Hellman交换：
      • DH密钥交换需要6个参数：两个域参数（dh_p dh_g）由服务器选取；协商过程中客户端和服务器各自生成另外两个参数，相互发送一个参数到对端，经过结合计算，得到共享密钥
    • 椭圆曲线DH密钥交换（ECDH）：
      • 基于椭圆曲线（elliptic curve），代替了域参数的角色
        
  • 身份验证
    • 为了避免重复执行密码操作造成的巨大开销，身份验证与密钥交换紧紧捆绑在一起
      
    • 在RSA中，客户端生成随机值作为预主密钥，使用服务器公钥加密传递给服务器
    • 在DHE和ECDH中，服务器使用私钥签名参数，客户端用公钥解密
  • 加密
    • 序列加密：
      • 计算MAC值：包含记录序列号（防重放）、标头（防止未加密的标头被篡改）、明文
      • 加密明文和MAC
    • 分组加密：
      • 计算序列号、标头、明文MAC
        
      • 构造填充，确认加密前的数据长度正好是分组大小
        
      • 生成与分组长度一致的IV
    • 已验证的加密：
      • 使用关联数据的已验证加密（AEAD）
      • 生成一个唯一的64位nonce
      • 使用已验证加密算法加密明文，同时也将序列号和记录标头作为完整性验证依据的额外数据交给算法
      • 将nonce和密文一起发送
  • 重协商
    • 客户端证书：使用场景为，网站根路径不需要进行客户端证书验证，某个子域需要，当客户打算浏览子区域时，服务器发起重协商请求。
    • 隐藏消息： 如上场景中的重协商是在加密中进行的，避免了协商被监听，泄露客户端身份，Tor就是用这种方式进行重协商的
    • 改变加密级别
    • 协议允许客户端在任意时间简单的发送ClientHello消息请求重协商，如果服务器希望重协商，会发送HelloRequest
  • 警报协议
    • alert level表示警报严重程度：可取值warning和fatal
    • 严重程度为fatal的消息会立即终止当前连接并使会话失效
    • 发送告警通知的一端不会主动终止连接，而是交由接收端通过发送它自己的严重警报对该警告自行作出反应
      
  • 关闭连接
    • 关闭连接警告用于以有序的方式关闭TLS连接
    • 一旦一端决定关闭连接，会发送一个close_notify警报，另一端收到后，会丢弃任何还未写出的数据，并发送自己的 close_notify,在此之后收到的消息都被丢弃
  • 密码操作
    • 伪随机数（pseudorandom function，PRF）
      • 使用一条秘密、一颗种子、一个唯一标签
    • 主密钥
      • master_secret = PBR（pre_master_secret,‘master secret‘,clienthello.random,serverHello.random）
      • 使用不同的密钥交换得到的预主密钥长度不同
      • 使用客户端和服务器随机数作为种子，所以主密钥是随机的，且和协商握手绑定
        
    • 密钥生成
      • key_block = PRF(master_secret, "key expansion",server_random + client_random)
        
      • 共六个密钥，两个MAC密钥、两个加密密钥、两个初始化向量
      • 恢复会话使用的是之前的主密钥，但是由于随机数不同，因此生成的密钥也不同
  • 密码套件
    • 密码套件的元素属性：
      • 身份验证方法
      • 密钥交换方法
      • 加密算法
      • 加密密钥大小
      • 密码模式
      • MAC算法
      • PRF（只有TLS1.2一定使用，其他版本取决于各自协议）
      • 用于finished消息的散列函数（TLS1.2）
      • verify_data结构的长度（TLS1.2）
  • 扩展（Extention）
    • 扩展以扩展块的形式加在ClientHello和ServerHello的末尾
    • 扩展块由所需的扩展一个个堆叠而成
    • 每个扩展头是2字节扩展类型（唯一标志），后接扩展数据
    • 扩展的格式和期望的行为由每个扩展字节决定
    • 扩展通常用于通知支持某些新功能以及用于在握手阶段传递所需的额外数据
    • 常见TLS扩展
      • 应用层协议协商（ALPN）
        • 在TLS连接上协商不同的应用层协议
        • 支持ALPN的客户端在该字段中提供自己支持的应用层协议列表给服务器，服务器回决定使用的协议并使用相同的扩展向客户端通知其决定
      • 证书透明度（certificate transparency）
        • 通过保持所有公开的服务器的证书来改进互联网PKI
        • CA将每一张证书都提交给一组公开的日志服务器，CA将收到日志服务器的提交证明，并中继给最终用户
      • 椭圆曲线功能
        • 现在只有两种曲线得到广泛支持：secp256r1、secp384r1
      • 心跳（heartbeat）
        • RFC 6520
        • 支持连接保活功能，检测对端是否可用
        • 为TLS和DTLS发现路径最大传输单元（PMTU）
        • 心跳的目标定位是DTLS，因其工作在不可依赖的协议上
        • 客户端和服务器通过心跳扩展相互通告支持心跳
        • RFC只允许握手完成后发送心跳，但是，OpenSSL在TLS扩展交换完成以后就立即允许发送
      • 次协议协商
        • 客户端通过一个新的握手消息NextProtocol表明期望的应用层信息
      • 安全重协商
        • 用以验证重协商的双方仍是之前完成握手的两个团体
        • 开始通过扩展通告对方支持重协商
        • 后续通过提交先前握手信息作为证明：客户端以先前的Finished消息作为verify_data，服务器发送客户端的verrify_data+自己的verify_data
      • 服务器名称指示（server name indication SNI）
        • 通过server_name扩展实现
        • 为客户端提供机制，使得客户端可以向服务器通告自己希望访问的服务器名称，服务器基于该扩展可以查询到对应的证书信息
        • 实现了一个IP地址可以部署多张证书
      • 会话票证（session ticket）
        • 引入一种新的会话恢复机制，不需要任何服务器端存储
        • 服务器取出所有的会话状态并进行加密，再以票证的方式发回客户端
        • 在接下来的连接中，客户端发回票证，服务器检查票证完整性，解密其内容并恢复会话

《HTTPS权威指南》读书笔记——SSL/TLS协议

原文：https://www.cnblogs.com/yurang/p/11974160.html