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

«корректные сертификаты»
что значит корректные? ПОкупные? или самоподписные?

«у тебя настроен отзыв сертификатов»

это как то должно настраиваться в nginx?

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

Представить - не сложно, а вот на практике реализовать - серьёзная научная работа, да ещё и с возможностью получения вывода, что всё же низзя :)

что значит корректные? ПОкупные? или самоподписные?

Это значит те, которые подписаны секретным ключом который достаточно трудно стырить злоумышленнику :) А так же те, секретный ключ от которых тоже достаточно сложно стырить злоумышленнику. Но я думаю тебя сугубо прикладные цели интересуют, поэтому рекомендую использовать сертификат подписанный надёжным издателем (есть бесплатные штуки типа let’s encrypt, но там придётся немного поплясать с автоматизацией).

это как то должно настраиваться в nginx?

В сертификате прописываются адреса где нужно читать списки отозванных сертификатов(CRL) и адреса серверов статуса сертификатов работающих по протоколу OCSP. По любому TLS решению всегда можно погуглить какие из этих технологий оно поддерживает и в каком объёме.

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

Это вопрос модели безопасности. Если в твоей модели безопасности, утечка данных взломанного клиента это Ок, то и пофик.

Тут ведь как - вопрос какого уровня гарантии ты хочешь дать. Насколько я знаю, есть модели безопасности в которых решение продолжает обеспечивать сохранность критичных данных в условиях скомпрометированной ОС и скомпрометированного ПО. Ключевая оговорка тут всегда - на протяжении какого времени. Например для расшифровки AES трафика тоже ведь есть время и требования по оборудованию, просто эти сотни тысяч лет - выглядят вполне приемлемо для бизнеса :)

как я понимаю Вы говорите про установку сертов на web клиентах? Тут такое дело, чтобы с клиентами (с их настройкой) не было особых заморочек.
предполагается что будет использоваться firefox на смартфоне и компе. Как на них настраиваются сертификаты я пока без понятия, возможно ли такое - не гуглил.
для меня важно чтобы не расшифровали, обмен данными клиент-сервер посередине, а не на конечных хостах!!! Если уж клиент будет физически захвачен, то тут как говориться, приплыли сливай воду.

Такое же как и на стороне. Только предупреждение в браузере будет.

не понял про такое же как и на стороне

Я имею ввиду взять у регистраторов или как их там. Которые выдают сертификаты.

Аутентификация клиента используется в основном для авторизации доступа к серверу. Для защиты от mitm достаточно только аутентификации сервера.

Можно, если сделать MitM.

«Для защиты от mitm достаточно только аутентификации сервера.»
Для этого нужно на сервере установить сертификат от CA (чтобы у кого было спросить про подлинность серта от сревера) как я понимаю? Самоподписной не годиться?

на сервере установить сертификат от CA

На клиенте.

Самоподписной не годиться?

Самоподписанный сертификат ничем не отличается от купленного, подаренного или выданного летсенкрипт. Разница в способе проверки цепочки доверия, что в каких-то случаях плюс, в каких-то минус. Самоподписанный придётся проверять клиенту самостоятельно.

в каком месте устанавливается сертификат сервера для его проверки клиентом firefox мобильного телефона?

Ну и да, про атаки на ослабление крипты уже говорили?

И отсутствие доверия к сертификату прокси.

Для этого нужно на сервере установить сертификат от CA (чтобы у кого было спросить про подлинность серта от сревера) как я понимаю? Самоподписной не годиться?

tl;dr - да.

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

Сразу несколько вопросов:

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

firefox

https://support.mozilla.org

клиентом … мобильного телефона

В общем случае, это пользовательское хранилище сертификатов, браузеру надо разрешить им пользоваться. Beta файрфокса для android это умеет, а может уже и релиз тоже.

Посмотрите в андроиде пункт пользовательские сертификаты.

Не понял если честно. Если прокси делает mitm он должен клиенту представиться валидным сертификатом сервера, если прокси туннелирует нижележащий протокол как-то ещё, то вопрос взаимоотношения клиента и и прокси лежит в отдельной плоскости, если о5 же не брать в расчёт квантовые компы.

а где написано как расшифровать TLSv1.2?

Для RSA key exchange здесь написано: https://arxiv.org/pdf/1905.09749.pdf

Они оценивают время до появления подходящих квантовых компьютеров в 25 лет.

Если прокси делает mitm он должен клиенту представиться валидным сертификатом сервера

В сертификате указано, кому он выдан, включая доменное имя хоста. Если сертификат, выданный linux.org.ru придет с хоста mitm.hkr.nsa - твой браузер заругается.

Поэтому, если прокси не делает sslstrip (когда прокси перенаправляет тебя на http, а сам строит https до хоста), то прокси отдает тебе свой сертификат, и приземляет https на себя, и строит уже новую https-сессию до целевого хоста. Но, что бы твой браузер не начал опять ругаться на то, что ему какую-то гадость пихают, у прокси должен быть валидный сертификат, которому доверяет твой браузер.

Не слышал, что бы прокси проксировал https трафик.

А, ты про https прокси. Ну так это вопрос доверия прокси-серверу. Это уже проблемы протокола https а не tls - не используйте https прокси, которым не готовы раскрыть все ваши данные as-is :)

И отсутствие доверия к сертификату прокси.

До меня дошло значение исходного тут утверждения, я почему-то думал, что оно относится к тому, для чего нужна аутентификация клиента, тупнячок.

Прослушать нельзя. Его использование супер-надёжно (невозможно расшифровать передаваемый трафик). TLSv1.2 не менее надёжный.

еще вопрос, насколько самоподписной сертификат на сервере - ненадежное решение?

В этом нет смысла. Пользуйся letsencrypt.

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

Клиент увидит. Но как он отличит самоподписанный сертификат Влада от самоподписанного сертификата Васяна? Если он до этого видел самоподписанный сертификат Влада и добавил его себе в доверенные, то надёжность будет абсолютной. А если он его до этого не видел и не может/не хочет позвонить Владу и уточнить, тот ли это сертификат, тогда надёжность нулевая.

«корректные сертификаты»

что значит корректные? ПОкупные? или самоподписные?

Корректные это значит те, которым доверяют браузеры твоих клиентов. Можно покупать, если деньги девать некуда. Нормальные люди используют бесплатный letencrypt.

«у тебя настроен отзыв сертификатов»

это как то должно настраиваться в nginx?

Вообще да, OCSP Stapling. Но браузеры обычно игнорируют этот аспект, поэтому особо можешь не заморачиваться, хотя для порядку надо.

Вообще настройки своего сервера удобно проверять на SSL Labs. Если там A+, значит всё нормально.

звучит ну прям очень опасно, конечно.

посмотреть можно, впихнуть в этот список свой открытый .cer никак не получается :(
такое чувство что для безопастности пользователя ему связывают руки.

Погугли ssl inspection. Вроде, даже squid умеет.

Погугли ssl inspection.

Ну для этого у инспектора должен быть сертификат, которому доверяет клиент. А это уже как бы не совсем прокси, которое от слова «здоровый» :)

А это уже как бы не совсем прокси, которое от слова «здоровый» :)

Чойта? SSL-инспекция на предмет малваре и unacceptable behavior - это вполне себе здоровое использование.

от слова «здоровый»

:)

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

Что мешает на основе своего самоподписанного сертификата сделать dane TLSA запись при условии что домен под dnssec ?

Тогда валидность сертификата легко проверяется.

Кстати, возвращаясь ко второй части вопроса:

какие есть варианты 100% защищенности https соединения?

Это конечно тоже не 100% но довольно приближенное к ней состояние - использовать ключ генерированный системами qkd в качестве psk ключей для TLS или других протоколов шифрования трафика. При таком подходе mitm исключают текущие законы физики по идее, т.е. для атаки нужно как минимум ряд теорий квантовой физики опровергнуть:)

Может, если подменят сертификаты ssl.