id: Гость   вход   регистрация
текущее время 21:14 28/03/2024
Автор темы: Ghola, тема открыта 12/10/2003 22:50 Печать
https://www.pgpru.com/Форум/Криптография/ЕстьЛиВзаимоблокировкаВTLSSSL
создать
просмотр
ссылки

Есть ли взаимоблокировка в TLS/SSL?


Есть ли взаимоблокировка в TLS/SSL?
Прочитал в FAQ'е про протокол взаимоблокировки при обмене открытыми ключами. Спасибо, очень познавательно! Вопрос такой – предусмотрено ли нечто подобное при установке связи по защищённым протоколам – в частности при работе с почтой? В случае предполагаемого мной положительного ответа, значит ли это, что при работе по этим протоколам мы полностью (исключая ошибки реализаций) застрахованы от атаки man-in-the-middle? Хотелось бы по возможности цитат и ссылок...


 
Комментарии
— SATtva (13/10/2003 03:14)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Вопрос хороший. В принципе, если Вас всерьёз интересуют подробности, лучшим ресурсом по всем потрохам и деталям работы TLS (он же SSL v.3) являются его IETF-спецификации:
http://www.ietf.org/rfc/rfc2246.txt?number=2246

Вкратце процедура протокола заключается в следующем (при анонимном подключении):

1. Ваш браузер (клиент) обращается к серверу. На этом этапе происходит отправка некоторых уникальных данных, упакованных в т.н. client hello message, дабы в дальнейшем избежать потенциальной атаки с повторной передачей.
2. После ответного приветствия сервер отправляет клиенту свой сертификат X.509 и относящийся к нему открытый ключ.
3. Клиент генерирует симметричный сеансовый ключ, зашифровывает его открытым ключом сервера и отправляет.
4. Сервер расшифровывает своим закрытым ключом сеансовый ключ и устанавливает с клиентом защищённое соединение: вся передаваемая информация шифруется сеансовым ключом.

При обращении, как Вы отметили, к почтовому ящику по защищённому TLS/SSL каналу связи обычно подразумевается работа с узлом, имеющим сертификат X.509, подписанный доверенным удостоверяющим центром. В свою очередь, корневые сертификаты большинства удостоверяющих центров "вшиты" в дистрибутивы таких браузеров, как IE или NN. По получении сертификата на этапе 3, Ваш браузер проверяет подпись на нём (иными словами, кем он выдан), и если устанавливает, что сертификат сервера подписан аксиоматически достоверным корневым ключом ЦС, это свидетельствует, что ответ поступил именно от того сервера, с которым происходило установление связи на этапе 1.

Таким образом, чтобы провести атаку "человек в середине", взломщику потребуется создать липовый сертификат с доменным именем и ip сервера и подписать его подделаной подписью ЦС. Если корневой сертификат ЦС имеет достаточно крупный ключ, это маловероятно.

У взломщика могла бы быть возможность провести атаку с повторной передачей, но в TLS применяются особые процедуры по её предотвращению (presecret и master secret messages, отметки времени и пр.).

Подытоживая, можно сказать, что SSL и TLS не используют протокол взаимоблокировки. Но предусматривают альтернативные механизмы защиты от таких атак.

Вообще же для пущей надёжности советую шифровать отправляемые письма на уровне приложения (с помощью PGP, например ;-) ), поскольку использование исключительно защиты на транспортном уровне (SSL/TLS) может поставить информацию под угрозу раскрытия при передаче сообщения между серверами или от почтового сервера получателя на его компьютер, если его сервер не поддерживает защищённую передачу данных.

Если же используете защиту транспортного уровня для обращения к различным сетевым ресурсам (например, к web-узлу он-лайн банкинга), не используйте анонимного подключения, но и сами предоставляйте серверу свой сертификат X.509.
— Ghola (13/10/2003 23:09)   профиль/связь   <#>
комментариев: 63   документов: 5   редакций: 0
Спасибо за ответ!
Поторопился я с вопросом под впечатлением от FAQ'а. Ведь сколько раз "слышал о" и использовал корневые сертификаты при проверке обычных, загружал CRL'ы...
Кстати, есть ли бесплатные российские почтовые сервисы, использующие сертификаты, подписанные известными криптографическими авторитетами – например Thawte или VeriSign?
— SATtva (14/10/2003 00:20)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Мне о таких неизвестно. В то же время, есть бесплатная почтовая служба https://www.hotbox.ru, владелец которой — РБК — является партнёром Thawte на территории РФ. Сервис хороший: большой ящик, поддержка ssl и на входящей, и на исходящей почте, imap. Но ЦС там собственный (впрочем, не вижу в этом никаких проблем).

А вообще, imho, не могу назвать ни Thawte, ни VeriSign "криптографическими авторитетами" (авторитеты — это, скажем, RSADSI и Counterpane). Это лишь компании, предлагающие широкий спектр решений в области сертификации, оттого и имеющие такую известность. Та же VeriSign ещё и монопольный регистратор в доменных зонах .com и .net... Но это всё, в общем-то, лирика и к сути дела не относится.
— Ghola (14/10/2003 06:57)   профиль/связь   <#>
комментариев: 63   документов: 5   редакций: 0
...бесплатная почтовая служба *https://www.hotbox.ru, владелец которой — РБК — является партнёром Thawte на территории РФ. Сервис хороший: большой ящик, поддержка ssl и на входящей, и на исходящей почте, imap. Но ЦС там собственный (впрочем, не вижу в этом никаких проблем).


По-моему это одна из проблем! Удивительно это! Партнёр Thawte и как Вы говорите не имеет подписанного сертификата. Причём все вопросы на эту тему в своём форуме они игнорируют!

Да, о Хотбоксе недаром есть и нехорошие мнения... Вроде и почту перлюстрируют, меняют формат сообщений, раскрывают упакованные вложения и включают их в тело письма. Портят ZIP-архивы. Но ведь всё это и может быть результатами пресловутой атаки...

Главный же и неустранимый недостаток российских сервисов – в том, что они российские. Так что необходимость PGP никто не подвергает сомнению. Шифрование "транспортного уровня" подразумевает сокрытие от провайдера заголовков почты, в частности твоего и твоего корреспондента почтовых и IP-адресов... И вот как раз провайдер или операторы "выносного пульта" вероятно и имеют все предпосылки для атаки с подменой сертификата...

И как раз отсутствие подписанного сертификата – подразумевает очень простую атаку с его подменой. Любой может изготовить псевдо-сертификат hotbox с его текстовыми реквизитами и IP-адресом...

Я лично постоянно сталкиваюсь с тем, что сертификат, по которому устанавливается связь почтовым клиентом – отличается от того, который закачан на сайте hotbox.

Вот так!
___
Кстати, снова о правильно подписанных сертификатах российских сервисов. Например авторизация пользователя в Web-интерфейсе https://mail.yandex.ru – происходит с использованием нормального сертификата, подписанного Thawte. Но в том-то всё и дело, что так происходит исключительно передача пароля. Дальше вас снова выбрасывает в обычное HTTP-соединение. Итак – подписанный сертификат не проблема, даже для российских сервисов.

Выводы, по-моему, напрашиваются совершенно однозначные...
— SATtva (14/10/2003 12:14)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Шифрование "транспортного уровня" подразумевает сокрытие от провайдера заголовков почты, в частности твоего и твоего корреспондента почтовых и IP-адресов...

Анализ трафика — одна из наиболее сложных проблем практических приложений. Думаю, Вам известно, что серверы почтовых служб и провайдеров корреспондентов передают между собой информацию открытым текстом. Пока не будут защищены все сегменты сети передачи сообщения (причём методами потокового шифрования, дабы ликвидировать утечку некоторых параметров сообщение: время передачи, размер), его пассивный перехват и чтение служебных заголовков остаётся потенциально осуществимым.

В итоге мы приходим к тому, что а) нельзя использовать сервисы бесплатных почтовых служб, б) информация высокой степени важности должна передаваться методом Р2Р. Следовательно, необходимость в инструкции по работе с PGPnet VPN становится более актуальной. ;-) Но это для индивидуальных пользователей. Организациям же я бы настоятельно рекомендовал PGP Universal. К несчастью, соответствующие современным реалиям требования к безопасности (прежде всего информационной) осознаёт и предъявляет ничтожное меньшинство наших доморощенных бизнесов. Опять же лирика...
— Ghola (15/10/2003 00:34)   профиль/связь   <#>
комментариев: 63   документов: 5   редакций: 0
SATtva:
Шифрование "транспортного уровня" подразумевает сокрытие от провайдера заголовков почты, в частности твоего и твоего корреспондента почтовых и IP-адресов...

Анализ трафика — одна из наиболее сложных проблем практических приложений. Думаю, Вам известно, что серверы почтовых служб и провайдеров корреспондентов передают между собой информацию открытым текстом. Пока не будут защищены все сегменты сети передачи сообщения (причём методами потокового шифрования, дабы ликвидировать утечку некоторых параметров сообщение: время передачи, размер), его пассивный перехват и чтение служебных заголовков остаётся потенциально осуществимым.

Нет, честно говоря я так глубоко не копал... В случае применения SSL мой провайдер знает только время и хост к которому я подключаюсь. Я знаю из результатов снифинга, что весь трафик между мной и почтовым хостом шифруется. Разумеется, если адрес моего корреспондента расположен на другом хосте – то трафик от моего почтового сервера до его – может быть в общем случае нешифрован. Но здесь, думаю, вероятность перехвата частной корреспонденции меньше. Приём почты корреспондентом – его забота, здесь я никак повлиять не могу. Впрочем хорошим вариантом может быть использование одного почтового сервиса обоими участниками переписки...

SATtva:
В итоге мы приходим к тому, что а) нельзя использовать сервисы бесплатных почтовых служб, б) информация высокой степени важности должна передаваться методом Р2Р. Следовательно, необходимость в инструкции по работе с PGPnet VPN становится более актуальной. ;-) ... Опять же лирика...

Да. Эт всё так! А уж если использовать бесплатные защищённые сервисы – то безусловно зарубежные.

К тому же по-моему затруднительно бесплатно добыть надёжный дистрибутив с PGPnet... В смысле такой, к которому был бы ключ – а не крак. Да и трудно представить его практическое применение для нужд частных лиц...
— SATtva (15/10/2003 03:17)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Разумеется, если адрес моего корреспондента расположен на другом хосте – то трафик от моего почтового сервера до его – может быть в общем случае нешифрован. Но здесь, думаю, вероятность перехвата частной корреспонденции меньше. Приём почты корреспондентом – его забота, здесь я никак повлиять не могу.

Всё зависит от ценности передаваемой информации. Если это просто частная переписка, шифруемая от посторонних глаз, — можно не беспокоиться. Если что-то более серьёзное — я бы задумался. Есть зависимость и от контекста проходящей пересылки, социального статуса Вас и корреспондента и ещё уйма факторов, влияющих на интерес к Вашей информации со стороны посторонних: от недоброжелателей и хакеров-энтузиастов до государственных спецслужб (причём не только отечественных).
Впрочем хорошим вариантом может быть использование одного почтового сервиса обоими участниками переписки...

В случае защиты трафика только на транспортном уровне возникает угроза перлюстрации корреспонденции работниками сервиса.
Да и трудно представить его практическое применение для нужд частных лиц...

А в чём, простите, сложность?
— SATtva (26/10/2003 19:00)   профиль/связь   <#>
комментариев: 11558   документов: 1036   редакций: 4118
Если потроха TLS Вас всё ещё интересуют, нашёл обстоятельный материал на русском языке (по сути, перевод RFC):
http://book.itep.ru/6/tls.htm
— Ghola (01/11/2003 19:43)   профиль/связь   <#>
комментариев: 63   документов: 5   редакций: 0
Спасиб! Надо взглянуть!
Ваша оценка документа [показать результаты]
-3-2-1 0+1+2+3