LINUX.ORG.RU

Можно ли прослушать https(TLSv1.3) трафик ? какие есть варианты 100% защищенности https соединения?

 


0

1

Почитал пару дней про шифрование, сертификаты и все такое и даже поднял TLSv1.3 на nginx ))
Но нарвался на статьи где wireshark ом могут прослушать передаваемый трафик
И стало стремновато, везде пишут что TLSv1.3 круто, но насколько реально его использование супер надежно (невозможно расшифровать передаваемый трафик) не нашел статей

буду признателен если есть ссылки и схемы настройки для защиты https трафика.

кто знает что реально или не реально прослушать трафик шифруемый с использованием TLSv1.3 ?

планируемые клиенты - это браузеры мобильных телефонов и компов.

PS
сделал wiresark ом дамп обмена трафиком на сервер и увидел что в дампе внутри TLSv1.3 данных передаются данные TLSv1.2 который как бы вообще менее надежный.

★★★★

Прослушать трафик передаваемый с использованием корректной реализации TLSv1.3 на текущем оборудовании не реально. Ключевое слово тут корректная.

Однако, теоретически, через 5-6 лет этот трафик можно будет расшифровать с использованием квантового компьютера.

faq2
()
Ответ на: комментарий от faq2

через 5-6 лет этот трафик можно будет расшифровать с использованием квантового компьютера

Я где-то это уже слышал, 8 лет назад.

vvn_black ★★★★★
()

Прости, но что за бред я прочитал?

Читай свои статьи еще раз, до наступления понимания. Пока это можно только под снос за 4.2.

t184256 ★★★★★
()
Ответ на: комментарий от faq2

Из трёх возможных оставляете только:

TLS_AES_256_GCM_SHA384 TLSv1.3

И теоретическое время планируемой расшифровки ещё лет так на 10 от предполагаемого Вами срока сдвинется.

А за 15 лет всё ещё 10 раз поменяют :)

suffix ★★
()

Но нарвался на статьи где wireshark ом могут прослушать передаваемый трафик

Наверное при этом wireshark-у надо явно ключи указать для расшифровки

Harald ★★★★★
()
Ответ на: комментарий от Vlad-76

Обида за правила форума. Редчайший ресурс, где гнать пургу запрещено правилами — а тут такое.

t184256 ★★★★★
()

еще вопрос, насколько самоподписной сертификат на сервере - ненадежное решение? я так понимаю что самоподписной сертификат можно каким то образом подменить и этого клиент не увидит?

Vlad-76 ★★★★
() автор топика
Ответ на: комментарий от vvn_black

разве CA (центр сертификации) не нужен для проверки сертификата с сервера в т.ч. чтобы обнаружить его подмену в пути?

Vlad-76 ★★★★
() автор топика
Ответ на: комментарий от Vlad-76

Сертификат, любой, подразумевает, что его кто-то выдал, подписал. В случае самоподписанного, ты сам себе CA.

vvn_black ★★★★★
()

извини, а где написано как расшифровать TLSv1.2? Только чтобы не за тысячу лет, а вот быстро?

v9lij ★★★★★
()
Ответ на: комментарий от anonymous

Или если проверяет, но CA подменного сертификата внесён в доверенные.

Т.е. есть у тебя сайт example.org с сетификатом для example.org. По умолчанию, браузер смотрит на сертификат, смотрит какой CA его выдал, проверяет подписи/фингерпринты и считает соединение защищённым.

Но если в барузере в качестве доверенного добавлен некий CA1, между браузером и сайтом есть некий сервер, который видя, что идёт запрос к example.org, подставляет свой сертификат для него, заверенный CA1, браузер такое соединение тоже считает валидным. При этом промежуточный сервер держит два шифрованных соединения. Браузер <-> server, server <-> example.org, а любы запросы/ответы просто проксирует между ними.

Но это уже не дырка в TLS, а MiTM.

shell-script ★★★★★
()
Последнее исправление: shell-script (всего исправлений: 1)
Ответ на: комментарий от Vlad-76

Например, что узлы клиента и сервера считаются доверенными.

faq2
()
Ответ на: комментарий от suffix

А сейчас уже меняют, в NIST готовят принципиально новые алгоритмы, на другой математике. Думаю следующий TLS будет на них.

faq2
()
Ответ на: комментарий от shell-script

Да, если есть контроль над узлом клиента, то всё выглядит сильно просто. Да даже если не подменить CA - можно прочитать из памяти :)

faq2
()
Ответ на: комментарий от goingUp

На разминку можно вот-это и референсы. Когда 1000кубитные компы(для ECDH некоторых курвов как будто нужно 2048 + константа кубит) будут не адиабатические конечно сложно предсказать, но сейчас как-будто даже некое подобие закона мура прослеживается по развитию, только шаг 2 года.

faq2
()

сделал wiresark ом дамп обмена трафиком на сервер и увидел что в дампе внутри TLSv1.3 данных передаются данные TLSv1.2 который как бы вообще менее надежный.

У тебя слегка каша в голове, данные передаются в формате TLS 1.3, просто отличить их от данных в формате TLS 1.2 не зная изначально, что сессия была TLS 1.3 невозможно, а диссектор в вайршарке стейтлесс, как минимум если не включать пересборку TCP потока.

faq2
()
Ответ на: комментарий от faq2

сегодня вот читаю и перечитываю повторно ссылки, полегче стало, что то даже откладывается и проясняется

PS
хочется ведь всегда быстрее, но мозг работает в своем режиме

Vlad-76 ★★★★
() автор топика
Ответ на: комментарий от Vlad-76

В общем если ты используешь корректные сертификаты, у тебя настроен отзыв сертификатов и на узлах клиента и сервера нет злоумышленника с правами суперпользователя, данные можно передавать смело - здесь и сейчас никто не прочитает. Если не брать в расчёт квантовую угрозу, но это скорее отдельная проблема, которая сам по-себе протокол TLS никак не затрагивает, только криптографические алгоритмы которые принято использовать в текущей версии.

faq2
()
Ответ на: комментарий от goingUp

Типа того, да. Но очень много людей трудятся чтобы стало можно, не ради того чтобы взломать крипту, а просто там куча других интересных задачек начинает решаться которые сейчас по 10к лет на всё оборудовании планеты считаются с нужной размерностью :)

faq2
()
Ответ на: комментарий от faq2

В статьях описывающих алгоритм Шора и его реализациях :)

Только как это поможет с симметричными алгоритмами?

vvn_black ★★★★★
()
Ответ на: комментарий от faq2

Ну эта цифра плавает, но 8 лет назад не было рабочих прототипов так-то.

А 30 лет назад? Этой истории с квантовыми алгоритмами лет много, но, кмк, потребности в них немного.

vvn_black ★★★★★
()
Ответ на: комментарий от vvn_black

И 30 лет назад не было прототипов. Но 30 лет назад и RSA был ракетной наукой так-то :)

faq2
()
Последнее исправление: faq2 (всего исправлений: 1)
Ответ на: комментарий от vvn_black

А что не так с симметричными алгоритмами? Зачем им помогать?

Ты ругаешься как будто, в теме, но про факт, что для симметричных алгоритмов можно просто повысить размер ключа в два раза и всё будет Ок не в курсе:)

faq2
()
Последнее исправление: faq2 (всего исправлений: 1)
Ответ на: комментарий от vvn_black

BTW про атаки на симметричные алгоритмы смотри алгоритм Гровера(он вроде не единственный, но концептуально там как будто мало кто чего выдумал нового).

faq2
()
Ответ на: комментарий от v9lij

Кстати, говорить о расшифровать TLSv1.2 не совсем корректно, TLS это протокол, а шифрование происходит симметричным блочным шифром. Другое дело, что в рамках этого протокола передаются открытые части ключей на основе которых формируется общий между узлами обмена данными секретный ключ, который уже используется симметричным блочным шифром(упрощённо, на самом деле задействован ещё KDF и ряд других механизмов, поэтому напрямую распределённый ключ не используется).

Т.е. правильней будет сказать, что на протокол или его реализации могут быть проведены атаки позволяющие заполучить секретную часть ключа. Атаки на протокол понятно, что страшнее, чем на реализации.

faq2
()
Ответ на: комментарий от faq2

А что не так с симметричными алгоритмами? Зачем им помогать?

для симметричных алгоритмов можно просто повысить размер ключа в два раза и всё будет Ок

Спросил и сам ответил, как тебе квантовые алгоритмы расшифруют трафик через 5-6 лет, если они бесполезны против AES?

Т.е. правильней будет сказать, что на протокол или его реализации могут быть проведены атаки позволяющие заполучить секретную часть ключа.

Воооот, ну наконец-то!

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 2)
Ответ на: комментарий от suffix

Хм, а NamedGroup какой ставить чтобы ещё на 10 лет?(спойлер в стандарте TLS 1.3 таких нет).

Толку от блочного шифра, если есть возможность восстановить ключ шифрования?

faq2
()
Ответ на: комментарий от vvn_black

Разговор про TLS.

В TLS блочный шифр работает с ключом распределённым по ассиметричной схеме либо с PSK. В случае PSK - всё Ок. Верь курьерам, или таскай с собой токен, или используй TEE - да, всё будет хорошо. Но большинство современных систем передачи данных устроенно по-другому :)

faq2
()
Ответ на: комментарий от faq2

The same principles apply: a web browser would only ever use PSK as a way to resume a session that was started with asymmetric cryptography.

Вроде так и есть.

А глобально, PSK немного для других вещей, типа авторизации. Как вы представляете обмен ключами в веб?

vvn_black ★★★★★
()

Почитал пару дней про шифрование

И всё равно ничего не понял.

WitcherGeralt ★★
()
Ответ на: комментарий от vvn_black

Проблема либо с формулировкой либо с лёгкой кашицей в голове. Распределение ключей и PSK это отличные и никак не связанные напрямую механизмы.

PSK это режим рукопожатия TLS подразумевающий что ключи уже есть на обоих узлах и никак не регламентирующий их доставку до конечного устройства.

Распределение ключей (KEX) это криптографическая схема выработки одинакового секрета в условиях незащищённого соединения.

faq2
()
Ответ на: комментарий от t184256

Прости, но что за бред я прочитал?
Читай свои статьи еще раз, до наступления понимания. Пока это можно только под снос за 4.2.

Придурок, самозабанься!

anonymous
()
Ответ на: комментарий от faq2

Распределение ключей и PSK это отличные и никак не связанные напрямую механизмы.

Так это вы предлагаете их использовать в веб или нет? Как вы предлагаете их использовать, не вдаваясь в дистрибьюцию?

vvn_black ★★★★★
()
Последнее исправление: vvn_black (всего исправлений: 1)

прослушать можно, но браузер шухер поднимет что слушают, я на работе установил открытый wi-fi и стал внаглую шмонать http+https по шаблону логин\пароль при помощи ettercap или bettercap

# bettercap -T --proxy --proxy-https -P POST
ettercap -T -V text -P autoadd -qSM arp:remote /// ///

арендаторов дофига и полно всякого народу шарится - желающих воспользоваться открытой точкой доступа придостаточно, но браузер и другие интеренет программы ругаются на небезопасное соединение, кто то шугается и дальше не лезит, а кому то пофиг - жмет продолжить все равно и погнали, наловил всякого и от вконтакта и от фейсбука и от майлру и от яндекса… что относительно программ для шмона то bettorcap мне больше понравился, но сейчас его так переделали, что он в какой то отстой превратился и вообще нифига не шмонает или я не догоняю чего то, так что остается ettercap - он не так крут как bettercap, но дело свое знает…

anonymous
()
Ответ на: комментарий от vvn_black

Я просто пытаюсь подвести к простому факту - в TLS который используется в web используются механизмы распределения ключей, но не используется PSK. Следовательно большую часть https трафика, который в свою очередь представляет не менее половины всего tls трафика, можно расшифровать с использованием алгоритма Шора.

Широкое использование TLS PSK в веб могло бы серьёзно повлиять на это соотношение, особенно если опустить вопросы дистрибьюции ключей. В таком режиме можно было бы использовать statefull kdf и симметричный ключ пары ресурс:устройство. Вопрос дистрибьюции ключей и иеррархии подобной PKI но свободной от паразитов типа УЦ представить тоже не очень сложно.

faq2
()
Ответ на: комментарий от faq2

Вопрос дистрибьюции ключей и иеррархии подобной PKI но свободной от паразитов типа УЦ представить тоже не очень сложно.

Звучит как идея на миллион для единорога.

vvn_black ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.