dxdt.ru: занимательный интернет-журнал

Как я уже упоминал, для нового выпуска “Доменных имён“, посвящённого истории Интернета, мы с Артемием Ломовым написали статью “Сценарии конца Интернета“. Сейчас статья доступна на сайте журнала, в PDF, рекомендую. Небольшая цитата:

Некоторые умные люди небезосновательно утверждают, что вероятность любого события тождественно равна нулю до его наступления и тождественно равна единице – после. Например, почти ровно 100 лет тому назад, в первой половине апреля 1912-го, вероятность гибели «Титаника» как раз оценивалась всеми здравомыслящими людьми как нулевая. Любое пророчество о том, что первый же рейс станет последним для непотопляемого лайнера, не могло быть воспринято иначе, чем инфернальный бред. Однако все мы хорошо знаем, что случилось дальше.

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

Да, текст, местами, художественный, но некоторые из упомянутых в статье сценариев уже просматриваются в реальности. Итак, вот, ещё раз, ссылка на PDF.

Тут Артемий Ломов сделал специальную страницу, имитирующую медленную загрузку элементов в браузер – можно вживую посмотреть, как отрисовываются разные блоки и “применяются” стили. Страница находится на сайте WebHiTech-а.

Специальная система приёма заявок на новые домены верхнего уровня у ICANN окончательно сломалась на день космонавтики, 12 апреля. С тех пор ICANN регулярно выпускает бюрократические уведомления, содержание которых сводится к следующему: “всё в порядке, ничего не потеряно, систему чинят, и вот-вот откроют обратно”. Впрочем, пока что прошло чуть более двух недель. Да. Казалось бы.

А с другой стороны, интереснее такая интерпретация: разработанная по заказу ICANN система настолько некачественная, что восстановление после сбоя уже заняло больше двух недель. Это как же нужно было спроектировать программное обеспечение, чтобы достичь такого эффекта? При этом в корпорации, контролирующей распределение адресного пространства всего Интернета, управление проектами налажено так “замечательно”, что ICANN даже не может уверенно прогнозировать время восстановления после сбоя. В общем, абсурд там какой-то с этими New gTLD, по всем фронтам.

Начался приём работ на конкурс WebHiTech-2012. В этом году заявки принимаются по новой схеме, качество каждой оценивается жюри уже на этапе отбора. Подать заявку можно на сайте конкурса.

Как известно, почтовые серверы, принимающие почту для адресов заданного домена, обозначаются при помощи MX-записей. Я собрал значения этих записей со всех делегированных и доступных в DNS доменов .RU (по состоянию на 15.04.12). Собственно, интересно было посмотреть, как используются сервисы для доменов от “Яндекса” и Google (с хостерами и так всё ясно).

Итак, “Яндекс” (“Почта для домена”) предлагает установить в качестве значения MX-записи – mx.yandex.ru. То есть, можно предположить, что если у домена такая MX-запись, то, с большой вероятностью, этот домен используется для яндексовского почтового сервиса. Таких доменов удалось обнаружить 96201.

Google для своих Google Apps предлагает список из пяти почтовых серверов, все они встречаются сравнимое число раз, я взял в качестве показателя самый приоритетный (и самый распространённый) – aspmx.l.google.com. Такую запись удалось обнаружить для 97226 доменов.

То есть, примерно поровну. И примерно 96201+97226=193427 доменов второго уровня .ru используют сервисы электронной почты от поисковых систем. Впрочем, это всего лишь ~5% от общего числа зарегистрированных доменов. Мало. Понятно, что подсчёт MX-записей даёт несколько размытую картину, так как администраторы доменов нередко настраивают DNS с ошибками. Но, тем не менее, показатели информативные.

Дефект (скорее, уязвимость) в интерфейсе приёма заявок на New gTLD ICANN признала 12 апреля, хотя, подтверждают, что сообщения о проблемах от пользователей поступали с 19 марта. Сегодня – 14 апреля, и пока что ICANN, в своём стиле, только обещает 16 апреля сообщить о том, смогут ли они возобновить приём заявок 17 апреля.

Вчитайтесь: через двое суток после аварии, ICANN, на полном серьёзе, выпускает официальное сообщение о том, что ещё через два дня опубликуют очередное сообщение, в котором будет уведомление о поступлении следующего сообщения. Это рафинированный образец бюрократии в действии.

New gTLD – очень шумное начинание. Одно из самых шумных с момента создания ICANN. Понятно, что сломать, в принципе, могут всё что угодно. Но, в случае с закрытым сервисом ICANN, списывать очки на этот бесспорный момент – очень непросто. Кроме того, не факт, что там была какая-то сложная и серьёзная причина для сбоя, вполне вероятно, что просто тривиальная ошибка программиста, вылезшая в “боевой” продукт по причине отсутствия аудита качества.

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

Впрочем, посмотрим, как оно повернётся.

Конкурс WebHiTech в 2012 году планируем проводить в новом формате. Старт приёма заявок – на РИФе, некоторые подробности – в официальном сообщении.

Ещё немного Интернета. Вот “Битрикс” с шумом запускает проект bitrix24.ru. Конечно, “облачный”. Позиционируют как корпоративный интранет. Естественно, всякое у них написано про то, как обеспечивают безопасность, что, мол, только по https, все дела. Цитата с сайта: “Безопасность вашей информации превыше всего!”. И, без сомнения, для корпоративного интранета безопасность действительно важна. Особенно, если какая-то компания удумает держать интранет в “облаке”, под “Битриксом”. Судя по всему, вертится проект на амазоновском EC2.

Но я о другом. Идём на https://bitrix24.ru/ и – любуемся на кривой самоподписанный сертификат, который отдаёт нам сервер:

Issuer: E = test@email.address; CN = Bitrix; OU = Bitrix R&D; O = Bitrix; L = Kaliningrad; ST = Moscow; C = RU;
Subject: E = test@email.address; CN = Bitrix; OU = Bitrix R&D; O = Bitrix; L = Kaliningrad; ST = Moscow; C = RU;

Тот же сертификат отдаёт www1.bitrix24.ru. При этом у проекта есть сертификат для *.bitrix24.ru – его отдают другие их веб-серверы.

А благодаря смелым настройкам DNS “Битрикс24″, можно открывать “сайт” под любым выдуманным (несуществующим) адресом третьего уровня внутри bitrix24.ru, например, http://alskdjfhg.bitrix24.ru/, и наблюдать страницу-заглушку, которая, судя по тексту, обозначает временную недоступность сервиса в целом. Поведение, очевидно, совершенно некорректное. Проявив чуть больше смекалки, и попробовав адреса уровнем ниже третьего (a.b.c.bitrix24.ru), повторно наблюдаем кривое использование SSL-сертификата, но теперь уже в случае с сертификатом для *.bitrix24.ru, который, вообще-то, при правильном применении, вполне себе валидный (выдан Go Daddy CA).

И это, наверняка, не все проколы. Ну и вот как тут можно говорить про безопасность корпоративного интранета в подобном “облаке”, которое разработчики не сумели настроить?

Дополнение (13.04.12): не менее показательно, что в разделе “Безопасность – техническим специалистам” на сайте написано буквально следующее (цитата): “на уровне операционной системы веб-серверов «Битрикс24» через сетевой экран закрыт внешний доступ по все портам, кроме 443″; но при этом нетрудно убедиться, что их веб-сервер охотно отвечает на 80 порту (301 Moved Permanently), перенаправляя на тот же IP, но на 443 порт. Понятно, что иначе и быть не может – пользователи не умеют https набирать.

Во как: у ICANN сломалась (сломали?) система приёма заявок на новые домены верхнего уровня. Сегодня последний день приёма таких заявок, но, понятно, срок продлили.