?

Log in

No account? Create an account
Кот Муций
19 September 2020 @ 01:12 am
Спросили меня насчёт интервью, которое дал украинскому сайту "Гордон" какой-то бизнесмен Михаил Талан, утверждающий, что российские спецслужбы рутинно проводят массовую "man-in-the-middle" атаку на TLS-соединения российских пользователей.


– Каким образом россиянам удалось вставить туда "посредника" и считывать зашифрованный трафик?
– Подсунув подменный SSL-сертификат в веб-браузер. Подчеркиваю: именно подменный, а не поддельный. SSL-сертификат – это технология аутентификации, которая, если вы открываете Google, говорит веб-браузеру: да, это точно Google. Подделка SSL-сертификата – это, по сути, базовая хакерская атака, а вот подмена – это базовая функция того, кто этот сертификат продает. Подмена доступна исключительно официальному органу, и делается это на основании запроса и, как правило, "для борьбы с терроризмом".
...
В головах у интернетчиков бытует мнение – поддельный SSL-сертификат не сработает. А я еще раз говорю: не поддельный, а подменный, и он выдается корневым центром сертификации по запросу государства для борьбы с терроризмом. Понимаете? Они опять "продают" идею борьбы с терроризмом. Они таким образом заставили всех выдать им сертификаты, но встала вторая проблема – как их встроить в трафик.


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

Чисто технически в этом ничего невероятного нет, о чём я и писал уже давно (1, 2) - государство действительно может добиться от CA такого сертификата, такую подделку действительно тяжело засечь, поскольку практически все поля в поддельном сертификате будут идентичные настоящему, кроме публичного ключа и его хэша. Смену сайтом публичного ключа можно засечь - см. HTTP Public Key Pinning - но она может произойти и по совершенно нормальным причинам, к тому же разные сервера, на которых хостится сайт, могут одновременно иметь разные сертификаты с разными ключами, да и использовал HPKP очень мало кто.

Но вот политически звучит это невероятно. То, что ключи американских центров сертификации есть у NSA, меня не удивит нисколько - но вот какой смысл им делиться ключами с Россией? Своё же собственное государство по головке не погладит за подобную работу на потенциального противника. Далее, даже если у фирмы, скажем, Digicert от российских денег в зобу дыханье спёрло и они решили продать ФСБ сертификат с включённым флагом "CA" - это означает для них страшнейшую игру с огнём, поскольку один доказанный случай MiTM-атаки с их помощью - и вся их репутация сгорает на корню, а репутация - это в принципе единственное, чем CA торгует, без неё он нафиг никому не нужен. А уж содействовать не просто каким-то очень выборочным атакам на определённых людей, а массовому перехвату в масштабах страны - это просто чистое безумие.

Конечно, вполне в возможностях российских спецслужб попросту украсть корневой или дочерний сертификат одного-двух западных CA - просто подкупив их служащих, к примеру. Сумели же американские / израильские подписать Stuxnet ключами легальных сертификатов для защиты програмного кода. Но опять же, для перехвата трафика условного Навального - это вполне годно. А вот если любой зарубежный сайт для российских пользователей внезапно окажется подписанным именно этими одним-двумя центрами - то это такое шило, которое в мешке не утаишь.

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

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

2. А вот второй: штука под названием cryptobinding / channel binding. Идея в следующем. Допустим, мы устанавливаем с сервером соединение по TLS, и затем запускаем с ним какой-то протокол аутентификации - скажем, Kerberos, NTLM или EAP. Пускай он использует обычные пароли. Но помимо зашифрованных паролей, мы с ним обмениваемся ещё и некоторыми контрольными суммами, удостоверяющими, что мы с сервером используем общие ключи для TLS - иными словами, и клиент, и сервер соединены прямой "трубой" TLS-соединения.
Если между нами вклинится перехватчик, пускай и с самым безупречным сертификатом, это уже будут две "трубы" - от клиента до перехватчика, и от перехватчика до сервера. Суммы не сойдутся и протокол аутентификации провалится.
В обычном IIS, включённым во всякую винду, эта фича существует под названием "Extended Protection for Authentication" и включается парой движений мышкой.

Ну и добавлю, что если бы массовый перехват происходил, то Талану было бы очень легко привести пример типа "зайдите на https://mail.google.com через российского провайдера и через украинского и сравните ключи". Пользу он этим принёс бы огромную, однако ж страшные глаза он делает, а конкретикой не балует. Самая крутая конктретика там такая:

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

Holy Mother of God. :-) Если я в фейсбуке на F5 нажму, то тоже получу две разные по содержанию ленты, алгоритм фейсбука так работает. :-)


- Американцы отменили 35 организациям SSL-сертификаты. Это невероятно. Я, признаться, не верил, что США отменят SSL-сертификат Федеральной службе безопасности РФ. Но они отменили. Зайдите на официальный сайт ФСБ или Кремля, например. Что вы видите рядом с адресной строкой этих сайтов?
– Надпись "Not secure".
– Во-о-от, а обычно рядом с адресом любого сайта стоит значок замочка, то есть трафик защищен. А теперь у официальных сайтов ФСБ и Кремля, например, трафик не зашифрован. То есть США отозвали сертификаты большинству сайтов, связанных с официальной российской властью. На мой взгляд, это беспрецедентная демонстрация того, на что готов пойти Вашингтон, если Москва не начнет вести себя нормально.


Грандиозно, только жаль, что никаких подтверждений тому, что какой-то CA отозвал сертификат для https://fsb.ru мне найти не удалось. :-) Оный сайт сейчас действительно доступен лишь по HTTP, но сложно поверить, что если бы это был результат отзыва, то во всём Интернете про это знал бы лишь один Талан.

Короче, гражданин трепло, выступающее перед падкой на алармистскую риторику аудиторией.
 
 
Current Music: Clutch - X-Ray Visions
 
 
Кот Муций
15 August 2020 @ 01:34 am
У Микрософта нашли очередную дыру, и не абы где, а в святая святых, в домен контроллере. В общем, патчим, товарищи, не ленимся.




Там, похоже, читают мой бложик: cтоило обругать Azure Firewall, как в нём появилась именно та фича, которой мне и не хватало. :-) То есть можно указать в качестве destination любое имя, которое резолвится DNS в IP-адрес или список адресов, и Firewall разрешит (ну или заблокирует) соединение на любой из этих адресов, независимо от аппликативного протокола.

Но есть некоторая разница с Фортигейтом - для этой фичи Микрософт требуют превратить Azure Firewall в DNS proxy и настоятельно рекомендуют указать его внутренний адрес в качестве DNS-резолвера для всей живности, что будет через него свой трафик пускать. Делается это для того, чтобы минимизировать ситуации, когда Firewall резолвит то же имя в один список IP-адресов, а клиент - в другой.

Тем не менее, пока эта фича в preview и работает скорее теоретически. В моём опыте, примерно две трети соединений блокировались файерволлом даже тогда, когда он сам же клиенту список IP и резолвил. Правда, у DNS-имени, с которым я экспериментил, был очень короткий TTL, секунд в десять. Ну, будем надеяться, к запуску в продакшен её доведут до ума.




В связи с этими делами, стал стучаться в башку такой вопрос: поле Host в HTTP и SNI в TLS вводили, конечно, не ради файерволлов, а чтобы можно было множество сайтов на один серверный IP вешать. Но тем не менее, получилось довольно удобно, что теперь файерволл, работающий в режиме explicit / transparent proxy, может их использовать для сверки со своими правилами:
- и правила эти можно сделать гораздо более точными, чем если иметь для принятия решения лишь пару destination IP & port;
- и файерволл теперь может самостоятельно новое соединение к цели открыть, согласно собственному DNS lookup, независимо от destination IP в пакете, пришедшему от клиента;
- и заодно серверный сертификат может сверить на соответствие.

Так может стоит эту практику на прочие аппликативные протоколы распространить? Ну скажем, на NTP, IMAP, SMTP. Прописывать в явном виде "авторскую интенцию" - DNS-имя, на которое открывается соединение или посылается запрос.

В наш-то век облачных сервисов, когда то же DNS-имя переводится тем же самым DNS-сервером в разные списки IP в ответ на разные запросы, причём интервал между этими разными ответами может измеряться секундами, с традиционным файерволлом пытаться ограничивать исходящий трафик - практически безнадёжная задача, проще сразу "destination = ALL" прописать.

Из-за того иногда приходится прибегать к разным уродливым костылям, чтобы разрешить нужный исходящий трафик, не разрешая всё на свете. Ну, скажем, нужно позволить посылать письма через smtp.googlemail.com. Но поскольку даже если на файерволле можно прописать этот FQDN, по прежнему вероятна ситуация, когда клиент резолвнет этот адрес в IP1, а файерволл - в IP2 (даже используя тот же DNS-сервер!) и заблокирует соединение, то приходится идти на следующий некрасивый трюк: прописывать на внутреннем DNS-сервере (используемый ими обоими) зону smtp.googlemail.com с постоянным ограниченным набором IP-адресов - а дальше надеяться, что Гугл их в обозримом времени будет поддерживать в рабочем состоянии.




С другой стороны, это мне-то, решающему задачу ограничения исходящего трафика, это было бы удобно. Но вообще-то, это огромный вопрос - должен ли сетевой протокол быть дружелюбным к файерволлу или же напротив, максимально недружелюбным к нему - и вопрос этот политический. Если мы исходим из того, что государственная цензура - зло (а я так и считаю), то напротив, протокол должен быть как более непрозрачен, чтобы затруднить жизнь Великому китайскому файерволлу, Роскомнадзору и их аналогам. И тенденция идёт как раз в этом направлении - см. Encrypted SNI.

Наверное, дело решится настройкой, позволяющей клиенту запускать соответствующий протокол как в firewall-friendly, так и в unfriendly режимах. Корпоративные сети будут использовать первый, частные юзеры - второй. Серверам, по идее, должно быть всё равно.




Технически этот Encrypted SNI представляет собой раздражающий костыль. Давайте посылать юзеру шифровальный ключ в сертификате, а чтобы никто не догадался, какой именно сертификат (и сайт) запрашивается - разместим ещё один ключ в DNS, и пускай клиент свой запрос этим ключом шифрует. Блин, а почему б тогда сам первый ключ в DNS не разместить? А потому, что если враги его подменят, то это будет game over, а так они разве что увидят, на какой сайт юзер лезет. Хорошо, а по DNS-запросам они это не поймут? Поймут, но вот если юзер будет обращаться к заранее известным надёжным DNS-серверам, расположенным за границей, и само соединение с ними шифровать по TLS... Ну хорошо, а если враги запретят с такими серверами соединяться?...

В общем, похоже, пока моё старое предложение располагать крамольный сайт так, чтобы по хостнейму опознать его было нельзя, релевантности не теряет.
 
 
Current Music: Deep Purple - Whoosh!
 
 
 
Кот Муций
23 May 2020 @ 12:45 am
Внезапно пригодился генератор ругательств шекспировской эпохи, который когда-то доставленный [personal profile] el_d в Удел. Я на него перенаправляю незаконные запросы к API.



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

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

Звучит клёво. Да только при первой же попытке это построить натыкаешься на вот такущий список исключений, который ты обязан реализовать - и в раутинге, и в фильтрации - и все они относятся к общению между этим микрософтовским продуктом, ASE, и другими микрософтовскими же сервисами в том же Ажуре, и всё это общение должно почему-то проходить через твою типа частную сеть. Причём список этот максимально недружелюбен - не во всякий файерволл его и вобьёшь. Хочешь просто указать IP-диапазоны? - а хрен тебе. Нет, на тебе стопиццот хостнеймов, причём их один и тот же DNS-сервер будет резолвить в разное время в разный список IP-адресов. Мало тебе? - на ещё и wildcard-хостнеймы, которые файерволлу вообще указать нельзя, тут transparent proxy нужен. И причём отделить трафик собственно ASE от трафика живущих в нём приложений нельзя по определению - всё из того же сабнета.

А не реализуешь по списку - ну пожалуйста, либо у тебя дыра в безопасности будет, либо наш замечательный ASE возьмёт и сломается, сам будешь виноват, дурень.

И то же самое с каждым ихним изобретением - к каждому прилагается список УРЛов, без регулярного общения с которыми оно помрёт, хорошего вам настроения.

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

Подозрение, что это делается с целью заставить использовать Azure Firewall, не добавляет желания всем этим пользоваться. Файерволл, кстати, хороший, с фичей transparent proxy, частично удолетворяющих моим мечтаниям. Но есть и раздражающий момент: указать ему хостнейм, чтобы он сам его перевёл в IP-адрес или список адресов, нельзя. Фортигейт умеет, а он нет. Точнее, умеет, но лишь для тех протоколов, что поддерживает его proxy - HTTP(S) и MSSQL. А для всех остальных шиш, вбивайте по IP.

Ye roguish sour-faced cutpurses!
 
 
Current Music: Pomplamoose - Happy Together
 
 
Кот Муций
07 March 2020 @ 11:55 pm
Задумался вот. Допустим, пишем мы вебсайт, к которому есть такое интересное требование - non-repudiation. То есть если юзер выполняет на нём некое действие - он не должен иметь возможности отрицать, что он его совершил, даже если сайт вместе со своей датабазою взломан вдребезги и пополам.

На первый взгляд, всё довольно тривиально - даём юзеру смарт-карту с секретным ключом, им подписывается тело любого POST- или PUT-запроса на сайт. Запросы сохраняются в лог и хранятся там, пока релевантность не отпадёт.

На второй - немного сложнее. Насколько я понимаю, не существует никакой возможности обращаться к ключам на смарткартах, TPM, Windows store и т.д. из бегущего в браузере JavaScript-а. И по хорошей причине - такая возможность дала бы недобросовестным сайтам выполнять операции с юзерскими ключами (подписывать или расшифровывать что-то) без ведома юзера. Даже если юзер должен разрешить доступ к ключу введением кода - ему неоткуда знать, как именно ключ используется, приходится полагаться на приложение.

Существует "Web Cryptography API", но он, насколько я понимаю, не позволяет обращаться к смарткартам и прочим устройствам PKCS#11 - он позволяет генерить ключи прямо в браузере и хранить их в local storage и т.д. Защитой, необходимой для non-repudiation, такие ключи не обладают.

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

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



Ну а для контента, выдаваемого сервером, организовать non-repudiation не в пример легче, и не дорого - генерим неизвлекаемый ключ в каком-нибудь online HSM, скажем, в том же Azure Key Vault, и подписываем отсылаемые файлы.



То, что смарт-карта не должна позволять экспорт ключей, тривиально - а вот есть ли смарт-карты, не разрешающие также и импорт? Чтобы ключ можно было бы сгенерировать лишь в ней, и быть уверенным, что он существует лишь в единственном эксземпляре?
Это свойство и для аутентификации полезно, но для non-repudiation - особенно.



Даже и в этом случае хитрый юзер мог бы отпираться "я не я и корова не моя" - мало ли что в сертификате написано, может, админ CA сам его себе на моё имя выписал. А смарткарту и потерять можно. Способ это побороть - заставить расписаться (ручкой по бумажке) при получении смарткарты, с указанием thumbprint сертификата - для каждого ключа уникального. Ну или использовать такие карты, от которых особо не пооткрещиваешься, типа нового израильского "биометрического" удостоверения личности - хоть там косяков и полно.
 
 
Current Music: Машина времени - Рыбак рыбака
 
 
 
Кот Муций
24 February 2020 @ 10:57 am
Azure Key Vault - очей разочарованье. Читаешь - вау, круто, хардверная защита, неэкспортируемые ключи, файерволлы, managed identities, access control!
Вникаешь в детали - и тут же выясняется, что для SSL защита ключей нерелевантна. Потому что то, что реально происходит, это:
- сертификаты с секретными ключами просто сохраняются где-то на диске,
- ажурные виртуалки, на которых бегают App Services или App Gateways, попросту переписывают их себе - вместе с ключами - и используют локально.

Таким образом:
- HSM вообще не при делах,
- да и импортировать ключ в этот HSM тоже нельзя - только сгенерировать внутри (поправка: не точно, но для того требуется исходный HSM, так что один хрен),
- да и просто сохраняемый на диске software-protected key тоже экспортируемым быть обязан - иначе для SSL он неприменим. То есть любой, имеющий доступ к Key Vault, его скачает без проблем.

Умом, впрочем, и так понимаешь, что не могёт того быть, чтобы для любой новой SSL-сессии к HSM обращаться - а всё одно обидно.
 
 
Current Music: Fairport Convention - Night-Time Girl
 
 
 
Кот Муций
30 December 2019 @ 07:30 pm
В продолжение мечтаний:

Вот интересно, существует ли на белом свете сетевая хреновина типа файерволла, умеющая обрабатывать исходящий HTTPS-трафик следующим образом:
1. Ответить на попытку установить TCP-соединение на любой адрес - от имени этого адреса.
2. Получить от юзера пакет "Client Hello", прочесть оттуда хостнейм из поля SNI - сегодня его посылают практически все.
3. Проверить по DNS, на какие IP-адреса резолвится этот хостнейм.
4. И лишь после этого искать подходящую firewall policy и проверять:
  • соответствует ли хостнейм из SNI тому адресу, на который было запрошено соединение,
  • или тому, что указано как destination в этой полиси - а это могут быть как и диапазоны адресов (в таком случае надо проверить, попадает ли адрес, используемый юзером - или же адреса, полученные от DNS - в эти диапазоны), или же текстовые правила типа регулярных выражений (тогда надо на них проверить хостнейм),
  • соответствует ли сертификат, посланный сервером, этому хостнейму - по полям CN и SAN.

    Ну и в качестве вишенки на торте, чтобы проверяла полученный сертификат по ограниченному списку CA и чтоб deep inspection умела делать. Ну ещё и заголовками HTTP манипулировала, мечтать так мечтать.

    Фортигейтов Explicit Proxy умеет многое из этого, но это прокси. Клиентов надо настраивать к нему обращаться. Но вообще-то без малого 2020-й год на дворе, было бы неплохо уметь делать умную обработку трафика и прозрачным для юзеров образом.

    Если нет такого - так выпьем же за то, чтобы в наступающем новом году!..
  •  
     
    Current Music: Dropkick Murphys - The Season's Upon Us
     
     
     
    Кот Муций
    07 December 2018 @ 02:37 am
    Давно я Микрософт не ругал.

    Понадобилось тут прокинуть site-to-site IPsec-туннель между FortiGate и Windows-сервером. Документации по такому сценарию нагуглилось ноль, пришлось действовать методом проб и ошибок. Благодаря сниффингу, дебаггингу и молитвам к известной матери построить таки получилось - см. описание в технобложике. Но до чего ж я в процессе пыли нажрался, и всё благодаря замечательным качествам Windows RRAS (Routing & Remote Access Service).

    Сюрприз первый - ограничить принимаемые сертификаты от второй стороны только выписанными определённым CA нельзя. Можно жмякнуть по галке "Verify Name and Usage attributes of the server's certificate", и на этом всё. То есть да, будет проверено, что в сертификате значится хостнейм, к которому мы обращаемся, что сертификат не протух и что он подписан валидным CA. Да только этих валидных CA на любом Windows - несколько десятков!

    То есть если между двумя сторонами сидит хакер, который может направить трафик на адрес Фортигейта на свой сервер (через DNS ли, через раутинг ли) - то он может как нефиг делать получить на этот хостнейм сертификат от LetsEncrypt, с их-то смехотворной верификацией. И затем выдавать себя за Фортигейт. Подключиться к Фортигейту от имени RRAS ему не выйдет - Фортигейт-то как раз проверяет, какой CA удостоверил вторую сторону. Но если обе стороны - Windows, то вот вам полноценный рецепт на man-in-the-middle.

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

    (Справедливости ради, Windows позволяет использовать поверх IPsec протокол EAP, а вот там-то CA ограничивать можно. Но:
  • это усложняет инфраструктуру - нужен RADIUS (и проверяется сертификат именно RADIUS, а не VPN-гейта)
  • документации по такому использованию EAP у Фортинета примерно ноль, но в этом не Микрософт виноват,
  • это поверх - уже после аутентификации IPsec; проверяет оно юзера, и клиентский сертификат должен сидеть в профиле юзера. Как это заставить работать с автоматическим подключением RRAS? Может, если запустить certmgr.msc под SYSTEM и импортировать туды, то и выгорит...
    В общем, дикие траблы. Скорее всего, не взлетит. Да и точно ли это устраняет MiTM?)

    Этого можно было бы легко избежать, попросту перейдя с сертификатов на pre-shared keys, однако тут нас ждёт сюрприз второй - это работает примерно с десятого раза на двадцатый. Подозреваю баг. Девять раз получаешь "authentication failed", на десятый неожиданно подключаешься. Забиваешь PSK заново - сразу подключаешься; если отключишься, то по новой. Причём, похоже, работает только если сессию инициирует Фортигейт.

    Сюрприз третий - назначить статический адрес диал-ап интерфейсу нельзя, настройки игнорируются. Because fuck you. В какой-то момент получилось через "netsh interface ipv4 add address", потом снова обломись.

    Сюрприз четвёртый - банальный forwarding между LAN и туннелем раз работает, а раз нет. Почему - понять не удалось.

    В общем - если рассудок и жизнь дороги вам, держитесь подальше от торфяных болот.
  •  
     
    Current Music: Dierks Bentley - What Was I Thinkin'?
     
     
    Кот Муций
    24 November 2018 @ 03:33 am
    Настраивал давеча в одной сеточке синхронизацию часов и был поражён, внезапно обнаружив, что в il.pool.ntp.org не осталось ни одного IP-адреса. Совсем недавно была парочка, а теперь всё.

    В Израиле публичных NTP-серверов не дофига. Попытался использовать сервер Israel Internet Association, timeserver.iix.net.il - но и тут вышел облом. Он, похоже, лишь израильские IP обслуживает - а у моей сеточки, так уж вышло, они значатся как зарубежные. Плюнул и пошёл тянуть время с иностранных серверов.

    Всё-таки, мне кажется, должен быть какой-то минимум сетевых служб, которое приличное государство должно поддерживать для своих жителей - без тоталитарных попыток заставить пользоваться только ими, и без дурацких попыток ограничить доступ к ним лишь определённым сетям. Я бы в перечень включил DNS, NTP, e-mail и службу аутентификации, IdP.

    Всё ж таки ситуация, когда огромное количество организаций, включая государственные, полагаются на гугловский DNS 8.8.8.8 как на главный и зачастую единственный источник, нездоровая.
    Tags:
     
     
    Current Music: Bustan Abraham - Canaan
     
     
     
    Кот Муций
    23 November 2018 @ 03:50 am
    Скажите, мне одному кажется, что схема верификации, которую использует LetsEncrypt - это издевательство над логикой?

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

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

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

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

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

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

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

    Поразительно, сколько админов в Сети радостно пишут: сертификаты! бесплатно! бежим брать! - совершенно не задаваясь вопросом, что именно те сертификаты удостоверяют. Бесплатный сыр удивительно эффективно отключает мозги.
     
     
    Current Music: Moonspell - 1755
     
     
    Кот Муций
    10 November 2018 @ 02:56 pm
    Зашёл почитать, что новенького есть в новой версии шифровального протокола TLS, в девичестве SSL (которая скоро будет использоваться всякий раз, когда мы жмём на линк с https:// и во многих, многих других случаях) - и был крайне сильно шокирован. Прямо в RFC, официальном документе, описывающем протокол, открытым текстом признаётся, что он подвержен replay attack, и что борьба с этим - ответственность разработчиков серверного приложения: вот вы, мол, и постройте систему так, чтобы это было неважно.

    О чём вообще речь?Collapse )
    Почему это возможно в новой версии TLS?Collapse )
    Что предлагается?Collapse )
    Почему это скверная идея?Collapse )
    Частный случайCollapse )

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

    P.S. Полезные ссылочки: 1, 2, 3.
     
     
    Current Music: Moonspell - Desastre