主要观点：

• Opossum 攻击利用 TLS 认证机制中的问题使客户端和服务器失步，即便现有 ALPACA 对策已到位，攻击针对隐式 TLS 和机会型 TLS 应用层的小差异，若服务器支持两种方法会导致协议期望不匹配。
• 攻击中中间人攻击者拦截客户端隐式 TLS 连接并重定向到服务器机会型 TLS 端口，完成 TLS 握手后造成不同步，攻击者可延迟服务器响应。
• 管理员需知若使用 RFC 2817 应检查是否受影响，非 HTTP 协议问题更具理论性，仍建议迁移到隐式 TLS 变体。
• 攻击者可在 HTTPS 环境中造成资源混淆等多种攻击，其他协议也会破坏通道完整性假设。
• 攻击需服务器支持隐式和机会型 TLS、中间人位置及特定同步协议，HTTP 等协议受影响，其他协议场景更常见但无实际利用。
• 可通过 curl 测试网站是否 vulnerable，多数网站不 vulnerable，浏览器对此无影响，修复需禁用机会型 TLS 改用隐式 TLS，TLS 1.3 也受影响。
• 机会型 TLS 支持较普遍但多数无实际利用，漏洞自机会型 TLS 引入就存在，之前未被发现是因为基于 ALPACA 攻击且相关 RFC 不广为人知。
• 技术上可在 TLS 中修复但可能性低，需针对 ALPACA 攻击采取对策并分离 ALPN 字符串上的协议变体。
• 以动物命名攻击便于讨论，可通过配置 Apache2 使服务器 vulnerable，相关供应商已响应，建议禁用机会型 TLS 支持。

关键信息：

• Opossum 攻击原理及影响范围
• 攻击的前提条件和实际情况
• 对不同方面（如管理员、浏览器、网站等）的影响及应对措施
• 相关 RFC、TLS 版本及供应商的情况

重要细节：

• 攻击在 HTTP(S)中很实用可靠但多数情况不满足条件，其他协议场景常见但无实际利用
• 多数现代 web 服务器默认禁用 HTTP TLS 升级功能
• 漏洞自 2000 年 RFC 2817 引入 HTTP TLS 升级及 email 协议 STARTTLS 以来存在二十多年
• 相关供应商已被告知并采取措施，如 BSI CERT、IETF、Apache Foundation 等
• 可通过特定 curl 命令测试网站是否 vulnerable