Динамический SSL

Динамический SSL — это технология защиты канала связи, разработанная Дэниелом МакКанном (Daniel McCann ) и Нимой Шарифимер (Nima Sharifimehr) из NetSecure Technologies Ltd ^[1]. Она была создана чтобы решить проблему безопасности в публичных сетях, прозрачно корректируя ошибки имплементации SSL систем, из-за которых конфиденциальные данные могли быть изменены или украдены. Иногда данную технологию называют Динамическим TLS (SSL - предшественник).

Уязвимости SSL/TLS системПравить

Большинство имплементаций SSL предполагают, что клиентский компьютер является защищенный средой для передачи ключей, их хранения и шифрования. Это неверно в теории и на практике так как вредоносные технологии типа Spyware, KeyJacking, Man in the Browser могут обмануть SSL, получая конфиденциальные данные до момента их зашифровки^[2]^[3]. Более того, надеясь, что хост будет проводить валидацию сертификатов PKI, система остается уязвимой для атак «человек посередине»^[4].

Сложности для публичных сетейПравить

Традиционные решения защиты канала связи используют свои протоколы или проприетарные архитектуры аутентификации, которые не могут взаимодействовать с SSL. Во многих ситуациях, особенно в анонимных или распределенных средах, где взаимодействие с SSL это необходимость, синхронизация клиента и сервера с использованием проприетарных протоколов защиты попросту нереализуема на практике. Эту проблему называют Проблемой безопасности канала связи в общественных сетях.

Простыми словами, проблема защиты канала связи предполагает, что любая анонимная транзакция через браузер будет иметь риск, который не может быть удален без избавления от анонимности. Из-за того, что практически все веб транзакции предполагают анонимность клиента на уровне протокола^[5], любое стороннее решение в итоге сломает систему^[6]. Это фундаментальная уязвимость, которая лежит под всей веб инфраструктурой, оставляя любую транзакцию не в безопасности.

Динамический SSL решает эту фундаментальную проблему, фокусируясь на том, чтобы прозрачно закрыть уязвимости имплементаций, а не придумывать новый протокол. Поэтому, существующая SSL система остается нетронутой, как и изначальный протокол защиты. В итоге, безопасность достигается закрытием уязвимостей имплементации.

Принципы динамического SSLПравить

Главный принцип Динамического SSL в том, что шифрование конфиденциальной информации не может происходить в непроверенной среде, какой является большинство ПК, где безопасность процесса шифрования может быть нарушена. Поэтому, шифрование должно производиться вне ПК. Динамический SSL предполагает, что компьютер клиента — это непроверенная среда и может быть использована только для пересылки информации. Таким образом, Динамический SSL гарантирует безопасность тем, что информация не остается в незащищенных местах.

ИмплементацииПравить

Типичные имплементации содержат два основных компонента:

• Защищенная среда, содержащая защищаемые данные

• Криптографический прокси, который перенаправляет шифрование в защищенную среду

Опционально, может быть третий компонент, который контролирует то, что токенизация может быть реализована на уровне приложений. Все происходит непосредственно на хосте, на сервере ничего не требуется.

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

Динамический SSL работает при помощи системы токенизации для защищаемых данных и безопасного перенаправления криптографических операций в безопасную среду. Например, вместо того, чтобы вводить банковский пароль в браузер, можно напечатать бессмысленный (для человека) токен. Когда форма отправлена, токен кладется в HTTP запрос и запрос отправляется в криптографический провайдер SSL для безопасной передачи на удаленный сервер и шифрования. Вместо того, чтобы производить шифрование на хосте (может быть скомпрометировано), сессия перенаправляется в защищенную среду, где и содержится реальный банковский пароль. Внутри этой среды токен из запроса меняется местами с реальным паролем в момент шифрования. Зашифрованный пакет, содержащий реальный пароль возвращается в SSL систему на хосте для передачи на удаленный сервер.

Со стороны сервера, запрос выглядит обычным. Пакет зашифрован с помощью сессионного ключа SSL, о котором договорились с клиентом, так что он может быть легко расшифрован сервером. Сервер не видит разницы между SSL и динамическим SSL.

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

Сильные и слабые стороныПравить

Защита от атаки «человек посередине»Править

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

Защита от KeyjackingПравить

Ключи сессий и ключи аутентификации контекстуально связаны с операциями, которые они выполняют и не могут быть экспортированы. Ключ для зашифровки не может быть экспортирован и использован для дешифрования. Проще говоря, ключи протегированы чтобы удостовериться, что они не будут использованы не по прямому назначению.

Коммерческие реализацииПравить

Продукт SmartSwipe - первое известное коммерческое применение динамического SSL. Утверждается, что он предоставляет защиту от вредоносных программ и других атак на стороне клиента, поддерживая всех электронных продавцов, которые используют SSL^[7]. Неизвестно, используют ли другие продукты такую технологию.

ПримечанияПравить

↑ Архивированная копия (неопр.). Дата обращения: 2 декабря 2018. Архивировано из оригинала 30 декабря 2011 года.
↑ Philip Guhring, "Concepts against Man in the Browser Attack", 2006 http://www2.futureware.at/svn/sourcerer/CAcert/SecureClient.pdf Архивная копия от 21 декабря 2018 на Wayback Machine
↑ John Marchesini, S.W.Smith, Meiyuan Zhao, “Keyjacking: risks of the current client-side infrastructure,” Proceedings of the 2nd Annual PKI Research Workshop, 2003. pp. 80-95
↑ Serpanos D N, Lipton R J, "Defense Against Man-in-the-Middle Attack in Client-Server Systems with Secure Servers" 2003
↑ IETF | Internet Engineering Task Force (неопр.). Дата обращения: 2 декабря 2018. Архивировано 11 декабря 2018 года.
↑ Note: SSL client authentication does not solve this problem. Since all clients in a web session are anonymous until authenticated, the act of authentication is therefore inherently a risky transaction which is subject to endpoint vulnerabilities.
↑ Архивированная копия (неопр.). Дата обращения: 2 декабря 2018. Архивировано из оригинала 10 марта 2009 года.

СсылкиПравить

[1] Архивированная копия (неопр.). Дата обращения: 2 декабря 2018. Архивировано из оригинала 30 декабря 2011 года.

[2] Philip Guhring, "Concepts against Man in the Browser Attack", 2006 http://www2.futureware.at/svn/sourcerer/CAcert/SecureClient.pdf Архивная копия от 21 декабря 2018 на Wayback Machine

[3] John Marchesini, S.W.Smith, Meiyuan Zhao, “Keyjacking: risks of the current client-side infrastructure,” Proceedings of the 2nd Annual PKI Research Workshop, 2003. pp. 80-95

[4] Serpanos D N, Lipton R J, "Defense Against Man-in-the-Middle Attack in Client-Server Systems with Secure Servers" 2003

[5] IETF | Internet Engineering Task Force (неопр.). Дата обращения: 2 декабря 2018. Архивировано 11 декабря 2018 года.

[6] Note: SSL client authentication does not solve this problem. Since all clients in a web session are anonymous until authenticated, the act of authentication is therefore inherently a risky transaction which is subject to endpoint vulnerabilities.

[7] Архивированная копия (неопр.). Дата обращения: 2 декабря 2018. Архивировано из оригинала 10 марта 2009 года.

[1]

[2]

[3]

[4]

[5]

[6]

[7]