Легкая и простая защита MITM для HTTP?
БУДЬТЕ ЧЕТКО: Я НЕ хочу писать свой собственный протокол или свою собственную реализацию на стороне клиента. Я ищу СУЩЕСТВУЮЩИЙ протокол, часть стандартов HTTP, который, как правило, УЖЕ поддерживается обычными браузерами. (Такого может и не быть.)
У меня есть HTTP-приложение, которому нужна защита от угроз типа "злоумышленник посередине". (Сервер должен иметь возможность доказывать подлинность своих ответов клиенту.) Шифрование не имеет значения и не нужно. Кроме того, аппаратный бюджет довольно невелик, учитывая ожидаемую скорость попадания.
Обычно я бы просто получил дешевый сертификат и включил SSL на веб-сервере, но генератор нагрузки убил и Apache, и Nginx (и я не ожидаю, что какие-либо другие веб-серверы будут работать лучше). Для службы, отличной от HTTP, с нагрузкой все в порядке. Я также попытался настроить HTTPS-сервер для согласования нулевого шифра шифрования. Это немного помогло, но рукопожатие SSL все еще слишком тяжелое.
Простая подпись SHA-1 (сгенерированная сервером) над ответным документом, проверенная клиентом, меня вполне устроит. Я написал простой сценарий Python FastCGI и HTTP-клиент, чтобы протестировать только голую операцию SHA-1 - это добавляет некоторую нагрузку, но не намного, даже близко к тому, что добавляет SSL с нулевым шифрованием. Однако на практике моими клиентами будут не сценарии Python, а веб-браузеры.
(СНОВА, ЧТОБЫ БЫТЬ ЧЕТКО: я не предлагаю свой собственный криптопротокол, сценарий Python был просто проверкой того, какую нагрузку генерирует хэш SHA-1 сам по себе по сравнению с остальной частью согласования SSL. Я не могу использовать пользовательская реализация на стороне клиента, потому что у меня нет возможности установить ее для всех клиентских браузеров.)
Итак: существуют ли СУЩЕСТВУЮЩИЕ облегченные (по сравнению с SSL) протоколы аутентификации сервера для HTTP?
То, что вы ищете, на самом деле не существует. Облегченный механизм, встроенный в браузеры и серверы, - это SSL.
Некоторые обходные пути включают:
- HTTP-дайджест для имен пользователей / паролей
- DNSSEC для проверки адреса сервера
сделать механизм квитирования ajax и проверку страницы HMAC. Если вы вставляете страницу, имитирующую механизм открытого / закрытого ключа - третья сторона может легко подделать данные, иначе MITM также может легко исправить хеш данных. Помните, что криптография редко выполняется правильно, поэтому становитесь на плечи других и используйте проверенный механизм.
Я предлагаю вам использовать ssl с настроенным nginx (посмотрите ssl-сессии и шифры). В противном случае ваш MITM будет просто пародией, потраченной впустую работой и циклами процессора.
Если вы вставляете SHA1 в свой контент, а я MITMing вас, что мешает мне просто исправить SHA1?
В зависимости от того, насколько сильно вы контролируете клиент, вы можете заменить тривиально разрушаемый SHA1 на HMACSHA1. Проблема с HMAC заключается в том, что они требуют, чтобы секретный ключ был заранее известен обеим сторонам передачи. Любой, у кого есть доступ к вашему клиенту, вероятно, сможет извлечь секретный ключ, разобрав его.
Мы использовали это раньше для случаев, когда у нас было два отдельных веб-сервера, один из которых предоставлял веб-сайт, а другой обрабатывал заказы, которые были расположены в географически разных центрах обработки данных. Это гарантировало, что никто не сможет отправлять запросы напрямую на сервер выполнения и выставлять счета людям.
Проблема с использованием непонятного или специального протокола для подписи в том, что он еще не встроен в браузер (ы). Это означает, что вам необходимо предоставить логику проверки удаленному браузеру. Если у вас нет защиты от атаки MITM, когда вы доставляете этот код / логику, то что мешает MITM просто заменить код проверки чем-то, что возвращает «VALID», независимо от того, что он видит - и / или что останавливает MITM извлекает общий секрет, используемый для HMAC, из кода проверки на стороне клиента и использует его в атаке MITM?
Если вы просто не можете использовать SSL-шифрование в реальном времени, не могли бы вы реорганизовать свой процесс так, чтобы вы использовали HTTP для доставки предварительно вычисленных ответов, которые были подписаны GPG или иным образом подписаны в автономном режиме как часть пакетного процесса? Если вам нужно включить данные пользователя в вычисление / определение ответа, не могли бы вы добавить запросы в очередь с пакетной обработкой, чтобы результаты, подписанные GPG, доставлялись позже через пользователь, опрашивающий страницу ответа HTML, и / или по электронной почте ?
Вам нужно, чтобы это было доступно 24x7x365, или это используется время от времени? (например, события регистрационного типа, когда у вас большая нагрузка в один день или неделю, а затем ничего в течение месяцев) Если это последнее, не могли бы вы использовать облачный сервер, который вы просто арендуете на день или неделю, а затем уменьшите скорость пока он вам снова не понадобится?
Вместо того, чтобы пытаться решить неправильную проблему, возьмите карта ускорения шифрования или поместите Nginx перед своим веб-сервером в SSL-ускоритель / обратный прокси конфигурации и покончить с этим.