zed420

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

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

Владелец веб сервера (в т.ч. хостер VPS) так же при желании, способен получить доступ и к расшифрованному трафику, и к данным на диске и оперативной памяти, даже если это kvm/vmware виртуализация, даже если ты запускаешь полностью свою ОС со своим ядром... гипервизор все видит (на аппаратном уровне у intel и amd уже давно есть инструменты для защиты от некоторых атак, но вы уверены что они активированы в гипервизоре вашего хостера?).

Разработчики программного обеспечения, запущенного на клиенте, при желании могут получить доступ к вашим данным (и это эксплуатируется, за той же майкрософт с самого старта телеметрии замечали и хранение и передачи всех нажатых клавиш, и отправку данных с видеокамеры и прочее прочее). Открытый софт? да, один из аргументов его появления был именно этот момент, но помним, что софт то ты открыл, а вот драйвера... напомнить что производитель материнской платы через efi биос имеет полный доступ к всему что у тебя в ОС происходит. И это я еще молчу про бэкдоры и не закрытые ошибки в легитимном и защищенном софте...

И на засыпку, производители оборудования, начиная с клавиатуры с мышкой (точнее любой usb), и заканчивая любой pci-e переферией, имеют доступ к данным, с разной степенью полноты, например usb мышка способна подслушивать нажатия клавиш на клавиатуре, подключенной к тому же контроллеру, обычно на материнской плате порты от одного контроллера размещены парами или по 4, а вот pci-e устройства имеют полный доступ даже к оперативной памяти (под вопросом многоядерные сервера, там кажется доступ разделен на группы по физическим процессорам).

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

1. Кроме утечек посередине данные могут утекать и со стороны браузера и со стороны сервиса.
2. mitm вполне себе возможен при помощи подставного сертификата. С введением сертификатов минцифры на уровне браузера - это уже не выглядит как что-то невозможное.

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

Да, но как уже выше написал - если ты сделаешь что-то нелегальное на площадке, которая сотрудничает с госорганами (а это не только лишь отечественные сервисы), то все твои данные по одному запросу передадут куда следует.

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

Это уже надо читать, как работают те самые DPI. Кроме ip есть ещё куча других эвристик, по которым можно определить, что за трафик идёт. Для большинства блокировок/замедлений достаточно ip.

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

dpi не может блочить по контенту, иначе бы мы видели блокировки отдельных страниц с запрещённым контентом.

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

В корпоративной сети работает п2

Все описано в этой статье

1.

Как я понимаю в первых двух строчках 0.0.0.0 это два шлюза по умолчанию а маска 128 делит всю wan сеть пополам?

Да, почти. Строго говоря, 0.0.0.0/128.0.0.0 не считается "по умолчанию". Только маршрут с маской 0.0.0.0 - настоящий "по умолчанию". Но для простоты можно не придираться и сказать так.

И пакеты летят то на первый интерфейс, то на другой?

Да, в зависимости от адреса назначения. Что в общем случае неправильно (иногда бывает, что именно так задумано, но это не ваш случай). Исправьте на 0.0.0.0.
2.

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

Да, та самая команда route, через которую (route print) вы показали маршруты.
route /? выводит подсказку, там внизу есть примеры:
route add для добавления маршрута,
route delete для удаления маршрута,
route change для изменения.
Можно не добавляя и не удаляя только менять метрику. Когда есть два (и больше) маршрута с одинаковым адресом назначения и одинаковой маской, то работает маршрут с меньшей метрикой. В вашем примере метрика не срабатывала из-за разной маски. Маршрут с узкой маской имеет приоритет перед маршрутом с широкой маской, независимо от метрики (в вашем случае с маской 128.0.0.0 маршрут был бы приоритетнее, даже имея метрику 26).