Рекомендации по использованию SSL/TLS

Использование шифрования SSL/TLS постепенно становится не только "нормой" но и требованием, даже для, казалось бы на первый взгляд, не требующих защиты ситуаций. Например, это HTTPS для блогов - казалось бы, чего там скрывать, зачем условному кулинарному блогу SSL-сертификат? Однако таков тренд - и Google, и Яндекс учитывают наличие у сайта "заботы о пользователе", коим они считают наличие доступа к нему по HTTPS, в результате такой блог будет иметь больше шансов стать популярным.
Ну а для IT-сферы говорить о важности TLS-защиты каналов связи и говорить не нужно, само собой разумеется. В частности, Intel AMT, также имеет всё необходимое для работы с помощью SSL/TLS-сертификатов каналами связи.
В связи с "общеприменимостью" темы SSL/TLS далее буду подразумевать общие рекомендации "для всех" (при этом в подавляющем большинстве они будут относиться и к AMT), выделяя отдельно лишь специфичные для Intel AMT моменты.

Вопросы буду освещать без особого деления - от "примитивно-понятных", до "заумных". Честно говоря, я обычно все подобные "записи в блог" делаю "для себя" — чтобы после и самому не забыть (а точней, чтобы проще было вспомнить) и кому другому просто дать ссылку сюда, нежели ещё раз набирать. smile.gif

SSL, TLS или SSL/TLS?

Стандарт TLS есть "развитие" стандарта SSL. Примерно как когда-то был Intel Pentium, а сейчас - Intel Core.
SSL версии 1 "не было" (т.е. публично оный не был представлен). Поэтому везде в документации вы увидите SSL v.2 в качестве "минимальной". Однако из-за проблем с безопасностью в реальности говорить и о её применимости бессмысленно. Потому "действительно минимальной" считается версия SSL v.3, появившейся на свет в 1996-м году.
На базе SSL v.3 был разработан стандарт TLS 1.0 (1999 г.). После появились версии TLS 1.1 (2006 г.) и TLS 1.2 (2008 г.), которая на данный момент (начало 2015-го года) является последней.
Соответственно, если говорить правильно, подразумевая данную тему, то используют вариант "SSL/TLS". Однако и "просто SSL" и "просто TLS" - тоже вполне адекватно использовать в качестве термина - кто как привык. Важным отличием терминов SSL-TLS становится лишь в тех случаях, когда нужно подчеркнуть использование именно последней версии, т.е. TLS.
Дальнейшее описание и рекомендации по SSL/TLS подразумевает именно TLS "по умолчанию".

Самая лучшая версия - TLS 1.2?

Говорить о "лучшести" - весьма сложно. С точки зрения чего лучше? Если безопасности - конечно же, как и всё самое последнее - лучше. Т.е. TLS 1.2.

Однако если учесть ещё и совместимость, то можно вновь использовать аналогию с Intel Pentium/Core - обладатели "Pentium/SSL", не умеющие работать даже по TLS 1.0 получатся "в пролёте" (если вы, как администратор сервера, запретите использование SSL v.3) .


  • Если вам они (обладатели старых систем) не важны или таких клиентов (в т.ч. потенциальных) у вас просто нет - конечно же используйте максимально последнюю версию TLS1.0/TLS1.1/TLS1.2 (тут уже ограничение может быть с вашей стороны - чтобы используемое ваше программное обеспечение корректно работало с данной версией TLS).
  • А если они (обладатели старых систем) важны, вы не хотите их терять, есть возможность обеспечить адекватный уровень безопасности, либо требования к оной не столь критические (например, упомянутый выше "кулинарный блог") - в таком случае для вас (а точней - ваших клиентов) будет "лучшей" как раз версия SSL v.3 (т.к. с ней "всё точно будет работать").

TCP → TLS

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



TLS Layer

Если это соотносить с уровнями модели OSI, то TLS располагается на 5-м (сеансовом) и 6-м (представительском) уровнях. Кто-то его относит лишь к пятому, кто-то считает как шестой, в общем, нечто среднее, например, в версии Микрософт это так:
 


В данном случае лишь важно, что TLS располагается сразу "над" транспортным протоколом, "по умолчанию" - это TCP. Важно это тем, что "качество работы" TLS непосредственно зависит от TCP. В случае возникновения проблем работы SSL/TLS на самых ранних этапах - первым делом нужно проверить, что творится именно здесь - с TCP.
Например, при настройке Intel MPS сервера вне локальной сети вы с большой долей вероятности столкнётесь с проблемой подключения AMT компьютера к оному. Проблемы будут возникать в процессе TLS Handshake, в чём можно будет убедиться, просмотрев это дело с помощью Wireshark или Microsoft Network Monitor (либо др. анализаторов сетевого трафика). При этом данной проблемы не возникает при расположении MPS внутри локальной сети.
Проблема связана с тем, что разработка и тестирование AMT всегда велась внутри корпоративной локальной сети. "Теоретически" ничто не мешает расположить MPS вне её (например, в облаке), однако "практически" получите крайне нестабильную работу из-за нерасчитанности работы AMT с большими задержками и прохождением большого количества различных маршрутизаторов.
Проблема решается уменьшением стандартно-дефолтных MTU/MSS:
 

MTU MSS

Подбирается эмпирически, обычно это где-то 1300-1370.


Выбор алгоритмов шифрования
 

  1. Алгоритм шифрования сертификата сервера - используется для того, чтобы "проверить сервер".
  2. Алгоритм шифрования для получения сессионных ключей.
  3. Основной алгоритм для шифрования передаваемых данных.
  4. Используемая функция хэширования - для проверки "контрольной суммы", т.е. чтобы убедиться в целостности пришедшей информации.

Посмотрим на примере HTTPS-сайта IT Galaxy:
 

IT-Galaxy TLS

Видны следующие настройки - используется протокол TLS 1.0, кроме этого, согласно пунктам:

  1. Ключ сертификата - шифрование RSA 2048 bit.
  2. Для получения сессионных ключей - DHE (Diffie-Hellman, DH, E - Ephemeral, обозначает, что ключи создаются случайно/временно для каждой сесссии).
  3. Шифрование трафика - AES 256 bit.
  4. Хэширование - SHA-1.

Разберём рекомендации по каждому пункту в отдельности.

Kлюч для сертификата сервера

Для сертификата сервера на 2015-й год рекомендацией является рекомендацией использование RSA с ключом 2048 бит и более. Алгоритм RSA весьма старый и в том числе очень популярный алгоритм, однако его производительность (и нагрузка на процессор) оставляет желать. Потому для уменьшения нагрузки на сервер, рекомендуется использовать ECDSA (Elliptic Curve Digital Signature Algorithm) 256-бит и более.


Почему ECDSA с 256-битным ключом лучше RSA с 2048-битным?

Сравнивать "только по битностям" нельзя. Если коротко, то ключи для симметричного шифрования используют все комбинации, а для ассиметричного - лишь малую часть.
Чтобы всё же как-то сравнить ключи, с учётом их длины и типа, то можно посмотреть тут. Где можно увидеть, что ECDSA 256 бит надёжней, чем RSA 2048 бит, но менее надёжен, чем RSA 4096 бит.

А при этом скорость работы ECDSA-256 в разы выше, чем RSA-2048 (не говоря уже про ещё более высокую битность). Однако не все поддерживают ECDSA, потому рекомендуется задействовать такие серверные конфигурации, где параллельно можно использовать и RSA (для "старых" клиентов) и ECDSA ("для новых").


Стоит ли использовать "максимально возможную битность" ключей?

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


  • Нужно учитывать, что чем больше длина ключа, тем больше нагрузка на сервер. Это значит и скорость его работы и расходы на его содержание.
  • Чем больше длина ключа - тем больше нагрузка и на клиент. Не все клиенты не имеют проблем с вычислительной мощностью. Да и те, кому это не проблема - всё равно получают дополнительную задержку при установлении соединения, что также не добавляет плюсов.
  • Клиент (браузер) может просто не поддерживать большой размер ключа (например, если браузер/ОС старые).
  • Используемое ПО (не только браузер) может не поддерживать большой размер ключа. Это очень часто является ограничением.

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

В частности, например, в том числе, если у вас ноутбуки на Intel AMT 2.5/2.6, где скорость процессора Intel ME далеко не самая лучшая - это тоже может быть весьма актуально.

Во всех же остальных случаях - RSA рекомендуется 2048 бит.

Короткое промежуточное резюме по RSA-ключам:

  • Для совместимости со старым: RSA 1024 бит
  • Современное: 2048 бит
  • Рекомендуемое: 2048 бит
  • Параноидальное: 4096 бит

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

Отдельно стоит добавить по парольной защите приватных ключей для SSH. Если вы на неё серьёзно полагаетесь, то нужно помнить, что для этого по дефолту используется MD5 со всеми вытекающими. Правильней для использовать PKCS#8.

Чтобы минимизировать проблемы с приватными ключами:


Алгоритм для сессионных ключей

Очень важный с точки зрения "полной безопасности" момент, обеспечивающий так называемую "Forward Secrecy" - когда для аутентификации сервера используется один алгоритм (например, RSA), а для установления сессионого ключа - другой (например, ECDHE). И так, чтобы этот ключ постоянно менялся. В этом случае, даже если враги запишут зашифрованный разговор и после с помощью метода терморектального криптоанализа вычислят приватные RSA-ключи (сертификата сервера) - они не смогут расшифровать ваш записанный разговор (лишь только будущие - где будут использованы эти же "добытые" ключи).
Современной реализацией для этого является ECDHE. В частности, на примере выше у IT Galaxy используется "более совместимый" (со старыми клиентами) DHE - много более прожорливый (3-10 раз по сравнению с ECDHE).
Для настройки параметров DH параметров генерируется файл "DH param". Рекомендации следующие - размер "DH param" не должен быть меньше, чем ключ RSA:


  • Для совместимости со старым: DH param 1024 бит
  • Современное: DH param 1024 бит или 2048 бит
  • Рекомендуемое: DH param 2048 бит
  • Параноидальное: DH param 4096 бит

Алгоритм шифрования передаваемых данных

Для шифрования данных на такущий момент является AES.


  • Для совместимости со старым: 3DES (медленно) или RC4 (ненадёжно)
  • Современное: AES 128 bit
  • Рекомендуемое: AES 128 bit
  • Параноидальное: AES 256 bit

Хэширование

Наиболее распространённым на текущий момент является SHA-1. Однако в 2016-м году истекает его использование сертификационными центрами, потому даже несмотря на достаточную защиту - нужно переходить на SHA-256 и выше.


  • Для совместимости со старым: SHA-1
  • Современное: SHA-1
  • Рекомендуемое: SHA-256
  • Параноидальное: SHA-384

Рекомендуемые версии SSL/TLS

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


  • Для совместимости со старым: SSL3 - TLS1.2
  • Современное: TLS1.0 - TLS1.2
  • Рекомендуемое: TLS1.0 - TLS1.2 или TLS1.1 - TLS1.2
  • Параноидальное: TLS1.2

Для демонстрации рекомендаций по SSL/TLS приведу пример конкретной реализации при настройке NGINX-сервера.

Рекомендации по настройка NGINX для SSL/TLS

Базовые настройки SSL/TLS:
...

server {
listen 443; ### используемый порт, стандартный - 443
ssl on;
ssl_certificate /etc/ssl/private/your_site.crt; ### Сертификат сайта вместе промежуточным/-и (не забываем!)
### Если, например, вы получили "халявный" сертификат StartSSL (см. статью Aidjek),
### то не забываем соединить (просто один за другим - сертификат сайта и за ним
### промежуточный сертификат StartSSL Class 1,
### иначе некоторые браузеры, которые
### не будут у себя его (промежуточный сертификат) иметь —
### откажутся соединяться.
ssl_certificate_key /etc/ssl/private/your_site.key.pem; ### Приватный ключ

...

Чтобы указать наши "рекомендации" по выбору нужных алгоритмов шифрования - включаем предпочтение шифров сервера, а не клиента:

ssl_prefer_server_ciphers on;

Далее требуется перечислить конкретные "связки" алгоритмов шифрования, которые будут предлагаться клиенту. Последовательность крайне важна - сначала идут наиболее надёжные/эффективные, в конце те, что для совместимости (если вам они нужны).
 

  • Для совместимости со старым прописываем:

ssl_protocols SSLv3 TLSv1 TLSv1.1 TLSv1.2; ### Поддерживаемые версии SSL/TLS
ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:ECDHE-RSA-DES-CBC3-SHA:ECDHE-ECDSA-DES-CBC3-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA"; ### Алгоритмы шифрования и хэши в порядке убывания "надёжности/эффективности"
ssl_dhparam /etc/nginx/ssl/dh1024.pem; ### DH param 1024 бит, генерим с помощью "openssl dhparam -out dh1024.pem 1024"

  • Для современных систем:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ### Поддерживаемые версии SSL/TLS
ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA"; ### Алгоритмы шифрования и хэши в порядке убывания "надёжности/эффективности"
ssl_dhparam /etc/nginx/ssl/dh2048.pem; ### DH param 2048 бит, генерим с помощью "openssl dhparam -out dh2048.pem 2048"

  • Рекомендуемые:

ssl_protocols TLSv1.1 TLSv1.2; ### или TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers "ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK"; ### Алгоритмы шифрования и хэши в порядке убывания "надёжности/эффективности"
ssl_dhparam /etc/nginx/ssl/dh2048.pem; ### DH param 2048 бит, генерим с помощью "openssl dhparam -out dh2048.pem 2048"

  • Для параноиков:

ssl_protocols TLSv1.2; ### Поддерживаемые версии SSL/TLS
ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!3DES:!MD5:!PSK"; ### Алгоритмы шифрования и хэши в порядке убывания "надёжности/эффективности"
ssl_dhparam /etc/nginx/ssl/dh4096.pem; ### DH param 4096 бит, генерим с помощью "openssl dhparam -out dh4096.pem 4096"

Session Resumption

Дополнительно стоит упомянуть важный параметр возобновления TLS-сессии, который серьёзно снижает нагрузку от вернувшихся клиентов, т.к. TLS Handshake в таком случае идёт "по укороченной программе" и нет затратных операций.

Для его реализации добавляем блок:


###Session Resumption
ssl_session_cache shared:SSL:10m;
ssl_session_timeout 1h;
###Располагается вне server{ … } т.к. является общим


Итого по рекомендациям использования SSL/TLS.
Если вы не параноик, то выбор настроек для SSL/TLS должен учитывать компромисс - между надёжностью, максимальной поддержкой ваших клиентов, скоростью работы и нагрузки - как на сервер, так и на клиентский компьютер. Потому "однозначных" рекомендаций нет, всегда стоит учитывать конкретный случай.

Комментарии

Добрый день. Пытаюсь настроить MutualTLS на плате DQ67OW и др. Никак не подключается в KVM - с клиентов RealVNC и MDTK. Пишет, что нет нужного сертификата. При этом, по HTTPS работает работает вроде, т.к. запрашивает сертификат. Скажите, получилось ли у кого-нибудь подключиться или этот функционал не работает в принципе?

Аватар пользователя apple_rom

У меня есть такая плата, потому проверю и опишу, возможно даже виде статейки.

Добавить комментарий

Filtered HTML

  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Доступные HTML теги: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd>
  • Строки и параграфы переносятся автоматически.

Plain text

  • HTML-теги не обрабатываются и показываются как обычный текст
  • Адреса страниц и электронной почты автоматически преобразуются в ссылки.
  • Строки и параграфы переносятся автоматически.
Anti-bot.