RFC4251阅后总结

ps: 线索里的tab键都被吞了,正在处理中


来源

来源 https://datatracker.ietf.org

  • IETF Internet Engineering Task Force
  • RFC Request for Comment

    线索

  • 设计架构

    • 主机key
      • 两个信任模型
        • 有CA
        • 无CA
    • 可拓展性
      • 方法标识符
        • 算法
        • 认证方式
    • 策略问题
      • 加密
      • 完整性
      • 压缩
      • 密钥交换
      • 公钥算法和格式
      • 身份认证方式
      • The operations that the user is allowed to perform using the
        connection protocol
    • 安全特性
      - 协商 negotiation
      
    • 本地化和字符集问题
    • 数据类型

      • 比特 byte
      • 布尔 boolean
      • 32位无符号整型 uint32
      • 64位无符号整型 uint64
      • 字符串 string
      • 多精度整型 mpint
      • 列表 name-list
    • 算法和方式命名 algorithm and method naming

      • implementation自带了一些算法和方式,但是可以自己加
  • 消息数字标识 Number Message

    • 传输层协议
    • 身份认证协议
    • 连接层协议
    • 反弹客户端协议 Reversed for client protocol
    • 本地拓展
  • IANA因素 IANA Consideration

    • Internet Assigned Numbers Authority
      • https://www.iana.org/
      • The global coordination of the DNS Root, IP addressing, and other Internet protocol resources is performed as the Internet Assigned Numbers Authority (IANA) functions.
      • 在协议中,其职能是分配协议的名称或专业术语(?)、注册协议(?)
    • RFC4250——IANA专业术语定义文档
  • 协议层次

    • 传输层协议
      • 对服务端的身份认证
      • session id (给上层协议使用)
    • 身份认证协议
      • 密码认证
      • 密钥认证
      • 基于主机的认证
    • 连接协议
      • 多路复用
  • 安全考虑

    • 伪随机数生成
    • 控制字符过滤
    • 传输
      • 保密性
      • 完整性
      • replay——确保数据在不同会话间的隔离,防止replay先前会话的数据
      • 中间人攻击——三种情形
      • DOS Denial of Service
      • Convert Channals 转换频道?
      • 前向加密 forward secrecy FS 或完美前向加密 perfect forward secrecy PFS
        • 确保即使私钥被泄漏或破解,过去的通信数据依旧不能被解密。一般方法是在非对称加密之前,用仅在通信会话期间有效,并且不会存储在长期存储介质中的临时密钥来加密
        • Diffie-Hellman key exchange
        • compromise
      • 密钥交换方式提供
        • 好像不是安全考虑
      • 流量分析
    • 身份认证
      • 弱传输
      • 调试信息 debug message
        • 可能暴露主机信息
      • 公钥认证
        • 前提:客户端是没有被渗透,私钥没有被拿到
        • 需要密码来加密私钥
        • smartcards
      • 密码认证
        • 前提:服务器是真的
        • 不然会暴露用户名和密码
      • 基于主机的认证
        • 前提:客户端没有被渗透
    • 连接
      • 端点安全?End Point Security
        • 如果服务端被入侵了,终端会话、端口转发、系统访问都被入侵
        • 如果客户端被入侵了,并且攻击者没被身份认证协议组织,其暴露的服务都容易收到攻击
      • 端口转发?
      • X11转发?

奇怪的单词

- compromise google翻译上的英语释义是妥协,但是文档中的意思好像是妥协(?)

总结

阐述了ssh的设计理念、总体架构和安全考虑,以及延伸了某些技术细节,介绍了更进一步学习的路径

问题

  1. 什么是CA
    1. CA认证的工作原理是什么
    2. 没有CA的那个信任模型到底是怎么工作的
  2. 如何自定义算法或认证方式
  3. 什么是IANA
    1. 其职责或目的是什么
    2. 其产出了什么文档、项目或(其他知识载体)?
  4. 什么是IETF
    1. 其职责或目的是什么
    2. 什么是RFC,我能从中获得什么?
    3. 除了RFC还有什么其他文档或(其他知识载体)?
  5. 关于传输层协议
    1. 如何构建加密session对话的?
    2. 如何确认服务端身份的?
    3. 安全风险在哪里
    4. 算法协商的流程?
  6. 关于身份认证协议
    1. 三种认证方式各自的原理和具体工作流程是什么
    2. 各自的漏洞是什么
    3. 认证协商的流程?
  7. 关于连接协议
    1. 什么是多路复用,具体技术细节和原理是什么?
  8. 如何猜解伪随机数
    1. 当前常用的生成看似随机的伪随机数的算法有哪些?
  9. 什么是Convert Channals?
  10. Diffie-Hellman key exchange原理是什么?
  11. 什么是端口转发和X11转发
  12. 最终问题:从传输层协议到连接协议,一套完整的工作流程是什么
    1. 常见的ssh工具有哪些
    2. 如何使用这些工具
    3. wireshark使用技巧有哪些
    4. 如何进行网络编程,用python模拟ssh工作流程

      下一跳

      进一步了解ssh

      [SSH-TRANS]——RFC4253
      [SSH-USERAUTH]——RFC4252
      [SSH-CONNECT]——RFC4254
      [SSH-NUMBERS]——RFC4250

      进一步了解IETF、IANA和RFC

      [RFC2119]
      [RFC2434]