通过HTTPS进行身份验证会降低我的应用程序速度吗？

我正在构建一个Web应用程序和RESTful Web服务。

我一直在阅读有关如何验证对Web服务的请求的最佳方法的各种文章。

对我而言，最好的选择似乎是使用HTTP基本身份验证。我阅读的几乎每篇文章都说，身份验证应该通过SSL或等效协议进行加密。

我不太确定这涉及什么。这是否意味着我的整个Web服务必须位于安全的服务器上？这会减慢速度吗？

首先，尝试了解SSL（HTTPS）和HTTP身份验证的工作方式。

常用的HTTP身份验证方法（摘要，基本和可在HTTP之上实现的任何基于表单+ cookie的身份验证方案）本身都不安全，因为它们或多或少以明文形式发送身份验证信息。在这方面，无论数据是在POST字段中还是在标头中，以及是否应用了base64编码，这都没有关系，任何访问网络流量的人都可以清楚地看到该密码。这意味着通过不受信任的通道进行的HTTP身份验证毫无价值：攻击者读取您的密码所需要的只是一点网络嗅探。

SSL在本质上不安全的通道上实现了安全的通信通道。大致可以按如下方式进行：

1. 服务器发送签名证书
2. 客户端根据已知有效的签名密钥列表验证证书；可以将证书签名链接起来，以便每个节点都说“如果给我签名的签名很好，那么我也是如此”，但是最终，该链需要解析为客户端上预先配置的少数可信授权机构之一。
3. 客户端使用服务器的公共加密密钥发送共享密钥
4. 服务器使用私钥解密共享机密（因为只有合法服务器才具有私钥，其他服务器将无法解密共享机密）
5. 客户端发送实际的请求数据，并使用共享密钥进行加密
6. 服务器解密请求数据，然后发送加密的响应
7. 客户端解密响应并将其呈现给用户。

请在此处注意一些要点：

• 通过证书链，客户端可以确保与之交谈的服务器是真实的服务器，而不是有人在拦截他们的请求。这就是为什么您应该购买真实的SSL证书的原因，以及为什么浏览器在您访问使用无效，过期或其他错误证书的网站时向您发出可怕的警告：如果和错误的人说话。
• 用于交换机密的公共/专用加密确保成功的通信仅在这对特定的客户端和服务器之间有效：嗅探到的网络数据包将被加密，并且它们将需要服务器的专用密钥来获取数据。
• 对称加密用于大部分请求，因为它的性能开销比私钥/公钥加密低得多。但是，可以使用私钥/公钥加密来交换密钥（共享机密），因为这是以安全方式进行加密的唯一方法（除非通过单独的渠道（例如快递服务）进行传输）。

显然，这涉及一些开销，但是并没有您想像的那么糟糕-在大多数情况下，“向它扔更多的硬件”是适当的响应，除非您正在为绝对大量的流量做准备（ （例如Google或Facebook）。在正常情况下，即典型的Web应用程序使用情况，SSL开销可以忽略不计，因此，一旦您有了任何机密数据，最好仅通过SSL运行所有内容，包括资源。SSL也是确保HTTP流量安全的唯一可行方法。其他方法根本不那么标准化，因此得不到广泛支持，您绝对不想自己实现这些东西，因为老实说，弄错它们太容易了。

TL; DR：是的，SSL +基本身份验证是一个好主意，是的，您需要一个安全的服务器（和一个有效的证书），是的，这会使速度变慢，但是，没有，这不用担心现在。

HTTPS（SSL）不是用户身份验证FYI。它仅提供2个端点之间的加密。

但是，是的，这只是一小部分的开销（尽管不足以保证计划/硬件的改变）。看这里 ：

/programming/548029/how-much-overhead-does-ssl-impose

使用HTTP基本身份验证，用户提供的用户名和密码随每个请求一起发送到服务器。这意味着即使在您网站的不一定需要安全的区域，它们也采用纯文本格式。显然，您希望此处使用SSL来确保用户安全。

从理论上讲，您可以使用cookie身份验证，并且仅将SSL放在登录页面（发送用户名和密码的位置）上。如果您的Cookie具有一定的安全性，并且可以防止重放攻击，那么即使攻击者设法成功获得它们，攻击者也将无法对其进行任何操作。

基本身份验证是在http请求的标头中设置用户名和密码。如果您不使用SSL或等效协议，则该用户名和密码将以纯文本格式发送，对于任何人来说都是微不足道的。

如今，大多数Web服务器都支持即开即用的HTTPS，尽管它确实为每个调用增加了开销，但开销却很小。

您可以保护某些端点，而不保护其他端点（即，具有可生成可用于其他呼叫的令牌的经过身份验证的端点）。我强烈建议对整个服务使用SSL，因为它更加安全。（如果没有其他阻止敏感数据被拦截的行为）

杰夫·阿特伍德（Jeff Atwood）不久前写了一篇简短的博客文章，内容关于完全加密是否可行。他描述了一些实际示例，并且在性能方面也有几行内容。

此外，他引用了有关Gmail案例研究的这篇文章，并引用了以下内容：

在今年1月（2010年），默认情况下，Gmail切换为对所有内容都使用HTTPS。以前，它是作为一种选项引入的，但是现在，我们所有的用户都使用HTTPS来始终保护其浏览器和Google之间的电子邮件安全。为此，我们无需部署其他机器，也无需部署特殊硬件。在我们的生产前端计算机上，SSL / TLS占CPU负载的不到1％，每个连接的内存少于10KB，网络开销不到2％。许多人认为SSL需要占用大量CPU时间，我们希望上述数字（首次公开）有助于消除这种情况。

他还提到了浏览器最近通过HTTPS对客户端页面缓存进行的一些改进。

他指出，尽管如此，还有其他惩罚，其中大多数不是性能而是实施成本：

• 在保持软件质量的同时，为繁忙的团队增加了更多的复杂性，
• 代理缓存很难正确配置，并且也需要更改代码，
• 对于来自不同来源的内容混搭，很难获得正确的安全性，
• 低端移动设备可能难以进行加密。

没有您自己的会话处理的HTTP基本身份验证可能会使您容易受到跨站点请求伪造攻击。如果您结合自己的会话处理，则可能可以使用它，但是您可能无法提供干净的“注销”功能。

无论用于身份验证的内容是什么，都将需要使用HTTPS来加密连接（除非仅在受控的安全网络上访问Web应用程序）。这可能会使速度变慢（连接建立成本很高，但浏览器倾向于保持一段时间），但是如果您想要一个安全的应用程序，则无论如何都无法避免，因此您并不需要担心它。

注意：“ HTTPS身份验证”（您在标题中提到了）具有误导性-它可能是指SSL客户端证书身份验证，它与您的问题文字无关，并且具有其自身的优缺点。您可能不想触摸它。

您将如何完成基本身份验证？
如果这是一个硬编码的用户名/密码，并且您正在使用网络服务器的内置功能来执行此操作，则可能会产生几乎为零的影响。如果您打算在数据库中执行疯狂的操作或类似的操作，那么可能会产生影响。

就像其他人在这里指出的那样，SSL和发送额外的标头从技术上讲会使事情变慢，但从任何意义上来说都不重要。