Криптография для чайников

Очень хорошее видео (но на английском языке) о том как работает обмен ключами в том же самом HTTPS.

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

vladon (vladon.ru) № 1
https в принципе можно подслушать в среде active directory, переподписывая пакеты корпоративным CA (т.к. внутри домена ему доверяют все члены домена: доменный ca политиками домена вносится в trusted всех браузеров, не уверен только насчет оперы)
Евгений Степанищев (bolknote.ru) автор № 2
Атака MiM, ага. В AD приватный ключ CA доступен всем?
vladon (vladon.ru) № 3
нет конечно. тут другое: шлюз tmg (ex-isa) может переподписывать пакеты в обе стороны, это стандартная функция причем. приватный ключ CA делается известным только шлюзу.
vladon (vladon.ru) № 7
Комментарий для Евгения Степанищева:

я не ставлю пишу обычно, но почему-то у тебя при потере фокуса в форме ввода спереди добавляется знак больше. можешь проверить сам: андроид + опера мобайл. вот сейчас вручную удалил.
Moriarty № 9
Diffie-Hellman, кстати, к MITM уязвим, так что «почему нельзя подслушать HTTPS-трафик» к видео довольно опосредованное отношение имеет.
Диктор забавный — 46 читает как «forty two».
invalidCCIE (blog.invalid.org.ua) № 12
в ssl/https используется не diffie-hellman а rsa.
оба алгоритма уязвимы к атакам mitm.
для https это решается тем что стороны проверяют друг друга с помощью сертификатов x509.
для dh это решается использованием x509 сертфикатов или psk ключей для генерации nonce.

перехват https на корпоративном шлюзе требует не просто доверия к сертификату. он требует что б совпал subject name. для этого для шлюза выполняющего перехват создают сертификат с subject name=*, и если приложение не забракует такой subject name, то оно примет сертификат при условии доверия к корпоративному ca.
так что есть несколько «если», но технически это не только реализуемо, но и реализуется…
vladon (vladon.ru) № 14
не вижу трудностей в подстановке в subject name конкретного хоста. выпускается и подписывается-то он все равно центром сертификации, которому клиент доверяет.