NTLM 认证方法一直是个棘手的问题。
这是一个微软设计的专有协议，很久以前就被逆向工程破解了。当时的成果就是相关的在线文档，我在 2003 年就以此为基础实现了 curl 功能。同时，我还编写了 wget 的 NTLM 代码。
NTLM 打破了 HTTP 的传统范式：它用于验证连接，而不是验证请求，而 HTTP 身份验证和其他所有方法原本都是验证请求的。这听起来似乎微不足道，但它对所有 HTTP 实现都产生了重大影响。间接地，它也是 HTTP 代码中诸多安全问题的根源，因为 NTLM 需要许多特殊的例外情况和额外的特殊处理。
curl 记录显示，NTLM 相关代码中至少存在七个安全漏洞！虽然这可能并非完全是 NTLM 的问题，但这无疑加剧了问题的严重性。
基于连接的概念也使得该方法与 HTTP/2 和 HTTP/3不兼容。NTLM 要求服务坚持使用 HTTP/1。
NTLM (v1) 使用非常弱的加密算法（DES 和 MD5），即使不考虑其他原因，这也是一个糟糕的选择。
我们正在逐步弃用 curl 中的 NTLM 身份验证，但首先会将其设为可选功能。从 curl 8.20.0 开始，NTLM 默认在构建过程中处于禁用状态，除非明确启用。
微软自己已经弃用了 NTLM 身份验证。wget 项目似乎也即将把 NTLM 支持改为可选功能。
中小企业
curl 仅支持 SMB 版本 1。该协议使用 NTLM 进行身份验证，而 NTLM 在此协议中的表现同样糟糕。如果在构建过程中未启用 NTLM，则 SMB 支持也会被禁用。
此外，SMBv1 本身就是一个功能较弱的协议，curl 用户几乎不用，因此从 curl 8.20.0 开始，该协议也变成了可选的。您需要在构建过程中显式启用它才能添加该协议。
尚未移除
我想强调的是，我们并没有取消对这些古老协议的支持，我们只是强烈不建议使用它们，而且我相信这是逐步淘汰它们的第一步，将来它们将被彻底移除。
原文： https://daniel.haxx.se/blog/2026/03/22/ntlm-and-smb-go-opt-in/