Задать вопрос

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

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

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

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

Я знаю что есть локальные фаерволы NGFN которые могут блокировать ресурсы из локальной сети по содержимому страниц (возможно не по содержимому, но по крайней мере). Это же тоже странно, что фаервол видит содержимое страниц между сайтом и моим браузером.
Но впрочем для корпоративной сети это наверное нормально...
  • Вопрос задан
  • 4922 просмотра
Подписаться 4 Средний 2 комментария
Пригласить эксперта
Ответы на вопрос 8
mainheader
@mainheader
Divide et impera
Все описано в этой статье
Ответ написан
Комментировать
@rPman
Хочу напомнить, удостоверяющий центр, выдавший сертификат, способен полностью расшифровать и даже подделать ваш трафик (на сайты, чьи сертификаты он обслуживает). Думать, что удостоверяющие центры не отдают своему государству (а ведь еще есть межгосударственные договоренности, типа не отдашь ключи, 'отключим газ') все необходимые ключи, опрометчиво.
При условии если приватник он сгенерировал а не пользователь самостоятельно.

Владелец веб сервера (в т.ч. хостер 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
Ответ написан
Комментировать
saboteur_kiev
@saboteur_kiev Куратор тега Информационная безопасность
software engineer
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
Ответ написан
Комментировать
CityCat4
@CityCat4 Куратор тега Информационная безопасность
//COPY01 EXEC PGM=IEBGENER
В 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, а сайт с котиками - заглушка, Васю вызвать на беседу.
Ответ написан
Комментировать
@Rensar
Ютуб замедляется благодаря тому, что SNI пакет не зашифрован https и содержит доменное имя сайта, а именно YouTube.com и Googlevideo.com. Технически существует механизм шифрования и SNI пакета, но на практике это не внедрено т.к. должно продерживаться и на клиенте и на сервере, а на сервере обычно выключено.
Ответ написан
Комментировать
@Fedoresko1
Никак не стыкуется. Для такого типа блокировок нужен расшифрованный трафик. Это значит, что вы передаете подобному сервису свои ключи шифрования. Именно поэтому данные услуги сомнительны для крупных компаний, способных самим построить свою систему защиты без рисков для безопасности трафика. С другой стороны, если вы хоститесь некоем облаке, условном амазоне, то облако может предоставлять все сервисы из коробки, в таком случае вы можете предпочесть терминировать HTTPS в файрволе самого облака, для примера: https://aws.amazon.com/blogs/security/tls-inspecti...
Что касается замедления ютуба и дискорда: есть ли сведения что замедление носит избирательный характер? Нужен ли вообще DPI для такого замедления? Думается, что там просто-напросто блокируют часть пакетов, идущих определенным маршрутом, и даже в этом случае нужно делать это на уровне провайдеров.
Ответ написан
Комментировать
Кому ты нужен со своим MITM? Если кому-то понадобишься, найдут тебя как разговорить. Для этого не обязательно сувать твои пальцы в мясорубку. В чатах, форумах, соцсетях по тебе можно собрать информацию, что сейчас делается довольно легко, и потом тебя могут разговорить.
С другой стороны, судя по бесконечным утечкам, торчащими голым задом в интернет базам данных и тотальному наплевательству к безопасности мудрить с MITM даже не надо.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Похожие вопросы