Guzzle отключает проверку сертификата на false, насколько это небезопасно?

ну это большая проблема если вы например

1. наличие системы входа в систему по запросу, который вы отправляете с помощью guzzle
2. с оплатой/выездом по запросу
3. в основном любые конфиденциальные данные передаются на другой сервер

потому что, когда вы передаете данные без SSL-сертификата, ваши запросы могут быть перехвачены вредоносными программами, такими как

BurbSuite / WireShark , cain and abel / EtterCap 

поскольку эти программы являются Sniffing программами, и любой может получить версию из Интернета, поскольку они имеют открытый исходный код, и все, что происходит без SSL, может быть перехвачено хакером с помощью инструментов, упомянутых выше, и хакер может просмотреть весь запрос в открытый текст! поэтому настоятельно рекомендуется использовать SSL-соединение при передаче конфиденциальных данных.

Стоит упомянуть: в наши дни даже SSL не очень безопасен, потому что хакеры могут удалить его с помощью инструмента SSLStrip, но поверьте мне, SSL значительно усложнит им доступ к вашему запросу, потому что, если они использовали его, ваш сайт иногда будет незавершенным. запросы, и он уведомит пользователя о том, что сеть не защищена, это затруднит хакеру получение данных пользователя,

TLS/SSL в обычных конфигурациях дает вам три вещи:

• конфиденциальность — никакая третья сторона не может прочитать отправленные и полученные сообщения,
• целостность — никакая третья сторона не может изменить отправленные и полученные сообщения,
• аутентификация сервера — вы знаете, с кем разговариваете.

То, что вы делаете с установкой verify на false, отключает проверку сертификата. Он немедленно отключает функцию аутентификации сервера, а также позволяет потерять конфиденциальность и целостность при столкновении с активным злоумышленником, имеющим доступ к вашему потоку данных.

Как это?

Во-первых, TLS/SSL опирается на инфраструктуру открытых ключей. Не вдаваясь в подробности: вы держите на своей машине набор сертификатов так называемых центров сертификации (ЦС), которым вы доверяете. Когда вы открываете новую связь со службой, вы получаете сертификаты служб и в процессе проверки проверяете, среди прочего, принадлежит ли сертификат ЦС, которому вы доверяете. Если да, то общение может продолжаться. Если нет, то канал связи закрыт.

Шаблоны атак

Отключение проверки сертификата позволяет проводить атаки «человек посередине» (MitM), которые легко могут быть выполнены в вашей локальной сети (например, через отравление ARP), в локальной сети службы, к которой вы звоните, или в сети между ними. Поскольку мы обычно не доверяем сети полностью, мы склонны проверять.

Представьте, что я атакую ​​вас. Я провел отравление ARP, теперь я вижу весь ваш трафик. Он зашифрован, не так ли? Ну, не очевидно. Рукопожатие TCP и TLS, которые, по вашему мнению, вы выполнили с целевой службой, вы выполнили со мной. Я предъявил вам не удостоверение целевой службы, так как не могу его подделать, а свое собственное. Но вы не подтвердили это, чтобы отклонить его. Я также установил соединение между мной и целевой службой от вашего имени, чтобы я мог просмотреть расшифрованный трафик, изменить при необходимости и ответить вам, чтобы вы поверили, что все в порядке.

Во-первых, все твои секреты принадлежат мне. Во-вторых, я могу проводить атаки как на вас, так и на целевой сервис (который мог бы быть защищен механизмами аутентификации, но сейчас это не так).

Как это исправить?

В XXI веке не должно быть особых причин отключать проверку TLS где бы то ни было. Однако настроить его для правильной работы может быть проблемой, особенно когда вы делаете это впервые. По моему опыту, наиболее распространенными проблемами в мире микросервисов являются:

1. целевой сертификат является самоподписанным,
2. у вас отсутствует корневой сертификат ЦС в хранилище доверенных сертификатов,
3. микросервис предоставляет его сертификат, но не предоставляет промежуточный сертификат ЦС.

Трудно догадаться, в чем ваша проблема. Нам нужно копнуть глубже.

В то время как другие ответы указывают на действительно хороший момент о том, насколько важен SSL / TLS, ваше соединение по-прежнему зашифровано, а используемая вами удаленная конечная точка также имеет https://. Таким образом, вы не полностью отключаете SSL, когда устанавливаете для проверки значение false, если я не ошибаюсь. Это просто менее безопасно, поскольку вы не проверяете сертификат удаленного сервера, если они подписаны центром сертификации (ЦС) с использованием пакета ЦС.

Нужно ли вам беспокоиться?

Если это что-то на вашем производстве, в идеале вы хотите, чтобы все было безопасно и правильно настроено, так что да. Не проверяя сертификат, как упомянул Марек Пухальски, существует вероятность того, что сервер может быть не тем, о котором вы думаете, и также допускает атаку mitm (человек посередине). Подробнее о mitm здесь и одноранговой проверке здесь.

Почему это происходит и как это исправить?

• Наиболее распространенной проблемой является неправильно настроенный сервер, особенно конфигурация PHP. Вы можете исправить конфигурацию PHP, следуя этому руководству , где вы будете использовать добавление в конфигурацию комплекта корневых сертификатов ЦС. В качестве альтернативы вы можете добавить это в Guzzle.
• Другая распространенная проблема заключается в том, что удаленный сервер использует самозаверяющий сертификат. Даже если вы настроили свой пакет ЦС в доверенном хранилище, этому сертификату нельзя доверять, поскольку он не подписан доверенным ЦС. Таким образом, серверу необходимо настроить SSL-сертификат, подписанный ЦС. Если это невозможно, вы можете вручную доверять этому корневому центру сертификации, однако это также связано с некоторыми проблемами безопасности.

Надеюсь, это помогло :)