Использование HTTPS в Java без шифрования

Question

Мы ищем решение, которое позволит нам использовать HTTPS без шифрования. Зачем? Вот история:

Наш продукт (установленный у клиентов) подключается к нашим серверам для получения обновлений, публикации информации и т. Д. Мы хотим, чтобы продукт проверял, что он подключен к серверу (а не обманщику) до публикации данных. Мы также должны убедиться, что нет атак «человек посередине» (то есть контент должен быть подписан и т. Д.). Однако наши клиенты требуют, чтобы они могли прослушивать трафик (Wireshark, tcpdump и т. Д.) И просматривать все содержимое транзакции. Это из соображений соответствия и безопасности.

Кстати, наш продукт написан на Java.

Есть идеи?

UPDATE: Пожалуйста, извините, если я не использую правильную форму для ответа на ответы, я довольно новичок на этом сайте.

Прежде всего, спасибо за ваши быстрые ответы!

Наша причина для изучения возможности HTTPS заключается в том, что мы не хотим изобретать здесь новый протокол. Это не только объем работы, но и тот факт, что изобретать собственный протокол безопасности (даже если только для подписи) обычно считается плохой практикой. Мы пытаемся получить преимущества HTTPS в аутентификации сервера (что важно, этот сервер также обслуживает исполняемый код, который может быть довольно большим - мы не хотим, чтобы кто-нибудь обслуживал вредоносное ПО или делал нашим клиентам большие данные, которые только после получения всей система обнаружит, что это плохо), а также гарантирует, что MITM не произойдет (подписание самих сообщений). Мы не возражаем, если кто-нибудь заметит трафик, потому что он никогда не содержит конфиденциальных данных. Кроме того, не обязательно легко читать содержимое в Wireshark, это возможно только для аудиторов.

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

@ erickson - первое решение с использованием шифров NULL выглядит интересно, мы его рассмотрим. Второе решение потребует набора ключей для каждого клиента, а не того, чем мы бы хотели управлять.

@ ZZ Coder - вы имеете в виду, что с нулевыми шифрами будет невозможно просмотреть содержимое в Wireshark?

Answer 1

Существуют «наборы шифров» SSL без шифрования, и все версии поставщика JSSE Sun поддерживают SSL_RSA_WITH_NULL_SHA.Однако все данные приложения по-прежнему заключены в записи SSL (для переноса MAC-адреса, обеспечивающего защиту целостности и т. Д.), Поэтому, если вы посмотрите на них в Wireshark, вы увидите эти структуры.до тех пор, пока вы не используете эфемерный Diffie-Hellman (один из DHE_XXX наборов шифров), вы можете дать Wireshark закрытый ключ сервера, и он расшифрует сеанс SSL.Хотя это дополнительная работа, она не налагает каких-либо необычных требований на сервер или клиент для поддержки редко используемых незашифрованных шифров.

Answer 2

Если вам нужна только подпись, почему вы не можете просто подписать каждый ответ закрытым ключом (поместить подпись в заголовок) и проверить его с помощью открытого ключа на клиенте, но не использовать HTTPS вообще? Пока ваш закрытый ключ остается секретным и вы выбираете подходящий алгоритм подписи, это должно предотвратить вмешательство в тело ответа, но без сохранения этого тела в секрете.

Answer 3

Существуют альтернативы, позволяющие расшифровать трафик, чтобы его можно было прочитать.Netronome - это только один пример.Подробнее см. http://werebuild.telecomix.org/w/images/2/25/Netwitness-SSL-Decryption.pdf

Answer 4

Я бы согласился с @Jon Skeet - вы не должны пытаться использовать поврежденный HTTPS, вместо этого вы должны просто подписать свои ответы.Вы можете посмотреть в документации по Amazon S3 хороший пример надежной, надежной и в то же время довольно простой модели безопасности.

Короче говоря, основная идея состоит в том, чтобы иметькакой-то секретный ключ, добавьте его и отметку времени к вашему сообщению и хэшируйте его.Отправьте хэш и дату (но не секрет) вместе с вашим сообщением на сервер.Затем ваш сервер проверяет, что дата достаточно близка к доверию (скажем, 15 минут), и хэширует запрос, дату и секретный ключ, который он имеет в файле.Если он получает тот же хеш, то доверенный ресурс сгенерировал запрос, и сервер может безопасно продолжить работу.

Очевидно, что это небезопасно от перехвата сообщения "посередине" (который, кажется, вам подходитс), но это не позволит MITM изменять или создавать фальшивые запросы.

Answer 5

ну не должен ли каждый клиент иметь отдельный ключ в любом случае?иначе как ваш сервер узнает, кто публикует?серверу наплевать на любого человека посередине?

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

Answer 6

Вы можете попробовать использовать шифры NULL (1 и 2), но большинство серверов настроены так, чтобы не принимать слабые шифры.Конечно, эти 2 шифра являются самыми слабыми.

Даже полезная нагрузка будет в открытом тексте, она по-прежнему заключена в рамку SSL, поэтому наиболее распространенный дешифратор пакетов не работает.