company_banner
10 апреля 2014 в 15:50

Почему после обнаружения Heartbleed мы не предлагаем пользователям Почты Mail.Ru менять пароли

Короткий ответ на вопрос, озвученный в заголовке: потому, что этого не требуется. Heartbleed, одна из самых критичных уязвимостей в истории OpenSSL, не ударила по нашим пользователям. Чуть более подробный ответ – под катом.



Мы, как и многие другие сервисы, используем библиотеку OpenSSL в наших проектах, однако бОльшая часть наших серверов, включая почтовые, оказались вне зоны риска. На многих наших проектах мы используем OpenSSL 1.0.0, которая оказалась неуязвима к атаке.

Тем не менее, мы не спешили расслабляться – сначала нужно было проверить остальные проекты. На коленке был написан NSE-скрипт к Nmap, эксплуатирующий уязвимость, и уже через полчаса мы получили список машин с уязвимыми версиями OpenSSL.

Уязвимыми для атак оказались серверы нашей баннерной системы и несколько контент-проектов. Немного паники, и к 14:00 8 апреля уязвимость была запатчена.

Хотя на этих проектах Heartbleed не давала возможности получить доступ к личным данным, логинам или паролям пользователей, злоумышленники всё же могли получить авторизационные сессии (cookie) случайных людей, а так же потенциально скомпрометировать наши SSL-сертификаты.

Разбираться с SSL-сертификатами мы начали немедленно. Все критичные сертификаты уже перевыпущены и будут заменены, работа по замене остальных продолжается.

Что же касается авторизационных сессий пользователей, то и тут мы были защищены. На наших критически важных проектах работает так называемое разделение сессий. Суть его в следующем: если даже злоумышленник так или иначе завладеет авторизационной сессией пользователя, то с её помощью он не сможет получить доступ к другим проектам портала.

Может быть, прогноз Codenomicon сбудется, и Heartbleed действительно станет для многих сервисов поводом усилить систему безопасности. Для нас вся эта история сыграла роль учебной тревоги – мы потренировались быстро реагировать на сообщение об угрозе и оперативно закрывать все лазейки. Ну и, пожалуй, говорить злоумышленникам «no pasarán!».
Автор: @Soboleva

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

  • НЛО прилетело и опубликовало эту надпись здесь
    • +45
      Почта критично — на нее приходят подтверждение о смене паролей на многих сервисах. Завладеть основной почтой человека — все равно что получить доступ ко всем сервисам, привязанным к этой почте.
      • +2
        Что ещё раз напоминает про важность двухфакторной аутентификации на таких важных сервисах.

        UPD: извините, сморозил глупость — двухфакторная аутентификация не спасёт от угнанной сессии. Извините ещё раз.
        • 0
          Двухфакторная аутентификация позволит потом восстановить доступ к угнаной почте, например.
    • +2
      Не понимаю, при чем здесь РайффайзенБанк. У них сейчас SMS либо ридер, генерирующий одноразовые пароли, без которых ничего перевести невозможно. А по ссылке выше последнее сообщение от 02.12.2013.

      P.S. мне от них пока ничего связанного с внеочередной сменой пароля не приходило.
  • 0
    Интересно было бы посмотреть примерный список тех, кого удалось слить с использованием данной уязвимости. Судя по слухам — всё очень печально.
    • +1
      Мне кажется, что из известных сервисов больше всех пострадал Yahoo. Их медлительность при патчинге стали активно ретвитить, провоцируя людей заряжать скрипты на login.yahoo.com

      Про остальных — не знаю. Но даже на текущий момент, люди не особо задумываются о том что уязвимость не в HTTPS, а в OpenSSL. А значит все Jabber порты, SMTPS, SMTP/TLS и т.п. уязвимы наравне с вебом.
      • 0
        Насчёт jabber — не всегда. Если Jabber-сервер Ejabberd, то всё ок.
    • +1
      Хах! Еще даже не все российские банки залатали дыру, о чем тут дальше говорить.
  • +61
    Почему после обнаружения Heartbleed мы не предлагаем пользователям Почты Mail.Ru менять пароли


    Потому что mail.ru не страшны взломы и угоны сертификатов — они и так подписывают своими сертификатами вредоносное ПО (пруф 1, 2).
    • +1
      Насколько мне известно, это были неблагонадёжные партнёры и от них уже давно избавились.
      И я склонен верить тому, что впредь такого не повторится :)
      • +42
        Суть понятия «сертификат» как раз в том, чтобы знать, кто отвечает за подписанный бинарник, чтобы «неблагонадёжный партнёр» не мог выдать своё ПО за чужое. Подписано сертификатом Mail.ru? Отвечает Mail.ru.
        • –16
          Сертификатиом подписывается только наш бинарник, который занимается загрузкой и установкой. Устанавливаемый бинарник нашим сертификатом не подписывался. Примерно то же самое, что Install Shield или Akamai'евский загрузчик обвинять в том, что он устанавливает вредоносное ПО.
          • +13
            Ну дурачка-то не включайте. Сколько раз примерно вы видели подписанный инсталлшилд, устанавливающий вредоносное ПО? Для чего в винде есть галка «всегда доверять полученному от %companyname%»?
            • +3
              Зачем на чужой смотреть, давайте прямо сейчас свой сделаем.

              Идем в папку c:\program files\InstallShield Installation Information / c:\program files (x86)\InstallShield Installation Information (она скрытая)
              Cмотрим по папочкам.
              Ищем setup.exe с электронными подписями. У меня есть на выбор с подписями от:

              InstallShield Software Corporation
              Macrovision Corporation
              Realtek Semiconductor Corp
              CyberLink

              Могу подарить любой.
              Из любого из них можно сделать троянца, например подменив неподписанный _setup.dll. Проверил, целостность не проверяется.

              P.S. Я не спорю хорошо это или плохо, более того, негативно отношусь к дистрибуции посредством партнерских программ. И еще более того, 20 лет участвую в опенсорсных проектах. Но это же технический чятег, да, я могу указать кому-то на техническую неточность?
              • 0
                Из любого из них можно сделать троянца, например подменив неподписанный _setup.dll. Проверил, целостность не проверяется.

                Что вы имеете в виду под проверкой целостности? Проверку именно виндой в момент запуска установщика или проверку самим установщиком этой библиотеки?
                • +2
                  Ни там ни там.

                  Вот PoC с тремя разными setup.exe с разными подписями:
                  cloud.mail.ru/public/8b9e46cd16ff/virus.zip
                  запускает безопасный «вирус» переименованный в data1.cab.
                  Сорсы приложены.
                  Т.е. воспроизведите действие обычного пользователя — загрузите, откройте в проводнике. Он предложит извлечь, после чего запускайте любой из сетапов.

                  Похожий фокус можно провернуть практически с любым подписаным файлом и это будет до тех пор, пока система не начнет проверять все исполняемые файлы на наличие подписи.
                  • 0
                    Похожий фокус можно провернуть практически с любым подписаным файлом и это будет до тех пор, пока система не начнет проверять все исполняемые файлы на наличие подписи.

                    Вам не кажется, что это сродни перекладыванию с больной головы на здоровую? Система проверяет подпись того файла, который запускается пользователем. Потому что именно это действие пользователь санкционировал лично. Все прочие исполняемые файлы, в том числе подсасываемые установщиком библиотеки, должны проверяться на целостность самим установщиком, ибо только он знает, какие библиотеки ему нужны.

                    Почему именно так? Да потому что библиотеки в проекте могут идти из разных ресурсов, и условиями лицензий на их использование может быть запрещена любая их модификация, а цифровая подпись требует модификации бинарника. Как следствие, если ОС обяжет подписанный ехе-шник использовать только подписанные dll-ки, у части разработчиков возникнут проблемы.

                    Поэтому идеологически верно контролировать целостность используемых тобой библиотек самостоятельно. По крайней мере если ты действительно хочешь обеспечить безопасность пользователю своего продукта.
                    • 0
                      Я не знаю, какое решение теоретически правильное, я показываю что тот механизм проверки целостности, который есть, сейчас на практике не работает и тривиально обходится, PoC выше.

                      То, что Вы предлагаете при текущей организации загрузки приложения в Windows не сработает. Производитель EXE файла не знает какие именно библиотеки будут подгружены итоге в адресное пространства процесса. Системные библитеки могут подгружать другие библиотеки. Для того, чтобы все это контролировать надо писать свой динамический линковщик взамен системного и перехватывать системные вызовы на загрузку библиотек. Т.е. подменять функционал системы. При этом вирмейкеру достаточно для маскировки любого одного приложения, которое так делать не будет. Вот это как раз перекладывание с больной головы на здоровую — реализовывать системный функционал в каждом исполняемом файле.
                      • 0
                        О системных библиотеках никто и не говорит. Они не идут в комплекте поставки приложения, и их целостность — уже забота той стороны, которая эти библиотеки в систему запустила.

                        А вот проверять целостность тех библиотек, которыми ты самолично комплектуешь свой продукт — подход более чем уместный. Ваш PoC выше не прокатит, если использовать именно такой подход. Как не прокатит и установка говнософта с помощью подписанного Mail.ru инсталлятора, потому как инсталлятор должен будет сам знать, какой _setup.dll с ним используется.
                        • 0
                          Нет, это прокатит только для библиотек, которые грузятся в процессе выполнения приложения через LoadLibrary. Но не прокатит для библиотек, которые подключаются через динамическую линковку при старте приложения (а их большинство), т.к. динамическую линковку в Windows выполняет не само приложение и библиотека будет загружена раньше, и DllMain выполнен раньше, чем начнет работу код приложения и будет возможность проверить целостность библиотеки. Скорее всего, есть какой-нибудь способ проверить уже загруженную библиотеку до того, как сработает DllMain, но все равно это пляски с бубном и наколенные решения. Гораздо проще и правильней подписать свои библиотеки и на уровне системы не разрешать загрузку неподписанных.
                          • 0
                            О чем вы там спорите? Очевидно же, что файлы, загружаемые системным загрузчиком (динамически прилинкованные), должны проверяться им же, а файлы, загружаемые самим приложением — должны проверяться приложением.
                            • 0
                              Как вариант, да.
                              А почему не очевиден вариант проверять все, что грузится через LoadLibrary?
                              • 0
                                Антивирусники так делают… и при этом система загибается. Слава богу, додумались «кешировать» результаты проверки — для каждой версии базы вирусов неизмененные файлы проверяются лишь один раз.

                                Но блин, я один раз встречал приложение, которое модифицирует исполняемые файлы в процессе работы и делает это часто с последующим запуском. Это был какой-то видеоконвертер, который создавал «оптимизированный» файл обработчика чуть ли не под каждый кадр. Фух, теперь вспоминаю как страшный сон.
                                Антивирусу это не понравилось и каждый раз надо было нажимать какие-то кнопки для продолжения.
                                • 0
                                  Не путайте сигнатурную проверку с проверкой подписи. У них немного разная скорость работы.
              • 0
                Из любого из них можно сделать троянца, например подменив неподписанный _setup.dll. Проверил, целостность не проверяется.


                В этом и проблема. Да, в данном случае Загрузчик IS не проверяет, что он устанавливает. Так же, как и загрузчик mail.ru. Возможно, это старая версия IS лохматых времен, а новые проверяют, а Realtek и прочие не озаботились апгрейдом.

                Но есть и различие с загрузчиком mail.ru. Устанавливаемый контент находится не внутри загрузчика, а скачивается по определенному URL. У mail.ru ЕМНИП была процедура проверки загружаемого приложения (отдельный вопрос, насколько она была честной и тщательной, но была). Но результаты этой проверки не фиксировались в виде цифровой подписи самого контента. Достаточно подменить файл по этому URL и троян-даунлоадер готов.
          • +5
            То, что установка идет через прокси, сути не меняет. Единственная цель всей этой схемы — беспрепятственное попадание левого ПО на комп неискушенного пользователя. «Левого» в данном случае означает, что автор поделки не тратился на сертификат, его никто не проверял, что он не мошенник и не вирмейкер. То есть доверия к нему никакого. А ваша схема создает у пользователя иллюзию, что ему можно доверять. Это обман пользователя, как ни крути. Это примерно то же самое, что вывешивать сверху каждого письма зеленую плашку с текстом «Проверено антивирусом , все OK», когда на самом деле никакой проверки не производится.
            • +1
              Последние кавычки читать как «Проверено антивирусом AVname, все OK».
              • –6
                Я чуть выше написал. Если пользователь из недоверенного источника готов скачать исполняемый файл и его запустить, то помочь ему очень сложно. Если это будет не setup.exe, а zip-файл в котором будет дистрибутив чего-то с setup.exe, причем с вполне доверенной подписью — что-то изменится?
                • 0
                  Если пользователь из недоверенного источника готов скачать исполняемый файл и его запустить, то помочь ему очень сложно.

                  Вы знаете, далеко не все производители софта позволяют скачать свою продукцию со своего сайта через HTTPS. Публикует хэши от выложенных бинарников и того меньше контор. И я лично помню случаи, когда с официального сайта разработчика меня перекидывало на какой-нибудь download.com, потому что это был официальный метод распространения софта.

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

                    Это Ваша точка зрения. Моя точка зрения, что в настоящий момент такого способа в Windows, вообще нет, т.к. контролируется целостность только непосредственно исполняемого файла. Разультат выполнения приложения зависит не только от исполняемого файла, который непосредственно запускается, но и от среды выполнения — динамических библиотек, данных, с которыми приложение оперирует, параметров настройки. Пока не контролируется целостность и валидность хотя бы одной компоненты — есть возможность модифицировать результат работы подписанного приложения. PoC когда запуск подписанного приложения приводит к выполнению троянского кода — выше. И это не особенность конкретного инсталлятора, такое можно сделать с практически любым подписанным EXE-файлом.

                    Мне кажется, для десктопных систем надо полностью отказаться от установки приложений мимо подписанных пакетов установки и не разрешать запускать приложения или менять их среду выполнения другими способами, что-то похожее есть в мобильных системах Пока этого нет в десктопных системах, но к этому все и идет.
                    • 0
                      Вы несете какой-то бред. Достаточно сделать установщик состоящий из одного исполняемого файла и подписать его. Этот файл должен содержать все необходимые данные для установки. Модифицировать его, сохранив при этом валидность подписи будет практически невозможно. В случае с даунлоадерами они должны скачивать только подписанные пакеты установки и проверять их подпись. Вот и все, хватит уже отмазываться. Вы просто не хотите обеспечить (да собственно я уверен, что и цель такую не ставили) защиту пользователя от «левого» софта.
                      • 0
                        Я полностью с Вами согласен и чуть ниже написал то же самое. Чтобы это работало на практике, в десктопной системе не должно быть способа загрузить и выполнить приложение другим способом.

                        Но «должен» и то как сейчас на практике распространяется софт — это ведь разные вещи, да?
                    • –1
                      Да и ник у вас соответствующий что тут говорить.
          • +1
            О да. Это безусловно меняет дело. Я надеюсь, что вам по жизни будут попадяться врачи с таким же убеждением как у вас. Они будут делать вам прививки и говорить, что мы оказываем вам медицинскую услугу «инъекция» а что мы вводим — это не наша ответственность, это к производителю вакцины, мы у них не спрашивали что это, нам сказали так нужно. Ну и почаще вам продавцов недвижимости, которые отвечают только за «подписание» договора, а что вы там получите, чтоб их не волновало. Ну и в магазине вам продавцов, которые отвечают только за правильно пробитый чек, а что там в пакете они насовли — чтоб ваша ответственность была, вы же покупаете. Почаще вам людей встречать, которые четко отделяют свою зону ответственности и чтоб она не подпадала под типичные ваши ожидания. Чтоб вам нужно было каждую закорючку проверять и кропотливо искать тех, кто возьмет на себя обязательства в полном объеме и так как вы ожидаете.
  • +12
    Не особо информативная статья. Заголовок
    Почему после обнаружения Heartbleed мы не предлагаем пользователям Почты Mail.Ru менять пароли
    и ответ
    На наших критически важных проектах работает так называемое разделение сессий.

    Ни короткого объяснения что это такое или как оно работает. Получилось: "- Почему ..? — Потому."
    • +4
      В скором времени мы обязательно расскажем об этом подробнее )

      Но если просто, то на данный момент, для каждого домена третьего уровня выставляется отдельная Secure и HTTPOnly авторизационная кука, вместо одной общей. При этом сохраняется единая авторизация, и снижаются риски эксплуатации XSS и угона сессии на каком-нибудь богом забытом проекте компании, куда ещё не дошли руки безопасников.
      Примерно по такой-же схеме работает авторизация на Google.com
    • +2
      разделение же, а значит один сервис проекта — одна сессия. Получив сессию почты можешь нагадить только в почте, все остальные сервисы в рамках проекта будут обломайтунг.
    • –3
      Все очевидно же. Разделение сессий — это когда ни у кого не дошли руки сделать единую сессию…
      • +2
        А может это всё же означает персональный sid для каждого домена/проекта? И в случае смены IP (= кражи сессии) sid «перевыпускается» центральным auth-сервисом, на котором вы логинитесь? При взломе auth-сервиса это не спасает, но зато это весьма ограниченный участок, который можно за счёт этого сделать высоко надёжным. Некоторые крупные проекты примерно так и работают, судя по редиректам.
        • 0
          Да, вы правы, всё так и есть.
      • 0
        Единая сессия, всегда ведёт к большим проблемам в безопасностью, поэтому что это самый очевидный, самый лёгкий, но самый небезопасный путь. И большинство компаний начинают именно с единой сессии.

        Как пример уязвимостей доступных к эсплуатации с единой сессией:
        1) XSS на проекте a.domain.com, ведёт к компрометации b.domain.com. Хотя на b.domain.com — багов не было.
        2) Кража кук в открытой сети на проекте a.domain.com(который не умеет https) ведёт к компрометации b.domain.com(который умеет и любит HTTPS). Потому что невозможно выставить Secure флаг для авторизационных cookie — a.domain.com работать перестанет.
        и т.п.
  • 0
    > злоумышленники всё же могли получить авторизационные сессии (cookie) случайных людей, а так же потенциально скомпрометировать наши SSL-сертификаты.
    Они просмотрели весь трафик через свои сервера чтобы узнать это?
    • +4
      Потенциально, в кусках памяти этих веб-серверов, которые можно было читать при помощи уязвимости, могли встречаться некритичные куки пользователей и приватные ключи наших сертификатов.
      Мы решили не рисковать и отозвать их.
  • +2
    А вы не подумали, что при взломе сторонних сервисов где указана почта, первым делом хакеры проверяют совпадет ли пароль от сервиса с паролем от почты?
    К примеру, из этой вчерашней тестовой выборки из 10 аккаунтов игрового сервера целых 3 аккаунта mail.ru были скомпроментированы.
    habrahabr.ru/post/218661/#comment_7480907

    А надо сказать, что огромная куча сторонних сайтов уязвима и сейчас.
    Так что как минимум предупредить красным шрифтом стоит.
    • +1
      Спасибо, действительно, не подумали. Сейчас займёмся )
      P.S. А может есть где-нибудь общая база знаний последствий атаки? Чтобы понять кто мог потенциально пострадать?
      • –4
        facepalm.jpg
        • +3
          Ну, если вы расскажете нам где пачками брать аккаунты с других сервисов, мы будем вам безмерно благодарны :) Да и не только мы.
      • +2
        Что значит «последствий»? Дело еще не закончено. Осталось прочекать все хосты в интернете — нет ли на них уязвимостей. Ну и потом мониторить, чтобы таковые не появлялись.
        • +1
          Но дампами то на паблик никто делиться не будет (
          Всё что найдём нашего на других сервисах или в паблике — конечно проверим.
      • +4
        Вам надо предупредить об абсолютной недопустимости использовать пароль от почты где-либо еще в связи с этой уязвимостью.
        Если пароли уже совпадают, то предложить срочно сменить.
        • +2
          > предупредить об абсолютной недопустимости

          Это не работает.
          1) Мозг человека физически не может генерировать криптостойкие и различные пароли. Ну пять, ну семь хороших паролей для самых нужных мне сервисов я могу держать в памяти. Для регистрации же на каком-нибудь говнофоруме используется какой-нибудь «любимый» пароль типа 111111.
          2) Заранее очень сложно определить — нужен ли данный сервис мне, чтобы ради регистрации придумывать стойкий пароль и как-то его сохранить у себя.
          3) Возрастной порог вхождения в интернет уменьшается — сперва условный «первоклассник» заводит себе почту, а потом уже начинает курить… тьфу! читать маны и узнает о необходимости иметь хорошую защиту

          > Если пароли уже совпадают, то предложить срочно сменить.

          У mail.ru нет возможности определить — совпадает ли пароль пользователя на почте с паролем на каком-либо сервисе.
          • 0
            > предупредить об абсолютной недопустимости

            Это не работает.
            1) Мозг человека физически не может генерировать криптостойкие и различные пароли. Ну пять, ну семь хороших паролей для самых нужных мне сервисов я могу держать в памяти. Для регистрации же на каком-нибудь говнофоруме используется какой-нибудь «любимый» пароль типа 111111.

            Противоречивая какая то информация. Если я могу запомнить два пароля, то уже могу использовать один — для почты, а другой — для всего остального. А уж тем более 5 или 7 :)

            Ну и очередной повод обзавестись менеджером паролей для хранения учетных данных на всяких не очень часто посещаемых сервисах.
            • 0
              Вы говорите «как должно быть», я с этим не спорю, но рассказываю «как есть на самом деле».
              Человек сперва заводит себе почту, потом узнает о криптостойкости и много-много времени спустя приходит к использованию менеджеров паролей. Во всех книжках, во всех местах на всех сайтах написано, что не надо использовать один и тот же пароль на разных ресурсах. От того, что мы с вами повторим это еще раз для посетителей хабра — ничего не изменится. Здешняя аудитория об этом и так знает (надеюсь)

              Если mail.ru произведет рассылку по пользователям и/или повесит алерт о желательности смены пароля (придется вешать всем) — по большому счету тоже мало что изменится. Бегущий генерал вызывает в военное время панику, а в мирное время — смех. Еще раз повторю — я не считаю, что это делать не надо. Я говорю, что это не спасет.
              • 0
                Я бы не говорил, что это «не работает», я бы сказал, что у этого способа «низкая эффективность». Можно сколько угодно напоминать пользователям о том, что нужно иметь разные пароли для разных сервисов, но пока пользователь сам до этого не дозреет — эти напоминания ни к чему не приведут. Но на тех, кто «дозрел», напоминание все же может повлиять.

                По большому счету — ничего не изменится, но если считать конкретных людей, которых эта рассылка может подтолкнуть к действиям — то, вполне возможно, польза будет. Не «спасение», ни в коем разе. В этом случае вполне подходит фраза о том, что «спасение утопающего — дело рук самого утопающего».
        • +5
          Вы правы, это плохо, т.к. на многих сервисах е-мейл является логином, если пароль там совпадает с паролем от почтового ящика — это катастрофа. Мы стараемся об этом предупреждать пользователя при любой удобной возможности, я говорю это в каждом комментарии в СМИ по поводу безопасности. К сожалению, заставить людей довольно сложно.
        • +1
          Если вы имеете ввиду разные ресурсы mail.ru, то у нас централизованная система аутентификации, почти для всех ресурсов mail.ru пользователь авторизуется в одном месте и нет необходимости хранить и защищать много паролей в разных местах. Что во многом спасло нас от этой атаки.

          А вто то, что пользователь использует один и тот же пароль в разных сервисах — это действительно проблема, о ней мы стараемся говорить при каждом удобном случае. Вот здесь, например: http://habrahabr.ru/company/mailru/blog/169801/ достаточно подробно объясняется почему не надо так делать.
      • 0
        могу добавить что из примерно 10 проверенных с сайта который для меня важен — в одном случае логин и пароль пользователя с mail.ru подошел к почте… дальше… было решено не смотреть. так что проблема вполне себе реальная.
  • –17
    Добавьте, пожалуйста, кармы до 5, не могу опубликовать статью о вредоносном скрипте в Google Analytics (Да простит меня НЛО)
    • –7
      Ok, можете минусовать мне карму. Вот сам топик: storage.sashok724.net/temporary/habratopic.html
      Если кто хочет — выложите. Правда, интересно, у одного ли меня такая проблема.
      • 0
        Google Analytics здесь не причём.
      • 0
        Ваш топик интересен. Но расследование не доведено до конца. Похоже на зловредный прозрачный прокси. Проверьте, не взломан ли роутер.
    • +1
      Такие просьбы пишут только друзьям в личку, и то НЛО за такое может забанить даже «топовых» пользоватей и за благие намерения.
      • –3
        Я уже понял… Но друзей на Хабре у меня пока что нет.
    • –3
      Всем еще раз спасибо, в отрицательной карме доступен Recovery Mode ;)
  • –1
    Disclaimer: Мнение автора комментария может не совпадать с мнением его работодателя.
    Вы уж простите, не удержался.

    Твой позорный недуг в подвиг определим. © ДМБ

    • +2
      Привет Эльдар :) Вас там бьют в Яндексе за несогласие с мнением партии?
      В чём же наш позорный недуг?
      • –1
        мне нечего о нем рассказать т.к. я к нему не имею никакого отношения.
      • 0
        Скорее это моя личная профессиональная деформация:

        www.ssllabs.com/ssltest/analyze.html?d=e.mail.ru

        странно видеть, как люди пиарятся на отключении TLS в 2014 году ;)
        Peace.
        • +1
          У нас не возникало нужды переходить на TLS 1.2, можешь считать что стабильность — это наше всё.
          В ближайшее время, безусловно, проапгрейдимся, если новых багов не найдут)
  • 0
    Теперь этот баг будет поводом для ПР? 8)
  • –5
    >Хотя на этих проектах Heartbleed не давала возможности получить доступ к личным данным, логинам или паролям пользователей

    Это вы так думаете что не давала. А кто знает что там на самом деле. Сертификаты то вы перевыпустили! Короче mail.ru в своем стиле-как всегда «заботится» о пользователях.

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

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