Дамп интернет-трафика, как правило, довольно однообразен: пароли и данные форм, которые по-прежнему повсеместно передаются без HTTPS, е-мейлы и переписка из различных IM-мессенжеров. Последнего — особенно много. А теперь посмотри на свои открытые окна в мессенжере и подумай: хотел ли ты, чтобы твои мессаги сейчас кто-то читал? Задумавшись на этот счет, я решил не играть с судьбой и немного заморочился по части шифрования приватных разговоров.

 

Шифруем почту в Gmail

Когда я забирал почту с многочисленных почтовых ящиков с помощью The Bat!, отправлять письма в зашифрованном виде было проще простого. Давно зарекомендовавшую себя систему шифрования PGP было легко подключить к любому популярному почтовику и при этом вполне удобно использовать. Со временем я, как и многие другие, перешел на GMail и стал использовать веб-интерфейс, а поддержки шифрования сообщений в нем как не было, так и даже не анонсировано. Хотя нельзя сказать, что Google не заботится о безопасности: гуглопочта для авторизации давно использует исключительно HTTPS и даже, больше того, позволяет постоянно работать по защищенному соединению. Проверь, чтобы в настройках опция «Browser connection» была выставлена как «Always use https».

Таким образом, можно не волноваться, что твои письма отснифают в каком-нибудь кафе или другом месте с открытым Wi-Fi, но чтобы скрыть содержание письма от самого Gmail и всех других серверов, придется использовать дополнительное шифрование — например, с помощью PGP/GPG. Если говорить о веб-интерфейсе, то подключить его можно только в Firefox'е, для которого уже довольно давно разрабатывается плагин FireGPG (ru.getfiregpg.org/s/install). Напомню, что смысл шифрования PGP в существовании пары ключей: закрытого (private) и открытого (public), а также специальной процедуры, которая может с помощью открытого ключа преобразовать сообщение так, чтобы обратное преобразование было возможно только с помощью закрытого ключа. Получается, ты можешь подписывать сообщения своим открытым ключом и использовать открытый ключ другого человека для того, чтобы отправить ему зашифрованное сообщение, и наоборот. Это основной принцип ассиметричного шифрования. В сам плагин FirePGP никакие криптографические функции не включены, это лишь прослойка между веб-интерфейсом GMail и программой для шифрования GnuPG, которую предварительно необходимо установить. Есть разные вариации, в зависимости от ОС:

Далее, подключив к браузеру и сам плагин, Firefox предложит указать настройки. Самое главное — сгенерировать закрытый и открытый ключи, указав несколько параметров, в том числе пароль, срок действия ключа, его длину. Важная опция «Включить поддержку Gmail» свяжет FirePGP с GMail, и она включена по умолчанию. Теперь при создании нового письма в интерфейсе GMail у тебя появятся кнопки «Зашифровать» и «Прикрепить зашифрованный файл». Понятно, что для чтения зашифрованных писем адресату точно также потребуется PGP/GPG и твой открытый ключ. При этом это совершенно необязательно должен быть Gmail — эта система шифрования, как я уже говорил, отлично прикручивается к любому почтовому клиенту. Да и GMail — это не только веб-почта, с аккаунтом можно отлично работать по протоколам POP/IMAP/SMTP.

 

Безопасное общение в аське

С почтой, вообще говоря, все понятно: есть PGP, к которому давно все привыкли, — его и используем. А вот с многообразием мессенжеров, которых с шифрованием сообщений обделили никак не меньше, далеко не все так гладко. Из популярных в России протоколов шифрование изначально предусматривалось только в Jabber'е (об этом ниже). Но как быть с самой популярной сетью — ICQ? Единственное, что было переработано в протоколе — это соединение с сервером, которое, ура, можно проводить через SSL. Но, черт его знает, что там на сервере? Нужно шифровать сообщение, и эту функцию придется каким-то образом реализовывать поверх протокола. Один из подходов — перехватывать все сообщения и шифровать трафик на лету. Допустим, пустить весь трафик мессенжера через промежуточный SOCKS-сервер, который будет шифровать каждое сообщение и уже в безопасном виде отправлять его на сервер. Тело сообщения при этом дойдет в таком виде до самого адресата и только там преобразуется в открытый вид точно таким же SOCKS-сервером. Удобно, что не надо никак привязываться к мессенжеру (ведь каждый из нас любит что-то свое: miranda, qip, pidgin и т.д.) — системе абсолютно пофигу на него. Важно только, чтобы у каждого клиента был установлен и настроен такой шифрующий SOCKS-сервер. Описанный подход в частности реализовали французские программисты, выпустившие серию продуктов SimpLite (www.secway.fr). Увы, проект последние годы не обновляется, и если раньше он работал более-менее сносно, то сейчас заставить его корректно функционировать довольно сложно.

Зато семимильными шагами развивается даже не конкретное программного решение, а именно протокол для безопасной передачи сообщений, который может работать поверх любого незащищенного соединения, в том числе ICQ. OTR или Off-the-Record Messaging — это хитрая комбинация симметричного шифрования с помощью AES, известного алгоритма Диффи-Хеллмана для обмена ключей и хеш-функции SHA-1. Все вместе это позволяет надежно защищать IM-сессии с обязательным шифрованием сообщений, аутентификацией собеседника и проверкой целостности сообщения. Перед тем же PGP у протокола есть важное преимущество. Даже если твой приватный ключ попадет в чужие руки, то предыдущая переписка не будет скомпрометирована: злоумышленник просто не сможет ее прочитать. Привычные публичный и приватный ключи используются только для первичной аутентификации пользователей, но все дальнейшие сообщения шифруются уже с помощью одноразовых AES-ключей — так называемых Message Authentication Codes (MACs). Но не будем вдаваться в математику (ссылки на подробное описание протокола ты найдешь в сносках), а посмотрим, как это работает на практике.

На официальном сайте протокола www.cypherpunks.ca/otr доступна так называемая OTR localhost AIM proxy — реализация того самого посредника между IM-клиентом и сервером, о котором мы говорили выше. Программа (есть версии для винды, линукса и macos) работает в системе, как самая обычная прокси, через которую нужно пустить трафик твоего IM-мессенжера (неважно какого). Для этого в настройках соединения пропиши SOCKS5 (127.0.0.1:1080) или HTTP-прокси (127.0.0.1:8080). Во время следующего соединения программа подключится к ICQ-серверу через OTR, а в окно Proxy ты увидишь новое подключение. Для каждого ICQ-аккаунта необходимо сгенерировать ключи, но делать это самому в принципе необязательно — программа сделает это автоматически. Если собеседник захочет установить безопасное подключение, то должен будет предоставить свой публичный ключ (в OTR он называется fingerprint) — прокси об этом тебя предупредит и добавит связку uin-fingerprint в свою базу данных. Далее fingerprint будет использоваться для того, чтобы установить, что собеседник — именно тот, за кого себя выдает. Обмен ключами производится автоматически, и тебе, по сути, вообще ничего не надо настраивать. Если оба клиента подключаются к ICQ-серверу через OTR, то программа по умолчанию установит безопасное соединение. С помощью настроек ты можешь отключить автоматическое инициирование безопасного подключения или, напротив, указать, что с некоторыми из контактов обмен сообщениями должен происходить с обязательным шифрованием. По своему опыту могу сказать, что система не только работает, но и работает очень здорово. Можно даже попробовать отснифать трафик и убедиться, что сообщения передаются исключительно в закриптованном виде.

Другой способ использовать OTR — прикрутить к мессенжеру специальный плагин. Для Pidgin'а есть официальный аддон, к Miranda и quitIM соответствующее дополнение разрабатывается энтузиастами, а в известном Mac'овском IM-клиенте Adium поддержка протокола есть по умолчанию. Если говорить об альтернативах OTR в принципе, то для Miranda есть плагин SecureIM, который защищает сообщения либо встроенным в плагин алгоритмом AES-192, либо внешней программой GPG/PGP. К слову, для использования в Miranda GPG/PGP есть и другие плагины — например, GnuPG Plugin (addons.miranda-im.org/details.php?action=viewfile&id=3485). Но тут надо обязательно иметь в виду, что все участники разговора в этом случае должны использовать одно и то же решение.

 

Jabber & PGP

Вместо того чтобы прикручивать шифрование там, где его никогда не было, есть другой вариант — перейти на протокол, который изначально предусматривает безопасную передачу сообщений. Что неудивительно, таким протоком является XMPP (Jabber). Начнем с того, что практически любой XMPP-сервер сейчас поддерживает защищенное SSL/TLS-соединение между сервером и клиентом, что уже обламывает любителей поснифать трафик в локалке или хотспоте. Более того, во многих клиентах предусмотрена возможность шифровать сообщения между пользователями, прежде всего, на основе PGP/GPG. Тут опять же нас выручает свободная реализация системы PGP — GnuPG, на которую и возложены все функции шифрования. Попробуем прикрутить ее к одному из самых популярных XMPP-клиентов — psi (www.psi-im.org). С тем же успехом можно наладить связку GnuPG с Pidgin и многими другими мессенжерами.
Если ты уже использовал GnuPG вместе с плагином FireGPG, то у тебя уже наверняка есть пара из открытого и закрытого ключей, которую ты можешь использовать и для переписки в Jabber'е. В противном случае ключи необходимо создать с помощью команды «gpg --gen-key». В диалоговом режиме надо ответить на ряд сопутствующих вопросов, указав тип шифрования, длину ключа (чем больше — тем лучше), срок его действия, идентификатор пользователя, e-mail, а также пароль. Когда ключи будут готовы, необходимо экспортировать открытый ключ в файл и дальше передать его своему собеседнику. Для этого выполни команду «gpg --list-keys» — она выведет список доступных ключей и их идентификаторы. А дальше, используя нужный идентификатор, экспортируй ключ в файл: «gpg --armor --export ID_КЛЮЧА > mykey_gpg.asc». Файл mykey_gpg.asc будет похож на что-то вроде:

pub 1024D/29D59819 06.06.2010 myaccount's key (myaccount's key) <myaccount@gmail.com>
Primary key fingerprint:  586C 0FAB 3F0C 0009 40C6 273E 8885 6A80 29D5 9819

-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.9 (MingW32) - WinPT 1.4.3
Charset: UTF-8

mQGiBEwLWjwRBACT9pHfYBDC51cxwsIWuO5DE7xKBz/NscI05q7j+DaVl0PoXLko
[вырезано]
D1cedORKLsgnRfbfkIMAn2BDxiBT2hPvEnAFjHOpIWra8axQ
=l7zo
-----END PGP PUBLIC KEY BLOCK-----

Его-то и нужно передать всем адресатам, с которыми ты планируешь ввести приватные беседы. Чтобы не геморроиться с консольными утилитами для работы с ключами, есть замечательная GUI-тулза WinPT (winpt.gnupt.de), которая позволяет сделать все то же самое только в 10 раз проще. Но что делать со своим закрытым ключом? Ничего. Psi на запуске сама проверяет ключи, которые были созданы GnuPG (заметь, без каких-либо плагинов и шаманств с настройками). Надо лишь зайти в настройки аккаунта, перейти на вкладку «Подробности» и в настройках OpenPGP выбрать нужный приватный ключ. С этого момента во время подключения к серверу клиент будет запрашивать у тебя пароль для этого ключа. А всем тем, кто импортировал твой открытый ключ, клиент будет отображать, что твой статус подписан — к сети подключился действительно ты, а не кто-то другой. Осталось уже со своей стороны импортировать открытые ключи других пользователей и связать их с нужными контактами в Psi, нажав правой кнопкой мыши и выбрав «Присвоить ключ OpenPGP». Ключи проще всего импортировать в WinPK через меню «Ключ -> Импортировать». Единственное надо иметь в виду, что Psi считывает информацию о ключах во время запуска, поэтому после любого импорта ключей, его необходимо перезапустить. Все, теперь, когда ты откроешь новое окно с чатом, то увидишь иконку с замочком. После нажатия на нее произойдет сверка ключей, и система выдаст сообщение о том, что разговор зашифрован.

 

Безопасная конференция

Еще один нетронутый аспект — организация площадки для безопасного общения нескольких людей или даже большой команды. С этой целью уже давно разрабатывается профильное решение — SILC Secure Internet Live Conferencing (silcnet.org). SILC очень похож в использовании на IRC: тут тоже есть имена пользователей, общие каналы, частные сообщения. Более того, совпадают даже основные команды — словом, все, как в те времена, когда мы все еще зависали на IRC. Основное различие от IRC – изначально заложенная защита передаваемой информации. Причем шифрование – это базовая часть протокола, ее никак нельзя отключить. Шифруются абсолютно все: сообщения в привате или на канале, пароли, команды и уведомления. SILC появился на десять лет позже IRC, и у разработчиков (прежде всего, Пеки Риконнена) была возможность поучиться на чужих ошибках и учесть неудачные решения. Так, протокол обеспечивает защищенную передачу и аутентификацию между клиентом и сервером, сервером и сервером, и между клиентами в приватной беседе. К тому же, он банально удобен. Например, в клиенте по умолчанию поддерживается функция detaching: ты можешь отсоединиться от сервера, но у других создается иллюзия присутствия. В IRC для этого понадобилось на каком-нибудь сервере установить небезызвестный BNC :).

Система SILC состоит из сервера под никсы, который придется установить в безопасном месте, и официального клиента для Linux/Unix/Mac/Windows. Для подключения также можно использовать Pidgin с установленным плагином. Сервер легко собирается из исходников (стандартными командами ./configure&make&make install) или же инсталлится из rpm-пакета (rpm –i silc-server-1.1-0.fc8.i386.rpm). А вот, что придется сделать, так это сгенерировать для каждого пользователя ключ, что делается довольно мудреной командой:

silcd -C /etc/silcd --identifier="UN=<username>, HN=<hostname or IP>, RN=<real name>, E=<email>, O=<organization>, C=<country>"

После того как создашь пользователей, можно запустить сервер и попробовать подключиться к нему Pidgin'ом, создав новый профиль для работы через протокол SILC. Помимо обычных параметров, вроде имени и пароля, IP и порта сервера, необходимо указать расположение публичного и закрытого ключей. Ключа у тебя нет, но он будет автоматически сгенерирован при первом соединении с сервером. Пробуем подсоединиться... Ву-а-ля, теперь у нас снова есть удобный IRC, но гораздо более безопасный и удобный.

 

WARNING

Слабое место любого мессенжера — история переписки. Она не шифруется и, как правило, хранится в открытом виде. Поэтому ее лучше отключить.

 

WWW

Презентация с описанием протокола OTR: http://www.cypherpunks.ca/otr/otr-codecon.pdf

  • Подпишись на наc в Telegram!

    Только важные новости и лучшие статьи

    Подписаться

    • Открыть комментарии
    Подписаться
    Уведомить о
    0 комментариев
    Межтекстовые Отзывы
    Посмотреть все комментарии