Google улучшает защиту SSL-сессий

    Google первой среди крупных интернет-компаний внедрила на HTTPS-серверах функцию защиты от будущей потери секретного ключа (функция называется perfect forward secrecy или PFS). Для этого разработано open-source дополнение к OpenSSL, в частности, написан быстрый генератор ключей на эллиптических кривых P-224, P-256 и P-521. По ходу работы специалисты Google также исправили несколько багов в OpenSSL.

    PFS означает, что даже в случае получения (взлома) секретного серверного ключа злоумышленник не сможет расшифровать ранее перехваченный и записанный HTTPS-трафик. Пример из реальной жизни: предположим, что какая-то организация на уровне провайдера записывает и хранит весь ваш HTTPS-трафик, а в случае необходимости получает на сервере секретный ключ (или через много лет мощности компьютеров хватит, чтобы его взломать простым брутфорсом), после чего без проблем читает всю накопленную переписку.

    В случае с Google такой вариант не пройдёт. Теперь здесь используются недолговечные («эфемерные») сеансовые ключи, которые обмениваются по схеме ECDHE (аббревиатура ECDHE расшифровывается как «эфемерный алгоритм Диффи-Хеллмана с использованием эллиптических кривых»). После сеанса связи ключи уничтожаются, и даже владелец сервера не сможет расшифровать сессию, которую его сервер зашифровал прошлым ключом.

    Стандартная схема HTTPS предполагает «рукопожатие» с использованием алгоритмов RSA, RC4 и SHA, то есть клиент (браузер) выбирает случайный ключ для сессии, зашифровывает его с помощью открытого ключа сервера, подписывает своим закрытым ключом — и отправляет на сервер. Данную сессию можно расшифровать только с помощью закрытого ключа сервера и открытого ключа пользователя, так что сессия считается безопасной.

    Добавление в схему ECDHE означает, что сервер для каждой сессии генерирует новый открытый ключ и подписывает его своим закрытым ключом. Таким образом, сессия не только является безопасной в данный момент, но и защищена от будущей потери секретного ключа сервера. Для генерации открытых ключей Google использует эллиптические кривые P-256, криптостойкость которых примерно соответствует 3248-битному RSA.

    В настоящее время PFS считается опциональной фичей и редко используется в качестве опции HTTPS, и Google стал первой крупной компанией, которая внедрила его по умолчанию. Система perfect forward secrecy реализована во всех HTTPS-сервисах Google (это Gmail, Google+, Google Docs, SSL Search) и поддерживается браузерами Chrome и Firefox. К сожалению, браузер IE пока не поддерживает сочетание ECDHE и RC4.

    Вы можете убедиться в том, что используется механизм обмена ключами ECDHE, если во время защищённого сеанса связи с Google нажмёте на SSL-значок в адресной строке.

    Поскольку дополнение для OpenSSL выложено open-source, аналогичный апгрейд HTTPS могут реализовать у себя и другие веб-сервисы.

    via Google Online Security Blog, Adam Langley
    Метки:
    Поделиться публикацией
    Реклама помогает поддерживать и развивать наши сервисы

    Подробнее
    Реклама
    Комментарии 19
    • +8
      Ализар, добавление в схему ECDHE НЕ означает, что сервер для каждой сессии генерирует новый открытый ключ и подписывает его своим закрытым ключом. Это означает, что клиент и сервер совместно устанавливают ключ для симметричного шифрования.
      Собственно, алгоритм Диффи-Хелмана для этого и придуман. Он позволяет установить совместный секрет, обмениваясь данными по открым каналам.
      Закрытый ключ сервера теперь нужен только для аутентификации сервера перед клиентом.
      • +2
        Насколько я понял, тут реализован вариант Диффи-Хелмана именно с эфемерными «одноразовыми» ключами, вот здесь один разработчиков подробнее разъясняет.
        • 0
          Ну по хорошему, в Диффи-Хелмане ключевые пары генерируются каждый раз новые. Это прямо в алгоритме прописанно.
          Не вижу причины, зачем упоминать это отдельно. Но пусть будет :)
          Главное, что SSL наконец-то может использовать Диффи-Хелмана для установления общего секрета.

          • 0
            > Главное, что SSL наконец-то может использовать Диффи-Хелмана для установления общего секрета

            А раньше-то что ему мешало?.. Пусть без эллиптических кривых, но вроде в SSLv3 и в OpenSSL сто лет как есть DHE-* алгоритмы.
            • 0
              Всё верно. Кстати в реализации ECDHE вроде наша российская компания CryptoPro участвовала, во всяком случае они реализовали ГОСТ'овские алгоритмы, которые тоже используют эллиптические кривые.
          • 0
            А разве в SSL/TLS где-нибудь используется алгоритм Диффи-Хеллмана со статическими ключами?..
        • +5
          «К сожалению, браузер IE пока не поддерживает сочетание ECDHE и RC4.»
          Можно было и не писать.

          P.S> Этим комментом я хочу засечь когда IE начнёт это поддерживать.
        • 0
          DHE это конечно хорошо, его использование действительно не позволяет третьей стороне расшифровать перехваченный траффик без знания секретного ключа сервера. Но ведь оно уже довольно давно реализовано в OpenSSL и поддерживается абсолютным большинством современных веб-серверов и браузеров.

          Кстати, не знаю чего они там у себя обновили, но на gmail.com до сих пор RSA-RC4-SHA, без обмена ключами по Диффи-Хеллману. Перехваченную сессию с него можно даже Wireshark'ом расшифровать при наличии секретного ключа сервера. А вот на mail.yandex.ru включается DHE_RSA, и тут уже не всё так просто.
          • –1
            Упс, конечно же я хотел сказать:

            DHE это конечно хорошо, его использование действительно не позволяет третьей стороне расшифровать перехваченный траффик без знания даже при наличии секретного ключа сервера.
            • –1
            • +5
              Приятное нововведение — ничего не скажешь.

              А вот у меня по поводу Google и безопасности еще такое наблюдение: (paranoia ON) где-то с полгода назад заметил что при входе на Gmail с украинского IP в строке браузера стал кратковременно «проскакивать» адрес вида 'http://google.com.ua/accounts/SetSID?' — именно без httpS. А где-то с месяц назад этот адрес сменился на такой: 'https://accounts.youtube.com/accounts/SetSID?' Учитывая что в Gmail-е https был включён со времён закрытой беты — закрадывается мысль что с пол-года назад у Google случилась некая договорённость с кем-то из укр. спец. служб, а с месяц назад договорённость «прокисла»(paranoia OFF)
              • +1
                Адрес не сменился, а добавился. Сначала идёт авторизация на yotube, а затем на google. RequestPolicy в FF подсказал.
                • +1
                  Тоже заметил про youtube (кстати, местоположения — Россия). Зачем это сделано?
                  • 0
                    Для того, чтобы ваш g-аккаунт был связан с y-аккантом. Эта мысль возникла после покупки гулгом ютьюба. Я пытался удалить аккаунт на ютьюбе, ибо не нужен он мне был. Не вышло: входя на почту, все равно получаю редирект на авторизацию ютьюба, ибо там остался аккаунт @gmail.com. Этот акк уже не удалить.
                  • 0
                    Однако по-прежнему остается непонятным почему запрос на google.com.ua шел без https.
                • +2
                  О, безумное достижение! А когда у них будет использоваться TLS версии старше 1.0, в которой есть известные уязвимости?
                  • 0
                    А по-моему FF не пользует…
                    В Chrom* видно, да. В FF — неа.

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