1

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

Я пытаюсь npm install и скрипт, который он запускает, пытается загрузить файл через https, что не удается. Я пытался игнорировать сертификат в узле, но не повезло.

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

Есть ли способ, которым мы могли бы достичь этого? Я на Win7.

5 ответов5

1

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

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

1

В большинстве случаев (а также в этом случае) это невозможно. Вы будете просто перенаправлены на HTTPS. Так что я не буду беспокоиться об этом.

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

npm config set registry http://registry.npmjs.org/

Это не очень хорошая идея. Так же небезопасно, но все еще использует HTTPS:

npm config set strict-ssl false

Вместо этого рассмотрите возможность рассказать NPM о CA вашего работодателя:

npm config set ca "-----BEGIN CERTIFICATE-----\nXXXX\nXXXX\n-----END CERTIFICATE-----"

Значения должны быть в формате PEM с символами новой строки, замененными строкой "\n".

Безопасность всего этого, конечно, зависит от перехватчика HTTPS вашего работодателя. Если это отстой, это так же небезопасно, как обычный HTTP.

0

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

Принципиально, чтобы делать такие вещи, как

  • блокировать сайты https без плохого взаимодействия с пользователем (пусть браузер отображает страницу блокировки прокси вместо обычной страницы с ошибкой подключения браузера)
  • сканировать загруженный контент на наличие вредоносных программ (представьте, если мы прекратили сканирование загрузок только потому, что они были перемещены в https)
  • применять контроль уровня доступа URL к сайтам https (например, блокировать Facebook, за исключением страницы компании)
  • предотвратить загрузку (например, защиту от утечки данных) на сайты https
  • содержимое кэша для снижения требований к пропускной способности восходящего канала

которые являются общими и, возможно, разумными усилиями в бизнесе, возникает необходимость взломать шифрование https. Это часто называют Человеком в середине (MitM) "атака". Несмотря на то, что термин "атака" является уничижительным, могут быть веские причины для этого.

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

MitM (часто называемый проверкой SSL) ломает такие вещи, как:

  • Сертификаты расширенной проверки (так как они не могут быть подделаны)
  • Клиентские сертификаты (сайты, использующие их, не будут работать)
  • Cert пиннинг. Если сайт использует закрепление сертификата, клиент отклонит поддельный сертификат.
  • Обновления Windows и iTunes

По этим причинам прокси с такой возможностью (например, Squid, WinGate) должны иметь функцию списка исключений, позволяющую не перехватывать определенные сайты.

Возможно, вы сможете убедить своего администратора добавить нужные вам сайты в этот список.

Отказ от ответственности: я работаю на Qbik, которые являются авторами WinGate.

0

Этот вид сертификата-обертки распространен в большинстве систем веб-прокси /IDS. Поведение Windows по умолчанию заключается в автоматическом обнаружении прокси-серверов в вашей сети (что по многим причинам глупо, но выходит за рамки этого обсуждения). Все, что вам нужно сделать, это снять эту опцию с панели управления "Свойства обозревателя" (вкладка "Подключения", кнопка "Настройки локальной сети"). Просто снимите все флажки.

настройки интернета

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

Большинство приложений просто принимают настройки прокси-сервера системы при создании сокетов. Я не знаю npm достаточно хорошо, чтобы знать, есть ли в нем настройки переопределения прокси.


С другой стороны, "шпионаж" - это довольно сильное слово. Это обычная вредоносная тактика использования HTTPS-соединений для обхода систем обнаружения вторжений. Если вы работаете в корпоративной сети и проводите надлежащую проверку с точки зрения сетевой безопасности, вы должны иметь возможность проверять пакеты HTTP и HTTPS.

-1

Я бы обошел вокруг этого или, более конкретно, использовал бы зашифрованный туннель к внешнему серверу (у меня Raspberry Pi в моей домашней сети). Я использую SSH и динамический туннель, чтобы обойти веб-фильтрацию все время. Затем настройте вашу программу на использование прокси-сервера SOCKS на localhost:####. Номер - это локальный порт, к которому подключен динамический туннель. Конечно, это, вероятно, противоречит политике вашей компании.

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .