Обнаружение атак перехвата SSL, осуществляемых властями, и защита от них

"Криптографию обычно обходят, а не атакуют в лоб" — Ади Шамир [1].

"Только потому что вы используете шифрование, это не даёт вам талисман против преследующей стороны. Они могут заставить сотрудничать сервис-провайдера" — Фил Циммерман [2].

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

1. Введение

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

Безопасность и конфиденциальность миллионов интернет-транзакций в день зависит от протоколов Secure Socket Layer (SSL)/Transport Layer Security (TLS). Сердце этой системы — определённое число удостоверяющих центров или центров выдачи сертификатов, Certificate Authorities — (CAs), каждый из которых отвечает за проверку идентичности субъектов, которым он выдаёт SSL-сертификаты. За счёт конфиденциальности и аутентичности, предоставляемой УЦ, основанной на инфраструктуре открытых ключей, пользователи по всему миру могут совершать онлайновые банковские операции, заниматься электронной коммерцией и осуществлять коммуникации с друзьями и любимыми по поводу наиболее чувствительных тем, без необходимости беспокоиться по поводу злонамеренной третьей стороны, которая могла бы перехватывать и расшифровывать их коммуникации.

Однако, большинству пользователей неизвестно, что УЦ — это наиболее слабое звено инфраструктуры открытых ключей и проблема усиливается тем фактом, что большинство вэб-браузеров доверяют сотням различных фирм, выпускающих сертификаты. Каждая из этих фирм может быть подвергнута принуждению со стороны национального правительcтва с целью выпустить сертификат для любого определённого вэбсайта, которому будут доверять все браузеры без предупреждений. Таким образом, пользователи по всему миру поставлены в положение в котором их браузеры доверяют их приватные данные непрямым образом большому количеству властей (как местных так и зарубежных), которым эти люди сами по себе ни за что не стали бы доверять.

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

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

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

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

2. Удостоверяющие центры и поставщики браузеров

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

2.1 Удостоверяющие центры сертификатов

УЦ играют важную роль в инфраструктуре открытых ключей — Public Key Infrastructure (PKI) для SSL. Главная обязанность каждого УЦ — проверка идентичности субъекта, которому выдаётся сертификат.

Уровень проверки, осуществляемой УЦ зависит от типа выдаваемого сертификата. Регистрация сертификата на домен можен быть получена менее чем за 15$ и обычно требует, только чтобы запрашивающий был способен ответить на имэйл к административному адресу, находящемуся в списке базы данных WHOIS. Расширенная проверка (Extended Validation — EV) требует более сложных методов.

То есть, когда пользователь посещает https://www.bankofamerica.com, браузер будет информировать его о том, что банковский сертификат действителен, выдан компанией VeriSign и этот сайт запущен компанией Bank of America. Таким образом аутентичность и конфиденциальность гарантирована SSL для того чтобы пользователь мог продолжать свою транзакцию без необходимости беспокоиться о фишинг-атаках киберпреступников.

УЦ в общем случае попадают в одну из трёх категорий: те, которым доверяют браузеры (корневые УЦ — "root CAs"), те, которым доверяют корневые УЦ (промежуточные УЦ — "intermediate CAs" ) и те, которым не доверяют ни браузеры, ни какие-либо промежуточные УЦ (недоверяемые УЦ — "untrusted CAs"). Кроме того, промежуточные УЦ необязательно должны быть напрямую заверены корневым УЦ: они могут быть заверены другими промежуточными УЦ до тех пор, пока цепочка доверия оканчивается корневым УЦ.

С точки зрения конечного пользователя, корневые и промежуточные УЦ функционально эквивалентны. Вэбсайт, представляющий сертификат, подписанный любой из этих двух форм УЦ, приведёт к появлению в браузере пользователя иконки замка и изменение цвета строки статуса. Сертификаты, проверенные недоверяемым УЦ и потому являющиеся самоподписанными владельцем сайта, приведут к появлению предупреждений безопасности, что может испугать некоторых технически неподготовленных пользователей [3], привести их в замешательство и создать трудности, которые прийдётся преодолевать для продолжения навигации по сайту [4].

В том виде как система УЦ была задумана в оригинале и исполнена в данный момент, все корневые УЦ одинаково доверяемы для браузеров. Так, каждый из 264 УЦ, доверяемых для Microsoft, 166 доверяемых Apple и 144 корневых УЦ, доверяемых Firefox, способны выпустить сертификат для любого вэбсайта в любой стране или домене верхнего уровня [5]. Например, даже если Bank of America получит свой текущий сертификат от VeriSign, нет никакой технической причины, почему бы другой УЦ, скажем GoDaddy, не мог бы выпустить сертификат для него или кого-нибудь ещё. Злонамеренной третьей стороне нужно каким-то образом получить сертификат для сайта Bank of America и затем обманом направить пользователя на подставной вэбсервер (например, путём DNS или ARP спуфинга), при этом нет никакого практичного лёгкого пути для пользователя определить, что произошло что-то неправильно, поскольку интерфейс браузера будет сигнализировать об установлении корректной SSL-сессии.

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

Рис 1: Панели со строками статусов браузеров Internet Explorer (вверху), Firefox (посредине) и Chrome (внизу), в процессе посещения HTTPS-сайта с расширенной проверкой (Bank of America) и сайта со стандартным HTTPS-сертификатом (Chase). Обратите внимание, что информация о стране ("US"), представленная в браузерах, относится к корпорациям, которые получили сертификат, а не к местоположению центра сертификации (удостоверяющего центра).

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

Поставщики браузеров обладают значительной теоретической властью над каждым УЦ. Каждый УЦ, который не может более быть доверяемым ведущими поставщиками браузеров не сможет больше привлекать и удерживать клиентов, так как посетители вэбсайтов его клиентов будут каждый раз встречать запугивающие предупреждения при попытке установления защищённого соединения. Тем не менее, поставщики браузеров проявляют крайнюю неохоту в том, чтобы своевременно исключать УЦ из списков, что способствует их неподобающему поведению — мы всегда можем наблюдать большой список примеров плохих практик УЦ [6].

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

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

2.2 Вэб-браузеры

Не существует технического стандарта, который должен определять, как вэб-браузеры должны выбирать свои списки доверяемых УЦ. В результате, каждый поставщик браузера создаёт свой собственный набор политик для оценки и утверждения УЦ [7,8,9]. Поскольку нет никакого свидетельства, указывающего, что какой-либо браузер по умыслу или некомпетентности принимал нечестного УЦ, мы не обсуждаем тонкости проверки политик каждого отдельно взятого поставщика.

Далее больше внимания будет уделено методу, которым поставщики браузеров производят доставку и обновление своих списков корневых УЦ и как интерфейс браузера предоставляет конечным пользователям просмотр и управление ими.

Ведущие браузеры (Internet Explorer, Firefox, Chrome и Safari) используют несколько отличающиеся политики управления и отображения списков доверяемых УЦ: Firefox — единственный лидирующий браузер, ведущий собственную базу данных доверяемых УЦ, тогда как остальные три браузера вместо этого полагаются на список УЦ, предоставляемый операционной системой. Однако, поскольку два из этих трёх поставщиков браузеров также являются и крупными игроками в бизнесе компьютерных операционных систем, граница между браузером и операционной системой имеет тенденцию размываться.

Несколько лет назад Microsoft, как и другие поставщики, включила сотни УЦ в корневое хранилище (Trusted Root Store) своей операционной системы Windows. Пользователи, изучавшие соотвествующий интерфейс могли просматривать и управлять полным списком УЦ. Однако в ответ на критику от крупных корпоративных пользователей, Microsoft уменьшила число сертификатов в доверенном хранилище в последующих версиях ОС до считанных единиц.

Бывший менеджер по выпуску Internet Explorer заявлял, что "крайне малое число энтерпрайз-компаний, которые выбирали контроль над своим уровнем доверия, испытывали беспокойство по поводу того, что хранилище из 70-100 корневых УЦ может быть источником потенциальных злоупотреблений. По этим и другим причинам Microsoft впоследствии уменьшило число корневых сертификатов в доверенном хранилище [10]."

Для наивного пользователя (или исследователя по вопросам безопасности) на основе сравнения через пользовательский интерфейс различных баз данных УЦ, предоставляемых Microsoft, Apple и Mozilla легко придти к выводу о том, что Microsoft подходит более тщательно к вопросу доверия УЦ, чем конкуренты, поскольку пользовательский интерфейс свежеустановленной Windows Vista или Windows 7 будет содержать менее 15 УЦ в доверенном корневом хранилище ОС. К сожалению, этот интерфейс чрезвычайным образом вводит в заблуждение, поскольку он не показывает факты того, что Microsoft выбрало доверие к 264 различным УЦ. Собственная документация компании гласит, что:

Корневые сертификаты обновляются в Windows Vista [и Windows 7] автоматически. Как только пользователь посещает защищённый вэбсайт (при использовании HTTPS SSL [...] и сталкивается с новым корневым сертификатом, программное обеспечения Windows для проверки цепочек сертификатов проверяет подходящие обновления Microsoft для корневого сертификата. Если он находится, то он загружается в систему. Для пользователя это проходит как непрерывная операция. Пользователь не видит никаких диалоговых окон или предупреждений безопасности. Загрузка происходит автоматически, вне поля зрения [7] )

Таким образом, любой вэб-браузер, который зависит от доверенного хранилища сертификатов Microsoft (такой как Internet Explorer, Chrome или Safari под Windows) беспрекословно доверяет 264 различным УЦ, выдающим сертификаты, без предупреждения, хотя лишь малая часть из них показана в списке пользовательского интерфейса операционной системы. Несмотря на то, что Microsoft ясно описывает это в своей сетевой документации для разработчиков [7], никакого упоминания об этом важном выборе в проектировании браузера или в пользовательском интерфейсе управления сертификатами операционной системы не встречается, там где интересующиеся пользователи имели бы больше всего шансов это заметить.
2.3 Человек посредине

"Любой вэбсайт, защищённый TLS может быть подменён при использовании подложного сертификата, выданного недобросовестным УЦ. Это безотносительно того, какой УЦ выдавал подлинный сертификат вэбсайту и любого свойства этого сертификата"
— Марк Стивенс и др.[11]

В то время как подробное рассмотрение атак человека посредине против SSL выходит за рамки данной статьи, мы по крайней мере дадим краткое введение в тему. За последние годы протокол SSL был предметом серии успешных атак исследователей в области безопасности, некоторых, за счёт преимущественно фундаментальных изъянов протокола и других, фокусировавшихся на социальной инженерии и других техниках введения в заблуждение [12, 13].

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

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

Исследователь по вопросам безопасности Мокси Мэрлинспайк регулярно атаковал SSL, основываясь на цепочках доверия, обнаруживая эксплойты, влияющие как на уязвимости в дизайне браузеров, так и атаки социальной инженерии против конечных пользователей. Его утилиты sslsniff [14] и sslstrip [15] автоматизируют задачи выполнения атак человека-посредине, и при возможности оснащения действительным сертификатом (например полученным от недобросовестного УЦ), могут быть использованы для перехвата пользовательских коммуникаций без того, чтобы вызвать какие-либо предупреждения со стороны браузера.

3. Большой брат в браузере

Microsoft, Apple и Mozilla включают некоторое число УЦ государственных властей в соответствующие базы данных своих УЦ.

Например программа корневых сертификатов Microsoft включает властей Австрии, Бразилии, Финляндии, Франции, Гонконга, Индии, Японии, Кореи, Латвии, Макао, Мексики, Португалии, Сербии, Словении, Испании, Швейцарии, Тайваня, Нидерландов, Туниса, Турции, США и Уругвая [16].

Эти государственные УЦ часто включаются по законным причинам: многие власти встраивают криптографические открытые ключи в свои национальные ID-карты или не хотят доверять внешнее обслуживание в возможности выпуска своих внутренних сертификатов внешним компаниям.

Хотя это может быть достаточно приемлемо для эстонских пользователей браузера Internet Explorer — доверять по умолчанию УЦ своего государства (так как это даёт им более широкие возможности в сети, связанные с их национальными ID-картами), рядовому жителю Ливана или Перу меньше выгоды в доверии к эстонским властям в неограниченной возможности выдавать сертификат к любому вэбсайту. Таким образом люди со всего света оказываются в положении, что когда им приходится доверять приватные данные своему браузеру, то также косвенным образом им придётся доверять некоторому числу зарубежных правительств, которым эти люди в обычном случае никогда бы не стали доверять.

Возможен такой пример: Корейское агентство информационной безопасности создаёт действительный сертификат для промышленного и коммерческого банка Китая (текущий сертификат которого выпушен VeriSign, США), чтобы затем иметь возможность осуществлять эффективную атаку человека-посредине против пользователей Internet Explorer.

Хотя на первый взгляд это кажется чрезмерно мощной атакой, есть множество причин, из-за которых маловероятно, что власти будут использовать свои УЦ для проведения атак человека-посредине.

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

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

4. Сотрудничество по принуждению

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

В США законными актами определён перечень субъектов, которые могут быть принуждены к сотрудничеству в электронной слежке для органов охраны правопорядка:

Ордер, дающий полномочия для перехвата коммуникаций по проводам, электронным системам или в устном виде в этой главе должен [...] указывать на провайдера проводного или электронного коммуникационного сервиса, владельца, контролирующего или другое лицо в экстренном порядке снабжающее заявителя всей информацией, возможностями и технической помощью, необходимой для выполнения перехвата незаметным образом и с минимумом помех для сервисов, поставляемых таким провайдером, владельцем, управляющим или лицом, чьи коммуникации подвергаются перехвату См.:
18 U. S. C. §2518(4).

или расследований по запросам резведслужб:

См.: U. S. C. §1805©(2)(B).

и в значительно более широких случаях.

Обширный обзор способов, которыми технологичные фирмы могут быть принуждаемы к нарушению прав своих пользователей на приватность можно найти в [17].

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

За пределами США и других демократических стран специфические законодательные постановления могут играть даже менее важное значение. Правительство Китая, например регулярно принуждает к сотрудничеству телекоммуникационные и технологические компании для помощи в мерах по организации слежки [19, 20].

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

Легальные основания, связанные с таким типом помощи по принуждению значительно более сложны. Любое правительственное агентство США, принуждающее таким образом УЦ к сотрудничеству, должно конечно полагаться большей частью на условия, отмеченные нами ранее. Однако, неясно, насколько будет такое вынужденное сотрудничество законным для самих УЦ, поскольку оно противоречит обязанностям по предоставлению сервиса проверки идентичности. Такое сотрудничество по принуждению также вызывает серьёзные опасения по поводу Первой Поправки, по факту того, что американские власти будут приказывать УЦ фабриковать заведомо ложные данные по поводу идентичности получателя сертификата.

Каждый УЦ уже имеет развёрнутую инфраструктуру при помощи которой он способен выпускать SSL сертификаты. В сценарии с принуждением к сотрудничеству, от УЦ требуется всего лишь пропустить шаг проверки идентичности в своём процессе выпуска сертификатов.

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

В гипотетическом примере такой атаки американское Агентство Национальной Безопасности (АНБ) может вынудить VeriSign выпустить достоверный сертификат для коммерческого банка Дубая (текущий сертификат которого выпущен Etisalat, ОАЭ), что может быть использовано для эффективной атаки человека-посредине против всех современных браузеров.

5. Свидетельства

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

Автор попал в заголовки национальных СМИ в декабре 2009, когда он обнародовал аудиозапись дискуссии одной группы с этой конференции, в которой работники телекоммуникационных компаний хвастались степенью своей кооперации с правительственными агентствами, включая тот размах, которым они снабжали их информацией о GPS-местоположении своих пользователей [21,22].

Среди множества поставщиков, бывших на стендах в демонстрационном зале, была и Packet Forensics, компания из Аризоны, продающая чрезвычайно компактные устройства скрытого сетевого перехвата.

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

Устройства Packet Forensics созданы для внедрения и извлечения в нагруженные сети без вызывания заметных прерываний [...]. Это позволяет вам перехватывать вэб, имейл, VoIP и другой траффик всегда и везде, даже если он проходит внутри зашифрованного туннеля. Использование "человека-посредине" для перехвата TLS или SSL является важной атакой против лежащего в их основе протокола согласования криптографических ключей Диффи-Хеллмана [...]. Для того, чтобы использовать наш продукт в таком сценарии [государственные] пользователи должны иметь возможность импортировать копию любого действительного ключа, которую они смогут достать (потенциально по судебному ордеру) или могут сгенерировать "правдоподобно выглядящие" ключи, предназначенные для создания у субъекта ложного чувства уверенности в доверии к их аутентичности.

Фактически компания упаковала утилиту sslstrip в четырёхдюймовый прибор, предназначенный для государственных пользователей для быстрого подключения в сети по цене, "которая выгодна среди имеющихся".

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

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

Вследствие того, что устройства Packet Forensics содержат технологии шифрования, каждый, кто желает экспортировать устройства пятой серии в зарубежные страны кроме Канады, должен подписать полугодовые отчёты как для Департамента коммерции США, управления индустрии и безопасности и для Агентства Национальной Безопасности [23]. В конце октября 2009, мы подписали формальный запрос в коммерческий департамент на получение списка клиентов устройств пятой серии Packet Forensics. Запрос остался без ответа.

6. Некоторые УЦ уже участвовали в слежке

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

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

6.1 VeriSign

Сертификаты VeriSign используются более чем миллионом вэбсерверов по всему миру, больше чем от какого-либо другого УЦ. Компания утверждает, что 40 крупнейших банков и свыше 95% компаний списка Fortune-500 выбирают сертификаты или от них, или от их дочерних предприятий [25]. То есть среди всех УЦ, пользователи вероятно больше всего будут распознавать брэнднэйм VeriSign и возможно даже ассоциировать его с безопасными электронными транзакциями.

Мало кто из пользователей, слышавших о Verisign, знал, что компания вовлечена также и в другие сферы бизнеса, помимо продаж SSL-сертификатов высокого уровня. Частичное отношение к этому обсуждению имеет отдел бизнеса VeriSign, который используется во многих больших телекоммуникационных компаниях, которые соглашаются на аутсорсинг своих потребностей в слежке и удовлетворении требований со стороны властей. Маркетинговые материалы VeriSign описывают их аутсорсинговую помощь в коммуникациях в отношении акта об охране правопорядка (CALEA), некоторые детали этого продукта показаны на рис. 2, также раскрывается, что кабельный гигант Cox Communications и лидер VOIP Vonage относятся к многим, кто удовлетворяет такого рода запросы со стороны корпоративных пользователей.

Рис. 2: Движение потоков в офисе безопасности VeriSign в отношении обращения с аутсорсинговыми запросами по ордеру (по данным маркетинговых материалов компании) [24]

В 2004 году New York Times раскрыла сведения об отделе слежки этой компании:

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

Для того чтобы сделать прослушивание возможным, компании телефонной интернет-связи должны закупить оборудование и программное обеспечение, также как и нанять техников или заключить контракт с Verisign или одним из их конкурентов. Цена исчисляется миллионами долларов и зависит от размера интернет-телефонной компании и от количества запросов со стороны властей [28]

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

Тем не менее, VeriSign, крупнейший провайдер SSL-сертификатов в мире, включая множество зарубежных банков, компаний и правительств стран, не имеющих дружественных отношений с США, также зарабатывает значительные суммы денег на оказании помощи по раскрытию приватных данных американских пользователей для сил охраны правопорядка США и разведывательных агентств. Уже сам по себе этот факт даёт некоторым зарубежным организациям хороший повод задуматься в выборе своего УЦ.

6.2 Etisalat

Etisalat — это национальный телекоммуникационный сервис-провайдер Объединённых Арабских Эмиратов, который обслуживает 17 стран Азии, Среднего Востока и Африки. Кроме того, что он является тринадцатым в мире оператором по величине мобильных сетей, эта компания также является промежуточным УЦ (доверяемым браузерами через сертификат, выданный корневым УЦ GTE CyberTrust).

В июле 2009 года около 100000 пользователей смартфонов Блэкберри из ОАЭ среди абонентов Etisalat получили обязательный "увеличивающий производительность патч" от поставщика услуг сотовой связи. Патч привлёк внимание прессы тем, что некоторые пользователи жаловались, что он разряжал батареи их телефонов и снижал производительность [29]. После того как исследователи изучили код, они выяснили, что он в действительности содержит программы для слежки, которые мониторят исходящие сообщения электронной почты и посылают скрытые копии на центральный сервер [30]. Как только Etisalat и SS8, компания, основанная в США, которая создавала и продавала прослушивающее ПО, обе компании отказались от комментариев в дискуссиях по этому вопросу, RIM (которая является производителем Blackberry) подтвердила, что это ПО использовалось для скрытого мониторинга пользователей и быстро выпустила патч для удаления этого шпионского ПО [31].

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

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

7. Защита пользователей

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

В попытках существенно снизить урон от такой атаки для конечных пользователей, мы создали Certlock, лёгкое приложение для браузера Firefox. Наше решение выполняет политику доверия на первом использовании (Trust-On-First-Use — TOFU), укреплённую тем, что страна, откуда был выпущен сертификат не сменится в будущем. Наше решение особенно полагается на кэширование информации об УЦ, так что это даёт полномочия пользователю на возможность управление информацией на уровне стран в порядке создания отношений доверия, основанных на здравом смысле.

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

7.1 Мотивации для разработки

Атака создания сертификатов по принуждению — классический случай маловероятного, наносящего большой урон события [32]. Для подавляющего большинства пользователей крайне маловероятно пережить это, но тем, кто с этим столкнётся, будет по-настоящему плохо. В таком случае важно иметь крайне низкое количество ошибочно позитивных срабатываний, даже путём привлечения внимания пользователей к тому, что была детектирована попытка осуществления перенаправления SSL-сессии.

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

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

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

Мы также считаем, что пользователи доверяют УЦ не напрямую. Кроме крупнейших УЦ, таких как VeriSign и крупнейших телекоммуникационных фирм в странах своих регионов (Например, Verizon в США, Deutsche Telekom в Германии или Swisscom в Швейцарии), маловероятно, что пользователи слышали о сотнях компаний, выпускающих сертификаты, которым доверяет их браузер. Так, нет оснований ожидать, что американский пользователь будет делать обоснованный выбор в вопросе доверия сертификату, выданному польской технологической фирмой Unizeto Technologies также как и ожидать от японских пользователей, что они будут доверять сертификату, выданному фирмой QuoVadis с бермудских островов. Однако оба этих эти сертификата являются доверяемыми ведущими браузерами по умолчанию.

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

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

7.2 Доверие по странам

Мы верим, что большинство пользователей вполне способны выработать основные связи доверия на основании доверия по странам. Однако, количество жертв мошенничества в Америке, которые поддаются уловкам послать деньги жуликам в Нигерию, показывает, что не все пользователи готовы к выработке доверия на основании страны.

То есть, американский потребитель, банковские сессии которого в норме зашифрованы сервером, представляющим сертификаты, подписанные УЦ, относящимся к США, может отнестись с подозрением, если ему будет сообшено, что его американский банк теперь использует сертификат, подписанный УЦ из Тайваня, Латвии или Сербии.

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

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

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

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

7.3 Предотвращение ложных срабатываний

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

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

Принимая политику доверия после первого использования (TOFU), мы подразумеваем, что если вэбсайт начинает использовать сертификаты, выданные тем же самым УЦ, который выпустил предыдущие сертификаты, то нет никакой причины предупреждать пользователя. Такой подход облегчает нам достижение возможности значительного снижения количества ложных срабатываний, при этом оказывая малый негативный эффект на нашу способность защищать пользователей от множества угроз.

Мы также полагаем, что существует мало причин для того, чтобы предупреждать пользователя о том, что вэбсайт меняет УЦ в пределах одной и той же страны. Так как наша модель угрозы сфокусирована на государственном противнике, который имеет возможность при желании принуждать любого местного УЦ к выпуску сертификатов, УЦ внутри страны по существу можно рассматривать как равноценные. Это так, потому что правительственное агентство способно вынудить нового УЦ к выпуску сертификата, также легко, как это можно было бы сделать и со старым УЦ для этого же сайта. Поскольку мы уже решили не предупреждать пользователей об этом сценарии (описанном выше), то нет и никакой необходимости предупреждать пользователей в случае смены УЦ в пределах одной и той же страны.

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

7.4 Детали реализации

Наше решение CertLock в текущем виде будет выполнено как приложение к браузеру Firefox.

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

Хэш-отпечаток сертификата.
Страна выпускающего УЦ.
Имя УЦ.
Страна вэбсайта.
Имя вэбсайта.
Полная цепочка доверия до корневого УЦ.

Как только пользователь повторно посещает вэбсайт, защищённый SSL, CertLock сначала вычисляет хэш сертификата сайта и сравнивает его с хэшем, сохранённым от предыдущего посещения. Если он не был изменён, то страница загружается без предупреждения. Если сертификат поменялся, то сравнивается УЦ, который выпускал старый и новый сертификат. Если УЦ тот же или с той же самой страны, то страница загружается без всяких предупреждений. Если же поменялась страна, выдававшая УЦ, то пользователь увидит предупреждение (см. рис. 3).

Рис. 3: Предупреждение, которое выводится пользователям CertLock

На верхнем уровне этот алгоритм довольно простой. Однако есть некоторые тонкие места, в которых требуется некоторая сложность.

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

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

Как только CertLock определяет изменение сертификата, он может также определить тип УЦ, которым был выпущен новый сертификат. Если новый сертификат был выпущен корневым УЦ, то CertLock легко может сравнить страну старого УЦ со страной нового корневого УЦ. Однако, если новый сертификат был выпущен новым промежуточным УЦ, то у нас нет способа точно определить достоверность страны УЦ, выпустившего сертификат.

Например, израильские власти могут вынудить StarCom, израильский УЦ выпустить сертификат промежуточного УЦ, который будет ложным образом отображаться в списке стран промежуточных УЦ как США. Такой промежуточный УЦ будет затем выдавать сертификаты для последующих действий в области слежки. В таком гипотетическом сценарии мы можем представить, что этот мошеннический УЦ выпустит сертификат Bank of America, действительный сертификат которого выпущен VeriSign в США. Когда CertLock просто проверял бы страну УЦ по предыдущему выпущенному сертификату, который был ему доступен для Bank Of America и сравнивал его со страной, выпустившей подложный сертификат от промежуточного УЦ (неверно отображаемого также как из США), то CertLock не заметил бы попытки перехвата. В порядке обнаружения таких мошеннических промежуточных УЦ должны быть проведены более тщательные проверки.

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

8. Анализ

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

8.0.1 Сценарий A 

Действительный УЦ - VeriSign (США)
Принуждаемый УЦ - VeriSign (США)
Вэбсайт - Citibank (США)
Местоположение подозреваемого - США
Власти, осуществляющие слежку - США

В этом сценарии власти США принуждают VeriSign выпустить сертификат для использования органами охраны правопорядка с целью шпионить за коммуникациями между подозреваемым, находящимся в США и Ситибанком — банк, который он использует тоже из США.

Такую атаку засечь при помощи CertLock невозможно, поскольку УЦ, выпускающий подложный сертификат тот же самый, что и выпустивший реальный сертификат. Однако, мы считаем, что такой сценарий крайне маловероятен для того чтобы возникнуть в ходе следствия против конечных пользователей. Это так, поскольку если противник со стороны властей способен получить судебный ордер, принуждающий VeriSign к сотрудничеству, то ему также легко достать судебный ордер, принуждающий Citibank раскрыть информацию о счёте подозреваемого.

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

8.0.2 Сценарий B 

Действительный УЦ - VeriSign (США)
Принуждаемый УЦ - GoDadddy (США)
Вэбсайт - Citibank (США)
Местоположение подозреваемого - США
Власти, осуществляющие слежку - США

В этом сценарии, власти США принуждают GoDaddy, УЦ, находящегося в США к выпуску сертификата для разведывательного агентства, которое хочет шпионить за коммуникациями между подозреваемым, находящимся в США и банком также из США (CitiBank), который получил действительный сертификат от VeriSign.

Так же как и в сценарии A, крайне маловероятно, что такая атака будет осуществлена. Это так, потому что любое правительственное агентство, способное принудить GoDaddy, также способно получить судебный ордер на принуждение VeriSign или Bank of America. Путём сведения по редукции, атакующий, способный на выполнение сценария B, также способен и на сценарий A. CertLock не обнаруживает атаку этого типа.

8.0.3 Сценарий C 

Действительный УЦ - VeriSign (США)
Принуждаемый УЦ - VeriSign (США)
Вэбсайт - Poker.com (США)
Местоположение подозреваемого - США
Власти, осуществляющие слежку - США

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

В этом сценарии, поскольку обе стороны SSL-соединения находятся под следственными мероприятиями властей, то атака с созданием сертификатов по принуждению является высокоэффективным методом скрытого сбора улик. Однако, поскольку выпускающий УЦ не менялся, то CertLock неспособен определить такую атаку и предупредить пользователей.

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

8.0.4 Сценарий D 

Действительный УЦ - VeriSign (США)
Принуждаемый УЦ - CNNIC (Китай)
Вэбсайт - CCB (Китай)
Местоположение подозреваемого - Китай
Власти, осуществляющие слежку - Китай

В этом сценарии гражданин Китая получает доступ к своему онлайновому счёту China Construction Bank, который получил свой действительный сертификат от VeriSign, фирмы из США. Китайские разведслужбы заинтересованы в получении доступа к сетевым транзакциям подозреваемого и для этой цели принуждают China Internet Network Information Center (CNNIC) — местный УЦ, к выпуску сертификата для операции по прослушиванию.

Этот сценарий неидентичен сценарию A, хотя во многом схож. Опять же, если китайские власти способны принудить местного УЦ к сотрудничеству, мы подразумеваем, что им также будет легко заставить сотрудничать китайский банк для того чтобы предоставить информацию о состоянии счёта подозреваемого. Хотя мы считаем этот сценарий маловероятным, даже если он случится, CertLock его обнаружит.

8.0.5 Сценарий E 

Действительный УЦ - VeriSign (США)
Принуждаемый УЦ - CNNIC (Китай)
Вэбсайт - Google Mail (США)
Местоположение подозреваемого - Китай
Власти, осуществляющие слежку - Китай

В этом сценарии американский управляющий посещает Китай в целях ведения бизнеса и пытается получить доступ к своей защищённой, принадлежащей США учётной записи вэбмэйл с использованием интернет-соединения из номера отеля. Китайские власти хотят перехватывать его коммуникации, но поскольку Google использует SSL по-умолчанию для вэбмейл-коммуникаций [36], то власти должны выполнить атаку человека-посредине. Этот сценарий — идеальный кандидат для осуществления атаки создания сертификата по принуждению, поскольку китайские ласти не имеют рычагов влияния для принуждения к сотрудничеству Google или VeriSign. Этот сценарий также легко будет обнаружен CertLock.

8.0.6 Сценарий F 

Действительный УЦ - VeriSign (США)
Принуждаемый УЦ - Verisign (США)
Вэбсайт - CCB (Китай)
Местоположение подозреваемого - США
Власти, осуществляющие слежку - США

В этом сценарии китайский управляющий совершает поездку в США с бизнес-целями и пытается получить доступ к своему счёту в China Construction Bank, используя интернет соединение из своего номера в отеле. Представители американских властей хотят получить доступ к его финансовым записям, но не хотели бы, чтобы китайские власти знали, что их гражданин находится под следственными мероприятиями и поэтому не запрашивают его записи по официальным каналам для правоохранительных органов.

Это сценарий во многом идентичен сценарию E, однако есть одно ключевое отличие: действительный сертификат, используемый китайским банком выдан находящимся в США УЦ и американские власти обращаются к тому же самому УЦ за тем, чтобы он снабдил их подставным сертификатом. Таким образом, хотя этот сценарий и является идеальным кандидатом для проведения атаки с созданием сертификата по принуждению, он не относится к тем, которые бы легко можно выявить при просмотре УЦ на уровне изменений стран. Сам по себе CertLock неспособен выявить атаку этого типа.

8.1 Выигрышные позиции в слежке для Америки

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

В качестве одного примера — крупнейшие банки в Пакистане, Ливане и Саудовской Аравии (страны в которых США имеет сильный разведывательный интерес) все используют сертификаты, выпущенные VeriSign, для своих сетевых банковских серверов.

Пока зарубежные вэбсайты продолжают опираться на SSL-сертификаты, выпущенные УЦ, находящимися в США, американские власти будут сохранять возможность проведения атак человека-посредине, которые практически невозможно обнаружить. Закрытие этой бреши находится за пределами сферы этой работы, но к счастью организации могут легко решить это сами — переключившись на местный УЦ (или по крайней мере на один из размещающихся в стране, властям которой они доверяют).

9. Схожие работы

Кай Энгерт создал Conspiracy, приложение для Firefox, предоставляющее информацию об УЦ по странам для конечных пользователей в порядке их защиты от атак создания сертификатов по принуждению. Conspiracy отображает флаг страны для каждого УЦ в цепочке доверия в статусной панели браузера [37]. Тем самым пользователи могут сами запомнить страну каждого УЦ, выпустившего сертификат и определить, если страны поменялись. Мы полагаем, что это необоснованное бремя, взваливаемое на конечных пользователей, в частности учитывая как редко они могут встретиться с атакой создания сертификатов по принуждению.

Вэндлант и др. создали Perspectives, приложение Firefox, которое улучшает модель доверия после первого использования (TOFU) для использования в вэбсайтах, которые снабжены самоподписанными сертификатами [38]. В его системе пользовательский браузер осуществляет безопасное соединение с одним из множества нотариальных серверов, которые независимо обращаются к вэбсерверу для получения сертификата. В случае когда атакующий пытается осуществить атаку человека-посредине против пользователя, различие в сертификатах между внедрённым от атакующего и между полученным от нотариальных серверов Perspectives служит серьёзным индикатором того, что произошло что-то неладное.

К сожалению система Perspectives требует от пользователя предоставить нотариусам Perspectives список защищённых сайтов, которые они посещают в реальном времени.

Современные браузеры уже и так создают утечку информации в плане посещаемых пользователем вэб-сайтов, так как они автоматически соединяются с УЦ в порядке определения, что сертификат не был отозван (при помощи OCSP протокола). Поскольку это в настоящее время неизбежно, мы хотим избежать утечку приватных данных пользователя любым дополнительным сторонам.

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

Эличерри и Керомитис улучшили дизайн Perspectives с помощью системы DoubleCheck [39], подставляющую для специальных нотариальных серверов исходящие узлы сети Tor. Поскольку сеть Tor анонимизирует IP-адреса индивидуальных пользователей, для исходящего узла сети Tor нет способа определить, кто запрашивал сертификат для определённого вэб-сайта. Хотя авторы решили большую проблему с приватностью, терзавшую схему Perspectives, их выбор Tor заставил заплатить за это задержками. Их система добавляет дополнительные секундные задержки для каждого нового SSL-соединения и доходит до 15 секунд для посещения сервера с самоподписанным сертификатом. Мы верим что эта дополнительная задержка слишком высока, чтобы пользователи её терпели, особенно в свете того, что шансы встретиться с подставным УЦ так низки.

В мае 2008 года исследователь в области безопасности обнаружил, что библиотека OpenSSL в некоторых популярных дистрибутивах Linux генерирует криптографически слабые ключи. Хотя уязвимость двухгодичной давности была закрыта, SSL-сертификаты, создаваемые на компьютерах, на которых запускался уязвимый код, были сами по себе доступны для атаки [40, 41]. В ответ на эту уязвимость, немецкий журнал технологий Heise реализовал Heise SSL Guardian для ОС Windows, который предупреждал пользователь Internet Explorer и Chrome, когда им попадались уязвимые SSL-сертификаты [42].

В декабре 2008 года Стивенс и др. продемонстрировали, что уязвимость в алгоритме MD5 также может быть использована для создания подложного SSL-сертификата (без знания или помощи УЦ). В ответ, УЦ ускорили планируемые защитные меры перехода. Mґrton Anka разработал приложение для Firefox, обнаруживающее и предупреждающее пользователей о цепочках сертификатов, использующих алгоритм MD5 для подписей RSA [43].

10. Выводы и будущие исследования

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

Наше приложение к браузеру в настоящий момент всего лишь прототип и мы планируем улучшить его в будущем. Во первых, наш существующий предупреждающий диалоговый текст далёк от идеала и может быть значительно улучшен с помощью экспертов по удобству пользования ПО. Мы также планируем изучить возможность расширения модели использования стран до регионов, таких как Европейский Союз, где например жители Франции могут доверять испанским УЦ. Наконец, мы рассматриваем возможность пользователям добровольно отправлять потенциально подозрительные сертификаты на центральный сервер, где они могли бы быть изучены экспертами. Возможность такого рода, до тех пор пока она только опциональна, не собирает никаких идентифицирующих данных о пользователе и срабатывает, только когда раскрываются потенциально фальшивые сертификаты, что имеет мало или никаких проблем с приватностью.

В конечном итоге угрозы, представляемые атакой создания сертификатов по принуждению, не могут быть полностью исключены только с помощью приложения к браузеру. Система УЦ неполноценна на фундаментальном уровне и должна быть пересмотрена. DNSSEC может играть важную роль в решении данной проблемы, по крайней мере в уменьшении количества субъектов, которые могут быть принуждаемы к нарушению пользовательского доверия. Неважно какая система в конечном итоге заменит текущую, сообщество безопасности должно рассматривать атаку создания сертификатов по принуждению, осуществляемую для сотрудничества с властями, как реалистичную угрозу и гарантировать, что решение должно быть устойчиво к такой атаке.

Ссылки на использованные материалы

[1] Adi Shamir. Cryptography: State of the sci-
ence. ACM A. M. Turing Award Lecture, June
8 2003. awards.acm.org/images/awards/
140/vstream/2002/S/s- pp/shamir_1files_
files/800x600/Slide8.html.

[2] Ryan Singel. PGP Creator Defends Hushmail.
Wired News Threat Level Blog, November 19
2007. www.wired.com/threatlevel/2007/11/
pgp- creator- def.

[3] Johnathan Nightingale. SSL Question Cor-
ner. meandering wild ly (blog), August 5
2008. blog.johnath.com/2008/08/05/ssl-
question- corner/.

[4] Joshua Sunshine, Serge Egelman, Hazim Al-
muhimedi, Neha Atri, and Lorrie F. Cranor.
Crying wolf: An empirical study of SSL warn-
ing effectiveness. In Proceedings of the 18th
Usenix Security Symposium, August 2009.

[5] Ed Felten. Web Certification Fail: Bad
Assumptions Lead to Bad Technol-
ogy. Freedom To Tinker, February 23
2010. www.freedom- to- tinker.com/blog/
felten/web- certification- fail- bad-
assumptions- lead- bad- technology.

[6] Mozilla. Potentially problematic CA practices
, 2010. wiki.mozilla.org/CA:Problematic_
Practices.

[7] Microsoft Root Certificate Program, January
15 2009. technet.microsoft.com/en- us/
library/cc751157.aspx.

[8] Mozilla CA Certificate Policy (Version 1.2).
www.mozilla.org/projects/security/
certs/policy/.

[9] Apple Root Certificate Program.
www.apple.com/certificateauthority/
ca_program.html.

[10] Craig Spiezle. Email conversation with author,
February 15 2010.

[11] Marc Stevens, Alexander Sotirov, Jacob Appel-
baum, Arjen Lenstra, David Molnar, Dag Arne
Osvik, and Benne Weger. Short chosen-prefix
collisions for MD5 and the creation of a rogue
CA certificate. In Proceedings of the 29th An-
nual International Cryptology Conference on
Advances in Cryptology, pages 5569, Berlin,
Heidelberg, 2009. Springer-Verlag.

[12] Marsh Ray and Steve Dispensa.
Renegotiating tls, November 4 2009.
extendedsubset.com/wp- uploads/2009/
11/renegotiating_tls_20091104_pub.zip.

[13] Stuart E. Schechter, Rachna Dhamija, Andy
Ozment, and Ian Fischer. The emperor's new
security indicators. In SP '07: Proceedings
of the 2007 IEEE Symposium on Security and
Privacy, pages 5165, Washington, DC, USA,
2007. IEEE Computer Society.

[14] Moxie Marlinspike. sslsniff, July 3 2009. www.
thoughtcrime.org/software/sslsniff/.

[15] Moxie Marlinspike. sslsniff, December 18
2009. www.thoughtcrime.org/software/
sslstrip/.

[16] Windows Root Certificate Program Members,
November 24 2009. download.microsoft.
com/download/1/4/f/14f7067b- 69d3- 473a-
ba5e- 70d04aea5929/windows\%20root\
%20certificate\%20program\%20members.
pdf.

[17] Christopher Soghoian. Caught in the cloud:
Privacy, encryption, and government back
doors in the web 2.0 era. In Journal on
Telecommunications and High Technology Law,
Forthcoming.

[18] Declan McCullagh. Court to FBI: No spying
on in-car computers. CNET News, Novem-
ber 19 2003. news.cnet.com/2100- 1029_3-
5109435.html.

[19] John Markoff. Surveillance of skype messages
found in china. The New York Times, Octo-
ber 1 2008. www.nytimes.com/2008/10/02/
technology/internet/02skype.html.

[20] Andrew Jacobs. China requires censorship soft-
ware on new pcs. The New York Times, June 8
2009. www.nytimes.com/2009/06/09/world/
asia/09china.html.

[21] Christopher Soghoian. 8 Million Reasons for
Real Surveillance Oversight. Slight Paranoia
blog, December 1 2009. paranoia.dubfire.
net/2009/12/8- million- reasons- for-
real- surveillance.html.

[22] Kim Zetter. Feds `Pinged' Sprint GPS Data 8
Million Times Over a Year. Wired News Threat
Level Blog, December 1 2009. www.wired.com/
threatlevel/2009/12/gps- data/.

[23] Packet Forensics. Export and Re-Export Re-
quirements, 2009. www.packetforensics.
com/export.safe.

[24] VeriSign. Netdiscovery service sub-
poena processing and handling, 2004.
www.verisign.com/stellent/groups/
public/documents/data_sheet/001928.pdf.

[25] Why VeriSign. www.verisign.com/ssl/why-
verisign/index.html.

[26] VeriSign Case Study. VeriSign helps an inno-
vative broadband telephony provider focus on
core business goals, October 16 2006. www.
verisign.com/static/039933.pdf.

[27] VeriSign. Cox communications: Complying
with CALEA regulations in a cost-effective
manner, while expanding services, 2004. www.
verisign.com/stellent/groups/public/
documents/success_stories/002378.pdf.

[28] Ken Belson. The call is cheap. the wiretap
is extra.; enlisting internet phones in the
battle against crime. The New York Times,
August 23 2004. www.nytimes.com/2004/08/
23/business/call- cheap- wiretap- extra-
enlisting- internet- phones- battle-
against- crime.html.

[29] Kim Zetter. Researcher: Middle East
Blackberry Update Spies on Users. Wired
News Threat Level Blog, July 14 2009.
www.wired.com/threatlevel/2009/07/
blackberry- spies/.

[30] Chris Eng. BlackBerry Spyware Dis-
sected. Veracode: Zero in a bit, July
15 2009. www.veracode.com/blog/2009/07/
blackberry- spyware- dissected/.

[31] RIM. RIM Customer Statement Regarding
Etisalat / SS8 Software, July 19 2009.
www.securityprivacyandthelaw.com/
uploads/file/RIM%20Statement.pdf.

[32] Matthieu Bussiere and Marcel Fratzscher. Low
probability, high impact: Policy making and
extreme events. Journal of Policy Modeling,
30(1):111121, 2008.

[33] Cormac Herley. So long, and no thanks for the
externalities: the rational rejection of security
advice by users. In NSPW '09: Proceedings of
the 2009 workshop on New security paradigms
workshop, pages 133144, September 2009.

[34] Certificate patrol, 2010. patrol.psyced.org/.
[35] Dan Kaminsky. Email conversation with au-
thor, February 28 2010.

[36] Sam Schillace. Default https access for
Gmail. The Official Gmail Blog, January
12 2010. gmailblog.blogspot.com/2010/01/
default- https- access- for- gmail.html.

[37] Kai Engert. Conspiracy — A Mozilla Fire-
fox Extension, March 18 2010. kuix.de/
conspiracy/.

[38] Dan Wendlandt, David G. Andersen, and
Adrian Perrig. Perspectives: improving ssh-
style host authentication with multi-path prob-
ing. In ATC'08: USENIX 2008 Annual Tech-
nical Conference on Annual Technical Confer-
ence, pages 321334, Berkeley, CA, USA, 2008.
USENIX Association.

[39] Mansoor Alicherry and Angelos D. Keromytis.
Doublecheck: Multi-path verification against
man-in-the-middle attacks. In ISCC 2009:
IEEE Symposium on Computers and Com-
munications, pages 557563, Piscataway, NJ,
USA, 2009. IEEE.

[40] David Ahmad. Two Years of Broken Crypto:
Debian's Dress Rehearsal for a Global PKI
Compromise. IEEE Security and Privacy, 6:70­
73, September 2008.

[41] Scott Yilek, Eric Rescorla, Hovav Shacham,
Brandon Enright, and Stefan Savage. When
private keys are public: results from the 2008
Debian OpenSSL vulnerability. In Proceedings
of the 9th ACM SIGCOMM conference on In-
ternet measurement conference, pages 1527,
New York, NY, USA, 2009. ACM.

[42] The H Security. heise SSL Guardian:
Protection against unsafe SSL certifi-
cates, July 4 2008. www.h- online.com/
security/features/Heise- SSL- Guardian-
746213.html.

[43] Mґrton Anka.
a SSL Blacklist 4.0, Jan-
uary 31 2010. www.codefromthe70s.org/
sslblacklist.aspx.

Кристофер Согоян и Сид Стэмм © 2010.
Перевод © 2010 unknown