HTTP Basic Auth 存在一些问题：

• 密码以 base64 编码（可以很容易地转换为明文）通过网络发送。
• 对于每个请求，都会重复发送密码。（更大的攻击窗口）
• 密码由网络浏览器缓存，至少在窗口/进程的长度内。（可以由对服务器的任何其他请求静默重用，例如 CSRF）。
• 如果用户请求，密码可以永久存储在浏览器中。（同上一点，另外可能被共享机器上的其他用户盗用）。

其中，使用 SSL 只能解决第一个问题。即使这样，SSL 也只会保护到网络服务器——任何内部路由、服务器日志记录等，都会看到明文密码。

因此，与任何事情一样，看全貌很重要。

HTTPS 是否保护传输中的密码？是的。

够了吗？通常，没有。（我想说，永远不会 - 但这实际上取决于您的网站是什么以及它需要有多安全。）

试着这样想：当您使用 SSL 登录任何网站时，您很可能通过 HTTPS 以纯文本形式传递密码（例如 GMail）。

Basic-Auth 的唯一区别是用户名/密码在请求标头中传递，而不是在请求正文(GET/POST) 中传递。

因此，使用 basic-auth+https 的安全性不亚于基于 HTTPS 的基于表单的身份验证。

基于 HTTPS 的基本身份验证很好，但并不完全安全。与Fiddler用于 SSL 调试的方式类似，企业 HTTPS 代理管理 Web 浏览器和代理（其 IP 地址出现在您的 Web 服务器日志中）之间的连接。在这种情况下，HTTPS 密码被解密，然后在公司代理处重新加密。

根据谁在管理代理，以及它的日志是如何使用的，从您的角度来看，这可能是可以接受的，也可能是一件坏事。

有关如何完成 SSL 拦截的更多信息，请参阅此链接：

当 SSL 代理拦截 SSL 连接时，它会向客户端浏览器提供一个模拟的服务器证书。客户端浏览器向最终用户发出安全弹出窗口，因为浏览器不信任 ProxySG 使用的发布者。如果 SSL 代理使用的颁发者证书作为受信任的根导入客户端浏览器的证书存储区，则不会出现此弹出窗口。

ProxySG 可通过其管理控制台下载所有已配置的证书。您可以要求最终用户通过 Internet Explorer 或 Firefox 下载颁发者证书，并将其作为受信任的 CA 安装在他们选择的浏览器中。这消除了模拟证书的证书弹出窗口......

一些公司通过 GPO 将根证书（代理的）部署到每个工作站来解决上面提到的证书弹出问题。虽然这只会影响使用 Microsoft 证书存储的软件。Firefox 等软件需要进行不同的更新。

您注意到需要对客户端进行身份验证并询问基于 SSL 的 HTTP 基本身份验证的安全性。这就是 SSL 的设计目的，只要密码正确，它就可以正常工作。如果你真的只为一个客户端设置这个，很容易通过选择一个长的随机密码来确保，例如使用良好的随机性来源的 12 个字符，或本网站讨论的其他技术。

您的客户还需要确保您拥有适用于服务器的正确证书。在您所描述的情况下，使用引用的 python ssl 页面中描述的自签名证书就可以了。