Инфраструктуры открытых ключей
Передача сертификатов браузерам
Так как сертификат открытого ключа предоставляет подтверждение личности, разумно предположить, что уровень подтверждения, необходимый для клиента, гораздо ниже уровня, необходимого для сервера.
Перед предоставлением сертификата сервера CA потребует документальное подтверждение законности запроса. Для клиента это доказательство зачастую может быть предоставлено online, потому что в этом случае требуется более низкий уровень проверки. Это особенно справедливо для интранет-среды. Сертификационные серверные продукты первоначально предназначались для тех организаций, которые хотели настроить процесс внутренней аутентификации.
Браузер Netscape для инициирования запроса сертификата клиента использует механизм, отличный от механизмов, применяемых в других браузерах (таких, как Mozilla, IE, Lynx и т. д.).
В случае Netscape ключом механизма является тег <KEYGEN>, расширение HTML, которое применяется только в форме. Когда браузер видит этот тег, он генерирует пару ключей и возвращает запрос сертификата (в формате PKCS #10) для пары ключей с формой центру сертификации. CA обрабатывает запрос сертификата и отправляет его обратно как подписанный сертификат X.509 v3 в специальном MIME-формате (известном как формат PKCS #7), который может принять браузер.
В случае других браузеров, к примеру Internet Explorer, единственным отличием в процессе запроса сертификата является то, что IE требует установки управляющего элемента регистрации сертификатов ActiveX (CERTENR3.DLL для IE 3.0 и XENROLL.DLL для IE 4.0). Этот управляющий элемент ActiveX генерирует открытый/секретный ключи и шифрует их в формат PKCS #7 для CA точно таким же образом, как это делает Netscape.
6.2.6 Центр сертификации Domino
Помимо разъяснения понятия центра сертификации (Certificate Authority) в разделе о компонентах PKI, в предыдущем разделе мы увидели, что CA является связующим звеном, которое позволяет серверу и клиенту использовать протокол SSL. CA также является связующим звеном при обмене безопасными сообщениями электронной почты (такими, как S/MIME, которые мы кратко описали).
Существует возможность использовать третью сторону, коммерческий орган сертификации одной из упомянутых ранее компаний. В качестве альтернативы можно использовать центр сертификации Domino как внутренний CA для всей организации. За подробностями о настройке центра сертификации Domino 6 и обо всем процессе генерирования связок ключей, а также о сертификатах X.509 сервера и клиента (используемых для SSL-аутентификации и S/MIME) обратитесь к документу IBM (IBM Redpaper) The Domino Certification Authority, REDP (Центр сертификации Domino).
6.2.7 Безопасный обмен сообщениями в Интернете
Бурное развитие применения в Интернете электронной почты является результатом упрощенного характера используемых протоколов. Данный факт является палкой о двух концах: простота в управлении гарантирует, что текущие стандарты обмена сообщениями хорошо подходят для миллионов пользователей; однако простота в исполнении имеет своим результатом множество открытых брешей и уязвимостей в обеспечении безопасности.
Сертификаты X.509 v3 помогают обеспечить не только безопасные каналы связи с использованием протокола SSL, но также и безопасный обмен сообщениями для множества других интернет-приложений, причем для основных из них. Этот вид использования, вместе с некоторыми расширениями существующих стандартов, устраняет некоторые из существующих брешей и уязвимостей и даже может предоставлять средства обеспечения безопасности при передаче, приеме и проверке достоверности сообщений электронной почты, содержащих чувствительную информацию.
В этом разделе мы опишем средства, предлагающие обеспечить безопасный обмен сообщениями между клиентами электронной почты в Интернете, а именно опишем, как реализована эта безопасность обмена сообщениями, когда Lotus Notes используется как интернет-клиент обмена сообщениями, а Domino является интернет-сервером обмена сообщениями.
Перед тем как сделать это, давайте все-таки выполним краткий обзор технологий и стандартов, вовлеченных в основной процесс обмена сообщениями в Интернете.
Обычно используемые почтовые протоколы
Для отправки и получения почты в Интернете обычно употребляются следующие интернет-протоколы.
SMTP
SMTP (Simple Mail Transport Protocol) определяет протокол для отправки сообщений электронной почты между хостами, хотя при использовании службы доменных имен DNS (Domain Name Service) и записей Mail eXchange (MX) он может предлагаться для отправки сообщений электронной почты пользователям между доменами.
Большинство систем электронной почты, которые отправляют почту по Интернету, используют для отправки сообщений с одного сервера на другой протокол SMTP. В дополнение к этому протокол SMTP, как правило, применяется для отправки сообщений от почтового клиента к почтовому серверу. Любой хост, который поддерживает SMTP, может также работать как ретранслятор SMTP, и в этом случае он может пересылать сообщения другому SMTP-хосту.
SMTP поддерживает только 7-битовые символы ASCII, что означает отсутствие поддержки выделенных символов, иностранных символьных наборов, обогащенного текста и чего-либо двоичного по своей сущности, например изображений и видео.
MIME
MIME (Multipurpose Internet Mail Extensions) являются спецификацией для форматирования сообщений, которые не являются сообщениями ASCII, для обеспечения возможности их отправки по Интернету.
Как упоминалось ранее, одной из проблем исходной спецификации SMTP было предположение о том, что сообщения электронной почты будут состоять в основном из текста, и соответственно в ней поддерживается только открытый текст ASCII.
MIME расширяет эту спецификацию за счет разрешения "переупаковки" двоичных данных в текстовую форму и передачи их по Интернету в почтовых сообщениях, которые совместимы с исходной спецификацией.
Если проводить сравнение, то сообщение электронной почты, которое поддерживает MIME, будет иметь дополнительную информацию в заголовке после поля Subject. Здесь приведен пример подобного сообщения.
From: frederic.dahm@ch.ibm.com To: roger.guntli@ch.ibm.com Subject: Map of Western Canada… MIME-Version: 1.0 Content-Type: image/gif Content-Transfer-Encoding: base64 Content-ID: Content-Description: […JPEG data…]
Практически каждый клиент электронной почты поддерживает стандарт MIME, что позволяет им отправлять и получать графические, аудио- и видеофайлы посредством инфраструктуры обмена сообщениями в Интернете. В дополнение к этому, как уже упоминалось, MIME также поддерживает сообщения, представленные наборами символов, отличных от ASCII.
POP
POP и IMAP (который мы опишем следующим) являются протоколами, которые определяют доступ к почте из почтового ящика в Интернете или с почтовой станции.
Почтовый протокол POP (Post Office Protocol) версии 3 (POP3) используется для приема электронной почты в сети. Не все компьютерные системы, которые применяют электронную почту, подключены к Интернету 24 часа в сутки, 7 дней в неделю. Некоторые пользователи звонят поставщику услуг по мере необходимости, в то время как другие могут быть подключены к ЛВС с постоянным соединением с Интернетом, но их рабочие станции могут быть не всегда включены.
В подобных случаях электронная почта, адресованная пользователям этих систем, отправляется центральной почтовой системе электронной почты, где она сохраняется для пользователей до тех пор, пока они не смогут ее принять.
POP3 дает возможность пользователю подключиться к почтовой системе электронной почты по сети. Почтовая система производит аутентификацию пользователя с применением ID и пароля, после чего позволяет скачать почту и, по выбору, удалить почту, находящуюся в центральной почтовой системе.
IMAP
IMAP4 (Internet Message Access Protocol, версия 4, известный также как протокол интерактивного доступа к электронной почте (Interactive Mail Access Protocol)) является более новым протоколом, используемым клиентами электронной почты для извлечения сообщений электронной почты с почтового сервера и работы с почтовыми ящиками на сервере.
Последняя версия, IMAP4, подобна POP3, но предлагает дополнительные и более сложные возможности. С помощью IMAP, к примеру, можно работать с электронной почтой на сервере, проводить сортировку и управление электронной почтой, находящейся в папках на сервере.
За дополнительной информацией о IMAP обратитесь к Web-странице Стэнфордского университета, находящейся по следующему адресу:
http://www-camis.stanford.edu/projects/imap/ml/imap.html
Проблемы с данными протоколами
Как упоминалось ранее, простота этих протоколов означает, что они создают проблемы в обеспечении безопасности для любого, кто отправляет и принимает почту посредством Интернета.
SMTP
Протокол SMTP не использует какого-либо процесса аутентификации при установке связи с другим SMTP-хостом для передачи и доставки почты.
По существу, отправляющий хост посылает принимающему SMTP-хосту команду, содержащую информацию о том, кто он такой, и о его желании взаимодействовать. Принимающий хост доверяет тому, кто сказал, кто он такой, и ожидает дальнейших команд. После этого отправляющий хост посылает другую команду, содержащую информацию о том, от кого почта, и эту команду снова получает принимающий SMTP-хост. После этого отправляющий хост посылает другую команду, содержащую информацию о том, кто является вероятным получателем этой почты, и эту команду также получает принимающий SMTP-хост. После этого отправляющий хост посылает команду, сообщающую о том, что следует в текстовом сообщении, причем конец строки сообщения уведомляет о завершении сообщения.
Как можно видеть, при таком сценарии любой, имеющий в своем распоряжении сетевой сниффер, может получить сведения о таком трафике в сети, так как весь он отправляется в виде открытого текста. Что еще хуже, любому человеку достаточно просто сфальсифицировать сообщение на любом SMTP-сервере. Очень легко инициировать связь с SMTP-хостом и представить все так, будто почта была отправлена кем-то другим.
Насколько все это просто, демонстрирует следующий пример. При подключении к SMTP-хосту с использованием TELNET по порту 25 и отправке команд, которые ожидает принимающий SMTP-хост, мы можем сфальсифицировать сообщение электронной почты:
Telnet <SMTP host> 25 HELO foobar.com MAIL FROM: <reverse-path> RCPT TO: <forward-path> DATA SEND FROM: whatever.address@you.like
POP
Исходная спецификация POP3 не определяет каких-либо методов аутентификации. Подобно SMTP, информация между клиентом POP3 и сервером POP3 отправляется открытым текстом. Фактически команды USER и PASS применяются для передачи имени пользователя и пароля при использовании для авторизации при подключении к серверу POP3 в целях получения почты. За дополнительной информацией об этом мы рекомендуем вам обратиться к RFC 1725 – Post Office Protocol – Version 3.
Усовершенствование данных протоколов
Существуют определенные усовершенствования, сделанные в этих протоколах для преодоления некоторых технических ограничений относительно вопросов обеспечения ИT-безопасности, однако все это еще далеко от совершенства, как мы и покажем в процессе последующего обсуждения.
POP
В протокол были внесены изменения в метод аутентификации между клиентом и сервером, включая более новые и более безопасные методы аутентификации, такие, как S/KEY, GSSAPI, APOP и Kerberos V4. Однако эти методы на текущий момент не получили широкой поддержки в Интернете.
IMAP
IMAP4 также предоставляет дополнительные механизмы аутентификации, такие, как Kerberos V4.
SSL
При связи с использованием POP3 или IMAP4 для шифрования сеанса существует возможность применять SSL. Это позволяет решить проблему слабых схем аутентификации, используемых в POP3 и IMAP4.
SASL
SASL (Simple Authentication and Security Layer (SASL)) определен в RFC 2222. Он описывает метод добавления поддержки аутентификации к протоколам на основе соединения. Каждый протокол, который использует SASL, включает команду для идентификации и авторизации пользователя на сервере и необязательного проведения переговоров об уровне безопасности при последующих взаимодействиях в рамках протокола.
Разработчики протоколов хотят использовать спецификацию SASL для поддержки аутентификации в своих протоколах (к примеру, расширение SMTP для проведения аутентификации является профилем SASL).
Domino применяет SASL только для служб LDAP. Domino использует SASL автоматически, если SSL – вместе с аутентификацией клиента – настроен на сервере и если клиент LDAP поддерживает протокол. В этом случае дополнительная конфигурация не нужна.