cat_mucius

Снилось, что я то ли читаю статью на Хабре, то ли смотрю видеолекцию - о своеобразном аспекте безопасности. Есть, дескать, для макбуков и айфонов приложение - секретарша Дженни. У Дженни есть много настроек предпочтений владельца, и в том числе такие - когда, кому и как можно вступать с владельцем в физический контакт. Подавалось это как инструмент борьбы с приставаниями на рабочем месте, и поэтому, к примеру, была такая опция: кто и в какие часы может владельцу класть руку на плечо. Скажем, с 08:00 и до 17:00 никому нельзя.

В случае нарушения Дженни мигом сигнализировала куда надо. Такая виртуальная дуэнья.

Ну и дальше шёл рассказ о том, как злоумышленники могут хакнуть бедную Дженни, чтобы владельца (вернее, владелицу) безнаказанно помацать. И как её от тех атак защитить.

Почему-то, несмотря на то, что жила Дженни на эппловских девайсах, её интерфейс был вебным, с табами, как на домашних раутерах. Судя по тому, что там можно было задавать все эти правила доступа на языке SDDL (такая вот нечитабельная хрень), это была админка для продвинутых.

P.S. Похоже, про сны мне есть рассказать куда больше, чем про реальность...

У аутентификации по клиентским сертификатам есть множество ограничений, из-за которых она редко используется:
- общая сложность для понимания и настройки,
- сложность с управлением ключами, особенно когда юзеру надо ходить с нескольких устройств, с их обновлением,
- сложность с отзывом сертификатов, необходимость держать доступными точки 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. Ну, мои тебе соболезнования, приятель. :-))

Техническое: про Гугл, SAML и Keycloak.
http://blog.mucius.tk/2017/04/google-as-saml-idp.html

Поругаю для разнообразия Микрософт:

1. Ознакомился с возможностями Point-to-Site VPN в Azure, ихнем облаке. Впечатлён - редкостное убожество. Аутентификация предусмотрена только по сертификатам, но и это реализовали по-идиотски: заливаешь корневой сертификат в список доверенных, после чего все его потомки признаются доверенными - если только ты explicitly не указал, что вот конкретно этому, этому и этому доверять нельзя. Причём CRL тянуть оно не умеет - указывай там же, на ихнем портале.

То есть чудесно: если у меня и у Васи есть сертификат от, скажем, Comodo, и я хочу организовать нам доступ - то заливая корневой сертификат Comodo я даю доступ к своим облачным сетям всем, у кого тоже есть сертификат от Comodo!

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

Удивительно: это компания, сделавшая в своё время VPN-гейт с наилучшим набором фич для аутентификации из всех, что я видел - я имею в виду ForeFront TMG. А теперь они выкатывают эту хрень. А TMG они убили! Убили, Карл!

Вообще, опознаванию на сертификатах как-то не везёт, как Булгакову на экранизации. Вот в FortiGate сделали гораздо правильнее: заливаешь корень и перечисляешь список значений поля Subject, которые надо принимать - а все прочие идут лесом. Но при этом не подумали, что если этих фортигейтов в организации больше, чем один, то ведение этих списков превращается в management hell.


2. Сломался у меня давеча скрипт, что CRL в облако публиковал. Полез разбираться - и что же вы думаете? Скрипт мне поломала славная корпорация Микрософт. Я пользовался програмкой cURL - а эти добрые люди решили, что они сейчас пойдут навстречу потребителю и в новой версии PowerShell обозначили curl как синоним своего коммандлета Invoke-WebRequest. Изменение команды на curl.exe решило проблему, но вашу же душу, благодетели!..

Товарищи френды, если у кого есть аккаунт на DreamWidth.org, который я ещё не зафрендил - отметьтесь, пожалуйста.

Кстати, преимущество DW перед ЖЖ - нормальное шифрование траффика (имеет смысл в браузер / закладки вносить адрес бложика с префиксом https:// - тогда и при переходе на другие страницы HTTPS сохраняется). Правда, он расшифровывается для инспекции на CloudFlare (если кто не знает - такой сервис для защиты сайтов и кэширования для экономии траффика). Возможно, американская гэбня туда нос совать может - но российская вряд ли.

А вот чего не хватает - это возможности обращаться к журналам только по URL вида https://dreamwidth.org/~account или https://dreamwidth.org/users/account. Точнее, она есть, но сервер сразу же перенаправляет на страницу вида https://account.dreamwidth.org. Что, конечно, выглядит покрасивше, но зато открывает возможность какой-нибудь системе блокировки отследить, какой конкретно журнал пытаются открыть - и по запросу DNS, и по полю SNI в начальном запросе HTTPS (подробнее на ту же тему). Открыл support request на эту тему, авось да отнесутся (update: отказали, да в общем-то и правильно - не продумал).

А ведь используй Клинтон, её окружение и верхушка американской демпартии S/MIME или PGP с нормальной защитой ключей - и наверняка не было бы у них всех этих почтовых скандалов. Залезли бы фбрщики или злые хакеры на сервер - и нашли бы кучу мейлов с нечитаемым аттачментом smime.p7m. Всё.

Сами виноваты, патамушта ослы. :-)

Паки и паки повторяю - не пренебрегайте шифрованием.

Завёл себе технобложик, буду там постить всякие сисадминские штучки - и у самого под лапой будут, и авось кому ещё пригодятся.

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

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

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

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

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


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

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

Неожиданное продолжение этой темы - принят новый российский закон (ФЗ-445), обязывающий все фирмы, выпускающие свои цифровые сертификаты (Сertificate Authorities, Удостоверяющие Центры) не использовать в качестве корневого самоподписанный сертификат, а получить его от государства, за подписью от некоего Государственного Удостоверяющего Центра. Что означает, что отправной точкой, от которой выстраивается цепочка доверия той или иной цифровой подписи, становится не сертификат определённой фирмы (какого-то российского аналога Verisign), а этого самого ГУЦ.

В статье на Хабре в качестве обоснования этого шага приводится забота о юзере - ему, дескать, не надо решать вопрос доверия каждому из CA - добавил государственный корневой сертификат в список доверяемых и вся недолга. У меня такой подход вызывает сомнение: система PKI тем и хороша, что позволяет определять меру доверия разным CA (и соответственно, выданным ими сертификатам) независимо друг от друга, и в случае чего вовсе это доверие отменить (что чуть не произошло с фирмами TrustWave и TeliaSonera, и произошло с DigiNotar). Доверие единому корню же навязывает логику "всё или ничего" (ну и к тому же, сам факт государственной регуляции в области, где это совершенно не требуется...)

На это можно возразить, что такое построение не мешает конечным юзерам (или сисадминам в корпоративной сети) выстраивать цепочки доверия по своему усмотрению: занести сертификат ГУЦ или проштрафившегося частного CA в список недоверяемых, или наоборот, указать сертификат CA в качестве корневого, хоть он и не самоподписан.

Но вот что у меня сомнения не вызывает, так это то, что такая система позволяет государству подделать сертификат от любого CA из заверенных им, способом, куда более сложнообнаружимым, чем при нынешнем положении дел. Как я писал ранее, сегодня государство может заставить какой-нибудь из CA, действующий под его властью, выдать поддельный сертификат под любой сайт, почтовый адрес и т.д., который будет принят браузером или мэйлером без возражений - но проверка такого сертификата может обнаружить, что его CA внезапно изменился. Странно будет, если вдруг окажется, что сайт https://mail.google.com заверен израильской фирмой StartCom, а не американским GeoTrust, не так ли? По ссылке описан плагин CertLock, который именно это и проверял.

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

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

Что я могу посоветовать тем, кто имеет основания опасаться интереса к своему траффику со стороны российских спецслужб: если в списке "Trusted Root Certification Authorities" засветился какой-нибудь ГУЦ - переправить его в "Untrusted Certificates". Если опасения сильные, можно туда отправить и все прочие российские CA.

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

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

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

А хрен. Вот подходит к двери подсобки честный труженик Вася. Достаёт карточку, вставляет в замок. Только замок тот не простой, а малость хакнутый - любой сигнал с васиной карточки пересылает на другую, принадлежащей вражьему засланцу Пете. И обратно. А Петя свою карточку в это время вставляет в другую дверь, ведущую в местную chamber of secrets, куда Вася допущен, а он - отнюдь.

Что произойдёт? Васина карточка пообщается с замком chamber'а, они обменяются честь по чести нужными данными и разойдутся, довольные друг другом. Вася зайдёт в подсобку, Петя пойдёт красть секреты.

Теоретически, решение-то на поверхности - надо, чтобы замок посылал карточке криптозаверенное сообщение, в какой именно двери он стоит, а карточка показывала его владельцу. Это у нас в HTTPS и происходит - имя сайта в адресной строке сравнивается с именем Subject в сертификате, если совпало - всё ок.

Теоретически-то да, но как это будет выглядеть на практике? "Вы пытаетесь открыть дверь в комнату 613, находящуюся по адресу такому-то, в третьем здании, на шестом этаже"? А кто это будет читать?

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

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

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

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

Вот такие пироги. Есть идеи?

P.S. Кстати, и недавняя загадка к проблеме невольной аутентификации имеет прямое отношение.