В протоколе WireGuard. В том то и дело, что нигде в нём не увидел HTTPS. В современных реалиях без возможности инкапсуляции протокола в HTTPS перспективы протокола сомнительны. Более интересным вариантом с этой точки зрения выглядит SoftetherVPN.
Думаю, именно на podman, если собираетесь остаться на RHEL-производных дистрибутивах. Например, у меня не получилось просто довести docker нас свежем RHEL8 из-за проблем с зависимостями и необходимостью настройки вручную сети для работы контейнеров.
Как я понял автора комментария: Использовать HTTPS протокол, видимый для DPI, который будет инкапсулировать уже протокол MTProxy. В таком случае нужен будет свой TLS сертификат для HTTPS трафика (Например, lets encrypt), на который государство может осуществлять бессмысленную MITM атаку с подменой сертификата, как в Казахстане. Бессмысленную — потому что внутри первого слоя будет уже MTProxy.
Хотя, думаю, популярностью он не шибко пользуется, учитывая наличие абонентской платы за его использование (сервер поддерживает XEP-0357, а за push-уведомленя надо платить...)
Если пользователь пользуется Conversations через сторонний сервер, то какие вообще данные могут быть у Даниэля? (крашлоги разве что)
Включаю режим теорий заговора: Если брать клиент из google play, то он может отличаться от собранного с исходников в github
Вряд ли, там же нужно платить за использование больше 1-ого месяца, а значит, и светить кредиткой/пэйпалом. Тогда скорее бы 404.city заблокировали, им вероятнее воспользуются различные личности.
Ну, вот и настал момент, когда они решили заняться децентрализованными сетями. Вангую, что скоро на ростелекоме начнутся «случайные»/«ошибочные» блокировки XMPP трафика.
Спасибо за пояснение! Действительно, до MITM атак под компании они вряд ли дойдут, но вот законодательно заставить внедрить корневой сертификат на устройства могут заставить, ведь заморачиваться с требованием сессионных ключей у каждого оператора ПД они тоже вряд ли начнут.
Спасибо, подправил комментарий, не знал, что уже в SSLv3 ввели эти протоколы. Тогда возможно Вы можете пояснить: насколько я понимаю, если у ФСБ будет возможность получить приватный ключ TLS сертификата, то они смогут получить всю цепочку генерируемых ключей, в том числе и долговременных ключей, что даст им возможность читать переписку/смотреть файлы/историю поиска и т.п.?
Шифрование в вебе (до SSL v3) осуществляется с помощью асимметричной криптографии, когда у клиента есть
сертификат удостоверяющего центра, (он проверяет подпись у открытой части пары, отправляемой сервером), который зашит в ОС или браузер,
а также у провайдера (в нашем случае Яндекса) есть приватный ключ, который и нужен ФСБ,
так как после его получения можно будет перехватить момент обмена ключа симметричного шифрования (сеансового), которое уже используется за счёт более быстрого процесса шифрования данных и меньшего их объёма, что критично при передаче по сети
Softether на Android/iOS можно в режиме SFTP/OpenVPN ещё использовать.
Думаю, именно на podman, если собираетесь остаться на RHEL-производных дистрибутивах. Например, у меня не получилось просто довести docker нас свежем RHEL8 из-за проблем с зависимостями и необходимостью настройки вручную сети для работы контейнеров.
Включаю режим теорий заговора: Если брать клиент из google play, то он может отличаться от собранного с исходников в github
По-моему, прекрасно всё понятно.
- сертификат удостоверяющего центра, (он проверяет подпись у открытой части пары, отправляемой сервером), который зашит в ОС или браузер,
- а также у провайдера (в нашем случае Яндекса) есть приватный ключ, который и нужен ФСБ,
так как после его получения можно будет перехватить момент обмена ключа симметричного шифрования (сеансового), которое уже используется за счёт более быстрого процесса шифрования данных и меньшего их объёма, что критично при передаче по сетиТолько в ней смысла не будет, так как она не будет чирикать с самого начала. Даже до своего появления ей чирикать смысла не было.
Risc-V?
Живёте и покупаете в России?