ВЕБ ПОД ЗАМКОМ!
Технологии для создания защищенных соединений

Kirion (kkr@mailru.com)

Спецвыпуск Xakep, номер #030, стр. 030-014-1

Ну что, создал уже свой мегамодный портал? Все просто ломится от скриптов, флэша и прочего PHP :). А после предыдущего номера ты наверняка решил создать левый Интернет-магазин :). Возможно, ты также решишь хранить на нем важную инфу или использовать его для секретной переписки. И тут во весь рост встает проблема безопасности...

ЛАЗУТЧИК СО СНИФФЕРОМ

Не секрет, что безопасности в протоколах TCP/IP нет. Что FTP-соединение, что HTTP-соединение может быть перехвачено, прочитано и искажено. Конечно, если это Джон Смит, заходящий по паролю на порносайт, то особой опасности перехват его пароля не несет (ну подумаешь, заплатит еще раз :)). А вот если это номер кредитки Джона Смита, по которой он регистрировался на этом сайте, - это уже интереснее. В моей локальной сети огромное количество умников, вечно сниффающих траффик - попрощайтесь с мылом, аськой, ником на ирке, сайтом. Еще не страшно? Конфиденциальность и секретность нужны всем, особенно в свете всеобщей борьбы с терроризмом и небывалой активизации спецслужб в плане контроля над личной жизнью граждан :). Над вопросом обеспечения конфиденциальности данных при передаче по сети крупные компании задумались достаточно давно. Технологии для шифрования были - надо было приспособить их для Интернета. Результатом работы стал официальный протокол Secure HTTP (RFC 2660), однако он не получил особой распространенности. А все потому, что компания Netscape разработала протокол SSL (Secure Socket Layers), который и получил наибольшую популярность и распространение (что неудивительно, если вспомнить, какой браузер был лидером долгие годы :)). Популярность SSL также определила его независимость от платформы и программной реализации. Протокол был разработан на принципах переносимости и не зависит от приложений, в составе которых он используется. Кроме того, хотя сам протокол и непрозрачен для приложений, поверх него могут накладываться и другие протоколы, например для увеличения степени защиты или для применения SSL в другой области. То есть если в проге нет поддержки SSL - ни фига у тебя работать не будет. А если поддержка есть - то ты можешь забыть, что SSL вообще существует, и использовать любые протоколы прикладного уровня (модель ISO/OSI, куда же мы без нее), например - проверять почту, лазить по FTP, смотреть чужие ресурсы через NetBios, ну и естественно - работать с HTTP. Во всех этих протоколах можно применять SSL для шифрования данных. Можно еще и дополнительную защиту прикрутить - протокол это позволяет. Если хочешь - можешь сравнить две реализации безопасного протокола: про Secure HTTP можно почитать на www.faqs.org/rfcs/rfc2660.html, а про SSL на home.netscape.com/eng/ssl3/draft302.txt. Знание технического английского приветствуется (можешь перевести и отослать мне - получишь приз :)).

БОЖЕСТВЕННАЯ АСИММЕТРИЯ

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