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)
    Коллега порадовал сообщением, что 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)
    Мир стал бы немножечко уютней, если бы желающие соорудить очередной 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)
    Вот какой бы вывод вы ожидали увидеть, запустив такую простенькую java-програмку на винде?
    public static void main(String[] args)
    {
        long first;
        long next;
    				
        first = System.currentTimeMillis();
        while (true)
        {
            next = System.currentTimeMillis();
            if (first != next)
                break;
        }
    				
        System.out.println("Difference: " + (next - first));
    }
    


    А такую?
    public static void main(String[] args)
    {
        long first;
        long next;
    		
        Thread t = new Thread()
        {
            public void run()
            {
                try
                {
                    Thread.sleep(Integer.MAX_VALUE);
                } catch (InterruptedException e) {}
            }
        };
        t.start();
    		
        first = System.currentTimeMillis();
        while (true)
        {
            next = System.currentTimeMillis();
            if (first != next)
                break;
        }
    				
        System.out.println("Difference: " + (next - first));
        t.interrupt();
    }
    


    Жизнь, натурально, прекрасна и удивительна.
    cat_mucius: (Default)
    Узнал сегодня о существовании технологии для автоматического разрешения конфликтов в серверных кластерах - когда, скажем, с какими-то из участников пропадает контакт и есть опасение, что они сейчас искорёжат общие данные. Особенно эффектно она работает в ситуациях типа split-brain, когда кластер распадается на две равные части, каждая из которых считает главной себя.

    Называется она STONITH и расшифровывается так: Shoot The Other Node In The Head.
    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 - да.
    cat_mucius: (Default)
    Развлекаюсь - научился авторизироваться в ЖЖ по отпечатку пальца. :-)

    Как это работает?
    Удолетворить любопытство )

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

    Что б ещё наворотить? :-)
    cat_mucius: (Default)
    Безопасность, разное.

    1. В Windows 8 появилась такая штука: возможность логиниться с "microsoft account" a.k.a Live ID. Великолепный ход. С одной стороны, юзеру это реально удобно: один аккаунт для массы всего. С другой, юзера ко всей микрософтовской экосистеме привязывает ещё крепче. С третьей, от потрёпаной юзерской privacy оттяпали ещё один солидный кус. А с четвёртой, впервые ключи к миллионам личных компьютеров (а также хранимым на них паролям к другим ресурсам и приватным ключам от сертификатов и инфокарт) передаются - совершенно легально и добровольно - на хранение напрямую доброй корпорации Microsoft.

    Причём для некоторых сценариев даже неважно, к примеру, хранит ли Микрософт пароли в криптованном виде и может ли их расшифровать: кто подтверждающий токен выдаёт, тот систему и контролирует, извините... Так что пользоваться не советую, мнээ, не советую. Съедят. Стоит лишь захотеть съесть, конечно.

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

    (Кстати. Я сейчас провёл несколько часов в попытках найти какую-то нормальную документацию по этому делу - message flows, диаграммы, описание протоколов и криптоопераций. Не нашёл ни черта - ни через гугл, ни на MSDN, ни на Technet. Скажите, это я дурак и параноик, или оно действительно нигде не опубликовано? Выглядит это очень странно, учитывая, что очень подробная информация по Керберосу, или PKI, или инфокартам, или ADFS находится на том же Технете с полпинка).

    Полезно рассмотреть с этой точки зрения также Azure ACS. Вкратце идея: допустим, у нас есть сайт, на который мы хотим пускать юзеров - но не заставляя их заводить очередной местный аккаунт, а позволяя логиниться с существующими: от Гугла, Твиттера, Фейсбука, того же Микрософта. Но для этого надо налаживать траст между сайтом и гуглом-твиттером, надо, чтобы сайт умел использовать протоколы всех перечисленных. А они разные. Приходит Микрософт и говорит: дорогой вебмастер, не волнуйся! Используй нашу замечательную службу-посредник ACS, наладь траст только с ней - а уж она с гуглами-фейсбуками сама договорится.

    Чтож, замечательно. Это реально удобно. Одно но: это значит, что доступ к сайту контролирует не юзер, и даже не identity provider, которому юзер выбрал доверять - а Микрософт. И к данным юзера на сайте Микрософт при желании добирается как нефиг делать, безо всякой нужды знать его пароли.


    2. Без связи с предыдущим. Читаю очередную статью и в который раз натыкаюсь: Kerberos, мол, замечательный протокол, но вне корпоративных сетей неприменим, поскольку, дескать, какой же админ решится KDC в интернет обнажить беззащитным 88-м портом? Вот, думаю: а почему бы нет, собственно? Чем это он так уязвим, что ADFS выставлять в Сеть можно, а его нет? Шифрование на месте по определению, на то и Цербер. DoS? Вроде нет.

    (Вообще интересно: а насколько реально опасно domain controllers целиком поместить в Сеть, если провести нормальный hardening, поубирать всё лишнее, типа NTLM, включить IPsec где можно? Много работы, но и результат может быть стоящий).

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

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

    Интересно, что в отличие от паролей и криптоключей, “отпирающая” мысль не обязана быть секретом. Она не обязана быть воспроизведением какой-нибудь кодовой фразы – можно петь про себя, к примеру. Или представлять себе картинку. Или сосредоточиться на тактильных ощущениях. Мысль может быть глубоко частного характера, а может быть доступной любому - например, когда участники испытаний просто сосредотачивались на своём дыхании, на вероятности правильно соотнести энцефалограмму с её “хозяином” это сказывалось не хуже, чем в случаях, когда их просили думать что-то сугубо личное. Можно шевелить ушами, а можно вспоминать счастливейший миг своей жизни, мысленно произнося “eXpect0 p@tronum!

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

    Должен сказать, что если это прикол, то я купился полностью. Впрочем, для прикола он как-то чересчур малоабсурден – масса народу перепечала сообщение без всяких опасений, журнал “Хакер”, к примеру. :-) Наушники с сенсором существуют на самом деле, в любом случае.

    Но даже если это розыгрыш, всё равно интересно подумать, насколько безопасна была бы такая схема. Я пока вижу несколько слабых мест:
    Read more... )
    Так что полагаться на ЭЭГ как на основной метод аутентификации, на мой взгляд, нельзя. Иное дело, что в качестве дополнительной меры защиты к паролю или к смарт-карте с криптоключом она может быть вполне полезна. К тому же по сравнению с прочей биометрией у неё есть то неоспоримое приемущество, что в случае чего придумать новую мысль-ключ несравненно проще, чем отрастить новую сетчатку или отпечаток пальца. :-)

    Эх, жалко будет, если розыгрыш – я уж отчётливо представил себе, как устанавливаю расширение схемы Active Directory, добавляющее к каждому объекту класса user объект класса pensieve. :-)

    P.S. Собираюсь сегодня на концерт Amorphis – френды, ещё кто-то идёт?

    Update: отменный был концерт, музыканты молодцы. После неудачного экспириенса с Symphony X меня преследовали печальные мысли, уж не устарел ли я для металла. Аморфис доказали: нет, не устарел. :-)

    Update2: вот тут можно не только узнать, что игралось, но и послушать, если кому вдруг любопытно.
    cat_mucius: (Default)
    Продолжая тему: тут я говорил о том, как частный хакер или группа может обойти безопасность SSL и других протоколов, основанных на наследовании доверия к криптоключам.

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

    Причём вполне возможно, что получить такую подпись от CA спецслужба может методом безупречно легальным: каким-нибудь судебным ордером, обязующим оказывать содействие. Впрочем, я бы не стал особо сомневаться, что и в неофициальном порядке вряд ли Verisign откажется помочь NSA, а израильский StarCom - ШАБАКу.

    Излишне говорить, что у государств также и наибольшие возможности по перехвату траффика и проведению "man-in-the-middle"-атак.

    Авторы этой статьи задались вопросом, как же можно защитить юзера от спецслужбистского любопытства, и предложили решение - очень частичное, но хоть какую-то дополнительную защиту предлагающее. Они написали плагин к Firefox под названием CertLock, действующий по такой логике )

    Наиболее опасным из государственных противников оказываются при таком раскладе сюрприз, сюрприз! )

    Но в общем и в целом решения нет.

    Есть, правда, и хорошая сторона в этом деле: если государство или ещё кто-то любопытный использовал фальшивый сертификат, подписанный известным CA, и это удалось обнаружить - то сам факт подделки опровергнуть практически невозможно. Если удалось такой сертификат выцепить - то CA не сможет отрицать свою подпись, а значит, есть нехилый шанс на всесетевой скандал и очень болезненный удар по репутации этого CA. Мало кому захочется доверяться честному слову конторы, пойманной за откровенным предательством доверия.
    Page generated Sep. 26th, 2017 05:56 pm
    Powered by Dreamwidth Studios