В настоящее время у меня есть группа веб-сервисов, предоставляющих интерфейсы для различных типов клиентов и ролей. Аутентификация выполняется с помощью пар открытого / закрытого ключей (RSA) только для проверки URL-адреса как подписи в заголовке HTTP.
В настоящее время тело HTTP не зашифровано (я использую частный / открытый ключ 2048 бит, который позволяет мне шифровать только небольшие объемы информации), поэтому RSA недостаточно безопасен, потому что сервер больше не может доказать себе, что нет Человек посередине. Я могу зашифровать также тело HTTP, но как насчет производительности?
У меня вопрос: какие методы рекомендуются для предотвращения атаки MITM в этом случае?
Если ваша цель - только аутентичность (а не конфиденциальность), подпись в заголовке, либо от клиента, либо от сервера, либо в обоих направлениях, может использоваться для проверки того, что биты получены от отправителя.
Обратите внимание, что если подписанный контент не имеет отметки времени, которая проверяется, он уязвим для простого воспроизведения, которое может позволить кому-то посередине выполнять некоторую функцию или маскироваться под другую сторону на неопределенный срок.
Ошибка «данные слишком велики для размера ключа» частично возникает из-за того, что прямое шифрование / дешифрование RSA требует значительных вычислительных ресурсов, поэтому реализация не предназначена для обработки больших объемов данных. Фактический предел связан с гарантиями криптографической стойкости, которые обеспечивает алгоритм. Допуск большой полезной нагрузки с низкой энтропией ослабит его.
Чтобы избежать этой ошибки, необходимо использовать алгоритм дайджеста сообщения, который выполняет одностороннее хеширование, например MD5, для большего набора битов, например тела HTTP POST, а затем зашифровать результат дайджеста фиксированного размера с помощью шифрования RSA. Зашифрованный хеш - это, по сути, цифровая подпись. Затем сторона-получатель расшифровывает, вычисляет результат хеширования тела и сравнивает хеши для проверки подписи.
Обратите внимание, что если сеансовый ключ доступен, потому что также используется шифрование, то хэш тела может быть просто зашифрован с помощью этого общего симметричного ключа вместо более дорогостоящего шифрования RSA. Это называется кодом аутентификации сообщения (MAC), и он не такой надежный, как подпись.
Там есть абсолютно бессмысленно при использовании HTTPS, если вы не шифруете всю аутентифицированную сессию. Если в какой-то момент вы передаете идентификатор сеанса по незащищенному каналу, злоумышленник может использовать его для аутентификации (например, Firesheep). Более того, вы нарушаете OWASP a9.
С точки зрения производительности самой дорогой частью SSL является первоначальное рукопожатие. Это кешируется и делается только один раз для каждого клиента.
Еще нужно помнить, что если вы хотите прекратить SSLStrip стиль атаки, то вы должны установить STS-заголовок.
Воспользуйтесь проверенным и проверенным решением: используйте HTTPS с взаимной аутентификацией, в качестве бонуса зашифруйте весь сеанс. Производительность HTTPS не является проблемой, если ваш клиент не работает на калькуляторе TI. Google использует его для всего Gmail, это должно быть хорошим примером.