Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
| | |
я тоже не догоняю... [upd2] 04.12.11 19:34 Число просмотров: 1738
Автор: Den <Денис Т.> Статус: The Elderman
Отредактировано 04.12.11 19:48 Количество правок: 4
|
поправьте меня, если я ошибаюсь.
сертефикат сервера, который получает клиент при подключении, содержит открытый ключ шифрования, ассиметричную пару которого (закрытый ключ), серв использует при расшифровке данных от клиента. клиент при подключении генерит свой (сессионный) "открытый" и "закрытый" ассиметричные ключи. свой "открытый" ключ клиент шифрует открытым ключем серва и отсылает серву. серв расшифровывает "открытый" ключ, которым он будет шифровать данные, отправляемые клиенту.
всё, что нужно в такой схеме - достаточно часто менять сертификат серва (чаще, чем 1 раз в год).
[upd]
даже если клиент генерит симметричные сессионные ключи - не имеет значения, т.к. самым уязвимым местом в данной схеме является пара ассиметричных ключей сервера, использующуюся в схеме обмена сессионными ключами и на которую и будет осуществляться атака.
я правильно понимаю?
[upd2]
на сколько я смог понять, гугль собирается заиметь свой собственный CA, сертификатом которого будет подписывать динамически сгенерированный сертификат сервера, который, в свою очередь, будет генерироваться с некоторой заданной частотой.
|
|
<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 <Денис Т.> Статус: 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
|
|
|
|
|
подробно о проекте
Анализ криптографических сетевых...
