информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Где водятся OGRыСетевые кракеры и правда о деле ЛевинаВсе любят мед
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / site updates
Имя Пароль
ФОРУМ
если вы видите этот текст, отключите в настройках форума использование JavaScript
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
весьма трезвое и правильное решение 24.11.11 01:50  Число просмотров: 1752
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
<site updates>
Гугль решил защититься от будущих атак на свой https-трафик 24.11.11 01:19  
Publisher: dl <Dmitry Leonov>
<"чистая" ссылка>
Гугль решил защититься от будущих атак на свой https-трафик
InfoWorld https://www.infoworld.com/d/security/google-protects-its-current-https-traffic-against-future-attacks-179934

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

Полный текст
Или я дурак, единственный, не врубился в текст статьи, про... 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 <Denis> Статус: 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 <Denis> Статус: The Elderman
<"чистая" ссылка>
> Да, только я бы не называл это CA - CA выдают всем, этот
> только себе.

ну да, я маленько запутался в терминологии ) CA - всего лишь сертификат.
Хотел иметь ввиду (сорь за каламбур), что Гугль собирается забацать собственный доверенный корневой центр сертификации, подписывающий динамически сгенерированные сертификаты сервов.
весьма трезвое и правильное решение 24.11.11 01:50  
Автор: Den <Denis> Статус: The Elderman
<"чистая" ссылка>
1




Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach