Category: it

(no subject)

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

Работает так:
* клиент хочет сертификат для сайта example.org;
* пускай он разместит нечто по адресу http://example.org/some/path - мы это нечто проверим, и если оно окажется тем, что мы ожидаем увидеть, то это послужит доказательством того, что юзер - законный владелец этого имени хоста и вправе получить на него сертификат.

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

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

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

Для того, чтобы оценить маразм идеи, достаточно знать следующее: в новой версии Google Sites при создании сайта с custom domain Гугл автоматически выписывает ему сертификат от LetsEncrypt. Автоматически. LetsEncrypt у держателя домена не проверяет ничего. Сразу выдаёт сертификат Гуглу. Всё. Совершенно не нужно ничего понимать в криптографии, чтобы понять, какая это профанация.

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

Да, более традиционные процедуры domain validation тоже не лишены слабых мест: и создание DNS-записей с рандомальными значениями, и уж тем более получение мейла на адрес вида admin@example.org. Но то, что позволяет LetsEncrypt - это man-in-the-middle как он есть. Это не безопасность, это сапоги всмятку.

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

TLS v1.3 0-RTT replay attack

Зашёл почитать, что новенького есть в новой версии шифровального протокола TLS, в девичестве SSL (которая скоро будет использоваться всякий раз, когда мы жмём на линк с https:// и во многих, многих других случаях) - и был крайне сильно шокирован. Прямо в RFC, официальном документе, описывающем протокол, открытым текстом признаётся, что он подвержен replay attack, и что борьба с этим - ответственность разработчиков серверного приложения: вот вы, мол, и постройте систему так, чтобы это было неважно.

Collapse )
Collapse )
Collapse )
Collapse )
Collapse )

В общем, брат-админ, где фичу 0-RTT увидишь - там её и прибей.

P.S. Полезные ссылочки: 1, 2, 3.

Облака - белогривые лошадки

За последнее время много вожусь с IaaS-облаком; хочется излить несколько наблюдений, как подходы, принятые в обычных, невиртуализированных системах некритически переносятся в облачную среду:

1. Неоднократно наблюдал, как на облачных серверах баз данных или там Exchange люди привычно ставят диск для баз, и отдельно - диск на transaction logs, думая, что это улучшит производительность. Да с чего бы? На обычном железе в этом был простой, понятный смысл: на диске баз данных считывающая головка может прыгать между секторами как угодно, а на диске логов будет большую часть времени просто записывать в хвост. Соответственно, лучше, чтобы диски были разные.
Но зачем это делать в облаке, где все эти диски - всего лишь файлы на датасторе? Если они хранятся на одном и том же физическом хард-диске - ну так значит, он обречён крутиться псевдорандомально. Но даже если мы разнесём их на разные хранилища - один чёрт каждое из них используется тучей прочего народу. Предсказать, как реально будут крутиться хард-диски в этих хранилищах - абсолютно невозможно.

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


2. Продолжая тему дисков - объясните мне кто-нибудь, а какой смысл в локальных дисках в облаке? Почему не определить любой, или хотя бы любой data disk как shared? (Шишков, прости...) Это в физическом мире у нас есть либо SAN, либо просто SCSI-кабель к дискам, который больше чем в один компьютер не воткнёшь. А в виртуальном какая разница, какое устройство эмулировать - SCSI-контроллер или HBA какой-нибудь? Один чёрт наши диски - просто файлы на каком-то датасторе.

Сегодня облака shared disks обычно не предоставляют, и поэтому, чтобы завести какой-нибудь кластер на виртуалках, который их требует (да хотя бы файлсервер на микрософтовском Failover Cluster) нужно сооружать дикие турусы на колёсах. А как было бы просто: кликаешь в облачном портале мышкой пару раз - вот тебе виртуалка с диском. Кликаешь ещё - вот тебе вторая, третья, восьмая виртуалка, и все видят тот же диск. А дальше дело твоё, как их координировать: либо только главный сервер кластера юзает диск, либо ставь файловую систему, поддерживающую доступ со многих, типа VMFS или GFS2.


3. VLANs и, шире говоря, Ethernet вообще. Как-то упускается из виду, что в обычных локальных сетях broadcast domains существуют не от хорошей жизни, а оттого, что каждый компьютер в порт файерволла не воткнёшь. Хотелось бы инспектировать трафик между любыми двумя хостами - но что делать, свитчи функциональностью современного файерволла не обладают, а если такие и есть, то цена у них заоблачная, pun intended. Поэтому, если не хочется угробить производительность, приходится разбивать сеть на какие-то секьюрити-зоны, отказываться от возможности фильтровать трафик внутри них и удолетворяться фильтрацией между ними. Кроме того, VLAN-ы позволяют с лёгкостью гонять групповой и широковещательный трафик.

Но это не то, что я хотел бы от облака! Там-то мне возможность фильтровать трафик между двумя любыми машинами гораздо чаще пригождалась бы, чем преимущества broadcast domains.

Пример: допустим, у меня классический расклад - 20 вебных фронтэндов, за ними SQL Server. По логике секьюрити-зон, мне надо засунуть фронтэнды в один VLAN, SQL - в другой, и контролировать трафик между ними. Но тогда фронтэнды могут между собой неограниченно общаться - а зачем мне это надо? Им нужно говорить с HTTP-клиентами и с SQL-сервером, а друг дружке им что-либо передавать незачем.

Тут пригодился бы Private VLAN, но облако такое не предоставляет. Наштамповать отдельный VLAN под каждый фронтэнд можно, но мы упрёмся в иные ограничения. Приходится сажать их в общий, а это лишний риск.

Надо сказать, что Микрософт это как раз осознали - в Azure классического Ethernet-а нету, они там наворотили что-то своё на Layer2 (апдейт - таки да). В результате можно фильтровать трафик между любыми машинами, даже если они сидят в одном сабнете - но любой неюникастовый и, шире, любой не-IP трафик не поддерживается. По-моему, выбор в правильную сторону.


А у вас какие наблюдения?

(no subject)

Недавно мимо меня пробегало новенькое израильское удостоверение личности (теудат зеут) - уже не бумажка, а смарткарта - и я, конечно, тут же его зацапал глянуть, что на ентой смарткарте есть. Мда. После потрошения ейного сертификата могу честно сказать - построено ужасно, просто ужасно.
Collapse )

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

Если кто хочет повтыкать в детали сам - припадайте. "Leaf" сертификат со смарткарты не выкладываю из соображений приватности владельца, а правительственные - на здоровье.

(no subject)

У аутентификации по клиентским сертификатам есть множество ограничений, из-за которых она редко используется:
- общая сложность для понимания и настройки,
- сложность с управлением ключами, особенно когда юзеру надо ходить с нескольких устройств, с их обновлением,
- сложность с отзывом сертификатов, необходимость держать доступными точки CRL и OCSP, что может быть довольно геморройно, если у нас не общий Интернет, а изолированые сети,
- нельзя защитить часть сайта - скажем, чтобы https://hostname/public был доступен всем, а https://hostname/private требовал сертификата для опознания юзера. Точнее, этого результата можно добиться, но лишь при применении определённых хитростей.
- отсутствует нормальный logout - для того, чтобы сайт перестал тебя опознавать, надо полностью закрывать браузер (или изначально заходить в incognito-окне).

Но есть одно крутое преимущество - по сравнению с другими методами логина поверх SSL, она сильно усложняет проведение атаки man-in-the-middle, она же SSL interception. Вплоть до "вообще никак".

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

Способов добавить сертификат в список доверяемых есть масса, начиная с домейновых group policies и windows update, и заканчивая малварью и банальной социальной инженерией. Более того, тот же Avast antivirus делает это просто по дефолту - добавляет сертификат своего типа-CA в "Trusted Root Certification Authorities" и расшифровывает трафик.

Но когда требуется сертификат ещё и клиентский, то всё намного усложняется, посколько тогда система-перехватчик должна подменить и его тоже. А сервера куда недоверчивее в этих вопросах, чем браузеры. Им, как правило, просто указывают - сертификаты от этого CA и от этого принимать, а остальных лесом. К примеру, в FortiGate при создании PKI-юзера надо в явном виде задать и CA, которым его сертификат должен быть подписан, и что у этого сертификата должно быть в Subject. К тому же, тот может быть и вовсе самоподписанным. Тут не разгуляешься.

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

Так что стоящая вещь, товарищи, пользуйтесь. :-)

(Это я тут с админом одной сеточки пообщался - негодовал, что не может инспектировать наш SSL-VPN. Ну, мои тебе соболезнования, приятель. :-))

(no subject)

Забавно - вот я большой любитель всяких протоколов federated identity и прочей продвинутой аутентификации: SAML, oAuth, всё такое. Но вот уже в двух проектах приходится ловить людей за хвост и орать: опоментайтесь, панове! Вот вы хотите, чтоб на ваш сайт люди заходили через свой Google account - да, это очень удобно. Но подумали ли вы, что это значит, что доступ к данным ваших юзеров будет полностью в руках у Гугла? А подумали ли вы, что какой-нибудь ихний работник может залогиниться к вам под аккаунтом любого юзера по своему выбору, никаких паролей не зная вообще? А вы взвесили, позволяет ли природа этих данных вам брать такой риск, пусть даже и маленький? А этично ли это по отношению к юзерам, которые решили доверять вам, но вовсе не Гуглу?

И ведь люди-то не какие-то ламера, ещё нетвёрдо уверенные, чем Word от Firefox отличается - нифига, веб-разработчики, проджект-менеджеры и секъюрити-специалисты.

Вообще, ощущение такое, что удобство многочисленных облачных сервисов здорово развратило народ. Лет так десять назад предложение Микрософта "а давайте мы будем пароли от ваших персоналочек у себя держать" вызвало бы немедленный вопль негодования и ждала бы эту инициативу бесславная судьба проекта Clipper. А теперь - пожалуйста, куча народа логинится в Windows через Microsoft account, и никаких криков по этому поводу не слышно.

Или вот, пожалуйста - успешный бизнес, на 99% построенный на идее "а давайте мы будем контролировать доступ к вашим устройствам, от персоналки с виндой и до VPN-гейта". Этап первый - давайте выкачаем всю вашу Active Directory со всеми юзерами и паролями... Как на такое можно соглашаться - для меня загадка, но вот ведь.

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

Вангую, что в недалёком будущем мы станем свидетелями не одной утечки и взлома с участием персонала таких вот провайдеров всевозможных "... as a service". Потому что если чем-то можно злоупотребить - этим злоупотребят.

Немного о трёхглавых собаках

Нашёл недавно довольно интересную штуку:
Положим, у нас есть сайт, использующий "Windows Integrated Authentication" - то есть Kerberos или NTLM. И допустим, что юзер, пытающийся на него зайти - относится к другому, недоверяемому домену, или же он локальный юзер на доменном компе, а то и вовсе на стэнд-элоне. Так или иначе, попытка автоматического, прозрачного для юзера логина проваливается. Что произойдёт?

Ответ: зависит от браузера. Firefox просто выдаст сообщение об ошибке. А вот Chrome или IE поступят по другому - выкинут стандартное окошко username & password. А самое интересное, что если username указать в полной форме - к примеру, me@mydomain.com, - то они пошлют запросы DNS-серверу на две записи SRV, стремясь обнаружить керберосовский центр раздачи ключей (KDC) для указанного домена:
  • _kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs.mydomain.com
  • _kerberos._tcp.dc._msdcs.mydomain.com

  • и получив ответ, попытаются запросить по его адресу керберосовский билетик для сайта. Каковой затем и предъявят сайту как доказательство юзерской личности.

    Кстати, и клиент Remote Desktop в Win7 тоже так умеет.

    Почему это так интересно? А потому, что означает, вопреки популярному убеждению, что Kerberos можно использовать в Интернете - а не только в корпоративных сеточках.
    (Апдейт: не так всё здорово, см. внизу *).

    Collapse )

    * Апдейт: не так всё просто, оказывается. Между получением адресов контроллеров от DNS и запросом билетиков Kerberos есть ещё один этап - "LDAP ping". Это запрос по Connectionless LDAP (CLDAP) к домейн-контроллеру, адрес которого получен от DNS, по UDP-порту 389. Его цель - обнаружить ближайший контроллер для дальнейших запросов. Контроллер, получивший "ping", смотрит, с какого адреса он пришёл, и смотрит к какому сабнету можно его отнести (а сабнеты в AD относятся к тому или иному "сайту", в каждом "сайте" как минимум один свой контроллер). Соответственно, он сообщает клиенту, от какого контроллера тому требовать билетики.
    Ответ кэшируется, так что при перезапуске браузера "LDAP ping" будет послан необязательно.

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

    (no subject)

    Ответ на криптозагадочку, заданную здесь.

    Сперва пара моментов:

    1. Одно из сильных преимуществ ассиметричных ключей над паролями в том, что одну и ту же пару "публичный-секретный ключ" можно использовать для аутентификациии против массы разных серверов, не беспокоясь о том, что владелец сервера сможет злоупотребить знанием публичного ключа клиента, чтобы выдавать себя за него - поскольку из публичного восстановить секретный ключ нельзя, господа Ривест, Шамир и Адлеман гарантируют это.

    2. При изучении SSL, SSH и прочих протоколов на ассиметричных ключах, люди обычно сосредотачиваются на классическом сценарии, когда пара хороших честных ребят - Алиса и Боб - хотят пообщаться по секрету, в то время как злая ревнивая Мэллори желает перехватить разговор, выдавая себя то за Алису, а то и за Боба.

    Collapse )

    (no subject)

    Израильское: вслед за каньоном Азриэли обнаглела железнодорожная компания: пытаются перехватывать HTTPS-траффик в своей вайфай-сети (ISRAEL-RAILWAYS), при заходе на сайт по https:// подсовывают левый сертификат. Существуют достойные причины это делать (регулирование траффика), но это значит, что безопасность паролей, с которыми вы куда-то логинитесь через эту сеть, зависит чисто от доброй воли ихней техобслуги. Так что если вам браузер выкидывает предупреждение о сертификатах и SSL - лучше воздержитесь.

    Граждане, будьте бдительны.
    • Current Music
      Sheryl Crow - Motivation
    • Tags

    (no subject)

    Развлекаюсь - научился авторизироваться в ЖЖ по отпечатку пальца. :-)

    Как это работает?
    Collapse )

    Если отмахнуться от вопроса доверия к Гуглю, то схема по моему вкусу близка к идеальной:
    * никаких shared secrets между мной и сайтами,
    * никаких паролей и кодов, которых надо помнить,
    * тот input, что мне нужно вводить (отпечаток пальца) используется только на моём компе и не пересылается никуда,
    * правила, регулирующие, как часто мне нужно доказывать, что я - это я, тоже местные, и устанавливаются мною, а не Гуглем и не ЖЖ.
    * секретный ключ практически неизвлекаем,
    * ADFS-сервер не может имперсонировать меня в AD и исполнять под моим именем код,
    И вообще, используются одним махом все современные навороты в области - claim-based authentication, сертификаты + TPM, биометрия, а это прикольно.

    Что б ещё наворотить? :-)