Guzzle 禁用证书验证为假，它有多不安全？
Guzzle disabling certificate verification to false, how insecure is it?
最近我发现自己在使用 Guzzle 时向另一台服务器发出请求 post 并获取一些数据，在某些情况下是令牌。但是我收到证书无效错误，我什至尝试获取新的 .pem 证书，但 Guzzle 仍然不接受并不断抛出该错误。所以最后，我按照“互联网”所说的做了：
$guzzleClient = new Client([
'verify' => false
]);
现在虽然这个解决方案有效，但我不确定它会有多不安全。我需要担心吗？如果是，在什么场景下？
好吧，如果你是这样的话，这就是个大问题
- 根据您使用 guzzle 发送的请求登录系统
- 有 payment/checkout 请求
- 基本上所有敏感数据都被传递到另一台服务器
因为当您在没有 SSL 证书的情况下传递数据时，您的请求可能会被恶意程序捕获，例如
BurbSuite / WireShark , cain and abel / EtterCap
因为这些程序是 Sniffing 程序，任何人都可以从互联网上获得一个版本，因为它们是开源的，没有 SSL 的任何事情都可以被黑客使用上述工具拦截，并且黑客可以查看 纯文本中的整个请求！ 因此强烈建议在传递敏感数据时使用 SSL 连接
值得一提：现在连 SSL 都不是很安全，因为黑客可以使用 SSLStrip 工具将其删除，但请相信我，SSL 会使他们更难获得您的请求，因为如果他们使用您的网站有时会发出未完成的请求，它会通知用户网络不安全，这将使黑客很难获取用户的数据，
TLS/SSL 在常见配置中旨在为您提供三样东西：
- 机密性 - 任何第三方都无法读取发送和接收的消息，
- 完整性 - 任何第三方都无法修改发送和接收的消息，
- 服务器身份验证 - 你知道你在和谁说话。
将 verify 设置为 false 所做的就是禁用证书验证。它会立即禁用服务器身份验证功能，并在面对有权访问您的数据流的活跃攻击者时，也会失去机密性和完整性。
怎么样？
首先TLS/SSL依赖Public Key Infrastructure。无需赘述太多细节：您在计算机上持有一组您信任的所谓证书颁发机构 (CA) 的证书。当您打开与服务的新通信时，您将获得服务证书，并在验证过程中验证证书是否属于您信任的 CA。如果是，则通信可以继续。如果否，则关闭通信通道。
攻击模式
禁用证书验证会允许中间人 (MitM) 攻击，这在您的本地网络中很容易执行（例如通过 ARP poisoning 攻击），在您所在服务的本地网络中呼叫或在网络之间。由于我们通常不完全信任网络，所以我们倾向于验证。
想象一下我对你进行攻击。我已经执行了 ARP 中毒，现在我可以看到你所有的流量。它是加密的，不是吗？好吧，不明显。您认为您已与目标服务执行的 TCP 握手和 TLS 握手 - 您已与我执行。我没有向您提供目标服务的证书，因为我无法伪造它，而是我自己的。但是您没有验证它以拒绝它。我也代表你打开了我和目标服务之间的连接，这样我就可以查看解密的流量，必要时进行修改并回复你，让你相信一切正常。
首先-你所有的秘密都属于我。其次 - 我能够对您和目标服务执行攻击（这可能已经通过身份验证机制得到保护，但现在不是）。
如何解决这个问题？
在二十一世纪，几乎没有理由在任何地方禁用 TLS 验证。将它配置为正常工作可能会很痛苦，尤其是当您第一次这样做时。根据我的经验，微服务世界中最常见的问题是：
- 目标证书是自签名的，
- 您的信任库中缺少 CA 根证书，
- 微服务确实提供了他的证书，但没有提供中间CA证书。
很难猜出你的问题是什么。我们需要更深入地挖掘。
虽然其他答案指出了关于 SSL/TLS 的重要性的一些非常好的观点，但您的连接仍然是加密的，并且您使用的远程端点也有 https://。因此，如果我没有记错的话，当您将 verify 设置为 false 时，您并没有完全禁用 SSL。它只是不太安全，因为如果远程服务器的证书是由证书颁发机构 (CA) 使用 CA 捆绑包签名的，则您不会验证它们。
你需要担心吗？
如果这是您制作的内容，理想情况下您希望内容安全且配置正确，所以是的。
通过不验证证书，就像 Marek Puchalski 提到的那样，服务器可能不是您认为的那个服务器，并且也允许 mitm（中间人）攻击。更多关于 mitm here, and peer verification here.
为什么会发生这种情况以及如何解决？
- 最常见的问题是服务器配置错误，尤其是 PHP 配置。您可以在 this guide, where you'll be using adding the CA root certificates bundle 之后修复您的 PHP 配置。或者，您可以将其添加到 Guzzle。
- 另一个常见问题是，远程服务器使用的是自签名证书。即使您在受信任的存储区中配置了 CA 捆绑包，该证书也不能被信任，因为它不是由受信任的 CA 签名的。所以服务器端需要配置一个由CA签发的SSL证书。如果那不可能，您可以 manually trust this CA root，但是这也会带来一些安全问题。
希望这对您有所帮助:)
最近我发现自己在使用 Guzzle 时向另一台服务器发出请求 post 并获取一些数据，在某些情况下是令牌。但是我收到证书无效错误，我什至尝试获取新的 .pem 证书，但 Guzzle 仍然不接受并不断抛出该错误。所以最后，我按照“互联网”所说的做了：
$guzzleClient = new Client([
'verify' => false
]);
现在虽然这个解决方案有效，但我不确定它会有多不安全。我需要担心吗？如果是，在什么场景下？
好吧，如果你是这样的话，这就是个大问题
- 根据您使用 guzzle 发送的请求登录系统
- 有 payment/checkout 请求
- 基本上所有敏感数据都被传递到另一台服务器
因为当您在没有 SSL 证书的情况下传递数据时，您的请求可能会被恶意程序捕获，例如
BurbSuite / WireShark , cain and abel / EtterCap
因为这些程序是 Sniffing 程序，任何人都可以从互联网上获得一个版本，因为它们是开源的，没有 SSL 的任何事情都可以被黑客使用上述工具拦截，并且黑客可以查看 纯文本中的整个请求！ 因此强烈建议在传递敏感数据时使用 SSL 连接
值得一提：现在连 SSL 都不是很安全，因为黑客可以使用 SSLStrip 工具将其删除，但请相信我，SSL 会使他们更难获得您的请求，因为如果他们使用您的网站有时会发出未完成的请求，它会通知用户网络不安全，这将使黑客很难获取用户的数据，
TLS/SSL 在常见配置中旨在为您提供三样东西：
- 机密性 - 任何第三方都无法读取发送和接收的消息，
- 完整性 - 任何第三方都无法修改发送和接收的消息，
- 服务器身份验证 - 你知道你在和谁说话。
将 verify 设置为 false 所做的就是禁用证书验证。它会立即禁用服务器身份验证功能，并在面对有权访问您的数据流的活跃攻击者时，也会失去机密性和完整性。
怎么样？
首先TLS/SSL依赖Public Key Infrastructure。无需赘述太多细节：您在计算机上持有一组您信任的所谓证书颁发机构 (CA) 的证书。当您打开与服务的新通信时，您将获得服务证书，并在验证过程中验证证书是否属于您信任的 CA。如果是，则通信可以继续。如果否，则关闭通信通道。
攻击模式
禁用证书验证会允许中间人 (MitM) 攻击，这在您的本地网络中很容易执行（例如通过 ARP poisoning 攻击），在您所在服务的本地网络中呼叫或在网络之间。由于我们通常不完全信任网络，所以我们倾向于验证。
想象一下我对你进行攻击。我已经执行了 ARP 中毒，现在我可以看到你所有的流量。它是加密的，不是吗？好吧，不明显。您认为您已与目标服务执行的 TCP 握手和 TLS 握手 - 您已与我执行。我没有向您提供目标服务的证书，因为我无法伪造它，而是我自己的。但是您没有验证它以拒绝它。我也代表你打开了我和目标服务之间的连接，这样我就可以查看解密的流量，必要时进行修改并回复你，让你相信一切正常。
首先-你所有的秘密都属于我。其次 - 我能够对您和目标服务执行攻击（这可能已经通过身份验证机制得到保护，但现在不是）。
如何解决这个问题？
在二十一世纪，几乎没有理由在任何地方禁用 TLS 验证。将它配置为正常工作可能会很痛苦，尤其是当您第一次这样做时。根据我的经验，微服务世界中最常见的问题是：
- 目标证书是自签名的，
- 您的信任库中缺少 CA 根证书，
- 微服务确实提供了他的证书，但没有提供中间CA证书。
很难猜出你的问题是什么。我们需要更深入地挖掘。
虽然其他答案指出了关于 SSL/TLS 的重要性的一些非常好的观点，但您的连接仍然是加密的，并且您使用的远程端点也有 https://。因此，如果我没有记错的话，当您将 verify 设置为 false 时，您并没有完全禁用 SSL。它只是不太安全，因为如果远程服务器的证书是由证书颁发机构 (CA) 使用 CA 捆绑包签名的，则您不会验证它们。
你需要担心吗？
如果这是您制作的内容，理想情况下您希望内容安全且配置正确，所以是的。 通过不验证证书，就像 Marek Puchalski 提到的那样，服务器可能不是您认为的那个服务器，并且也允许 mitm（中间人）攻击。更多关于 mitm here, and peer verification here.
为什么会发生这种情况以及如何解决？
- 最常见的问题是服务器配置错误，尤其是 PHP 配置。您可以在 this guide, where you'll be using adding the CA root certificates bundle 之后修复您的 PHP 配置。或者，您可以将其添加到 Guzzle。
- 另一个常见问题是，远程服务器使用的是自签名证书。即使您在受信任的存储区中配置了 CA 捆绑包，该证书也不能被信任，因为它不是由受信任的 CA 签名的。所以服务器端需要配置一个由CA签发的SSL证书。如果那不可能，您可以 manually trust this CA root，但是这也会带来一些安全问题。
希望这对您有所帮助:)