Комментарии:
 |
Или я дурак, единственный, не врубился в текст статьи, про... 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
|
|
|
|
