最近我发现自己在Guzzle上工作，同时向另一台服务器请求发布和获取一些数据，在某些情况下是令牌。但我收到了证书无效的错误，我甚至试图获得一个新的.pem证书，但Guzzle仍然不接受，并不断抛出这个错误。所以最后，我做了；互联网"；说：
$guzzleClient = new Client([
'verify' => false
]);
现在，尽管这个解决方案有效，但我不确定它会变得多么不安全。我需要担心吗？如果是，在什么情况下？
如果你是，这是一个大问题
- 在您使用guzzle发送的请求上使用登录系统
- 应要求付款/结账
- 基本上是传递给其他服务器的任何敏感数据
因为当您在没有SSL证书的情况下传递数据时，您的请求可能会被等恶意程序捕获
BurbSuite / WireShark , cain and abel / EtterCap
因为这些程序是Sniffing程序，任何人都可以从互联网上获得一个版本，因为它们是开源的，没有SSL的每一件事都可以被黑客使用上述工具拦截，黑客可以查看明文中的整个请求因此强烈建议在传递敏感数据时使用SSL连接
值得一提的是：现在连SSL都不太安全，因为黑客可以使用SSLStrip工具删除它，但相信我，SSL会让他们更难处理你的请求，因为如果他们使用它，你的网站有时会发出未完成的请求，它会通知用户网络不安全，这会让黑客很难获取用户的数据，
TLS/SSL在常见配置中提供三种功能：
- 保密性-没有第三方能够读取发送和接收的消息
- 完整性-没有第三方能够修改发送和接收的消息
- 服务器身份验证-您知道与谁交谈
将verify设置为false将禁用证书验证。当面对可以访问您的数据流的主动攻击者时，它会立即禁用服务器身份验证功能，并使机密性和完整性丧失。
怎么样
首先是公钥基础设施上的TLS/SSL救济。不需要过多的细节：您在机器上持有一组您信任的所谓证书颁发机构(CA)的证书。当你打开与服务的新通信时，你会获得服务证书，在验证过程中，你会验证证书是否属于你信任的CA。如果是，则通信可以继续。如果否，则通信通道关闭。
攻击模式
禁用证书验证允许中间人(MitM)攻击，而这种攻击可以在您的本地网络(例如，通过ARP中毒攻击)、您正在呼叫的服务的本地网络或两者之间的网络中轻松执行。由于我们通常不完全信任网络，我们倾向于进行验证。
想象一下我在攻击你。我已经执行了ARP中毒，现在我可以看到你所有的流量。它是加密的，不是吗？嗯，不明显。TCP握手和TLS握手你认为你已经与目标服务执行了-你已经与我执行了。我没有向你出示目标服务的证书，因为我无法伪造它，而是我自己的证书。但你没有验证它以拒绝它。我也代表你打开了我和目标服务之间的连接，这样我就可以查看解密的流量，必要时进行修改并回复你，让你相信一切都好。
首先，你所有的秘密都属于我。其次，我能够对你和目标服务进行攻击(可能通过身份验证机制进行了保护，但现在不是了)。
如何解决此问题
在二十一世纪，应该没有什么理由在任何地方禁用TLS验证。不过，将其配置为正常工作可能会很痛苦，当你第一次这样做时，情况会更糟。根据我的经验，微服务世界中最常见的问题是：
- 目标证书是自签名的
- 您的信任存储中缺少CA根证书
- 微服务确实提供了他的证书，但不提供中间CA证书
很难猜测你的问题是什么。我们需要深入挖掘。
虽然其他答案指出了SSL/TLS的重要性，但您的连接仍然是加密的，并且您使用的远程端点中也有https://。因此，如果我没有弄错的话，当您将verify设置为false时，您并没有完全禁用SSL。这就不那么安全了，因为如果远程服务器的证书是由证书颁发机构(CA)使用CA捆绑包签名的，那么您就不会验证证书。
你需要担心吗
如果这是你的生产中的事情，理想情况下你会希望事情是安全的，并且配置正确，所以是的。正如Marek Puchalski提到的那样，通过不验证证书，服务器可能不是你认为的服务器，也允许mitm(中间人)攻击。点击这里了解更多关于mitm的信息，点击这里了解同行验证。
为什么会发生这种情况&你是怎么修的
- 最常见的问题是服务器配置错误，尤其是PHP配置。您可以按照本指南修复您的PHP配置，在本指南中，您将使用将CA根证书捆绑包添加到您的配置中。或者，您可以将此添加到Guzzle中
- 另一个常见问题是，远程服务器使用自签名证书。即使您在受信任的存储中配置了CA捆绑包，该证书也不能被信任，因为它不是由受信任的CA签名的。因此，服务器需要配置由CA签名的SSL证书。如果这不可能，您可以手动信任该CA根，但这也会带来一些安全问题
希望这有帮助：)