Удалёнка: опыт и лайфхаки
Реклама
Комментарии 19
+8
Ализар, добавление в схему ECDHE НЕ означает, что сервер для каждой сессии генерирует новый открытый ключ и подписывает его своим закрытым ключом. Это означает, что клиент и сервер совместно устанавливают ключ для симметричного шифрования.
Собственно, алгоритм Диффи-Хелмана для этого и придуман. Он позволяет установить совместный секрет, обмениваясь данными по открым каналам.
Закрытый ключ сервера теперь нужен только для аутентификации сервера перед клиентом.
+2
Насколько я понял, тут реализован вариант Диффи-Хелмана именно с эфемерными «одноразовыми» ключами, вот здесь один разработчиков подробнее разъясняет.
0
Ну по хорошему, в Диффи-Хелмане ключевые пары генерируются каждый раз новые. Это прямо в алгоритме прописанно.
Не вижу причины, зачем упоминать это отдельно. Но пусть будет :)
Главное, что SSL наконец-то может использовать Диффи-Хелмана для установления общего секрета.

0
> Главное, что SSL наконец-то может использовать Диффи-Хелмана для установления общего секрета

А раньше-то что ему мешало?.. Пусть без эллиптических кривых, но вроде в SSLv3 и в OpenSSL сто лет как есть DHE-* алгоритмы.
0
Всё верно. Кстати в реализации ECDHE вроде наша российская компания CryptoPro участвовала, во всяком случае они реализовали ГОСТ'овские алгоритмы, которые тоже используют эллиптические кривые.
0
А разве в SSL/TLS где-нибудь используется алгоритм Диффи-Хеллмана со статическими ключами?..
+5
«К сожалению, браузер IE пока не поддерживает сочетание ECDHE и RC4.»
Можно было и не писать.

P.S> Этим комментом я хочу засечь когда IE начнёт это поддерживать.
0
Гм… Есть то они есть, но почему-то недоступны для использования в SSL/TLS. Microsoft такой Microsoft.
0
DHE это конечно хорошо, его использование действительно не позволяет третьей стороне расшифровать перехваченный траффик без знания секретного ключа сервера. Но ведь оно уже довольно давно реализовано в OpenSSL и поддерживается абсолютным большинством современных веб-серверов и браузеров.

Кстати, не знаю чего они там у себя обновили, но на gmail.com до сих пор RSA-RC4-SHA, без обмена ключами по Диффи-Хеллману. Перехваченную сессию с него можно даже Wireshark'ом расшифровать при наличии секретного ключа сервера. А вот на mail.yandex.ru включается DHE_RSA, и тут уже не всё так просто.
-1
Упс, конечно же я хотел сказать:

DHE это конечно хорошо, его использование действительно не позволяет третьей стороне расшифровать перехваченный траффик без знания даже при наличии секретного ключа сервера.
+5
Приятное нововведение — ничего не скажешь.

А вот у меня по поводу Google и безопасности еще такое наблюдение: (paranoia ON) где-то с полгода назад заметил что при входе на Gmail с украинского IP в строке браузера стал кратковременно «проскакивать» адрес вида 'http://google.com.ua/accounts/SetSID?' — именно без httpS. А где-то с месяц назад этот адрес сменился на такой: 'https://accounts.youtube.com/accounts/SetSID?' Учитывая что в Gmail-е https был включён со времён закрытой беты — закрадывается мысль что с пол-года назад у Google случилась некая договорённость с кем-то из укр. спец. служб, а с месяц назад договорённость «прокисла»(paranoia OFF)
+1
Адрес не сменился, а добавился. Сначала идёт авторизация на yotube, а затем на google. RequestPolicy в FF подсказал.
+1
Тоже заметил про youtube (кстати, местоположения — Россия). Зачем это сделано?
0
Для того, чтобы ваш g-аккаунт был связан с y-аккантом. Эта мысль возникла после покупки гулгом ютьюба. Я пытался удалить аккаунт на ютьюбе, ибо не нужен он мне был. Не вышло: входя на почту, все равно получаю редирект на авторизацию ютьюба, ибо там остался аккаунт @gmail.com. Этот акк уже не удалить.
0
Однако по-прежнему остается непонятным почему запрос на google.com.ua шел без https.
+2
О, безумное достижение! А когда у них будет использоваться TLS версии старше 1.0, в которой есть известные уязвимости?
Только полноправные пользователи могут оставлять комментарии.  , пожалуйста.