информационная безопасность
без паники и всерьез
 подробно о проекте
Rambler's Top100Spanning Tree Protocol: недокументированное применениеВсе любят медЗа кого нас держат?
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
 Умер Никлаус Вирт 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / RSN / архив / 2011 / ноябрь
2011
главная
январь
февраль
март
апрель
май
июнь
июль
август
сентябрь
октябрь
ноябрь
декабрь





Гугль решил защититься от будущих атак на свой https-трафик
dl // 24.11.11 01:19
Большинство текущих реализаций HTTPS предполагает существование единственного неизменного секретного ключа, известного только владельцам домена, который уже используется для шифрования сессионных ключей.
[Не забывайте при копировании материала указывать полный адрес источника: //bugtraq.ru/rsn/archive/2011/11/05.html]
Однако история показывает, что многие решения, обеспечивающие приемлемую безопасность при своем внедрении, через некоторое время обходились за счет роста производительности вычислительной техники.

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

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

Источник: InfoWorld    
теги: google  |  предложить новость  |  обсудить  |  все отзывы (6) [6729]
назад «  » вперед

аналогичные материалы
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
Google постепенно отключит доступ к G Suite сторонним приложениям, использующим простой пароль // 17.12.19 17:18
 
последние новости
Три миллиона электронных замков готовы открыть свои двери // 22.03.24 20:22
Doom на газонокосилках // 28.02.24 17:19
Умер Никлаус Вирт // 04.01.24 14:05
С наступающим // 31.12.23 23:59
Четверть приложений, использующих Log4j, до сих пор уязвима // 11.12.23 18:29
Google Drive находит файлы // 07.12.23 01:46
Google Drive теряет файлы // 27.11.23 20:02

Комментарии:

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


анонимность клоуны конференции спам уязвимости .net acrobat activex adobe android apple beta bgp bitcoin blaster borland botnet chrome cisco crypto ctf ddos dmca dnet dns dos dropbox eclipse ecurrency eeye elcomsoft excel facebook firefox flash freebsd fsf github gnome google gpl hp https ibm icq ie intel ios iphone java javascript l0pht leak linux livejournal mac mcafee meltdown microsoft mozilla mysql netware nginx novell ny open source opera oracle os/2 outlook password patch php powerpoint programming pwn2own quicktime rc5 redhat retro rip router rsa safari sco secunia server service pack shopping skype smb solaris sony spyware sql injection ssl stuff sun symantec torrents unix virus vista vmware vpn wikipedia windows word xp xss yahoo yandex youtube



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



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