Краткий обзор MashSSL
Не так давно компания Comodo объявила о поддержке новой технологии от SafeMashups при использовании SSL-сертификатов Comodo, мы публикуем перевод статьи с кратким обзором MashSSL.
MashSSL устраняет недостатки при использовании SSL для решения проблемы через:
- Введение криптографических инноваций (описаны ниже), чтобы сделать SSL многосторонним протоколом без каких-либо изменений в системе безопасности основного SSL протокола;
- Запуск MashSSL поверх HTTP в стеке протокола, т.е. сообщения MashSSL отправляются с помощью HTTP.
- Сама спецификация определена в терминах REST.
Вы можете прочесть Стандарт для получения дополнительной информации о том, как определяется протокол и Software Central. Более подробное описание можно найти здесь: White Paper, а мы затронем лишь основные понятия криптографии.
Криптография MashSSL
Начнём с того, что кто-то может высказать очень серьёзные замечания о SSL-протоколе (смотри ниже) при использовании взаимной аутентификации. А в частности, он считается безопасным даже в присутствии нескольких промежуточных объектов (Man-In-The-Middles - MITMs), которые могут манипулировать сообщениями. Под словом «безопасным» мы имеем в виду, что они не могут выдавать себя друг за друга, а также они не могут узнать секретный ключ, использующийся для шифрования сообщений.
Приняв этот тезис, давайте теперь зададим, казалось бы невозможный вопрос. В какой ситуации объекты "MITMs" могут:
- Иметь возможность манипулировать сообщениями;
- Выполнять успешно протокол;
- В какой степени защита, предоставляемая SSL, не будет скомпрометирована?
Существует только одна ситуация, когда это возможно: Если изменения вносятся объектами MITMs в то время, как серверы отсоединяются друг от друга!
В качестве примера рассмотрим сценарий с тремя Объектами: Объект (LEFT), Объект (CENTER) и Объект (RIGHT).
Представьте, если Web-приложение 1 отправляет первоначальное SSL-сообщение, LEFT манипулирует случайным числом R1, зашифровывая его паролем, совместным с CENTER. CENTER расшифровывает и переводит его в первоначальный R1, а RIGHT передаёт его Web-приложению 2 без изменений. И таким же образом на обратном пути, RIGHT зашифровывает случайное число R2 с помощью совместного с CENTER пароля. Затем CENTER расшифровывает его и отправляет LEFT, который просто передает его Web-приложению1. В этом сценарии SSL протокол будет работать правильно. Манипуляция действительно произошла, но ничто не выдало себя за чужое Web-приложение, и не узнало чужих секретов. Итак, как же мы используем эту конструкцию?
MashSSL-протокол по существу вводит три "легитимных объекта" в стандарт протокола SSL. LEFT и RIGHT находятся в Web-приложениях 1 и 2 соответственно, и MIDDLE находится в браузере. Web-приложения генерируют и получают SSL-сообщения, но в соответствующих пунктах протокола, они также манипулируют сообщениями (далее именуется "кодируют") перед отправкой. Когда это происходит, браузер должен "декодировать" сообщение перед его отправкой в другое Web-приложение.
В примере выше случайное число R1 кодируется (например паролем Alice) Web-приложением 1 перед отправкой, и она успешно декодирует его по пути к Web-приложению 2. Аналогичным образом Web-приложение 2 кодирует R2, который Alice декодирует и отправляет в Web-приложение 1.
Мы выбрали этот метод объяснения MashSSL, потому что он убедительно дает понять, что система безопасности MashSSL, с точки зрения взаимной аутентификации двух Web-приложений, и конфиденциальности их секрета, является такой же как и у SSL.
Можно сразу заметить основное преимущество. Если после установки доверительного соединения через Alice, с этими двумя Web-приложениями работает другой пользователь Fran, то они просто используют сокращенный обмен данными, который не связан операциями обмена публичными ключами и следовательно чрезвычайно эффективен.
Итак, как же точно должно происходить кодирование? Протокол MashSSL явно не определяет никакого конкретного способа кодирования. Мы заметили, что при поиске в Google информации "recipes for scrambled eggs" мы обнаружили сотни статей. Точно также существует бесчисленное множество способов, с помощью которых можно осуществить кодирование и декодирование. Например, можно использовать существующие методы аутентификации, такие как: пароли, одноразовые пароли, смарт-карты, устройства идентификации и т.д. Более детально этот вопрос обсуждается здесь: White Paper, а также говорится о том, что необходимо думать о безопасности при выборе метода кодирования. И наконец, мы видим, что, если пользователь уже вошёл в систему, и Web-приложение получает куки сессии подтверждающие это, то оно может выполнить "виртуальное кодирование", или другими словами оно вообще не выполняет никакого кодирования.
По материалам www.safemashups.com
Перевод КОМТЕТ komtet.ru