Использование HTTPS в Java без шифрования
Мы ищем решение, которое позволит нам использовать HTTPS без шифрования. Почему? Вот история:
Наш продукт (установленный в клиентах) подключения к нашим серверам для выборки обновлений, разместите информацию и т.д. Мы хотим, чтобы продукт проверил, что подключен к серверу (и не самозванец) до регистрации данных. Мы также должны удостовериться, что нет никаких атак "человек посередине" (то есть, содержание должно быть подписано, и т.д.). Однако наши клиенты требуют, чтобы они могли осуществить сниффинг трафика (Wireshark, tcpdump, и т.д.) и просмотреть контент всей транзакции. Это для соответствия и соображений безопасности.
Наш продукт записан в Java, между прочим.
Какие-либо идеи?
ОБНОВЛЕНИЕ: извините меня, если я не использую правильную форму для ответа на ответы, я являюсь довольно новым на этом сайте.
В первую очередь, спасибо за Ваши быстрые ответы!
Наша причина исследования возможности HTTPS состоит в том, потому что мы не хотим изобретать новый протокол здесь. Это не просто объем работы, но также и то, что изобретение Вашего собственного протокола системы защиты (даже если только для подписания) обычно считают плохой практикой. Мы пытаемся получить преимущества HTTPS в аутентификации сервера (который важен, этот сервер также вручает исполняемый код, который может быть довольно большим - мы не хотим никого вручающего вредоносное программное обеспечение или DoSing наши клиенты с большими данными, которые только после получения всей вещи будут система узнавать, что это плохо), а также гарантирующий, что MITM не происходит (подписание самих сообщений). Мы не возражаем, если любой evesdropes на трафике, потому что он никогда не содержит что-то конфиденциальное считаемое. Кроме того, должно не обязательно быть легко считать содержание в Wireshark, только возможном, таким образом, аудиторы могут сделать это.
@Nate Zaugg - нет, это не шутка. На самом деле удивительно, что поставщики используют HTTPS с шифрованием сегодня и не получают много обратной реакции от клиентов со строгими проблемами соответствия.
@erickson - первое решение с ПУСТЫМИ исками шифра выглядит интересным, мы изучим его. Второе решение потребует ряда ключей для каждого клиента - не что-то, чем мы хотели бы управлять.
Кодер @ZZ - Вы подразумеваете, что с пустыми шифрами не будет возможно просмотреть содержание в Wireshark?
5 ответов
Существуют «наборы шифров» SSL без шифрования, и все версии поставщика Sun JSSE поддерживают SSL_RSA_WITH_NULL_SHA . Однако все данные приложения по-прежнему заключены в записи SSL (для переноса MAC, который обеспечивает защиту целостности и т. Д.), Поэтому, если вы посмотрите на них в Wireshark, вы увидите эти структуры.
В качестве альтернативы, если вы не используете эфемерный алгоритм Диффи-Хеллмана (один из DHE_XXX наборов шифров), вы можете предоставить Wireshark закрытый ключ сервера, и он расшифрует сеанс SSL. Хотя это дополнительная работа, она не предъявляет никаких необычных требований к серверу или клиенту по поддержке редко используемых незашифрованных наборов шифров.
Если вам нужна только подпись, почему вы не можете просто подписывать каждый ответ закрытым ключом (помещая подпись в заголовок) и проверять его с помощью публичный ключ на клиенте, но вообще не использовать HTTPS? Пока ваш закрытый ключ остается в секрете и вы выбираете подходящий алгоритм подписи, это должно предотвратить подделку тела ответа, но без сохранения этого тела в секрете.
Я согласен с @Jon Skeet - вы не должны пытаться использовать поврежденный HTTPS, вместо этого вы должны просто подписать свои ответы. Вы можете посмотреть документацию по Amazon S3 , чтобы получить хороший пример прочной, надежной и в то же время довольно простой модели безопасности.
Короче говоря, основная идея состоит в том, чтобы иметь какой-то секретный ключ, добавить его, временную метку к вашему сообщению и хешировать это. Отправьте хэш и дату (но не секрет, очевидно) вместе с вашим сообщением на сервер. Затем ваш сервер проверяет, что дата достаточно близка, чтобы доверять (скажем, 15 минут), и хеширует запрос, дату и секретный ключ, которые у него есть в файле. Если он получает такой же хеш, значит, запрос был сгенерирован доверенным ресурсом, и сервер может безопасно продолжить работу.
Очевидно, что это небезопасно от сниффинга «злоумышленник посередине» (с которым вы, кажется, согласны), но это предотвратит изменение или создание фальшивых запросов MITM.
Вы можете попробовать использовать NULL-шифры (1 и 2), но большинство серверов настроено не принимать слабые шифры. Конечно, эти 2 шифра самые слабые.
Даже полезная нагрузка будет в виде открытого текста, она по-прежнему заключена во фрейм SSL, поэтому наиболее распространенное дешифрование пакетов не работает.
ну, в любом случае, разве у каждого клиента не должно быть отдельного ключа? иначе как ваш сервер узнает, кто пишет? серверу плевать на человека посередине?
если у каждого клиента есть ключ, например простой пароль, который известен серверу, этот ключ можно использовать как соль с хеш-функцией для подписи запросов / ответов.