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

Question

[zed420]

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

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

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

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

Comments

[Василий Банников]

ну тут надо звать ValdikSS

[aleks-th]

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

Answer 1

[mainheader]

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

Answer 2

[rPman]

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

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

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

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

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

Comments

[Lynn «Кофеман»]

> Хочу напомнить, удостоверяющий центр, выдавший сертификат, способен полностью расшифровать и даже подделать ваш трафик

Это как?

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

Но никак не «способен полностью расшифровать» именно ваш трафик.

[rPman]

Lynn «Кофеман», если приватный ключ для шифрования был взят у удостоверяющего центра (это не обязательно, но почитайте гайды, все его берут у CA)

[AlexVWill]

rPman, пресловутый certbot, насколько я помню, приватный ключ генерит локально (да и иначе быть не должно, ключи передавать запрещено), а вот сертификат, подписанный ключом, получает с сервера. У других CA примерно та же история, как я понимаю.

[shurshur]

Все приличные CA позволяют заслать им CSR а не генерят ключ.

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

Тут риск скорее в том, что CA может сгенерить новый серт и начать изображать из себя тот же самый сайт, не являсь им.

Answer 3

[Василий Банников]

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

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

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

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

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

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

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

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

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

Answer 4

[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

Answer 5

[CityCat4]

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

С х.. ли баня-то сгорела? В https атаки типа MitM цветут пышным цветом и даже не всегда считаются атаками. Например, берем корпоративный прокси с бампингом. Он выполняет, фактически именно MitM - установив тебе свой корневой сертификат, он "на лету" подменяет целевой сертификат своим, получает shared secret и спокойно себе расшифровывает соединение.
То же самое весьма скоро будет у нас всех на компах - когда всех обязуют поставить госсертификат, без которого в тырнет просто не выйдешь.

мы в любом случае чувствуем себя небезопасно и неаноимно

Мы - это кто? Даже если провайдер (РКН, тащмайор) умудрится как-то узнать, что я смотрю порнуху - мне это в общем-то поуху. А политоту я в тырнет не тащу - ученый...

но сами данные никто увидеть не сможет?

Кроме самих даных есть еще множество косвенной информации, по которой можно достаточно точно судить о том, что "внутри". Кстати, защита некоторых протоколов на этом и базируется - убедить, что "внутри" безобидный https с котиками.

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

на основе предположений. Например:
1. Вася каждый день ходит на сайт 1.2.3.45 и прокачивает стопицот метров трафика
2. На сайте 1.2.3.45 отвечает простейший сайт с котиками, который не в состоянии генерить такой трафик
Вывод: сайт 1.2.3.45 - VPN, а сайт с котиками - заглушка, Васю вызвать на беседу.

Answer 6

[Rensar]

Ютуб замедляется благодаря тому, что SNI пакет не зашифрован https и содержит доменное имя сайта, а именно YouTube.com и Googlevideo.com. Технически существует механизм шифрования и SNI пакета, но на практике это не внедрено т.к. должно продерживаться и на клиенте и на сервере, а на сервере обычно выключено.

Answer 7

[Fedoresko1]

Никак не стыкуется. Для такого типа блокировок нужен расшифрованный трафик. Это значит, что вы передаете подобному сервису свои ключи шифрования. Именно поэтому данные услуги сомнительны для крупных компаний, способных самим построить свою систему защиты без рисков для безопасности трафика. С другой стороны, если вы хоститесь некоем облаке, условном амазоне, то облако может предоставлять все сервисы из коробки, в таком случае вы можете предпочесть терминировать HTTPS в файрволе самого облака, для примера: https://aws.amazon.com/blogs/security/tls-inspecti...
Что касается замедления ютуба и дискорда: есть ли сведения что замедление носит избирательный характер? Нужен ли вообще DPI для такого замедления? Думается, что там просто-напросто блокируют часть пакетов, идущих определенным маршрутом, и даже в этом случае нужно делать это на уровне провайдеров.

Answer 8

[Станислав Бодро́в]

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