На главную страницу  
+7 (499) 124-62-26
О компании Продукты Демо-версии Купить Цены Контакты Решения

FAQ МагПро КриптоПакет

  1. Вопрос. Почему МагПро КриптоПакет базируется на OpenSSL 0.9.8e, когда уже существует 0.9.8g. Не приводит ли это к проблемам с безопасностью?

    Ответ. В OpenSSL 0.9.8f было включено большое количество новой функциональности из разрабатываемой ветки 1.0.0. Выпуск security update 0.9.8g связан преимущественно с этой функциональностью. Мы предпочли не включать эту функциональность в МагПро КриптоПакет. Но все обновления безопасности, появившиеся с момента выпуска 0.9.8e, в частности CVE-2007-5135, интегрированы в КриптоПакет.


  2. Вопрос. Подвержены ли Debian-пакеты МагПро КриптоПакет уязвимости CVE-2008-0166?

    Ответ. Ни одна из когда-либо выпускавшихся версий МагПро КриптоПакет для Debian не подвержена этой уязвимости. Коммерческие версии МагПро КриптоПакет, использующие сертифицированные ДСЧ и отдельную программу генерации долговременных ключей вообще не затрагиваются этой уязвимостью. Ознакомительные версии МагПро КриптоПакет используют ДСЧ, встроенный в OpenSSL. Но они выпускаются на основе единой codebase для всех операционных систем, и далеко не все патчи, применяемые в конкретных дистрибутивах используются в библиотеках OpenSSL, входящих в МагПро КриптоПакет. В частности, патч, вызвавший данную уязвимость нами никогда не применялся.


  3. Вопрос. Как создать сертификат сервера? С помощью команды openssl req?

    Ответ. С помощью openssl req создается заявка на сертификат. Эту заявку необходимо отправить в удостоверяющий центр. Там заявка подписывается на ключах удостоверяющего центра. Полученный сертификат пересылается обратно заявителю.


  4. Вопрос. Сертификат передается по открытому каналу связи?

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

    Целостность всех остальных сертификатов, выданных данным удостоверяющим центром, проверяется с помощью проверки электронной подписи удостоверяющего центра под этими сертификатами на корневом сертификате удостоверяющего центра. Эта функциональность встроена в библиотеку OpenSSL.

    В качестве удостоверяющего центра в простейшем случае можно использовать команду openssl ca. Но это решение не сертифицировано как удостоверяющий центр.


  5. Вопрос. Где можно посмотреть исходники простейшего клиент-серверного приложения, использующего OpenSSL API для ГОСТов?

    Ответ. Например, исходники любого OpenSource-приложения, использующего OpenSSL (с учетом патчей, как правило, сводящихся к вызову OPENSSL_config(NULL)).

    Исходники команд s_server и s_client, идущих в составе OpenSSL (эти команды и так читают файл конфигурации openssl).

    Исходники тестов на SSL API, идущие в составе OpenSSL. См. также руководства программиста по продукту МагПро КриптоПакет.

  6. Вопрос. Какие дополнительные меры необходимы для использования алгоритмов ГОСТ?

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

    • До вызова SSL_library_init был загружен модуль engine, реализующий алгоритмы ГОСТ. Если загрузка engine описана в конфигурационном файле OpenSSL (openssl.cnf), то достаточно загрузить этот файл вызовом OPENSSL_config(NULL) (с NULL оно загрузит конфигурационный файл по умолчанию).
    • В списке шифрсьютов, устанавливаемым вызовом SSL_CTX_set_cipher_list или SSL_set_cipher_list, должен присутствовать шифрсьют GOST2001-GOST89-GOST89.
    • Сертификат сервера и соотвествующий секретный ключ должны использовать алгоритм ГОСТ Р 34.10-2001.

    Подробности описаны в файле README.gost, входящем в состав снапшота openssl-1.0.0.


  7. Вопрос. При запуске приложения, работающего с МагПро КриптоПакет, происходит ошибка. Система сообщает:

    error:14092073:SSL routines:SSL3_GET_SERVER_HELLO:bad packet length

    Ответ. В конфигурационном файле приложения запрещено использование протокола TLSv1. Алгоритмы ГОСТ работают только с протоколом TLSv1, поэтому для нормальной работы приложения следует в конфигурационном файле разрешить использование TLSv1.


  8. Вопрос. Поступила информация, что в протоколе TLS обнаружена уязвимость. Что это за уязвимость и как можно ее избежать?

    Ответ. 4 ноября 2009 г. опубликована информация об уязвимости в протоколе TLS.

    Этой уязвимости подвержен в первую очередь протокол HTTPS, в частности web-сервер Apache, поддерживаемый СКЗИ «МагПро КриптоПакет».

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

    Уязвимость возникает в тех случаях, когда сервер позволяет клиенту выполнить следующую последовательность действий:

    1. При обращении на сервер (на какую-то из страниц, находящихся на этом сервере) установить анонимное TLS-соединение;

    2. затем, если при запросе другой страницы, находящейся на этом же сервере, требуется авторизация по сертификату, с помощью механизма renegotiation в TLS проапгрейдить установленное соединение до авторизованного по сертификату.

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

    Таким образом, сервера, на которых при установлении TLS-соединения:

    • или вообще не производится аутентификация клиента;

    • или аутентификация производится по логину-паролю, а не по сертификату;

    • или аутентификация клиента по сертификату выполняется при любом TLS-соединении, т.е. без аутентификации клиента по сертификату TLS-соединение с данным сервером установить вообще невозможно,

    полностью защищены от эффектов обнаруженной уязвимости.

    Уязвимости подвержены только те сервера, на которые можно попасть автономно, а затем, уже установив автономное TLS-соединение с данным сервером, провести аутентификацию по сертификату. Т.е. сервера, на которых запрос на сертификат требуется не для любого TLS-соединения, а только для доступа к определенным страницам внутри сервера.

    (Т.е в файле конфигурации Apache директива SSLVerifyClient require указана внутри блока Directory или Files.)

    В настоящее время полного решения этой проблемы не найдено. Патч, предложенный в OpenSSL 0.9.8l, просто запрещает работу механизма renegotiation, что приводит к потере работоспособности для широкого спектра решений с использованием TLS.

    Мы рекомендуем: чтобы обезопасить такие сервера, на которых запрос на сертификат требуется не для любого TLS-соединения, а только для доступа к определенным страницам внутри сервера, страницы, для доступа к которым требуется сертификат, должны быть вынесены на отдельный виртуальный сервер (т.е. на отдельный IP адрес или отдельный порт).

 
Copyright © ООО "Криптоком". 2001-2016. All Rights Reserved.