company_banner

Почему после обнаружения 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!».

    Mail.Ru Group

    778,84

    Строим Интернет

    Поделиться публикацией
    Комментарии 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
            Хах! Еще даже не все российские банки залатали дыру, о чем тут дальше говорить.
          • НЛО прилетело и опубликовало эту надпись здесь
              +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 в своем стиле-как всегда «заботится» о пользователях.

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

                                                            Самое читаемое