Компания
315,75
рейтинг
28 ноября 2013 в 16:31

Разработка → Яндекс теперь поддерживает шифрование исходящей и входящей почты

На прошлой неделе мы включили в Яндекс.Почте шифрование для межсерверных SMTP-соединений с использованием STARTTLS — как на приём, так и на отправку писем. Теперь все письма из нашей почтовой системы пользователям других сервисов, которые поддерживают такое шифрование (например, Gmail) передаются в зашифрованном виде, и никто по дороге не сможет их прочитать. По этому поводу я немножко расскажу о протоколах, которые используются при передаче электронной почты в зашифрованном виде.

Несмотря на то, что шифрование соединения между пользователем и интерфейсом почты уже довольно распространено среди массовых сервисов, переписка между почтовыми системами часто шла в незащищённом виде. А безопасность переписки — очень важная штука для нас (хоть она и не очень заметна обычному пользователю).

image

Исследователям ещё предстоит найти причину истинной любви интернет-технологов к аббревиатурам. Со времён 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 была объявлена устаревшей и нерекомендуемой.

Итак, подводя итоги:
  1. SSL ─ это протокол безопасных соединений поверх TCP. Новых версий SSL не бывает. TLS ─ это и есть новый SSL, с новой нумерацией версий.
  2. Есть старый SSL v2. Он негодный — если он поддерживается, его надо отключать. Есть SSL v3, который везде поддерживается много лет. Но в нём найдены недостатки, которые могут негативно сказаться на безопасности. Есть TLS v1.0, в нём сохраняются уязвимости SSL v3, и его лучше бы использовать только с поточным алгоритмом шифрования RC4 (который отдельно считается теоретически уязвимым). Поэтому лучше всего использовать TLS v1.1 или v1.2 и запрещать шифр RC4.

Протоколы электронной почты


Можно уверенно сказать, что основным пользовательским протоколом передачи электронной почты является HTTP. Это может звучать необычно, но подавляющее большинство пользователей именно так читает и отправляет свои электронные письма в 2013 году.

image

Почтовые программы, хоть и отошли на второй план, по-прежнему широко используются и работают по трём протоколам: старый 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.

image

В момент, когда клиент и сервер в уже установленном открытом соединении понимают, что с обеих сторон есть возможность и желание зашифровать передачу данных, клиент даёт команду STARTTLS и сразу же начинает TLS handshake.

image

От прикладного протокола зависит только способ убедиться во взаимной поддержке TLS до начала шифрования. В случае SMTP это происходит через механизм расширений ESMTP ─ здесь есть подробности и об этом.

image

Шифрование SMTP через STARTTLS по стандартным портам (напомню, 25 и второй 587, про который часто забывают) или по порту 465 сразу же стало набирать популярность. TLS позволяет многое: и аутентификацию по сертификатам, и проверку подлинности сервера ─ всё это интересные, нужные и доселе недоступные возможности. Сейчас, кажется, не существует почтовых систем, которые не принимают от пользователей почту по зашифрованному соединению. Другое дело ─ межсерверное общение.

SMTP ─ не просто рабочая лошадка электронной почты, он ещё и двухголовая лошадка.

Весь обмен письмами между серверами различных почтовых систем тоже происходит по SMTP. Конечно там уже нет парольной аутентификации ─ вместо неё используется проверка адреса получателя письма на прикладном уровне. Если и её нет, то получается Open Relay, за который ваш IP-адрес обязательно накажут отрицательной репутацией все антиспам-системы мира. Обычно там нет и шифрования. Причин этому несколько. Во-первых, считается что каналы связи между серверами почтовых систем сами по себе достаточно безопасные. И действительно, при передаче между серверами письма как правило не спускаются в «последнюю милю», где обычно и происходит мелкий, «казуальный» перехват трафика. Во-вторых, эта передача асинхронная и неинтерактивная, благодаря чему нет никакой возможности уточнить у человека, что делать в случае несоответствия или просроченности сертификата принимающей соединение стороны.

Все эти аргументы, однако, оказываются несостоятельными. Принимающий сервер может находиться не в стойке большого защищённого датацентра, а где угодно. Правительственные организации по всему миру запускают программы прослушки на всех каналах связи. Проверка сертификатов пусть и полезна, но совсем не обязательна для того, чтобы обезопасить передачу информации. Поэтому всё чаще и чаще мы встречаем письма, которые переданы в зашифрованном виде на всём своём пути ─ от браузера пользователя по HTTPS на сервер почтовой системы, затем на сервер получателя по SMTP over TLS, а после этого по зашифрованному IMAP в телефон человека, которому предназначено послание. И это хорошо.

Поддержка шифрования в протоколах Почты Яндекса


В 2009 году одновременно с запуском IMAP мы добавили поддержку SSL/TLS в наш POP3-интерфейс. Примерно тогда же появилось шифрование в SMTP для приёма писем из почтовых программ. Сегодня, спустя больше чем 4 года, наши сервера всё ещё позволяют открывать незащищенные соединения из почтовых программ, хотя мы не рекомендуем их использовать и даже, по возможности, не документируем.

image

Мобильные приложения Яндекс.Почты всегда используют SSL/TLS-соединения, а внутри — протокол XMPP.

В 2011 году мы включили HTTPS в веб-интерфейсе mail.yandex.ru и покрыли таким образом все основные способы передачи информации пользователей в облако. В этом году мы сделали HTTPS обязательным при доступе к Почте, а на этой неделе отключили любые возможности подключиться к ней по незащищённому протоколу.Мы также проделали большую работу по защите пользовательских паролей в системе аутентификации — Яндекс.Паспорте — и обязательно расскажем об этом.

image

Вот как сейчас выглядит соотношение зашифрованного и обычного трафика на наших SMTP-серверах связи с внешним миром.

image
image

Подходящий к концу 2013 год можно уверенно назвать как годом громких скандалов, связанных с массовой прослушкой данных правительственными организациями, так и первым годом повсеместного облачного шифрования. Мы призываем всех наших коллег по индустрии присоединяться к тренду и брать курс на стопроцентное шифрование всех пользовательских данных в сети. Такие дела.

PS: Эдвард, привет! :)
PPS: Эдвард Сноуден не работает и никогда не устраивался на работу в Яндекс.
Автор: @kappa
Яндекс
рейтинг 315,75

Комментарии (149)

  • +8
    Казалось бы, причем здесь Pink Floyd?
    • +11
      Шифрование — это ведь another brick in the wall.
      • +4
        а на картинке — Dark side of the moon, Значит не соответствует картинка
    • +11
      Мне кажется, что суть в том, что на картинке изображена призма (PRISM). А Пинк Флойд не при чем )
      • –1
        извините, но «НИ при чем»
    • –2
      Вот именно. Больше к сжатию подходит картинка, а не к шифрованию.
  • 0
    SSL.no — это mail.ru?
    И, кстати, на почте для доменов это тоже работает?
    • +1
      Да, письма Почты для доменов принимаются и отправляются с тех же серверов, что и письма простой Яндекс.Почты.
      • 0
        А какой в этом случае подключающемуся серверу предъявляется сертификат? Нужно ли мне, как владельцу домена, предоставлять SSL-сертификат в ПДД?
        • +4
          Нужно ли мне, как владельцу домена, предоставлять SSL-сертификат в ПДД?
          Нет, не нужно. Используется сертификат, выписаный на CN сервера, являющегося MX. В случае ПДД — mx.yandex.ru.
          • 0
            А проблем не может быть, если CN сертификата не совпадает с MX?
            Например, настроен сбор почты с другого ящика. И там тоже сервер умеет шифрование.
            Но при отправке через web интерфейс яндекса, письмо уходит с серверов яндекса, а не с сервера моего ящика.
            • 0
              Честно говоря, я не понял примера. Так или иначе, есть два разных процесса:

              — выяснение, кто MX этого домента;
              — подключение к MX и проверка сертификата.

              Первый процесс функционально со вторым не связан.
            • +1
              Сертификат выдаётся в данном случае не на тот домен, который указан в email после собаки, а на доменное имя сервера, который принимает или отправляет письма. А также отправка (как минимум у Яндекса) производится не с MX-серверов, а с других.
    • +2
      mail.ru, кстати, тоже использует шифрование. Причём очень давно.
      Вот такие стоки я регулярно наблюдаю в логах моего сервера:
      Anonymous TLS connection established from abusef1.i.mail.ru[185.5.137.4]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)


      От яндекса тоже:
      Anonymous TLS connection established from forward1m.mail.yandex.net[37.140.138.1]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)


      У обоих выбранный алгоритм шифрования всё же получше чем у гугла:
      Anonymous TLS connection established from mail-ea0-f194.google.com[209.85.215.194]: TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)
      • +1
        Mail.ru использует только в одну сторону, к сожалению. Исходящая почта от них может быть зашифрованной, а входящая — нет. Что несколько снижает смысл этого.
        • +2
          Проверил. Действительно :(

          Кстати, а на кого расчитана вот эта реклама? :)
          $ telnet mx.yandex.ru 25
          Trying 77.88.21.89…
          Connected to mx.yandex.ru.
          Escape character is '^]'.
          220 mxfront10o.mail.yandex.net (Want to use Yandex.Mail for your domain? Visit pdd.yandex.ru)
          • +15
            На вас :)
  • +11
    Хорошо расписали что к чему, и зачем сделано. Всегда приятно такое почитать. Спасибо.
  • 0
    Использование шифрования в своём сервисе не требует лицензии в ФСБ?
    • –4
      Яндекс — голландская компания!
      • –2
        О как меня замнусовали.

        Минусующим советую сходить хотя бы на википедию и почитать.

        Компания зарегистрирована в России как ООО «Яндекс», 100 % уставного капитала которого владеет зарегистрированное в Нидерландах акционерное общество Yandex N.V.


        Это я о том что юридически российский офис Яндекса мало чем отличается от офиса Гугла.
        И ФСБ прежде чем делать такие заявления не мешало бы четко пояснить о каких компаниях они говорили и как это предстоит оценивать чиновникам.
        • 0
          Чисто юридически Яндекс — полностью российская компания.
          • 0
            Это вы как определили?
            67% акций торгуется на иностранных биржах, 100% уставного капитала юридически сосредоточено за пределами РФ.

            Да, есть офисы в России, есть разработчики в России, ровно как есть и офисы с разработчиками за пределами нашей родины.
            Вы поясните, пожалуйста, по каким критериям компания может называться российской и как это вяжется юридически.
              • –2
                При всем уважении к этому замечательному человеку, как эти слова можно подкрепить юридически?
                Да, эта компания была основана на российские деньги, русским людьми.
                Но инвесторы иностранные. И деньги на развитие иностранные.
                То что вы видите сейчас — это не российская компания, которой Яндекс был в самом начале.
                Как бы вам не хотелось. Мне тоже очень хочется чтобы это было так, как и многим, мне совершенно не чужда любовь к родине и патриотизм. Но факты нужно воспринимать такими какие они есть.
            • +1
              На иностранных биржах торгуются акции Yandex NV. Ей принадлежит полностью российское ООО Яндекс. Которая и осуществляет всю деятельность.
              • –3
                О чем и речь.
                Все принадлежит иностранной компании.
                И большая часть ее акций не принадлежит ей самой, а торгуется свободно на иностранных биржах.

                У меня не повернется язык назвать это российской компанией.
            • 0
              Вы поясните, пожалуйста, по каким критериям компания может называться российской и как это вяжется юридически.

              Зарегистрирована в России, налоги платит в России, подавляющее большинство имущества находится в России, подавляющее число работников тоже. Кто владеет компанией дело десятое — это лишь вопрос распределения прибылей.

              И вы путаете ООО «Яндекс» и Yandex N.V. ООО «Яндекс» — российская компания, основной капитал которой находится в России (тут же был оплачен уставной). 67% акций торгуется у Yandex N.V., которая является владельцем российского ООО.
              • +1
                Вот, это уже лучше чем банальное сливание кармы.

                То есть, серверами владеет российская ООО Яндекс и они не входят в уставной капитал, я правильно понял?
                • 0
                  Серверами владеет российская компания, они, скорее всего, входят в её основные средства и вряд ли являются частью уставного капитала, который сам по себе вещь достаточно абстрактная.
                  • +1
                    Ок, тогда ООО Яндекс можно назвать российской компанией.
    • +1
      Нет, использование не требует.

      Вот что говорят наши юристы по этому вопросу:
      Яндекс не разрабатывает и не применяет собственные технические средства защиты информации, в том числе криптографические, и на него не возложена обязанность по сертификации таких средств или по лицензированию компании в качестве их разработчика. Техническое обслуживание таких средств для обеспечения собственных нужд компании и с учетом примененных в проекте технических решений, по указанию Постановления Правительства РФ от 16.04.2012 N 313 и смежных актов, также не является лицензируемой деятельностью.
      • 0
        Но у вас не собственные нужды, вы предоставляете сервис.

        К шифровальным (криптографическим) средствам (средствам криптографической защиты информации), включая документацию на эти средства, относятся:
        а) средства шифрования — аппаратные, программные и программно-аппаратные шифровальные (криптографические) средства, реализующие алгоритмы криптографического преобразования информации для ограничения доступа к ней, в том числе при ее хранении, обработке и передаче;

        www.consultant.ru/document/cons_doc_LAW_128739/
        © КонсультантПлюс, 1992-2013

        Так что ваши юристы — весьма отчаянные ребята, раз хотят такими формулировками жонглировать.
      • 0
        Вот всегда интересовал вопрос: поднимаю я на собственном сервере https для публичного доступа. Имхо, это уже не внутренние нужды, а предоставление сервиса с использованием криптографии. Как ваши юристы ответят на подобные претензии со стороны контролеров?
        • 0
          Мне тоже интересно это узнать.
          На сегодня все решается выводом сервера с сайтом за пределы РФ.

          При трансграничной передаче шифровать ГОСТом ФСБ не требует.
          • 0
            Сейчас вроде как ФСБ не должно требовать шифровать по ГОСТу (если не считать гостайну и т. п.), даже если деятельность лицензируемая. Другое дело, что по слухам получить сертификат на другие СКЗИ стоит значительно дороже, типа индивидуальная экспертиза.
            • 0
              Нет, ФСБ просто не лицензирует ничего кроме ГОСТа.
              Сертификат на СКЗИ можно получить только с использованием ГОСТа, это прямое требование.
              • 0
                Можно ссылку на это прямое требование?
  • +7
    Это всё конечно круто, но если вам т.е Яндексу придет запрос от ФСБ с требованием раскрыть содержание писем некого пользователя, я уверен что вы это сделайте практически мгновенно.
    • +5
      Содержание писем мы можем раскрывать только по санкции суда.
      • +3
        Было бы великолепно если бы вы все обращения (кроме тех которые через суд) публиковали на отдельной странице — как это делает TPB, таким образом вы ничего не нарушаете а органы будут знать что к вам только с законными требованиями идти.

        И второй вопрос, Яндекс — юридически не русская компания, зачем вы соблюдаете русские законы и взаимодействуете с органами?

        По нынешнему законодательству вы можете ничего не делать ссылаясь на то, что вы живете по законам другой страны — там где зарегистрированы, а если им что-то не нравиться они могут обратиться в ваш суд.
        • +4
          Подчеркну, что я не юрист, и сейчас буду говорить исключительно от своего имени.

          1. Насколько я понимаю, мы не можем раскрывать запросы по закону об оперативно-разыскной деятельности. Мы думаем о том, чтобы сделать более публичной статистику таких запросов, но это тоже сопряжено со множеством технических и юридических сложностей, поэтому пока точно не можем ничего обещать.

          2. Яндекс юридически и фактически — российская компания.
          • –1
            2. — Весьма странно, помниться я читал, что компания юридически не в России зарегистрирована.

            Хорошо, тогда встречный вопрос, а зачем вы тогда русская компания?
            (Это я к вопросу поставленному выше, что таким образом можно будет следовать закону другой страны)
            • +4
              На мой взгляд — потому, что мы из России и хотим жить и работать в России :)

              Но я постараюсь задать этот вопрос тем людям, которые смогут дать более квалифицированный ответ.
              • –7
                Жить и работать можно в России, а сервера (основные) и вообще всё декларировать как зарубежная фирма, в ООО же — ничего не держать
            • +7
              ООО «ЯНДЕКС» — российская компания. Когда говорят о голландской компании, имеют ввиду Yandex NV. Но Yandex NV не ведет экономической деятельности, не владеет серверами, не оказывает хозяйственных услуг.

              Согласно закону об оперативно-розыскной деятельности, уполномоченные органы вправе проводить ее негласно. Поэтому ООО «Яндекс» не может легко разглашать все (или некоторые) обращения, сделанные органами. Тем не менее, мы, вместе с нашими юристами, изыскиваем все возможности повысить прозрачность этой деятельности и надеемся, что через какое-то время получим легальную возможность публиковать обобщенные отчеты.
              • –8
                Не получите, и вы ничего не сделаете, потому, что вы боитесь потерять бизнес что вполне логично.

                Если бы вы хотели что-то сделать, то вы могли вывести людей на улицу устроить движуху и правильно просвещать людей о том, что творит наше государство.

                Я вижу что, вы из Яндекса, тогда переадресую вопрос вам, из-за его бизнес зарегистрирован в России?
            • 0
              (Это я к вопросу поставленному выше, что таким образом можно будет следовать закону другой страны)

              И получить блокировку на уровне магистральных провайдеров. Да даже без блокировки невыполнение российских законов означает лишение возможности вести бизнес в России. Поисковиком и почтой люди смогут продолжать пользоваться, если не будет блокировки, а вот деньги получать с российских рекламодателей будет затруднительно, даже если валютные переводы не будут отклоняться, а это, вроде как, основной источник доходов.
      • –11
        Содержание писем мы можем раскрывать только по санкции суда

        Так значит все-таки можете? В опжу тогда такие криптографии!
        • +2
          Таких, кто может не раскрыть содержание письма даже по санкции суда, не бывает, увы. Это требование закона (не только в России).
        • 0
          Шифруйте свои письма открытым ключом получателя и только он сможет их раскрыть. SSL/TLS предназначены для защиты от негласной прослушки (и вторжения) каналов передачи, а не хранящихся данных.
          • 0
            Ок, понял, был неправ. Как верно ответили ниже, защита от ФСБ/АНБ/etc — «дело рук самих утопающих». И для полного «end-to-end» шифрования почты нужно использовать GnuPG.
            • 0
              GnuPG — лишь реализация PGP.

              Можно использовать любую реализацию.
            • +1
              Возможностей утечки много, Яндекс теперь перекрыл один из них в теории.

              Кроме GnuPG есть и другие средства. Тут главное как ключи согласовывать с получателем.
    • +6
      > придет запрос от ФСБ с требованием раскрыть содержание писем некого пользователя, я уверен что вы это сделайте практически мгновенно.

      Речь не о ФСБ, а о MITM атаках. Которые более распространены и массовы, чем запросы от служб безопасности. И вообще, кому реально есть что скрывать давно используют GnuPG. А то, что в новости — защита всех остальных данных, которые, попади не в те руки, могут быть неправильно использованы.
      • –3
        Да это понятно всё, это конечно великолепно, но нет ничего хуже чем иллюзия безопасности.
        • +2
          Хмм, какая иллюзия? От хацкеров благодаря такому я, в какой-то степени, в большей безопасности. А государственным органам проще меня IRL достать, если вдруг понадоблюсь.

          Постарайтесь понять уже — все технологии вот такого вот шифрования не направлены на защиту от органов власти — это не в интересах компаний, которые хотят нормально и легально работать на территории страны и при этом (внезапно!) зарабатывать деньги. Это никому не надо, кроме самих юзеров, которые уже давно пользовались собственным шифрованием с обменом ключами.

          И когда говорят о «безопасности», подразумевают именно защиту от всяких недобросовестных личностей или конкурентов, и вот против них эта схема вполне себе должна работать.
          • 0
            Когда я говорю про иллюзию безопасности, то я имею ввиду такие продукты как Bittorrent Sync — теоретически он безопасен, а на практике? — никто исходников не видел.

            Яндекс же может тролить власть сообщая о факте получения доступа к информации пользователя.
            • 0
              Яндекс же может тролить власть сообщая о факте получения доступа к информации пользователя.


              Зачастую такой троллинг может дорого обойтись, вплоть до ареста.
              • +1
                Только по решению суда.

                Проще ВНЕЗАПНО найти детский прон на серверах и заблокировать по IP.
                • 0
                  Что значит «только»? Думаете это кого-то утешит, если состав ст. 310 УК РФ налицо даже для самого объективного суда?
              • 0
                Я выше писал, что следует не быть русской компанией
                • 0
                  Не имеет значение, если находиться в России физически. Да и не находясь есть нюансы типа договоров о выдаче преступников.
      • 0
        Где-то читал, про передачу зашифрованных сообщений в комментариях на YouTube. Сообщения шифруются одноразовыми криптоблокнотами и просто выкладываются в общий доступ. Прелесть же!
        • 0
          А как они блокнотики получают?
        • 0
          Ага, и удаляются первым же модератором, увидевшим такое вот счастье…
  • –8
    https для соединения с абонентом — и так уже фактически стандарт, тут нечем хвастаться.
    Лучше расскажите нам про шифрование данных на ваших серверах и существует ли оно вообще.
    • +9
      Вы не очень внимательно прочитали пост. Речь не о https до пользователя, а о шифровании писем между почтовыми системами. И это пока, к сожалению, совсем не стандарт.

      Например, только около 30% почтовых систем, с которыми ведут переписку наши пользователи, такое шифрование поддерживают.
  • +2
    Круто. А какие ещё сервисы (из популярных) кроме GMail поддерживают шифрование?
    • –9
      Вконтакте (если мы о https)
      • +4
        Причем тут https? Разговор идет же о шифровании между серверами, а не между пользователями и сервером.
        • 0
          Прошу прощения, значит я не понял сути вопроса.
    • 0
      Например, Facebook умеет отправлять уведомления на почту с поддержкой шифрования.
  • +1
    Автор, чтож ты ничего не рассказал про структуру PKI? Публичная-то она — это хорошо, но PKI ущербна в самой своей сути из за наличия CA — «корней» дерева и тучи предустановленных «доверенных» сертификатов когда юзер доверяет непонятно кому. И вообще, это не хайтечно и напоминает допотопные времена, когда никакого DNS не было и все хосты прописывались в /etc/hosts, а службы — в /etc/services

    Пока еще SMTP по автомату принимает самоподписанные сертификаты, но что-то мне подсказывает, что эта халява продлится недолго. Например, в CommunigatePro уже есть опция «Отключить прием самоподписанных». И привет.

    $ openssl s_client -starttls smtp -crlf -host mx-corp.yandex.ru -port 25

    depth=2 C = US, O = GTE Corporation, OU = «GTE CyberTrust Solutions, Inc.», CN = GTE CyberTrust Global Root


    ФСБ негодуе, особенно от C=US

    • 0
      Фактически вопрос доверия в данном случае решается на уровне приложения, функции аутентификации TLS не используются.
  • 0
    А на токене можно ключ хранить?
  • НЛО прилетело и опубликовало эту надпись здесь
  • +4
    Ребят, ценность этого шифрования близка или равна нулю. Нарисуйте там чёрного человечка, между красным человечком и синим, и поймете почему.

    1) Магистральному провайдеру достаточно встать MITM-ом и для отдавать smtp Яндекса фейковые пакетики что удалённый MX не умеет STARTTLS, и всё. Что вы почту доставлять не будете? Да нет, вы просто пойдёте по старинке, plain-text-ом.

    2) Ничто, и никто не мешает магистральному провайдеру подсовывать для ваших smtp сертификаты, подписанные купленым Intermediate CA(аналогичных используемым в DPI) или каким-нибудь маленьким доверенным CA. И тем более, SSL никоим образом не спасает в этом месте от всяких там PКISM и прочих америкосов, кто имеет доступ внутрь больших корневых CA.

    Вобщем байки это всё, с человечками :)
    • +7
      Привет, Дим. Рад, что так внимательно следишь за новостями про нас. Помню, про твое умение пользоваться scapy, но, надеюсь, помимо этого, ты знаешь и про certificate pinning и тебе понятно, как он решает эти проблемы.

      Если нет, заезжай в гости, расскажем-покажем. Будем рады, если mail.ru тоже подтянется к шифрованию.
      • 0
        Привет Вов. Очень внимательно слежу, скучаю ведь :)
        Сertificate pinning(если он реализован конечно и вы действительно запоминаете issuer-ов для всех возможных MX) решает не все проблемы.
        Действительно, с Intermediate CA проблем не будет, но это не решает проблемы с потенциальным доступом АНБ к корневым сертификатам, например.

        Или с тем, что многие MX могут внезапно перевыпустить свой сертификат, уже через другого CA.
        И кстати именно по этой причине, в современные браузеры certificate pinning не встроен, т.к. процент false positive у него неимоверно высок.

        Крупные вендоры могут договориться, да, но что делать остальным?

        И ты не ответил про блокировку STARTTLS ;) Что будет, если DPI у магистральщика будет «отменять TLS», провоцируя downgrade до plaintext? Не можете же вы не доставлять письма.
        • 0
          Я ж тебе написал, что если через пининг выучить (или руками написать, когда речь идет о top-10 компаний), что вот для этих mx даунгрейдить нельзя, считай это эквивалентом HSTS. Поскольку MX'ов в мире сильно меньше, чем браузеров, а почта сосредоточена среди нескольких крупных игроков, решение проблемы на 80% выглядит реальным.

          В общем, следите за нашими анонсами, а планы мы традиционно не раскрываем.
          • +1
            Ну так вопрос-то остался без ответа: да, вы заметите, что Google внезапно перестал предлагать STARTTLS (а раньше предлагал, сертификат был выдан вот этим CA). Ну или внезапно предъявил сертификат от Komodo (вместо Geotrust через свой промежуточный).

            И что, откажетесь доставлять почту в этом случае?
            • 0
              Зачем сразу переставать доставлять почту? Самое простое — сравнить результаты на других каналах и принять решение. Есть ведь варианты, если подумать.
              • +1
                Представляю себе, насколько усложнится smtp-клиент, передающий почту другим серверам. Ему придётся как минимум знать, что есть «другие каналы»…
        • +1
          А если добавить в стандарт DMARC политику шифрования. Типа наша почта только с DKIM и шифрованная, иначе реджект.
    • +3
      > Ничто, и никто не мешает магистральному провайдеру подсовывать для ваших smtp сертификаты, подписанные купленым Intermediate CA(аналогичных используемым в DPI)

      Мешает то, что за подобные выкрутасы мозилла выкинет из списка доверенных CA, выпустивший сертификат для такого SubCA.
      Обычно, насколько я знаю, SSL bump в DPI делается лишь внутри организаций, при этом используется частный CA, добавленный в качестве доверенного на корпоративные машины через какие-нибудь групповые политики.
    • +3
      Встать MITM-ом и пассивно прослушать стоит разных усилий.

      Привет :)
  • –1
    в тему:
  • 0
    Немного не в тему, но всё же, как движутся дела с внедрением поддержки IMAP IDLE?
  • –3
    Только смысл от всего этого, если вы банально игнорируете добавление двухэтапной аутентификации?
  • +2
    Все меньше жалею, что отказался от Gmail в пользу Яндекса несколько лет назад.
    А ещё есть вопрос не совсем по теме: при получении письма можно узнать некоторую информацию об отправителе, например профиль в фейсбуке, привязанный к этому ящику. Можно ли как-то настроить показ этой информации? Кроме отвязки почты я способов не нашёл.
    • 0
      Facebook свободно показывает профиль, зарегистрированные на определённый email, если ввести этот email в поиск самого Facebook. Но запретить показывать свой портрет в Яндекс.Почте можно по инструкциям на странице help.yandex.ru/mail/abook.xml#social-profiles
    • 0
      Все меньше жалею, что отказался от Gmail в пользу Яндекса несколько лет назад.


      Но все-таки еще жалеете?
      • 0
        Когда даю свою почту каком-нибудь гику, то вижу явное пренебрежение на лице, например.
  • 0
    Привет Эдварду следовало бы заключить в тег , вы не находите? Он ведь показал, что АНБ не дураки и врезались на участке Гугл-Гугл, где трафик нешифрованный. Рассказали бы, если можно, как у вас с этим дело обстоит. Все сервера в Москве или есть региональные датацентры?
    • 0
      Черт, и я на это попался, хоть думал об этом прямо во время написания :)
      «в тег sarcasm» — следует читать.
  • +2
    Немного не по теме, но всё же выпущу немного лучей зла: яндексовцы, зачем при регистрации в ваших сервисах стоит наиглупейшее ограничение на длину пароля и множество используемых символов? То есть какой-нибудь qwerty проходит на ура, а что-нибудь длиннее 20 символов или, скажем, содержащее знак вопроса сразу бракуется. Наверное, пользователю лучше знать насколько секурный пароль ему использовать?
    • +1
      Ограничение связано с тем, что логин в Яндексе используется в очень различных сервисах и протоколах, каждый из которых в своё время накладывал на пароль свои ограничения как по длине, так и по содержанию. Когда мы убедимся, что ни одна часть за логином не пострадает от расширения набора символов и длины пароля, мы, скорее всего, изменим существующие ограничения.
  • +1
    Ещё одни распространенным протоколом, где регулярно используется STARTTLS, является LDAP.
  • +2
    Спасибо, интересно.
    Немного не по теме вопрос, но всё-же: у меня есть проектик мелкий связанный с электронной почтой и там используется свой SMTP релей. Проблема в том, что при попытке отправить почту на yandex ящики постоянно возникает ошибка
    retries_exceeded {temporary_failure,"mx.yandex.ru",<<"451 4.7.1 
    Sorry, the service is currently unavailable. Please come back later. aybVX4avs9-66CaKdFk\r\n">>}
    retries_exceeded {temporary_failure,"mx.yandex.ru",<<"451 4.7.1 
    Sorry, the service is currently unavailable. Please come back later. boXDD0YAFa-6aC0CbEh\r\n">>}
    

    Если повторять попытку отправки много раз, то всё-же письмо проходит. С другими сервисами (mail.ru, gmail) всё проходит с первого раза.
    Это нормальное поведение и просто нужно продолжать попытки или всё-же где то закрался баг?
    • +5
      Это банальный грейлистинг. Скорее всего вы просто недостаточно аутентифитировали свой релей. Стоит начать со следующих ключевых слов: PTR, SPF, DKIM, DMARC.
      Думаю эта проблема к тебе межсерверного шифрования не относится. Открой вопрос, например, в тостере. Там вам быстрее помогут.
      • 0
        А, в смысле «спамеры не будут делать много попыток отправить письмо, а легальным сервисам хочешь-не-хочешь а нужно». Что то такое читал…

        SPF добавил несколько дней назад, DKIM в процессе. DMARC без DKIM не работает, так что тоже в процессе.
        PTR я так понимаю не получится настроить, если с одного сервера отсылается почта с нескольких доменов.
        • +1
          PTR как раз получится настроить. Никто же не требует, чтобы почта с user@domain.ru уходила обязательно с хоста в domain.ru.

          Настройте в PTR то же имя, что и в прямой, а уже для MX-ов всех ваших доменов укажите именно это одно имя. Ну и в SPF и прочих записях указывайте его, если используете конкретную технологию.
      • 0
        Грейлистинг — бессмысленная технология IMHO. Сделана в надежде, что «спаммеры так не умеют» и «у них машинки слабенькие». Оба тезиса неверны.
        • 0
          Не совсем так. Самое главное в грейлистинге это проверка засылающей стороны а) на реализацию корректной обработки ошибок и б) на корректную реализацию очереди с рекомендуемыми в RFC таймаутами. Т.е убеждение, как одна из ряда проверок, что перед нами какой-никакой MTA. Я не фанат данной технологии, но по информации оно срезает от 10% до 50% спама в зависимости от того в какие спам базы вы попали :)
          Минусы технологии только в увеличенном времени доставки. Но вот яндекс, в отличие от горе админов, использует грейлистинг правильно и включает его только при срабатывании фильтра по контенту.
      • 0
        Оказалось, что всё намного проще. После экспериментов заметил, что у меня в EHLO подставлялся не реальный домен сервиса а локальный хостнейм из /etc/hostname
        После того как это поправил проблема вроде исчезла. Но нужно ещё понаблюдать.
        • НЛО прилетело и опубликовало эту надпись здесь
  • 0
    Кстати, правильно я понимаю, что 465 порт сразу ssl соединение, а 587 Submission?
  • –3
    Вот лет 15 назад это было ново :)

    Новость — отличная, что ни говори!
    • 0
      За что минусуете? Новость и правда отличная, а что вводят сейчас, а не 5, а то и 10 лет назад — да, не очень рано, но тоже понять можно, зашифровать такое число соединений и такой трафик тоже немало ресурсов кушает.
    • +1
  • 0
    Вопрос на засыпку: а клиентское шифрование собираетесь поддерживать, чтобы даже вы не знали текста письма? Хотя, конечно, Директ…
    • 0
      Если Яндекс не будет знать о содержимом письма, то как он сможет его отдавать по IMAP/POP3, отсылать на другие сервера получателям?
      • 0
        Расшифровывать на стороне клиента, используя что-то вроде реализации PGP на Javascript.

        Отдать по IMAP/POP3 можно. Посмотреть, «что там» — нельзя.
        • –1
          Там другие проблемы возникают.
          1) Где хранить приватный ключик юзера для расшифровки письма
          2) Где хранить и как получать публичные ключи тех, кто собсно юзеру пишет, для проверки подписи напримерили для шифровки сообщений для них.

          т.е. при помощи JS это делать вообще мимо, нужно делать в каком-нибудь клиентском приложении. Можно в Я.Браузере или аддоном каким-нибудь, но тогда возникают проблемы вида: А я зашел в свою почту с другого компьютера, и письма прочитать не могу, т.к. приватных ключиков нету.
          • 0
            Как раз JS в браузере — отличное клиентское приложение. Например, все плагины в Fx и есть JS.

            Приватный ключ хранить можно например в Local Storage. Публичные ключи хранить можно где угодно, например, вообще не хранить, а дёргать с сервера ключить каждый раз — на то они и публичные.
            • 0
              То что плагины ФФ пишутся на JS(XUL) это понятно, но свои внутренние данные они хранят на диске в надёжном пользовательском профиле, а не в куках или некоем ненадёжном localstorage.

              Ты представь себе ситуацию, когда у тебя есть сотни зашифрованых писем, а твой приватный ключик для их расшифровки лежит в localstorage, который очищается сотней левых тулз или плагинов для браузера. Потерял ключик — потерял все письма.
              • 0
                А чем это отличается от, например, удаления профиля? Тоже же можно. А ещё винт может посыпаться.

                Конечно приватный ключ должен храниться там в зашифрованном (парольной фразой) виде, а также где-то на зашифрованной флешке должна быть его резервная копия. Это должно быть так вне зависимости от того, как устроено шифрование и т. п.
                • 0
                  Отличается тем, что в случае с плагином ты можешь заставить пользователя сохранить свой ключик где-нибудь в надёжном месте, а в случае с JS и localstorage уже нет :)

                  • 0
                    И в случае с плагином никак не получится заставить. Он всегда, например, сможет «сохранить и потом стереть».

                    Самое главное: запрещено заставлять. Предупредить и напомнить — да, но заставлять — нет. Хочет выстрелить себе в ногу — пусть стреляет, это его право. Я ему не хозяин.

                    Вы всё придумываете какие-то странные отговорки, вроде как «не получится» или «невозможно на джаваскрипте» или там «негде хранить ключ». Не понимаю, зачем. Можно всё, можно. Но Яндексу и прочим это не нужно — наоборот, во вред, т.к. контекстная реклама.
                    • НЛО прилетело и опубликовало эту надпись здесь
                      • 0
                        например в Local Storage
                        • НЛО прилетело и опубликовало эту надпись здесь
                          • 0
                            Почему не подходит? Ключ вполне представим в виде строки. Реализовать RSA и AES на Javascript можно. Чего не хватает?
                            • НЛО прилетело и опубликовало эту надпись здесь
                              • 0
                                Технически это возможно. Да, Кэп, Идея глупая (с точки зрения безопасности), но точно реализуемая.

                                Странно ещё видеть кого-то, кто беспокоится, что LocalStorage может попать в своп, но кого не смущает сама по себе идея веб-сервиса с «end-to-end шифрованием в браузере». Помните веб-сервис генерации SSH-ключей? Вот ничем же не отличается по сути.

                                • НЛО прилетело и опубликовало эту надпись здесь
        • 0
          Я, конечно, прошу прощения, но браузеров, умеющих получать почту по POP3/IMAP и затем исполняющих полученный с сервера JS для обратоки писем, не бывает.
        • +2
          И я правильно понял, что вы не хотите доверять серверу яндекса открытый текст сообщения, но с радостью доверите его коду, который передается в браузер с сервера яндекса и может измениться в любой момент?
          • –1
            Это то же самое, что доверять, скажем, операционной системе Windows. Всё равно всё может измениться в произвольный момент — пришло обновление, которое ставится принудительно вне зависимости от настроек обновлений — и привет.
            • 0
              Какой-то витиеватый ответ на вопрос. :)
              Т.е. можно считать, что все-таки вы будете доверять коду, который отдает вам почтовый сервис, которому вы не доверяете содержимое писем. Я правильно понял?
              • 0
                Если витьеватый ответ, то — я вообще-то не доверяю Windows и не использую её ;)

                А если серьёзно, то нет, я не буду доверять. Я не буду вообще доверять это никому в «обычном» интернете.
                • НЛО прилетело и опубликовало эту надпись здесь
                  • 0
                    в «отправленных» оно сохраняется уже в зашифрованном виде. Причём так, что я сам по идее не способен расшифровать: для этого нужен приватный ключ адресата, которого у меня естественно нет
                    • НЛО прилетело и опубликовало эту надпись здесь
                    • +1
                      Можно шифровать и на свой ключ тоже, как вариант.
      • 0
        А зачем для этого ему знать содержимое? Вот я сейчас отправляю шифрованные (шифрую в консоли и копипащу в веб-интерфейс) письма и нормально доходят.
    • 0
      И как он будет определять спам?
      • +1
        По содержимому — никак. Ему будет доступно некоторое количество метаданных (например, заголовки).

        Рассылать зашифрованный спам — практически бесполезная затея, на мой взгляд. Я всегда могу настроить со своей стороны, чтобы зашифрованный-и-не-подписанный контент автоматически отбрасывался, а подписываться спаммер вряд ли очень захочет, а если и подпишется — вряд ли у него наберётся много доверия.
      • 0
        А ему это нужно?
  • 0
    Не понимаю почему это не было включено с самого начала? Не хватало серверных мощностей?
  • 0
    А ни у кого последние 3 дня проблем с отправкой через smtp не возникает?

    Подключена Яндекс.Почта для домена. Больше года всё работало без проблем. С 7-ого появились задержки в получении почты адресатом, письма (на gmail) приходили с опозданием в 5-10 минут, потом вовсе перестало что либо приходить. 9-ого в обед вывалилось всё, что застряло с 7-ого. А сегодня частенько «Send AUTH command first» и «Sender address rejected: not owned by auth user» на пустом месте для приблизительно 1 письма из 10.

    Кто виноват и что делать?
    • 0
      Авторизируюсь на smtp.yandex.ru на 465 порт с ssl. Пробовал 587, tls — не помогло.
    • 0
      Жалуйтесь саппорту через feedback2.yandex.ru/pdd/other/more/?from=pdd а не сюда.
      • 0
        Было сделано в первую очередь, однако ответ задерживается. Хотелось бы получить больше информации и не только от саппорта, поэтому и написал сюда.
  • 0
    а без SSL работать можно или для него порты принудительно убрали?
    • 0
      Если речь про POP, IMAP и SMTP, то работать без SSL больше нельзя. На MX и отправляющих серверах пока ещё некоторые письма принимаются и отправляются без SSL, потому что не все почтовые службы поддерживают работу по SSL в этом месте. Но вообще работа без шифрования — это снижение безопасности информации, поэтому Яндекс.Почта старается безальтернативно переходить на SSL.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка