Previous Entry Share Next Entry
ssldump vs. https
Linux
sanmai
Представим, что мы в диагностических целях хотим послушать HTTPS-трафик. При этом у нас, как у порядочного системного администратора, есть доступ к ключу и сертификату, используемым на сервере.

С учетом вышесказанного, это очень легко сделать. Рассказываю по шагам на примере тестового сервера:

1. Записываем интересующий нас трафик в файл при помощи tcpdump:
tcpdump -vs 0 -w ssl.cap port 443 and host secure.example.com
В дампе обязательно должно быть начало SSL-сессии. Добиться этого можно, например, перезапуском сервера или клиента.

2. Расшифровываем дамп трафика при помощи ssldump:
ssldump -r ssl.cap -k server.key -d
(Эта программа может расшифровать только зашифрованное шифрами типа Static RSA, из выдачи команды openssl ciphers -v kRSA)

3. Наблюдаем на экране расшифровку трафика:


Мораль отсюда простая: берегите SSL-ключи как зеницу ока. Если они попадут в руки постороннему, то тому не составит труда прослушать ваш шифрованный трафик.

  • 1
Если есть и ключ и доступ к серверу, то нужно-ли будет извращаться с перехватом трафика? Пропросить всё складывать в лог и всё. Разве что ответ тоже почему-то важен

Вам может быть и не нужно, а у посторонних другого пути может не быть.

Ну просто показалось странным, что права перезапустить сервер и делать дамп трафика есть, а поковыряться в конфигурации нет :) Но да, можно и так, конечно.

Что тут странного? Это мой личный компьютер: что хочу, то и делаю. Глупо было бы не пользоваться возможностью перезапустить сервер, когда она есть, ведь правда?

Да нет, конечно можно. Просто мне показалось странным -- как-бы самому закрыть что-нибудь в сейф, и вместо ключа сделать подкоп и выпилить дно :) Ради спортивного интереса.
А если сервер свой то просто скинуть весь запрос в лог прямо через apache и готово.

В реальном случае единственное, про что думается, если хостер внезапно раздобыл копию SSL сертификата, и пакостит перехватом трафика

Рекомендую прочитать RFC 2606, раздел 3, а потом еще раз прочитать пост.

Сертификат передается клиенту при каждом соединении. Ну сохранит его кто-то себе на диск, будь то клиент или хостер, что толку? Еще раз рекомендую ещё раз внимательно перечитать пост.

Неужели я так непонятно пишу? :)

Я чего-то сильно не понимаю.
Если человек имеет аккаунт на системе так что:
- имеется достаточно прав на перезапуск сервера
- достаточно прав на перехват трафика
- он ещё и копию ключа достал

То в такой ситуации вся катавасия с расшифровкой ну просто совсем не нужна.
Или вредителю скучно, и вместо прямого пути -- изменения конфигурации сервера с записью всего запроса в лог, он выбирает какое-то окружное болото с перехватами и расшифровками. Или это принцип такой, что можно просто сделать копию, но не хочется?

Если нет доступа к серверу то да, если взять ключ и потом перехватить весь траффик то можно всё расшифровать. И да, раздавать всем желающим ключ не надо. С этим я абсолютно согласен.
За одно не надо раздавать юзерам права на перехват трафика.

А я кажется понял. Злоумышленник-то вряд-ли получит доступ к закрытому ключу сервера, так что тут всё спокойно.

А вот если мы отлаживаем своё приложение, работающее через https, то можно посмотреть трафик именно так. При этом менять конфигурацию сервера с записью в лог - это примерно то же самое, как если при отладке приложения на C++ использовать printf вместо отладчика.

Что удивляет - я думал, что SSL, по крайней мере, не слабее, чем Диффи-Хеллман, который не взломать простым прослушиванием без MITM. А тут вроде используется пассивное прослушивание. Или же секрет скрыт в фразе "Эта программа может расшифровать только зашифрованное шифрами типа Static RSA", а в реальности используется что-то более устойчивое?

Ну разве что для отладки, и в случаях когда https глючит по неизвестной причине :) (хотя если сам транспорт глючит то и расшифровка наверняка раком встанет) и при этом программиста не допускают до клиента из принципа.

А то для отладки содержимого обмена на клиентской стороне есть намного более удобные средства -- в обычном Fire Bug внутри FireFox закладка Net. Хром умеет сам по себе всё отслеживать. Если IE то тоже есть средства.

В нашем проекте при получении ошибки приложения запросы обычно автоматом в лог пишутся -- для простоты обработки потом :) Признаюсь, я привык работать с application server-ами -- там обычно сам веб-сервер делает очень мало.

Ну я имел в виду случай, когда не https глючит, а само веб-приложение, которое работает поверх https.

Хотя да, средствами браузера это делать действительно удобнее, не подумал.

Веб-приложения в своем браузере действительно проще отлаживать в браузере. Пост не про это.

На основе RSA сертификаты используют GMail, VeriSign, Microsoft и даже ЖЖ :)
Секрета нет. Оговорка здесь к тому, что программа не ломает считанные оставшиеся не-RSA шифры потому что автор по своим причинам не затачивал программу под те другие шифры. Они основаны на тех же принципах и "ломаются" с тем же успехом.

Из того, что в тестовом окружении используется Apache и есть права для его перезапуска, никак не следует что в реальной задаче что-то можно перезапустить и что вообще есть доступ к исходникам сервера или клиента.

Посмотрите таки RFC 2606, раздел 3, а так же перевод слова "example" в словаре.

Э.. а чем ты там профессинально занимаешься??? Я думал, что ты фотографируешь)

Фотографирую я для души в свободное от работы время)

Edited at 2011-01-24 02:23 pm (UTC)

Боже, и ты программист)

Спасибо за деверие) Надеюсь, что шедевры кода не менее красивы, чем фото ;)

  • 1
?

Log in

No account? Create an account