Как известно, одной из самых удачных во всех отношениях форм шифрования является асимметричное, при котором используются два ключа - публичный и секретный. Но большинство пользователей не имеют инструментов для осуществления защиты своей информации таким способом, не хотят вникать в тонкости процесса, не желают возиться с ключами или просто не осведомлены о подобных технологиях.
С позиции большинства пользователей опасности перехвата информации не существует или они об этом никогда не задумывались. Многие считают, что опасность возможно и есть, но хранимая и передаваемая ими информация представляет мало ценности для третьих лиц. Всё это более чем понятно и, естественно, потребителям свойственно потребительское отношение, а обеспечить безопасность - дело чести организации, с которой клиент имеет дело, которой он доверяет хранить и оперировать сведениями, представляющими для него ценность. Кто хоть раз делал покупки в интернет-магазинах с использованием кредитных карт, тот возможно замечал, что на сайте, обеспечивающем снятие денег с кредитки и перевод их на чей-либо счёт, основным протоколом работы с клиентом является HTTPS вместо привычного HTTP. Если Ваш Интернет-провайдер производит расчёты с вами посредством веб-интерфейса, то скорее всего, его биллинговая система тоже защищена методом доступа только посредством HTTPS ( HyperText Transfer Protocol Secured - Защищенный протокол передачи гипертекста ). Каждый раз при заходе на страницу с адресом, начинающимся с https://, можете быть уверены, что при обмене информацией между вами и сервером происходит участие SSL слоя (Secure Sockets Layer), на котором и обеспечивается ПРОЗРАЧНОЕ, незаметное (вернее, не представляющее никаких затруднений) для пользователя, двустороннее шифрование.
HTTPS и SSL это не синонимы. С помощью SSL-слоя могут быть защищены любые стабильные соединения (протокол TCP). Через SSL могут также работать, например, POP3 и SMTP (приём и отправка почты), Jabber XMMP (протокол мгновенного обмена сообщениями). Можно настроить любую службу, использующую TCP для работы с SSL, даже если изначально она не поддерживает SSL (только нужно в этом случае не забыть настроить клиентскую сторону для поддержки SSL). Важно подчеркнуть, что сам протокол (язык общения клиента и сервера) остаётся прежним.

SSL изнутри
Что нужно знать об использовании SSL слоя (и протоколом HTTPs, в частности)?
- На первом этапе общения клиента с сервером происходит согласование методов шифрования (SSL поддерживает несколько методов в целях совместимости), ориентируясь на предпочтения клиента. Дальше происходит сложный обмен множеством ключей, шифруемых сначала сертификатом сервера и сертификатом клиента. Далее происходит генерация уникальных для сессии аргументов шифрующих алгоритмов (challenge, master_key, server_read_key, client_read_key ). Во избежание внедрения в SSL-сессию в шифрованном обмене используются дополнительные числовые величины, согласованные на начальном этапе - connection_id, session_id. Все эти средства, используемые вместе, обеспечивают очень устойчивое шифрование передаваемых данных. Даже с использованием самых современных алгоритмов перебора и вычислительных мощностей раскрытие переданных данных займёт столь значительное время (годы), что заниматься этим взломщикам просто нецелесообразно и невыгодно - в большинстве случаев раскрытая информация будет уже неактуальной ко времени раскрытия или её ценность упадёт настолько, что затраты несопоставимы с возможной выгодой.
Но защита, о которой мы говорили, защищает данные только от перехвата третьими лицами. А если у лица, которому адресована информация, не совсем чистые помыслы? Возможно, центр процессинга кредитных карт, которому вы передали информацию о своём электронном счёте, таковым и не является? Ведь может такое произойти, что система, которой вы решили воспользоваться, создана злоумышленником для сбора информации о кредитных картах для последующего нелегального их использования? И это не фантазия - история интернета знает множество подобных случаев мошенничества. Здесь уже стоит вопрос о доверии или недоверии серверу и информационному ресурсу, который на нём работает. И как решить, кому можно доверять, а кому доверять опасно? В этом нелегком деле остаётся надеяться на сертификаты.

СЕРТИФИКАТЫ
С первых дней электронной коммерции и до середины девяностых остро стоял вопрос как осуществить привязку сервера, сайта, домена к определенному юридическому или физическому лицу? Интернет - настолько свободная информационная среда, что любой может выдать себя за кого угодно, например создав красивый и солидный сайт или завладев доменом, аналогичным домену официального ресурса-жертвы. Как решить кто есть кто? Кому верить?
Для решения этой проблемы были созданы сертификационные центры (Certification Authority). Самые известные из них - Thawte и VeriSign. Эти организации занимаются выдачей электронных сертификатов юридическим и физическим лицам. Сертификат привязан к определенному домену. Использование сертификата на сайте с другим доменом невозможно - клиенту будет выдаваться предупреждение, сообщающее о несоответствии домена, указанного в сертификате реальному. CA ведут реестр лиц, которым выданы сертификаты, содержащие паспортные данные, ИНН и другие сведения, достаточных, например, для предъявления исков конкретному лицу, если организация, на сайте которой была совершена сделка, вас "кинула". Как вы понимаете, сертификат не является гарантией кредитоспособности и доброго имени сертифицированного лица - сертификационный центр не может поручаться за каждого, кому он выдаёт сертификат. CA только закрепляет соответствие сертификата определенному лицу и не более. Для получения сертификата достаточно сгенерировать запрос на получение сертификата - CSR ( Certificate Sign Request ), собрать необходимые документы ( в т.ч., документы на домен ), выложить некоторую сумму, дождаться проверки и подписания сертификата. Потом настраиваете вебсервер (IIS, Apache) или другой сервис, работающий поверх SSL, для использования подписанного сертификата - и можете использовать SSL без уведомления клиента браузером (если речь идёт о вебсервисе) о недоверии вашему узлу.
Стоимость получения сертификата вышеназванными сертификационными центрами довольно высока, существует множество вторичных CA, уполномоченных за более скромную плату подписать ваш сертификат, которому тоже можно будет доверять (а можно будет уже и не доверять - кто как захочет). При значительной конкуренции не исключено, что клиент выберет аналогичную службу, аттестованную корневым центром. Вообще доверять CA или не доверять - личное дело каждого (режим доверия/недоверия задаётся в настройках SSL клиентского приложения). Подписать сертификат может не только CA. Получив сертификат, можете сами им подписывать сертификаты любого количества лиц (а те своим сертификатом тоже могут подписать любое количество сертификатов... и т.д.), но ответственность за них будет нести именно лицо, выдавшее сертификат. Если цепочка сертификатов не доходит до корневого CA, то считается (большинством браузеров), что сертификату доверять нельзя - выводится предупреждение.
Если вы не желаете воспользоваться услугами CA, можете САМИ подписать свой сертификат (идеально для экспериментов). О генерировании Self-signed сертификатов и настройке серверов в Интернете очень много детальной технической информации.

Таким образом, использование SSL решает сразу несколько задач:
- обеспечение стойкого шифрования отправляемых и получаемых данных, которое делает практически невозможным раскрытие переданной пользователем информации третьими лицами при передаче через Интернет.
- принятие решения о доверии или недоверии удалённой стороне на основе сертификата. Таким образом почти отпадает вопрос о доверии/недоверии удалённой стороне.

Побочные эффекты, важные для бизнеса:
- само использование SSL (HTTPS) внушает большее доверие (и уважение), как параноикам, так и просто разбирающимся в IT людям, даже в том случае, если информация объективно не представляет большой ценности. Отказ от использования SSL на критичных к раскрытию информации сервисах намного страшнее - это как минимум показывает непрофессионализм специалистов компании, а в худшем случае это может обернуться отзывом лицензии на определенный вид деятельности (при проверке компетентными организациями), судебными исками в случае причинения ущерба, ударом по репутации...
- использование сертификата, подписанного Сертификационным Центром, внушает еще большее уважение и уверенность в ваших услугах.
- практика показывает, что значительная часть интернет-аудитории (Наиболее продвинутая, динамичная, активная, следовательно и наиболее интересная для бизнеса) склонна отказываться от использования сервисов, где защите информации уделяется мало внимания.