Что мы знаем о защите информации в Интернете ?

Новейший центр обработки данных NSA в штате Юта. Стоимость 1.5 миллиарда долларов.

На пленарном заседании 88-го совещания IETF (Internet Engineering Task Force, http://www.ietf.org/) - основной организации по стандартизации Интернет-протоколов, участники единогласно признали, что проблема прослушивания данных в Сети должна также быть решена на инженерном уровне. Этот единогласный порыв последовал после презентаций Брюса Шнайера, Брайана Карпентера, Стивена Фаррелла и часового обсуждения и комментариев у «открытого микрофона».

Заседание было посвящено «закалке» Интернета, прежде всего против всеобъемлющего сбора информации о пользователях Сети и прослушивания передаваемых данных. Хотя тема была естественно продиктована все еще разворачивающимся скандалом вокруг разведслужб США и Великобритании, для IETF это был также повод еще раз оценить вопросы безопасности в Интернете и мобилизовать собственные усилия в этой области.

Калейдоскоп кодовых имен

События развивались стремительно, постепенно детализируя картину деятельности NSA (Агентства национальной безопасности, http://www.nsa.gov/) и GCHQ (Центра правительственной связи, http://www.gchq.gov.uk) по использованию современной коммуникационной инфраструктуры, и в первую очередь Интернета, для создания системы всеобъемлющего сбора информации.

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

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

На следующий день мир узнал о программе PRISM, благодаря которой NSA при кооперации со стороны крупнейших сервис-провайдеров, таких как Google, Microsoft, Yahoo, etc. совершала широкомасштабный сбор метаданных о пользователях услуг этих компаний. По непонятным причинам единственным исключением был Twitter. Кооперация была добровольно-принудительной, но по заявлениям официальных лиц - законной.

Представление о масштабности этой работы было скорректировано, когда общественность узнала, что британская разведка GCHQ использует прослушивающие устройства на межконтинентальных каналах связи между датацентрами Google, Yahoo и возможно других провайдеров с "облачными" инфраструктурами. Эта программа называется MUSCULAR.

Разоблачение программы BULLRUN выявило возможности NSA преодолеть защиту таких протоколов как TLS/SSL, HTTPS, SSH, что позволяет дешифровать обмен данными с защищенными вэб-сайтами, VPN, содержимое «чатов» и т.д1.

События развивались калейдоскопом кодовых имен - помимо названных PRISM, MUSCULAR и BULLRUN были упомянуты QUANTUM, FOXACID, Black Heart, Mineral Eyes, Highlands. Список можно продолжить.

Хотя детали и масштаб активности NSA шокируют, собственно слежка и прослушивание линий связи явление не новое - история этой деятельности на государственном уровне берет свое начало по крайней мере с Первой Мировой Войны, когда, кстати, было образовано GCHQ - британская спецслужба, ответственная за ведение радиоэлектронной разведки, и прообраз NSA. Разведывательные операции стали масштабнее и более технологически искусными во времена Холодной Войны. Примером одной из операций по прослушиванию, кстати, при участии NSA, стала операция под кодовым названием Ivy Bells (Колокола Плюща) по прослушиванию советского подводного кабеля (http://en.wikipedia.org/wiki/Operation_Ivy_Bells). Без сомнения подобные операции проводились и проводятся и другими государствами, оснащенными средствами, предоставляемыми организациями, подобными NSA.

И в то же время разоблачения Эдварда Сноудена (Edward Snowden) стали сенсационными и шокирующими, не только потому, что это - пожалуй, самое масштабное публичное и грамотно соркестрированное разоблачение подобной деятельности, и не только благодаря ее тоталитарному характеру, включая государства-союзников США, но и во многом потому что в качестве инструмента использовался Интернет, его глобальный размах, технологии и услуги. И потому, что в глазах общественности, злоупотребляя своей доминирующей позицией, США нарушили неписанный социальный контракт.

Краткая история безопасности протоколов IETF

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

С этим настроением многие собрались на техническое пленарное заседание третьего дня встречи IETF88 в Ванкувере (http://www.ietf.org/meeting/88/index.html).

Как я заметил в начале статьи, основными докладчиками были Брюс Шнайер (Bruce Schneier, http://ru.wikipedia.org/wiki/Шнайер,_Брюс), Брайан Карпентер (Brian Carpenter, председатель IETF 2005-2007) и Стивен Фаррелл (Stephen Farrell, Директор Области «Безопасность» IETF).

Брайан провел краткий исторический экскурс усилий IETF по созданию безопасных протоколов. В частности, он напомнил, что требование наличия раздела «Security Considerations» («соображения безопасности») для спецификаций IETF было введено еще в 1993 году (RFC1543, http://tools.ietf.org/html/rfc1543). Правда, к этому времени фундаментальные протоколы Интернета (такие как IP, UDP и TCP) были уже стандартизованы, а многие RFC в этом разделе лишь указывали, что вопросы безопасности в данном документе не рассматриваются. Например, в предпоследней спецификации протокола маршрутизации между сетями Интернета - BGP образца 1995 года, этот раздел так и звучал: “Security issues are not discussed in this document”. В 1998 году (RFC2316, http://tools.ietf.org/html/rfc2316) последовало требование более серьезно относиться в разделу соображений безопасности.

Не то чтобы IETF не относился к вопросам безопасности серьезно. Еще 1991 году вышел RFC1244 “Site Security Handbook” (http://tools.ietf.org/html/rfc1244), содержавший указания по созданию эффективной политики безопасности сети. В середине 1990-х были стандартизованы такие протоколы как IPsec (http://ru.wikipedia.org/wiki/IPsec) и S/MIME (http://ru.wikipedia.org/wiki/SMIME). В 1994 году IAB организовал совещание по безопасности (RFC1636, http://tools.ietf.org/html/rfc1636), за ним последовало еще одно совещание в 1997 (RFC2316, http://tools.ietf.org/html/rfc2316), которое впоследствии привело в публикации документа RFC3365 “Strong Security Requirements for Internet Engineering Task Force Standard Protocols” (Строгие требования по безопасности для протоколов IETF, http://tools.ietf.org/html/rfc3365).

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

Надо заметить, что вопросы безопасности, особенно связанные с криптографией, не были однозначными и вызывали противодействие со стороны различных правительств даже в середине 1990-х. Во многих странах использование криптографии, особенно с высокой степенью защиты, регулировалось, а технологии нередко становились объектом экспортного контроля. Позиция IETF по отношению к криптографии формировалась в ходе длительного обсуждения. Результатом этих дискуссий явилось совместное заявление IAB и IESG, опубликованное под номером RFC1984 (http://tools.ietf.org/html/rfc1984). Выбор номера был неслучайным, Джон Постел (Jon Postel, http://ru.wikipedia.org/wiki/ Постел,_Джонатан_Брюс), в то время выполнявший функцию IANA, обладал тонким чувством юмора. В этом документе руководство IETF отметило, что существующее регулирование, ограничивающее использование криптографических средств, негативно сказывается на пользователях Интернет и имеет только эфемерные преимущества для правоохранительных органов и разведки. Позиция IETF была определена – использование сильной криптографии, где это возможно.

История на этом не заканчивается. На рубеже столетия IETF неоднократно сталкивался с требованиями предусмотреть в разрабатываемых протоколах средства СОРМ, конкретно – возможность «прослушивания» канала. Очередная долгая дискуссия закончилась еще одним документом – RFC2804 “IETF Policy on Wiretapping” (http://tools.ietf.org/html/rfc2804). Основной пункт – вмешательство в коммуникационный канал – это атака, по крайней мере, с точки зрения получателя и отправителя прослушивание неотличимо от атаки. Поэтому решено - IETF не будет рассматривать требования по прослушиванию при разработке протоколов.

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

Шифровать все!

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

Стивен Фаррелл продолжил эту линию, показав, что действия NSA по-существу неотличимы от кибер-атаки. И IETF должен взяться за работу, как это обычно происходит при обнаружении уязвимости протокола, открывающей возможность атаки.

В своем докладе он предложил несколько направлений работы IETF.

Во-первых, шифрование. Так называемое оппортунистическое шифрование (http://ru.wikipedia.org/wiki/Оппортунистическое_шифрование), когда аутентичность сервера не является обязательным условием для создания защищенного канала. Такой подход может существенно упростить применение таких протоколов как TLS, поскольку сервер может использовать самоподписанные сертификаты2. Этот подход может быть применен не только к вебу, но и к протоколам других уровней, например IPsec.

Во-вторых, рассмотреть в каких случаях требования безопасности могут быть распространены не только на разработку и внедрение протоколов, но и на их использование. Например, почему бы в новой версии протокола HTTP (2.0), обеспечивающего передачу данных между браузером и веб-сервером, не сделать использование TLS обязательным? Другими словами, если веб-сервер не может обеспечить шифрование канала, доступ к контенту возможен только по протоколу-предшественнику - текущему протоколу HTTP 1.0. Обсуждение обязательного применения сильной защиты продолжилось на заседании рабочей группы HTTPbis (http://datatracker.ietf.org/wg/httpbis/). Хотя такое предложение кажется логичным, оно, безусловно, имеет свои недостатки, в первую очередь связанные с внедрением. Некоторые отметили, что Интернет, возможно, не был бы таким открытым, глобальным и устойчивым, если бы защита данных имела больший приоритет.

Практика внедрения безопасности также указывает на то, что это непростая задача. Например, многие вопросы безопасности так и не решены для протоколов XMPP и SIP, составляющих основу VoIP.

Единый порыв

Пленарное заседание закончилось небольшим опросом, который Председатель IAB Расс Хаусли (Russ Housley) провел среди участников. По традиции IETF, мнение аудитории определяется не голосованием, а т.н. hum’ом, своего рода мычанием, громкость которого указывает предпочтение большинства.

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

Неудивительно, что мнение аудитории было однозначным – да, IETF должен работать над противодействием такого рода атакам. Будем надеяться, что это единогласное заявление будет служить своего рода путеводной звездой в непростых решениях при разработке протоколов.

Печальные реалии

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

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

Другой трудностью является то, что, несмотря на шокирующий характер новостей о деятельности NSA и партнеров, для среднего пользователя Интернета, к сожалению, они являются не более, чем сенсацией, не имеющей непосредственного отношение к его жизни. Широко бытующее мнение «мне нечего скрывать» характеризует этот отношение.

Например, возможность шифрования электронной почты существует и сегодня. К сожалению, провайдеры веб-почты, предоставлявшие эту услугу с удобным пользовательским интерфейсом, такие как Lavabit (http://lavabit.com/) и Silent Mail компании Silent Circle (https://silentcircle.com), вынуждены были закрыть свои сервисы, поставленные перед моральным выбором прекратить свою деятельность или скомпрометировать доверие пользователей открыв ключи таким агентствам, как NSA. Возможность шифровать почту c помощью технологий PGP или S/MIME3 для таких почтовых приложений как Thunderbird существует уже давно, но многие ли из нас систематически пользуются этой возможностью?

Другим примером борьбы за защиту личных данных, на сей раз со стороны регулятора, является так называемый Европейский «Закон о Cookie» (Cookie являются небольшим фрагментом данных, которые веб-сайт сохраняет на компьютере пользователя и использует для отслеживания состояния сеанса, хранения персональных предпочтений и т.п.). В зависимости от их функциональности, сookie могут представлять значительную опасность для личных данных пользователя и отслеживания его поведения во Всемирной Паутине, см. http://ru.wikipedia.org/wiki/HTTP_cookie). Эта Директива Евросоюза предписывает операторам веб-сайтов получить согласие посетителей сайтов перед сохранением cookie на компьютере пользователя. С момента принятия закона прошло почти полтора года и о его эффективности мало что известно. Однако известно, что Директива вызвала раздражение как со стороны веб-провайдеров, так и пользователей, вынужденных делать лишний клик для согласия с cookie из опаски уменьшения функциональности сайта.

Большие данные

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

О растущей проблеме концентрации информации и связанной с ней проблеме защиты личных данных я писал в статье «Конфиденциальность информации в Интернете» (http://www.ripn.net/articles/privacy/). Этот существенный момент как-то затерялся среди сенсационных сообщений о новых технологических возможностях NSA.

Однако именно «большие данные» изменили правила игры. Как сказал Фил Циммерманн (Phil Zimmermann), создатель криптографического пакета PGP (Pretty Good Privacy), в интервью онлайн-журналу Gigaom (http://gigaom.com/2013/08/11/zimmermanns-law-pgp-inventor-and-silent-circle-co-founder-phil-zimmermann-on-the-surveillance-society/):

«Большие данные подразумевают концентрацию информации и имеют разлагающее влияние. Это действительно концентрирует власть в руках тех, кто владеет этими данными - правительства, компании. Революция ПК конца 1970-х и 1980-х и позже ранний Интернет 1990-х, казались такими многообещающими, предоставляющими такие возможности индивидууму. Теперь с большими данными происходит смещение власти в другом направлении, сосредоточивая ее в руках немногих.»

Что дальше?

Жизнь идет своим чередом. Сенсации уйдут в прошлое, однако то, что произошло, оставит след и возможно приведет к видимым изменениям.

Я не буду здесь останавливаться на политических последствиях. Новости последних месяцев, безусловно, изменили расстановку сил и обострили некоторые вопросы администрирования, если не управления Интернетом. Более сильно зазвучала «национальная» компонента, связанная с юрисдикцией и государственными границами.

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

Одним из фундаментальных требований, лежавших в основе дизайна Интернета, была возможность обходить поврежденные участки без потери функциональности. Будем надеяться, что Сеть обойдет и этот «участок».

Андрей Робачевский

Мнения, представленные в статье, не обязательно отражают официальную позицию Internet Society






1 Документ “PRISM-Proof Security Considerations” содержит ряд предположений, как может быть преодолена криптографическая защита (http://tools.ietf.org/html/draft-hallambaker-prismproof-req).

2 Протоколы рабочей группы DANE (http://datatracker.ietf.org/wg/dane/) могут существенно улучшить ситуацию в этой области, позволяя администраторам услуг декларировать самоподписанные сертификаты в системе DNS/DNSSEC под собственным доменным именем.

3 Обе технологии не обеспечивают полной секретности, поскольку оставляют видимым поле темы сообщения (“Subject:”), а также мета-данные. Однако это, безусловно, не является причиной их недостаточного использования.