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

Поскольку SSL не был разработан для такого сценария использования, гуглеинженерам пришлось разработать расширение популярной библиотеки OpenSSL, которое будет интегрировано в будущую версию 1.0.1. Пока сочетание выбранной схемы передачи ключей ECDHE RSA и алгоритма шифрования RC4 128 поддерживается лишь FireFox и Chrome.

Источник: InfoWorld

теги: google  |  предложить новость  |  обсудить  |  все отзывы (6)

[6821]

назад «  » вперед

аналогичные материалы Google заблокировала 2 с лишним миллиона приложений в прошлом году // 30.04.24 13:10 Google Drive находит файлы // 07.12.23 01:46 Google Drive теряет файлы // 27.11.23 20:02 Google начинает платить за найденные уязвимости // 31.08.22 20:16 Google окончательно прикрывает бесплатный G Suite // 28.01.22 16:48 Apple, Google, Microsoft и Mozilla забанили казахстанский сертификат // 19.12.20 03:13 Google закрывает безлимитные Photos // 11.11.20 22:12

последние новостиBugTraq.Ru: последние новости Ядро Linux избавляется от российских мейнтейнеров // 23.10.24 23:10 20 лет Ubuntu // 20.10.24 19:11 Tailscale окончательно забанила российские адреса // 02.10.24 18:54 Прекращение работы антивируса Касперского в США // 30.09.24 17:30 Microsoft Authenticator теряет пользовательские аккаунты // 05.08.24 22:21 Облачнолазурное // 31.07.24 17:34 TeamViewer обвинил в своем взломе русских хакеров // 29.06.24 15:31

Комментарии: Или я дурак, единственный, не врубился в текст статьи, про... 04.12.11 18:26   Автор: WendyH Статус: Незарегистрированный пользователь <"чистая" ссылка> Или я дурак, единственный, не врубился в текст статьи, про "постоянную память" и "схему постоянной смены секретного ключа".. Пришлось лезть по ссылкам источника и выяснять. В общем, как всегда, испорченный телефон. Для крипто-интересующихся: Гугловцы в расширении применили алгоритм Диффи-Хеллмана для генерации временных сессионных ключей, для обеспечения forward secrecy. сессионные ключи временные по определению 04.12.11 19:17   Автор: dl <Dmitry Leonov> <"чистая" ссылка> forward secrecy предполагает постоянное обновление и асимметричных ключей, которыми шифруются симметричные сессионные. я тоже не догоняю... [upd2] 04.12.11 19:34   Автор: Den <Денис Т.> Статус: The Elderman Отредактировано 04.12.11 19:48  Количество правок: 4 <"чистая" ссылка> поправьте меня, если я ошибаюсь. сертефикат сервера, который получает клиент при подключении, содержит открытый ключ шифрования, ассиметричную пару которого (закрытый ключ), серв использует при расшифровке данных от клиента. клиент при подключении генерит свой (сессионный) "открытый" и "закрытый" ассиметричные ключи. свой "открытый" ключ клиент шифрует открытым ключем серва и отсылает серву. серв расшифровывает "открытый" ключ, которым он будет шифровать данные, отправляемые клиенту. всё, что нужно в такой схеме - достаточно часто менять сертификат серва (чаще, чем 1 раз в год). [upd] даже если клиент генерит симметричные сессионные ключи - не имеет значения, т.к. самым уязвимым местом в данной схеме является пара ассиметричных ключей сервера, использующуюся в схеме обмена сессионными ключами и на которую и будет осуществляться атака. я правильно понимаю? [upd2] на сколько я смог понять, гугль собирается заиметь свой собственный CA, сертификатом которого будет подписывать динамически сгенерированный сертификат сервера, который, в свою очередь, будет генерироваться с некоторой заданной частотой. это текущая ситуация 04.12.11 20:27   Автор: dl <Dmitry Leonov> Отредактировано 04.12.11 20:30  Количество правок: 1 <"чистая" ссылка> > даже если клиент генерит симметричные сессионные ключи - не > имеет значения, т.к. самым уязвимым местом в данной схеме > является пара ассиметричных ключей сервера, использующуюся > в схеме обмена сессионными ключами и на которую и будет > осуществляться атака. > я правильно понимаю? Это текущая ситуация. Один комплект асимметричных ключей, меняющийся вместе с сертификатом раз в иногда. Только сессионный ключ не асимметричный, а какой-нибудь DES. > [upd2] > на сколько я смог понять, гугль собирается заиметь свой > собственный CA, сертификатом которого будет подписывать > динамически сгенерированный сертификат сервера, который, в > свою очередь, будет генерироваться с некоторой заданной > частотой. Да, только я бы не называл это CA - CA выдают всем, этот только себе. ну да, я маленько запутался в терминологии ) CA - всего лишь... 04.12.11 20:48   Автор: Den <Денис Т.> Статус: The Elderman <"чистая" ссылка> > Да, только я бы не называл это CA - CA выдают всем, этот > только себе. ну да, я маленько запутался в терминологии ) CA - всего лишь сертификат. Хотел иметь ввиду (сорь за каламбур), что Гугль собирается забацать собственный доверенный корневой центр сертификации, подписывающий динамически сгенерированные сертификаты сервов. весьма трезвое и правильное решение 24.11.11 01:50   Автор: Den <Денис Т.> Статус: The Elderman <"чистая" ссылка>

<добавить комментарий>