Pull to refresh

Comments 64

Еще больше геморроя для админов. Let’s Encrypt удобен (сам им пользуюсь), но он только для smb или неосновных сервисов. Для крупных сервисов — не вариант

Для крупных сервисов — не вариант

Почему?

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

Нормальный компетентный админ-параноик без проблем порежет приблуде все лишние доступы (как минимум certbot и acme.sh заявляют работоспособность без root), проблема надумана

Коллега взгляните вот на эти свежие баги curl 7.71.0 с устранением двух уязвимостей и представьте себе что ваш certbot или acme.sh с одной стороны как-нибудь неудачно используют вот тот-же curl а с другой стороны они как минимум может читать/писать сертификаты, а скорее всего гораздо больше. Вам спокойно на душе?
Сделать скрипт который лазит за данными во внешний мир (вне вашего контроля) и при этом делает это реально безопасно — задача далеко не тривиальная.

Вы настолько не доверяете ISRG, что уверены в том, что однажды он подсунет вам специально оформленный пакет, эксплуатирующий какую-нибудь уязвимость? Мне кажется, что вероятность, что какой-нибудь очередной школьник хацкнет ваш проект через какой-нибудь очередной heartbleed в каком-нибудь очередном openssl, НАМНОГО больше, и вы беспокоитесь не о том, о чём реально надо беспокоиться.


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


Ну и вроде бы у certbot и acme.sh никаких серьёзных уязвимостей пока не находилось. В отличие от того же openssl, ага

В вопросах безопасности лучше не верить никому.

Люди безосновательно сокращающих срок действия сертификата творят зло, так как вынуждают меня делать либо больше ручной работы (Errare humanum est) или прикручивать некие certbot или acme.sh в коде которых тоже безусловно есть ошибки по той-же причине (Errare humanum est)…

И касательно ISRG у меня претензий нет но взгляните на проблему шире: к примеру можно заставить certbot или acme.sh пойти на другой сайт через отравление DNS… Я не буду прямо здесь и сейчас строить полный сценарий того как можно проэксплуатировать подобную конструкцию, просто смотрите на вопрос шире…

В вопросах безопасности лучше не верить никому.

Тогда нужно поднимать вопрос доверия к nginx, Docker, Linux, да и вообще к производителям процессоров и материнских плат, раз уж на то пошло (а слухи о бэкдорах в серверных материнках уже бывали...)


пойти на другой сайт через отравление DNS…

И у вас ничего не выйдет, потому что завалится проверка TLS.


Я не буду прямо здесь и сейчас строить полный сценарий

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

пойти на другой сайт через отравление DNS…
И у вас ничего не выйдет, потому что завалится проверка TLS.

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

Ну смотрите, вы уже сами затребовали сочетание одновременно трёх проблем: отравление DNS, баг в коде обработки сертификатов в openssl (curl тут вообще никаким боком) и какая-нибудь RCE-уязвимость в certbot (иначе напакостить просто никак не получится). Вы серьёзно считаете, что возможность проявления этих трёх проблем одновременно в одном и том же месте в одно и то же время не исчезающе мала?

Про сочетание трех проблем — это ваше. Я лишь указал что все эти «боты» пользуются сторонними утилитами и показал реальную гипотезу компрометации. Не зацикливайтесь на конкретике. Бот автоматически ходит куда-то и зачем-то. Если питрат знает что бот пользуется не пропатченым curl он может подсунуть ему нужные данные через отравленый днс, ваш реальный прокси или прозрачный прокси вашнго провайдера (привет всяким СОРМам), взломаный фронтенд Let's Encrypt, (сколько такого уже было), CDN, и т.п. и т.д.…
показал реальную гипотезу компрометации

Не показали. Чтобы уязвимость привела к компрометации, нужно найти пути её эксплуатации — а это как минимум очень трудно, учитывая специфику certbot.


Отравить днс — это трудно, для этого нужно устроить MitM-атаку или что-то похожее по сложности.


Подделать TLS — это очень трудно, для этого нужно не только устроить MitM-атаку, но и найти уязвимость в openssl, который уже вычитала куча народа вдоль и поперёк, особенно после heartbleed. Или же подкупить какой-нибудь центр сертификации, но он вряд ли станет рисковать своей репутацией ради какой-то жалкой «крупной компании».


Найти RCE-уязвимость в certbot, чтобы напакостить подсунутыми данными — это максимально трудно, потому что он написан на высокоуровневом языке Python без всякой работы с сырыми указателями, и атаковать можно разве что сишные библиотеки, которые этот certbot использует (тот же openssl), при этом certbot ещё и должен использовать уязвимую библиотеку небезопасным способом — найти такое сочетание обстоятельств невероятно трудно. (Про acme.sh не скажу, в шеллах не силён)


Плюс к этому нужно ещё подожать по крайней мере месяц, чтобы certbot вообще начал куда-то подключаться. Это тоже не способствует упрощению атаки.


Я не вижу смысла тратить время и деньги на анализ и защиту от практически невозможных атак. Рассуждать обо всём это бессмысленно, если речь не о государственной тайне и защите от атак другого государства. (А государство не то что Let's Encrypt — даже просто чужие алгоритмы шифрования использовать не будет, во избежание.)


(сколько такого уже было)

Ноль?

Мне кажется вы «не видете леса за деревьями», попробую зайти с другой стороны: какова, по-вашему, вероятность наличия критических уязвимостей в certbot со всеми его зависимостями в утилитах, питоне и его зависимостях? Надеюсь вам очевидно что она 99.999% (Писать 100% статистически неуместно).

В местах где безопасность критична (как при работе с сертификатами) нужно использовать максимально простыми, прозрачными и надежными инструментаи, а лучше ручками.

(сколько такого уже было)
Ноль?
Вашими бы молитвами, но нет: www.opennet.ru/search.shtml?words=%D7%DA%CC%CF%CD+%C9%CE%C6%D2%C1%D3%D4%D2%D5%CB%D4%D5%D2%D9

Надеюсь вам очевидно что она 99.999%

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


Вашими бы молитвами, но нет:

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


Во-вторых, для причинения «крупному сервису» реального вреда помимо «взлома инфраструктуры» нужно ещё найти уязвимость в certbot, подходящую целям хакера — и как я уже неоднократно говорил выше, вероятность одновременного наступления этих событий настолько мала, что я не вижу смысла рассматривать её как реальную. Почему вы по этому поводу параноите, всё ещё не понимаю.


Вообще, если уж говорить о «взломах инфраструктуры», то гораздо более вероятного (хоть и всё ещё маловероятно) получение доступа к какому-нибудь репозиторию какой-нибудь ubuntu с какой-нибудь подменой deb-пакетов на какие-нибудь вредоносные. Только вот тогда с таким же успехом можно подменить какой-нибудь nginx или вообще openssh-server, и Let's Encrypt тут уже никаким боком.


Не о том вы беспокоитесь, вот вообще не о том.

Мне кажется вы в жизни разработчик на чем-то вроде того-же питона… Вы просто не можете понять о чем я пишу…

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

Попробую последнюю аллегорию: группа товарищей предлагает по быстрому заменить механический контроль полета ну скажем в Боинге на набор ардуринок, сервоприводов и веселеньким сайтом на Джанго, потому что модно и молодежно…

Вы на таком самолете полетать рискнете? Я вот нет. Пусть энтузиасты летают, вылизывают, а потом будет видно выйдет чего или нет.

Во-первых, я ничего не говорил про время жизни сертификатов, в контексте Let's Encrypt я топлю лишь за автоматику (а при наличии автоматики время жизни уже не имеет значения). Во-вторых, сервер — не самолёт, пусть хоть даже полный root-доступ у хакера появится — ничего вопиюще страшного не случится, кроме какой-нибудь неприятной утечки персональных данных, некоторых финансовых проблем (зависит от специализации «крупного сервиса» и пряморукости админов) или чего-нибудь в таком духе. А учитывая мизерную вероятность наступления такого события — жертвовать большим удобством ради малюсенького и сугубо теоретического улучшения безопасности я считаю неразумным.


И опять же, вы сами скорее всего используете серверы на линуксе/фряхе/винде, написаннных на Си и с вероятностью 99.999% содержащих пачку RCE-уязвимостей в сетевом стеке, сливающих содержимое оперативки всем подряд. Вам самим не страшно на таком «самолёте» летать?

содержащих пачку RCE-уязвимостей в сетевом стеке, сливающих содержимое оперативки всем подряд
Почитайте как реально ломают сервера — вам будет интересно.

Вам самим не страшно на таком «самолёте» летать?
У меня в портфолио был сервер в том числе со смотрящим в мир web сайтом на php. Это не планировалось но он проработал без обновлений (кроме сертификатов) 15 лет, потом перешли на новую систему — старый сервер физически устарел. Я знаю что это не удача, как и какой ценой этого добиться.

Так как вы пишете что «я топлю лишь за автоматику», скажите: вы, конкретно вы, смотрели что Certbot делает с вашим приватным ключем? Смотрели его исходники? Может кто провел независимый аудит? Хотите использовать автоматику в этом месте веруя что там все в порядке — ради бога но не нужно это всем навязывать.

Просто помните что современная криптография обеспечивает стойкое шифрование на десятки лет, а производители навигаторов толкают к смене сертификатов чуть-ли не каждые несколько месяцев и тут-же подталкивают к решению в виде летающего сарая с плавательным бассейном и гольфом… Зачем???
Почитайте как реально ломают сервера — вам будет интересно.

Точно не через certbot.


вы, конкретно вы, смотрели что Certbot делает с вашим приватным ключем? Смотрели его исходники?

Если вы не доверяете ISRG и разработчикам certbot — так и скажите, а не тяните резину. Когда я вас спрашивал про доверие ISRG несколько десятков комментов назад, вы ответили, что «претензий нет». Теперь претензии, оказывается, есть?


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


как и какой ценой этого добиться

Я так понимаю, вы лично провели полный аудит ядра ОС и движка PHP на этом сервере? Вы же не доверяете кому-то просто так, дааа??

Если вы не доверяете ISRG и разработчикам certbot — так и скажите, а не тяните резину. Когда я вас спрашивал про доверие ISRG несколько десятков комментов назад, вы ответили, что «претензий нет». Теперь претензии, оказывается, есть?
От CA мне нужен только сертификат — его легко получить и проверить. Все остальное мне пока не интересно: претензий нет но и доверия тоже. Я предпочитаю не верить никому — помните?
Я так понимаю, вы лично провели полный аудит ядра ОС и движка PHP на этом сервере?
Вы не представляете насколько вы близки к истине — кастомно собранное монолитное ядро, кастрированный от всего экспериментального PHP и все его зависимости, и т.д. Несмотря на многократные ежедневные сканы и регулярные проверки на появляющиеся уязвимости — выстоял… Логи было смотреть просто занимательно… ;-)

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

Вы опять не о том: безосновательно создается проблема (навигаторы искусственно сокращают срок действия сертификатов), а дальше рассказываться байки о всяком гумусе который все должны прикрутить там где можно, а где нельзя так «нам все равно — не наши проблемы»…

Во-первых, это хоть и лютый трындец, но к уязвимостям не приводит и ничего из сказанного мной не отменяет. Во-вторых, поэтому нужно использовать именно написанный компетентными людьми certbot, а не всякие левые васянские поделки (вы же помните что я даже про acme.sh ничего не говорил?)

Я с философией автора согласен:
Автор проекта dehydrated согласился, что разбор JSON является большой проблемой, но добавлять внешние парсеры он не считает хорошей идеей, так как одним из ключевых достоинств скрипта является отсутствие привязки к внешним зависимостям.

Насколько я понимаю, в certbot все библиотеки «полные» но и кода/зависимостей, на вскидку, раз в 10-20 больше — для критичных к безопасности сервисов это очень плохо…

Если считать системные зависимости, то и здесь кода наберётся много, команды шелла ведь не из воздуха берутся. А если системным зависимостям доверять (вы же так и не сказали ничего про аудит линукса?), то и у certbot без плагинов, наверное, будет не слишком много кода (надо бы посчитать когда-нибудь)

Системные зависимости неизбежны в любой реализации.
у certbot без плагинов, наверное, будет не слишком много кода
certbot зависит от питона со всеми его зависимистями.

Сам питон давным-давно фактически превратился в системную зависимость, тщательно вылизанную за тридцать-то лет. Вы параноик, а я питону доверяю

В моих воспоминаниях питон пролез в стандартную поставу линуксов где-то лет 15 тому, и еще долго был заметной занозой в заднице так как ломал систему то тут (ропозитори) то там (кикстарт). А финты в духе изменения синтаксиса в минорных изменениях версий (типа print между 2.2 и 2.4) меня безмерно раздражали…

IMHO питон в системе предназначенной для совместного использования или там где нужна автоматизация разворачивания питона и его зависимостей — это и сейчас лютый писец. Приходится использовать анаконду, а про pip/conda живущие параллельно с rpm/apt я промолчу что-бы не материться, и т.п…

Я живу с питоном без всяких анаконд и мне норм. Но удобство его использования не имеет отношения к теме безопасности, в любом случае я считаю, что он достаточно распространён и оттестирован, чтобы ему можно было доверять, особенно после того как в третьем питоне пофиксили большинство родовых проблем (в то время как в тех же шеллах их никто исправлять не планирует во имя совместимости, и впихивать в систему безопасности шелл-скрипты длиннее пары строк — себя не уважать)

Если вы не доверяете сторонним программам, которые обновляют вам сертификат, то вы можете написать свою. Let's encrypt предоставляет API для этого. В любом случае, это можно автоматизировать.

Сделать можно все, только вот из-за их «инициативы» возможно придется делать дополнительную нетривиальную работу неизбежно привносящую дополнительные риски в систему…
Я написал «возможно» потому что после демарша Apple с Safary мы с коллегами обсуждали что делать и решили не менять нашу внутреннюю политику (2-летние сертификаты). Пользователи маков поставят себе Firefox (у нас чуть больше 10000 пользователей в организации и Firefox — доминирующий навигатор).
В основную ветку это вроде пока не планировали, а там будет видно… Может еще одумаются.
представьте себе что ваш certbot или acme.sh с одной стороны как-нибудь неудачно используют вот тот-же curl
А ваше приложение curl не использует? Или использует его исключительно «удачно»?

они как минимум может читать/писать сертификаты, а скорее всего гораздо больше
Вполне можно настроить прокси-сервер исключительно для .well-known запросов и исключительно в отдельную директорию с сертификатами только от Let’s Encrypt.

Не вижу никаких проблем (хоть с контейнеризацией, хоть без). Если есть конкретика — был бы рад услышать.
Что-то менять вручную — вот это несекурно.

Прошу пояснения — что может быть несекурного в ручной замене в файле данных старого сертификата на данные нового (копи/паст) ?

В том, что это делается вручную. Могу предположить и приватный ключ в txt файле.

Тут два варианта:


Либо Вы просто не понимаете что такое секурность либо квалификацию других людей меряете по себе.

Секурность подразумевает централизованное управление конфигурацией серверов, контроль версий конфигов и т.д. Вручную менять сертификат — несекурно.
Дискасс?

Вы издеваетесь?
Да в кровавом энтерпрайзе на кучу slave серверов конечно в автомате сертификаты ставятся но на мастер-сервер никто certbot и близко не пускает. Ручками, только ручками.

Вы вообще представляете как работает certbot и как сертификаты попадают в систему управления серверами? Похоже слабо. И что такое мастер-сервер? Сложно представить его функцию.

Выше в ветке коллега tbp2k5 всё уже написал про certbot — повторяться не буду.

Так нет проблемы централизации. Сертификат и ключ можно заливать в какой-нибудь vault, а он уже будет раскатываться по серверам с помощью любой реализации IaC. А как заливаются сертификат и ключ в vault уже не имеет значение для секурности.
А вот certbot как мне кажется, наоборот противоречит принципу Infrastructure as Code, так как это скрипт, который меняет конфиги веб-сервера. Да, ему можно запретить менять конфигурацию веб-сервера, но всё равно, генерить сертификат на сервере, не самый лучший вариант.

certbot меняет конфиги конфигурацию веб-сервера, если используется авторизация через веб-сервер, то есть только для domain + www.domain. Для получения wildcard сертификата необходимо использовать только dns авторизацию, а это значит по API дергается какой-нибудь Cloudflare или GoDaddy, и тут уже управляемая инраструктура остаётся неизменной.
генерить сертификат на сервере, не самый лучший вариант.

А какая разница где его генерить, если в итоге приватный ключ всё равно придётся класть на сервер?


Ну и да, как отметили выше, можно получать сертификаты через DNS-01 challenge без использования сервера

Например, я не готов вводить данные своей кредитной карты на ресурсе с сертификатом let’s encrypt. Такой сертификат в разы проще получить, чем «нормальный»

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

А какая разница в случае кредитных карт? Если сайт может самостоятельно работать с данными кредитных карт то вся его инфраструктура по работе с картами должна была пройти сертификацию у VISA/MaterCard, а это намного сложнее получения EV сертификата

Это не так. Вот, к примеру, есть одна из крупнейших компаний по приёму электронных платежей — Stripe.

Знаете, что нужно было, чтобы получить EV-сертификат на имя Stripe, Inc у Comodo? Всего лишь зарегистрировать компанию c таким же именем в любом другом штате. Удостоверяющий центр честно проверил (причём, проверка эта поверхностна) наличие компании и выдал сертификат. Позже такую же штуку провернули с GoDaddy, и тоже прокатило. Причём, оба УЦ так и не признали, что выдача сертификатов была ошибкой. Их позиция «компания существует — мы выдаём, а уж если потом заметим, что это фрод, тогда и отзовём».

Сложность получения сертификата, о которой вы говорите, составила 100 долларов.

А теперь расскажите, каким образом вы определите, то ли это та самая Stripe из Делавера, то ли это другая Stripe из Кентукки? И вообще, помните ли вы наизусть, в каком штате зарегистрирована, хотя бы, PayPal?
IMHO Тут сама концепция («Чаще меняем сертификат» = «Безопаснее») дурацкая:
— проблемы в алгоритмах так часто не появляются (а если вдруг оные всплывут коротко-живучесть сертификатов никак не спасет)
— с крадеными сертификатами вопрос решается через CRL и вот как раз проверку CRL разработчики навигаторов могли-бы радикально улучшить.

Я (косвенно через опрос моего «издателя сертификатов») голосовал против сокращения жизни сертификатов потому что я реально не вижу плюсов для безопасности но вижу гигантскую проблему в виде всяких OBM (out-of-band management) типа iLO или iDRAC, web-нтерфейсы свичей, камер и прочих IoT в которых смена сертификата и трудоемка и бессмысленна (приватный ключ такие системы зачастую не покидает никогда).

Я считаю что возможности генерировать и использовать сертификаты сроком до 5-7 лет — вполне адекватная потребность.

В общем с Вами согласен, но проблемы с "в виде всяких OBM" не вижу — только браузеры же перестанут сертификаты больше года воспринимать — это же приложений не касается.

OBM, как и все остальное мною перечисленное — это в общем случае вебсайт к которому хотя-бы надо ходить из браузера :-(
Управление hp ilo осуществляется через браузер. И консоль через браузер. Лично встречал сервера, доступ к oobm которых современными chrome/firefox блокируется, так как им не нравится сертификат. Выручал только (тарам-пам-пам) Internet Explorer.

печально :(


К ipmi supermicro через приложение доступ есть.

IPMI там тоже есть но возможность видеть экран сервера или монтировать локальный CD/USB на удаленный сервер в навигаторе — очень удобно

Как раз отказался от комодо в пользу летсэнкрипт в виду снижения критичности узлов… ну придётся строить процесс через гитлаб/докер/ансибл/паппет/заббикс, чтобы все домены обновлять, мониторить и проверять работу этого всего до раскатки и после. За процессом придётся следить более тщательно… всё-таки комодо мы могли предьявить претензии и привлечь их саппорт, а летсэнкрипту уже нет. Больше точек отказа и утечек, но меньше точек хьюмен эррора… когда всё будет настроено. Насчёт безопасности очень спорный вопрос… но кейсов обоих случаев можно придумать равнозначно много.

Что больше всего удручает в таких мерах безопасности — это их безальтернативность: они будут применяться ко всему содержимому.
Тогда как требования безопасности для разных сайтов (и даже разделов одного сайта) кардинальным образом отличаются.
Я вижу, как минимум, три разных группы по требуемому уровню безопасности.
1. Распространеняющие общедоступную информацию: всевозможные новостные, развлекательные и популяризаторские сайты, сайты с советами и кухонными рецептами и прочие им подобные. Кстати, витрины и каталоги интернет-магазинов, по моему мнению, тоже попадают в эту категорию. По большому счету, для основного содержимого таких сайтов (кроме разделов для администрирования) TLS вообще не нужен: там нет ни информации, которую нужно скрывать, ни искажение которой способно реально нанести хоть сколь-нибудь серьезный ущерб. Единственная хоть сколь-нибудь разумная, на мой взгляд, причина использовать TLS для таких сайтов/разделов — это защита рекламных вставок от подмены существующих или добавления новых провайдерами доступа в Интернет.
2. Сайты с некритичным в плане потери денег/утечки важных данных содержимым, создаваемым и или дополняемым пользователями: всевозможные форумы и прочие сайты для общения, для публикации содержимого, создаваемого пользователем, разделы сайтов, содержащие комментарии и т.п. В частности, Хабр(основной и Q&A) относится к этому типу. Защищать соединения с такими сайтами/разделами нужно (хотя бы — для аутентификации пользователей и разграничения доступа), но вот требования к уровню их защиты невысокие, и, в частности, требование раз в год менять ключ шифрования — IMHO явно избыточное.
3. Сайты/разделы содержащие нечто действительно ценное: разделы всевозможных платежных систем, сайты содержащие или позволяющие ввести информацию, которая ценна сама по себе (персональные данные) или передача которой приводит к юридическим последствиям (сайт, позволяющий обращаться к органам власти, типа Госуслуг, например), а ткже — сайты предоставляющие доступ к внутренним системам предприятий. Вот там передаваемая информация достаточно ценна, чтобы оправдать действительно серьезные меры защиты, типа требований к криптостойкости и огарничение сроков действия криптографических ключей.
Но вот внедрение чохом мер, реально необходимых лишь для последней, требущей наибольшей защиты, группы ресурсов Интернет, IMHO неоправданно и ведет к избыточным затратам на администрирование всех остальных ресурсов.

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


Сейчас смысл TLS 1.3, DOH, HTTP/3 и уменьшение времени жизни сертификатов — что бы канал до всех сайтов был одинаково хорошо зашифрован. И внешний наблюдатель не сможет знать что летит в шифрованной трубе: телеграмм или личный блог с котиками — для внешнего наблюдателя это должно быть не видно.


PS: интересно, в чем проблема обновлять свои сертификаты на load balancer’e в автоматическом режиме? А если компания не такая большая и LB отсутствует — тогда CloudFlare все может сделать сам, вместо админа...

И внешний наблюдатель не сможет знать что летит в шифрованной трубе: телеграмм или личный блог с котиками — для внешнего наблюдателя это должно быть не видно.

Поясните, пожалуйста, в чем риски того, что внешний наблюдатель определит категорию информации, которую получает пользователь. То есть, почему это настолько существенно повысит вероятность получить несанкционированный доступ к информации той самой третьей категории — которая одна имеет достаточную ценность, чтобы её имело смысл защищать серьезными мерами — что оправдает тотальное применение этих серьезных мер по защите информации.
Я таких рисков не вижу. Но, может быть, я что-то упустил.
PS: интересно, в чем проблема обновлять свои сертификаты на load balancer’e в автоматическом режиме? А если компания не такая большая и LB отсутствует — тогда CloudFlare все может сделать сам, вместо админа...

Проблема — исключительно в дополнительных затратах на поддержание безопасности. Есть общий принцип выбора экономически обоснованного уровня безопасности: стоимость мер защиты не должна превышать возможный ущерб. А значительная часть информации в Интернете не имеет такой ценности, чтобы оправдать затраты даже на столь несложные меры по её защите. Для первой категория это однозначно так — там цена информации практически нулевая. Насчет второй, конечно, надо считать конкретно каждый случай, но что-то мне подсказывает, что для большинства случаев в этой категории вывод будет тот же: усиление защиты невыгодно.
Поясните, пожалуйста, в чем риски того, что внешний наблюдатель определит категорию информации, которую получает пользователь
  1. Продажа данных относительно пользователя, включая персональные данные, если трафик вообще не зашифрован
  2. Ограничение доступа к информации (блокировки легче осуществлять, когда есть хоть какие-то маркеры)
  3. Манипулирование трафиком устраняя сетевой нейтралитет как оператору вздумается
  4. Модификация трафика под разными целями: мошенничество; SSL Strip и аналоги; DNS редиректы; подмена рекламы для заработка оператором, а не сайтом; встраивание рекламы там, где её по факту и нет (страницы 404)
  5. поломка работы IoT устройств из-за модификации трафика в тех местах, где IoT устройство не ожидает

Продолжать можно вечно…

почему это настолько существенно повысит вероятность получить несанкционированный доступ к информации той самой третьей категории… — что оправдает тотальное применение этих серьезных мер по защите информации.
Однажды, отец позвал их к себе и попросил разломать пополам веник. Сначала попробовал старший сын, но, сколько он не старался — ничего не получилось. Такие же неудачи постигли среднего и младшего. Тогда отец развязал веник, и попросил каждого сына разломать по несколько соломинок. Это, конечно же, им с лёгкостью удалось.


  1. Иногда для защиты одной части населения нужно защищать и другую, дабы различить первую и вторую группу и в дальнейшем работать с одной из них (или меньшинством) было невозможно.
  2. Весьма часто пользователи и не знают когда им нужно использовать шифрование и другие доступы защиты информации, а когда нет. Особенно когда речь идёт о молодых людях.
  3. Не только пользователи нуждаются в шифровании, но и сами компании. Как вы убедите, что это именно провайдер добавил JS скрипт и украл какие-либо данные пользователя, а не вы передали третьей стороне без разрешения на это?
Я сожалею, что мне не ответил автор предыдущего комментария, который прочел и прокомментировал мой оригинальный комментарий.
Так что, прошу прощения, я вам буду отвечать максимально кратко, поскольку ваш ответ несколько выбивается, как мне покзалось, из контекста предыдущего обсуждения.
По первой группе ваших аргументов.
1. Персональные данные я еще в своем оригинальном комментарии однозначно отнес к третьей группе — требующих максимальных мер защиты. Более того, для тех владельцев ресурсов, которые не осознают важность персональных данных, многие государства приняли законы (про Евросоюз и РФ — знаю про такие законы точно), заставляющие владельцев осознать важность этих данных под угрозой наказания.
2. Блокировки я вообще тут не обсуждал — я рассматривал чисто экономические аспекты.
Однако даже тут далеко не всё однозначно: избыточная защита может вредить. В частности, на моем личном примере: мой провайдер интернета (весьма небольшой) фактически блокирует мне доступ к сайту worldometers.info — одному из лучших источников информации о пандемии COVID-19. И делает он это не со зла, а потому что ровно на тех же IP на серверах Cloudflare размещен сайт онлайн-казино (надеюсь, вы не возражаете что есть причины блокировать такого рода ресурсы), а оборудование провайдера не позволяет выделить из SNI, к какому именно сайту идет доступ. Если бы данные worldometers.info не шифровались (безопасность это не нарушает, т.к. данные — общедоступные, первая группа в моем оригинальном комментарии), то моему провайдеру было бы легче блокировать только то, что блокировать ему надо.
3. Т.к. нарушать сетевой нейтралитет в пользу крупных компаний-монополий (т.е. там, где эти нарушения наиболее опасны) можно не по именам сайтов, а, с тем же успехом, по их IP, то считаю ваш аргумент опровергнутым.
4. Меня как потребителя мало волнует, кто именно показывает мне рекламу. Да, владельцев сайтов это волнует — они теряют деньги, потому они собственно и используют TLS. Но альтернатива тут есть: законодательный запрет искажения трафика провайдером, предусматривающий существенные штрафы и возмещение убытков распространителю исходной информации.
А угрозой подмены лично для меня данных из общедоступных источников я пренебрегаю: нет у меня столько денег, чтобы кому-то на этом можно было заработать.
5. Критически важные данные для функцинирования IoT — это опять-таки третья группа, требующая максимальных мер защиты.

Вторая группа аргументов
1,2. Разбиение по группам предлагается по ресурсам, а не по пользователям. Так что непонятно, как это помогло бы реализвать описанные вами угрозы.
3. Во-первых, ценные данные должны защищаться достаточно надежными методами (см. опять про третью группу), в том числе — от несанкционированного доступа из недоверенной области ресурса. Технически в браузерах сейчас это реализуется в полной мере.
А во-вторых, тут как раз мог бы, совместно с законом о запрете модификации трафика, помочь пресловутый «закон Яровой» (люблю случаи, когда можно получить пользу от того, что считается вредным): суд может запросить зафиксированный по этому закону трафик у хостинг-провайдера и провайдеров промежуточных операторов и по этим данным установить источник искажения.
1. Это мало что меняет, если меняет вообще. Шифруя всё мы наверняка поможем в ситуациях, когда информация утекла непредвиденным способом, по непредвиденному каналу или прочих не очевидных моментах. Даже если сайт представляет из себя банальный кусок статического контента, то это всё равно не значит, что с помощью MITM нельзя добыть персональную информацию любым из доступных методов идентификации (к примеру, через E-Tag).

2.
Однако даже тут избыточная защита может вредить. В частности, мой провайдер интернета фактически блокирует доступ к сайту worldometers.info
Это проблема не «избыточной защиты», а именно наличия веерных блокировок.
(надеюсь, вы не возражаете против блокировки такого рода ресурса)
Я против блокировок в принципе. Веб-ресурс — не армия IRL. Пользователь можно спокойно уйти с веб-ресурса, если он ему не нужен или представляет для него какую-либо опасность. Если онлайн-казино представляет опасность, то пусть и государственное казино заблокируют.

К тому же мы все прекрасно знаем насколько эффективны эти блокировки.

(безопасность это не нарушает, т.к. данные — общедоступные, первая группа в моем оригинальном комментарии)
Нарушает, поскольку возможен MITM с запуском произвольного исполняемого кода как минимум в браузере, не говоря уже о соц. инженерии с предложением скачать APK. Сделать это может не только рядовой сотрудник провайдера, но и любой человек, который окажется между провайдером и абонентом. Не знаю как вы, но я бы не хотел на официальном сайте скачать .APK/.EXE/.DEB от злоумышленника (надеюсь наш диалог не скатится в холивар о монополии сторов).

моему провайдеру было бы легче блокировать только то, что блокировать надо
А ещё ему было бы легче встраивать свою рекламу вместо рекламы владельца сайта и ваш сайт о COVID-19 получил бы меньше денег на развитие. Но получил бы провайдер. Давайте похлопаем.

3.
можно не по именам сайтов, а, с тем же успехом, по их IP, то считаю ваш аргумент опровергнутым.
Как минимум это было бы более затруднено. Многие из «партнёров» тоже сидят в облаках.

4.
Меня как потребителя мало волнует, кто именно показывает мне рекламу.
А меня, как потребителя, нет. Почему какой-то, просите, обоссанный провайдер-монополист, должен получать деньги за просмотр контента, который он не генерировал? Почему он должен получать деньги вместо ресурса, который проделал работу? Провайдер передаст часть заработка, что бы ресурс смог существовать не переводя всех пользователей на подписку? За какую такую работу провайдер получает деньги? За «просто так»?

Да, владельцев сайтов это волнует — они теряют деньги
Если бы потребители контента понимали все последствия подмены рекламы, то и они были бы против.

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

А угрозой подмены лично для меня данных из общедоступных источников я пренебрегаю: нет у меня столько денег, чтобы на этом можно было заработать.
У вас нет, а у кого-то есть. А ещё личная информация — тоже ценность. Только из-за того, что вам всё равно, другие люди не должны вездесущее шифрование вводить? Или как? Вот лично я, к примеру, вообще на HTTP не хожу. Всегда включён HTTPS Everywhere. Любой сайт без HTTPS моментально теряет меня как клиента. У меня нет абсолютно никакого желания каждую неделю проверять устройство детей на момент установленных зловредных приложений после очередного незаконного редиректа в HTTP трафике мобильным оператором, юристы которого в разы круче любого юриста, которого я могу оплатить. Не говоря уже о честности судей.

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

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

Это если и поможет, то далеко не во всех случаях, т.к. трафик модифицируется прямо перед отдачей данных непосредственно пользователю. Оператор или абсолютно любой промежуточный узел (в т.ч. злоумышленник) может изменить трафик и остаться абсолютно незамеченным.
По пунктам:
1. Вы игнорируете экономическую сторону вопроса обеспечения безопасности. А в оригинальном комментарии она была краеугольным камнем всех рассуждений.
2. Блокировка тут именно что не веерная, а совершенно прицельная, но — ограниченная техническими возможностями. Кстати, если бы шифрование содержимого тоннеля было бы идеальным (SNI все-таки — это компромис), то избыточная блокировка была бы неустранима вообще принципиально. Ну, а в реальности этого примера она ограничена экономическими соображениями, от чего положение ничуть не лучше.
Допустимость или недопустимость блокировок вообще — это вопрос субъективных ценностей, а такие вопросы я вообще предпочитаю не обсуждать ввиду очевидной непродуктивности обсуждения.
Угроза удаленного выполнения нежелательных программ через принимаемую браузером информацию слабо связана с возможностью модификации трафика на пути от источника, потому что и сам источник нельзя считать доверенным (возможна угроза через оригинальное немодифицированное содержимое), а потому защищаться от нее надо всегда, и потому — совсем другими методами.
3. Может, и затруднено, но возможно. Монополисты имеют возможность получить свои, специально выделенные для них IP и их группы. И если это им будет сулить выгоду (и по рукам им за это никто не даст)- воспользуются этими воможностями, не сомневайтесь.
4.
А меня, как потребителя, нет.

Ну, если вас волнует, кто и как распределяет не ваши деньги, то, оставаясь в рамках идеологии оригинального поста, возразить нечего: все рассуждения в нем основаны на частных материальных интересах, а не на соотвествии какми-либо идеалам. Мне, вот например, в принципе не нравится реклама (любая), а схема возмещения затрат на создание и поддержку ресурсов интернета через рекламу кажется мне нездоровой, и я готов заплатить рыночную цену за то, что мне хочется получить. Но я считаю, что выбор той или иной схемы возмещения затрат — это, пока схема не противоречит закону, частное дело владельца ресурса, т.е. меня оно не касается.
Ну, и ещё раз напоминаю (по поводу «запрета чтения»), что действительно ценная информация должна быть надлежащим образом защищена.
С возможностью модификации контента ресурса третьей стороной, группа этого ресурса, внимание, внезапно может быть изменена.
Понижена она незаметно для пользователя быть не может (браузер предупреждает сообщением типа «вы собираетесь отправить данные через незащищенное соединение» и т.п.), ну а повышена — да пожалуйста.
Это если и поможет, то далеко не во всех случаях, т.к. трафик модифицируется прямо перед отдачей данных непосредственно пользователю

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

PS Похоже, у вас система ценностей не соответсвует той, на которую опирается оригинальный комментарий: с вашей позиции, которая изложена чуть выше, я понял, что неограниченные свобода, приватность и т.п. идеальные ценности являются для вас бесценными, а комментарий оперался на другой подход: не на идеалы, а на прагматичное следование каждым своим материальным интересам в рамках закона. Если так, то дальнейшую дискуссию вести смысла нет: ни к каким выводам, не вызывающим возражений у дискутирующий, она все равно не приведет. Так что, если желаете, можете ответить на мой комментарий, и на этом мы с вами дискуссию закончим.
Либо, как вариант — продолжим её вести в рамках сугубо прагматичной системы ценностей.
Sign up to leave a comment.