Как защитить данные от атак MITM через HTTPS?
Я работаю над корпоративным https://over.wiki/api/" class="blnk">API, который доступен для корпоративных сервисов, где MITM может иметь ужасные последствия.
мы решили использовать HTTPs вместо HTTP, но после googling я понял, что SSL только недостаточно.
Как я понимаю, есть две основные уязвимости при использовании SSL: 1) сейчас много компаний-провайдеров CA, поэтому никто не защищен от атаки MITM, где обычный сертификат используется взломщиками (я нашел некоторые статьи, где он было сказано, что у VeriSign был секретный отдел, который предоставлял Секретные услуги для MITM, когда VeriSign был единственным CA во всем мире) 2) большинство атак MITM возможны при использовании отравления кэша ARP
Итак, я могу увидеть только одно решение на мгновение, но не уверен, что это лучшая практика: Поскольку API является внутренним, я могу использовать следующие вещи: 1) шифрование данных с помощью алгоритма симметричного шифрования 2) ограничить ips, которые могут использовать API (как в приложении, как в сервере брандмауэр)
этого достаточно? может быть, есть другие лучшие практики, чтобы сделать действительно безопасное соединение, что сделает MITM невозможным?
Если это решение (SSL + симметричный алгоритм шифрования) в порядке, не могли бы вы посоветовать наиболее подходящие алгоритмы шифрования для такого рода проблем?
спасибо заранее, будем рады любой помощи / советам.
UPD: VPN (по рекомендации frenchie) не подходит в этом контексте
UPD2: Public-Private ключ (RSA-alike) возможен (thx 2 Craigy), но очень дорогой на стороне сервера.
3 ответов
мы решили использовать HTTPs вместо HTTP, но после googling i понимать, что SSL только не хватает.
Я не уверен, что вы гуглили, но SSL/TLS, при правильном использовании, может защитить вас от атак MITM.
Если это решение (SSL + симметричный алгоритм шифрования) в порядке, может пожалуйста, посоветуйте наиболее подходящие алгоритмы шифрования для такого рода проблема?
шифрование в SSL / TLS уже сделано с использованием симметричной криптографии. Только аутентификация осуществляется с помощью асимметричной криптографии.
Как я понимаю, есть две основные уязвимости при использовании SSL: 1) теперь есть много компаний-провайдеров CA, поэтому никто не защищен из атаки MITM, где обычный сертификат используется крекерами (i нашел несколько статей, где говорилось, что у VeriSign есть секрет отдел, который предоставлял Секретные услуги для MITM, когда VeriSign только ЦС по всему миру) 2) большинств нападения MITM возможны пока использование отравления кэша ARP
защита от атак MITM-это именно цель сертификата. Это исключительно ответственность клиента (а), чтобы проверить, что HTTPS используется, когда это ожидается и (Б), чтобы проверить действительность сертификата сервера.
первый момент может быть очевидным, но это такие атаки, которые инструменты, как sslstrip do: они MITM понижают атаки, которые предотвращают пользователь, чтобы попасть на страницу HTTPS вообще. Как пользователь, убедитесь, что вы находитесь на странице HTTPS, когда это должен быть HTTPS. В корпоративной среде скажите своим пользователям, что они должны проверить, что они обращаются к вашему серверу через HTTPS: только они могут знать (если вы не хотите использовать аутентификацию клиента-сертификата).
второй момент (проверка сертификата) также зависит от клиента, хотя большая его часть автоматизирована в браузере. Пользователь обязан не игнорировать браузер предупреждение. Остальная часть проверки сертификата, как правило, выполняется с помощью предварительно установленных сертификатов CA (например, Verisign).
Если происходит атака MITM (возможно, через отравление ARP), пользователь должен получить неправильный сертификат и не должен продолжать. Правильные проверки HTTPS должны позволить вам иметь безопасное соединение или вообще не иметь соединения.
упомянутые уязвимости связаны с проверкой сертификата (модель PKI). Действительно, проверка правильности сертификата сервера зависит от сертификатов CA, которым доверяет браузер. Там любой доверенный ЦС может выдать сертификат для любого сервера в принципе, поэтому эта модель хороша как самый слабый ЦС в списке. Если один доверенный CAs выдает поддельный сертификат для сайта и дает его другой стороне, это так же хорошо, как иметь паспортный стол, выдающий настоящий "поддельный" паспорт. Это довольно сложно противостоять, но есть способы обойти он.
вы можете положиться на расширения, такие как Перспективные Проекты, которые отслеживают изменения сертификата, даже если оба являются доверенными. Такое предупреждение должно побудить пользователя исследовать, было ли изменение сертификата законным (сделано вашей компанией) или нет.
более радикально, вы можете развернуть свой собственный ЦС, удалить все доверенные сертификаты ЦС из браузера пользователя и установить только свой собственный ЦС сертификат. В этом случае пользователи смогут безопасно подключаться только к машинам с сертификатами, выданными центром сертификации. Это может быть проблемой (в том числе для обновлений программного обеспечения, если Ваш браузер использует хранилище сертификатов ОС).
в принципе, вы можете вообще избежать сертификата и использовать Общие Ключи шифров. Однако это не поддерживается всеми стеками SSL/TLS и не обязательно адаптировано для HTTP через TLS (отсутствует спецификации относительно проверки имени хоста, насколько я знаю).
вас также могут заинтересовать эти вопросы по безопасности.SE:
для защиты от атак MITM при использовании асимметричной криптографии ключей в вашей сети вы можете настроить открытым ключом инфраструктура свой собственный. Вы бы настроить и управлять Сертификат и отключить все другие поэтому никто не мог притворяться кем-то другим, тем самым предотвращая атаки MITM. Если ЦС был скомпрометирован, то атаки MITM снова будут возможны.
чтобы убедиться, что мы находимся на одной странице, эти предложения независимы от реализации. Вы можете использовать любой алгоритм симметричного ключа для первого предложение.
по второму предложению, вам понадобится более сложная система, которая называется асимметричной или криптография с открытым ключом. Они построены на таких алгоритмах, как RSA.
протокол SSL - это протокол, использующий криптографию с открытым ключом для обмена ключами и симметричное шифрование для отправки сообщений.
правильная защита от человека в середине атаки требует двух вещей:
- никогда не обслуживайте свой сайт по HTTP; только слушайте HTTPS-трафик
- используйте заголовок Strict-Transport-Security в ответах с большим временем жизни
отравление ARP атакой SSLStrip зависит от браузера, инициирующего HTTP-соединение с сервером и переходящего позже на HTTPS. Именно в этот переходный момент происходит атака. эффект.
однако, если браузер инициирует запрос как запрос HTTPS, то рукопожатие аутентифицирует сервер в браузере, прежде чем что-либо еще произойдет. В принципе, если происходит атака "человек в середине", пользователь будет уведомлен о том, что соединение SSL не может быть выполнено или что сервер не является правильным сервером.
никогда не обслуживая ваш сайт через HTTP заставляет кого-либо ссылаться на него, чтобы использовать HTTPS в ссылке. Заголовок Strict-Transport-Security инструктирует совместимые браузеры конвертировать в HTTPS любую попытку связи через HTTP на ваш сервер.
для вашего случая использования кажется, что любое другое решение, кроме двух рекомендаций выше, будет излишним. Подробнее о Strict-Transport-Security читайте в разделе статья Википедии о строгой транспортной безопасности.