качество и надёжность с 2008 года

8 (800) 200-25-11

Техническая поддержка support@komtet.ru —

круглосуточно и без выходных дней

load-whois

Онлайн-касса

для интернет-магазина

Подключите ваш интернет-магазин

к онлайн-кассе в соответствии с 54-ФЗ

Главная Техническая библиотека Разное SSL Краткий обзор MashSSL

Краткий обзор MashSSL

В статье "MashSSL Overview" автор объясняет принцип работы системы безопасности MashSSL и об использовании SSL-сертификатов.

Не так давно компания Comodo объявила о поддержке новой технологии от SafeMashups при использовании SSL-сертификатов Comodo, мы публикуем перевод статьи с кратким обзором MashSSL.

MashSSL устраняет недостатки при использовании SSL для решения проблемы через:

  1. Введение криптографических инноваций (описаны ниже), чтобы сделать SSL многосторонним протоколом без каких-либо изменений в системе безопасности основного SSL протокола;
  2. Запуск MashSSL поверх HTTP в стеке протокола, т.е. сообщения MashSSL отправляются с помощью HTTP.
  3. Сама спецификация определена в терминах REST.

fig1

Вы можете прочесть Стандарт для получения дополнительной информации о том, как определяется протокол и Software Central. Более подробное описание можно найти здесь: White Paper, а мы затронем лишь основные понятия криптографии.

Криптография MashSSL

Начнём с того, что кто-то может высказать очень серьёзные замечания о SSL-протоколе (смотри ниже) при использовании взаимной аутентификации. А в частности, он считается безопасным даже в присутствии нескольких промежуточных объектов (Man-In-The-Middles - MITMs), которые могут манипулировать сообщениями. Под словом «безопасным» мы имеем в виду, что они не могут выдавать себя друг за друга, а также они не могут узнать секретный ключ, использующийся  для шифрования сообщений.

fig2

Приняв этот тезис, давайте теперь зададим, казалось бы невозможный вопрос. В какой ситуации объекты "MITMs" могут:

  1. Иметь возможность манипулировать сообщениями;
  2. Выполнять успешно протокол;
  3. В какой степени защита, предоставляемая SSL, не будет скомпрометирована?

Существует только одна ситуация, когда это возможно: Если изменения вносятся объектами MITMs в то время, как серверы отсоединяются друг от друга!

В качестве примера рассмотрим сценарий с тремя Объектами: Объект (LEFT), Объект (CENTER) и Объект (RIGHT).

fig3

Представьте, если 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-приложение.

fig4

В примере выше случайное число R1 кодируется (например паролем Alice) Web-приложением 1 перед отправкой, и она успешно декодирует его по пути к Web-приложению 2. Аналогичным образом Web-приложение 2 кодирует R2, который Alice декодирует и отправляет в Web-приложение 1.

Мы выбрали этот метод объяснения MashSSL, потому что он убедительно дает понять, что система безопасности MashSSL, с точки зрения взаимной аутентификации двух Web-приложений, и конфиденциальности их секрета, является такой же как и у SSL.

Можно сразу заметить основное преимущество. Если после установки доверительного соединения через Alice, с этими двумя Web-приложениями работает другой пользователь Fran, то они просто используют сокращенный обмен данными, который не связан операциями обмена публичными ключами и следовательно чрезвычайно эффективен.

fig5

Итак, как же точно должно происходить кодирование? Протокол MashSSL явно не определяет никакого конкретного способа кодирования. Мы заметили, что при поиске в Google информации "recipes for scrambled eggs" мы обнаружили сотни статей. Точно также существует бесчисленное множество способов, с помощью которых можно осуществить кодирование и декодирование. Например, можно использовать существующие методы аутентификации, такие как: пароли, одноразовые пароли, смарт-карты, устройства идентификации и т.д. Более детально этот вопрос обсуждается здесь: White Paper, а также говорится о том, что необходимо думать о безопасности при выборе метода кодирования. И наконец, мы видим, что, если пользователь уже вошёл в систему, и Web-приложение получает куки сессии подтверждающие это, то оно может выполнить "виртуальное кодирование", или другими словами оно вообще не выполняет никакого кодирования.

По материалам www.safemashups.com

Перевод КОМТЕТ komtet.ru

Другие документы на эту тему

SSL-сертификаты

КОМТЕТ предлагает SSL-сертификаты и осуществляет их установку.

Клиентам — домены в подарок!
Бесплатный тест виртуального хостинга
Перенос сайта — бесплатно
Все акции
На сайте КОМТЕТ используются cookie-файлы, данные о IP-адресе и местоположении посетителей. Если, прочитав это сообщение, вы остаетесь на нашем сайте, это означает, что вы не возражаете против использования этих технологий.