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

Проблема защиты канала связи

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

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

В идеальной ситуации все замечательно. Но поскольку сайт находится в сети Интернет, а это - открытый канал связи, то злоумышленник может перехватить передаваемые данные. Перехватить данные он может или просто прослушивая канал связи, или же создав подставной сервер и, тем или иным способом, заставить пользователя думать, что обменивается данными с "правильным сервером". Таким образом, злоумышленник может узнать логин и пароль пользователя, перехватывать данные, которые тот отправляет на сервер, а также получить доступ к защищенному серверу от имени "скомпрометированного пользователя". Довольно серьезно, не так ли?

И как бы хорошо ни был защищен сам сервер, если канал связи не защищен, то данные могут быть украдены. Именно поэтому был изобретен протокол SSL, на основе которого впоследствии был разработан TLS.

Зачем нужен TLS?

TLS (расшифровывается как Transport Layer Security, безопасность транспортного уровня) - это протокол, обеспечивающий защищённую передачу данных в сети Интернет. Он решает сразу обе описанные выше проблемы: гарантировать, что сервер "подлинный", а также защитить канал обмена данными между сервером и клиентом. На сервер устанавливается сертификат, выданный доверенным Удостоверяющим Центром, который и подтверждает тот факт, что сервер "подлинный". С помощью этого же сертификата защищается процесс генерации "сессионного ключа", которым впоследствии и шифруются все данные, которыми обмениваются клиент и сервер.

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

Trusted TLS - российская криптография для протокола TLS

Для реализации протокола TLS с сервером Apache open-source сообществом был разработан модуль mod_ssl, который сейчас успешно работает на множестве веб-серверов. Но этот модуль работает только с зарубежными криптоалгоритмами, которые, понятное дело, в России не считаются безопасными. И здесь на сцене появляется Trusted TLS.

Разработчики компании "Цифровые технологии" доработали модуль mod_ssl таким образом, что он научился работать и с российскими криптоалгоритмами, а в частности - с криптопровайдером КриптоПро CSP для Unix. 

Еще одним преимуществом является то, что для использования Trusted TLS в связке с КриптоПро CSP нет необходимости в процедуре проверки встраивания - эта связка включена прямо в документацию КриптоПро CSP и уже сертифицирована ФСБ вместе с самим КриптоПро CSP для Unix.

Но как же будет работать шифрование, если у клиента нет КриптоПро CSP?

Действительно, если у пользователя не установлен на компьютере КриптоПро CSP, то российское шифрование не заработает. Но хочу вас обрадовать: Trusted TLS может работать в режиме, когда для таких ситуаций используется зарубежная криптография - она-то есть практически на всех компьютерах с ОС Windows.

К тому же, для этого сценария нет необходимости использовать коммерческую лицензию КриптоПро CSP. Если операция не использует закрытый ключ пользователя (а это именно эта ситуация), то использование КриптоПро CSP абсолютно бесплатно.

А какие еще есть варианты использования Trusted TLS?

• Аутентификации пользователей по сертификатам - пользователь вместо логина и пароля (или вместе с ними) предъявляет свой сертификат
• Использование в качестве прокси-сервера - позволяет связывать между собой защищенные российскими криптоалгоритмами системы и незащищенные системы (или защищенные, но зарубежной криптографией).
• Интеграция Trusted TLS с серверами приложений (например Tomcat, IBM Websphere, Oracle WebLogic Server и т.д.)

Следует заметить, что "из коробки" эти варианты не поддерживаются. Чтобы их реализовать, потребуются дополнительные работы на стороне заказчика.

Какие поддерживаются платформы?

1) для Apache 2.2 совместно с КриптоПро CSP 3.6/3.6R2:

• Windows 2000 Service Pack 4, Windows 7, Windows Server 2003, Windows Server 2008, Windows Server 2008 R2 (в тестовых целях возможно развертывание на Windows Vista и Windows XP) 32 bit (64 bit в тестовых целях)
• Linux 32|64 bit (протестировано на Red Hat Enterprise Linux 4|5 32|64 bit, Ubuntu 10.04.3 LTS (lucid) 64 bit)
• Solaris 10 Sparc|Intel 32|64 bit
• FreeBSD 6.3|7.4|8.2 32 bit
• AIX 5.3|6.1 ppc 32|64 bit

2) для Apache 2.2 совместно с КриптоПро CSP 3.6R3:

• Linux 32|64 bit (протестировано на Red Hat Enterprise Linux 4|5 32|64 bit)