Saboteur

HTTPS = HTTP + TLS, между клиентом(браузером пользователя) и удаленным сервером(сайтом) строится TLS туннель на основе публичных ключей, далее идет обмен приватных симметричных ключей и затем https сессия шифруется уже симметрично.

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

В HTTPS условно невозможны атаки типа MITM

То есть? MITM зависит не от HTTPS, а от того, доверяете ли вы серверу. Условно тут могут и сертификат украсть и днс подшаманить и вам в доверенные сертификаты подсунуть нужный, что обычно делается в корпорациях (и это можно увидеть).

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

HTTPS обеспечивает шифрованный канал между сервером и клиентом. Все. Он не гарантирует, что вы подключились к неправильному серверу, он старается гарантировать, что зашифрованные данные не могут быть расшифрованы третьей стороной.

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

Потому что ломают не только HTTPS, есть множество точек уязвимости.

Даже учитывая то что https обеспечивает передачу данных по шифрованному каналу, мы в любом случае чувствуем себя небезопасно и неаноимно выходя в интернет напрямую через нашего провайдера.

Шифрование не дает анонимности. Ваш IP адрес видит и провайдер и удаленный сервер.

Скажите, правильно ли я понимаю, что провайдер и все промежуточные узлы видят только IP адрес на уровне L3 (и мак на уровне L2), а сами данные L4 на сеансовых и следующих уровнях для них зашифровано и недоступно? (из-за шифрования HTTPS) Т.е. в худшем случае мы можем только засветить свой белый айпишник, который привязан к географическому положению (и также хранится на логах сессий в маршрутизаторе у провайдера), но сами данные никто увидеть не сможет?

Почти так. Но кое-какие данные идут не только по HTTPS. Есть DNS реквесты, есть пару HTTP реквесты которые идут во время рукопожатия HTTPS.

И если это так, то то же замедление ютуба или недавнего Дискорда- DPI (Deep Packet Insepction почему-то именно слово "Deep" настораживает.) - Как система может определять тип пакетов/траффика и исходя из этого делать уже какие-то выводы/принимать действия?

Ну тут банально - куда ты подключаешься - к серверам гугла? Значит тормозим.

Там всё же вводятся ограничения на уровне ip-адреса ресурса или же эти системы умеют копать глубже, на уровне приложений? В таком случае как тогда это стыкуется с безопасностью и шифрованием данных в HTTPS, если DPI может блочить по контенту?

Шифрованный VPN Трафик отличается от шифрованного HTTPS трафика. VPN тоже разными технологиями делается. Трафик условного звонка по телеграмму отличается от HTTPS траффика. То есть можно анализировать тип трафика. Естественно содержимое страничек DPI не видит (если не включает в себя MITM). Незашифрованный траффик DPI может по заголовкам фильтровать очень гибко.

Я знаю что есть локальные фаерволы NGFN которые могут блокировать ресурсы из локальной сети по содержимому страниц...Но впрочем для корпоративной сети это наверное нормально...

В основном потому что корпоративный MITM

NoNameUser01,

все же хотелось получить ответ на вопрос именно от вас, ибо в Гугле много шлака сейчас по первой выдаче :)

Пока не научишься среди шлака находить нужные вещи, у тебя все время будет проблема. Ибо на ЛЮБОМ уровне знаний, самое первое что нужно уметь - это искать и находить нужную в данный момент информацию.
Она далеко не всегда есть в том виде, в каком тебе кажется или хочется. Нужно привыкнуть к тому, в каком виде могут быть полезные ответы, в каком лежит различная документация, датащиты, рфц, и приучиться их читать и искать по ним. Не отмахиваться от ответов, которые, как тебе кажутся, не совсем по теме. Возможно они гораздо глубже чем кажется на первый раз

Пользуйся современными инструментами - на уровне новичка на 90% базовых вопросов может ответить чатгпт, или поиск по уже готовым вопросам/ответам. Особенно если применять английский.

Нет секретного ингредиента, который тебя сразу направит на единственный правильный путь.
Становление специалистом это не просто прочтение пары книг, иначе любой бы мог стать поэтом/писателем/программистом/физиком.
Это воспитание в себе нужных привычек в процессе получения знаний. Поэтому примерный роадмап есть, примерно по нему иди. Через 10000 часов непосредственного занятия по направлению, будешь лучше понимать куда копать дальше. И сам же себе ответишь, почему так сложно ответить новичку на вопрос как у тебя.

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

Уязвимость номер раз, требуется квалифицированный пользователь, который понимает как и что он настраивает и может оценить риски.

Мессенджер использует симметричное шифрование, а ключи передаются между пользователями в оффлайн-формате.

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

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

Как проверяется, что сервер не дешифрует сообщение?

Притом, на сервере хранится только последнее сообщение каждого пользователя(история не сохраняется)

В каком виде? Дешифрованном или шифрованном? Какова вероятность компроментации сервера?

Ну и что за шифрование используется, насколько легко оно сейчас ломается, и как часто меняются ключи, учитывая сложность обновления ключей....

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

Ну и вообще, такой мессенджер скорее всего бесполезен. Если пользователи настолько опытные, что могут арендовать и настроить виртуальную машину, поставить и настроить там сервер, подключить к нему клиент, обменяться ключами, то в чем проблема ПРОСТО установить сервер, подключиться любым ссш клиентом и уже на самом сервере пообщаться в talk/write ?

liiliiilliliiiliiiilllill,

То, что я описал в вопросе, можно решить чисто технически, а полиция чаще оперирует человеческой психологией

Почему вы вдруг так считаете, что это технический вопрос?

Это вообще не технический.
Это как раз вопрос политический и организационный.

Вы можете хотя бы представить усилия, которые нужны, чтобы проверить ВЕСЬ КОД в мире?
Весь код какой-либо операционной системы или популярного софта?

Сколько для этого нужно специалистов?
Сколько для этого нужно времени?
Сколько для этого нужно денег?

А кто сможет гарантировать, что эти специалисты будут достаточно квалифицированы?
Что они не будут подкуплены?

В мире огромное количество аудиторских компаний и продуктов, которые выполняют различные проверки на уязвимость. И как-то все равно уязвимости иногда находятся случайно спустя десятки аудитов и десятки лет. А что-то может быть и не находится.

Я глянул решения - HashiCorp Vault, Azure Key Vault, Doppler, Dotenv Vault - все они key-value без возможности скачать свой .env-файл. Dotenv Vault подошел бы, но он не работает с Docker, только с бекендом внутри контейнера. А это неприемлемо, бекенды внутри контейнеров я не контролирую вообще, image не мои.

А в чем проблема положить конфигурационный файл в value?
Так многие делают. Просто клади их как base64 строку.

в VeraCrypt в свое время были выявлены критические уязвимости, что говорит о соответствующем уровне разработчиков.

И какой же?
Вы как бы должны понимать, что софт непростой, и написать его вообще без уязвимостей, надо быть боженькой, что невозможно.
Veracrypt - форк от Truecrypt, в котором уже точно были найдены определенные уязвимости, и в веракрипт они были исправлены.

Соответствующие аудити выявляли возможные уязвимости, которые были исправлены. Последний публичный аудит был еще в 2020 году.
Хотите провести аудит - исходники открыты, аудитируйте.

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

То есть найти уязвимость или даже если есть открытые issue, это далеко не тоже самое, что иметь возможность легко расшифровать зашифрованный том. Уязвимость может лежать в других моментах. Например драйвер веракрипт, который как и все драйвера, внедряются на уровень ядра ОС, может позволить выполнить несанкционированные действия. Но к шифрованию это никакого отношения не имеет.
Например https://www.cvedetails.com/cve/CVE-2015-7358/

tcpview из sysinternals попробуй.

Конечно можно.
Задача разработчика ресурса такие запросы не обрабатывать. Возможно блокировать. И всегда быть готовым, что кто-то пришлет непредусмотренный системой запрос.

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

Так а откуда берутся все эти "ботсети"?
Это как раз зараженные устройства. Вебкамеры, розетки, роутеры, смартТВ - все что подключено к сети, особенно напрямую смотрит в инет.
Для организации DDOS нужна не мощная машина а много-много маленьких устройств, которые могут вполне легально пинговать. ПРосто когда это делает десяток тысяч устройств - это проблема.

Глупая идея.
Ну заблочите всех таких, будут у вас регистрироваться Вася Пупкин и Иван Иванов. Что изменится то?
Если нужны РЕАЛЬНЫЕ имена - интегрируйтесь с какими-нить госуслугами.
Если у вас просто хотелочка, а пользователи не хотят - подавайте на них в суд, или как вы их заставите, если у вас нет полномочий?

суперпользователь в линуксе один, это тот у которого UID=0

то есть ваши два суперпользователя не имеют суперюзерских прав. они видимо просто имеют доступ к sudo чтобы стать рутом.
А рут может просто выполнить su и стать другим юзером даже без пароля.

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

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

Найти уязвимость устройства - это не подобрать пароль, = это поиск способа подбирать пароль к устройству такого типа.
А подобрать пароль к этому устройству - это называется взлом этого конкретного устройства.

Например если вы сможете доказать, что перебор пароля на данном устройстве возможен с определенной скоростью, и эта скорость позволяет перебрать за разумное время (час/день), например пароли длиной 8 символов.
Тогда можно будет сказать, что пароли длиной до 8 символов - уязвимы.

Или сможете найти заводской пароль, который захардкожен прямо в эту прошивку, тогда это тоже уязвимость.

Следует почитать что вообще такое IP и как ты его получаешь от твоего провайдера.
Нельзя просто так взять и поменять внешний IP какой-то программой.

Пентестер в первую очередь программист, потом сисадмин и уже только потом тестер.
Он ищет уязвимости операционных систем, протоколов и инструментов. Для того, чтобы тестить вещи на этих уровнях, часто нужно писать много своего кода. Да и вообще не имея хороших навыков программирования ты не поймешь что ты вообще ищешь и проверяешь.
Не путай пентестера и тестировщика (QA)