Компания «Яндекс» включила в Яндекс.Почте шифрование для межсерверных SMTP-соединений с использованием STARTTLS — как на прием, так и на отправку писем. Теперь, например, все письма из российской почтовой системы пользователям Gmail передаются не только по IPv6, но и в зашифрованном виде. По этому поводу я немножко расскажу о протоколах, которые используются при передаче электронной почты в зашифрованном виде.
Исследователям еще предстоит найти причину истинной любви интернет-технологов к аббревиатурам. Со времен 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 и покрыли таким образом все основные способы передачи информации пользователей в облако. В 2011 году мы включили HTTPS в веб-интерфейсе mail.yandex.ru и покрыли таким образом все основные способы передачи информации пользователей в облако. В этом году мы сделали HTTPS обязательным при доступе к Почте, а на этой неделе отключили любые возможности подключиться к ней по незащищенному протоколу. Мы также проделали большую работу по защите пользовательских паролей в системе аутентификации — «Яндекс.Паспорте» — и обязательно расскажем об этом.
Вот как сейчас выглядит соотношение зашифрованного и обычного трафика на наших SMTP-серверах связи с внешним миром.
