<p>httpie отказывается доверять самозаверяющему сертификату</p>

Никогда не рекомендуется доверять самозаверяющему сертификату. Опасно, если программа принимает его по умолчанию. Хакер может просто ввести самоподписанный, чтобы пользователи чувствовали себя в безопасности, хотя это не так.

Однако я бы посоветовал httpie ответить на вопрос об использовании самозаверяющего сертификата более четким сообщением, а не просто отказать. Было бы замечательно предложить использовать --verify=no для отключения проверки в целях тестирования.

@ giskard22

Я не совсем понимаю обсуждение проблемы № 480, но я думаю, что основная причина этой проблемы может быть такой же. Мне нужен httpie, чтобы доверять самозаверяющему сертификату. Технически это самозаверяющий промежуточный центр сертификации, но я могу использовать один из реальных сертификатов сервера от этого центра и получить тот же результат.

Глядя на # 480, это не та же основная причина. HTTPie в этом случае использует предоставленный вами пакет.

Я подозреваю, что на самом деле причина в следующем:

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

Никогда не рекомендуется доверять самозаверяющему сертификату. Опасно, если программа принимает его по умолчанию. Хакер может просто ввести самоподписанный, чтобы пользователи чувствовали себя в безопасности, хотя это не так.

Советы @alvis blanket обычно неверны, и в данном случае они совершенно неверны. Самозаверяющие сертификаты - это решение проблемы. Я не знаю, как использовать здесь самоподписанный сертификат @ giskard22, и вы тоже. В этом случае ваш совет, скорее всего, бесполезен не только для @ giskard22 , но и для остальных людей, получающих уведомления по электронной почте о проблемах в этом репозитории.

Самозаверяющие сертификаты могут быть опасными для доверия без проверки, но в этом случае кажется, что @ giskard22 знает цепочку доверия и доверяет ей, что делает такое использование совершенно безопасным. Да, если вы попали на сайт, использующий HTTPS, на который вам может потребоваться ввести конфиденциальную информацию, не рекомендуется использовать самозаверяющий сертификат, но это совершенно другая ситуация, насколько я понимаю.

Да, здесь используется httpie через корпоративный веб-прокси, который выполняет HTTPS-посредник, чтобы проверять трафик. Он генерирует сертификат для домена на лету. Мля.

Я не понимаю, как отказ прокси-сервера предоставить полную цепочку сертификатов вызывает эту проблему. Возможно, поведение OpenSSL (или это поведение Python?) Отличается от встроенного механизма MacOS.

Цепочка доверия для подключений через прокси выглядит так:

1. Сертификат на лету, выданный www.testdomain.com
2. Промежуточный сертификат CA с именем proxy-name
3. Самозаверяющий сертификат корневого центра сертификации с именем company-name

Мне не удалось получить сертификат 3. Однако сертификат 2 доступен через прокси-сервер. Я импортировал в свою Связку ключей и пометил ее как надежную для использования SSL. Этого было достаточно, чтобы удовлетворить все на моем Mac, кроме httpie, включая другие инструменты командной строки, такие как curl. Наблюдаемое поведение заключается в том, что механизм проверки следует по цепочке, пока не найдет доверенный сертификат, а затем останавливается. Отсутствие корневого сертификата не имеет значения.

В выводе отладки httpie, который я опубликовал в своем первоначальном отчете, я сохранил сертификат 2 в intermediate-authority.pem и указал этот файл с помощью --verify . Вы хотите сказать, что для httpie этого недостаточно, и я также должен предоставить сертификат 3?

Возможно, поведение OpenSSL (или это поведение Python?) Отличается от встроенного механизма MacOS.

Итак, OpenSSL будет искать в пакете, который вы ему предоставляете, все, что ему не хватает. Если он не может найти его там, он не проходит проверку. Это также транзитивное поведение Python. SecureTransport (встроенный механизм MacOS) работает несколько иначе, но только если сертификаты находятся в связке ключей MacOS. Кроме того, в MacOS Python по умолчанию имеет взломанную (из-за отсутствия лучшего термина) версию OpenSSL, которая использует Keychain и, таким образом, может разрешить их, даже если вы предоставите ему свой собственный пакет сертификатов (то есть, если вы укажете ему только доверять Что находится в файле пакета, он скажет: «LOL, но у меня есть доступ к Keychain, и он доверяет ему, так что YOLO» ... или YOVO? (You Only Verify Once ... Idk)).

Если вся цепочка доверия для этих «на лету» сертификатов - это то, что вы описали, я думаю, вы сможете обойтись без пакета, который включает только звенья 2 и 3 в цепочке.

Кроме того, если вы установили httpie из homebrew на MacOS, тогда он был установлен с домашними версиями OpenSSL , Python и virtualenv вот почему он не может воспользоваться взломанным OpenSSL Mac.

Наконец-то я смог идентифицировать и получить самоподписанный корневой сертификат. После помещения как этого сертификата, так и промежуточного сертификата в файл .pem и использования этого файла с --verify я больше не получал ошибку SSL. Это хорошо! Как и предполагалось, OpenSSL требует всей цепочки сертификатов. В отличие от SecureTransport, он не принимает частичную цепочку, даже если она введена вручную.

Есть мысли о следующем дополнительном усложнении? Прокси-сервер позволяет трафику попадать в определенные домены, не вставляя собственный сертификат. Похоже, вы не можете использовать несколько аргументов --verify . Побеждает последний. Есть ли способ использовать несколько пакетов сертификатов?

У меня есть обходной путь, который включает объединение предоставленного OpenSSL пакета корневого CA и настраиваемого пакета по запросу, но я надеюсь этого избежать.

Итак, OpenSSL поддерживает предоставление каталога, полного файлов .pem для проверки. Тем не менее, поддержка этого в Python нечеткая. Честно говоря, я не думаю, что что-либо старше Python 3.5 или 3.6 поддерживает каталоги в стандартной библиотеке, и я не помню, будет ли это поддерживать pyOpenSSL. Суть в том, что я не думаю, что вы сможете достичь своих целей, не имея одного .pem файла

Старый почтальон спешит на помощь. Вы можете отключить обнаружение самоподписанного сертификата.

SSL - это хорошо, наверное, разработчики это знают. Отключение SSL из-за угловых случаев и языковых ограничений или чего-то еще. Я знаю, что люди просто хотят, чтобы работа была сделана. Мне просто интересно, когда мы скажем, что SSL - это хорошо, и у нас будет такая же внутренняя реакция, когда мы скажем «отключить проверку SSL». Если вы отключите проверку SSL, SSL будет отключен. Но SSL - это хорошо. Мы все это знаем, верно? Это сбивает с толку или общеизвестно, что проверка SSL - это действительно все, что есть в SSL? Если у почтальона есть возможность отключить проверку SSL, это просто причудливый способ сказать что-то потенциально небезопасное? curl имеет ту же опцию, что и флаг под названием --insecure . Это просто причудливый способ, который точно скрывает, в чем проблема (отключает SSL)? Думаю, в Postman можно потестить. TIL, что у Почтальона есть такая возможность. Я собираюсь снова его включить? Или я просто отключил SSL для всех текущих и будущих проектов? Я отправляю ключи API из кафе? : |

Я надеюсь, что машины https dev, самозаверяющие сертификаты и корпоративные центры сертификации однажды будут вытеснены автоматическими сертификатами letsencrypt с поддержкой сценариев. Жаль, что python делает http менее органичным, доверяя системному хранилищу keychain / ssl. Это замена локонов, за исключением этой области. Думаю, у golang есть обнаружение операционной системы для всего этого. Таким образом, современная замена curl (например, bat), написанная на go, будет иметь хороший вывод, приятный интерфейс командной строки и обрабатывать настраиваемые центры сертификации или завершение SSL (балансировщики нагрузки).

SSL - это хорошо, наверное, разработчики это знают. Отключение SSL из-за угловых случаев и языковых ограничений или чего-то еще. Я знаю, что люди просто хотят, чтобы работа была сделана. Мне просто интересно, когда мы скажем, что SSL - это хорошо, и у нас будет такая же внутренняя реакция, когда мы скажем «отключить проверку SSL». Если вы отключите проверку SSL, SSL будет отключен. Но SSL - это хорошо. Мы все это знаем, верно? Это сбивает с толку или общеизвестно, что проверка SSL - это действительно все, что есть в SSL? Если у почтальона есть возможность отключить проверку SSL, это просто причудливый способ сказать что-то потенциально небезопасное? curl имеет ту же опцию, что и флаг под названием --insecure . Это просто причудливый способ, который точно скрывает, в чем проблема (отключает SSL)? Думаю, в Postman можно потестить. TIL, что у Почтальона есть такая возможность. Я собираюсь снова его включить? Или я просто отключил SSL для всех текущих и будущих проектов? Я отправляю ключи API из кафе? : |

Я надеюсь, что машины https dev, самозаверяющие сертификаты и корпоративные центры сертификации однажды будут вытеснены автоматическими сертификатами letsencrypt с поддержкой сценариев. Жаль, что python делает http менее органичным, доверяя системному хранилищу keychain / ssl. Это замена локонов, за исключением этой области. Думаю, у golang есть обнаружение операционной системы для всего этого. Таким образом, современная замена curl (например, bat), написанная на go, будет иметь хороший вывод, приятный интерфейс командной строки и обрабатывать настраиваемые центры сертификации или завершение SSL (балансировщики нагрузки).

Нет, не хорошо. Необходимо иметь возможность завивать, даже если сертификат разработчика adhoc.