cat_mucius

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

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 решило проблему, но вашу же душу, благодетели!..

Current Music: Flogging Molly - The Worst Day Since Yesterday
Crossposts: http://cat-mucius.livejournal.com/50962.html

Случайно обнаружил, что при заходе на 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 не предусмотрен. Тенденция эта, на мой взгляд, скверная.

Current Music: Derek Sherinian - Axis Of Evil
Crossposts: http://cat-mucius.livejournal.com/50912.html

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

Но увы.

Current Music: Alan Parsons - Tales Of Mystery And Imagination
Crossposts: http://cat-mucius.livejournal.com/47691.html

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

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

Current Music: Nautilus Pompilius - Морской змей
Crossposts: http://cat-mucius.livejournal.com/47563.html

Просто мысля, чтоб не потерялась:

Сегодня подавляющее количество траффика из типичной внутренней сети в Интернет выходит по шифрованному 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 внезапно предоставит сертификат от какого-нибудь странного ГУЦ, зато файерволл - таки да.

Интересно, изобретён ли уже этот велосипед?

Current Music: Deep Purple - Flight Of The Rat
Crossposts: http://cat-mucius.livejournal.com/47140.html

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

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

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

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

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

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

Current Music: Opeth - The Devil's Orchard
Crossposts: http://cat-mucius.livejournal.com/46917.html

Нашёл недавно довольно интересную штуку:
Положим, у нас есть сайт, использующий "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... )

Current Music: Flogging Molly - Every dog has its day
Crossposts: http://cat-mucius.livejournal.com/46410.html

Вот какой бы вывод вы ожидали увидеть, запустив такую простенькую 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();
}

Жизнь, натурально, прекрасна и удивительна.

Current Music: Guns & Roses - Nightrain
Crossposts: http://cat-mucius.livejournal.com/44570.html

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

Называется она STONITH и расшифровывается так: Shoot The Other Node In The Head.

Current Music: Molly Hatchet - Flirtin' With Disaster
Crossposts: http://cat-mucius.livejournal.com/41562.html

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

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

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

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

( Но что если... )

Current Music: Lene Marlin - Sitting Down Here
Crossposts: http://cat-mucius.livejournal.com/41390.html

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

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

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

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

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

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

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

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

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

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

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

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

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

Current Music: Threshold - March of Progress
Crossposts: http://cat-mucius.livejournal.com/41100.html

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

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

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

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

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

Current Music: Zac Brown Band - It's Not OK
Crossposts: http://cat-mucius.livejournal.com/40919.html

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 - да.

Current Music: Paddy Reilly - Come out you Black and Tans
Crossposts: http://cat-mucius.livejournal.com/38875.html

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

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

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

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

Current Music: Sheryl Crow - Shotgun
Crossposts: http://cat-mucius.livejournal.com/35395.html

Безопасность, разное.

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 ничем не поможет, б.) степень беспарольности, которую даёт Керберос, будучи применённой вне родной сети, админов может и напрягать.

Current Music: Skyclad - The Great Brain Robbery
Crossposts: http://cat-mucius.livejournal.com/34800.html

Прочёл давеча совершенно сногсшибательную штуку: группа из Беркли сумела построить систему аутентификации на основе электроэнцефалограмм. То есть буквально так: компьютер способен опознать юзера с помощью мысли.

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

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

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

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

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

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

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

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

Update2: вот тут можно не только узнать, что игралось, но и послушать, если кому вдруг любопытно.

Current Music: Skyclad - Thinking Allowed?
Crossposts: http://cat-mucius.livejournal.com/31799.html

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

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

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

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

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

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

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

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

Current Music: Shadow Gallery - Encrypted
Crossposts: http://cat-mucius.livejournal.com/31594.html

Фига в кармане, криптографическая версия:

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

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

Так. Сурово. Но ежели провайдер таким законом недоволен, то есть у него и обходной путь. Если грамота такая предъявлена, то говорить о ней нельзя. Но вот ежели никто её не приносил - то сказать о том закон не запрещает! А уж не сказать - так тем более.

Поэтому делается просто - каждый божий день провайдер берёт и сообщает принародно: сегодня подслушку не заказывали! А если вдруг не сообщит - делайте выводы, граждане.

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

Хорошо, а если оные слуги возьмут да и заставят провайдера таких объявлений на год вперёд наштамповать с подписями, да и будут сами их вывешивать? И на то способ придуман: в сообщения заголовки сегодняшних газет пихать. Предугадать, что будет в газетах наперёд, даже правительству трудно.

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

http://en.wikipedia.org/wiki/Warrant_canary
http://www.rsync.net/resources/notices/canary.txt

Current Music: Enter the Haggis - Cynical
Crossposts: http://cat-mucius.livejournal.com/30828.html

Криптографическая атака, описанная здесь, конечно, впечатляет, но я думаю, что ахиллесова пята SSL и других протоколов, основанных на инфраструктуре открытых ключей (PKI), вовсе не в криптографии.
( Кому мы доверяем? )
( А стоит ли? )
( Так что делать? )

P.S. Ну и напоследок. Пару лет назад была история с иранским хакером, который взломал итальянскую фирму, перепродающую сертификаты Comodo, и сумел подписать ключом Comodo сертификаты для https://mail.google.com, https://login.yahoo.com, https://addons.mozilla.org и ещё к нескольким сайтам. Внимание обсуждающих тогда сосредоточилось, естественно, на подробностях взлома, да на том, вправду ли взломал или блеф (не блеф), да одиночка ли это, или иранское правительство (которому такой взлом мог и вправду быть весьма полезен).

Между тем, наиболее тревожным мне кажется ( совсем другой аспект... )

Current Music: Sepultura - Roots
Crossposts: http://cat-mucius.livejournal.com/30664.html

Что-то никто, кроме

yigal-s, над вопросом про сертификаты думать не захотел. :-)
Ладно, просто так расскажу. Интересны они вот чем: один из них настоящий. Другой - поддельный. А подпись у них одинакова.
( Краткая напоминалка )
( Амбула )
( Что могло бы выйти )
( Контрмеры )
Вот какая неприятность может произойти всего-то из того, что хэш-функция для двух input’ов выдала один output. :-)

( Выводы )

Current Music: Dropkick Murphys - Going Out In Style
Crossposts: http://cat-mucius.livejournal.com/30065.html

Profile

cat_mucius

June 2025

S	M	T	W	T	F	S
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

Syndicate

Page Summary

Style Credit

Style: Neutral Good for Practicality by timeasmymeasure

Expand Cut Tags

No cut tags

Page generated Jun. 16th, 2025 11:42 am

Entries tagged with computing

(no subject)

(no subject)

Бесполезные жалобы и пустые мечтанья

(no subject)

(no subject)

(no subject)

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

(no subject)

(no subject)

(no subject)

Involuntary authentication и распознание объектов

(no subject)

Как затруднить жизнь цензуре

(no subject)

(no subject)

(no subject)

(no subject)

(no subject)

Roots, bloody roots

(no subject)

Profile

June 2025

Syndicate

Most Popular Tags

Page Summary

Style Credit

Expand Cut Tags