На прошлой неделе мы включили в Яндекс.Почте шифрование для межсерверных SMTP-соединений с использованием STARTTLS — как на приём, так и на отправку писем. Теперь все письма из нашей почтовой системы пользователям других сервисов, которые поддерживают такое шифрование (например, Gmail) передаются в зашифрованном виде, и никто по дороге не сможет их прочитать. По этому поводу я немножко расскажу о протоколах, которые используются при передаче электронной почты в зашифрованном виде.
Несмотря на то, что шифрование соединения между пользователем и интерфейсом почты уже довольно распространено среди массовых сервисов, переписка между почтовыми системами часто шла в незащищённом виде. Безопасность почты — это то, что мы считаем очень важным.
Исследователям ещё предстоит найти причину истинной любви интернет-технологов к аббревиатурам. Со времён ARPANET все сети, протоколы, стандарты и т.д. предпочитают называть буквенными сокращениями. Этот простой и понятный способ словообразования приводит к появлению предложений вида: «IETF published RFC6594 by CZ.NIC on the use of SHA-256 with RSA, DSA and ECDSA in SSHFP». Как видно, особенно много таких сокращений в криптографии.
Что такое SSL и TLS?
В девяностых годах прошлого века одним из «инкубаторов», где всякие интересные идеи из академической среды воплощались в реальность, была компания Netscape. Именно её сотрудники в начале позапрошлого десятилетия реализовали возможность шифрования соединений, опубликовали протокол и назвали его Secure Sockets Layer (SSL). Его первой публичной версией была SSL v2, в которой быстро нашли ряд уязвимостей. За ней вышла последняя на текущий момент SSL v3. Оригинальное описание на сайте Netscape кануло в лету в момент поглощения Netscape компанией AOL, но в 2011 его всё-таки опубликовали для истории в виде RFC6101.
Тогда же появилась и первая свободная реализация SSL. Энтузиаст Эрик Янг начал публиковать библиотеку SSLeay (на этот раз сборная аббревиатура: SSL + Eric A. Young) под BSD-подобной лицензией. SSLeay спустя несколько лет превратится в известную всем специалистам библиотеку OpenSSL.
Что важно знать про SSL v2 и v3? Во-первых, эти протоколы предназначены для работы поверх транспортного протокола с надёжной доставкой и соединениями (например, TCP). Во-вторых, SSL v2 использовать уже нельзя — он официально считается слишком уязвимым и в текущих условиях может давать только иллюзию безопасности.
На основе SSL v3 группа учёных и инженеров в рамках IETF создала протокол TLS (Transport Layer Security). Фактически, TLS v1.0 является небольшой (но несовместимой) переработкой SSL v3, включающей в себя все его возможности и добавляющей некоторые детали.
Конец девяностых и начало нулевых ознаменовались повсеместным использованием HTTPS (а это, напомню, просто HTTP поверх SSL/TLS — HTTP с шифрованием), а следовательно, и более пристальным вниманием к этим протоколам со стороны специалистов по компьютерной безопасности в шляпах обоих цветов. В результате был обнаружен целый класс уязвимостей при использовании SSL v3 или TLS 1.0 с блочными алгоритмами шифрования в режиме CBC (а в SSL другие режимы блочных алгоритмов не использовались). В 2006 году — аж через 7 лет — была выпущена обновлённая версия TLS 1.1, устраняющая эти уязвимости. Однако инженеры не торопились реализовывать TLS 1.1 аж до 2011 года, когда по всему интернету прогремела громкая атака на браузеры, использующие TLS 1.0, под названием BEAST. Было немедленно изобретено несколько костылей (например, переключение на поточный шифр), а также подняты приоритеты по апгрейду всего и вся на TLS 1.1+.
В 2008 году была выпущена спецификация последней на текущий момент версии TLS ─ 1.2. В ней появилось много нововведений. Во-первых, стала обязательной возможность использовать алгоритм шифрования AES, причем появился новый режим шифрования в дополнение к CBC — GCM. Во-вторых, была исключена поддержка устаревших алгоритмов DES и IDEA. В-третьих, в протоколе отказались от использования HMAC на основе алгоритма хеширования MD5 и перешли на более стойкие SHA256 и SHA384. В-четвертых, появился механизм расширений TLS extensions, позволяющий включать новые фичи без полной переработки протокола. Одним из таких расширений является SNI, который активно используется в сервисах Яндекса. Наконец, чтобы все нововведения не оказались бесполезными, в протоколе возможность даунгрейда на SSLv3 была объявлена устаревшей и нерекомендуемой.
Итак, подводя итоги:
- SSL ─ это протокол безопасных соединений поверх TCP. Новых версий SSL не бывает. TLS ─ это и есть новый SSL, с новой нумерацией версий.
- Есть старый SSL v2. Он негодный — если он поддерживается, его надо отключать. Есть SSL v3, который везде поддерживается много лет. Но в нём найдены недостатки, которые могут негативно сказаться на безопасности. Есть TLS v1.0, в нём сохраняются уязвимости SSL v3, и его лучше бы использовать только с поточным алгоритмом шифрования RC4 (который отдельно считается теоретически уязвимым). Поэтому лучше всего использовать TLS v1.1 или v1.2 и запрещать шифр RC4.
Протоколы электронной почты
Можно уверенно сказать, что основным пользовательским протоколом передачи электронной почты является HTTP. Это может звучать необычно, но подавляющее большинство пользователей именно так читает и отправляет свои электронные письма в 2013 году.
Почтовые программы, хоть и отошли на второй план, по-прежнему широко используются и работают по трём протоколам: старый POP3, чуть более новый IMAP и универсальный SMTP. Про историю POP3 и IMAP я немного рассказывал раньше, а теперь чуть-чуть добавлю про SMTP.
Электронную почту по праву называют первым киллераппом компьютерных сетей. Корнями современный SMTP (Simple Mail Transfer Protocol) уходит очень глубоко в ARPANET, в до-TCP/IP-шную эпоху передачи файлов между компьютерами американских универсистетов на деньги Министерства обороны США. Это были наивные прекрасные времена повсеместного взаимного доверия, когда не требовалось не только шифрования, но и даже простейшей аутентификации. Чем нам это аукнулось годы спустя можно, кстати, увидеть в собственной папке «Спам».
Смотрите, первая версия SMTP для Интернета (с большой буквы!) специфицирована в RFC 788 в конце 1981 года. Уже тогда это был результат более чем десятилетнего развития электронной почты в ARPANET. И только ещё почти через 20 лет в 1999 году появляется официальный стандарт на аутентификацию ─ то есть на логины и пароли в SMTP. Всё это время передача почты по SMTP была возможна сразу после соединения кем угодно кому угодно. Этот режим, конечно, подходил для межсерверного общения в сети с большим количеством хопов ─ в этом случае хосты могут служить релеями для чужой почты. Но первоначальная отправка, так называемый submission, без аутентификации привёл к появлению спама, а затем уже к изобретению SMTP AUTH. Кстати, старожилы ещё могут помнить режим «POP3 before SMTP», который использовал POP3 в качестве аутентифицирующего костыля к SMTP.
Как только в протоколе появляются пароли, сразу начинают задумываться и о шифровании. В 2002 году выходит стандарт на поддержку апгрейда открытой SMTP-сессии до режима TLS ─ RFC3207. Это была попытка зафиксировать и улучшить дефакто ситуацию ─ шифрование SMTP на отдельном порту 465 к тому моменту уже применяется несколько лет.
Схема работы STARTTLS представляет отдельный интерес. Это универсальное расширение для любого текстового протокола. В реальности оно получило распространение для SMTP, IMAP/POP3 и немножко для FTP.
В момент, когда клиент и сервер в уже установленном открытом соединении понимают, что с обеих сторон есть возможность и желание зашифровать передачу данных, клиент даёт команду STARTTLS и сразу же начинает TLS handshake.
От прикладного протокола зависит только способ убедиться во взаимной поддержке TLS до начала шифрования. В случае SMTP это происходит через механизм расширений ESMTP ─ здесь есть подробности и об этом.
Шифрование SMTP через STARTTLS по стандартным портам (напомню, 25 и второй 587, про который часто забывают) или по порту 465 сразу же стало набирать популярность. TLS позволяет многое: и аутентификацию по сертификатам, и проверку подлинности сервера ─ всё это интересные, нужные и доселе недоступные возможности. Сейчас, кажется, не существует почтовых систем, которые не принимают от пользователей почту по зашифрованному соединению. Другое дело ─ межсерверное общение.
SMTP ─ не просто рабочая лошадка электронной почты, он ещё и двухголовая лошадка.
Весь обмен письмами между серверами различных почтовых систем тоже происходит по SMTP. Конечно там уже нет парольной аутентификации ─ вместо неё используется проверка адреса получателя письма на прикладном уровне. Если и её нет, то получается Open Relay, за который ваш IP-адрес обязательно накажут отрицательной репутацией все антиспам-системы мира. Обычно там нет и шифрования. Причин этому несколько. Во-первых, считается что каналы связи между серверами почтовых систем сами по себе достаточно безопасные. И действительно, при передаче между серверами письма как правило не спускаются в «последнюю милю», где обычно и происходит мелкий, «казуальный» перехват трафика. Во-вторых, эта передача асинхронная и неинтерактивная, благодаря чему нет никакой возможности уточнить у человека, что делать в случае несоответствия или просроченности сертификата принимающей соединение стороны.
Все эти аргументы, однако, оказываются несостоятельными. Принимающий сервер может находиться не в стойке большого защищённого датацентра, а где угодно. Правительственные организации по всему миру запускают программы прослушки на всех каналах связи. Проверка сертификатов пусть и полезна, но совсем не обязательна для того, чтобы обезопасить передачу информации. Поэтому всё чаще и чаще мы встречаем письма, которые переданы в зашифрованном виде на всём своём пути ─ от браузера пользователя по HTTPS на сервер почтовой системы, затем на сервер получателя по SMTP over TLS, а после этого по зашифрованному IMAP в телефон человека, которому предназначено послание. И это хорошо.
Поддержка шифрования в протоколах Почты Яндекса
В 2009 году одновременно с запуском IMAP мы добавили поддержку SSL/TLS в наш POP3-интерфейс. Примерно тогда же появилось шифрование в SMTP для приёма писем из почтовых программ. Сегодня, спустя больше чем 4 года, наши сервера всё ещё позволяют открывать незащищенные соединения из почтовых программ, хотя мы не рекомендуем их использовать и даже, по возможности, не документируем.
Мобильные приложения Яндекс.Почты всегда используют SSL/TLS-соединения, а внутри — протокол XMPP.
В 2011 году мы включили HTTPS в веб-интерфейсе mail.yandex.ru и покрыли таким образом все основные способы передачи информации пользователей в облако. В этом году мы сделали HTTPS обязательным при доступе к Почте, а на этой неделе отключили любые возможности подключиться к ней по незащищённому протоколу.Мы также проделали большую работу по защите пользовательских паролей в системе аутентификации — Яндекс.Паспорте — и обязательно расскажем об этом.
Вот как сейчас выглядит соотношение зашифрованного и обычного трафика на наших SMTP-серверах связи с внешним миром.
Подходящий к концу 2013 год можно уверенно назвать как годом громких скандалов, связанных с массовой прослушкой данных правительственными организациями, так и первым годом повсеместного облачного шифрования. Мы призываем всех наших коллег по индустрии присоединяться к тренду и брать курс на стопроцентное шифрование всех пользовательских данных в сети. Такие дела.
Автор: kappa
