Лидеры форума

Ну что ж, можно и поподробнее, тем более, что я уже достаточно начитался вашей хренотени, REVERSE, и делать это ещё раз не имею никакого желания. Итак, допустим мир сошёл с ума и ваше бредорешение воплотилось в программном коде, рассмотрим алгоритм его работы пошагово. На первом шаге пусть идёт установление обычного сетевого соединения, опустим вопросы с емейлом, пусть остаётся на совести автора. Самое интересное начинается далее, по версии автора клиент соединяется со своей серверной частью, автор полагает его эдаким хранилищем открытых ключей, которые хранятся аки сокровище какое и не меняются пока пользователь не захочет. В реальности, а не в мире "по-реверсу", открытые ключи являются сессионными, и хранить их нет ни малейшего смысла. Далее автор, описывает процедуру аутентификации, мол "вшитый" в клиент сертификат(в случае необходимости его изменения, придётся все клиенты обновлять, что отлично ящитайю), сравнивается с сертификатом сервера и дескать у браузера так же, автор опять же не в курсе, что там используются ЭЦП третьей стороны, то есть центра сертификации. (Который выписывается под паспортные данные, Реверс, а не "хотя браузер может еще проверять его удаленно у самих CA", не знаешь ты про X.509 не знаешь, как ssl/tls работает) Что помешает злоумышленнику вклиниться на этапе установления соединения и как раз и реализовать атаку "человек посередине", вопрос открытый, к сожалению тут автор молчит как партизан на допросе и только стрелки переводит. Видимо даже его "парсер" почувствовал тут подвох. Но тут любопытен и заслуживает отдельного упоминания другой курьёз, автор в первом случае пишет про сертификаты, получаемые от сервера, во втором случае пишет про кодовую фразу и пару ключей, которые держит сервер, а сам при этом на вопрос, хранятся ли на сервере какие-либо закрытые ключи в каком-либо виде уверенно так отвечает, что нет, не хранятся. Я напомню, как формируется ЭЦП: 0. Пользователь А, в нашем случае Сервер, по незащищённому каналу пересылает открытый ключ U пользователю B, в нашем случае это Клиент. 1. Далее пользователь А шифрует сообщение в нашем случае сертификат, своим закрытым ключом, которые обязан быть и хранится только у него. 2. Далее идёт пересылка нашего сертификата пользователю А, по его собственному запросу. 3. Пользователь А проверяет подлинность сообщения с помощью своего открытого ключа. Возникает логичный вопрос, если закрытые ключи на сервере не хранятся ни в каком виде, о каких сертификатах мы (а точнее автор) вообще говорим. Тоже самое и со вторым вариантом, там сервер, также обязан использовать закрытые ключи. Тут ясно видно, что автор так до конца и не разобрался, что происходит в случае двухстороннего соединения. Мне даже интересно как он будет выкручиваться, наверное опять услышим что-нибудь про парсер Плюс ко всему вышенаписанному, стоит добавить, что в случае несанкционированного доступа к серверу и его захвату злоумышленником компрометируется вся схема полностью, поскольку никакие md5 и подобный бред автора от подмены ключа не спасёт, поскольку подделать и md5 и тем более crc, которое к шифрованию как таковому вообще отношения не имеет, в настоящий момент не представляет сложности. Вот так вот Сабзира То что мы изволим здесь видеть, от г-на Реверса, есть сеанс "гугления по аббревиатурам" это когда берётся строка написанного тобой вбивается в гугл и тебе в ответ на твою реплику, летят куски нагугленного из различных источников, отвратительное явление, к сожалению уже имеющее аналоги в реальной жизни. При текущем низком уровне вхождения в ИТ и огромном кадровом голоде, такие вот которые "ну в принципе знают, а если, что могут нагуглить" встречаются на собеседованиях чуть менее чем через 2 - 3 человек.