|
Протокол SSL (secure socket layer) был разработан фирмой Netscape, как протокол обеспечивающий защиту данных между сервисными протоколами (такими как HTTP, NNTP, FTP и т.д.) и транспортными протоколами (TCP/IP). Не секрет, что можно без особых технических ухищрений просматривать данные, которыми обмениваются между собой клиенты и серверы. Был даже придуман специальный термин для этого _ Tsniffer. А в связи с увеличением объема использования Интернета в коммерческих целях, неизбежно вставал вопрос о защите передаваемых данных. И пользователи не очень были бы рады, если номер их кредитной карточки, был бы перехвачен, каким ни будь предприимчивым хакером Tпо дороге к виртуальному магазину. И, в общем, появление такого протокола как SSL было вполне закономерным явлением. С одной стороны остаются все возможности сервисных протоколов (для программ-серверов), плюс к этому все данные передаются в зашифрованном виде. И разкодировать их довольно трудно. Опустим здесь возможности взлома SSL (она, безусловно, есть, но это отдельная тема для большой статьи). Следует отметить, что SSL не только обеспечивает защиту данных в Интернете, но так же производит Tопознание_ сервера и клиента (Tserver/client authentication_). В данный момент протокол SSL принят W3 консорциумом (W3 Consortium) на рассмотрение, как основной защитный протокол для клиентов и серверов (WWW browsers and servers) в сети Интернет.
Алгоритм работы SSL построен на принципе публичных ключей. Этот принцип построен на использовании пары асимметричных ключей (публичном и приватном) для кодирования/декодирования информации. Публичный ключ раздается всем желающим. И с его помощью шифруются необходимые данные, которые можно дешифровать только с помощью приватного ключа. Отходя от темы, можно сказать, что так оно выглядит в теории. На практике все несколько менее строго. Из-за юридических ограничений на длину ключей, они поддаются взлому, хотя для этого и необходимы достаточно большие вычислительные мощности.
Теперь рассмотрим, каким образом все-таки работает SSL.
Представьте себе, что есть два человека, которые общаются посредством Интернета и соответственно не видят друг друга. И лишены возможности, узнать, о том кто же его абонент. Их имена _ Алиса и Боб. Допустим Алисе надо, узнать действительно она разговаривает с Бобом или нет. В этом случае диалог может выглядеть следующим образом:
- Алиса отправляет Бобу случайное сообщение.
- Боб шифрует его с помощью своего приватного ключа и отправляет его Алисе.
- Алиса дешифрует это сообщение (с помощью публичного ключа Боба). И сравнив это сообщение с посланным, может убедиться в том, что его действительно послал Боб.
Но на самом деле со стороны Боба не очень удачная идея шифровать сообщение от Алисы с помощью своего приватного ключа. И возвращать его. Это аналогично подписи документа, о котором Боб мало что знает. С такой позиции Боб должен сам придумать сообщение. И послать его Алисе в двух экземплярах. В первом сообщение передается открытым текстом, а второе сообщение зашифровано с помощью приватного ключа Боба. Такое сообщение называется message digest. А способ шифрования сообщения с помощью своего приватного ключа _ цифровой подписью (digital signature).
Теперь закономерно встает вопрос о том, каким образом распространять свои публичные ключи. Для этого (и не только) была придумана специальная форма - сертификат (certificate). Сертификат состоит из следующих частей:
- Имя человека/организации выпускающего сертификат.
- Для кого был выпущен данный сертификат (субъект сертификата).
- Публичный ключ субъекта.
- Некоторые временные параметры (срок действия сертификата и т.п.).
Сертификат Tподписывается_ приватным ключом человека (или огрганизации), который выпускает сертификаты. Организации, которые производят подобные операции называются _ TCertificate authority (CA). Если в стандартном Web-клиенте (web-browser), который поддерживает SSL, зайти в раздел security. То там можно увидеть список известных организаций, которые Tподписывают_ сертификаты. С технической стороны, создать свою собственную CA достаточно просто. Но против этого могут действовать скорее юридические препятсвия.
Теперь рассмотрим, каким образом происходит обмен данными в Интернете. Воспользуемся все теми же действующими лицами.
- Алиса: привет.
- Боб: привет, я Боб (выдает свой сертификат).
- Алиса: а ты точно Боб?
- Боб: Алиса я Боб. (Сообщение передается два раза, один раз в открытую, второй раз, зашифрованный с помощью приватного ключа Боба).
- Алиса: все нормально, ты действительно Боб. (И присылает Бобу секретное сообщение, зашифрованное с помощью публичного ключа Боба).
- Боб: А вот и мое сообщение (посылает сообщение, которое было зашифровано с помощью секретного ключа, например того же шифрованного сообщения Алисы).
Поскольку Боб знает сообщение Алисы, потому что он владеет приватным ключом и Алиса знает, что было в том сообщении. Теперь они могут использовать симметричный шифровальный алгоритм (где в качестве секретного ключа выступает сообщение Алисы) и безбоязненно обмениваться шифрованными сообщениями. А для контроля над пересылкой сообщений (от случайного/преднамеренного изменения) используется специальный алгоритм - Message Authentication Code (MAC). Довольно распространенным является алгоритм MD5. Обычно, и сам MAC-code так же шифруется. В связи с этим достоверность сообщений повышается в несколько раз. И внести изменения в процесс обмена практически невозможно.
Теперь несколько слов о реализации SSL. Наиболее распространенным пакетом программ для поддержки SSL _ является SSLeay. Последняя версия (SSLeay v. 0.8.0) поддерживает SSLv3. Эта версия доступна в исходных текстах. И без особых проблем устанавливается под UNIX (я не пробовал ставить SSLeay под операционные системы фирмы Microsoft). Этот пакет предназначен для создания и управления различного рода сертификатами. Так же в его состав входит и библиотека для поддержки SSL различными программами. Эта библиотека необходима, например, для модуля SSL в распространенном HTTP сервере _ Apache. Если Вы устанавливаете версию, вне США, то особых проблем с алгоритмом RSA быть не должно. Но только накладывается ограничение на длину ключа в 40 бит (возможно, на данный момент это ограничение снято, но на пакете SSLeay это никоим образом не отразилось. Действеут это ограничение и на другой пакет от фирмы Netscape - SSLRef). А вот если компьютер с SSLeay находится на территории США, то за использование алгоритма RSA необходимо заплатить какие то деньги. Но об этом нужно разговаривать с самой фирмой RSA Data Security Inc. Я точно не знаю, но по слухам необходимо регистрировать сертификаты в ФСБ. Если кто обладает такой информацией, всегда буду рад узнать.
Подводя итоги, можно сказать, что SSL просто необходим в сфере коммерческого Интернета, особенно там, где нужно обеспечить конфиденциальность данных. На самом деле решение о том насколько необходим такой канал, должен принимать администратор Web-узла. По своему опыту могу сказать, что особо ощутимой нагрузки на сервер, при использовании SSL, не наблюдается. |
