《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将收到日志服务器的提交证实，并中继给最终用户
      • 椭圆曲线功能
        • 如今只有两种曲线获得普遍支持：secp256r一、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）
        • 引入一种新的会话恢复机制，不须要任何服务器端存储
        • 服务器取出全部的会话状态并进行加密，再以票证的方式发回客户端
        • 在接下来的链接中，客户端发回票证，服务器检查票证完整性，解密其内容并恢复会话