Почему вообще необходимо применять технологии доверия? Использование Сети в обыденной жизни уже давно стало привычным: если нужно посмотреть пробки на дорогах, мы обращаемся к соответствующим веб-сервисам, если нужно встретить родных на вокзале, то к нашим услугам различные сайты, визуализирующие информацию от РЖД, а с авиабилетами выбор еще больше — здесь и сайты аэропортов, и авиакомпаний, и дискаунтеров-агрегаторов, а если нужно понять, начислена ли нам зарплата, можно, не вставая с рабочего места и даже не беспокоя бухгалтерию, просто обратиться к онлайн-банкингу. И вот тут вы, вдруг, получаете сообщение (рис. 1.).

 

Рис. 1. Пример предупреждения о недействительном сертификате
Рис. 1. Пример предупреждения о недействительном сертификате

 

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

Уровни доверия

 

Рис. 2. Иллюстрация изобилия IP-адресов поисковых машин
Рис. 2. Иллюстрация изобилия IP-адресов поисковых машин

Несмотря на то что обмен информацией в Интернете между компьютерами происходит с использованием IP-адресов, мало кто из обычных пользователей эти адреса помнит. Например, какой адрес у «Яндекса»? Не каждый специалист «с ходу» даст ответ на этот вопрос, тем более что таких адресов может быть множество (рис. 2). Поэтому вместо адресов используются доменные имена.

В общем виде это выглядит следующим образом. Пользователь вводит имя, а браузер обращается к системе DNS, которая возвращает IP-адрес. Затем браузер посылает запрос по полученному IP-адресу на загрузку контента, а сервер управления контентом возвращает программе требуемую страницу с содержимым. В этой схеме мошенники могут либо заставить пользователя ввести некорректное имя ресурса, либо подменить соответствие между именем и адресом. Классический пример введения в заблуждение по вводу имени — почтовая рассылка с предложением перейти на поддельный сайт и обновить свои идентификационные данные. Первый случай такой подмены (фишинга) в России был зафиксирован 18 мая 2004 года, когда «Ситибанк» от имени своего президента Алана Херста распространил заявление, что не имеет отношения к массовой почтовой рассылке, в которой клиентов банка просили обновить данные своих кредитных карт. При этом ссылка из почтового сообщения вела на поддельный сайт, который был точной копией страницы авторизации, однако доменное имя не совпадало с доменным именем сайта «Ситибанка».

Эксперты по компьютерной безопасности не перестают рекомендовать обычным пользователям обращать внимание на адреса сайтов и в первую очередь на доменные имена сайтов, которые они посещают. В ответ злоумышленники стали использовать для своих страниц имена, похожие на имена сайтов, клиенты которых подвергаются атаке: например, в 2007 году такой фишинговой атаке подверглись клиенты системы «Яндекс.деньги», когда, кроме копирования страницы, мошенники использовали доменное имя yancleх.ru. Следует заметить, что по прошествии пяти лет подобного рода атаки не потеряли своей актуальности, и в октябре 2012 года специалисты «Лаборатории Касперского» отметили несколько подобных атак на Twitter и Facebook, использовавших доменное имя tviwtter.com.

Рекомендация в этом случае сводится к тому, чтобы снова внимательнее смотреть на адресную строку загружаемого ресурса. В случае с Twitter понять отличие может внимательный пользователь: мало того, что доступ к сайту осуществляется по https-протоколу https://twitter.com вместо http://twitter.com, так еще и адресная строка подсвечивается зеленым цветом (рис. 3).

 

Рис. 3. Пример экрана с настоящим сертификатом
Рис. 3. Пример экрана с настоящим сертификатом

 

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

Удостоверение контента

Для чего в обычной жизни требуется именно нотариально заверенная доверенность и кому она реально нужна? Функции нотариата определены в «Основах законодательства Российской Федерации о нотариате» от 11 февраля 1993 года. Нотариус — это персона, которой доверяют совершенно не знакомые друг с другом люди и организации. А вот почему именно нотариусу можно доверять, определяет государство. Нотариусы заверяют как копии документов, в том числе и скриншоты экранов компьютеров, так и подписи физических лиц и представителей юридических лиц. В случае подписи нотариус гарантирует факт подписания документа конкретным лицом, чью подпись заверяет, но не истинность содержания самого документа. В онлайн-пространстве может быть нотариально заверенное заявление на передачу доменного имени от одного администратора другому. Нотариус в данном случае просто удостоверяет тот факт, что под заявлением поставлена подпись заявителя, а не другого лица.

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

Теперь рассмотрим процедуру доступа к информационному ресурсу с использованием SSL-сертификата, что обычно происходит при обращении к сайту по протоколу HTTPS. В рамках этого взаимодействия происходит создание SSL-сессии (рис. 4), в которой Server digital ID — это SSL-сертификат, содержащий открытый ключ сервера и алгоритм шифрования. Сертификат был ранее выдан сайту, а точнее, физическому лицу или организации, которые установили его на сервер общепризнанным Удостоверяющим центром (УЦ).

 

Рис. 4. Установка SSL-сессии
Рис. 4. Установка SSL-сессии

 

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

  1. аутентификация (authentication);
  2. шифрование (encryption);
  3. целостность (integrity);
  4. достоверность (non-repudiation, безотзывность).

Аутентификация обеспечивается УЦ, который при выдаче сертификата проверяет заявителя. Для разных сертификатов серьезность проверки различна, но она всегда есть и всегда можно посмотреть, каким именно УЦ был выдан сертификат (рис. 5).

 

Рис. 5. Отображение информации о SSL-сертификате
Рис. 5. Отображение информации о SSL-сертификате

 

Для twitter.com сертификат был выдан УЦ компании VeriSign, установившей достоверность сведений, которые Twitter передал при заявке на сертификат. По сути, УЦ VeriSign выполнил функции нотариуса по удостоверению подписи twiiter.com.

Шифрование при организации взаимодействия по HTTPS не только преследует цель сокрытия передаваемых данных от посторонних глаз, но и гарантирует, что никто не подменит данные при их передаче. Речь здесь идет о поддержке достоверности передаваемых данных. Шифрование канала при использовании HTTPS очень часто выводят на первый план, смещая акцент в применении SSL-сертификатов с доверия на безопасность. Это совершенно неправильно и может привести к серьезным ошибкам в реализации мер по обеспечению безопасности клиентов сайта. В конечном итоге можно самому выпустить SSL-сертификат и им подписать свой сайт, что многие и делают, особенно если речь идет о внутрикорпоративных системах — ведь все и так всех знают, а шифрование канала обеспечено и чужие не смогут подсмотреть данные. Но если речь идет об обслуживании чужих людей и сборе с них «чувствительной» информации, то почему они должны вам доверять? Именно по этой причине все браузеры предупреждают о сертификатах, применяемых некорректно (рис.1) или выпущенных неизвестным УЦ.

В случае «самодельного» сертификата в предупреждении обычно упомянуто некое «неизвестное бюро», а значит, есть бюро, «известные» браузеру, — УЦ, прошедшие процедуру международного аудита (www.webtrust.org), которая проводится ежегодно под патронажем аудиторских компаний, таких как KPMG, Ernst&Young, PwC. В каждой стране список аудиторов свой — правда, в России на сегодняшний день еще никто такого аудита по международной процедуре не проходил.

Известные УЦ называют корневыми центрами сертификации — именно эти центры выполняют действия по удостоверению сторон SSL-взаимодействия. Рынок УЦ узок, а порог входа на него высок, и лидируют здесь Symantec Group (42,9%), Comodo (25,9%), Go Daddy (13,9%), GlobalSign (7,9%) и Entrust (3,1%). В России наиболее широко представлены сертификаты Symantec и Comodo, крупнейшим российским ресселером этих сертификатов является ssl.ru.

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

Последняя функция — достоверность или безотзывность (non-repudiation), означающая невозможность отказа от своих обязательств. Это свойство SSL-обмена редко обсуждают, но именно оно позволяет утверждать, что если на какой-либо странице при доступе по HTTPS был обнаружен «зловред», то он действительно там был и ответственность за его распространение несет администратор сайта.

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

Что же проверяет УЦ, прежде чем выпустить сертификат и отправить его заявителю (своему клиенту)? Фактически речь идет о проверке права заявителя управлять доменным именем, на которое выпускается сертификат.

Самый простой и быстрый способ — это доказать свою способность управлять зоной домена. В заявке на сертификат указывается контактная информация, которая в простейшем случае должна совпадать с указанной в Whois для домена. Такие сертификаты называются сертификатами с доменной валидацией (domain validation sertificate) или обычными сертификатами.

Обычные сертификаты быстрее всех других выпускаются и дешевле стоят. Они могут выпускаться на один домен, на несколько на одном сервере или на множество поддоменов — так называемые сертификаты wild card. В случае с сертификатом Сбербанка (рис. 1) налицо ошибка в выборе и установке сертификата, который был выпущен для одного домена, а в силу особенностей настройки HTTP-сервера оказался востребован для другого домена. Однако обычные сертификаты предоставляют наименьшую степень защищенности контента, фактически наименьшую степень доверия.

Очевидно, что административный контакт, используемый в процессе проверки, — это слабое место процедуры сертификации: существуют инструменты коллекционирования административной информации whois; очень часто в качестве административного контакта указывается адрес электронной почты на одном из публичных сервисов типа gmail.com и mail.ru. Если почтой не пользуются, то ее адрес может попасть в пул свободных адресов и новый пользователь почтового сервиса сможет его зарегистрировать на себя. Если кто-то хочет перехватить управление доменом, то все это повышает вероятность получения доступа к домену — теоретически возможен выпуск сертификата по запросу злоумышленника.

Другой тип сертификатов — это сертификаты, выпущенные по процедуре расширенной валидации (Extended Validation Certificates). В этом случае УЦ проверяет не только контактную информацию домена, но и администратора доменного имени. Пакет документов довольно пухлый — от свидетельства о регистрации до контактного телефона, на который обязательно последует контрольный звонок. Проверка заявителя — это основная функция УЦ, его бизнес.

А что случается, когда УЦ ошибаются? Последствия бывают различными. Во всяком случае, для сертификатов предусмотрена процедура отзыва. Здесь следует заметить, что в офлайновом мире нотариальные акты вступают в силу немедленно, поэтому законодательно не предусмотрена процедура исправления ошибок, хотя в нотариальной практике такое случается.

В 2001 году VeriSign выдало сертификаты на программы физическому лицу, которое представилось сотрудником Microsoft. С момента выпуска сертификатов до момента обнаружения ошибки прошло шесть недель, после которых VeriSign опубликовала публичное заявление на своем сайте и отозвала сертификат. Но более серьезные проблемы возникают при взломе системы УЦ. В 2011 году пользователи браузера Google в Иране стали получать предупреждения о невалидном сертификате на сервисах Google. При более пристальном рассмотрении оказалось, что была взломана локальная сеть голландского УЦ DigiNitar, в результате чего злоумышленник смог выпустить валидные сертификаты для *.google.com. Все сертификаты DigiNitar были исключены из списков валидных сертификатов, а УЦ разорился.

Удостоверение адреса

Кроме подмены контента, существует еще возможность подмены соответствия между IP-адресом и доменным именем.

В 2008 году Дэн Камински обнаружил фундаментальную уязвимость системы DNS, используя которую злоумышленник мог подменить соответствие между доменными именами и IP-адресами, причем даже для корневых серверов системы DNS. Для того чтобы избежать такой подмены, нужно было построить систему, которая бы гарантировала тот факт, что на запросы к системе DNS отвечают именно те серверы, которые уполномочены это делать. Для решения этой задачи было решено использовать спецификацию DNSSEC(Domain Name System Security Extensions), в рамках которой администратор DNS-сервера имеет возможность подписать свой домен. Технология DNSSEC была предложена в 1995 году после выявления первых уязвимостей системы DNS, названных Cache Poison (отравление кэша). Первые варианты DNSSEC плохо масштабировались на все пространство Сети, поэтому в 2005 году была выпущена новая версия спецификации, которая используется в современных реализациях DNSSEC.

Система DNS имеет возможность проверять эти подписи и тем самым защищать конечных пользователей от подмены. Цепочка доверия в этой схеме строится от корневой зоны системы DNS к зоне, из которой получаем IP-адрес. В упрощенном виде это работает следующим образом.

  1. Администратор домена генерирует ключи и размещает их в файле описания зоны своего домена.
  2. На основе ключей генерируется так называемая DS-запись, которая передается в зону уровнем выше — например, для домена domain.ru DS-запись будет передана в зону ru.
  3. При обращении к системе DNS в поисках IP-адреса программное обеспечение, отвечающее за этот поиск, получает DS-запись и ключ. Используя ключ, можно сгенерировать DS-запись. Если DS из старшей зоны совпадает с генерированной по ключу, то подмены информации о соответствии доменного имени адресу не произошло. В противном случае детектируется подмена соответствия.
  4. Если все ответы от корня системы DNS до зоны, в которой установлено соответствие, проверены, то полученной информации можно доверять, в противном случае налицо факт подмены.

Сегодня технология DNSSEC используется в 96 доменах верхнего уровня из 316. Уже подписаны две из трех национальных доменных зон России (рф и su), а в начале декабря 2012 года в компании «Технический Центр Интернет» была проведена процедура генерации ключей DNSSEC для зоны ru. 10 декабря 2012 ключи появились в файле зоны ru. Таким образом, во всех российских доменах будет внедрена процедура проверки адресной информации по протоколу DNSSEC, однако следует заметить, что пользователи не готовы с энтузиазмом брать на вооружение новые возможности. Во всех национальных доменных зонах на первое декабря 2012 года были подписаны только шесть доменов, из них только один с валидными подписями. Остальные — это лишь упражнения на тему «проверить систему на устойчивость к ошибкам».

Для того чтобы администраторы доменных имен начали использовать DNSSEC, необходимо предоставить им простые и надежные сервисы поддержки DNSSEC, но пока из всех российских ICANN-аккредитованных регистраторов данную технологию поддерживает только RU-CENTER. Однако только 24 из 1028 ICANN-аккредитованных регистраторов во всем мире поддерживают эту технологию, предоставляя поддержку DNSSEC в качестве дополнительного бонуса для своих клиентов. Поэтому пока говорить о каком-то бизнесе на услугах DNSSEC еще не приходится. Тем не менее среди бизнес-моделей регистраторов эта технология должна занимать одно из ведущих мест — сейчас наметилась тенденция к снижению стоимости регистрации доменов, и администраторы доменов активно переходят от одного регистратора к другому. DNSSEC ограничивает такую активность — ключи нужно постоянно менять, требуется хранить секреты и их обновления, что усложняет переход от одного провайдера услуг DNS к другому.

***

С расширением Сети растут и объемы мошенничества, что порождает спрос на услуги доверия. Сегодня в российском сегменте Сети 4 млн доменных имен и почти 3 млн работающих сайтов, из которых только 4% имеют SSL-сертификаты, но почти половина из них — самодельные. Только 2% сайтов Рунета защищены сертификатами УЦ, прошедших международный аудит. Если сравнивать с объемами внедрения SSL в мире, то коммерческие сертификаты использует порядка 30% всех сайтов, а «самопальные» — только 11%. На этом фоне российские цифры более чем скромные. Все это свидетельствует не только о вопиющих недостатках в вопросах безопасности, но и о потенциале рынка услуг доверия.

Внедрение DNSSEC во всех национальных доменных зонах создает хорошие предпосылки для построения защищенной национальной системы DNS, однако внедрение DNSSEC находится еще в самом начале пути. Рынка управления секретами DNS пока нет не только в России, но и во всем мире. Из первых шагов в этом направлении стоит отметить лишь заявку компании VeriSign на патент «Transfer DNSSEC domains».

Можно удостоверить контент, можно удостоверить адрес, но существует еще маршрутизация, и вопрос доверия здесь стоит не менее остро, чем при доступе к сайтам или электронной почте, — получение пограничным маршрутизатором недостоверной информации может привести к массе проблем, подобных случившейся 8 апреля 2010 года, когда в течение 18 минут из-за ошибки маршрутизатора China Telecom большие объемы трафика США шли через Китай.

Павел Храмцов (paulbkh@google.com) — доцент Национального исследовательского ядерного университета «МИФИ» (Москва).

Поделитесь материалом с коллегами и друзьями

Купить номер с этой статьей в PDF