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

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

Если кто хочет повтыкать в детали сам - припадайте. "Leaf" сертификат со смарткарты не выкладываю из соображений приватности владельца, а правительственные - на здоровье.
cat_mucius: (Default)
У аутентификации по клиентским сертификатам есть множество ограничений, из-за которых она редко используется:
- общая сложность для понимания и настройки,
- сложность с управлением ключами, особенно когда юзеру надо ходить с нескольких устройств, с их обновлением,
- сложность с отзывом сертификатов, необходимость держать доступными точки 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. Ну, мои тебе соболезнования, приятель. :-))
cat_mucius: (Default)
Понакидал в технобложик своих постов из внутренней вики - авось широкой публике пригодятся:
  • про то, как удобно настроить раутинг для VPN-клиентов TMG, мир его памяти. С картинками!
  • про то, как опознавать на Tomcat юзеров из Active Directory, используя Kerberos и LDAP - фактически, очень подробное продолжение этого поста,
  • и про то, как то же самое можно делать, заменив Kerberos на сертификаты. На самом деле, заменять они друг друга не обязаны, могут и дополнять.
  • cat_mucius: (Default)
    Техническое: про Гугл, SAML и Keycloak.
    http://blog.mucius.tk/2017/04/google-as-saml-idp.html
    cat_mucius: (Default)
    Коллега порадовал сообщением, что Whatsapp безопаснее, чем SMS, поскольку сообщения в нём шифруются. Верно, шифруются, и юзерам даже дали возможность ключи сравнить (прочие скайпы до таких высот не дошли).

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

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

    А пока эти заверения означают не больше, чем "мамой клянёмся, мы не подсматриваем". Если даже законодательство не обязывает компанию обеспечивать органы специально проверченными дырками для "lawful interception", полагаться всерьёз на это слово после Сноудена, Lavabit, и так далее...

    Разумеется, к iMessage, скайпу и прочим вайберам это всё относится в той же мере.


    Вообще впечатляет, насколько при мощных успехах опен-сорса на многих фронтах, безрадостна ситуация на рынке мобильных аппликаций. Особенно касаемо мессенджеров - децентрализации ноль, открытости ноль, полная зависимость от малого числа компаний. Феодализм, как сказал Брюс Шнайер.
    cat_mucius: (Default)
    Поругаю для разнообразия Микрософт:

    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 решило проблему, но вашу же душу, благодетели!..
    cat_mucius: (Default)
    Случайно обнаружил, что при заходе на https://wirade.ru с мобильника браузер гневно отвергает SSL-сертификат от StartCom.
    Привинтил взамен новый от Let's Encrypt, должен обновляться автоматом каждые три месяца.

    Люди с разными нестандартными платформами - мобильными, десктопными - сделайте одолжение, скажите, не выкидывает ли вам браузер предупреждалку на тему SSL, certificates и всё такое при заходе на сайт.

    Со Старткомом же произошла пренеприятная история. Это израильский CA был куплен другим CA, китайским WoSign. Это, конечно, может случиться с каждым, но к ним была выдвинута претензия, что о сделке они не сообщили публично. Очевидно, для CA, единственным товаром которого является его репутация, это серьёзное дело. Дальше - хуже, WoSign поймали на том, что какое-то количество сертификатов они подписали более ранним числом, чем когда они были выданы реально - чтобы браузеры не ругались на сайты их клиентов из-за использования устаревшего алгоритма SHA-1. Это, конечно, с подвигами TrustWave ни в какое сравнение не идёт, но тем не менее, и WoSign-у, и Старткому был объявлен интердикт: разом Эппл, Гугл и Мозилла забанили их сертификаты.

    К большой моей печали, поскольку как раз эти двое были единственные, кто выдавал долгосрочные SSL-сертификаты забесплатно, то есть даром. Чем я с удовольствием пользовался, а теперь увы.

    (Впрочем, обе конторы старательно делают вид, что ничего не происходит, business as usual. Стартком пообещал выкатить новый корневой сертификат, но не выкатил.)

    Дополнительно меня напрягает, как именно этот бан был реализован. Не обычным выкидыванием корневого сертификата из доверенных или занесением его в untrusted (что, впрочем, Гуглу было бы проблемно реализовать: Chrome использует хранилища ключей Windows, а Микрософт к отлучению не присоединялся). А следующим образом: сертификаты, выданные до 21.10.2016 признаются легальными. А выданные позже - уже нет.

    Это спасает большинство клиентов этих CA, заплативших за свои сертификаты, но это означает, что эта запретительная логика реализована в коде самих браузеров (Firefox 51, Chrome 56) и юзер над ней не властен. То есть хозяин компьютера или айтишник компании не может решить своей волей, что его браузеры будут всё-таки этим CA доверять - за него решение приняли большие компании, и override не предусмотрен. Тенденция эта, на мой взгляд, скверная.
    cat_mucius: (Default)
    Товарищи френды, если у кого есть аккаунт на 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: отказали, да в общем-то и правильно - не продумал).
    cat_mucius: (Default)
    Накатал в технобложик о своих приключениях с load balancer'ом в FortiGate - авось другим бедолагам пригодится.

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

    Что ведёт к неприятному следствию - если мы хотим учитывать группы в правилах доступа (чего очень бы хотелось), то приходится либо:
    - Концентрировать все такие правила на VPN-гейте. Что просто не масштабируется и неудобно: надо, чтобы этот гейт знал все объекты в сети, к которым VPN-клиентам потребуется доступ. Во-первых, их может быть очень много, а во-вторых, это мешает нормальному распределению ответственности - вместо того, чтобы админ какого-то отдельного сегмента задавал правила на своём файерволле по своему разумению, он должен добиваться, чтобы их задал админ VPN-гейта. Хорошо, если это один и тот же чувак, а если разные?
    - Искать пути обхода - например, настроить гейт так, чтобы разным группам клиентов выдавались адреса из разных пулов. Тогда на дальнейших файерволлах можно эти пулы использовать как заменители групп. Что тоже не фонтан - не факт, что гейт такую возможность вообще поддерживает, да и опять таки излишняя зависимость между админами и неудобняк. А если группы между собой ещё и частично пересекаются?

    Хотелось бы иметь технологию, позволяющую разным файерволлам (в идеале - ещё и от разных производителей) распространять соседям информацию о подключённых VPN-клиентах, чтобы те могла строить свою политику о группах самостоятельно. Кто-нибудь знает о чём-то подобном? Вроде бы у Cisco есть что-то под названием TrustSec, но с их оборудованием мне работать как раз не доводилось. Интересно, есть ли такое у других вендоров? Какой-нибудь open-source проект?
    cat_mucius: (Default)
    А ведь используй Клинтон, её окружение и верхушка американской демпартии S/MIME или PGP с нормальной защитой ключей - и наверняка не было бы у них всех этих почтовых скандалов. Залезли бы фбрщики или злые хакеры на сервер - и нашли бы кучу мейлов с нечитаемым аттачментом smime.p7m. Всё.

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

    Паки и паки повторяю - не пренебрегайте шифрованием.
    cat_mucius: (Default)
    Мир стал бы немножечко уютней, если бы желающие соорудить очередной VPN-клиент (а говоря шире - любую шнягу для аутентификации, включая вебные) изначально поддерживали бы протокол EAP. Его великое преимущество в том, что проверку любых credentials и решение о допуске можно взять и переложить с VPN-гейта (вебсервера, терминал-сервера, чего угодно) на широкие плечи RADIUS - причём гейт/сервер нисколько не волновало бы, что из себя представляют эти credentials - будь то пароли, сертификаты, infocards, SAML tokens или ещё какая хрень.

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

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

    Сегодня подавляющее количество траффика из типичной внутренней сети в Интернет выходит по шифрованному HTTPS. Современный файерволл предоставляет две опции для его обработки:
    - либо отказаться от инспекции, разве что попытавшись проверить destination IP против заранее заданного списка (скажем, на файерволле заранее указано, какие адреса соответствуют *.windowsupdate.com),
    - либо устраивать SSL inspection, то есть "узаконенный" man-in-the-middle attack: подсовывать юзеру фальшивый сертификат, расшифровывать и проверять траффик.

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

    Возможна третья опция - неидеальная, но предоставляющая какой-то компромисс. Файерволл может проактивно тестировать заранее заданные HTTPS-сервисы, подключаясь на них самостоятельно. Это позволит задавать в правила, наряду с стандартными "source & destination IP, source & destination port" также: Subject сертификата, имя выдавшего его CA, его уровень (DV/OV/EV), валидность по времени, длину ключа и так далее. Если файерволл подключился к сервису и получил сертификат, отличающийся от ожидаемого - соединения из внутренней сети туды не допускаются и конец делу.

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

    Как вариант, тестирование может проводить не сам файерволл, а служба егойного производителя, от которой файерволл будет получать регулярные апдейты (см., например, FortiCloud).

    Кроме того, файерволл может проверять поле SNI в пакетах "Client Hello" исходящих SSL-соединений, чтобы убедиться, что клиенты пытаются подключиться к законному и проверенному сервису.

    Таким образом, и клиентская приватность сохраняется, и сисадмину больше уверенности, что траффик наружу легальный ходит (а не какой пакостный бот изнутри на свой C&C коннектится).
    К тому же, юзер уберегается от MitM-атак снаружи - он, допустим, не заметит, если mail.google.com внезапно предоставит сертификат от какого-нибудь странного ГУЦ, зато файерволл - таки да.

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

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

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

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

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

    Вангую, что в недалёком будущем мы станем свидетелями не одной утечки и взлома с участием персонала таких вот провайдеров всевозможных "... as a service". Потому что если чем-то можно злоупотребить - этим злоупотребят.
    cat_mucius: (Default)
    Нашёл недавно довольно интересную штуку:
    Положим, у нас есть сайт, использующий "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

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

    (Update: обнаружил, что и клиент Remote Desktop в Win7 тоже так умеет.)

    Почему это так интересно? А потому, что означает, вопреки популярному убеждению, что Kerberos можно использовать в Интернете - а не только в корпоративных сеточках.
    Read more... )
    cat_mucius: (Default)
    Неожиданное продолжение этой темы - принят новый российский закон (ФЗ-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.
    cat_mucius: (Default)
    Ответ на криптозагадочку, заданную здесь.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    P.S. Кстати, и недавняя загадка к проблеме невольной аутентификации имеет прямое отношение.
    cat_mucius: (Default)
    Пришла в голову одна идея, поцарила и скончалась, не выдержав столкновения с жестокой реальностью. Бедняжку жаль, поэтому хочется почтить её память, озадачив вас небольшой криптографической загадочкой.

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

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

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

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

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

    Есть тьма способов обходить сетевые фильтры путём шифрования и прятанья одних пакетов в других (SSH, VPN, Tor, I2P, etc.), но все они требуют активных действий со стороны читателей запрещённых сайтов. А что со своей стороны может сделать вебмастер?

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

    Блокировка может осуществляться 3-4 способами:
    1. по IP (точнее, по паре IP:порт). Видим, что пытаются обратиться на конкретный адрес - отвечаем вместо него страницей "мы приносим свои извинения, но хрен вам".
    2. по DNS - видим, что запрашивают имя запрещённого сайта, подсовываем левый IP с оной страницей.
    3. по HTTP-запросу (наиболее точный способ) - видим в заголовке адрес определённой страницы, блокируем.

    Это всё абсолютно тривиально, но не все знают, что можно и
    4. по HTTPS-запросу - видим адрес запрашиваемого сайта, блокируем.

    Почему, ведь HTTPS - он шифрованный? Верно, с одним исключением. Имя сайта (hostname) современные браузеры высылают всё-таки открытым текстом. Ради чего, это ведь нарушает принцип, ради которого HTTPS и придумывался? А вот догадайтесь. :-) Хинт: без этого возникает забавная техническая проблема курицы и яйца.

    Ваши версии?


    Таким образом, сайт строить нужно так, чтобы все 4 способа были бы для интернет-цензуры неприменимы. А для этого требуется несколько пересмотреть подход к сайтостроению. На протяжении двух десятилетий каждый вебмастер старался первым делом обзавестись каким-то легкозапоминаемым vanity URL: скажем, если он хостится у какого-то провайдера, то чтобы адрес был не http://provider.com/path/to/vasya или http://provider.com/~vasya, а http://vasya.provider.com. А ещё лучше - и вовсе скрыть всё лишнее: http://vasya.com/. Чем больше процент уникальной информации в адресе - тем лучше. А уж обзавестись собственным сервером, собственным IP, собственной сетью - ещё круче. Но и тем легче блокировать!

    Потому именно от этого и надо отказаться: не выступать гордо под собственным флагом, а напротив, прятаться за спиной гигантов. Использовать URL вида https://provider.com/vasya, обязательно с HTTPS на всех страницах. Да, это ударяет по запоминаемости, да, юзерам придётся держать в уме, что без https:// сайт не откроется. Но тогда всё, что сможет выцепить интернет-фильтр - это что обращение идёт на hostname провайдера и на IP провайдера, и если провайдер огромный и содержит десятки тысяч проектов (Гугл, Фейсбук, Windows Azure, Wordpress, etc.), то его блокировать цензуре выйдет себе дороже.

    И да, естественно! провайдер должен быть не российский.

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

    P.P.S. Да, если вы знаете примеры провайдеров, позволяющих создавать адреса такого вида - напишите, плиз. Насколько я знаю, Blogger (Blogspot) и Wordpress.com не позволяют, Google Sites - да.
    Page generated Jul. 27th, 2017 08:37 am
    Powered by Dreamwidth Studios