Рис. 8.46. Передача данных при использовании SSL

Следует остерегаться следующего подводного камня: уже говорилось о том, что RC4 имеет некоторые слабые ключи, которые довольно просто взламываются, поэтому SSL с RC4 — это довольно шаткая основа (Fluhrer и др., 2001). Браузеры, позволяющие пользователю выбирать тот или иной шифр, лучше всего настраивать на постоянное использование тройного алгоритма DES со 168-разрядными ключами и SHA-1, невзирая на то, что такая комбинация работает еще медленнее, чем RC4 + MD5. Или можно использовать браузеры, поддерживающие преемника SSL, которого мы коротко опишем.

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

В 1996 году корпорация Netscape Communications направила SSL на стандартизацию в IETF. Результатом стал стандарт TLS (Transport Layer Security — защита транспортного уровня). Он описан вRFC 5246.

TLS был построен на SSL, версия 3. В SSL при создании стандарта TLS было внесено не так уж много изменений, однако их оказалось достаточно для того, чтобы SSL версии 3 и TLS стали несовместимыми. Например, в целях усиления ключа был изменен способ вычисления ключа сеанса по подготовительному ключу и нонсам. Из-за этой несовместимости большинство браузеров применяют оба протокола, и TLS превращается обратно в SSL, если это необходимо. Это называется SSL/TLS. Впервые TLS был применен в 1999 году, версия 1.2 появилась в августе 2008 года. Она включает поддержку более сильных наборов шифров (в том числе AES). SSL продолжает удерживать сильные рыночные позиции, хотя, вероятно, TLS постепенно его заменит.

8.9.4. Безопасность переносимых программ

Именование ресурсов и соединения — это две области, которые, несомненно, тесно связаны с защитой информации во Всемирной паутине. Однако существуют и другие, не менее важные вопросы, связанные с той же темой. Поначалу веб-страницы представляли собой полностью статические HTML-файлы и не содержали исполняемый код. Теперь же на веб-страницах очень часто встречаются небольшие программы: Java-апплеты, управляющие элементы ActiveX, скрипты JavaScript. Загрузка и выполнение таких переносимых программ (mobile code), очевидно, связана с большим риском для безопасности. Были разработаны различные методы, направленные на минимизацию этого риска. Ниже мы обозначим некоторые вопросы, связанные с проблемами, возникающими из-за переносимых программ, и некоторые подходы к обращению с ними.

Безопасность Java-апплетов

Java-апплеты — это небольшие программы на языке Java, откомпилированные в машинный язык со стековой организацией под названием JVM (Java Virtual Machine — виртуальная машина Java). Такие программы могут размещаться на веб-странице и загружаться вместе с ней. После загрузки страницы апплеты обрабатываются интерпретатором JVM в браузере, как показано на рис. 8.47.

Рис. 8.47. Апплеты могут интерпретироваться веб-браузером

Преимущество интерпретируемого кода перед компилируемым состоит в том, что перед исполнением изучается каждая инструкция. Это дает интерпретатору возможность проверить состоятельность адреса инструкции. Кроме того, системные вызовы также перехватываются и интерпретируются. Как именно они обрабатываются, зависит от политики защиты информации. Например, если апплет надежный (например, он был создан на локальном диске), его системные вызовы могут обрабатываться без дополнительных проверок. Если же апплет не может считаться надежным (например, он был загружен из Интернета), его можно поместить в так называемую песочницу (sandbox), регулирующую его поведение и пресекающую его попытки использовать системные ресурсы.

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

ActiveX

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

Для принятия таких решений корпорацией Microsoft был выбран метод, базирующийся на подписях кода (code signing). Суть в том, что каждый элемент ActiveX снабжается цифровой подписью, а именно, хэшем кода, подписанным его создателем с использованием открытого ключа. Когда браузер встречает управляющий элемент, он вначале проверяет правильность подписи, убеждаясь в том, что код не был заменен по дороге. Если подпись корректна, браузер проверяет по своим внутренним таблицам, можно ли доверять создателю программы. Возможно, про самого создателя ничего не известно, но существует цепочка заверений, ведущая к какому-либо известному своей надежностью разработчику. Если создатель надежный, программа выполняется, в противном случае игнорируется. Система, созданная Microsoft для проверки управляющих элементов ActiveX, называется Authenticode.

Полезно противопоставлять друг другу подходы Java и ActiveX. В первом случае не производятся никакие попытки установить авторство апплета.

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

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

JavaScript

В JavaScript вообще отсутствует какая-либо официальная модель системы защиты информации, зато существует длинная история неудачных попыток ее внедрения. Каждый производитель пытается придумать что-нибудь свое. Например, в Netscape Nvigator версии 2 было реализовано нечто подобное Java-модели, а уже в четвертой версии прослеживаются черты модели подписей кода.