Что такое handshake в контексте передачи данных по сети ethernet
Обновлено: 07.07.2024
За созданием этого проекта стоят люди, подарившие миру Purse и Private Internet Access .
Handshake , несмотря на популярное заблуждение, не стремится децентрализовать существующую DNS-инфраструктуру во всей её полноте. Это значило бы замахнуться на нечто много большее, чем то, что может быть по зубам любой криптовалютной системе. Отчасти по этой причине ни одному из предшественников Handshake не удалось добиться истинного принятия.
Проект Handshake намеревается заместить посредника в лице ICANN децентрализованным блокчейном на основе proof-of-work и использовать криптографические подписи для управления этой неотъемлемой частью инфраструктуры, на которой основывается безопасность самого интернета.
И это, хоть и более точное, но тоже довольно поверхностное объяснение. Вы же пришли сюда за сырой, сочной информацией, дистиллированной из документации проекта и полученной из уст его участников, правда?
Я говорила с Кристофером Джеффри , плодовитым системным инженером, который спроектировал и написал реализацию блокчейна Handshake, а до того известным тем, что представил альтернативный биткойн-клиент bcoin .
Кроме того, я много дискутировала с Джозефом Пуном , безумным гением, стоящим за двумя главными решениями второго уровня для масштабирования блокчейнов – Lightning Network и Plasma , – который участвовал в разработке предлагаемых механизмов распределения для Handshake.
Готовы? Ведь вас ожидает погружение в самые глубины этого протокола, и чем дальше, тем больше технических подробностей будут вам открываться.
Центры сертификации
Центры сертификации в DNS-сети, построенной так, как сегодня, являются доверенными распорядителями, ответственными за функционирование интернета. Целью этих организаций, как объясняется в whitepaper проекта , является максимизация прибыли. То есть, у ICANN нет альтруистических стимулов действовать добросовестно, но зато у неё есть все стимулы для сохранения своей естественной монополии на управление критически важным слоем глобальной сети. И даже если пока центры сертификации действуют добросовестно, точка зрения сторонников децентрализации основывается на том, что нам вообще не следовало бы полагаться на один централизованный орган управления, особенно если речь идёт о пространстве, где сосредоточено всё человеческое знание.
Если сейчас эти несметные богатства эксплуатируются централизованными организациями, стоящими на самой вершине иерархии, децентрализация модели управления пространством имён, в случае успеха, может распределить этот ресурс в новой открытой и основанной на распределённом реестре сети, которая надёжно и эффективно заместит собой существующую парадигму.
Познакомьтесь с Handshake
Вопреки распространённому мнению, бóльшая часть проблем, с которыми мы сталкиваемся сегодня, с помощью блокчейна не решается. И многие из вас, скептиков, прекрасно это понимают. Но что касается Handshake, что делает этот специализированный блокчейн настолько полезным и, пожалуй, идеальным решением для управления распределением доменных имён?
Трилемма Зуко гласит, что, если речь идёт о пространстве имён, то одновременно можно удовлетворить только два из этих трёх свойств:
- удобочитаемые имена
- безопасность
- распределённое пространство имён
Handshake, будучи блокчейном базового уровня, едва ли когда-то столкнётся с проблемами масштабируемости.
Софт-форк к массовому принятию
Главное затруднение, с которым сталкивался каждый протокол именования, стремящийся к подлинному принятию, заключалось в решении проблемы интеграции и удобства использования.
Как ваше по определению более медленное блокчейн-приложение может даже пытаться превзойти намного более быстрое и удобное централизованное решение, уже используемое миллиардами людей?
Handshake был кропотливо реализован таким образом, чтобы быть софт-форком для существующей интернет-инфраструктуры, с полным осознанием того, что любые попытки перевести пользователей на новую, непроверенную систему являются нереалистичными и препятствуют широкому использованию системы. Речь идёт об ассимиляции, а не о миграции. И это делает использование системы именования Handshake намного более удобным в сравнении с предшественниками.
Для ускорения принятия своей системы проект использует два метода:
- Компактные доказательства для локального разрешения имён (SPV)
- Интегрирование стимулов от сопровождающих пакетов
Разрешение имён с SPV
Для обеспечения максимальной открытости, децентрализации, безопасности и, самое главное, устойчивости к цензуре, Handshake использует алгоритм proof-of-work. Такое решение позволяет тем, кто содержит узлы упрощённой проверки платежей (Simplified Payment Verification, SPV) бездоверительным образом разрешать имена со скоростью, превосходящей отправку запроса на DNS-резолверы Google. Это быстрее в том случае, если ваш полный/SPV узел имеет локальный кэш данных. (Я попробовала это на своём опыте, запустив SPV-клиент!)
В отличие от предшествующих протоколов, Handshake с введением компактных SPV-доказательств открывает совершенно новые перспективы. Это по определению позволяет исключить (что очень важно) из процесса верификации доверие к третьей стороне, так как ваш SPV-клиент позволяет локально запускать собственный рекурсивный DNS-резолвер. Архитектура же существующей DNS просто не допускает такого прямого разрешения без посредничества центрального органа.
Изначально в Handshake использовалась требовательная к памяти функция графа под названием Cuckoo Cycle , созданная Джоном Тромпом и применявшаяся в таких проектах, как æternity и MimbleWimble . Впоследствии от неё было решено отказаться в пользу SHA3, старой доброй хеширующей функции, которую невозможно взломать даже с использованием всех существующих вычислительных мощностей мира (и даже с квантовыми вычислениями будущего). Кристофер всерьёз обмолвился, что хочет сделать блокчейн Handshake настолько надёжным, чтобы он продолжал функционировать и после того, как человечество покинет Землю.
Интеграция со стороны сообщества FOSS (Free and Open-Source Software)
В этом есть большой смысл! Почему другие проекты так не делают?
Идея состоит в том, чтобы отблагодарить людей, включивших бесплатные программы в открытый код, которые изначально не рассчитывали получить финансового вознаграждения. Аналогичным образом, Handshake будет выплачивать финансовое вознаграждение той же группе людей, не ожидая получить от них взамен программный продукт.
Тем не менее социальный стимул для создания ПО, включающего в себя библиотеку интеграции Handshake, остаётся.
Рождение Urkel: от разреженных деревьев Меркла, Merklix-деревьев и MerkleSet к высокооптимизированному хранилищу проверенных данных
Следующий раздел основан на расшифровке моего интервью с Кристофером:
Появление Handshake принесло с собой множество инноваций, которые, я думаю, ещё окажут воздействие на развитие всей криптосферы. Одно из наиболее примечательных таких новшеств – это проверяемое хранилище данных, называемое деревом Urkel. В отличие от всех предшествующих блокчейн-систем, Handshake использует собственную – первую в своём роде и реализованную специально для использования с блокчейнами – структуру аутентифицированных данных, которая не касается levelDB или любого другого хранилища данных.
Urkel на данный момент написан на JavaScript, а портативная библиотека C запланирована на ближайшее будущее.
Дерево Меркла с плоскими файлами представляет собой адаптацию предложенных (хотя и не реализованных) Брэмом Коэном ( Chia Network ) и Амори Сечетом ( deadal nix ) ( Bitcoin ABC ) меркелизованных структур данных, называемых MerkleSet и Merklix Tree соответственно.
Кристофер обнаружил, что ни 16-ричное trie Эфириума, ни разреженное дерево Меркла, не отвечают требованиям Handshake:
Исследуя 16-ричное префиксное дерево Эфириума
Ключевые результаты исследования:
- В тестах производительности Urkel продемонстрировал примерно в 50–100 раз лучшую скорость, чем 16-ричное trie Эфириума.
- Размер двоичных доказательств Urkel оказался в 4 раза меньше 16-ричных доказательств Ethereum.
Исследуя разреженное дерево Меркла
В процессе исследования реально используемых структур данных, прежде чем принять решение о выборе в пользу автономной структуры данных, предназначенной специально для блокчейнов, Кристофер пришёл к конструкции, которую рассматривал и Виталик в качестве предпочтительной структуры проверенных данных для Plasma, и называемой разреженным деревом Меркла (Sparse Merkle Tree, SMT). При её реализации Кристофер обнаружил, что этот вариант не жизнеспособен, так как тяжёлое кэширование, необходимое для поиска в базе данных, негативно влияло на удобство использования. Так что от этого варианта тоже было решено отказаться.
Проект Certificate Transparency от Google единственный использует в эксплуатационной среде SMT, реализованный также поверх существующего хранилища данных (levelDB).
Ключевые результаты исследования:
- Превосходство Urkel в быстродействии по сравнению с разреженным деревом Меркла от Google было поразительным – в 500 раз.
- При этом компактные доказательства Urkel имели приблизительно тот же размер, что и сжатые SMT-доказательства – <1 Кбайта на десятки миллионов листьев. (Бинго!)
Такова истинная история происхождения Urkel (а не то, что вам покажут по телевизору).
Ковенанты
Эти ковенанты допускают динамическое поведение на уровне консенсуса, обычно отсутствующее в высокоограниченных основанных на UTXO машинах состояний, как Биткойн. Стремление к ковенант-подобному поведению, в сущности, привело к эксперименту по созданию платформы приложений, известному как Ethereum , система на основе счетов. Но Handshake, с реализацией смарт-контрактов поверх системы, основанной на UTXO, с добавлением новых опкодов скриптов в готовый к использованию код – это ещё один пример инноваций, открывающий новые возможности для всей экосистемы. Эта конструкция позволяет посредством софт-форков вводить в протокол поддержку новых типов ковенантов способом, прямо совместимым с будущей сетевой инфраструктурой DNS. Однако ковенанты в Handshake остаются специализированными и не предназначены для построения децентрализованных приложений, как смарт-контракты в Ethereum – ещё одно проектное решение, делающее блокчейн Handshake в высокой степени оптимизированным для решения конкретной задачи именования.
Как работает аукционная система
Аукционная система реализована как ковенант на уровне консенсуса, разбитый на отдельные действия, описанные на выходном слое как covenant_type (настолько низкоуровнево, насколько возможно). В Handshake используется аукцион Викри, однораундный закрытый аукцион, в котором право на покупку получает участник, предложивший максимальную ставку, но покупка осуществляется по второй максимальной ставке. На том, как принималось решение об алгоритме проведения аукциона, мы подробно останавливаться не будем. Вместо этого я лучше расскажу вам непосредственно о процессе приобретения имён на Handshake.
Приведём наглядный пример: для того чтобы сделать ставку на приобретение доменного имени, нужно использовать тип ковенанта bid . Вы отправляете деньги на счёт ковенанта, где они блокируются до окончания аукциона. Это слепые ставки, истинные ставки других участников вам неизвестны. То есть, у вас есть фактическая ставка (скажем, 5 HNS), но по желанию вы можете задать для маскировки большее значение (например, 10 HNS), которое будет скрывать истинный размер вашей ставки.
Ковенант принимает вашу фактическую ставку, связывает её с неким случайным одноразовым кодом, хеширует и предоставляет вам полученный хеш. После недельного периода раскрытия вы раскрываете ( reveal ) использованный код, что открывает вашу фактическую ставку в 5 HNS. После раскрытия вы выводите со счёта ковенанта 5 HNS сдачи.
(заблокированная сумма) – (фактическая ставка) = ваша сдача
5 HNS вашей фактической ставки остаются заблокированными в течение двух недель, пока аукцион не будет закрыт. По окончании аукциона выбирается его победитель, а проигравшие получают свои ставки обратно – проигравшие могут выйти из ковенанта.
Деньги победителя – помните, покупка происходит по второй максимальной ставке – отправляются на другой ковенант, register . Ковенант register предназначен для ведения и обновления имён. Монеты, отправляемые на этот ковенант, не могут быть из него выведены, то есть монеты победителей аукционов фактически сжигаются.
Отзыв
Отдельно следует упомянуть ковенант с функцией отзыва имени ( REVOKE ). Подобно функции выхода из игры в Plasma, отзыв в Handshake является крайней мерой и последней возможностью для законного владельца имени отменить или оспорить его передачу в случае утраты владельцем своих ключей. Наличие этой опции полностью лишает кражу имён финансового стимула.
DNSSEC “доказательства владения”
Ещё одна ошибка в дизайне предшественников Handshake, которая станет для них фатальной, заключается в игнорировании существующих владельцев имён. Представим, что я Microsoft и вложил существенный капитал в свой бренд, стоимость которого инкапсулирована в доменное имя. И вот появляется какая-то новая предлагаемая DNS-система, которая говорит мне, что в их системе я больше не владею этим именем. С чего бы мне на неё переходить?
Имея это в виду, Handshake предварительно резервирует топ-100.000 имён по версии Alexa, право собственности на которые может быть заявлено их полноправными владельцами в течение 4-х лет с даты запуска основной сети. Для того чтобы предъявить право собственности на свои имена, владельцы просто представляют очень конкретное DNSSEC-доказательство, которое в протоколе Handshake довольно остроумно перепрофилировано для использования в качестве безопасного подтверждения права владения именем. Важно то, как именно они реализовали процесс подтверждения имён существующими владельцами – распределение имён производится автоматически блокчейном, без участия кого-либо, хоть как-то причастного к проекту.
Вот что рассказал мне об этом процессе Кристофер:
Для создания финансового стимула, блокчейн Handshake выплачивает существующим владельцам имён вознаграждение в нативных койнах протокола при заявлении ими права собственности на свои доменные имена.
Вот где пригодятся средства венчурных капиталистов и фондов. Если ICO-модель потенциально деактуализирует этот класс инвесторов, то в модели изобилия им предназначена очень важная функция: оценить стоимость этих новосозданных койнов на основании сделанных инвестиций. С их инвестиционной поддержкой койны получают внутреннюю стоимость ещё до того, как будут выпущены на свободный рынок для определения цены. На момент написания статьи, венчурный капитал оценивает токен HNS в 0,10 $.
- В общей сложности 7,5 % из 1,36 млрд монет HNS предназначены для выплат существующим владельцам доменных имён при предоставлении ими достаточно надёжных DNSSEC-доказательств собственности.
- Ещё 2,5 % из 1,36 млрд монет предназначены для владельцев TLD, при условии, что они заявят и свои права на них.
Невостребованные монеты будут сожжены по окончании 4-летнего периода после запуска основной сети.
Интервал вывода имён
Люди могут открыть аукцион для любого имени, если оно не находится в списке предварительно зарезервированных имён и находится в пределах интервала вывода. Интервал вывода – это еженедельный вывод имён, которые становятся доступными для приобретения. В течение одного года для участия в торгах станут доступны все имена.
Для определения того, находится ли имя в интервале вывода, аналогично тому, как это реализовано в ENS, протокол Handshake хеширует имя, которое вы хотите открыть, запускает SHA3 над строкой, берёт остаток от деления на 52 и даёт вам конкретный номер недели, затем умножает это число на среднее количество блоков в неделю, в результате чего вы получаете высоту блока, на которой будет выводиться на рынок ваше имя. Таким образом, интервал вывода является детерминистически случайным и равномерно распределяется для всех доступных имён.
Заключительные замечания
Я написала эту статью, потому что очень верю в будущее Handshake, зная уровень мастерства и степень дотошности, с какими реализовывался этот проект.
И хотя многое из того, о чём шла речь в этой статье ещё не прошло проверку свободным рынком, идеи проекта выглядят вполне убедительно. Надежда состоит в том, что, чем больше светлых умов будут следить за этим экспериментом – за тем, что он представляет сейчас и чем потенциально может стать – тем больше предпринимателей, гениев и безумных учёных смогут взять на вооружение эти технические решения и механизмы организации, чтобы построить собственные неантагонистические проекты и таким образом способствовать росту рыночного изобилия, а не монопольной эксплуатации.
Когда больше лидеров мнений и предпринимателей придут к тому, чтобы структурировать свои модели подобным образом, мы сможем отойти от модели ICO и вступить в новую эру экономики дарения .
Подписывайтесь на BitNovosti в Telegram!
Делитесь вашим мнением об этой статье в комментариях ниже.
Этичный хакинг и тестирование на проникновение, информационная безопасность
Что такое рукопожатие (handshake — хендшейк)
С технической точки зрения, рукопожатие в беспроводных сетях — это обмен информацией между точкой доступа и клиентом в момент подключения клиента к ней. Эта информация содержит разнообразные ключи, обмен происходит в несколько стадий. Процесс подключения к беспроводной точке доступа неплохо документирован и вы можете найти по данному вопросу много информации, в том числе и на русском языке.
С практической точки зрения нам достаточно знать всего две очень простые вещи:
- рукопожатие можно захватить во время подключения клиента, который знает валидный пароль, к беспроводной точке доступа
- рукопожатие содержит достаточно информации для расшифровки пароля.
Все беспроводные точки доступа делают это
Расшифровка пароля из рукопожатия делается методом перебора (грубой силой, брутфорсингом). Именно поэтому расшифровка пароля в захваченном рукопожатии имеет вероятностный характер. Т.е. далеко не всегда заканчивается удачно.
Если у вас мощное железо и много времени, то ваши шансы увеличиваются.
Я считаю захват рукопожатий самой перспективной методикой взлома беспроводной точки доступа. Это мнение может показаться странным при том количестве новых техник по взлому WEP, WPS и при довольном низком проценте успешных взломов рукопожатий.
Дело в том, что количество точек доступа с включёнными WEP, WPS невелико. Благодаря просветительской деятельности (в том числе урокам подобным моим) самые обычные пользователи стали больше задумываться о безопасности, вникать в суть технологий и отключать уязвимые алгоритмы и стандарты.
Ещё одно наблюдение по мере накопления опыта: даже точки с включённым WPS иногда быстрее взломать захватом рукопожатия, чем ждать завершения работы Reaver или Penetrator-WPS. Дело в том, что если пользователь не задумался об отключении WEP, WPS, т. е. проявил безалаберность, то также высока вероятность неряшливости пользователя в выборе пароля — обычно это простые слова или фразы из словаря, которые довольно легко подбираются.
Вообще, можно сказать, что, формально, захватив рукопожатие, можно практически гарантированно взломать Wi-Fi, для этого нужно:
- мощное железо
- достаточно много времени
- не слишком сложный и длинный пароль
Как захватить хендшейк в Kali Linux
Алгоритм достаточно простой:
- смотрим доступные точки доступа
- выбираем точку доступа, запоминаем её ВSSID и номер канала
- переходим в режим ожидания рукопожатия на заданном сигнале
- (опционально) форсируем процесс путём применения атаки деаутентификация
Предполагается, что вы уже знакомы со статьями
В противном случае, у вас могут быть вопросы по изложенному здесь материалу.
Переводим карту в режим монитора
Смотрим доступные для атаки точки доступа
Я выбрал сеть Mial, её ВSSID 20:25:64:16:58:8C на канале 1. Поэтому я запускаю airodump-ng на первом канале
После ключа -w идёт префикс файла cap2 (это имя без расширения). В этот файл будет записано захваченное рукопожатие.
Можно ничего не делать — достаточно просто ждать, когда кто-то подключится или переподключится естественным образом. Если вы торопитесь, то можно форсировать процесс использованием атаки деаутентификация.
Для этого мы открываем новое окно терминала и набираем там команду:
Здесь -0 означает деаутентификация, 5 означает количество отправленных пакетов, -a 20:25:64:16:58:8C это ВSSID целевой ТД, а wlan0 — сетевой интерфейс в режиме монитора.
Результат не заставил себя долго ждать:
Надпись «WPA handshake: 20:25:64:16:58:8C» говорит нам о том, что рукопожатие уже захвачено.
Убеждаемся, что это действительно так:
Плюсы использования атаки деаутентификация:
- значительно ускоряется процесс получения рукопожатия
Системы обнаружения вторжений и мониторинга в этот момент могут вас засечь. При пассивном ожидании рукопожатия вы остаётесь полностью невидимым для этих систем.
Захват рукопожатий на 5 ГГц (802.11a/h/j/n/ac)
По умолчанию, airodump-ng скачет по каналам с 1 по 14 — это каналы 2.4 ГГц (т.е. 802.11b/g/n).
Протоколы 802.11a/h/j/n/ac работают на 5 ГГц, сюда входят каналы с 34 по 180.
На самом деле, процесс захвата рукопожатий на 5 ГГц ничем особо не отличается. Просто нужно явно указать каналы.
Но прежде чем пытаться что-то захватить, давайте проверим, какие вообще частоты поддерживает ваша беспроводная карта. Поскольку если ваша карта не поддерживает 5 ГГц, то можно и не пытаться — результата не будет. Проверку можно сделать командой:
Не забывайте, что вместо wlan0 вам нужно указать имя вашего желаемого беспроводного интерфейса.
Т.е. моя беспроводная карта может работать на частоте 5 ГГц с каналами с 36 по 140. А также на частоте 2.4 ГГц с каналами с 1 по 13.
Ещё больше информации вам даст команда
Там очень много самых разнообразных сведений по вашей беспроводной карте.
Если ваша беспроводная карта поддерживает 5 ГГц, то можно продолжать. Чтобы «осмотреться» в радиовещании наберите:
Думаю, особо здесь объяснять нечего, опцию --channel мы уже использовали ранее. Можно вместо каналов указывать непосредственно частоты или диапазон частот, это делается с помощью ключа -C, например:
Ключ и опция -C 5170-5825 указывают частоты в Мегагерцах, которым соответствуют каналы с 36 по 165. Эта и предыдущая команда полностью равнозначны.
Если вам вдруг интересно, то вот номера каналов и соответствующие им частоты:
802.11b/g/n
| Канал | Центральная частота (ГГц) |
|---|---|
| 1 | 2,412 |
| 2 | 2,417 |
| 3 | 2,422 |
| 4 | 2,427 |
| 5 | 2,432 |
| 6 | 2,437 |
| 7 | 2,442 |
| 8 | 2,447 |
| 9 | 2,452 |
| 10 | 2,457 |
| 11 | 2,462 |
| 12 | 2,467 |
| 13 | 2,472 |
| 14 | 2,484 |
802.11a/h/j/n/ac
| Канал | Частота (ГГц) |
|---|---|
| 34 | 5,170 |
| 36 | 5,180 |
| 38 | 5,190 |
| 40 | 5,200 |
| 42 | 5,210 |
| 44 | 5,220 |
| 46 | 5,230 |
| 48 | 5,240 |
| 52 | 5,260 |
| 56 | 5,280 |
| 60 | 5,300 |
| 64 | 5,320 |
| 100 | 5,500 |
| 104 | 5,520 |
| 108 | 5,540 |
| 112 | 5,560 |
| 116 | 5,580 |
| 120 | 5,600 |
| 124 | 5,620 |
| 128 | 5,640 |
| 132 | 5,660 |
| 136 | 5,680 |
| 140 | 5,700 |
| 147 | 5,735 |
| 149 | 5,745 |
| 151 | 5,755 |
| 153 | 5,765 |
| 155 | 5,775 |
| 157 | 5,785 |
| 159 | 5,795 |
| 161 | 5,805 |
| 163 | 5,815 |
| 165 | 5,825 |
| 167 | 5,835 |
| 171 | 5,855 |
| 173 | 5,865 |
| 177 | 5,885 |
| 180 | 5,905 |
802.11y
| Канал | Частота (МГц) | США | ||
|---|---|---|---|---|
| 5 МГц | 10 МГц | 20 МГц | ||
| 131 | 3657,5 | Да | Нет | Нет |
| 132 | 3662,5 | Да | Нет | Нет |
| 132 | 3660,0 | Нет | Да | Нет |
| 133 | 3667,5 | Да | Нет | Нет |
| 133 | 3565,0 | Нет | Нет | Да |
| 134 | 3672,5 | Да | Нет | Нет |
| 134 | 3670,0 | Нет | Да | Нет |
| 135 | 3677,5 | Да | Нет | Нет |
| 136 | 3682,5 | Да | Нет | Нет |
| 136 | 3680,0 | Нет | Да | Нет |
| 137 | 3687,5 | Да | Нет | Нет |
| 137 | 3685,0 | Нет | Нет | Да |
| 138 | 3689,5 | Да | Нет | Нет |
| 138 | 3690,0 | Нет | Да | Нет |
Вот какие результаты я собрал вокруг себя:
Кстати, обратите внимание, что каналы по какой-то непонятной причине не отобразились.
Можно указать airodump-ng прыгать по всем каналам и не беспокоиться, что мы что-то упустили в каком-то диапазоне частот:
Кстати, это помогло определить канал для ТД на 5 ГГц — канал оказался сороковым:
Захват рукопожатия в 5 ГГц ничем не отличается:
Также можно использовать атаку деаутентификация, чтобы ускорить процесс.
Если ваша беспроводная карта не поддерживает частоты на 5 ГГц, то для того, чтобы видеть сети на этих частотах и для выполнения разнообразных атак в отношении них, вам необходима Alfa AWUS051NH. Она работает на частотах 2.4 ГГц и 5 ГГц, поддерживает беспроводной стандарт N, поддерживает замену антенны, полностью совместима с Kali Linux и BlackArch, т.е. способна переходить в режим монитора и делать инъекцию фреймов.
Расшифровка рукопожатия в Kali Linux
Это отдельная наука. Расшифровка хендшейков «в лоб» может занять на порядок больше времени, чем эта же расшифровка, но с применением таких методик как: предварительный расчёт хешей, использование мощи графического процессора, использование словарей, использование масок и других приёмов, ускоряющих брутфорсинг.
В середине 90-х компания Netscape выпустила протокол, который повышал безопасность электронных платежей. Протокол получил название SSL и являлся предшественником протокола TLS. Версия 1.0 так и не пошла «в народ», будучи отбракованной на этапе тестирования. Версия 2.0 вышла в свет, но имела дыры в защите.
Если в настройке SSL не наблюдается погрешностей, сторонний наблюдатель не получит доступа к пакетным данным, в том числе не сможет их прочесть или подменить. Вся информация, которая окажется ему доступной – общая, не выходящая за рамки приватности: тип шифрования, примерный объем данных и частота пересылки.
Параметры безопасности
Протокол обеспечивает безопасность работающих над ним приложений. Гарантия имеет три направления: сохранение конфиденциальности, аутентификацию и контроль целостности данных.
- Конфиденциальность. Пользуясь симметричными алгоритмами, протокол TLS шифрует данные, которые передаются. Если данные окажутся перехваченными, прочесть их будет невозможно.
- Аутентификация. Гарантия, что обмен данными идет между теми узлами, для которых изначально создавался канал связи.
- Контроль целостности. Односторонним хэшированием проверяется входящая информация, исключая возможность подмены или искажения.
При использовании протокола веб-браузером поддерживаются параметры, способные обеспечить высшую степень безопасности. Статистика протокола TLS дает следующие данные:
TLS-рукопожатие
TLS False Start
Если клиент и сервер ранее устанавливали связь, функция позволит пропустить процедуру генерации ключей. Для установления безопасного канала связи будут использованы ключи, которые были вычислены ранее. Однако сессии имеют ограниченное время жизни, и если период сессии истек – придется повторно проводить процедуру TLS-рукопожатия.
TLS Chain of trust
Процедура строится на сертификатах подлинности и обеспечивает аутентификацию между сервером и клиентом. Сертификаты выдаются Центрами сертификации, которые периодически проверяют подлинность и могут отозвать сертификат, если он скомпрометирован. Именно эта процедура обеспечивает проверку подлинности передаваемых данных.
Версии протокола
- TLS 1.2 — на данный момент эта версия протокола TLS встречается чаще прочих. К сожалению, имеет уязвимости: чтобы поддерживать старые компьютеры, TLS 1.2 разрешает использование устаревших техник шифрования, которые малонадежны. Протокол сильно уязвим к активному вмешательству в соединение, когда взломщик перехватывает данные посреди сессии, а отправляет их уже после прочтения или подмены. Большинство уязвимостей обнаружены за последние 2 года, что и послужило толчком для создания обновленной версии.
- Статистика протокола TLS 1.3. В этой версии не поддерживаются устаревшие системы шифрования, благодаря чему протокол справляется с большинством уязвимостей. TLS 1.3 совместим с более старыми версиями: если одна из сторон не имеет возможности пользоваться новой системой шифрования, соединение откатится до версии 1.2. Если же во время атаки активного вмешательства взломщик попытается принудительным образом откатить версию протокола посреди сессии – такое действие будет замечено и сессия прервется.
Сертификат и конверсия
Современные требования к защите данных настолько строги, что браузеры буквально приучили пользователей негативно реагировать на сайты без сертификата. Пользователя пугает уведомление и связанные с ним риски — едва ли он посетит подобный сайт. Если протокол TLS установить корректно, то браузер не только уберет страшное уведомление, но еще и подсветит адресную строку зеленым. Посетители приучены доверять таким сайтам, ведь за доверием стоит TLS-технология, обеспечивающая безопасность обмена данными.
Особенно важен сертификат для сайтов, на которых необходимо указывать приватную информацию: пароли, коды, данные платежных систем. Сайт, имеющий сертификат, будет качественнее индексироваться поисковыми системами, в отличие от своего не сертифицированного собрата.
Уже купили виртуальный хостинг для сайта? Не забудьте о домене и сертификате TLS. Если только еще подумываете покупать сертификат – обращайте внимание на стандарты шифрования, которыми пользуется компания, предоставляющая защищенный канал связи.
Преимущества и недостатки протокола TLS
Еще в 1999 году, когда в SSL обнаружили уязвимости, было очевидно, что необходим обновленный протокол защиты данных. Это обстоятельство задало курс и тенденцию протоколу TLS. В 2014 POODLE успешно атаковал SSL 3.0, не оставив протоколу малейшего шанса. Что уж говорить о ранних версиях SSL.
Осенью 2014 Бодо Мёллер и его коллеги из Google Security Team обнаружили уязвимость в архитектуре протокола SSL 3.0. Атака POODLE подменяет пользовательские данные, и байт за байтом расшифровывает содержимое защищенного канала. Не существует способа обойти кодовую уязвимость, единственное логичное решение — блокировка использования протокола SSL 3.0 на всех рабочих системах.
Дизайн протоколов во многом идентичен: протокол TLS создавался по мотивам SSL, но в отличие от последнего параметры безопасности протокола TLS постоянно обновляется, в нем нет критических кодовых уязвимостей, что обеспечивает надежную защиту при транспорте данных.
Протокол TLS имеет ряд концептуальных отличий от SSL-протокола:
- В TLS используются другие ключи и увеличенный набор шифров.
- Улучшены стандарты формирования ключа на основе пароля.
- Есть различия в хэшировании HMAC, которое выполняет функцию создания блока симметричных ключей.
- Введены алгоритмы, увеличивающие безопасность канала.
Начинающие веб-разработчики сталкиваются с непростым вопросом: какой протокол выбрать? Для специалиста со стажем выбор очевиден – настройка протокола TLS идентична SSL, при этом безопасность шифрования на несколько порядков выше. Более того, специалисты по безопасности Google настоятельно рекомендуют не использовать SSL-протокол, отдавая предпочтение TLS.
Тем не менее, огромное количество пользователей ошибочно называют TLS «SSL-шифрованием». Откуда пошла путаница: поставщики сертификатов и веб-браузеры «застряли» в термине, который давно и плотно укоренился.
Знайте: когда вам предлагают «SSL-шифрование» — подразумевают TLS.Соединение, защищенное протоколом TLS, обладает одним или несколькими следующими свойствами:
Из-за невозможности гарантировать безопасность сети, через которую передается информация наилучшим способом защитить ее было выбрано шифрование и дешифрование на концах устанавливаемого соединения соответственно. Netscape могли бы встроить этот подход напрямую в свой браузер, но это бы не предоставило единого решения, которое другие приложения могли бы использовать. Требовалось получить более общный, независимый от приложения подход.
В итоге, Netscape разработал протокол SSL работающий поверх TCP, а также предоставляющий TCP-подобный интерфейс для приложений более высокого уровня. В теории, одним из преимуществ SSL для разработчиков являлась возможность заменить все традиционные TCP вызовы на новые SSL вызовы. Специфические детали того, как SSL шифрует и дешифрует данные были относительно прозрачны.
Работу протокола можно разделить на два уровня:
- Слой протокола подтверждения подключения (Handshake Protocol Layer)
- Слой протокола записи
Первый слой, в свою очередь, состоит из трех подпротоколов:
- Протокол подтверждения подключения (Handshake Protocol)
- Протокол изменения параметров шифра (Cipher Spec Protocol)
- Предупредительный протокол (Alert Protocol)
Протокол подтверждения подключения производит цепочку обмена данными, что в свою очередь начинает аутентификацию сторон и согласовывает шифрование, хэширование и сжатие. Следующий этап — аутентификация участников, которая осуществляется также протоколом подтверждения подключения.
Существует четыре протокола записи:
- Протокол рукопожатия (handshake protocol);
- Протокол тревоги (alert protocol);
- Протокол изменения шифра (the change cipher spec protocol);
- Протокол приложения (application data protocol);
Принцип работы SSL состоит из двух фаз: фаза рукопожатия и фаза передачи данных. Во время фазы рукопожатия клиент и сервер используют шифрование открытым ключом для того, чтобы определить параметры секретного ключа, используемого клиентом и сервером для шифрования во время фазы передачи данных.
Сертификат - это набор данных, который подтверждает подлинность. Подтвержденная третья сторона, известная как центр сертификации (CA), генерирует сертификат и проверяет его подлинность. Чтобы получить сертификат сервер должен использовать безопасные каналы для отправки своего публичного ключа в центр сертификации. Он генерирует сертификат, который содержит его собственный ID, ID сервера, публичный ключ сервера и другую информацию. А также центр сертификации создает отпечаток (digest) сертификата, который, по сути, является контрольной суммой. Далее центр сертификации создает подпись сертификата (certificate signature), которая формируется путем шифрования отпечатка сертификата приватным ключом центра сертификации.
Для проверки сертификата сервера клиент использует публичный ключ центра сертификации для расшифровки подписи. Затем клиент самостоятельно считает отпечаток сертификата сервера и сверяет с расшифрованным. Если они не совпадают, то сертификат был подделан. Естественно, для расшифровки подписи у клиента должен быть публичный ключ центра авторизации. Поэтому клиент хранит у себя список публичных ключей подтвержденных центров сертификации. По факту, многие браузерные приложения имеют подобный список, находящийся непосредственно в их коде. Когда клиент установил подлинность сервера (сервер также может запросить сертификат у клиента), сервер использует шифрование открытым ключом для определения секретного ключа для обмена информацией.
Протокол SSL использует сертификаты для проверки соединения. Сертификаты расположены на безопасном сервере и используются для шифрования данных и идентификации Web-сайта.
Способы получения SSL-сертификата:
- Использовать сертификат, выданный центром сертификации (Certification authority)
- Использовать самоподписанный сертификат
- Использовать «пустой» сертификат
Самоподписанный сертификат — сертификат, созданный самим пользователем — в этом случае издатель сертификата совпадает с владельцем сертификата. «Пустой» сертификат — сертификат, содержащий фиктивную информацию, используемую в качестве временной для настройки SSL и проверки его функциональности в данной среде.
Существует два основных способа шифрования данных: симметричный ключ (общий секретный ключ) и асимметричный ключ (открытый ключ).
Суть асимметричного шифрования заключается в том, что используется пара ключей. Один из них используется в качестве открытого (как правило, он публикуется в самом сертификате владельца), второй ключ называется секретным — он держится в тайне и никогда никому не открывается. Оба ключа работают в паре: один используется для запуска противоположных функций другого ключа. Если открытый ключ используется для того, чтобы зашифровать данные, то расшифровать их можно только секретным ключом и наоборот. Такая взаимосвязь позволяет делать две важные вещи.
Любой пользователь может получить открытый ключ по назначению и использовать его для шифрования данных, расшифровать которые может только пользователь, владеющий секретным ключом. (RSA)
Если заголовок шифрует данные, используя свой секретный ключ, каждый может расшифровать данные, используя соответствующий открытый ключ. Именно это является основой для цифровых подписей. (DSA)
RSA — самый распространенный алгоритм шифрования с использованием асимметричных ключей.
Алгоритмы симметричного шифрования часто включают установленное число добавок и сдвигов. Такие алгоритмы часто используют ключ для помощи при битовых манипуляциях или для того, чтобы шифруемые данные стали более случайными. Другими словами, при увеличении размера секретного ключа может увеличиться случайность шифруемых данных, но не обязательно возрастет сложность вычислений при расшифровке. Однако, шифрование открытым ключом использует ключ как экспоненту, поэтому значительное увеличения ключа сильно увеличивает количество вычислений, требуемых для шифрования / дешифрования данных.
Таким образом хотя алгоритмы шифрования открытым ключом не сталкиваются с проблемой распределения, с которой сталкиваются алгоритмы шифрования секретным ключом, они требует значительно больше вычислительной мощности. Для использования сильных сторон обоих типов алгоритмов протоколы безопасности обычно используют шифрование открытым ключом для передачи секретных ключей. Как только секретный ключ доставлен начинается передача данных с использованием симметричного шифрования.
Существует еще один подход, использующий открытый ключ как соглашение, а не как способ доставки секретного ключа другим. Обе стороны обмениваются публичными ключами и независимо генерируют секретный ключ. Самой распространенной формой такого соглашения является протокол Диффи-Хеллмана. Хотя SSL поддерживает протокол Диффи-Хеллмана, большинство SSL транзакций не используют его. Вместо него используется алгоритм RSA, который решает проблему распределения секретных ключей.
SSL поддерживает 3 типа аутентификации:
- аутентификация обеих сторон (клиент — сервер),
- аутентификация сервера с неаутентифицированным клиентом,
- полная анонимность.
Обычно для аутентификации используются алгоритмы: RSA, DSA, ECDSA.
Если клиент имеет сертификат, содержащий параметры алгоритма Diffie-Hellman, то сертификат также содержит информацию, требующуюся для того, чтобы завершить обмен ключами. В этом случае клиент и сервер должны будут сгенерировать одинаковые Diffie-Hellman результаты (pre_master_secret) каждый раз, когда они устанавливают соединение. Для того, чтобы предотвратить хранение секрета (pre_master_secret) в памяти компьютера на время дольше, чем необходимо, секрет должен быть переведен в общий секрет (master_secret) настолько быстро, насколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами.
Создатели SSL знали, что алгоритмы шифрования открытым ключом вычислительно сложные, и клиент, создающий несколько новых соединений к одному и тому же серверу в течение короткого промежутка времени может сильно нагрузить сервер, что приведет к заметным временным задержкам ответа. Однако, если клиент и сервер уже установили соединение, то ему будет соответствовать уникальный идентификатор сессии, позволяющий ссылаться на него и использовать такой же секретный ключ при последующих соединениях в рамках некоторого временного отрезка. Безусловно, такой подход привносит определенный риск в безопасность соединения. Поэтому, если необходимо, клиент может пересоздать новые идентификатор и секретный ключ для данной сессии. Microsoft’s Internet Explorer, например, проделывают эту операцию каждые 2 минуты.
Если клиент планирует обратиться к серверу, который требует клиентской аутентификации, он должен хранить свой сертификат и связанный с ним приватный ключ. Сервер должен всегда хранить свой сертификат и связанный с ним приватный ключ.
Клиент и сервер обязаны хранить идентификаторы сессий и связанные с ними секретные ключи для использования во время восстановления соединения.
Версия 1.0 никогда не была обнародована. Версии 2.0 была выпущена в феврале 1995 года, но содержала много недостатков по безопасности, которые привели к разработке SSL 3.0 версии.
Как только различные компании (Microsoft) начали предпринимать попытки разработки собственных безопасных протоколов транспортировки, IETF решило вмешаться и определить стандарт протокола шифрования. Впоследствии, при поддержке множества компаний, на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS 1.0. Его также часто называют SSL 3.1.
Хотя TLS и SSL имеют существенные различия в реализации, разработчики обычно замечают лишь немногие из них, а конечные пользователи вовсе их не различают. Тем не менее TLS 1.0 и SSL 3.0 несовместимы. Значительное различие состоит в том, что TLS требует определенные алгоритмы шифрования, которые SSL не поддерживает. Таким образом TLS сервер должен “откатиться” (downgrade) до SSL 3.0 для работы с клиентами, использующими SSL 3.0.
Протокол TLS делится на два слоя: TLS Record и TLS Handshake.
После обработки протоколом TLS Record зашифрованные данные передаются на слой TCP для передачи.
Читайте также: