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

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

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

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

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

что Вы подразумеваете под корректной реализацией?

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

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

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

TLS_AES_256_GCM_SHA384 TLSv1.3

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

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

ЭГО зашкаливает?

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

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

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

мерси

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

С точностью до наоборот.

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

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

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

Подменить можно, если клиентский софт не проверяет, что это именно твой сертификат.

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

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

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

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

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

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

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

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

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

Ну давайте уже ссылку на свои статьи, или боитесь, что развенчают?

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

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

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

«У тебя слегка каша в голове» )) да не слегка

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

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

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

А, ну так-то конечно можно, но пока нельзя (с) :)

Сложно поспорить :)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот ещё интересно, умеет ли кстати хоть один браузер в HTTPS с PSK?:)

Огнелис походу не умеет, х3 насколько актуальная инфа:

https://wiki.mozilla.org/Security/Cipher_Suites

Вроде чела никто не поругал, и в этих наших вебах PSK не юзают.

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 немного для других вещей, типа авторизации. Как вы представляете обмен ключами в веб?

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

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

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

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

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

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

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

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

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

прослушать можно, но браузер шухер поднимет что слушают, я на работе установил открытый 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, но дело свое знает…

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

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

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

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