Техническое описание TLS

31. August 2015, 10:37 Безопасность, Интернет, Компьютеры и ПО, Околонаучное, Ссылки

Частота появления новых записок на dxdt.ru снизилась, и вот почему: я за это время написал большой текст про TLS, рассказывающий как этот протокол работает в подробностях. Несмотря на то, что изложение начинается с истории разработки TLS – это технический, ориентированный на специалистов, текст, подразумевающий некоторую подготовку у читателя: местами протокол разобран буквально до байта (в качестве примеров я рассматриваю дампы TLS-сессий). Подробных русскоязычных описаний для TLS очень мало, а протокол этот получает всё большее распространение – неправильное понимание принципов работы TLS ведёт к неприятным ошибкам в реализациях сервисов, которые его используют. Поэтому, думаю, такое описание будет полезно.

Описание я планирую дополнять, потому что, несмотря на объём, охвачены ещё не все аспекты, которые хотелось бы рассмотреть. Сейчас в деталях рассмотрены такие ключевые моменты, как установление соединения (Handshake) и логика построения обмена сообщениями – это основа основ TLS. В ближайших планах: раздел, разбирающий современные шифры (в различных режимах работы), пояснения про использование криптографии на эллиптических кривых. Вероятно, будут исходники на С, поясняющие некоторые моменты реализаций. Конечно, нужен структурный путеводитель по RFC, имеющим отношение к TLS (их великое множество). Для того, чтобы получился полноценный тематический сайт я выделил проекту отдельный адрес: https://tls.dxdt.ru/. (Правда, пока там многое нужно оформить.)

Если есть какие-то поправки, уточнения, пожелания по новым темам (про что написать подробнее) – сообщайте, пожалуйста, либо мне почтой, либо в комментарии к этой записке.

Сам текст:

Ключи, шифры, сообщения: как работает TLS

Адрес записки: https://dxdt.ru/2015/08/31/7629/

Похожие записки:



Далее - мнения и дискуссии

(Сообщения ниже добавляются читателями сайта, через форму, расположенную в конце страницы.)

Комментарии читателей блога: 12

  • 1. 31st August 2015, 15:01 // Читатель Гость написал:

    Отличная статья!

  • 2. 4th September 2015, 16:52 // Читатель Z.T. написал:

    “Этот режим не нуждается в MAC, так как целостность данных защищается самим алгоритмом шифрования.” – “не нуждается в отдельном MAC”, GCM и CCM имеют MAC но в TLS он идет как часть шифротекста.

  • 3. 4th September 2015, 17:13 // Читатель Z.T. написал:

    “Повторное проведение Handshake” – не сказано очень важное: повторное проведение Handshake зашифровано, поэтому client certificate не будет виден атакующей стороне.

  • 4. 4th September 2015, 17:16 // Читатель Z.T. написал:

    “Предупреждения” – важно сказать что после CSS сами alert зашифрованы.

  • 5. 4th September 2015, 17:24 // Читатель Z.T. написал:

    “Эти функции работают с записями, имеющими тип Application Data.” – неверно, после первого CSS все шифруется.

  • 6. 4th September 2015, 17:42 // Читатель Z.T. написал:

    “Суперсовременная рекомендация … типичный для современного Интернета вариант … ” – надо сказать что TLS очень запаздывает, SSH например повсеместно использует более современную криптографию. HTTP2 не разрешает TLS с CBC, и Google будет давить на быструй переход на TLS 1.3 и отмену всех старых шифронаборов. Причина отсталости серверы настроенные много лет назад и не имеющие постоянного админа который бы изменил конфигурацию и обновил openssl. В 2015-ом не надо называть GCM суперсовременным, это дозволеный минимум для сегодняшних технологий (HTTP 2). Старые серверы (RHEL 5.x) и Java должны быть защищены от интернета с помощю прокси.

  • 7. 4th September 2015, 18:45 // Читатель Z.T. написал:

    “Заметьте, что задача выработки общего секрета – эквивалентна аутентификации узла, с которым устанавливается соединение.” – не совсем. Да, если диффи хеллман сломан а электронная подпись не сломана тогда рассчитывается сеансовый ключ и утекает вся информация. Если диффи хеллман сломан в режиме on-line, возможна подмена информации. Если наоборот сломана электронная подпись но не диффи хеллман, можно сделать “человек по середине” с тем же исходом. Какая разница? Если сейчас технология устойчива, но через 10 лет не будет устойчивой. Допустим я пользуюсь RSA-1024 и ECDHE P-256. Через 10 лет (даже раньше), RSA-1024 можно будет сломать с помощю AWS ЕС2, но как атаковать сеанс связи десятилетней давности? Никак. А вот расшифровать записаный трафик десять лет спустя, может быть полезно. Поэтому, система установления сеансого ключа должна быть более стойкой чем система аутентификации.

  • 8. 4th September 2015, 18:53 // Читатель Z.T. написал:

    “заведомо нестойких, устаревших шифронаборов, использующих ключи длиной менее 128 бит” – 3DES (112 бит) безопасен, просто во всех отношениях хуже AES.

  • 9. 4th September 2015, 22:05 // Александр Венедюхин:

    Z.T., спасибо за ценные комментарии! Внёс в текст уточнения.

  • 10. 6th September 2015, 22:05 // Читатель jno написал:

    > Google будет давить на быструй переход на TLS 1.3 и отмену всех старых шифронаборов

    эхх…
    и что делать во всяких интранетах, где куча *оборудования* со старыми шифрами, кривыми сертификатами и т.п., которые просто так не поменять?
    вот, днями столкнулся – железка с 2012 не продаётся, а с 2014 (емнимс) и не поддерживается.
    в результате ни одним современным браузером нормально в консоль зайти низзяяяяя…

  • 11. 7th September 2015, 21:52 // Читатель Z.T. написал:

    @jno в Firefox есть много конфигурации в about:config, можно включить SSLv3 и т.д.

  • 12. 14th September 2015, 10:34 // Читатель Jno написал:

    Во1х – это пока можно, во2х – не в каждом интранете есть фф.