Перейти к содержимому

Ubuntu tls что это

  • автор:

3. Настройка TLS (Transport Layer Security)

В наши дни использование TLS является практически обязательным. TLS реализует защитные функции конфиденциальности и целостности данных, а так же служит для поддержки аутентификации LDAP с использованием механизма SASL EXTERNAL. TLS определён в RFC4346. Для настройки TLS на сервере нам понадобятся SSL сертификат и ключ. Сертификат должен быть подписан доверенным удостоверяющим центром (УЦ, Certificate Authority, CA) или собственным удостоверяющим центром (на основе самоподписанного, self-signed, сертификата), если используется в тестовых целях. С помощью OpenSSL мы создадим импровизированный удостоверяющий центр и затем настроим TLS. Прямая цитата из Википедии:

Сертификаты, как правило, используются для обмена зашифрованными данными в больших сетях. Криптосистема с открытым ключом решает проблему обмена секретными ключами между участниками безопасного обмена, однако не решает проблему доверия к открытым ключам. Предположим, что Алиса, желая получать зашифрованные сообщения, генерирует пару ключей, один из которых (открытый) она публикует каким-либо образом. Любой, кто желает отправить ей конфиденциальное сообщение, имеет возможность зашифровать его этим ключом, и быть уверенным, что только она (так как только она обладает соответствующим секретным ключом) сможет это сообщение прочесть. Однако описанная схема ничем не может помешать злоумышленнику Давиду создать пару ключей, и опубликовать свой открытый ключ, выдав его за ключ Алисы. В таком случае Давид сможет расшифровывать и читать, по крайней мере, ту часть сообщений, предназначенных Алисе, которые были по ошибке зашифрованы его открытым ключом. Идея сертификата — это наличие третьей стороны, которой доверяют две другие стороны информационного обмена. Предполагается, что таких третьих сторон немного, и их открытые ключи всем известны каким-либо способом, например, хранятся в операционной системе или публикуются в журналах. Таким образом, подлог открытого ключа третьей стороны легко выявляется. Если Алиса сформирует сертификат со своим публичным ключом, и этот сертификат будет подписан третьей стороной (например, Трентом), любой, доверяющий Тренту, сможет удостовериться в подлинности открытого ключа Алисы. В централизованной инфраструктуре в роли Трента выступает удостоверяющий центр. В сетях доверия Трент может быть любым пользователем, и следует ли доверять этому пользователю, удостоверившему ключ Алисы, решает сам отправитель сообщения.

3.1 Удостоверяющий центр на основе самоподписанного сертификата с помощью OpenSSL

Где работаем: ldap-srv Итак, мы создаём централизованную инфраструктуру открытых ключей (PKI) в миниатюре. Для этого сформируем пару закрытый ключ/корневой сертификат удостоверяющего центра. Причём сертификат будет подписан этим же закрытым ключом (т. е. станет самоподписанным). Затем сгенерируем новый закрытый ключ для нашей службы каталогов и создадим для неё сертификат, подписанный закрытым ключом нашего удостоверяющего центра. При этом клиенские рабочие станции должны знать только корневой сертификат. Используя его они могут установить безопасное соединение с любым сервером, который имеет закрытый ключ и соответствующий ему сертификат, подписанный нашим УЦ. Такие пары (ключ/сертификат) можно создавать для множества задач. Например, в разделе, посвященном репликации, мы создадим второй сервер каталогов, которому тоже понадобится такая пара. Удостоверяющий центр желательно разворачивать на отдельной машине, не имеющей подключения к сети, но для простоты примера мы проделаем всю работу на ldap-srv.example.com. Создадим каталог для нашего удостоверяющего центра (CA) и установим безопасные права доступа. Затем зададим значение umask таким, чтобы вновь создаваемые файлы имели права доступа чтения и записи только для создавшего их пользователя:

# mkdir /root/CA # chmod u=rwx,g=,o= /root/CA # cd /root/CA # umask 066

В конфигурационном файле /etc/ssl/openssl.cnf в секции [ CA_default ] для удобства поменяем значение директивы dir = ./demoCA на dir = ./ . В этом же разделе директивой default_days задаётся срок действия выпускаемых сертификатов. Можете поменять её значение по своему усмотрению. Файлы index.txt и serial будут играть роль своеобразной базы данных, чтобы отслеживать статус выпущенных закрытых ключей и сертификатов. Создадим структуру каталогов и файлов для своего удостоверяющего центра:

# mkdir certs crl newcerts private # chmod 700 private # touch index.txt # echo 1000 > serial

Сгенерируем закрытый ключ удостоверяющего центра (длиной 4096 бит). Он должен хранится особенно бережно. Поэтому мы защитим его при помощи шифра AES. Вам будет предложено ввести пароль для доступа к новому закрытому ключу. Запомните его и не потеряйте. Это последний рубеж защиты от злоумышленника. Без пароля выпустить новые сертификаты не получится.

# openssl genrsa -aes256 -out private/rootca.key 4096

Изменим права доступа к новому ключу, чтобы ненароком его не стереть:

# chmod 400 private/rootca.key

Откройте конфигурационный файл OpenSSL (openssl.cnf) и найдите секции [ usr_cert ] и [ v3_ca ] . Убедитесь, что в них присутствуют следующие директивы:

[ usr_cert ] # Эти расширения будут добавлены при подписывании запроса нашим УЦ. basicConstraints=CA:FALSE keyUsage = nonRepudiation, digitalSignature, keyEncipherment nsComment = "OpenSSL Generated Certificate" subjectKeyIdentifier=hash authorityKeyIdentifier=keyid,issuer [ v3_ca ] # Расширения для типового УЦ subjectKeyIdentifier=hash authorityKeyIdentifier=keyid:always,issuer basicConstraints = CA:true keyUsage = cRLSign, keyCertSign

Сейчас мы можем выпустить корневой сертификат удостоверяющего центра, подписав его закрытым ключом rootca.key. Так как это сертификат УЦ, используем расширение v3_ca :

# openssl req -sha256 -new -x509 -days 3650 -extensions v3_ca \ -key private/rootca.key -out certs/rootca.crt \ -subj /C=RU/ST=Moscow/L=Moscow/O=ExampleInc/OU=ITdept/CN=ca-server/emailAddress=support@example.com # chmod 444 certs/rootca.crt

В качестве алгоритма хэширования мы используем SHA-2 (подвид SHA-256). Стоимость атаки на SHA-1 стремительно падает, а о практическом применении новоявленного SHA-3 говорить пока рано. Почему мы выбрали именно SHA-256, а не SHA-512? С сертификатом, использующим SHA-512, Вы сможете запустить демон slapd, но не сможете к нему подключиться. Увидите лишь такую многозначную ошибку:

can't connect: A TLS packet with unexpected length was received.
  • C — Country Name (страна) — RU
  • ST — State or Province Name (штат или провинция) — Moscow
  • L — Locality Name (город) — Moscow
  • O — Organization Name (наименование организации) — ExampleInc
  • OU — Organizational Unit Name (наименование подразделения) — ITdept
  • CN — Common Name (имя субъекта или FQDN сервера) — ca-server
  • emailAddress — Email Address (адрес электронной почты) — support@example.com

Можем посмотреть содержимое сертификата следующей командой:

# openssl x509 -in certs/rootca.crt -noout -text

Удостоверяющий центр готов к выпуску сертификатов.

3.2 Выпуск сертификата для сервера службы каталогов

Где работаем: ldap-srv

Как правило, закрытые ключи клиентов УЦ не должны хранится в самом УЦ. Клиент может сам сформировать ключевую пару и прислать в УЦ лишь запрос на подпись (Certificate Signing Request, CSR). Запрос содержит открытый ключ. Однако мы будем создавать все ключи и хранить их в одном месте. В организации, которая серьёзно подходит к проблемам безопасности такой процесс работы может быть неприемлемым.

Продолжаем в том же каталоге /root/CA. Создадим закрытый ключ для сервера службы каталогов:

# openssl genrsa -out private/ldap-srv.example.com.key 4096 # chmod 400 private/ldap-srv.example.com.key

Сгенерируем запрос на подпись сертификата. Наименование организации (ExampleInc) должно совпадать с наименованием в корневом сертификате УЦ. В качестве Common Name укажем FQDN нашего сервера:

# openssl req -sha256 -new \ -key private/ldap-srv.example.com.key -out certs/ldap-srv.example.com.csr \ -subj /C=RU/ST=Moscow/L=Moscow/O=ExampleInc/OU=ITdept/CN=ldap-srv.example.com/emailAddress=support@example.com

Следующим шагом должно быть подписание запроса CSR существующим доверенным удостоверяющим центром (например, VeriSign) в обмен на деньги. Но нам не хочется платить за эту услугу, или у нас нет своего (корпоративного) CA, или это просто тестовая конфигурация, а может нам просто всё равно. Поэтому мы подпишем его с помощью своего собственного CA:

# openssl ca -extensions usr_cert -notext -md sha256 \ -keyfile private/rootca.key -cert certs/rootca.crt \ -in certs/ldap-srv.example.com.csr -out certs/ldap-srv.example.com.crt # chmod 444 certs/ldap-srv.example.com.crt

Создадим каталог для ключевой информации нашего сервера и поместим туда получившиеся у нас файлы:

# mkdir /etc/ldap/ssl # chown openldap:openldap /etc/ldap/ssl # chmod 0500 /etc/ldap/ssl # cp certs/ldap-srv.example.com.crt private/ldap-srv.example.com.key /etc/ldap/ssl

Установим права доступа для ключевой информации:

# chown openldap:openldap /etc/ldap/ssl/ # chmod 0400 /etc/ldap/ssl/

Поместим корневой сертификат в каталог с сертификатами операционной системы и зададим для него права доступа:

# cp certs/rootca.crt /etc/ssl/certs/ # chmod 0644 /etc/ssl/certs/rootca.crt

В заключение можем удалить запрос CSR, он нам больше не нужен:

# rm -rf certs/ldap-srv.example.com.csr

Каталог /root/CA теперь выполняет роль удостоверяющего центра. Аналогичным образом его можно создать на другой машине, тогда надо будет копировать секретные ключи и подписанные сертификаты по сети с помощью scp или через съёмный носитель. Неплохой идеей будет хранить этот каталог на отдельном носителе и монтировать его только для выпуска новых сертификатов. Сам носитель можно, например, положить в сейф. Процесс создания новых пар ключ-сертификат в будущем будет состоять из трёх этапов:

  1. Генерация секретного ключа и запроса на подписание сертификата;
  2. Подписание сертификата с помощью закрытого ключа нашего CA (rootca.key);
  3. Перемещение новых секретного ключа и подписанного сертификата в каталоги, где они будут использоваться.

3.3 Настройка конфигурации TLS

Где работаем: ldap-srv

Вернёмся во временный каталог:

$ cd ~/ldap

Создадим LDIF-файл 3.2-tls-config.ldif для внесения в каталог конфигурации TLS и запишем в него:

dn: cn=config add: olcTLSVerifyClient olcTLSVerifyClient: never - add: olcTLSCertificateFile olcTLSCertificateFile: /etc/ldap/ssl/ldap-srv.example.com.crt - add: olcTLSCertificateKeyFile olcTLSCertificateKeyFile: /etc/ldap/ssl/ldap-srv.example.com.key - add: olcTLSCACertificateFile olcTLSCACertificateFile: /etc/ssl/certs/rootca.crt

Этими записи говорят демону slapd, где лежит его сертификат и ключ, где лежит корневой сертификат УЦ и что от клиентов требовать наличие сертификата не нужно. Чтобы окончательно всё запутать, мы могли бы создать сертификаты для всех клиентов. В реальной жизни такая аутентификация клиента принесёт небольшое усиление защиты за счёт большого увеличения работы по сопровождению всех этих сертификатов. Тем более далее в этом руководстве мы опишем механизмы аутентификации Kerberos.

Загрузим конфигурацию TLS в наш каталог:

# ldapmodify -QY EXTERNAL -H ldapi:/// -f 3.2-tls-config.ldif modifying entry "cn=config"

Теперь наш сервер OpenLDAP должен поддерживать расширения TLS. Перепроверим, что всё в порядке:

# ldapsearch -QLLLY EXTERNAL -H ldapi:/// -b cn=config -s base | grep -i tls olcTLSCertificateFile: /etc/ldap/ssl/ldap-srv.example.com.crt olcTLSCertificateKeyFile: /etc/ldap/ssl/ldap-srv.example.com.key olcTLSCACertificateFile: /etc/ssl/certs/rootca.crt olcTLSVerifyClient: never

Вновь отредактируем конфигурационный файл /etc/ldap/ldap.conf и включим поддержку TLS:

BASE dc=example,dc=com URI ldap://ldap-srv.example.com TLS_CACERT /etc/ssl/certs/rootca.crt TLS_REQCERT demand TIMELIMIT 15 TIMEOUT 20

Обычно для конфигурации cn=config перезагрузка службы не требуется, но чтобы созданная нами ключевая информация подхватилась, придётся это сделать:

# service slapd restart * Stopping OpenLDAP slapd [ OK ] * Starting OpenLDAP slapd [ OK ]

Проверьте соединение с сервером с использованием TLS (модификатор -ZZ ). На этот раз мы выполним запрос с использованием DN нашего администратора:

$ ldapsearch -xZZLLLWD cn=admin,dc=example,dc=com -b cn=config -s base Enter LDAP Password: dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd/slapd.args olcPidFile: /var/run/slapd/slapd.pid olcTLSCACertificateFile: /etc/ssl/certs/rootca.crt olcTLSCertificateFile: /etc/ldap/ssl/ldap-srv.example.com.crt olcTLSCertificateKeyFile: /etc/ldap/ssl/ldap-srv.example.com.key olcTLSVerifyClient: never

Обратите внимание, что в запросе ldapsearch нам не пришлось указывать имя хоста ( -H ldap://ldap-srv.example.com ). Всё потому что оно указано в файле /etc/ldap/ldap.conf. Что касается TLS, то во время инициирования соединения клиент (на данном этапе клиентский запрос выполняет сам сервер) получает от сервера его подписанный сертификат (ldap-srv.example.com.crt). Клиент может ничего не знать о сервере, но у него есть сертификат CA (rootca.crt), с помощью которого и проверяется сервер.

3.4 Создание CRL и отзыв сертификатов

Где работаем: ldap-srv

Сертификаты не вечны. Во-первых при создании задаётся его срок действия. При этом частота обновления сертификатов — баланс между безопасностью и удобством. Во-вторых он может быть скомпрометирован, если скомпрометирован его закрытый ключ. Как во втором случае оповестить субъектов доступа, что сертификат более не действителен? Для этого и служит Certificate Revocation List (CRL). Он представляет собой список серийных номеров отозванных сертификатов, подписанный УЦ, который их выпустил.

Вернёмся в каталог удостоверяющего центра:

# cd /root/CA

Прежде чем мы сможем сгенерировать CRL, надо создать файл crlnumber. Он нужен openssl, чтобы отслеживать номер следующего CRL:

# echo 1000 > crlnumber

В стандартной конфигурации openssl использует CRL V1. Раскомментируйте строку

crl_extensions = crl_ext

в /etc/ssl/openssl.cnf, чтобы переключиться на CRL V2. Это хорошая идея, за исключением тех случаев, когда надо использовать именно CRL V1 (например, при использовании сильно устаревшего браузера). Создаём CRL:

# openssl ca -keyfile private/rootca.key -cert certs/rootca.crt -gencrl -out crl/rootca.crl

Посмотреть результат можно так:

# openssl crl -in crl/rootca.crl -text

Предположим, что закрытый ключ сервера ldap-srv был скомпрометирован. Чтобы оповестить об этом клиентские машины, надо отозвать сертификат этого сервера, создать CRL, а затем — распространить CRL среди клиентов.

# openssl ca -keyfile private/rootca.key -cert certs/rootca.crt -revoke certs/ldap-srv.example.com.crt

Заглянем в index.txt. Начало записи с нашим сертификатом теперь изменилось с V на R :

# cat index.txt R 160116072355Z 150119081313Z 1000 unknown /C=RU/ST=Moscow/O=ExampleInc/OU=ITdept/CN=ldap-srv.example.com/emailAddress=support@example.com

Обратите внимание, что копии новых сертификатов так же содержатся в каталоге newcerts. При этом имя файла содержит серийный номер сертификата. Когда отзываете сертификаты, вместо файлов в каталоге certs Вы можете пользоваться каталогом newcerts. Результат будет идентичен. Например:

# openssl ca -keyfile private/rootca.key -cert certs/rootca.crt -revoke newcerts/1000.pem
# openssl ca -keyfile private/rootca.key -cert certs/rootca.crt -gencrl -out crl/rootca.crl

Взглянём на содержимое CRL:

# openssl crl -in crl/rootca.crl -text

Вы должны увидеть нечто подобное:

. Revoked Certificates: Serial Number: 1000 Revocation Date: .

Поместим CRL в каталог, где его увидит клиентское ПО:

# cp crl/rootca.crl /etc/ssl

Осталось только распространить этот CRL среди клиентов. Мы делаем это простым путём — копированием файлов по сети вручную.

Где работаем: ldap-client

На каждой клиентской машине надо будет запустиь:

# scp user@ldap-srv.example.com:/etc/ssl/certs/rootca.crt /etc/ssl/certs # scp user@ldap-srv.example.com:/etc/ssl/rootca.crl /etc/ssl/

Настроим клиентскую конфигурацию в /etc/ldap/ldap.conf и укажем, где хранится CRL:

BASE dc=example,dc=com URI ldap://ldap-srv.example.com TLS_CACERT /etc/ssl/certs/rootca.crt TLS_REQCERT demand TLS_CRLFILE /etc/ssl/rootca.crl TIMELIMIT 15 TIMEOUT 20

И попробуем получить доступ к серверу каталогов:

$ ldapsearch -xZZLLLWD cn=admin,dc=example,dc=com -b cn=config -s base dn ldap_start_tls: Connect error (-11) additional info: (unknown error code)

Наш CRL работает. Но к slapd теперь не подключиться. Надо выпустить новый сертификат для сервера.

Где работаем: ldap-srv

Сделаем это простой последовательностью команд. Мы повторяем пройденное, комментарии излишни:

# cd /root/CA # openssl genrsa -out private/ldap-srv.example.com.key 4096 # chmod 400 private/ldap-srv.example.com.key # openssl req -sha256 -new \ -key private/ldap-srv.example.com.key -out certs/ldap-srv.example.com.csr \ -subj /C=RU/ST=Moscow/L=Moscow/O=ExampleInc/OU=ITdept/CN=ldap-srv.example.com/emailAddress=support@example.com # openssl ca -extensions usr_cert -notext -md sha256 \ -keyfile private/rootca.key -cert certs/rootca.crt \ -in certs/ldap-srv.example.com.csr -out certs/ldap-srv.example.com.crt # chmod 444 certs/ldap-srv.example.com.crt # cp certs/ldap-srv.example.com.crt private/ldap-srv.example.com.key /etc/ldap/ssl # chown openldap:openldap /etc/ldap/ssl/ # chmod 0400 /etc/ldap/ssl/

Перезупустим демон slapd и убедимся, что к серверу можно подключиться:

# service slapd restart $ ldapsearch -xZZLLLWD cn=admin,dc=example,dc=com -b cn=config -s base dn Enter LDAP Password: dn: cn=config

В целом по отзыву сертификатов. Иногда в реальных условиях лучше применить другой подход. Намного удобней, когда клиентские машины самостоятельно выясняют у сервера, действителен конкретный сертификат или нет. В выпускаемые сертификаты можно вносить запись CRL Distribution Points . Она заставит клиентов самих периодически скачивать новый CRL. Или можно использовать OCSP. Но эта тема выходит за рамки данного руководства.

OpenLDAP и Ubuntu на практике > Настройка TLS (Transport Layer Security)

Pro-LDAP.ru 2015 г. Последнее изменение страницы — 3 мая 2015 г. Вопросы и предложения принимаются на форуме проекта.

MNorin.com

Блог про Linux, Bash и другие информационные технологии

TLS и SSL: Необходимый минимум знаний

Необходимый минимум знаний об SSL/TLS

TLS и SSL упоминаются в последнее время все чаще и чаще, более актуальным становится использование цифровых сертификатов, и даже появились компании, готовые бесплатно предоставлять цифровые сертификаты всем желающим, чтобы гарантировать шифрование трафика между посещаемыми сайтами и браузером клиента. Нужно это, естественно, для безопасности, чтобы никто в сети не мог получить данные, которые передаются от клиента серверу и обратно. Как же это всё работает и как это использовать? Чтобы это понять, надо, пожалуй, начать с теории, а потом показать на практике. Итак, SSL и TLS.

Что такое SSL и что такое TLS?

SSL — Secure Socket Layer, уровень защищенных сокетов. TLS — Transport Layer Security, безопасность транспортного уровня. SSL является более ранней системой, TLS появился позднее и он основан на спецификации SSL 3.0, разработанной компанией Netscape Communications. Тем не менее, задача у этих протоколов одна — обеспечение защищенной передачи данных между двумя компьютерами в сети Интернет. Такую передачу используют для различных сайтов, для электронной почты, для обмена сообщениями и много еще для чего. В принципе, можно передавать любую информацию таким образом, об этом чуть ниже.

Безопасная передача обеспечивается при помощи аутентификации и шифрования передаваемой информации. По сути эти протоколы, TLS и SSL, работают одинаково, принципиальных различий нет. TLS, можно сказать, является преемником SSL, хотя они и могут использоваться одновременно, причем даже на одном и том же сервере. Такая поддержка необходима для того, чтобы обеспечить работу как с новыми клиентами (устройствами и браузерами), так и с устаревшими, которые TLS не поддерживают. Последовательность возникновения этих протоколов выглядит вот так:

SSL 1.0 — никогда не публиковался
SSL 2.0 — февраль 1995 года
SSL 3.0 — 1996 год
TLS 1.0 — январь 1999 года
TLS 1.1 — апрель 2006 года
TLS 1.2 — август 2008 года

Принцип работы SSL и TLS

Принцип работы SSL и TLS, как я уже сказал, один и тот же. Поверх протокола TCP/IP устанавливается зашифрованный канал, внутри которого передаются данные по прикладному протоколу — HTTP, FTP, и так далее. Вот как это можно представить графически:

TLS и SSL: Необходимый минимум знаний

Прикладной протокол «заворачивается» в TLS/SSL, а тот в свою очередь в TCP/IP. По сути данные по прикладному протоколу передаются по TCP/IP, но они зашифрованы. И расшифровать передаваемые данные может только та машина, которая установила соединения. Для всех остальных, кто получит передаваемые пакеты, эта информация будет бессмысленной, если они не смогут ее расшифровать.

Установка соединения обеспечивается в несколько этапов:

1) Клиент устанавливает соединение с сервером и запрашивает защищенное подключение. Это может обеспечиваться либо установлением соединения на порт, который изначально предназначен для работы с SSL/TLS, например, 443, либо дополнительным запросом клиентом установки защищенного соединения после установки обычного.

2) При установке соединения клиент предоставляет список алгоритмов шифрования, которые он «знает». Сервер сверяет полученный список со списком алгоритмов, которые «знает» сам сервер, и выбирает наиболее надежный алгоритм, после чего сообщает клиенту, какой алгоритм использовать

3) Сервер отправляет клиенту свой цифровой сертификат, подписанный удостоверяющим центром, и открытый ключ сервера.

4) Клиент может связаться с сервером доверенного центра сертификации, который подписал сертификат сервера, и проверить, валиден ли сертификат сервера. Но может и не связываться. В операционной системе обычно уже установлены корневые сертификаты центров сертификации, с которыми сверяют подписи серверных сертификатов, например, браузеры.

5) Генерируется сеансовый ключ для защищенного соединения. Это делается следующим образом:
— Клиент генерирует случайную цифровую последовательность
— Клиент шифрует ее открытым ключом сервера и посылает результат на сервер
— Сервер расшифровывает полученную последовательность при помощи закрытого ключа
Учитывая, что алгоритм шифрования является асимметричным, расшифровать последовательность может только сервер. При использовании асимметричного шифрования используется два ключа — приватный и публичный. Публичным отправляемое сообщение шифруется, а приватным расшифровывается. Расшифровать сообщение, имея публичный, ключ нельзя.

6) Таким образом устанавливается зашифрованное соединение. Данные, передаваемые по нему, шифруются и расшифровываются до тех пор, пока соединение не будет разорвано.

Корневой сертификат

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

Запрос на подпись (CSR, Certificate Sign Request)

Для получения подписанного серверного сертификата необходимо сгенерировать запрос на подпись (CSR, Certificate Sign Request) и отправить этот запрос авторизационному центру, который вернет подписанный сертификат, устанавливаемый непосредственно на сервер, чуть ниже посмотрим, как это сделать на практике. Сначала генерируется ключ для шифрования, затем на основании этого ключа генерируется запрос на подпись, CSR-файл.

Клиентский сертификат

Клиентский сертификат может быть сгенерирован как для использования в устройствах, так и для использования пользователями. Обычно такие сертификаты используются при двусторонней верификации, когда клиент верифицирует, что сервер действительно тот, за кого себя выдает, и сервер в ответ делает то же самое. Такое взаимодействие называется двусторонней аутентификацией или mutual authentication. Двусторонняя аутентификация позволяет повысить уровень безопасности по сравнению с односторонней, а также может служить заменой аутентификации с использованием логина и пароля.

Цепочка действий по генерации сертификатов

Давайте посмотрим на практике, как происходят действия, связанные с генерацией сертификатов, с самого начала, и при этом на практике.

Первое, что делается — это генерация корневого сертификата. Корневой сертификат подписывается самим собой. А потом уже этим сертификатом будут подписываться другие сертификаты.

$ openssl genrsa -out root.key 2048 Generating RSA private key, 2048 bit long modulus . +++ . +++ e is 65537 (0x10001) $ openssl req -new -key root.key -out root.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:N/A Locality Name (eg, city) []:Saint-Petersburg Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:IT Service Common Name (e.g. server FQDN or YOUR name) []:My Company Root Certificate Email Address []:it@mycompany.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []:My Company $ openssl x509 -req -days 3650 -in root.csr -signkey root.key -out root.pem Signature ok subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/emailAddress=it@mycompany.com Getting Private key

Таким образом мы сгенерировали сначала приватный ключ, затем запрос подписи, а затем своим ключом подписали свой же запрос и получили собственный цифровой сертификат, выданный на 10 лет. Пароль (challenge password) при генерации сертификата можно не вводить.

Приватный ключ ОБЯЗАТЕЛЬНО необходимо хранить в надежном месте, имея его можно подписать от вашего имени любой сертификат. А полученный корневой сертификат можно использовать для идентификации того, что сертификат, например, сервера подписан именно нами, а не кем-то еще. Именно такие действия выполняют авторизационные центры, когда генерируют собственные сертификаты. После создания корневого сертификата можно приступать к генерации сертификата сервера.

Просмотр информации о сертификате

Содержимое сертификата можно просмотреть таким образом:

$ openssl x509 -noout -issuer -enddate -in root.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/emailAddress=it@mycompany.com notAfter=Jan 22 11:49:41 2025 GMT

Мы видим, кто выдал этот сертификат и когда заканчивается срок его годности.

Серверный сертификат

Для подписи сертификата для сервера нам нужно выполнить следующие действия:

1) Сгенерировать ключ
2) Сгенерировать запрос на подпись
3) Отправить CSR-файл в авторизационный центр или подписать самостоятельно

В серверный сертификат может включаться цепочка сертификатов, которыми подписан сертификат сервера, но ее можно также хранить в отдельном файле. В принципе, выглядит всё примерно так же, как и при генерации корневого сертификата

$ openssl genrsa -out server.key 2048 Generating RSA private key, 2048 bit long modulus . +++ . +++ e is 65537 (0x10001) $ openssl req -new -key server.key -out server.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:N/A Locality Name (eg, city) []:Saint-Petersburg Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:IT Service Common Name (e.g. server FQDN or YOUR name) []:www.mycompany.com Email Address []:webmaster@mycompany.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: $ openssl x509 -req -in server.csr -CA root.pem -CAkey root.key -CAcreateserial -out server.pem -days 365 Signature ok subject=/C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/emailAddress=webmaster@mycompany.com Getting CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in server.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/emailAddress=it@mycompany.com subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/emailAddress=webmaster@mycompany.com notAfter=Jan 25 12:22:32 2016 GMT

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

Установка SSL/TLS-сертификата на сервер с nginx

Для установки SSL/TLS-сертификата на веб-сервер nginx надо выполнить несколько простых шагов:

1) Скопировать файлы .key и .pem на сервер. В различных операционных системах сертификаты и ключи могут храниться в разных директориях. В Debian’е, к примеру, это директория /etc/ssl/certs для сертификатов и /etc/ssl/private для ключей. В CentOS это /etc/pki/tls/certs и /etc/pki/tls/private

2) Прописать необходимые настройки в конфигурационный файл для хоста. Вот как это примерно должно выглядеть (это просто пример):

server < listen 443; server_name www.mycompany.com; root html; index index.html index.htm; ssl on; ssl_certificate server.pem; ssl_certificate_key server.key; ssl_session_timeout 5m; # Не рекомендуется использовать SSLv3 . # Он здесь только для примера ssl_protocols SSLv3 TLSv1; ssl_ciphers ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv3:+EXP; ssl_prefer_server_ciphers on; location / < try_files $uri $uri/ =404; >>

3) Перезапустить nginx

4) Зайти браузером на 443 порт сервера — https://www.mycompany.com и проверить его работоспособность.

Установка SSL/TLS-сертификата на сервер с Apache

Установка SSL/TLS-сертификата на Apache выглядит примерно так же.

1) Скопировать файлы ключа и сертификата на сервер в соответствующие директории

2) Включить модуль ssl для Apache командой «a2enmod ssl», если он еще не включен

3) Создать виртуальный хост, который будет слушать 443 порт. Конфиг будет выглядеть примерно так:

  ServerAdmin webmaster@mycompany.com DocumentRoot /var/www Options FollowSymLinks AllowOverride None Options Indexes FollowSymLinks MultiViews AllowOverride None Order allow,deny allow from all ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/ AllowOverride None Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch Order allow,deny Allow from all ErrorLog $/error.log LogLevel warn CustomLog $/ssl_access.log combined SSLEngine on SSLCertificateFile /etc/ssl/certs/server.pem SSLCertificateKeyFile /etc/ssl/private/server.key # Эта директива добавляет файл, содержащий список # всех сертификатов, которыми подписан сертификат сервера #SSLCertificateChainFile /etc/apache2/ssl.crt/server-ca.crt SSLOptions +StdEnvVars SSLOptions +StdEnvVars BrowserMatch "MSIE [2-6]" \ nokeepalive ssl-unclean-shutdown \ downgrade-1.0 force-response-1.0 BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown

При этом надо сделать еще кое-что. Найти в файле httpd.conf, или apache2.conf, или ports.conf, в зависимости от системы, такой участок конфига:

 Listen 443

Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку

NameVirtualHost *:443

Эта строка может находиться в файле httpd.conf, apache2.conf или ports.conf

4) Перезапустить веб-сервер Apache

Создание клиентского сертификата

Клиентский сертификат создается примерно так же, как серверный.

$ openssl genrsa -out client.key 2048 Generating RSA private key, 2048 bit long modulus . +++ . +++ e is 65537 (0x10001) $ openssl req -new -key client.key -out client.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:Saint-Petersburg Locality Name (eg, city) []:^C mnorin@mnorin-work:~/Temp/certs/CA$ openssl req -new -key client.key -out client.csr You are about to be asked to enter information that will be incorporated into your certificate request. What you are about to enter is what is called a Distinguished Name or a DN. There are quite a few fields but you can leave some blank For some fields there will be a default value, If you enter '.', the field will be left blank. ----- Country Name (2 letter code) [AU]:RU State or Province Name (full name) [Some-State]:N/A Locality Name (eg, city) []:Saint-Petrersburg Organization Name (eg, company) [Internet Widgits Pty Ltd]:My Company Organizational Unit Name (eg, section) []:Engineering Common Name (e.g. server FQDN or YOUR name) []:Ivan Ivanov Email Address []:iivanov@mycompany.com Please enter the following 'extra' attributes to be sent with your certificate request A challenge password []: An optional company name []: $ openssl x509 -req -in client.csr -CA root.pem -CAkey root.key -CAcreateserial -out client.pem -days 365 Signature ok subject=/C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/emailAddress=iivanov@mycompany.com Getting CA Private Key $ openssl x509 -noout -issuer -subject -enddate -in client.pem issuer= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=My Company Root Certificate/emailAddress=it@mycompany.com subject= /C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/emailAddress=iivanov@mycompany.com notAfter=Jan 25 13:17:15 2016 GMT

Если необходим клиентский сертификат в формате PKCS12, создаем его:

$ openssl pkcs12 -export -in client.pem -inkey client.key -certfile root.pem -out iivanov.p12 Enter Export Password: Verifying - Enter Export Password:

Теперь можно использовать клиентский сертификат для работы с нашим сервером.

Настройка nginx на использование клиентских сертификатов

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

# Корневой сертификат(ы), которым(и) подписан клиентский ssl_client_certificate /etc/nginx/certs/clientroot.pem; # Возможные варианты: on | off | optional | optional_no_ca ssl_verify_client optional; # Глубина проверки цепочки сертификатов, которыми подписан клиентский ssl_verify_depth 2;

После этого надо перезагрузить настройки или сервер целиком и можно проверять работу.

Настройка Apache на использование клиентских сертификатов

Apache настраивается также через добавление дополнительных опций в секцию виртуального хоста:

# Директория, содержащая корневые сертификаты для проверки клиентов SSLCARevocationPath /etc/apache2/ssl.crl/ # или файл, содержащий сертификаты SSLCARevocationFile /etc/apache2/ssl.crl/ca-bundle.crl # Опция верификации клиента. Возможные варианты: # none, optional, require and optional_no_ca SSLVerifyClient require # Глубина просмотра цепочки подписей. По умолчанию 1 SSLVerifyDepth 2

Как видите, опции примерно такие же, как и для nginx, поскольку процесс проверки организован единообразно.

«Прослушка» информации о сертификате при помощи openssl

Для проверки взаимодействия сервера с клиентскими сертификатами можно проверить, устанавливается ли соединение с использованием TLS/SSL.

На стороне сервера запускаем прослушку порта при помощи openssl:

openssl s_server -accept 443 -cert server.pem -key server.key -state

На стороне клиента обращаемся к серверу, например, culr’ом:

curl -k https://127.0.0.1:443

В консоли со стороны сервера можно наблюдать процесс обмена информацией между сервером и клиентом.

Можно также использовать опции -verify [глубина проверки] и -Verify [глубина проверки]. Опция с маленькой буквы запрашивает у клиента сертификат, но он не обязан его предоставлять. С большой буквы — если сертификат не предоставлен, возникнет ошибка. Запустим прослушку со стороны сервера таким образом:

openssl s_server -accept 443 -cert server.pem -key server.key -state -Verify 3

Со стороны сервера ошибка выглядит так:

140203927217808:error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not return a certificate:s3_srvr.c:3287:

Со стороны клиента так:

curl: (35) error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure

Добавим с клиентской стороны сертификат и доменное имя (можно для проверки вписать в файл /etc/hosts имя хоста для адреса 127.0.0.1):

curl https://www.mycompany.com:443 --cacert root.pem --cert client.pem --key client.key

Теперь соединение пройдет успешно и можно устанавливать серверный сертификат на веб-сервер, клиентский отдать клиенту, и работать с ними.

Безопасность

При использовании SSL/TLS одним из основных методов является метод MITM (Man In The Middle), «человек посередине». Этот метод основывается на использовании серверного сертификата и ключа на каком-то узле, который будет прослушивать трафик и расшифровывать информацию, которой обмениваются сервер и клиент. Для организации прослушивания можно использовать, например, программу sslsniff. Поэтому корневой сертификат и ключ обычно желательно хранить на машине, которая не подключена к сети, для подписания приносить запросы на подпись на флэшке, подписывать и так же уносить. И, естественно, делать резервные копии.

В общих чертах именно так и используются цифровые сертификаты и протоколы TLS и SSL. Если есть вопросы/дополнения, пишите в комментарии.

Похожие посты:

  • PHP Warning: require_once(): open_basedir restriction in effect.
  • Параллельное выполнение в bash
  • Как записать терминальную сессию в Linux
  • Где в России можно сдать все LPIC и получить сертификат?
  • Несколько способов ускорить bash-скрипты
  • Создание сети для начинающих. Часть 2.
  • Генератор паролей на bash
  • Сохраняем входящую и исходящую почту в postfix
  • Мониторинг сети при помощи MTR
  • Корпоративная информационная культура
  • Нажмите здесь, чтобы поделиться контентом на Facebook. (Открывается в новом окне)
  • Нажмите, чтобы поделиться на LinkedIn (Открывается в новом окне)
  • Нажмите, чтобы поделиться на Reddit (Открывается в новом окне)
  • Нажмите, чтобы поделиться на Twitter (Открывается в новом окне)
  • Нажмите, чтобы поделиться записями на Tumblr (Открывается в новом окне)
  • Нажмите, чтобы поделиться записями на Pinterest (Открывается в новом окне)
  • Нажмите, чтобы поделиться записями на Pocket (Открывается в новом окне)
  • Нажмите, чтобы поделиться в Telegram (Открывается в новом окне)
  • Нажмите, чтобы поделиться в WhatsApp (Открывается в новом окне)
  • Нажмите, чтобы поделиться в Skype (Открывается в новом окне)

TLS и SSL: Необходимый минимум знаний : 29 комментариев

  1. cl-service.com12.07.2015 в 01:36 CSR клиент генерирует сам при заказе сертификата, где сохранять закрытый ключ также решает клиент, для выпуска сертификата нам не нужен закрытый ключ и клиент нам его никак не передает. Естественно если это происходит на обычном виртуальном, то у администраторов с root доступом к серверу есть доступ и к ключам, которые там хранятся.
  1. mnorin Автор записи 12.07.2015 в 01:52 Так и есть. Но некоторые сертификационные центры генерируют CSR сами, например, WoSign. Клиент и не должен передавать ключ, он должен передавать только sign request. На виртуальном сервере у администраторов хостинга есть доступ вообще ко всему. Но тут есть один момент. Если использовать ключевую фразу, то доступ к сертификату с ключом без нее бесполезен. Хотя тут есть и минус. При запуске сервера придется руками эту фразу вводить, поэтому сервер автоматически стартовать при старте системы не сможет.
  1. mnorin Автор записи 22.09.2016 в 12:25 Как говорится, отрицаешь — предлагай.
    Тема с описанной технологией связана напрямую, потому что именно то, что описано, в большинстве случаев и называют «Как работает SSL».
    Ну и RFC по заявке читателя:
    RFC 6101: The Secure Sockets Layer (SSL) Protocol Version 3.0
    RFC 5246: The Transport Layer Security (TLS) Protocol Version 1.2
    И да, тебе тоже добра.
  1. mnorin Автор записи 07.10.2016 в 04:31 Какой-то определенной программы для этих целей я еще не встречал, но пару советов по этому поводу могу дать.
    Можно использовать, например, Chromium или Google Chrome. Возьмем, например, сайт https://www.thawte.com/ — компания, которая собственно цифровымисертификатами и занимается.
    В адресной строке будет написано название компании и зеленый замочек. Это значит, что организация проверена, это как минимум SSL OV.
    Если кликнуть на замочек, а в выпавшем окошке «Details», а затем «View Certificate», то можно увидеть информацию о сертификате. Для Thawte сертификат подписан следующим сертификатом: «thawte Extended Validation SHA256 SSL CA», а сертификат для click.alfabank.ru тоже подписан Thawte, но другим сертификатом. Это «thawte EV SSL CA — G3», то есть они тоже проходили Extended Validation.
    Как-то так.
  1. xfiles10.06.2017 в 00:11 зеленую строку с названием организации можно получить только с EV сертификатом ?
  1. Maxim Norin Автор записи 11.06.2017 в 11:30 Насколько я помню, да
  1. Maxim Norin Автор записи 11.01.2017 в 11:34 Я лучше дам ссылку на technet.microsoft.com , раздел «Key exchange». В статье написано, естественно, упрощенно, чтобы просто объяснить принцип работы, при этом не сильно вдаваясь в детали.
  1. Maxim Norin Автор записи 15.01.2017 в 21:34 Вообще различия есть. Корневой сертификат обычно самоподписанный. И он используется исключительно для подписи других сертификатов. Серверный сертификат обычно подписан либо корневым, либо промежуточным, который подписан корневым. Корневые сертификаты распространяются публично в составе обновлений операционных систем, серверные не распространяются. Ну, а с точки зрения криптографии это, в принципе, одно и то же.
  1. Maxim Norin Автор записи 26.01.2017 в 04:03 Добрый день.
    Это не должно так работать однозначно. Обычно в нормальных сертификатах указываются ДНС имена, для которых он выдан (с www и без www).
    То, что вы описываете, бывает либо с сертификатами, в которых DNS-имена не указаны, либо с wildcard-сертификатами.
    Я думаю, что это кривые сертификаты и настройки у хостера все-таки.
    Плюс, возможно на самом сайте захардкожен протокол http в разных местах, поэтому контент отображается частично. Такие проблемы решаются либо проксированием, либо правкой сайта.
  1. Виталий26.01.2017 в 04:12 Спасибо, Максим.
    То, что сайт в одном из компонентов стал криво отображаться из-за захардкоженного http, я понял. Но оказалось, что и в админку стало не попасть для того, чтобы проверить эти косяки )))
    А техподдержка хостера предлагает восстановление из бэкапа ))) Вместо того, чтобы, по моему пониманию, разобраться с настройками сервера, который, несмотря на удаление сертификата, по-прежнему инициирует https-соединение.
    Пока спорил с ними, и читал про SSL, во время чего и попал к Вам на сайт, немного понял, как это должно работать, и что на деле работает некорректно.
    Спасибо за подтверждение моих предположений. Мне следует осваивать тему глубже.
    С уважением,
    Виталий
  1. Maxim Norin Автор записи 10.07.2017 в 23:18 Добрый день. Нужно сгенерировать новые сертификаты с указанием IP в качестве имени сервера (поле CN), оно же FQDN. С уже сгенерированными сертификатами ничего сделать не получится.
  1. Сергей10.07.2017 в 23:41 Что, помимо сертификата, необходимо для доступа по https? Настройка веб-сервера? Ткните в сторону нужного направления.
  1. Maxim Norin Автор записи 10.07.2017 в 23:51 Сертификат, ключ, цепочка сертификатов, которыми подписан сертификат сервера (чаще всего), и да, настройка веб-сервера, нужно в настройках указать путь к файлу сертификата, ключа, иногда к цепочке. Но обычно цепочка просто дописывается в сертификат сервера. В статье как раз есть примеры настройки Nginx и Apache
  1. Maxim Norin Автор записи 05.11.2017 в 02:05 Добрый день.
    Вариантов очень много. С учетом той информации, которую вы сообщили, вот несколько:
    1) Вирусы на вашем компьютере
    2) Сетевые проблемы у провайдера
    3) Происходит фоновое скачивание чего-то (обновления Windows, например, торренты, еще что-то)
    4) Активная работа фоновых приложений (тот же антивирус) или слабый процессор
    5) Давно не перезагружались
    Более точно сложно сказать что-то, вы даже не сказали, о какой операционной системе и каком браузере речь. Тем не менее, очень маленькие шансы, что это связано с самим TLS как-то, больше похоже либо на высокую нагрузку на процессор или сеть, либо на проблему сетевого характера, либо на вирус/троян/зловредное расширение для браузера. Сайты через HTTP открываются быстро?
  1. Maxim Norin Автор записи 28.11.2017 в 01:00 Да, влияет, конечно, как и на передачу по любому другому протоколу, работающему поверх TCP/IP. Потеря пакетов приводит к повторной их передаче как раз на уровне TCP/IP, поэтому разница не должна быть заметна. В теории возможны какие-то дополнительные задержки на стороне отправителя или получателя, связанные с необходимостью кодирования/декодирования пнредаваемых и получаемых данных
  1. xfiles30.11.2017 в 11:21 Дополню ответ автора. Если речь о dial-up скорости и существенные потери, например 5-10%, то http легче влетит в браузер чем https, т.к. на https затрачивается время на подготовку соединенияи. На очень медленных скоростях это будет заметно.
    По теме: https://stackoverflow.com/questions/149274/http-vs-https-performance
  1. Maxim Norin Автор записи 30.11.2017 в 11:40 Полностью поддерживаю
  1. Maxim Norin Автор записи 01.03.2018 в 21:27 Здравствуйте. Без правильного ключа ничего подписать не получится. А ключ, в отличие от сертификата, нигде не публикуется.

SSL/TLS

SSL (Secure Sockets Layer) и TLS (Transport Level Security) — криптографические протоколы, обеспечивающие защищенную передачу данных в компьютерной сети. Они широко используются в веб-браузерах, а также при работе с электронной почтой, обмене мгновенными сообщениями и в IP-телефонии.

Соединение, защищенное протоколом TLS, обладает одним или несколькими следующими свойствами:

  • Безопасность: симметричное шифрование защищает передаваемую информацию от прочтения посторонними лицами.
  • Аутентификация: «личность» участника соединения можно проверить с помощью асимметричного шифрования.
  • Целостность: каждое сообщение содержит код (Message Authentication Code, MAC), с помощью которого можно проверить, что данные не были изменены или потеряны в процессе передачи.

Так как большинство протоколов связи могут быть использованы как с TLS/SSL, так и без него, при установке соединения необходимо явно указать серверу, хочет ли клиент устанавливать TLS. Один способ добиться этого — использовать порт, по которому соединение всегда устанавливается с использованием TLS (например, 443 для HTTPS). Другой способ — использовать специальную команду серверу от клиента переключить соединение на TLS (например, STARTTLS для протоколов электронной почты).

История SSL

SSL изначально разработан компанией Netscape для добавления протокола — HTTPS в свой веб-браузер Netscape Navigator, потому что компания считала, что безопасное соединение между клиентом и сервером в первую очередь послужит успехом развитию Интернета как инструмента бизнеса.

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

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

Устройство протокола SSL

Фаза рукопожатия

Протокол SSL размещается между двумя протоколами: протоколом, который использует программа-клиент (HTTP, FTP, LDAP, TELNET и т.д.) и транспортным протоколом TCP/IP. SSL защищает данные, выступая в роли фильтра для обеих сторон и передает их далее на транспортный уровень.

Работу протокола можно разделить на два уровня:

  • Слой протокола подтверждения подключения (Handshake Protocol Layer)
  • Слой протокола записи

Первый слой, в свою очередь, состоит из трех подпротоколов:

  • Протокол подтверждения подключения (Handshake Protocol)
  • Протокол изменения параметров шифра (Cipher Spec Protocol)
  • Предупредительный протокол (Alert Protocol)

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

Протокол изменения параметров шифра используется для изменения данных ключа (keying material) — информации, которая используется для создания ключей шифрования. Протокол состоит всего из одного сообщения, в котором сервер говорит, что отправитель хочет изменить набор ключей.

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

Протокол записи

Протокол записи (Record Layer) — это уровневый протокол. На каждом уровне сообщения включают поля для длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, разумно сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента.

Существует четыре протокола записи:

  • Протокол рукопожатия (handshake protocol);
  • Протокол тревоги (alert protocol);
  • Протокол изменения шифра (the change cipher spec protocol);
  • Протокол приложения (application data protocol);

Принцип работы SSL

Фаза рукопожатия

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

Клиент инициирует рукопожатие посылая “hello”-сообщение серверу. Такое сообщение содержит список алгоритмов симметричного шифрования (cipher specs), поддерживаемых клиентом. Сервер отвечает похожим “hello”-сообщением, выбрав при этом наиболее подходящий алгоритм шифрования из полученного списка. Далее сервер отправляет сертификат, который содержит его публичный ключ.

Сертификат — это набор данных, который подтверждает подлинность. Подтвержденная третья сторона, известная как центр сертификации (CA), генерирует сертификат и проверяет его подлинность. Чтобы получить сертификат сервер должен использовать безопасные каналы для отправки своего публичного ключа в центр сертификации. Он генерирует сертификат, который содержит его собственный ID, ID сервера, публичный ключ сервера и другую информацию. А также центр сертификации создает отпечаток (digest) сертификата, который, по сути, является контрольной суммой. Далее центр сертификации создает подпись сертификата (certificate signature), которая формируется путем шифрования отпечатка сертификата приватным ключом центра сертификации.

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

Фаза рукопожатия завершается отправкой “finished”-сообщений, как только обе стороны готовы начать использование секретного ключа. Начинается фаза передачи данных, в ходе которой каждая сторона разбивает исходящие сообщения на фрагменты и прикрепляет к ним коды авторизации сообщений MAC (message authentication code). Код авторизации сообщения это зашифрованный отпечаток, вычисленный на основе содержимого сообщений. Из соображений безопасности, он не совпадает с секретным ключом и вычисляется вместе с секретным ключом на стадии рукопожатия. Для получения полноценного SSL пакета каждая из сторон объединяет данные фрагмента, код авторизации сообщения, заголовки сообщения и шифруют с использованием секретного. При получении пакета, каждая из сторон расшифровывает его и сверяет полученный код авторизации сообщения со своим. Если они не совпадают, то пакет был подделан.

Цифровые сертификаты

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

Способы получения SSL-сертификата:

  • Использовать сертификат, выданный центром сертификации (Certification authority)
  • Использовать самоподписанный сертификат
  • Использовать «пустой» сертификат

Самоподписанный сертификат — сертификат, созданный самим пользователем — в этом случае издатель сертификата совпадает с владельцем сертификата. «Пустой» сертификат — сертификат, содержащий фиктивную информацию, используемую в качестве временной для настройки SSL и проверки его функциональности в данной среде.

Хэширование

Хеш-значение является идентификатором сообщения, его размер меньше размера оригинального сообщения. Самыми известными хеш-алгоритмами являются MD5 (Message Digest 5), который создает 128-битное хеш-значение, SHA-1 (Standard Hash Algorithm), создающий 160-битное хеш-значение, SHA-2 и SHA-3. Результат работы алгоритма хеширования — значение, которое используется для проверки целостности передачи данных.

Шифрование

Существует два основных способа шифрования данных: симметричный ключ (общий секретный ключ) и асимметричный ключ (открытый ключ).

Открытый ключ

Шифрование открытым ключом

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

Любой пользователь может получить открытый ключ по назначению и использовать его для шифрования данных, расшифровать которые может только пользователь, владеющий секретным ключом. (RSA)

Если заголовок шифрует данные, используя свой секретный ключ, каждый может расшифровать данные, используя соответствующий открытый ключ. Именно это является основой для цифровых подписей. (DSA)

RSA — самый распространенный алгоритм шифрования с использованием асимметричных ключей.

Секретный ключ

Шифрование симметричным ключом

При шифровании секретным ключом используется один и тот же ключ для шифрованных данных. Если стороны хотят обменяться зашифрованными сообщениями в безопасном режиме, то у обеих сторон должны быть одинаковые симметричные ключи. Такой тип шифрования используется для большого объёма данных. Обычно используются алгоритмы DES, 3-DES, RC2, RC4 и AES.

Комбинированный подход

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

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

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

Аутентификация и обмен ключами

SSL поддерживает 3 типа аутентификации:

  • аутентификация обеих сторон (клиент — сервер),
  • аутентификация сервера с неаутентифицированным клиентом,
  • полная анонимность.

Обычно для аутентификации используются алгоритмы: RSA, DSA, ECDSA.

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

Главная цель процесса обмена ключами — это создание секрета клиента (pre_master_secret), известного только клиенту и серверу. Секрет (pre_master_secret) используется для создания общего секрета (master_secret). Общий секрет необходим для того, чтобы создать сообщение для проверки сертификата, ключей шифрования, секрета MAC (message authentication code) и сообщения «finished». Отсылая сообщение «finished», стороны указывают, что они знают верный секрет (pre_master_secret).

Анонимный обмен ключами

Полностью анонимная сессия может быть установлена при использовании алгоритма RSA или Диффи-Хеллмана для создания ключей обмена. В случае использования RSA клиент шифрует секрет (pre_master_secret) с помощью открытого ключа несертифицированного сервера. Открытый ключ клиент узнает из сообщения обмена ключами от сервера. Результат посылается в сообщении обмена ключами от клиента. Поскольку перехватчик не знает закрытого ключа сервера, то ему будет невозможно расшифровать секрет (pre_master_secret). При использовании алгоритма Диффи-Хеллмана открытые параметры сервера содержатся в сообщении обмена ключами от сервера, и клиенту посылают в сообщении обмена ключами. Перехватчик, который не знает приватных значений, не сможет найти секрет (pre_master_secret).

Аутентификация и обмен ключами при использовании RSA

В этом случае обмен ключами и аутентификация сервера может быть скомбинирована. Открытый ключ также может содержаться в сертификате сервера или может быть использован временный ключ RSA, который посылается в сообщении обмена ключами от сервера. Когда используется временный ключ RSA, сообщения обмена подписываются server’s RSA или сертификат DSS. Сигнатура содержит текущее значение сообщения Client_Hello.random, таким образом, старые сигнатуры и старые временные ключи не могут повторяться. Сервер может использовать временный ключ RSA только однажды для создания сессии. После проверки сертификата сервера клиент шифрует секрет (pre_master_secret) при помощи открытого ключа сервера. После успешного декодирования секрета (pre_master_secret) создается сообщение «finished», тем самым сервер демонстрирует, что он знает частный ключ, соответствующий сертификату сервера.

Когда RSA используется для обмена ключами, для аутентификации клиента используется сообщение проверки сертификата клиента. Клиент подписывается значением, вычисленным из master_secret и всех предшествующих сообщений протокола рукопожатия. Эти сообщения рукопожатия содержат сертификат сервера, который ставит в соответствие сигнатуре сервера сообщение Server_Hello.random, которому ставит в соответствие сигнатуру текущему сообщению рукопожатия.

Аутентификация и обмен ключами при использовании протокола Диффи-Хеллмана

В этом случае сервер может также поддерживать содержащий конкретные параметры алгоритм Диффи-Хеллмана или может использовать сообщения обмена ключами от сервера для посылки набора временных параметров, подписанных сертификатами DSS или RSA. Временные параметры хэшируются с сообщением hello.random перед подписанием для того, чтобы злоумышленник не смог совершить повтор старых параметров. В любом случае клиент может проверить сертификат или сигнатуру для уверенности, что параметры принадлежат серверу.

Если клиент имеет сертификат, содержащий параметры алгоритма Diffie-Hellman, то сертификат также содержит информацию, требующуюся для того, чтобы завершить обмен ключами. В этом случае клиент и сервер должны будут сгенерировать одинаковые Diffie-Hellman результаты (pre_master_secret) каждый раз, когда они устанавливают соединение. Для того, чтобы предотвратить хранение секрета (pre_master_secret) в памяти компьютера на время дольше, чем необходимо, секрет должен быть переведен в общий секрет (master_secret) настолько быстро, насколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами.

Восстановление сессии

Фаза рукопожатия

Создатели SSL знали, что алгоритмы шифрования открытым ключом вычислительно сложные, и клиент, создающий несколько новых соединений к одному и тому же серверу в течение короткого промежутка времени может сильно нагрузить сервер, что приведет к заметным временным задержкам ответа. Однако, если клиент и сервер уже установили соединение, то ему будет соответствовать уникальный идентификатор сессии, позволяющий ссылаться на него и использовать такой же секретный ключ при последующих соединениях в рамках некоторого временного отрезка. Безусловно, такой подход привносит определенный риск в безопасность соединения. Поэтому, если необходимо, клиент может пересоздать новые идентификатор и секретный ключ для данной сессии. Microsoft’s Internet Explorer, например, проделывают эту операцию каждые 2 минуты.

Администрирование

Обслуживание сертификатов и ключей

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

Хранилище идентификаторов сессий

Клиент и сервер обязаны хранить идентификаторы сессий и связанные с ними секретные ключи для использования во время восстановления соединения.

SSL 1.0, 2.0, 3.0 и TLS

Версия 1.0 никогда не была обнародована. Версии 2.0 была выпущена в феврале 1995 года, но содержала много недостатков по безопасности, которые привели к разработке SSL 3.0 версии.

Как только различные компании (Microsoft) начали предпринимать попытки разработки собственных безопасных протоколов транспортировки, IETF решило вмешаться и определить стандарт протокола шифрования. Впоследствии, при поддержке множества компаний, на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS 1.0. Его также часто называют SSL 3.1.

Хотя TLS и SSL имеют существенные различия в реализации, разработчики обычно замечают лишь немногие из них, а конечные пользователи вовсе их не различают. Тем не менее TLS 1.0 и SSL 3.0 несовместимы. Значительное различие состоит в том, что TLS требует определенные алгоритмы шифрования, которые SSL не поддерживает. Таким образом TLS сервер должен “откатиться” (downgrade) до SSL 3.0 для работы с клиентами, использующими SSL 3.0.

Принцип работы TLS

Протокол TLS делится на два слоя: TLS Record и TLS Handshake.

Подтверждение связи (handshake)

Схема подтверждения связи

  1. Клиент посылает сообщение ClientHello, указывающее версию SSL или TLS и поддерживаемые клиентом методы шифрования (англ. CipherSuite). Это сообщение также содержит случайное число (набор байт), которое используется в последующих вычислениях. Протокол также позволяет указать поддерживаемые клиентом методы сжатия данных.
  2. Сервер отвечает сообщением ServerHello, которое содержит метод шифрования, выбранный сервером из списка, предложенного клиентом, а также идентификатор сессии и еще одно случайное число. Также сервер посылает свой цифровой сертификат. Если серверу нужен сертификат для аутентификации клиента, на этом шаге он может послать клиенту запрос такого сертификата.
  3. Клиент проверяет сертификат сервера.
  4. Клиент отправляет случайное число, которое клиент и сервер используют для шифрования последующих сообщений. Сама строка из байт шифруется публичным ключом сервера.
  5. Если сервер потребовал у клиента сертификат, клиент отсылает набор байт, зашифрованный его секретным ключом, и свой цифровой сертификат, или оповещение об отсутствии сертификата.
  6. Сервер проверяет сертификат клиента.
  7. Клиент и сервер отправляют друг другу сообщение ChangeCipherSpec, объявляя об изменении режима передачи данных с незащищенного на защищенный.
  8. Клиент отправляет сообщение Finished, зашифрованное секретным ключом, и таким образом завершает подтверждение связи со своей стороны.
  9. Аналогичные действия производит сервер.
  10. На протяжении данной сессии клиент и сервер могут обмениваться сообщениями, зашифрованными секретным ключом.
Возобновление сессии
  1. Клиент посылает сообщение ClientHello, используя ID сессии, которую нужно возобновить.
  2. Сервер проверяет, есть ли у него в кэше соответствующий идентификатор. Если есть и сервер способен возобновить сессию, он отсылает клиенту сообщение ServerHello с этим же ID сессии. Если нет, сервер генерирует новый ID сессии и выполняет процедуру handshake с клиентом.
  3. Клиент и сервер обмениваются сообщениями ChangeCipherSpec, а затем Finished.
  4. Передача данных по защищенному каналу возобновляется.
Протокол записи (TLS Record)

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

  • Разбиение исходящих сообщений на блоки нужного размера и «склеивание» входящих сообщений.
  • Сжатие исходящих сообщений и распаковку входящих (используется не всегда).
  • Применение кода аутентификации к исходящим сообщениям и проверку входящих с помощью MAC.
  • Шифрование исходящих сообщений и дешифровку входящих.

После обработки протоколом TLS Record зашифрованные данные передаются на слой TCP для передачи.

Состав записи

Схема записи

  • Content type: тип сообщения — подтверждение связи (22), обычное сообщение (23) или оповещение (21).
  • Version: версия SSL/TLS.
  • Length: длина оставшейся части сообщения.
  • Payload: собственно зашифрованные данные.
  • MAC: код аутентификации.
  • Padding: «отступ» для получения нужного размера сообщения.

Цифровые сертификаты (стандарт X.509)

Структура X.509

  • Удобный способ показать, что кто-то владеет публичным ключом.
  • Выпускаются центрами сертификации (Certificate Authority, CA): GlobalSign, Comodo и др.
  • PKI (public key infrastructure) — механизм, регулирующий распространение и использование сертификатов (включая создание, отзыв и проверку подлинности).
  • Список доверенных CA поддерживается приложением (у браузеров свои списки).
  • Сертификаты подписываются другими сертификатами, что повышает надежность.
  • Сертификат может быть отозван. Система поддерживает список таких сертификатов (Certificate Revocation List, CRL). На стороне CA список обновляется каждые несколько часов.

Получение сертификата

  1. Пользователь генерирует ключ и посылает запрос серверу CA.
  2. CA отвечает сообщением со своим сертификатом.
  3. Пользователь собирает данные, необходимые для выдачи сертификата (email, отпечаток ключа и т.д.).
  4. Пользователь отправляет данные в CA, зашифровав их публичным ключом CA.
  5. CA проверяет полученные данные и отправляет сертификат пользователю.

Структура сертификата

  • Собственно сертификат
    • Версия
    • Серийный номер
    • Эмитент (тот, кто выпустил сертификат)
    • Субъект
    • Публичный ключ субъекта
    • Период действия
    • Дополнительные поля

    Меры безопасности в TLS

    • Защита от downgrade-атаки — понижения версии протокола к предыдущей (менее защищённой) версии или менее надёжному алгоритму шифрования;
    • Нумерация последовательных записей приложения и использование порядкового номера в коде аутентификации сообщения (MAC);
    • Использование ключа в идентификаторе сообщения (только владелец ключа может сгенерировать код аутентификации сообщения).
    • Сообщение, которым заканчивается подтверждение связи («Finished»), содержит хэш всех handshake-сообщений, отправленных обеими сторонами, что позволяет проверить подлинность выбранных параметров TLS-соединения.
    • Псевдослучайная функция делит подаваемые ей на вход данные пополам, применяет к половинкам разные хэш-алгоритмы (MD5 и SHA-1), а затем XOR’ит результаты для получения MAC. Это повышает безопасность в случае, если в одном из алгоритмов обнаружится уязвимость.

    Ключевые отличия SSL и TLS

    • Аутентификация сообщений: в TLS используется HMAC, работающий с любой хэш-функцией (а не только с MD5 или SHA, как в SSL).
    • Генерация ключа: в TLS при создании ключа используется псевдослучайная функция стандарта HMAC; в SSL — RSA, Diffie-Hellman или Fortezza/DMS.
    • Проверка сертификата: в SSL проверка требует передачи сложной последовательности сообщений; в TLS информация о проверке полностью передается в сообщениях во время handshake.
    • Методы шифрования: SSL поддерживает только алгоритмы RSA, Diffie-Hellman и Fortezza/DMS. В TLS отказались от поддержки Fortezza/DMS, но возможно добавление новых методов шифрования в последующих версиях.

    Виды возможных атак

    • Атака по словарю
    • Атака отражением
    • Атака протокола рукопожатия
    • Взлом SSL-соединений внутри ЦОД
    • BEAST атака
    • Раскрытие шифров
    • Атака «злоумышленник посередине»
    • THC-SSL-DOS
    • SSLstrip

    Источники информации

    • SSL and TLS: A Beginner’s Guide
    • Wikipedia: Secure Sockets Layer
    • Inside SSL: The Secure Sockets Layer Protocol
    • Tanenbaum-Structured-Computer-Organization-6th-Edition
    • SSL/TLS Strong Encryption: An Introduction
    • Wikipedia: Transport Layer Security
    • Microsoft Developer Resources: Transport Layer Security Protocol
    • IBM Knowledge Center: Cryptographic security protocols: SSL and TLS
    • Thomas, Stephen. SSL and TLS Essentials: Securing the Web.

    Полезные материалы

    • Криптографический пакет с открытым исходным кодом для работы с SSL/TLS. Позволяет создавать ключи RSA, DH, DSA и сертификаты X.509, подписывать их, формировать CSR и CRT
    • How To Create an SSL Certificate on Nginx for Ubuntu 14.04
    • Usage Statistics and Market Share of SSL Certificate Authorities

    �� Как проверить сервер на поддержку TLS на Linux

    Мануал

    Автор cryptoparty На чтение 3 мин Опубликовано 30.03.2021

    TLS – это аббревиатура от Transport Layer Security.

    TLS обеспечивает безопасную связь между компьютерами в Интернете.

    На момент написания этой статьи TLS 1.3 является последней версией.

    В этом руководстве объясняется, как проверить, какие версии TLS ваш сервер или веб-сайт поддерживает в системе Linux, а также используемый алгоритм шифрования (Cipher).

    Предпосылки

    • Машина с Linux
    • Пользователь с привилегиями sudo

    Проверим поддержку TLS с помощью Openssl

    Openssl – это инструмент с открытым исходным кодом для реализации безопасного обмена данными в Интернете.

    Инструмент openssl доступен во всех основных дистрибутивах Linux.

    Если инструмент openssl еще не установлен на вашем компьютере с Linux, вы можете установить его следующим образом:

    В дистрибутивах на основе Ubuntu / Debian:
    $ sudo apt install openssl
    В дистрибутивах на основе CentOS / Red Hat:
    $ sudo yum install openssl

    Теперь, чтобы проверить поддержку TLSv1.3 на вашем сервере или веб-сайте, выполните следующую команду.

    $ sudo openssl s_client -connect itsecforu.local:443 -tls1_3

    Примечание. Используйте доменное имя сервера или веб-сайта, который вы пытаетесь протестировать, вместо «itsecforu.local».

    Также вы можете заменить -tls1_3 на:

    • -tls1_2 для TLSv1.2
    • -tls1_1 для TLSv1.1
    • -tls1 для TLSv1

    Если в выходных данных команды вы видите цепочку сертификатов, а также сведения об успешном рукопожатии, то указанная версия TLS поддерживается.

    На примере TLSv1.2

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

    $ openssl s_client -cipher 'AES256-GCM-SHA384' -connect itsecforu.local:443

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

    Проверим поддержку TLS с помощью Nmap

    Nmap – это инструмент, который в основном используется для поиска доступных служб и портов в сети.

    Выполните команду показанную ниже, чтобы установить Nmap.

    В дистрибутивах на основе Ubuntu / Debian:
    $ sudo apt install nmap
    В дистрибутивах на основе CentOS / Red Hat:
    $ sudo yum install nmap

    После установки вы можете использовать инструмент nmap для проверки вашего сервера или веб-сайта на поддержку TLS следующим образом.

    $ nmap --script ssl-enum-ciphers -p 443 itsecforu.local

    Ниже приведен пример вывода, показывающий версию TLS и шифры, поддерживаемые на моем сервере.

    Заключение

    В этом руководстве мы рассмотрели, как проверить, поддерживает ли сервер или веб-сайт TLS, с помощью openssl и nmap.

    Тест TLS может определить степень безопасности вашего сайта.
    Мы надеемся, что эта информация окажется для вас очень полезной.

    Пожалуйста, не спамьте и никого не оскорбляйте. Это поле для комментариев, а не спамбокс. Рекламные ссылки не индексируются!

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

    Поддержать нас

    • Аудит ИБ (49)
    • Вакансии (12)
    • Закрытие уязвимостей (110)
    • Книги (27)
    • Мануал (2 385)
    • Медиа (66)
    • Мероприятия (39)
    • Мошенники (23)
    • Обзоры (835)
    • Обход запретов (34)
    • Опросы (3)
    • Скрипты (122)
    • Статьи (366)
    • Философия (133)
    • Юмор (19)

    Наш Telegram

    Социальные сети
    Поделиться

    Anything in here will be replaced on browsers that support the canvas element

    • �� Как проверить IPv4-адреса в скрипте 25.12.2023

    Проверка IP-адресов – распространенная задача в сетевом и системном администрировании. В этом уроке мы узнаем, как проверить IPv4-адреса с помощью скрипта оболочки. Это особенно полезно в ситуациях, когда нужно убедиться, что пользовательский ввод или данные из другого источника имеют правильный формат IPv4. IPv4 против IPv6: В чем разница между IPv4 и IPv6 Понимание формата адресов […]

    Deep Packet Inspection (DPI) – это передовая техника сетевой фильтрации. Если традиционные методы мониторинга и фильтрации сети позволяют лишь поверхностно изучить заголовки пакетов, то DPI проникает глубже, тщательно анализируя фактическое содержание данных в пакетах. Такая детальная проверка позволяет получить полное представление о потоке данных, что дает возможность определить не только тип или категорию данных, но […]

    Обратный инжиниринг, термин, часто ассоциируемый с технологическими инновациями и решением проблем, включает в себя сложный процесс раскрытия дизайна, структуры или функциональности продукта, системы или части технологии, чтобы понять их внутреннюю работу. Эта многогранная дисциплина играет ключевую роль в различных отраслях промышленности, способствуя инновациям, обеспечивая совместимость и способствуя продвижению вперед. Сегодня обратный инжиниринг услуги выполняют одни из лучших […]

    Компания “Автозайм”: надежное залоговое кредитование в СПб и по всей России “Автозайм” представляет собой современный автоломбард, который оперирует в различных городах России, включая Санкт-Петербург – https://spb.carzaem.ru/autolombard. Компания специализируется на предоставлении кредитов под залог автомобилей, предлагая клиентам удобные и прозрачные условия. Основные преимущества Быстрый и простой процесс. Процедура получения займа в “Автозайм” максимально упрощена. Клиенты могут подать […]

    Мы рассмотрим подписание коммитов и тегов ключом GPG, а также отправку и получение открытых ключей GPG на сервер ключей для проверки. Шпаргалка Неподписанный коммит: Подписанный коммит: Если ваши адреса электронной почты git и gpg-ключа отличаются, это приведет к неудаче, пока вы не настроите свой git signingkey Неподписанный тег: Подписанный тег: Переопределение параметров конфигурации автоподписания: Импорт […]

    Похожие публикации:
    1. Как открыть svg в фотошопе
    2. Как подключить базу данных к java
    3. Как подключить джойстик ps4 к компьютеру
    4. Что такое макросы в мышке

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *