TLS и SSL: Необходимый минимум знаний
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, а тот в свою очередь в 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 []:[email protected] 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/[email protected] 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/[email protected] 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 []:[email protected] 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/[email protected] 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/[email protected] subject= /C=RU/ST=N/A/L=Saint-Petersburg/O=My Company/OU=IT Service/CN=www.mycompany.com/[email protected] 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 порт. Конфиг будет выглядеть примерно так:
<IfModule mod_ssl.c>
<VirtualHost *:443>
ServerAdmin [email protected]
DocumentRoot /var/www
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/>
Options Indexes FollowSymLinks MultiViews
AllowOverride None
Order allow,deny
allow from all
</Directory>
ScriptAlias /cgi-bin/ /usr/lib/cgi-bin/
<Directory "/usr/lib/cgi-bin">
AllowOverride None
Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
Order allow,deny
Allow from all
</Directory>
ErrorLog ${APACHE_LOG_DIR}/error.log
LogLevel warn
CustomLog ${APACHE_LOG_DIR}/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
<FilesMatch "\.(cgi|shtml|phtml|php)$">
SSLOptions +StdEnvVars
</FilesMatch>
<Directory /usr/lib/cgi-bin>
SSLOptions +StdEnvVars
</Directory>
BrowserMatch "MSIE [2-6]" \
nokeepalive ssl-unclean-shutdown \
downgrade-1.0 force-response-1.0
BrowserMatch "MSIE [17-9]" ssl-unclean-shutdown
</VirtualHost>
</IfModule>При этом надо сделать еще кое-что. Найти в файле httpd.conf, или apache2.conf, или ports.conf, в зависимости от системы, такой участок конфига:
<IfModule mod_ssl.c>
Listen 443
</IfModule>
Если такого условия нет, его надо добавить в конфиг. И еще одно: Надо добавить строку
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 []:[email protected] 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/[email protected] 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/[email protected] subject= /C=RU/ST=N/A/L=Saint-Petrersburg/O=My Company/OU=Engineering/CN=Ivan Ivanov/[email protected] 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. Если есть вопросы/дополнения, пишите в комментарии.
- Нажмите здесь, чтобы поделиться контентом на Facebook. (Открывается в новом окне)
- Нажмите, чтобы поделиться на LinkedIn (Открывается в новом окне)
- Нажмите, чтобы поделиться на Reddit (Открывается в новом окне)
- Нажмите, чтобы поделиться на Twitter (Открывается в новом окне)
- Нажмите, чтобы поделиться записями на Tumblr (Открывается в новом окне)
- Нажмите, чтобы поделиться записями на Pinterest (Открывается в новом окне)
- Нажмите, чтобы поделиться записями на Pocket (Открывается в новом окне)
- Нажмите, чтобы поделиться в Telegram (Открывается в новом окне)
- Нажмите, чтобы поделиться в WhatsApp (Открывается в новом окне)
- Нажмите, чтобы поделиться в Skype (Открывается в новом окне)
Ssl что это такое. Принципы шифрования сертификатом
Добрый день, уважаемые подписчики, уверен, что в подавляющем большинстве вы слышали такие слова как сертификат безопасности или шифрования, либо SSL сертификат, и я уверен, что большинство из вас даже знает их назначение., если нет, то я вам об этом очень подробно расскажу на личных примерах, все как полагается, после этого вы уже будите более тонко понимать все рубежи безопасности, которые предоставляют нам SSL сертификаты, без них сейчас уже не возможно представить современный IT мир, с его банковскими переводами, электронной почтой smime или интернет магазинами.
Что такое SSL и TLS
Secure Socket Layer или ssl это, технология, призванная сделать доступ к сайтам более надежным и безопасным. Сертификат шифрования позволяет, надежно защитить трафик, передаваемый между браузером пользователя и веб ресурсом (сервером), к которому браузер обращается, все это происходит за счет протокола https. Сделано, это все после того, как бурное развитие интернета привело к огромному количеству сайтов и ресурсов, которые требуют от пользователя ввод личных, персональных данных:
- Пароли
- Номера кредитных карт
- Переписка
Именно эти данные и являются добычей для хакеров, сколько уже было громких дел, с кражей персональной информации и сколько еще будет, ssl сертификат шифрования, призван это минимизировать. Разработкой технологии SSL выступила компания Netscape Communications, позднее она представила Transport Layer Security или проще TLS, это протокол основанный по спецификации SSL 3.0. И Secure Socket Layer и Transport Layer Security призваны обеспечить передачу данных между двумя узлами по интернету.
SSL и TLS не имеют принципиальных различий в своей работе, могут даже быть использованы на одном сервере одновременно, делается это исключительно из соображений обеспечения работы новых устройств и браузеров, так и устаревших, где Transport Layer Security не поддерживается.
Если рассматривать современный интернет, то там в качестве сертификата безопасности сервера и шифрования используется TLS, просто знайте это
Для примера откройте сайт Яндекса, я это делаю в Google Chrome, там на против адресной строки есть значок замка, щелкаем по нему. Тут будет написано, что подключение к веб-сайту защищено и можно нажать подробнее.
сразу видим значок Secure TLS connection, как я и говорил, большая часть интернет ресурсов именно на этой технологии. Давайте посмотрим сам сертификат, для этого жмем View certificate.
В поле о сведениях о сертификате видим его предназначение:
- Обеспечивает получение идентификации от удаленного компьютера
- Подтверждает удаленному компьютеру идентификацию вашего компьютера
- 1.2.616.1.113527.2.5.1.10.2
История версий сертификатов шифрования
Всегда нужно знать историю, как сертификат шифрования эволюционировал и какие у него выходили версии. Так как зная это и принцип работы, будет проще искать решение проблем.
- SSL 1.0 > данная версия в народ так и не попала, причины, возможно нашли его уязвимость
- SSL 2.0 > эта версия ssl сертификата была представлена в 1995 году, на стыке тысячелетий, она так же была с кучей дыр безопасности, сподвигнувшие компанию Netscape Communications к работе над третье версией сертификата шифрования
- SSL 3.0 > пришел на смену SSL 2.0 в 1996 году. Стало это чудо развиваться и в 1999 году крупные компании Master Card и Visa купили коммерческую лицензию на его использование. Из 3.0 версии появился TLS 1.0
- TLS 1.0 > 99 год, выходит обновление SSL 3.0 под названием TLS 1.0, проходит еще семь лет, интернет развивается и хакеры не стоят на месте, выходит следующая версия.
- TLS 1.1 > 04.2006 это его отправная точка, было исправлено несколько критичных ошибок обработки, а так же появилась защита от атак, где делался режим сцепления блоков шифротекста
- TLS 1.2 > появился в августе 2008
- TLS 1.3 > появится в конце 2016 года
Принцип работы TLS и SSL
Давайте разбираться как работает протоколы SSL и TLS. Начнем с основ, все сетевые устройства имеют четко прописанный алгоритм общения друг с другом, называется он OSI, который порезан на 7 уровней. В ней есть транспортный уровень отвечающий за доставку данных, но так как модель OSI это некая утопия, то сейчас все работаю по упрощенной модели TCP/IP, из 4 уровней. Стек TCP/IP, сейчас стандарт передачи данных в компьютерных сетях и он включает в себя, большое количество известных вам протоколов прикладного уровня:
Список можно продолжать очень долго, так их более 200 наименований. Ниже представлена схема сетевых уровней.
Ну и схема стека SSL/TLS, для наглядности.
Теперь все тоже самое простым языком, так как не всем понятны эти схемы и принцип работы ssl и tls не понятен. Когда вы открываете например мой блог pyatilistnik.org, то вы обращаетесь по прикладному протоколу http, при обращении сервер видит вас и передает на ваш компьютер данные. Если это представить схематично, то это будет простая матрешка, прикладной протокол http, кладется в стек tcp-ip.
Если бы на Pyatilistnik.org стоял бы сертификат шифрования TLS, то матрешка протоколов была бы посложнее и выглядела бы вот так. Тут прикладной протокол http, кладется в SSL/TLS, который в свою очередь кладется в стек TCP/IP. Все тоже самое, но уже зашифровано, и если хакер перехватит эти данные по пути их передачи, то получит всего навсего цифровой мусор, а вот расшифровать данные может только та машина, которая устанавливала соединение с сайтом.
Этапы установки соединения SSL/TLS
- Клиент обращается к серверу, устанавливая с ним соединение, далее запрашивается защищенное подключение, тут два варианта, если вы изначально обращаетесь на порт 443, который предназначен для TLS/SSL соединения, или после того как вы установили обычное подключение, клиент делает дополнительный запрос на защищенное соединение.
- Когда идет установка соединения, клиент говорит серверу, какие алгоритмы шифрования ему известны, сервер сравнивает его со своим списком алгоритмов шифрования и находит тот, который поддерживается обоими сторонами. Далее он говорит клиенту, что будет использоваться именно этот метод защиты. По умолчанию сервер будет стараться использовать самый современный алгоритм (SSLv3, TLSv1, TLSv1.1, TLSv1.2)
- После того, как определились с алгоритмами шифрования, сервер передает клиенту свой цифровой сертификат, который подписан вышестоящим, мировым центром сертификации и открытый ключ сервера.
- Клиент проверяет ликвидность полученного сертификата от сервера, для этого он обращается к центру сертификации, который его выдавал, и спрашивает есть ли у тебя такой сертификат, если все нормально, можно продолжать. Тут главное, чтобы сертификат не был отозван и вы доверяли корневому центру сертификации, выдавшим его, по умолчанию в операционной системе Windows, уже есть большое количество корневых сертификатов, которым вы доверяете, и они обновляются при установке новых обновлений в систему.
- Следующим этапом, после получения клиентом нужных ключей, начинается генерация сеансового ключа для защищенного соединения по принципу: Клиентом происходит генерация случайной цифровой последовательности, которую он шифрует с помощью открытого ключа полученного от сервера и отсылает результат шифрования на сервер. Полученный сеансовый ключ расшифровывается сервером с помощью его закрытого ключа, в виду того, что используется асимметричный алгоритм шифрования, то расшифровать последовательность полученную от клиента, может только сервер. Об алгоритмах шифрования мы еще поговорим ниже.
- Все защищенный канал настроен и будет работать до тех пор, пока не будет разорвано соединение.
Вот еще одна красивая и наглядная схема создания защищенного канала.
Установка соединения SSL/TLS на уровне сетевых пакетов
На иллюстрации, черные стрелки показывают сообщения, которые отправляются открытым текстом, синие — это сообщения, подписанные открытым ключом, а зеленые — это сообщения, отправленные с помощью шифрования объёмных данных и того MAC, о которых стороны договорились в процессе переговоров.
Ну и подробно про каждый этап обмена сетевых сообщений протоколов SSL/TLS.
- 1. ClientHello > пакет ClientHello делает предложение со списком поддерживаемых версий протоколов, поддерживаемые наборы шифров в порядке предпочтения и список алгоритмов сжатия (обычно NULL). Еще от клиента приходит случайное значение 32 байта, его содержимое указывает отметку текущего времени, его позже будут использовать для симметричного ключа и идентификатора сессии, который будет иметь значение ноль, при условии, что не было предыдущих сессий.
- 2. ServerHello > пакет ServerHello, отсылается сервером, в данном сообщении идет выбранный вариант, алгоритма шифрования и сжатия. Тут так же будет случайное значение 32 байта (отметка текущего времени), его также используют для симметричных ключей. Если ID текущей сессии в ServerHello имеет значение ноль, то создаст и вернёт идентификатор сессии. Если в сообщении ClientHello был предложен идентификатор предыдущей сессии, известный данному серверу, то протокол рукопожатия будет проведён по упрощённой схеме. Если клиент предложил неизвестный серверу идентификатор сессии, сервер возвращает новый идентификатор сессии и протокол рукопожатия проводится по полной схеме.
- 3.Certificate (3) > в данном пакете сервер отправляет клиенту свой открытый ключ (сертификат X.509), он совпадает с алгоритмом обмена ключами в выбранном наборе шифров. Вообще можно сказать в протоколе, запроси открытый ключ в DNS, запись типа KEY/TLSA RR. Как я писал выше этим ключом будет шифроваться сообщение.
- 4. ServerHelloDone > Сервер говорит, что сессия установилось нормально.
- 5. ClientKeyExchange > Следующим шагом идет отсылка клиентом ключа pre-master key, используя случайные числа (или отметки текущего времени) сервера и клиента. Данный ключ (pre-master key) как раз и шифруется открытым ключом сервера. Данное сообщение может расшифровать только сервер, с помощью закрытого ключа. Теперь оба участника вычисляют общий секретный ключ master key из ключа pre-master.
- 6. ChangeCipherSpec — клиент > смысл пакета, указать на то, что теперь весь трафик, который идет от клиента, будет шифроваться, с помощью выбранного алгоритма шифрования объёмных данных и будет содержать MAC, вычисленный по выбранному алгоритму.
- 7. Finished — клиент > Это сообщение содержит все сообщения, отправленные и полученные во время протокола рукопожатия, за исключением сообщения Finished. Оно шифруется с помощью алгоритма шифрования объемных данных и хэшируется с помощью алгоритма MAC, о которых договорились стороны. Если сервер может расшифровать и верифицировать это сообщение (содержащее все предыдущие сообщения), используя независимо вычисленный им сеансовый ключ, значит диалог был успешным. Если же нет, на этом месте сервер прерывает сессию и отправляет сообщение Alert с некоторой (возможно, неконкретной) информацией об ошибке
- 8. ChangeCipherSpec — сервер > пакет, говорит, что теперь весь исходящий трафик с данного сервера, будет шифроваться.
- 9.Finished — сервер > Это сообщение содержит все сообщения, отправленные и полученные во время протокола рукопожатия, за исключением сообщения Finished
- 10. Record Protocol (протокол записи) > теперь все сообщения шифруются ssl сертификатом безопасности
Как получить ssl сертификат безопасности
Давайте теперь поймем где взять сертификат шифрования, или как получить ssl сертификат безопасности. Способов конечно несколько, есть как платные, так и бесплатные.
Бесплатный способ получить tls сертификат безопасности
Этот способ, подразумевает использование самоподписного сертификата (self-signed), его можно сгенерировать на любом веб-сервере с ролью IIS или Apache. Если рассматривать современные хостинги, то в панелях управления, таких как:
- Directadmin
- ISPmanager
- Cpanel
там это штатный функционал. Самый большой плюс в самоподписных сертификатах шифрования, это то, что они бесплатные и начинаются, сплошные минусы, так как никто кроме вас не доверяет этому сертификату, вы наверняка видели в браузерах вот такую картину, где сайт ругается на сертификат безопасности.
Если у вас самоподписный сертификат, используется исключительно для внутренних целей, то это нормально, а вот для публичных проектов, это будет огромный минус, так как ему никто не доверяет и вы лишитесь большого числа клиентов или пользователей, которые у видя ошибку сертификата безопасности в браузере, сразу его закроют.
Давайте смотреть как можно получить ssl сертификат безопасности, для этого формируется запрос на выпуск сертификата, называется он CSR запрос (Certificate Signing Request). Делается это чаще всего у специальной компании в веб форме, которая спросит вас несколько вопросов, про ваш домен и вашу компанию. Как только вы все внесете, сервер сделает два ключа, приватный (закрытый) и публичный (открытый). Напоминаю открытый ключ не является конфиденциальным, поэтому вставляется в CSR запрос. Вот пример Certificate Signing Request запроса.
Все эти не понятные данные легко можно интерпретировать специальными CSR Decoder сайтами.
Примеры двух сайтов CSR Decoder:- http://www.sslshopper.com/csr-decoder.html
- http://certlogik.com/decoder/
Состав CSR запроса
- Common Name: доменное имя, которое мы защищаем таким сертификатом
- Organization: название организации
- Organization Unit: подразделение организации
- Locality: город, где находится офис организации
- State: область или штат
- Country:двухбуквенный код, страны офиса
- Email: контактный email технического администратора или службы поддержки
Как только Certificate Signing Request сгенерирован, можно начинать оформлять заявку на выпуск сертификата шифрования. Центр сертификации будет производить проверку, всех данных указанных вами в CSR запросе, и если все хорошо, вы получите свой ssl сертификат безопасности и вы его сможете использовать для https. Теперь ваш сервер, автоматом сопоставит выпущенный сертификат, со сгенерированным приватным ключом, все вы можете шифровать трафик подключения клиента к серверу.
Что такое центр сертификации
Что такое CA — Certification Authority или центр сертификации, читайте по ссылке слева, я подробно рассказал об этом там.
Какие данные содержит в себе SSL сертификат
В сертификате хранится следующая информация:
- полное (уникальное) имя владельца сертификата
- открытый ключ владельца
- дата выдачи ssl сертификата
- дата окончания сертификата
- полное (уникальное) имя центра сертификации
- цифровая подпись издателя
Какие существуют виды SSL сертификатов шифрования
Основных видов сертификатов безопасности три:
- Domain Validation — DV > Это сертификат шифрования, который только подтверждает доменное имя ресурса
- Organization Validation — OV > Это сертификат шифрования, который подтверждает организацию и домен
- Extendet Validation — EV > Это сертификат шифрования, который имеет расширенную проверку
Назначение Domain Validation — DV
И так сертификаты шифрования, подтверждающие только домен ресурса, это самые распространенные в сети сертификаты, их делают всех быстрее, автоматически. Когда вам нужно проверить такой сертификат безопасности, отправляется email с гиперссылкой, кликая по которой подтверждается выпуск серта. Хочу отметить, что письмо вам отправят, только не подтвержденный email (approver email), указанный при заказе сертификата шифрования.
approver email так же имеет требования, логично, что если вы заказываете сертификаты шифрования для домена, то и электронный ящик должен быть из него, а не mail или rambler, либо он должен быть указан в whois домена и еще одно требование название approver email, должно быть по такому шаблону:
- webmaster@ваш домен
- postmaster@ваш домен
- hostmaster@ваш домен
- administrator@ваш домен
- admin@
Я обычно беру ящик postmaster@ваш домен
Сертификат tls-ssl подтверждающие доменное имя выпускаются, когда CA произвел валидацию того, что заказчик обладает правами на доменное имя, все остальное, что касается организации в сертификате не отображается.
Назначение Organization Validation — OV
Сертификаты шифрования tls-ssl, будет содержать название вашей организации, его получить частное лицо просто не сможет, его культурно пошлют регистрировать ИП. Делается он от 3 до десяти рабочих дней, все зависит от центра сертификации, который его будет выпускать.
Назначение Extendet Validation — EV
И так, вы направили CSR запрос на выпуск сертификата шифрования для вашей организации, CA начинает проверять, реально ли ИП рога и копыта существуют, как в CSR и принадлежит ли ей домен указанный в заказе.
- Могут посмотреть есть ли организация международных желтых страницах, кто не знает, что это такое, то это телефонные справочники в Америке. Проверяют так не все CA.
- Смотрят whois домена у вашей организации, делают это все центры сертификации, если в whois нет ни слова о вашей организации, то с вас будут требовать гарантийное письмо, что домен ваш.
- Свидетельство о государственной регистрации ЕГРИП или ЕГРЮЛ
- Могут проверить ваш номер телефона, запросив счет у вашей телефонной компании, в котором будет фигурировать номер.
- Могут позвонить и проверить наличие компании по этому номеру, попросят к телефону человека указанного администратором в заказе, так что смотрите, чтобы человек знал английский.
Сам сертификат шифрования extendet Validation — EV, самый дорогой и получается всех сложнее, у них кстати есть green bar, вы его точно видели, это когда на сайте в адресной строке посетитель видит зеленую стоку с названием организации. Вот пример клиент банка от сбербанка.
К расширенным сертификатам шифрования (extendet Validation — EV) самое большое доверие, это и логично вы сразу видите, что компания существует и прошла жесткие требования к выдаче сертификата. SSL cертификаты extendet Validatio делаются CA, только при выполнении двух требований, что организация владеет нужным доменом и, что она сама существует в природе. При выпуске EV SSL сертификатов, существует строгий регламент, в котором описаны требования перед выпуском EV сертификата
- Должен проверить правовую, физическую и операционную деятельности субъекта
- Проверка организации и ее документов
- Право владения доменом, организации
- Проверить, что организация полностью авторизована для выпуска EV сертификата
SSL cертификаты extendet Validatio выпускаются примерно от 10-14 дней, подходят как для некоммерческих организаций, так и для государственных учреждений.
Типы SSL сертификатов шифрования
Следующим важным вопросом, будет какие типы SSL — TLS сертификатов шифрования существуют, и их отличия и стоимость.
- Обычные SSL сертификаты > это самые распространенные сертификаты, делаются автоматически, для подтверждения только домена. Стоят в среднем 18-22 доллара.
- SGC сертификаты > это SSL — TLS сертификаты с поддержкой, более высокого уровня шифрования. Они в основном идут для старперных браузеров, у которых есть поддержка только 40-56 битное шифрование. SGC принудительно повышает уровень шифрования , до 128 бит, что в несколько раз выше. Так как XP доживает свои последние годы, скоро SGC сертификаты шифрования не будут нужны. Стоит это чудо около 300-ста баксов за год.
- Wildcard сертификаты > Требуются, для субдоменов вашего основного домена. Простой пример мой блог pyatilistnik.org, если я покупаю Wildcard, то имею возможно его вешать на все домены 4 уровня у себя, *.pyatilistnik.org. Стоимость Wildcard сертификатов шифрования варьируется от количества поддоменов, от 190 баксов.
- SAN сертификаты > Допустим у вас есть один сервер, но на нем хостятся много разных доменов, вот SAN сертификат можно повесить на сервер и все домены будут использовать его, стоит от 400 баксов в год.
- EV сертификаты > про расширенные мы уже все обсудили выше, стоят от 250 баксов в год.
- Сертификаты c поддержкой IDN доменов
список сертификатов, у которых есть такая поддержка, IDN доменов:
- Thawte SSL123 Certificate
- Thawte SSL Web Server
- Symantec Secure Site
- Thawte SGC SuperCerts
- Thawte SSL Web Server Wildcard
- Thawte SSL Web Server with EV
- Symantec Secure Site Pro
- Symantec Secure Site with EV
- Symantec Secure Site Pro with EV
Полезные утилиты:
- OpenSSL — самая распространенная утилита для генерации открытого ключа (запроса на сертификат) и закрытого ключа.
http://www.openssl.org/ - CSR Decoder — утилита для проверки CSR и данных, которые в нем содержаться, рекомендую использовать перед заказом сертификата.
http://www.sslshopper.com/csr-decoder.html или http://certlogik.com/decoder/ - DigiCert Certificate Tester — утилита для проверки корректно самого сертификата
http://www.digicert.com/help/?rid=011592
http://www.sslshopper.com/ssl-checker.html
В будущих статьях, мы еще сами по настраиваем CA и будем на практике использовать SSL/TLS сертификаты шифрования.
Протокол SSL
SSL — это открытый криптографический протокол (Secure Sockets Layer protocol, протокол защищенных сокетов), разработанный в 1996 году компанией Netscape для передачи зашифрованной информации по открытым каналам, обеспечивая надежный, защищенный обмен данными между двумя приложениями, работающими удаленно. Для работы протокол использует ассиметричную криптосистему с открытым ключом, разработанную компанией RSA Data Security.
SSL обеспечивает безопасный канал между клиентом и сервером, предоставляя возможность взаимной аутентификации, использования цифровых подписей для обеспечения целостности и шифрования для конфиденциальности.
В многоуровневой модели OSI протокол SSL располагается между протоколом транспортного уровня (например, TCP), и протоколом прикладного уровня (чаще всего HTTP).
Протокол SSL имеет два уровня: протокол записей (SSL Record Protocol) и протокол диалога (SSL Handshake Protocol). Нижний уровень SSL — SSL Record Protocol располагается поверх транспортного протокола (например, TCP). Верхний уровень — SSL Handshake Protocol позволяет серверу и клиенту идентифицировать друг друга и согласовывать алгоритм шифрования и криптографические ключи, до начала обмена данными.
В протоколе SSL реализована возможность два типа идентификации (или аутентификации):
- идентификация на стороне клиента;
- идентификация на стороне сервера.
Серверная сторона аутентифицируется всегда, в то время как клиентская — аутентифицируется опционно.
SSL-идентификация сервера позволяет клиенту проверить подлинность сервера, то-есть убедиться, что сертификат сервера и открытый ключ действительны и были выданы источником, находящимся в списке доверенных источников сертификатов этого клиента. В случае самоподписанных сертификатов клиенту нужно будет добавить исключение для данного сертификата.
SSL-аутентификация клиента позволяет серверу проверить личность пользователя. Используется в основном в финансовых системах.
При установлении соединения по SSL клиент и сервер обмениваются приветственными сообщениями (hello message). Кроме всего прочего приветственное сообщение устанавливает четыре основных параметра: версия протокола, идентификатор сессии, способ шифрования, метод компрессии, а также, два специально сгенерированных случайных числа; и сервер, и клиент, генерируют такие числа независимо друг от друга, а затем, просто обмениваются ими друг с другом.
После получения приветственного сообщения от клиента, сервер отсылает клиенту свой сертификат. После этого, производится еще ряд промежуточных обменных операций, в процессе которых, производится окончательное уточнение выбранного алгоритма шифрования и ключей. Для шифрования данных используются средства симметричной криптографии (например, DES, RC4 и т.д.) — протокол позволяет использовать по выбору различные алгоритмы для шифрования. В итоге сервер посылает клиенту некое финальное сообщение, после чего обе стороны приступают к обмену зашифрованной информацией.
Надежность соединения обеспечивается контролем целостности сообщений с помощью зашифрованного кода целостности (MAC). Для вычисления кодов МАС используются безопасные хэш-функции (например, безопасный хэш-алгоритм [SHA], MD5 и т.д.).
Одно из преимуществ SSL состоит в том, что он независим от протоколов приложений. Протокол высокого уровня может совершенно прозрачно располагаться поверх протокола SSL.
Версии SSL:
- SSL v2.0 — первый реализованный протокол SSL
- SSL v3.0 — ревизия протокола с целью предотвращения специфичных атак, добавление не-RSA шифров и цепей сертификатов
- TLS v1.Х — ревизия протокола SSL v3.0. Уровень MAC обновлен до HMAC. Добавлены дополнение блоков для блочных шифров, стандартизован порядок сообщений, расширены предупредительные сообщения.
В настоящее время на смену SSL v3.0 пришел протокол TLS (Transport Layer Security), но она до сих пор используется во многих современных браузерах (Chrome, Firefox) и веб-серверах в целях обратной совместимости. По некоторым оценкам, через SSL 3.0 проходит около 1% всего интернет-трафика.
TLS и SSL протоколы: все, что нужно знать о них.
Автор Исхаков Максим На чтение 4 мин. Просмотров 549 Опубликовано
Кибербезопасность может восприниматься как минное поле со всеми ее сложностями. Вы можете не знать, что такое SSL или TLS, но это важно. TLS – это то, благодаря чему хакеры не могут шпионить за вашим трафиком и красть данные вашей карты, пока вы используете интернет-банкинг. Но как это работает?
Определение SSL и TLS
SSL и TLS – это криптографические протоколы, которые шифруют и аутентифицируют данные, передаваемые от клиента (т. е. вашего устройства, запрашивающего веб-сайт) на сервер, компьютер или приложение.
SSL является предшественником TLS. Впервые протокол SSL был выпущен в свет в 1995 году. Однако у него было много уязвимостей, поэтому год спустя он был заменен SSL v3.0. Последнее тоже не было идеальным, поэтому TLS был введен в 1999 году. Большинство устройств и браузеров перешли на TLS v1.2. Однако многие люди настолько привыкли к термину SSL, что будут называть TLS SSLом. Большинство сейчас используют двойной термин SSL/TLS для лучшего понимания.
Зачем сайтам нужен SSL/TLS?
SSL/TLS взаимодействуют с HTTP и является тем, что добавляет S – HTTPS. HTTP – это прикладной протокол, который передает данные из браузера на сервер или, проще говоря, доставляет результаты поиска в ваш браузер. Однако HTTP соединения небезопасны сами по себе. Это все равно, что отправлять свои данные в открытый доступ – их может увидеть любой желающий. HTTP уязвим для атак, что означает, что любой, кто шпионит за трафиком, может украсть ваш логин или данные карты.
Вот почему был введен HTTPS. Это комбинация HTTP, которая обрабатывает механику передачи данных и SSL/TLS, который обрабатывает шифрование данных. Благодаря шифрованию SSL/TLS ваши данные безопасности – любой, кто следит за вашим трафиком, теперь может видеть только зашифрованные данные. В наши дни большинство сайтов используют HTTPS.
Как работает SSL?
SSL/TLS шифрование можно разделить на два этапа: handshake SSL/TLS и record layer SSL/TLS. Стоит углубится в них более подробно.
Что такое SSL handshake?
Это форма связи между клиентом и сервером, где оба решают, какая версия протокола будет использоваться для их дальнейшего взаимодействия. Как это работает на практике?
- Клиент посылает запрос “привет” на сервер, с которым он хочет связаться. Он включает в себя типы шифров (алгоритмы шифрования), которые может поддерживать клиент.
- Сервер отправляет’ привет ‘ обратно со своим сертификатом SSL и его открытым ключом. Клиент и сервер здесь используют асимметричную криптографию для обмена защищенными сообщениями. Это означает, что клиенту нужен открытый ключ сервера для шифрования сообщений, а серверу нужны два ключа – частный и открытый – для его расшифровки. Никто, шпионящий за трафиком, не может расшифровать их сообщения.
- Затем клиент использует открытый ключ сервера для создания предварительного pre-master и отправляет его на сервер. Это будет использоваться для создания ключей сеанса и повышения уровня связи до симметричного шифрования. Теперь оба конца будут использовать только закрытые ключи. Симметричная криптография сделает их связь намного быстрее и будет использовать меньше ресурсов.
- Сервер расшифровывает pre-master, использует его для создания симметричного ключа и обменивается им с клиентом. При установленном симметричном шифровании они теперь могут обмениваться зашифрованными сообщениями. Трафик защищен.
Уровень записи SSL/TLS
Именно здесь происходит шифрование. Данные отправляются из приложения пользователя и шифруются. В зависимости от шифра, он также может быть сжат. Затем он отправляется дальше на сетевой транспортный уровень, который определяет, как отправить данные на целевое устройство.
Что такое SSL-сертификат и зачем он нужен?
Серверы, поддерживающие протокол TLS, будут иметь сертификаты SLS, хотя правильнее было бы называть их сертификатами SSL/TLS. Они приобретаются с платформ хостинга и необходимы во время процесса handshake SSL/TLS, чтобы удостовериться, что они действительно являются провайдерами безопасного соединения.
Однако протоколы – это не то же самое, что сертификаты. Какой протокол будет использоваться при подключении, SSL или TLS, определяется вашим браузером и конфигурациями целевого сервера, а не сертификатом сайта. Можно подключиться к сайту, который имеет HTTPS, но использует устаревший протокол SSL v3.0.
Такие соединения уязвимы для атак. Большинство новых браузеров укажут это в вашем URL. Просто посмотрите на закрытые зеленые висячие замки и символы HTTPS. Если вы беспокоитесь о случайном подключении к сайту, который поддерживает только SSL v3.0, то можете вручную отключить SSL соединения. Но это может привести к обрыву связи.
На видео: SSL/TLS: история уязвимостей
SSL — это… Что такое SSL?
SSL (англ. Secure Sockets Layer — уровень защищённых сокетов) — криптографический протокол, который обеспечивает установление безопасного соединения между клиентом и сервером. SSL изначально разработан компанией Netscape Communications. Впоследствии на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS.
Протокол обеспечивает конфиденциальность обмена данными между клиентом и сервером, использующими TCP/IP, причём для шифрования используется асимметричный алгоритм с открытым ключом. При шифровании с открытым ключом используются два ключа, открытый и секретный, причем любой из них может использоваться для шифрования сообщения. Если для шифрования сообщения был использован открытый ключ, то для расшифровки должен использоваться секретный, и наоборот. В такой ситуации возможны два способа использования ключей. Во-первых, сторона, хранящая в тайне секретный ключ и опубликовавшая открытый, может принимать от противоположной стороны сообщения, зашифрованные открытым ключом, которые не может прочитать никто, кроме нее (ведь для расшифровки требуется секретный ключ, известный только ей). Во-вторых, с помощью закрытого ключа сторона-обладатель закрытого ключа может создавать зашифрованные сообщения, которые может прочесть кто угодно (ведь для расшифровки нужен открытый ключ, доступный всем), но при этом прочитавший может быть уверен, что это сообщение было создано стороной-обладателем секретного ключа.
Описание
Протокол SSL состоит из двух подпротоколов: протокол SSL записи и рукопожатия. Протокол SSL записи определяет формат, используемый для передачи данных. Протокол SSL включает рукопожатие с использованием протокола SSL записи для обмена сериями сообщений между сервером и клиентом во время установления первого соединения. Для работы SSL требуется, чтобы на сервере имелся SSL-сертификат.
SSL предоставляет канал, имеющий 3 основных свойства:
- Аутентификация. Сервер всегда аутентифицируется, в то время как клиент аутентифицируется в зависимости от алгоритма.
- Целостность. Обмен сообщениями включает в себя проверку целостности.
- Конфиденциальность канала. Шифрование используется после установления соединения и используется для всех последующих сообщений.
В протоколе SSL все данные передаются в виде записей-объектов, состоящих из заголовка и передаваемых данных. Передача начинается с заголовка. Заголовок содержит либо два, либо три байта кода длины. Причём, если старший бит в первом байте кода равен единице, то запись не имеет заполнителя и полная длина заголовка равна двум байтам, иначе запись содержит заполнитель и полная длина заголовка равна трём байтам. Код длины записи не включает в себя число байт заголовка. Длина записи 2-байтового заголовка:
RecLength = ((byte[ 0 ] & 0x7F) << 8) | byte[ 1 ];
Здесь byte[0] и byte[1] — первый и второй полученные байты. Длина записи 3-байтового заголовка:
RecLength = ((byte[ 0 ] & 0x3F) << 8) | byte[ 1 ]; Escape = (byte[ 0 ] & 0x40) != 0; Padding = byte[ 2 ];
Здесь Padding определяет число байтов, добавленных отправителем к исходному тексту, для того, чтобы сделать длину записи кратной размеру блока шифра, при использовании блочного шифра.
Теперь отправитель «заполненной» записи добавляет заполнитель после имеющихся данных и шифрует всё это. Причем, содержимое заполнителя никакой роли не играет. Из-за того, что известен объём передаваемых данных, заголовок может быть сформирован с учетом Padding.
В свою очередь получатель записи дешифрует все поля данных и получает полную исходную информацию. Затем производится вычисление значения RecLength по известному Padding, и заполнитель из поля данных удаляется. Данные записи SSL состоят из 3 компонент:
- MAC_Data[Mac_Size] — (Message Authentication Code) — код аутентификации сообщения
- Padding_Data[Padding] — данные заполнителя
- Actual_Data[N] — реальные данные
Когда записи посылаются открытым текстом, очевидно, что никакие шифры не используются. Тогда длина Padding_Data и MAC_Data равны нулю. При использовании шифрования Padding_Data зависит от размера блока шифра, а MAC_Data зависит от выбора шифра. Пример вычисления MAC_Data:
MacData = Hash(Secret, Actual_Data, Padding_Data, Sequence_Number);
Значение Secret зависит от того, кто (клиент или сервер) посылает сообщение. Sequence_Number — счётчик, который инкрементируется как сервером, так и клиентом. Здесь Sequence_Number представляет собой 32-битовый код, передаваемый хэш-функции в виде 4 байт, причём, первым передаётся старший байт. Для MD2, MD5 MAC_Size равен 16 байтам (128 битам). Для 2-байтового заголовка максимальная длина записи равна 32767 байтов, а для 3-байтного заголовка — 16383 байтов.
История и развитие
Протокол SSL был изначально разработан компанией Netscape. Версия протокола 1.0 публично не выпускалась. Версия 2.0 была выпущена в феврале 1995 года, но «содержала много недостатков по безопасности, которые, в конечном счёте, привели к созданию версии 3.0», которая была выпущена в 1996 году. Тем самым версия SSL 3.0 послужила основой для создания протокола TLS 1.0, стандарт протокола Internet Engineering Task Force (IETF) впервые был определен в RFC 2246 в январе 1999 года. Visa, Master Card, American Express и многие другие организации, работающие с интернет деньгами, имеют лицензию на использование протокола SSL для коммерческих целей в сети Интернет.
SSL работает модульным способом. Тем самым SSL расширяемо в соответствии с проектом о поддержке прямой и обратной совместимости и переговорам между соединениями в одноранговой сети.
Применение
Значительное использование протокола SSL привело к формированию протокола HTTPS (Hypertext Transfer Protocol Secure), поддерживающего шифрование. Данные, которые передаются по протоколу HTTPS, «упаковываются» в криптографический протокол SSL или TLS, тем самым обеспечивая защиту этих данных. Такой способ защиты широко используется в мире Веб для приложений, в которых важна безопасность соединения, например в платёжных системах. HTTPS поддерживается всеми браузерами. В отличие от HTTP, для HTTPS по умолчанию используется TCP-порт 443.
Изначально виртуальные частные сети (VPN) на основе SSL разрабатывались как дополнительная и альтернативная технология удалённого доступа на основе IPsec VPN. Однако, такие факторы, как достаточная надёжность и дешевизна сделали эту технологию привлекательной для организации VPN. Также SSL получил широкое применение в электронной почте.
Основные цели протокола в порядке приоритетности
- Криптографическая безопасность: SSL устанавливает безопасное соединение между двумя сторонами.
- Совместимость: Программисты, независимо друг от друга могут создавать приложения, использующие SSL, которые впоследствии будут способны успешно обмениваться криптографическими параметрами без всякого знания кода чужих программ.
- Расширяемость: SSL стремится обеспечить рабочее пространство, в котором новые открытые ключи и трудоемкие методы шифрования могут быть включены по мере необходимости.
- Относительная эффективность: работа протокола на основе SSL требует больших скоростей от CPU, в частности для работы с открытыми ключами. По этой причине SSL протокол был включен в необязательную сессию схемы кеширования для уменьшения числа соединений, которые необходимо устанавливать с нуля. Кроме того, большое внимание уделяется тому, чтобы уменьшить сетевую активность.
Аутентификация и обмен ключами
SSL поддерживает 3 типа аутентификации:
- аутентификация обеих сторон (клиент — сервер),
- аутентификация сервера с неаутентифицированным клиентом
- полная анонимность.
Всякий раз, когда сервер аутентифицируется, канал безопасен против попытки перехвата данных между веб-сервером и браузером, но полностью анонимная сессия по своей сути уязвима к такой атаке. Анонимный сервер не может аутентифицировать клиента. Если сервер аутентифицирован, то его сообщение сертификации должно обеспечить верную сертификационную цепочку, ведущую к приемлемому центру сертификации. Проще говоря, аутентифицированный клиент должен предоставить допустимый сертификат серверу. Каждая сторона отвечает за проверку того, что сертификат другой стороны еще не истек и не был отменен. Главная цель процесса обмена ключами — это создание секрета клиента (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, которому ставит в соответствие сигнатуру текущему сообщению рукопожатия.
Обмен ключами при использовании Diffie-Hellman и аутентификация
В этом случае сервер может также поддерживать содержащий конкретные параметры алгоритм Диффи-Хеллмана или может использовать сообщения обмена ключами от сервера для посылки набора временных параметров подписанных сертификатами DSS или RSA. Временные параметры хэшируются с сообщением hello.random перед подписанием, для того чтобы злоумышленник не смог совершить повтор старых параметров. В любом случае клиент может проверить сертификат или сигнатуру, для уверенности, что параметры принадлежат серверу.
Если клиент имеет сертификат, содержащий параметры алгоритма Diffie-Hellman, то сертификат также содержит информацию требуемую для того чтобы завершить обмен ключами. Заметим, что в этом случае клиент и сервер должны будут сгенерировать те же Diffie-Hellman результаты (pre_master_secret), каждый раз когда они устанавливают соединение. Для того чтобы предотвратить остановку секрета (pre_master_secret) в памяти компьютера на время дольше, чем необходимо, секрет должен быть переведен в общий секрет (master_secret) настолько быстро, на сколько это возможно. Параметры клиента должны быть совместимы с теми, которые поддерживает сервер для того, чтобы работал обмен ключами.
Протокол записи (Record Layer)
Протокол записи — это уровневый протокол. На каждом уровне сообщения включают поля для длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, разумно сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента.
Существует четыре протокола записи: протокол рукопожатия (handshake protocol), протокол тревоги (alert protocol), протокол изменения шифра (the change cipher spec protocol), протокол приложения (application data protocol). Если SSL реализация получает тип записи, который ей неизвестен, то эта запись просто игнорируется. Любой протокол созданный для использования совместно с SSL должен быть хорошо продуман, так как будет иметь дело с атаками на него. Заметим, что из-за типа и длины записи, протокол не защищен шифрованием. Внимание следует уделить тому, чтобы минимизировать трафик.
Протокол рукопожатия (handshake)
SSL клиент и сервер договариваются об установлении связи с помощью процедуры рукопожатия. Во время рукопожатия клиент и сервер договариваются о различных параметрах, которые будут использованы, чтобы обеспечить безопасность соединения.
- Рукопожатие начинается тогда, когда клиент подключается к SSL серверу. Запрос безопасного соединения представляет собой список поддерживаемых шифров и хэш-функций.
- Из этого списка сервер выбирает самый сильный шифр и хэш-функцию, которую он также поддерживает, и уведомляет клиентов о принятом решении.
- Сервер отсылает это решение в виде цифрового сертификата. Сертификат, обычно, содержит имя сервера, доверенный Центр Сертификации, и открытый ключ шифрования сервера. Клиент может связаться с сервером, который выдал сертификат (доверенного центра сертификации, выше) и убедиться, что сертификат является подлинным прежде чем продолжить.
- Для того, чтобы сгенерировать ключи сеанса, используется безопасное соединение. Клиент шифрует случайное число с помощью открытого ключа (ОК) сервера и отправляет результат на сервер. Только сервер в состоянии расшифровать его (с его закрытым ключом (ЗК)), и только этот факт делает ключи скрытыми от третьей стороны, так как только сервер и клиент имели доступ к этим данным. Клиент знает открытый ключ и случайное число, а сервер знает закрытый ключ и (после расшифровки сообщения клиента) случайное число. Третья сторона, возможно, знает только открытый ключ, если закрытый ключ не был взломан.
- Из случайного числа обе стороны создают ключевые данные для шифрования и расшифровывания.
На этом рукопожатие завершается, и начинается защищенное соединение, которое зашифровывается и расшифровывается с помощью ключевых данных. Если любое из перечисленных выше действий не удается, то рукопожатие SSL не удалось, и соединение не создается.
Протокол изменения параметров шифрования (The Change Cipher Spec Protocol)
Он существует для сигнализации перехода в режим шифрования. Протокол содержит единственное сообщение, которое зашифровано и сжато при текущем установленном соединении. Сообщение состоит только из одного бита со значением 1.
struct {
enum { change_cipher_spec(1), (255) } type;
} ChangeCipherSpec;
Сообщение изменения шифра посылается и клиентом и сервером для извещения принимающей стороны, что последующие записи будут защищены в соответствии с новым договоренным CipherSpec и ключами. Принятие этого сообщения заставляет получателя отдать приказ уровню записи незамедлительно копировать состояние отложенного чтения в состояние текущего чтения. Сразу после послания этого сообщения, тот кто послал должен отдать приказ уровню записи перевести режим отложенной записи в режим текущей записи. Сообщение изменения шифра посылается во время рукопожатия, после того как параметры защиты были переданы, но перед тем как будет послано сообщение ‘finished’.
Протокол тревоги (Alert Protocol)
Один из типов проверки, поддерживаемых в протоколе SSL записи, — это протокол тревоги. Сообщение тревоги передаёт трудности, возникшие в сообщении, и описание тревоги. Сообщение тревоги с критическим уровнем незамедлительно прерывает соединение. В этом случае другие соединения, соответствующие сессии, могут быть продолжены, но идентификатор сессии должен быть признан недействительным. Как и другие сообщения, сообщение тревоги зашифровано и сжато, как только указано текущее состояние соединения.
Протокол приложения (Application Data Protocol)
Сообщение приложения данных работает на уровне записи. Он фрагментируется, сжимается и шифруется на основе текущего состояния соединения. Сообщения считаются прозрачными для уровня записи.
Ошибки в протоколе SSL
В протоколе SSL обработка ошибок очень проста. Когда ошибка обнаружена, тот, кто её обнаружил, посылает об этом сообщение своему партнёру. Неустранимые ошибки требуют от сервера и клиента разрыва соединения. Протокол SSL определяет следующие ошибки:
- Unsupported_Certificate_Type_Error: такая ошибка возникает, когда клиент/сервер получает тип сертификата, который не поддерживается. Ошибка устранима (только для аутентификации клиента).
- No_Cipher_Error: ошибка возникает, когда сервер не может найти размер ключа или шифр, который поддерживается также и клиентом. Ошибка неустранима.
- Bad_Certificate_Error: такая ошибка возникает, когда сертификат считается принимающей стороной плохим. Это означает, что или некорректна подпись сертификата, или его значение некорректно. Ошибка устранима (только для аутентификации клиента).
- No_Certificate_Error: если послано сообщение Request_Certificate, то эта ошибка может быть прислана по причине того, что клиент не имеет сертификата. Ошибка устранима.
Атаки
Существует ряд атак, которые могут быть предприняты против протокола SSL. Однако SSL устойчив к этим атакам, при условии, что пользователь использует только доверенные сервера для обработки информации.
«Взлом» агентами ФБР SSL-соединений с помощью систем прослушки Carnivore и NarusInsight
Наиболее известный инцидент по массовому «взлому» информации защищенной SSL-протоколами был произведен агентами ФБР с помощью систем Carnivore и NarusInsight, что привело к судебному процессу от лица правозащитной организации Electronic Frontier Foundation против AT&T (подробнее в статье о NarusInsight), который установил данные комплексы для взлома криптографически защищенной информации.
Несмотря на высокий общественный резонанс в США данного дела и расследование на уровне конституционного комитета Палаты представителей (см. подробнее в статье Carnivore), технологически взлом протокола SSL агентами ФБР не производился. Carnivore и NarusInsight были установле в самом ЦОД, где находились сервера ведущие SSL-соединенения с удаленными клиентами. NarusInsight полностью восстановил зашифрованную информацию путем прослушивания не SSL-соединения, а внутреннего траффика между серверами приложений внутри самого ЦОД, уже после того как данные поступившие по SSL была расшифрованы сами сервером их принявшим от внешних пользователей.
Тем не менее, указанный инцидент показал, что SSL не может являться надежным средством криптозащиты данных серверов в Интернет покуда спецслужбы устанавливают системы прослушивания в ЦОД такие как NarusInsight или СОРМ-2. Любой вид криптографии подразумевающий, что ключи от шифров находятся у сервера-получателя в ЦОД взламываются снифферами спецслужб в автоматическом режиме за счет внедрения их в самого получателя. Далее данные полностью реконструируются по процедурам, которые на данный момент регулируется и законодательными актами такими как «Патриотический акт». Причем указанные законодательные акты запрещают вплоть до судебного преследования владельцов ЦОД удаление снифферов спецслужб из внутренней части серверов-получателей. С учетом наличия данных систем, SSL-протокол может защищать только соединение двух пользователей в Интернет, но не защищает от спецслужб любое SSL-соединение с внешним Web-сайтом.
Раскрытие шифров
Как известно, SSL зависит от различных криптографических параметров. Шифрование с открытым ключом RSA необходимо для пересылки ключей и аутентификации сервера/клиента. Однако в качестве шифра используются различные криптографические алгоритмы. Таким образом, если осуществить успешную атаку на эти алгоритмы, то SSL не может уже считаться безопасным. Атака на определенные коммуникационные сессии производится записью сессии, и потом, в течение долгого времени подбирается ключ сессии или ключ RSA.
Злоумышленник посередине
Также известна как MitM (Man-in-the-Middle) атака. Предполагает участие трех сторон: сервера, клиента и злоумышленника, находящегося между ними. В данной ситуации злоумышленник может перехватывать все сообщения, которые следуют в обоих направлениях, и подменять их. Злоумышленник представляется сервером для клиента и клиентом для сервера. В случае обмена ключами по алгоритму Диффи-Хелмана данная атака является эффективной, так как целостность принимаемой информации и ее источник проверить невозможно. Однако такая атака невозможна при использовании протокола SSL, так как для проверки подлинности источника (обычно сервера) используются сертификаты, заверенные центром сертификации.
Атака будет успешной, если:
- Сервер не имеет подписанного сертификата.
- Клиент не проверяет сертификат сервера.
- Пользователь игнорирует сообщение об отсутствии подписи сертификата центром сертификации или о несовпадении сертификата с кэшированным.
Данный вид атаки можно встретить в крупных организациях, использующих межсетевой экран Forefront TMG компании Microsoft. В данном случае «злоумышленник» находится на границе сети организации и производит подмену оригинального сертификата своим. Данная атака становится возможной благодаря возможности указать в качестве доверенного корневого центра сертификации сам Forefront TMG. Обычно подобная процедура внедрения проходит прозрачно для пользователя за счет работы корпоративных пользователей в среде Active Directory. Данное средство может использоваться как для контроля за передаваемой информацией, так и в целях похищения личных данных, передаваемых с помощью защищенного соединения HTTPS.
Наиболее спорным становится вопрос информированности пользователя о возможности перехвата данных, т.к. в случае подмены корневого сертификата никаких сообщений безопасности выводиться не будет и пользователь будет ожидать конфиденциальности передаваемых данных. Кроме того, при использовании Forefront TMG в качестве SSL-прокси возникает возможность проведения второй MitM-атаки на стороне интернета, т.к. оригинальный сертификат не будет передан пользователю, а Forefront TMG может быть настроен на прием и последующую подмену самоподписанных или отозванных сертификатов. Для защиты от подобной атаки необходимо полностью запретить работу с веб-серверами, чьи сертификаты содержат какие-либо ошибки, что безусловно приведет к невозможности работы по протоколу HTTPS со множеством сайтов.
Атака отклика
Злоумышленник записывает коммуникационную сессию между сервером и клиентом. Позднее, он пытается установить соединение с сервером, воспроизводя записанные сообщения клиента. Но SSL отбивает эту атаку при помощи особого уникального идентификатора соединения (ИС). Конечно, теоретически третья сторона не в силах предсказать ИС, потому что он основан на наборе случайных событий. Однако, злоумышленник с большими ресурсами может записать большое количество сессий и попытаться подобрать «верную» сессию, основываясь на коде nonce, который послал сервер в сообщение Server_Hello. Но коды nonce SSL имеют, по меньшей мере, длину 128 бит, а значит, злоумышленнику необходимо записать кодов nonce, чтобы получить вероятность угадывания 50 %. Но достаточно большое число, что делает эти атаки бессмысленными.
Атака против протокола рукопожатия
Злоумышленник может попытаться повлиять на обмен рукопожатиями для того, чтобы стороны выбрали разные алгоритмы шифрования, а не те, что они выбирают обычно. Из-за того, что многие реализации поддерживают 40-битное экспортированное шифрование, а некоторые даже 0-шифрование или MAC-алгоритм, эти атаки представляют большой интерес.
Для такой атаки злоумышленнику необходимо быстро подменить одно или более сообщений рукопожатия. Если это происходит, то клиент и сервер вычислят различные значения хэшей сообщения рукопожатия. В результате чего стороны не примут друг от друга сообщения Finished. Без знания секрета злоумышленник не сможет исправить сообщение Finished, поэтому атака может быть обнаружена.
Алгоритмы, использующиеся в SSL
- Для обмена ключами и проверки их подлинности применяются: RSA, Diffie-Hellman, ECDH, SRP, PSK.
- Для аутентификации: RSA, DSA, ECDSA.
- Для симметричного шифрования: RC2, RC4, IDEA, DES, Triple DES или AES, Camellia.
- Для хеш-функций: SHA, MD5, MD4 и MD2.
См. также
Ссылки
- Mozilla.org — введение в SSL протокол
- inSSL — ресурс про SSL
SSL. Безопасность передачи данных / Хабр
Как давно вы проверяли надежность своего SSL? Мало просто купить SSL сертификат и его установить, нужно его и настроить.Почему это важно. Внешний анализ безопасности (ручной или автоматический) обычно начинается с проверки SSL-конфигурации. SSL конфигурация обычно показывает общий уровень защищенности всей системы защиты данных. Поэтому продвинутые пользователи начинают слать запросы типа “как вы можете защитить мои персональные данные, если у вас ещё SSL v3 включён”. В рамках GDPR надежная настройка SSL относится к техническим мерам по защите персональных данных.
Тестирование конфигурации SSL
Проблемы связанные с версиями SSL протоколов:
- SSL v2 небезопасен, устарел и не рекомендуется для использования. См. атаку DROWN по этому протоколу.
- SSL v3 небезопасен и устаревший инструмент. См. атаку POODLE.
- TLS v1.0 также является устаревшим протоколом, но на практике он все же оказывается необходим. Его основная слабость (BEAST) была смягчена в современных браузерах.
- TLS v1.1 и TLS v1.2 оба не имеют известных проблем с безопасностью, но только v1.2 предоставляет современные криптографические алгоритмы.
SSL 2.0, SSL 3.0 и TLS 1.0 настоятельно рекомендуется отключить, так как большинство стандартов безопасности их уже давно не поддерживают (например, PCI DSS 3.1).
Рекомендуемые протоколы TLS v1.1 и TLS v1.2 с актуальными алгоритмами шифрование и снятия хэшей.
Анализ конфигурации SSL
Есть замечательный инструмент SSLLabs Test Tool для проверки тестирования надёжности конфигурации SSL.
A+ и А — это наилучший показатель конфигурация SSL. F — наихудший уровень.
Пример теста SSL для одного из наших сайтов продуктов
Ниже приведен еще один пример того, как быстро проверить уровень SSL-конфигурации с помощью инструмента nmap:
Надежные шифры
Низкий уровень конфигурации SSL в большинстве случаев связан с использованием устаревших и слабых алгоритмов шифрования.
Этот ресурс предоставляет информацию о том, как настроить хорошие SSL-алгоритмы на Apache, nginx, HAProxy и т. д.
Конфигурация на Nginx
Ниже приведен пример конфигурации веб-серверов на nginx, которые повысили настройку SSL с уровня B до A + и повысили защиту системы:
Конфигурация на Windows
Windows Server 2016 и выше уже имеют конфигурацию SSL, которая соответствует действующим регламентам безопасности (например, SSL v2 и SSL v3 отключены).
В более ранних версиях Windows Servers (2008, 2012) SSL v3 все еще включен, т. е. Вам необходимо вручную отключить устаревшие протоколы. См. рекомендации Microsoft: как отключить PCT 1.0, SSL 2.0, SSL 3.0 или TLS 1.0
Мы используем инструмент IIS Crypto tool, который предоставляет графический интерфейс для отключения слабых шифров и устаревших протоколов. Это позволяет избежать опасной ручной работы с реестром Windows.
Использование SSLLabs Test Tool, его советов и функциональных возможностей позволяет быстро защитить SSL / TLS на Windows.
Реальный пример конфигурации SSL для Windows Server 2012 R2
Автор — Денис Колошко, CISSP
Описание протокола SSL
Криптографический протокол SSL (Secure Socket Layer) был разработан компанией Netscape в 1996 году и быстро стал наиболее популярным методом обеспечения защищенного обмена данными через Интернет. Протокол SSL интегрирован в большинство браузеров и в web-сервера. Правительство США в 2014 году сообщило об уязвимости в текущей версии SSL протокола (3.0), на смену которому предложен протокол TLS.
Защищенный обмен данными обеспечивается двумя элементами протокола SSL :
- аутентификация клиента;
- шифрование данных.
SSL использует симметричный шифр для обеспечения конфиденциальности, асимметричную криптографию для аутентификации ключей обмена и коды аутентификации сообщений для целостности сообщений.
Для осуществления SSL соединения необходимо на сервере инсталлировать цифровой сертификат, который «привязан» к конкретному домену сети интернет. Центр сертификации проводит проверки, подтверждающие подлинность организации, и после этого создает и подписывает цифровой сертификат для этой организации/сайта. Цифровой SSL сертификат следует устанавливать только на тот домен WEB-сервера, для которого он прошел аутентификацию; это даёт пользователям сети Интернет необходимые гарантии чистоты WEB-сервера.
Центры сертификации
Прежде чем продолжать повествование о соединениях SSL, необходимо несколько слов сказать о центрах сертификации.
Центр сертификации CA (certificate authority) — это организация, имеющая право выдачи цифровых сертификатов. Эта организация производит проверку данных запроса на сертификацию в CSR перед выдачей сертификата. Имеется несколько разновидностей цифровых сертификатов, отличающихся содержащейся в них информацией, и, соответственно, ценой. В самых простых сертификатах CA проверяет только соответствие доменного имени; в самых дорогих выполняется комплекс проверок самой организации, запрашивающей сертификат.
Отличие самоподписанного сертификата от выданного центром сертификации платного связано с тем, что при использовании такого сертификата на сайте (сервере), браузер будет открывать страницу с предупреждением, что этот сайт не использует безопасное соединение SSL. Браузер предложит покинуть сайт или продолжить просмотр, но с большой осторожностью; решение за посетителем сайта.
И так, при установлении SSL соединения, т.е. при открытии начинающейся с https://… страницы, браузер должен выполнить проверку цифрового сертификата сервера. Данная проверка выполняется с использованием доверенных сертификатов, размещенных в хранилище браузера. На следующем скриншоте представлена вкладка страницы настроек браузера Google Chrome «Доверенные корневые центры сертификации». Чтобы открыть данную вкладку необходимо проделать следующий путь : Chrome Настройки -> Дополнительные -> Настроить сертификаты. В Chrome установлено более 45 корневых сертификатов. В этом хранилище браузер с Вашего согласия также размещает сертификаты, которым Вы доверяете.
Имеется большое количество различных центров сертификации. Наиболее популярные :
- Comodo — штаб-квартира в Jersey City, New Jersey, США.
- Geotrust — штаб-квартира Mountain View, California, США
- Symantec — бывший Verisign в состав которого входит и Geotrust.
- Thawte — основан в 1995, продан Verisign в 1999.
- Trustwave — штаб-квартира Chicago, Illinois, США.
Этот список можно было бы и продолжить. Вы можете самостоятельно просмотреть установленные в Вашем браузере цифровые сертификаты корневых центров.
На заметку
Иногда возникает ситуация, при которой браузер выдает предупреждение, несмотря на то, что на серверe SSL сертификат
установлен. Данная ситуация возникнает либо при отсутствии корневого сертификата, центра выдавшего сертификат, либо из-за
того, что закончился срок действия корневого сертификата. Помните, что корневые сертификаты в браузерах обновляются при
обновлении браузера.
В настоящее время сертификационные центры используют ключи 2048 bit RSA. Поэтому для корректной работы всех сертификатов необходимо контролировать корневые сертификаты. Если корневые сертификаты не соответствуют данным требованиям, то это может вызвать проблемы с распознаванием его некоторыми из браузеров.
Многослойная среда SSL
Разобравшись, с точки зрения необходимого понимания, с центрами сертификации и подписываемыми ими цифровыми сертификатами, вернемся к описанию SSL-соединения
Основным преимуществом SSL является его независимость от прикладного (верхнего уровня) протокола, который работает поверх протокола SSL. То есть протокол SSL согласовывает алгоритм шифрования и ключ сессии, а также аутентифицирует сервер до того, как приложение примет или передаст первый байт сообщения.
Структурно протокол SSL размещается между протоколом, используемым клиентами (HTTP, FTP, IMAP, LDAP, Telnet и т.д.) и транспортным протоколом TCP/IP. Таким образом SSL обеспечивает защиту и передачу данных на транспортный уровень. Благодаря многослойной структуре SSL протокол может поддерживать разные протоколы программ-клиентов.
Протокол SSL условно можно разделить на два уровня. Первый уровень обеспечивает подтверждение подключения и включает три подпротокола : протокол подтверждения подключения (handshake protocol), протокол определения параметров шифра (change cipher spec protocol) и предупредительный протокол (alert protocol). Второй уровень включает протокол записи. На следующем рисунке схематично изображена структура взаимосвязи слоев SSL.
Уровень подтверждения подключения включает три части протокола :
1. Подтверждение подключения
используется для согласования данных сессии между клиентом (браузером) и сервером. Сессия включает следующие данные :
- идентификационный номер сессии;
- сертификаты обеих сторон;
- параметры используемого алгоритма шифрования;
- алгоритм сжатия информации;
- симметричный ключ шифрования.
Уровень подтверждения подключения обеспечивает реализацию нескольких функций безопасности. Так он формирует цепочку обмена данными и согласовывает шифрование, алгоритмы хеширования и сжатия. При определении подлинности участников обмена данных уровень подтверждения подключения использует сертификат стандарта Х.509.
Таким образом, на первом шаге при установке соединения стороны (браузер и сервер) договариваются о возможных механизмах шифрования, поддерживаемых каждой из сторон, длине используемого ключа, режиме шифрования и производят обмен сертификатами. Такой начальный обмен данными называется handshake. Во время handshake генерируется симметричный ключ, который действует только для одной SSL сессии и устаревает, как только сессия становится неактивной.
2. Изменение параметров шифрования
необходимо для определения параметров ключа, который используется для шифрования данных между клиентом и сервером.
Параметры ключа представляют информацию, которая используется для создания ключей шифрования. Данная часть протокола
состоит из одного сообщения, в котором сервер говорит об изменении набора ключей. После этого ключ извлекается из
информации, которой стороны обменялись на уровне подтверждения подключения.
3. Предупреждение
Сообщение предупреждения информирует стороны взаимодействия об изменении статуса или о возможной ошибке. Имеется несколько
предупредительных сообщений, которыми обмениваются стороны, как при нормальном функционировании, так и при возникновении
ошибки. Как правило, предупреждение отправляется при закрытии подключения, при получении неправильного сообщения, которое
невозможно расшифровать, или при отмене операции пользователем.
4. Уровень записи
Протокол на уровне слоя записи получает данные, шифрует/дешифрирует и передает их на транспортный слой. При шифровании
данных они разбиватся на блоки размером, который подходит криптографическому алгоритму. При этом используется информация,
которая была согласована на уровне подтверждения подключения. В некоторых случая на этом уровне выполняется сжатие
(распаковка) данных.
Два вида SSL соединения
SSL соединение может быть двух видов : простая (односторонняя) SSL аутентификация и двусторонняя SSL аутентификация.
Односторонняя SSL аутентификация
При односторонней аутентификации сертификат с парным приватным ключом располагаются только на сервере. Зашифрованные с помощью открытого ключа данные могут быть расшифрованы с помощью приватного ключа на сервере. Клиент, устанавливающий соединение с сервером, проверяет его сертификат прежде чем установить шифрованное соединение. Проверка сертификата включает :
- действителен ли сертификат, т.е. не окончился ли срок действия сертификата;
- соответствие сертификата имени хоста;
- наличие в списке клиента/браузера центра сертификации, выдавшего сертификат;
- действительность цифровой подписи на сертификате.
При односторонней SSL аутентификации клиент не проверяется сервером. Следующий рисунок демонстрирует последовательность установления защищенного SSL соединения между сервером и клиентом, в качестве которого может выступать обычный браузер.
Если сервер аутентифицирован, то его сообщение о сертификации должно обеспечить сертификационную цепочку, ведущую к доверенному центру сертификации. То есть, аутентифицированный сервер должен отправить клиенту сертификат, подписанный одним из центров сертификации.
Двусторонняя SSL аутентификация
При двусторонней аутентификации обе стороны (и сервер, и клиент) предоставляют сертификаты для проверки подлинности друг друга при установке шифрованного соединения, как это представлено на следующем рисунке.
Шифрование пересылаемых данных
Для шифрования данных можно использовать два способа : симметричный и ассиметричный.
Симметричное шифрование
При симметричном способе шифрования используется один и тот же ключ как для шифрования, так и для дешифрирования.
Если две стороны договариваются обмениваться симметрично зашифрованными сообщениями в безопасном режиме, то они должны
иметь одинаковые ключи. Так как процесс симметричного шифрования и дешифрирования проходит быстрее, чем при ассиметричном
шифровании, то симметричное шифрование обычно используется для кодирования большого объема данных. Обычно используются
алгоритмы DES (Data Encryption Standard), 3-DES (тройной DES), RC2, RC4, и AES (Advanced Encryption Standard).
Ассиметричное шифрование
При ассиметричном шифровании используется пара ключей : открытый/публичный (public) и закрытый (private). Открытый ключ
центр сертификации размещает в самом сертификате владельца (заголовок subject). Секретный ключ не должен никому окрываться.
Эти ключи работают в паре и используются для выполнения противоположных функций второго ключа. Так, например, если открытым
ключом зашифровать данные, то расшифровать их можно будет только закрытым ключом. И наоборот, если данные шифруются закрытым
ключом, то открытый ключ должен данные дешифрировать.
Взаимосвязь открытого и закрытого ключей позволяет производить обмен открытыми ключами между сторонами (сервер и клиент), чтобы они могли
- отправлять на сервер шифрованные данные, которые может дешифрировать только сервер и
- получать от сервера шифрованные данные, которые они могут дешифрировать.
В случае двустороннего обмена ключами (двусторонняя аутентификация) обе стороны выступают и в качестве сервера, и в качестве клиента.
Протокол SSL использует ассиметричное шифрование для подтвердждения клиентом подлинности сервера/клиента, а также для определения ключа сессии. Ключ сессии необходим для шифрования большого объема данных (симметричный алгоритм). Это объединяет ассиметричное шифрование (проверка подлинности) и быстрое симметричное шифрование больших объемов данных.
Самым распространенным алгоритмом при ассиметричном шифровании является RSA, названный в честь разработчиков Rivest, Shamir, Adleman.
Что такое порт SSL? Техническое руководство для HTTPS
Получите данные SSLSecure Sockets Layer (SSL) — это технология, отвечающая за аутентификацию данных и шифрование для интернет-соединений. Он шифрует данные, передаваемые через Интернет между двумя системами (обычно между сервером и клиентом), чтобы они оставались конфиденциальными. А поскольку важность онлайн-конфиденциальности растет, вам следует ознакомиться с портом SSL.
Поскольку данные могут быть отправлены с использованием SSL или без него, один из способов указать безопасное соединение — это номер порта. По умолчанию соединения HTTPS используют порт TCP 443. Незащищенный протокол HTTP использует порт 80.
Обычно используемые TCP-порты
Тем, кто отвечает за настройку и управление веб-хостингом, полезно знать номера для общих служб, таких как порт SSL. Используйте приведенные ниже таблицы, чтобы быстро найти номера портов и их основные функции.
Интернет
| Порт # | Функция |
|---|---|
| 80 | HTTP |
| 443 | SSL |
| 21 | FTP |
| 990 | FTP |
| 22 | SFTP / SSH |
| 3306 | MySQL |
Электронная почта
| Порт # | Функция |
|---|---|
| 110 | POP — входящий |
| 995 | POP SSL — входящий |
| 143 | IMAP — входящие |
| 993 | IMAP SSL — входящий |
| 25, 80, 3535 | SMTP — исходящий |
| 465 | SMTP SSL — исходящий |
Вы можете увидеть, какие порты GoDaddy использует для электронной почты, помимо поиска информации о портах SSL, в Справочном центре GoDaddy.
cPanel
| Порт # | Функция |
|---|---|
| 2082 | cPanel Входящий TCP |
| 2083 | cPanel SSL входящий TCP |
| 2086 | WHM TCP, входящий |
| 2087 | WHM SSL TCP, входящий |
| 2089 | WHM SSL TCP, входящий |
| 2095 | Веб-почта Входящий TCP |
| 2096 | Веб-почта SSL TCP, входящий |
Вы можете увидеть, какие порты GoDaddy использует для cPanel, в Справочном центре GoDaddy.
Как работают HTTPS и SSL?
HTTP не является отдельным протоколом от HTTPS. Скорее, HTTPS работает путем установления безопасного HTTP-соединения с использованием SSL. Следовательно, стеки протоколов для HTTP и HTTPS выглядят одинаково:
| Слой | Стек протоколов HTTP | Стек протоколов HTTPS |
|---|---|---|
| Уровень приложения | HTTP | HTTP |
| Уровень безопасности | SSL (TLS) | |
| Транспортный уровень | TCP | TCP |
| Сетевой уровень | IP | IP |
| Уровень канала данных | Сетевые интерфейсы | Сетевые интерфейсы |
Единственная разница в том, что HTTPS работает поверх SSL.Для создания этого безопасного подключения к Интернету на веб-сервере устанавливается сертификат SSL. Сертификат SSL удостоверяет личность организации для активации протокола HTTPS, чтобы данные могли безопасно передаваться с веб-сервера в веб-браузер.
Различия между сертификатами и протоколами
Протокол HTTPS и сертификат SSL — это два разных, но очень важных фактора в создании безопасного интернет-соединения.
- Протокол HTTPS обеспечивает канал, по которому данные шифруются и безопасно передаются. Сертификаты
- SSL просто используются для аутентификации важной информации, когда пользователь Интернета пытается отправить информацию через безопасное соединение.
Следовательно, безопасное соединение определяется конфигурацией вашего сервера, а не самим сертификатом.
В чем разница между SSL и TLS?
Transport Layer Security (TLS) — это обновление протокола SSL. Первоначальный протокол SSL был разработан Netscape еще в 1995 году и опубликован как SSL 2.0. С тех пор были внесены обновления для обеспечения более надежного и безопасного шифрования.
В 1999 году TLS 1.0 был выпущен как обновление SSL 3.0. С тех пор TLS стал основной технологией, используемой для защиты данных через интернет-соединения и SSL. Однако, поскольку термин SSL более широко известен, название сохраняется, несмотря на то, что технология обесценивается.
Почему я должен беспокоиться о моем порте SSL?
Казалось бы, небольшой нюанс, ваш порт SSL важен по ряду причин.Во-первых, HTTP выходит из моды. Фактически, согласно отчету Google о прозрачности HTTPS, более 70 процентов веб-страниц загружаются через HTTPS в Google Chrome в США. Помимо причины, по которой «это делают все остальные», использование HTTPS имеет массу преимуществ по сравнению с HTTP.
Ограничьте подверженность преступной деятельности с помощью SSL
HTTPS предлагает дополнительный уровень защиты от цифрового подслушивания, с помощью которого злоумышленники отслеживают сетевую активность, чтобы украсть ценную информацию, например учетные данные для входа.Поскольку HTTPS зашифрован, это помогает предотвратить этот вид преступной деятельности.
HTTPS требуется для соответствия PCI
Если вы собираете информацию о кредитной карте на своем веб-сайте, индустрия платежных карт требует от вас использовать HTTPS.
HTTPS может загружать веб-страницы быстрее, чем HTTP
HTTPS не только обеспечивает более безопасный просмотр, но и может положительно повлиять на время загрузки содержимого вашего сайта. Если вам нужны доказательства, убедитесь сами.
Сделайте просмотр веб-страниц более надежным
Большинство основных веб-браузеров указывают, является ли сайт безопасным, в адресной строке с помощью значка замка или слова «безопасный».
веб-браузеры, такие как Chrome, стремятся предупреждать пользователей, когда они заходят на сайт, который не использует HTTPS.
SSL может повысить ваш SEO
HTTPS предпочитают основные поисковые системы и обычно считают полезным для SEO.Крайне важно, чтобы вы правильно реализовали HTTPS и предприняли несколько дополнительных шагов, чтобы воспользоваться преимуществами SEO. Следуйте этому контрольному списку миграции HTTPS для SEO, чтобы убедиться, что вы все поняли правильно.
Как мне получить SSL?
Сертификаты SSLможно приобрести в центре сертификации (CA), например в GoDaddy. После покупки сертификата следуйте инструкциям вашего хостинг-провайдера, чтобы установить сертификат SSL.
,Что такое SSL? | Обзор протокола Secure Sockets Layer
Как устанавливается соединение с шифрованием SSL?
Шаг 1 : Пользователь запрашивает безопасное соединение с веб-сайтом. Это делается путем ввода URL-адреса, начинающегося с «HTTPS», в интернет-браузере. Например, https://www.example.com
Шаг 2 : Веб-сайт отвечает на запрос пользователя и отправляет свой сертификат SSL в браузер для аутентификации.Это известно как «SSL-рукопожатие» .
Шаг 3 : браузер пользователя проверяет действительность сертификата SSL. Браузер отображает значок замка в URL-адресе, указывая на то, что веб-сайт безопасен и с ним можно общаться.
Шаг 4 : После успешной проверки между браузером и веб-сайтом устанавливается безопасное соединение. Дальнейшая коммуникация между браузером и сайтом зашифрована.Информация, передаваемая между двумя сторонами, может быть расшифрована только двумя вовлеченными сторонами. Хакеры не смогут расшифровать информацию, передаваемую между двумя объектами.
Как узнать, использует ли сайт SSL?
Интернет-браузеры, такие как Chrome, Firefox и Internet Explorer, указывают, использует ли веб-сайт SSL, предлагая несколько визуальных подсказок:
- URL-адрес сайта будет начинаться с https: //, где s означает безопасный
- Браузер покажет значок замка в адресной строке
- При использовании некоторых SSL-сертификатов адресная строка становится зеленой, указывая на то, что сайт использует сертификат расширенной проверки (самый безопасный и надежный из доступных сертификатов).
Что означает SSL для посетителей?
Сертификат SSL с подтверждением домена (DV) указывает, что соединение между пользователем и веб-сайтом надежно зашифровано.Вся информация, которой обмениваются пользователь и веб-сайт, защищена и не может быть перехвачена и прочитана третьей стороной. Однако сертификаты, подтвержденные доменом, не подтверждают личность владельца веб-сайта. Информация зашифрована, но пользователи понятия не имеют, является ли веб-сайт, на который они отправляют свои данные, надежным бизнесом. Сертификаты, подтвержденные организацией (OV) и сертификаты расширенной проверки (EV), обеспечивают как шифрование, так и уверенность в том, что веб-сайту можно доверять.Это связано с тем, что сертификаты OV и EV не выдаются до тех пор, пока не будет проведена проверка данных о владельце веб-сайта. Дополнительная информация в сертификатах OV и EV включает полное название компании и их юридический адрес. Эти детали улучшают репутацию организации в Интернете в глазах веб-браузеров, а также пользователей. И чем более легитимным выглядит веб-сайт, тем больше он будет приносить прибыль.
Где я могу получить сертификат SSL для своего сайта?
SSL-сертификаты можно приобрести в центрах сертификации.Сертификат SSL будет распознан интернет-браузерами и мобильными устройствами только в том случае, если он подписан доверенным центром сертификации (CA). Если это не так, то конечный пользователь увидит сообщения об ошибках при подключении к сайту. Первый шаг подачи заявки на сертификат — это создание владельцем веб-сайта запроса на подпись сертификата (CSR) на своем веб-сервере. Они отправят этот запрос на подпись в ЦС вместе с названием своей компании, служебным адресом и другими деталями. Центр сертификации выдаст сертификат после подтверждения личности организации.
Каковы преимущества использования SSL?
Помимо шифрования и защиты данных от взлома, вы получаете следующие преимущества:
- Вы укрепите доверие посетителей и сможете повысить коэффициент конверсии. : Интернет-пользователи были обучены искать надежный замок, когда они рассматривают возможность онлайн-транзакции.Сертификат от доверенного центра сертификации создаст этот замок на вашем сайте, потому что сертификат распознается всеми основными интернет-браузерами и мобильными устройствами. Это означает, что посетители вашего веб-сайта смогут четко видеть, что ваша операция безопасна, и будут более склонны совершать покупки вместе с вами.
- Вы точно знаете, что общаетесь с предполагаемым получателем. : Когда две стороны общаются через Интернет, выяснить, действительно ли вы взаимодействуете с предполагаемой стороной, непросто.Но с помощью SSL эта неопределенность в отношении предполагаемого получателя устраняется, поскольку соединение SSL позволяет пользователю (веб-браузеру) аутентифицировать веб-сайт (веб-сервер) до начала передачи данных.
- Трафик на ваш веб-сайт может увеличиться. : 3. Различные поисковые системы теперь дают преимущества SEO для страниц https по сравнению со страницами без HTTPS. Этот естественный рост вашего SEO-рейтинга может увеличить посещаемость вашего сайта. Чем больше трафика вы получите, тем лучше для вашего бизнеса.
Что такое «криптографический протокол»?
Протокол — это просто набор правил или инструкций, которые определяют, как действовать или взаимодействовать в данной ситуации. Криптографический протокол разработан для обеспечения безопасного обмена данными при заданном наборе обстоятельств. Криптографический протокол, наиболее знакомый пользователям Интернета, — это протокол Secure Sockets Layer (или SSL ), который (со своим потомком — протоколом Transport Layer Security или TLS ) защищает номера кредитных карт и другую конфиденциальную информацию, а также который содержит символ замка в адресной строке браузера, чтобы вы знали, что можете доверять соединению.
Хотя SSL (или, точнее, SSL / TLS) представляет собой сложный протокол с несколькими (часто изменяемыми) компонентами, вы можете думать о «свиньей латыни» как о примере (очень простого и не очень безопасного) криптографического протокола — назовите его Pig Latin Protocol (или PLP ) — с использованием следующего набора правил:
- «Если слово начинается с согласной, переместите первый слог в конец».
- «Добавляйте« -ay »в конце каждого слова».
Например, если Энди и Бренда оба знают и соглашаются передавать с помощью PLP (но их учитель математики миссисЧивер не делает этого), они могут попытаться использовать его для защиты своего общения (т. Е. Делиться ответами в классе).
Таким образом:
«Ответ на число шесть — сорок две целых два десятых».
с примененным PLP становится:
«Eethay answeray ootay umbernay ixsay isay ortyfay-ootay ointpay ootay».
ПРИМЕЧАНИЕ: Pig Latin делает очень плохим выбором в качестве криптографического протокола — его легко расшифровать, он позволяет передавать некоторые части сообщения в четко понятной форме (ответ ? ) и лежащий в основе код широко известен.По этой и многим другим причинам мы предлагаем , а не , попытаться использовать этот метод для сдачи алгебры, и SSL.com не несет ответственности, если вас вызовут в офис директора.
PLP, кстати, является примером симметричного шифрования, поскольку один и тот же «ключ» и кодирует, и декодирует информацию. Вообще говоря, симметричное шифрование — единственный вариант, применимый в реальных сценариях — альтернативное асимметричное шифрование с использованием двух наборов ключей слишком громоздко для повседневного использования.Однако SSL / TLS использует асимметричное шифрование в начальном «рукопожатии» для установки каждого нового безопасного сеанса с симметричным шифрованием.
Более подробную информацию о том, как работает SSL / TLS, можно найти в нашей статье о подтверждении SSL / TLS. Как всегда, если у вас есть какие-либо вопросы, свяжитесь с нами на SSL.com, где мы считаем, что чем безопаснее, тем лучше.
.ssl — оболочка TLS / SSL для объектов сокетов — документация Python 3.8.5
Исходный код: Lib / ssl.py
Этот модуль обеспечивает доступ к протоколу безопасности транспортного уровня (также известному как «Secure Уровень сокетов ») средства шифрования и одноранговой аутентификации для сети. сокеты, как на стороне клиента, так и на стороне сервера. Этот модуль использует OpenSSL библиотека. Он доступен во всех современных системах Unix, Windows, Mac OS X и возможно, дополнительные платформы, если на этой платформе установлен OpenSSL.
Примечание
Некоторое поведение может зависеть от платформы, поскольку вызовы выполняются API сокетов операционной системы. Установленная версия OpenSSL также может вызывают изменения в поведении. Например, TLSv1.1 и TLSv1.2 поставляются с openssl версии 1.0.1.
Предупреждение
Не используйте этот модуль, не ознакомившись с рекомендациями по безопасности. Делать это может привести к ложному чувству безопасности, так как настройки по умолчанию ssl-модуль не обязательно подходит для вашего приложения.
В этом разделе описаны объекты и функции модуля ssl ; для большего
общая информация о TLS, SSL и сертификатах читатель отсылает к
документы в разделе «См. также» внизу.
Этот модуль предоставляет класс ssl.SSLSocket , производный от socket.socket и предоставляет оболочку, подобную сокету, которая также
шифрует и расшифровывает данные, передаваемые через сокет с помощью SSL. Он поддерживает
дополнительные методы, такие как getpeercert () , который извлекает
сертификат другой стороны соединения и шифр () , который
извлекает шифр, используемый для безопасного соединения.
Для более сложных приложений класс ssl.SSLContext помогает управлять настройками и сертификатами, которые затем могут быть унаследованы
сокетами SSL, созданными с помощью метода SSLContext.wrap_socket () .
Изменено в версии 3.5.3: Обновлено для поддержки связывания с OpenSSL 1.1.0
Изменено в версии 3.6: OpenSSL 0.9.8, 1.0.0 и 1.0.1 устарели и больше не поддерживаются. В будущем для модуля ssl потребуется как минимум OpenSSL 1.0.2 или 1.1.0.
Функции, константы и исключения
Создание сокета
Начиная с Python 3.2 и 2.7.9, рекомендуется использовать SSLContext.wrap_socket () из экземпляра SSLContext для обертывания
сокеты как объекты SSLSocket . Вспомогательные функции create_default_context () возвращает новый контекст с безопасным значением по умолчанию
Настройки. Старая функция wrap_socket () устарела, так как она
оба неэффективны и не поддерживают указание имени сервера (SNI) и
соответствие имени хоста.
Пример клиентского сокета с контекстом по умолчанию и двойным стеком IPv4 / IPv6:
импортный разъем
импортировать ssl
hostname = 'www.python.org'
context = ssl.create_default_context ()
с socket.create_connection ((hostname, 443)) как sock:
с context.wrap_socket (sock, server_hostname = hostname) как ssock:
печать (ssock.version ())
Пример клиентского сокета с настраиваемым контекстом и IPv4:
hostname = 'www.python.org'
# PROTOCOL_TLS_CLIENT требует действительной цепочки сертификатов и имени хоста
контекст = ssl.SSLContext (ssl.PROTOCOL_TLS_CLIENT)
context.load_verify_locations ( 'путь / к / cabundle.pem')
с socket.socket (socket.AF_INET, socket.SOCK_STREAM, 0) как sock:
с context.wrap_socket (sock, server_hostname = hostname) как ssock:
печать (ssock.version ())
Пример серверного сокета, прослушивающего локальный IPv4:
контекст = ssl.SSLContext (ssl.PROTOCOL_TLS_SERVER)
context.load_cert_chain ('/ путь / к / certchain.pem', '/path/to/private.key')
с socket.socket (socket.AF_INET, socket.SOCK_STREAM, 0) как носок:
sock.bind (('127.0.0.1', 8443))
sock.listen (5)
с context.wrap_socket (sock, server_side = True) как ssock:
conn, addr = ssock.accept ()
...
Создание контекста
Удобная функция помогает создавать SSLContext объектов для общих
цели.
-
ssl.create_default_context( target = Purpose.SERVER_AUTH , cafile = None , capath = None , cadata = None ) Вернуть новый объект
SSLContextс настройками по умолчанию для данная цель .Настройки выбираются модулемssl, и обычно представляют более высокий уровень безопасности, чем при вызовеSSLContextнапрямую конструктор.cafile , capath , cadata представляют дополнительные сертификаты CA для доверие для проверки сертификата, как в
SSLContext.load_verify_locations (). Если все троеНет, эта функция может доверять системе по умолчанию Вместо этого сертификаты CA.Настройки:
PROTOCOL_TLS,OP_NO_SSLv2иOP_NO_SSLv3с наборами шифров с высоким уровнем шифрования без RC4 и без неаутентифицированных комплектов шифров.ПередачаSERVER_AUTHкак цель устанавливаетverify_mode снаCERT_REQUIREDи либо загружает сертификаты CA (если хотя бы один из cafile , capath или cadata ) или используетSSLContext.load_default_certs ()для загрузки сертификаты CA по умолчанию.Когда