• 记录协议(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协议的更多相关文章

  1. HTTP权威指南读书笔记

    HTTP权威指南笔记 读书有两种境界,第一种境界是将书读薄,另一种是读厚.本篇文章就是HTTP权威指南的读书笔记,算是读书的第一重境界,将厚书读薄.文章对HTTP的一些关键概念做了比较详细的概述,通读 ...

  2. 经典的性能优化最佳实践 web性能权威指南 读书笔记

    web性能权威指南 page 203 经典的性能优化最佳实践 无论什么网络,也不管所用网络协议是什么版本,所有应用都应该致力于消除或减 少不必要的网络延迟,将需要传输的数据压缩至最少.这两条标准是经典 ...

  3. css权威指南读书笔记

    今天翻手机,翻到了许久之前看css权威指南时的笔记,遂移到博客中来. 1.属性选择器p.one class名为one的p元素p[class][name] 含有class和name属性的p元素p[cla ...

  4. css权威指南读书笔记-第10章浮动和定位

    这一章看了之后真是豁然开朗,之前虽然写了圣杯布局和双飞翼布局,有些地方也是模糊的,现在打算总结之后再写一遍. 以下都是从<css权威指南>中摘抄的我认为很有用的说明. 浮动元素 一个元素浮 ...

  5. cassandra权威指南读书笔记--安全

    认证和授权driver,JMX和cassandra服务器支持SSL/TLS,cassandra节点间也支持SSL/TLS.密码认证器cassandra还支持自定义,可插拔的认证机制.默认的认证器:or ...

  6. Javascript权威指南——读书笔记

    一.JavaScript核心语法 1.字符串中接受RegExp参数的方法 (1)text.search(pattern)返回首次匹配成功的位置 (2)text.match(pattern)返回匹配组成 ...

  7. HTTP权威指南读书笔记——第一章(HTTP概述)

    1.HTTP(Hypertext Transfer Protocol,超文本传输协议)是在万维网上进行通信时所使用的协议方案,HTTP是应用层协议,无需关心网络通信的细节,细节交给了传输层协议TCP/ ...

  8. cassandra权威指南读书笔记--Cassandra架构(1)

    结构 集群-->数据中心-->机架-->节点. cassandra尽可能将数据副本存在多个数据中心,然后读取(查询路由到)尽可能在本地数据中心. 为了去中心化和分区容错性,使用gos ...

  9. Java性能优化权威指南-读书笔记(一)-操作系统性能监控工具

    一:CPU 1. 用户态CPU是指执行应用程序代码的时间占总CPU时间的百分比. 系统态CPU是指应用执行操作系统调用的时间占总CPU时间的百分比.系统态CPU高意味着共享资源有竞争或者I/O设备之间 ...

随机推荐

  1. Proxmox VE虚拟化管理平台-相关概念

    请阅读此文用户务必阅读以下链接,其中包含了汉化作者.张自然copy过来的原因等信息. www.zhangziran.com/proxmox-docs-zh-cn.htm a Proxmox VE 集群 ...

  2. FPGA_VIP_V101 视频开发板 深入调试小结

    FPGA_VIP_V101 推出已经有半年有余,各项功能例程已移植完毕,主要参考crazybingo例程进行移植和结合开发板设计了几个实例例程 主要包含: 硬件配置: FPGA:EP4CE6E22C8 ...

  3. 使用Gin+WebSocket在HTML中无插件播放RTSP

    在后台的开发中遇到了对接显示摄像头视频流的需求.目前获取海康及大华等主流的摄像头的视频流使用的基本都是RTSP协议.不过HTML页面并不能直接播放RTSP协议的视频流,查询了一番各种网页播放RTSP的 ...

  4. java—将数据库读取的list转tree

    一.引言 有时候我们从数据库中读取出了一个表的数据,比如存储的是中国的省市县的ID.名称与父节点ID,读出来的数据并不是前台想要的,这个时候我们要想法处理一下都出来的list,将它变为一个树. 比如直 ...

  5. CCF-CSP题解 201509-3 模板生成系统

    简单的替换一下字符串. 注意数组开大点. #include<bits/stdc++.h> const int maxm = 100; const int maxn = 100; using ...

  6. diff命令的妙用

    在读<Writing compilers and Interpreters>一书时需要按章节修改代码,由于实在一行一行比对实在难受,于是想了个办法,利用diff命令比较两章之间代码的修改位 ...

  7. ES6 promise 使用示例

    new Promise(function (resolve, reject) { $.ajax({ type : 'post', data : formData, dataType : 'json', ...

  8. 《Java基础知识》Java static关键字以及Java静态变量和静态方法

    static 修饰符能够与变量.方法一起使用,表示是“静态”的. 静态变量和静态方法能够通过类名来访问,不需要创建一个类的对象来访问该类的静态成员,所以static修饰的成员又称作类变量和类方法.静态 ...

  9. SpringBoot整合dubbo(yml格式配置)

    yml文件 如果只作为服务的消费者不用暴露端口号,扫描的包名根据自己service改 dubbo: application: name: springboot-dubbo-demo #应用名 regi ...

  10. Ajax获取网页添加到div中

    1:利用DOM获取该 div 的 ID,然后清空该DIV的内容(如果你需要接着里面的内容添加可不要清空):需要注意点是清空最好用“ empty()  ”: 2: 把  async设成true ,否则又 ...