Comments 22
В предыдущей статье было обещание рассказать "что Степан на этих ресурсах делал (то есть получить доступ к HTTP информации)."
Это и есть обещанный фрагмент или в следующий раз будет гораздо более интересный вариант?
Вариант с внедрением корневого сертификата, если верить хабру, уже даже на государственном уровне встречался, так что на данный момент всё упомянутое не сильно новость.
Есть какие-то более интересные варианты, не требующие в атакуемую систему ставить доверенный сертификат?
Основой SSL является ассиметричное шифрование, которое определяется наличием двух ключей – если одним зашифровать, то расшифровать можно только вторым, и наоборот.
Извините, но никакого «наоборот» нет. Закрытым ключом нельзя ничего зашифровать, публичным невозможно расшифровать что-либо.
Закрытым ключом можно подписать, а открытым — проверить подпись, но это не тождественно шифрованию/расшифровке в общем случае.
Можно зашифровать открытым, а расшифровать закрытым. Другой вопрос, что это ресурсоемко, и поэтому предпочтительнее временный симметричный ключ.
Вообще, пора бы уже отходить от заблуждения что «асимметричная криптография» == RSA. Потому что в каждой первой научно-популярной статье о криптографии особенности работы RSA выдают за особенности работы публичной криптографии вообще.
- Если сообщение зашифровано публичным ключом, его можно расшировать приватным
- Если сообщение зашифровано приватным ключом, его можно расшировать публичным
С математической точки зрения соотношение это возможно — например, для RSA ключи связаны по формуле 1=E*D(mod phi(N)). Поэтому без разницы какой ключ берётся для шифрования.
Но приватный и публичный ключи не взаимозаменямы по своей природе. Если брать все тот же RSA, публичный ключ даже по размеру меньше приватного, потому что приватный включает дополнительные математические переменные. И рассчитываются ключи математически по разному.
Почему популярно утверждение, что «приватным ключом данные шифровать нельзя». Потому что совсем нет смысла шифровать данные, если у всех есть публичный ключ для расшировки.
Поэтому шифрование приватным ключом используется обычно только для генерации цифровой подписи, которая представляет собой снятие хеша и его шифрование. Публичным ключом можно расшировать подпись и получить хеш, который потом можно сравнить с хешем, который высчитал сам.
По поводу второго вопроса. Действительно не стоит ассоциировать ассиметричное шифрование только с RSA. Ниже пару примеров популярных алгоритмов, и для каких задач они предназначены:
- RSA: Encryption, Digital Signature, Key Distribution
- ECC: Encryption, Digital Signature, Key Distribution
- Diffie-Hellman: Key Distribution
- EI Gamal: Encryption, Digital Signature, Key Distribution
- DSA: Digital Signature
- Knapsack: Encryption, Digital Signature, Key Distribution
Если брать тот же DSA, который поддерживает только цифровую подпись, это не значит, что он шифровать не умеет. Все эти алгоритмы построены на шифровании.
Это значит, что он не предназначен для защиты данных, его основное назначение гарантия надёжности цифровой подписи.
В целом говоря, первый ассиметричный алгоритм Diffie-Hellman был придуман людьми Whitfield Diffie и Martin Hellman, которые первыми попытались решить вопрос безопасного обмена симметричного ключа. Подход, описанный в статье, стоило бы отнести в первую очередь к ним. Алгоритмы усложняются и меняются, но базовые методологические основы остаются теми же.
Ps если в других алгоритмах принцип другой, то это повод для когнитивного диссонанса. Как тогда происходит подписывание и проверка?
Есть другие алгоритмы, например:
CBC-MAC — когда сообщение шифруется симметричным ключом, затем берется последний блок, который и будет являтся подписью
СМАС — это аналог CBC-MAC, только с более сложной математикой и математическими функциями
C HMAC тоже не все так просто. Чтобы во время передачи сообщений гарантировать целостность, и чтобы одно и тоже сообщение не получило одинаковую цифровую подпись — алгоритм немного усложняется: к сообщению добавляется что-то вроде сальта или ключа, затем все это прогоняется через хеширование и затем криптуется.
Ваше утверждение истинно в общем виде. Однако конкретно для RSA при подписи хеш шифруется приватным ключом, а при проверке расшифровывется публичным. https://en.wikipedia.org/wiki/RSA_(cryptosystem)#Signing_messages
Для других алгоритмов это не так.
Конечно, если углубиться еще дальше, то окажется что по сути все четыре операции, это — одно и то же возведение в степень. Но тем не менее…
Кстати, по вашей ссылке написано точно то же самое:
Suppose Alice wishes to send a signed message to Bob. She can use her own private key to do so. She produces a hash value of the message, raises it to the power of d (modulo n) (as she does when decrypting a message), and attaches it as a «signature» to the message. When Bob receives the signed message, he uses the same hash algorithm in conjunction with Alice's public key. He raises the signature to the power of e (modulo n) (as he does when encrypting a message), and compares the resulting hash value with the message's actual hash value
Какое-то время назад мне надо было для отладки расшифровать трафик между моим клиентом и моим сервером.
У меня был полный контроль над окружением, у меня были все ключи и у меня был дамп трафика в формате pcap. И… я не смог расшифровать этот дамп — ни один гайд на эту тему не сработал.
Chrome, Firefox можно попросить сессионные ключи сохранять. Повозился, но получилось, в этом случае Wireshark вполне успешно всё декодировал.
Аня генерирует две пары ключей ассиметричного шифрования – приватный Pr1 и публичный P1.
А может одну пару?
Как я люблю такие заявления:
каким-то образом (социальная инженерия, взлом с проникновением) прописать свой фейковый корневой центр сертификации в реестр Бориса.
В случае взлома, Почтальон уже имеет полный контроль над устройством и ему проще просто установить следящее ПО, майнинг Биткоино и тд, чем развлекаться с сертификатами. Он уже может больше чем просто слушать и изменять трафик.
Та же ситуация с социальной инженерией. Гараздо проще уговорить пользователя два раза кликнуть на exe, чем лезть в сертификационный центр. С этой задачей не каждый продвинутый пользователь справится, что уж говорить о бугалтерушечках.
Здесь описывалась общая проблема централизованного SSL, а не "как взломать соседа".
Так я и не говорю "как взломать соседа". Я говорю, что последствия взлома сосед не проблема архитектуры SSL, а проблема самого взлома соседа.
Уже много раз встречал подобные заявления и каждый раз умиляюсь.
Почему-то все забывают, что если Почтальон взломает Бориса, то Почтальон станет Борисом со всеми вытекающими последствиями. И SSL здесь вообще не при делах.
Слабости HTTPS. Часть 2