Этот мессенджер безопасен? (Часть 2)
BespalePhoneСодержание (ч.2)
Часть 1 (...2.2.3. алгоритмы/протоколы)
2.2.4. базовая асимметрия
2.2.4.1. RSA (1977)
2.2.4.2. PGP/OpenPGP (1991/1997)
2.2.4.3. SSL/TLS (1995/1999)
2.2.5. базовая симметрия
2.2.5.1. AES (1998), DES (1977)
2.2.5.2. Salsa/ChaCha (2005/2008)
2.2.6. промежуточный итог
2.2.7. решаем 3 проблемы шифрования
2.2.7.1. распределяем ключи DH (1976), ECDH (2006)
2.2.7.2. нейтрализуем человека-посередине SHA (1995), Poly1305 (2005)
2.2.4. базовая асимметрия
Ну что, здравствуй, наконец, реальность🤝
Начнем с асимметричных↪️🗝🔑↩️вариантов:
2.2.4.1. RSA (1977)
И начать разговор об асимметрии можно только с rsa - прародитель, ветеран, бывалый, заслуженный, действующий резерв.
rsa - самый базовый алгоритм асимметричного шифрования
rsa лежит в основе и/или составе очень и очень многих актуальных протоколов шифрования, фактически - активно используется аж по сей день.
И базово - это надежный алгоритм шифрования, т.е. один условный перехваченный пакет без ключа расшифрован не будет.
Но это один и условный и без ключа (3 проблемы).
Конечно, от rsa чудес ждать и не стоило, это всего лишь алгоритм, но заслуженную дань уважения отдаем в любом случае.
Кроме того, стоит еще отметить, что
rsa - это очень медленно (все-таки '77 год)
Собственно, поэтому он почти никогда не используется (в рамках протоколов) для шифрования самого sодержания, даже текста (не говоря уже о файлах/звонках), а применяется, как правило, для шифрования чего-нибудь поменьше: ключей/сертов/метадаты/хендшейков/подписей/итд, т.е. того, что сопровождает основные (большие) пакеты в их нелегком пути между a и b.
Почти никогда, за исключением разве что:
2.2.4.2. PGP/OpenPGP (1991/1997)
pgp - это классический асимметричный е2е-протокол, вот прям для двух собеседников - людей, создавался для общения через email вообще (какие уж там #мессенджеры в '91).
Изначально pgp НЕ был opensource, а был - proprietary, т.е. проприетарным программным продуктом (а это был не просто протокол, а прям продукт - набор библиотек и прочего софта для непосредственного использования). Проприетарный - значит коммерческий, закрытый от публики, следовательно (самое важное) - И КОД ЗАКРЫТ.
Но потом кто-то удачно все это дело спиздил, перелопатил как-то там слегка, адаптировал и создал уже свой протокол+программный продукт (почти близнец), назвав это - openpgp, подразумевая под этим полнейший opensource.
Ну чтож, спасибо этому крадуну, дал нам хоть пищу для обсуждений, не говоря уже обо всем остальном - т.е. ценнейшем вкладе в человеческое наследие, без шуток.
Суды, кстати, идут до сих(!!!)пор. Вот же сутяжники эти pgp-шники дешевые, даже винклвосы - и те уже давно схавались😁
Воистину - жадность фраера погубит.
Оставим эту драматургию и перейдем к технике:
(open)pgp - основан на rsa
т.е. sодержание (в данном случае сугубо текст) шифруется rsa-алгоритмом.
Реализация асимметрии↪️↩️ - в лоб:
a и b создали себе по паре 🗝🔑
обменялись 🗝
с помощью 🗝 друг друга шифруют исходящие пакеты
с помощью личных🔑- дешифруют входящие
И базово, благодаря rsa - это надежно. Но это базово ("один, условный и без ключа").
А в реальности (open)pgp сталкивается с проблемкой.. а точнее даже - с тремя:
2️⃣❗️человек-посередине будет собирать и копить пакеты уже точно зная, что они наши - ключ то 🗝ПУБЛИЧНЫЙ, к тому же ПОСТОЯННЫЙ (1️⃣❗распределение ключей). В один прекрасный день он соберет достаточно, после чего отправит к нам группу специалистов по крипто-ректальному-термо-анализу, получит наш 🔑 и расшифрует накопленные пакеты в 100% привязке к нашей грустной харе - какое уж тут 3️⃣❗️правдоподобное отрицание
Резюмируя по (open)pgp:
✔️надежно зашифрует пакеты, но и только
❗️постоянный, известный всем ключ - жесткое палево: мусора скопят пакеты, выпытают ключ, подошьют факты в дело
2.2.4.3. SSL/TLS (1995/1999)
Протокол tls - есть развитие (продолжение, дочка) протокола ssl, и строго технически говоря: все это е2е, т.к. обеспечивает шифрование из-конца-в-конец, но есть нюанс:
в данном случаем одним из концов будет сервер, потому что ssl/tls - это протокол шифрования клиент-сервер, тот самый, который дает s, в конце https, например.
❗️️Поэтому надо понимать:
да, tls/ssl позволяет безопасно общаться с сервером, но на самом сервере - все sодержание в открытом виде, поэтому для a и b - это НЕ безопасно, НЕ е2е.
Реализация ↪️↩️ в данном случае частичная:
асимметрично🗝🔑 (rsa) шифруется только одноразовый (на одну сессию) симметричный🔑 ключ
а уже с помощью него шифруются все дальнейшие пакеты
В целом, по факту ssl/tls - это https, т.е. - шифрование между посетителем и сайтом.. ну не знаю стоит ли тут вообще распинаться.. ладно, уговорили😁
❗️помимо того, что это бессмысленно изначально: за каждым сайтом все равно стоит своя сорм-коробка, а то и несколько
❗️помимо того, что сам протокол насквозь дырявый и критические уязвимости находят по сей день (ssl1->ssl2->ssl3->tls1->tls1.1/1.2/1.3)
❗️помимо того, что человеку-посередине нужен лишь БЕСПЛАТНЫЙ ssl-strip (kali linux) для полной дешифровки пакетов
Помимо всего этого, есть у ssl/tls одна фатальная, корневая, нерешаемая проблема - сертификаты и сертифицирующие центры.
Смысл в следующем:
ssl/tls должен не только зашифровать пакеты, но и удостоверить нас в том, что пакеты летят между нами и конкретным сайтом, оригинальным сайтом. Мы должны как-то точно узнать, что вводим свои логин/пароль именно на сайте своего банка, а не на фишинговом сайте с похожим доменом, например.
Обеспечить для нас это знание и должен некий сертифицирующий центр, путем выпуска сертификата для открытого ключа нашего банка.
Т.е. некий центр проверяет и удостоверяет, что:
банк - это банк
домен принадлежит банку
открытый ключ принадлежит банку
и все тут четко и законно
Это типа решает проблему распределения открытых ключей:
такой нотариус в интернете, авторитетная персона, которой мы должны почему-то поверить. Ну уже сами чуете куда идет, да?
Проблема с сертификатами и их центрами (а следовательно и с ssl/tls) в том, что они не могут выполнить ни одной поставленной задачи, не работают ни в одном направлении:
➡️это не может защитить нас от фишинга: вспоминаем клаудфлер и то, как легко он раздает свои серты (абсолютно такие же, законные, ничем не хуже других, в адресной строке все зелененькое и подтвержденное, как у настоящего банка) ботоводам, кардерам и фишерам
⬅️это не может обеспечить нам хоть мало-мальской сохранности данных: мусора приходят в сертифицирующий центр, выпускает себе дубль ключа/свой ключ, и дальше разгоняются как хотят - возможностей перехвата/дешифровки/разъеба не счесть
Резюмируя по ssl/tls:
❗️несмотря на https в адресной строке, все, что мы оставили в интернете - мы оставили В ОТКРЫТОМ ВИДЕ НА СТОЛЕ У МУСОРА, оставили НЕСКОЛЬКО РАЗ НАВСЕГДА
✔️это безопасно только когда мы - владелец сервера и центра, и хорошо при этом понимаем что, как и зачем делаем, и только как для владельца сервера; с точки зрения обычного юзера этот протокол не дает почти никакой безопасности - фиговый листок
2.2.5. базовая симметрия
Что касается полноценных, но при этом сугубо симметричных🔄протоколов (по аналогии с pgp и ↪️↩️), то их просто не существует в природе, т.к. распределение общего секретного🔑 невозможно организовать симметрично, придется изъебываться, получится уже не голая симметрия.
Но зато, существуют прекрасные симметричные алгоритмы, которые делают читаемое - 100%-но нечитаемым.
Быстро, с гарантией и одним 🔑 на выходе, ну а дальше ебитесь с ним как хотите
2.2.5.1. AES (1998), DES (1977)
И если ↪️↩️ начинается с rsa, то 🔄 - с aes.
Можно сказать, что aes пришел на смену алгоритму des, хотя напрямую ему и не наследует.
aes - это максимально надежно, это не ломается, это широко применяется не только в рамках е2е, но и для локального (офлайн) шифрования, например диска или флешки
Говоря об офлайн шифровании у aes, конечно, есть конкуренты, всякие рыбки и кузнечики, одни из которых вроде бы не так плохи, но уступают в скорости, другие - имеют сертификацию фсб (как вам такой серт-центр?😁).
Но в целом, нет ни одной разумной причины предпочесть aes'у другой алгоритм по части офлайна.
Что же касается е2е (т.е. онлайн шифрования), то тут все-таки стоит отметить достойного конкурента, а точнее даже - целое семейство:
2.2.5.2. Salsa/ChaCha (2005/2008)
Данное семейство симметричных🔄алгоритмов отличается от предыдущего (des/aes/и пр) самим алгоритмом, т.е. самим принципом шифрования:
aes (des) - это блочное шифрование, т.е. sодержание шифруется блоками, кусками, т.е. отдельными сообщениями/картинками/кусками голоса
в то время как
salsa/chacha - это потоковое шифрование, т.е. sодержание шифруется элементами, минимальными неделимыми частицами, т.е. буквами/символами/пикселями(🤷♂️)
Salsa20 - родоначальник семейства, сегодня используется нечасто, надо полагать из-за наличия более быстрых (оптимизированных) модификаций - xSalsa20, ChaCha20, xChaCha20, при этом ChaCha-ответвление еще и чуть более безопасное (усложненное).
Все это семейство рождено и модернизируется одним персонажем (ну или он просто фронтмен, хз) - Даниэлем Джулиусом Бернште(а)йном, низкий ему поклон, т.к. алгоритмы походу путевые, и именно для онлайна (е2е), судите сами:
✅пока никто не нашел ни одной дыры даже в самой первой sals'е, а активистов в этой сфере хватает, благо алгоритмы-то все - opensource (иначе и заикаться бы не стал)
✅потоковое существенно быстрее блочного (хотя aes все еще имеет запас скорости к сегодняшним реалиям, скажем так, но все-таки мир быстро меняется)
✅потоковому не так страшны обрывы связи (условно: потеряется не целое сообщение, а только 1 буква)
✅все больше и больше разработчиков/систем/протоколов переходят на/добавляют себе чачу-сальсу (в основном ChaCh'y20 почему-то, но причины уже точно за рамками данного исследования)
[к Содержанию ч.2]
2.2.6. промежуточный итог
Подведем небольшой итог.
По↪️↩️асимметрии:
❗️распределение ключей - все еще проблема, т.к. открытый ключ - палит всю хату, лишая нас возможности правдоподобно отрицать
❗️любое клиент-сервер шифрование (tls) предполагает расшифровку пакетов на сервере и не является для нас сколько-нибудь надежным, за исключением случаев, когда мы сами владеем/управляем тем сервером, или доверяем его владельцу/админу
❗️сертифицирующие центры - галимые нотариусы, а их сертификаты - галимые доверенности, и уж точно эта концепция никак не помогает решить ни проблему распределения ключей, ни проблему человека-посередине: человек-посередине защищает нас от человека-посередине😂, бля это ж надо было додуматься
❗️это медленно, поэтому практически никогда (за искл. pgp) не используется для шифровки sодержания
✅но это все еще предельно надежно (rsa) и порой удобно, поэтому широко используется в составе современных е2е-протоколов для шифрования небольших пакетов, сопровождающих sодержание (ключи/серты/чексуммы/итд)
Что же касается 🔄симметрии:
❗️ни ключи, ни середина, ни отрицание (3 проблемы) и здесь сами себя не защитят и не обеспечат, тем более что голая симметрия - это только алгоритмы, т.е. сугубо математика
✅но зато это предельно надежно
✅и кроме того, еще и довольно шустро, поэтому симметрия (aes/chacha) используется в рамках e2e-протоколов уже как раз для шифровки sодержания
Едем дальше
2.2.7. решаем 3 проблемы шифрования
Итак, способ надежно зашифровать sодержание (алгоритм) имеется, и даже несколько.
Теперь.
Чтобы из надежного алгоритма сделать надежный е2е-протокол нам необходимо решить все те же 3 насущные проблемы:
1️⃣❗️распределить ключи: будь они открытые или закрытые, постоянные или одноразовые - их надо распределить между a и b таким образом, чтоб ни одна
2️⃣❗️блядь-посередине не смогла получить доступ ни к ключам (любым🗝🔑), ни к открытым пакетам тем более, а также желательно не дать ей доступа к открытой метадате/чексуммам/сертам и прочей мелочи, которая сопровождает наши пакеты-с-sодержанием. И все это для того, чтобы оставить себе возможность
3️⃣❗️правдоподобно отрицать причастность ко всем этим пакетам/ключам/метадате/тяжкимпреступлениям
И, конечно, мы далеко не первые, кто задумался обо всем об этом.
2.2.7.1. распределяем ключи DH (1976), ECDH (2006)
В частности некто Диффи и его кентаврик Хеллман задумались о 1️⃣❗️распределении ключей довольно давно, и уже в 1976 представили миру свой протокол Дифи-Хеллмана (dh) - протокол обмена секретным 🔑 между a и b, которому не страшен никто-посередине, а ключ гарантировано достается только a и b, т.к. НЕ ПЕРЕДАЕТСЯ ПО СЕТИ
Технически выглядит примерно так:
1. для a и b создается (локально, в телефоне) по 1 открытому параметру - Oa и Ob, и по 1 закрытому - Za и Zb
2. a берет открытый параметр b - Ob (берет по сети, т.е. в открытую для всех)
2.1. добавляет к нему оба своих параметра - Oa и Za
2.2. локально, у себя в телефоне диффи-хеллмит (*dh) это все между собой
2.3. в результате получает некое значение, назовем его - dh-параметр
2.4. [условная] формула для a: (Ob+Oa+Za)*dh = dhOa
3. b в этот момент производит аналогичную (зеркальную) операцию, получая уже свой dh-параметр:
3.1. (Oa+Ob+Zb)*dh = dhOb
4. a и b обмениваются dh-параметрами друг друга по сети, в открытую: dhOa -> b, dhOb -> a
4.1. и при этом не боятся, что из dhO кто-то сможет размотать обратно их Z, т.к. придется перебрать пару триллионов вариантов
и наконец
5. a и b повторно диффи-хелмят dhO друг друга со своим Z, получая таким образом общий одинаковый🔑ключ, ЛОКАЛЬНО, У СЕБЯ В ТЕЛЕФОНЕ:
5.1. (dhOb+Za)*dh = 🔑 = (dhOa+Zb)*dh
Скажу вам по секрету: это пиздец как круто, а этих двух пассажиров (dh) можно смело причислять к лику святых, человечество им весьма обязано, но, как обычно, даже не в курсе🤦♂️
По большому счету, аналогов у этого не существует аж по сей день!
Справедливости ради надо отметить уже упомянутого ранее Бернште(а)йна, который в '06 году присобачил к dh какие-то там эллиптические кривые (🤷♂️🙈даже не спрашивайте) и назвал все это вместе - Elliptic curve Diffie–Hellman, или ecdh, или по-русски: диффи-хеллман-на-эллиптических-кривых.
Смысл этого тюнинга в скорости: эллиптический диффи существенно быстрее обычного, но никаких добавок по безопасности он не дает.
Консенсусное мнение специалистов:
ecdh не уступает в стойкости обычному dh
Хотя существует и иная точка зрения, но мы будем придерживаться консенсуса, тем более что если и уступает, то не сильно:
[условно] придется перебрать не пару триллионов комбинаций, а полтора триллиона
Поэтому
dh и ecdh - это надежно, это не ломается, это позволяет получить общий одинаковый🔑 безопасно, т.к. он создается локально, т.е. НЕ покидает телефон ВООБЩЕ
Конечно, существуют и другие протоколы распределения ключей: можно хоть tls'ом их раскидать, хоть любой другой асимметрией, опять же на эллиптические кривые ее частенько натягивают - всякие eddsa/ecdsa/ed-с-какими-то-цифрами. Но
Надо понимать!
Все эти способы распределения ключей - server-based.
Т.е. этот самый сервер увидит/сможет увидеть наши драгоценные ключи, а значит и наши куда более драгоценные сообщения/файлы/звонки.
Более того, наши драгоценные ключи будут еще и по сети гулять, что КРАТНО мультиплицирует угрозу (wifi в кафе/оператор на шлюзе/мусор на сорме).
Конечно, безопасно отправить ключ по сети можно, никакой магии: шифруем его как обычное сообщение надежным e2e-протоколом, делов-то😁
Но для этого ведь надо сначала безопасно раздать ключ, и на этом порочный круг server-based-ключей замыкается.
Поэтому
распределение ключей - это только (ec)dh, все остальное - от лукавого и безопасным НЕ ЯВЛЯЕТСЯ
И в целом эту насущную проблему можно считать решеной.. можно было бы, но как всегда есть нюанс:
2.2.7.2. нейтрализуем человека-посередине SHA (1995), Poly1305 (2005)
И тут мы опять упираемся в этого уебского 2️⃣❗️человека-посередине. Да, от него надо защищать не только основные пакеты, но и процесс распределения ключей, даже если он проходит с помощью (ec)dh.
В данном случае речь не столько о прослушке (от этого должно защитить шифрование), сколько о подмене: dh-параметров/ключей и, в конечном итоге, самого sодержания, что грозит уже не просто прослушкой, а самым что ни на есть "мам, скинь 100 рублей на телефон, я человека убил".
Чтобы решить проблему человека-посередине в корне, надо сделать довольно простую вещь:
убедиться, что пакет/ключ/итд, который a послал b, есть именно тот самый пакет/ключ/итд, что создал и отправил именно a, а не кто-нибудь-посередине.
Другими словами:
нужно обеспечить целостность и аутентичность пакета/ключа/итд
И с этой проблемой нам тоже повезло, потому что умные люди придумали такую штуку, как хеш-функция (mac/hmac): в отношении пакета вычисляется определенное значение, и такое значение будет уникальным для каждого уникального пакета. То есть:
два одинаковых сообщения "привет", отправленных одному и тому же адресату, но с разницей в долю секунды - это уже разные пакеты, у них будут разные хеш-функции
Еще проще:
хеш - это отпечаток пакета, он всегда уникален
Хеш вычисляется не просто из конкретного пакета с sодержанием, но и имеет корреляцию с предыдущим пакетом. Такая конструкция надежно защитит нас от этого уебка-посередине: если он в моменте вклинится и попытается что-то перехватить/подделать - у нас сразу перестанут биться хеши.
Понимающие могут усомниться: хеши-то брутят (т.е. перебирают sодержание пока не совпадет). И да, это так, но лишь отчасти.
❗️Во1, успешно брутятся только слабые алгоритмы хеширования, в 1 очередь - md5, реже sha1 (1995)
❗️Во2 и в главных, успешно брутится только совсем простое sодержание, в 1 очередь - пароли (по словарю).
Раньше еще кредитки (только цифры - идеально для перебора), но те времена давно минули, т.к. карточек в хешах больше не существует в природе, вымерли.
В свете вышесказанного, рекомендую понимающим провести натурный эксперимент:
1. придумать пароль, которого нет в словарях, т.е.: символов 25, a-Z, 0-9, !@#$
2. захешить его хотя бы даже md5
3. и попробовать сбрутить его любым доступным методом, коих - сотни.
После нескольких месяцев безуспешных попыток, порекомендовал бы экспериментаторам поберечь себя и перейти в плоскость рассуждений:
4. увеличить пароль (п.1) в 2-100 раз (примерно так будет выглядеть наше шифрованное общение с позиции-посередине)
5. захешить это предельно надежным sha2 (в миру - sha256/512)
6. и прикинуть хуй к носу: реально это сбрутить или нет?🙂
Помимо упомянутых выше
sha1, который не считается надежным (хотя это скорее про небольшие-пароли-по-словарю, в условиях е2е угроза стремится к нулю, но тем не менее)
и
sha2 (2012), который предельно надежен и не взламывается на существующих мощностях (если это опять же не пароль-по-словарю)
существует также
sha3 (2015), который еще надежнее, (и тоже бывает 256/512, кстати), но в рамках е2е-шифрования почему-то не применяется
Ну и кроме того, уже легендарный Бернште(а)йн и здесь постарался и создал протокол хеширования poly1305, который, по классике, не уступает в стойкости, но зато быстрее работает. Выказываем ему очередную порцию уважения.
Теперь суммируем по mitm/чел-посеред/целостность-и-аутентичность:
от mitm'а нас надежно защитят протоколы sha2 и poly1305, все просто🙂
И напоследок скажем, что есть еще dtls, который тоже призван обеспечить целостность и аутентичность пакетов, но вы уже умненькие, и видите там недвусмысленное tls, а это значит от mitm'a нас будет защищать другой mitm, сразу на душе спокойствие, да?
Повезло лишь, что применяется этот dtls очень узко, о чем скажем чуть позже.