Tls ssl что это: TLS и SSL: Необходимый минимум знаний
Содержание
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.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/TLS И HTTPS? Установка Сертификата Безопасности
Что такое SSL? SSL является аббревиатурой для Secure Sockets Layer. Это тип цифровой безопасности, которая позволяет зашифровать связь между веб-сайтом и веб-браузером. Технология в настоящее время устарела и полностью заменена TLS.
Что такое TLS? Это означает Transport Layer Security и обеспечивает конфиденциальность данных так же, как и SSL. Поскольку SSL фактически больше не используется, это правильный термин, который люди должны начать использовать.
Что таоке HTTPS? Это безопасное расширение HTTP. Веб-сайты, устанавливающие и настраивающие SSL/TLS-сертификат, могут использовать протокол HTTPS для установления безопасного соединения с сервером.
- Цель SSL/TLS — сделать соединение безопасным для передачи конфиденциальной информации, включая личные данные, информацию о платеже или регистрации.
- Это альтернатива простой передаче текстовых данных, в которой ваше соединение с сервером не зашифровано, и это затрудняет мошенникам и хакерам отслеживание соединения и кражу ваших данных.
- Большинство людей знают, что такое SSL/TLS. Это сертификаты, которые используются веб-мастерами для защиты своих веб-сайтов и обеспечения безопасного доступа для людей к транзакциям.
- Вы можете определить, использует ли веб-сайт сертификат безопасности, потому что рядом с URL-адресом в адресной строке появится значок маленького замочка.
В этом руководстве вы узнаете:
Как работают сертификаты SSL/TLS?
Сертификаты SSL/TLS работают путём цифровой привязки криптографического ключа к идентифицирующей информации компании. Это позволяет им шифровать передачу данных таким образом, что они не могут быть расшифрованы третьими лицами.
Получить Сертификат SSL
SSL/TLS работает, имея как частный, так и открытый ключ, а также ключи сеанса для каждого уникального безопасного сеанса. Когда посетитель вводит защищённый SSL-адрес в свой веб-браузер или переходит на безопасную страницу, браузер и веб-сервер устанавливают соединение.
Во время первоначального подключения общедоступные и закрытые ключи будут использоваться для создания ключа сеанса, который затем будет использоваться для шифрования и дешифрования передаваемых данных. Этот ключ сеанса останется действительным в течение ограниченного времени и будет использоваться только для данного сеанса.
Вы можете определить, использует ли сайт SSL, по значку замочка или зелёной полосе в верхней части браузера. Вы можете щёлкнуть по этому значку, чтобы просмотреть информацию о том, кому принадлежит сертификат, и управлять настройками SSL.
Когда и почему SSL/TLS необходимы?
SSL/TLS является обязательным, когда передаётся конфиденциальная информация, такая как имена пользователей и пароли или информация о платёжной обработке.
Цель SSL/TLS состоит в том, чтобы убедиться, что только один человек — лицо или организация, утверждённое пользователем, может получить доступ к передаваемым данным. Это особенно важно, когда вы думаете о том, между сколькими устройствами и серверами передаются данные до того, как они достигнут своего пункта назначения.
Получить Сертификат SSL
Существует три основных варианта использования SSL/TLS для вашего веб-сайта:
- Когда вам нужна аутентификация: любой сервер может претендовать на роль вашего сервера, захватив информацию, которую люди передают. SSL/TLS позволяет вам подтвердить личность вашего сервера, чтобы люди знали, что вы являетесь тем, кем вы говорите.
- Чтобы внушить доверие: если вы используете сайт электронной коммерции или спрашиваете пользователей о том, какие данные важны для них, вы должны поддерживать чувство доверия. Использование сертификата SSL/TLS является видимым способом показать посетителям, что они могут вам доверять, и это намного эффективнее всего, что вы могли бы сказать о себе.
- Когда вам нужно соблюдать отраслевые стандарты: в некоторых отраслях, таких как финансовая, вам необходимо будет поддерживать определённые базовые уровни безопасности. Существуют также правила в области платёжных карт (PCI), которых необходимо придерживаться, если вы хотите принять информацию о кредитной карте на своём веб-сайте. И одним из этих требований является использование сертификата SSL/TLS.
Помните, что SSL можно использовать практически на любом устройстве, что также делает его универсальным выбором безопасности в современном мире. Преимущества использования SSL-сертификата перевешивают время и денежные средства, необходимые для их настройки, так что вам нечего терять.
Влияет ли SSL/TLS на SEO?
Короткий ответ: да.
Google внёс изменения в свой алгоритм еще в 2014 году, чтобы определить приоритеты веб-сайтов, которые использовали SSL-сертификат, и с тех пор они продолжают уделять особое внимание сертификатам SSL. Они официально заявили, что сайты со статистикой SSL обойдут сайты без таковой, чтобы все остальные факторы были равны, и хотя защищённые сайты составляют только 1% результатов, 40% запросов возвращают хотя бы один защищённый SSL сайт на первую страницу.
Получить Сертификат SSL
На практике SSL не слишком сильно влияет, когда дело доходит до SEO, и простая установка SSL-сертификата на ваш сайт будет иметь гораздо меньшее значение, чем создание регулярного свежего контента и создание сильного профиля входящей ссылки. Но это не значит, что вы должны совсем забыть о них.
Также важно помнить, что поисковые системы используют целый ряд различных показателей, чтобы определить, где находится сайт. Одним из таких показателей является то, как часто люди возвращаются с вашего сайта на страницу результатов, и наличие сертификата SSL может повлиять на разницу между теми, кто покупает у вас, а кто проходит мимо. Множество других показателей, которые используются для ранжирования сайтов, могут быть затронуты, когда вы выбираете, использовать ли SSL-сертификат или нет.
Настройка SSL-сертификата повлияет на производительность поисковой системы (англ) вашего сайта, но вы должны использовать его не только по этой причине. Вместо этого настройте SSL-сертификат, чтобы повысить доверие между вашими посетителями и улучшить SEO в качестве бонуса.
Какое отношение имеют SSL/TLS к HTTPS?
Когда вы устанавливаете SSL-сертификат, вы настраиваете его для передачи данных с помощью HTTPS. Эти две технологии идут рука об руку, и вы не можете использовать одно без другого.
URL-адресам предшествует либо HTTP (Hypertext Transfer Protocol), либо протокол HTTPS (Hypertext Transfer Protocol Secure). Это эффективно определяет, как передаются любые данные, которые вы отправляете и получаете.
SSL/TLS не требуют огромных затрат. Найдите доступные SSL-предложения с Hostinger!
Это означает, что другой способ определить, использует ли сайт сертификат SSL, — это проверить URL-адрес и посмотреть, содержит ли он HTTP или HTTPS. Это связано с тем, что для соединений HTTPS требуется сертификат безопасности SSL.
Chrome указывает, использует ли сайт SSL/TLS
В большинстве основных браузеров, включая Google Chrome, Firefox и Microsoft Edge, наличие безопасного соединения будет заметно отображаться при доступе пользователей к сайту. Например, в Chrome вы увидите значок зелёного замочка в адресной строке рядом с сообщением Безопасный. Пользователи могут просмотреть более подробную информацию о сертификате SSL, щёлкнув по нему.
Кроме того, с момента введения Chrome 68 (англ) в июле 2018 года веб-сайты без сертификата SSL/TLS отображают предупреждение Небезопасно.
Поскольку браузеры активно показывают, безопасны ли сайты, в ваших интересах как владелец веб-сайта использовать подсказку и защитить свой сайт. Таким образом, посетители могут сразу увидеть, что ваш сайт надёжен, как только они его посещают.
Как добавить SSL/TLS на свой сайт?
Добавление SSL/TLS-сертификата на ваш сайт может быть запутанным и должно быть предпринято только профессионалом. Вы должны знать, есть ли у вас статья в бюджете на того, кто в этом разбирается.
Первый шаг — включить SSH-доступ перед установкой клиента ACME. На этом этапе вы можете создать свой сертификат SSL/TLS и установить его через область администрирования вашего веб-хоста. Мы написали полное руководство о том, как это сделать, что должно помочь, если вы готовы начать работу самостоятельно.
Если вы ищете платного поставщика сертификатов SSL/TLS, обратите внимание на Hostinger. Мы предлагаем пожизненную защиту SSL/TLS за одноразовую оплату. Кроме того, бесплатный сертификат поставляется вместе с нашим ежегодным планом хостинга Бизнес.
После того, как ваш сертификат готов, вы можете активировать HTTPS, вставив фрагмент кода в ваш файл .htaccess.
Как добавить SSL/TLS на сайт WordPress?
Немного легче начать работу с SSL/TLS в WordPress. Он предлагает плагины, такие как Really Simple SSL (англ) и SSL Insecure Content Fixer (англ), которые обрабатывают техническую часть для вас. Однако вам всё равно придётся приобретать SSL-сертификат у поставщика.
После того, как ваш SSL-сертификат был приобретён и установлен, вам всё равно нужно будет изменять настройки на панели инструментов WordPress (или использовать один из вышеупомянутых плагинов).
Хорошей новостью является то, что всё, что вам нужно сделать, это войти в WordPress и перейти в Настройки>Общие. Прокрутите вниз до полей WordPress Address (URL) и Site Address (URL) и измените их с HTTP на HTTPS. Обязательно сохраните изменения и проверьте свой сайт, чтобы убедиться, что всё работает как нужно.
Вывод
Что такое SSL? Это означает Secure Sockets Layer (в то время как TLS поддерживает Transport Layer Security) и показывает посетителям, что они могут безопасно передавать конфиденциальную информацию на сервер и с сервера. Он шифрует все передачи данных таким образом, что они не могут быть расшифрованы третьими сторонами, такими как хакеры и мошенники.
Вы можете узнать, использует ли веб-сайт SSL/TLS по значку висячего замочка или зелёной полосе в верхней части браузера. Обычно вы можете щёлкнуть по значку в своём браузере, чтобы узнать, кому принадлежит сертификат.
SSL/TLS влияют на безопасность, оптимизацию в поисковых системах и могут помочь вашему сайту превосходить конкурентов. С учётом сказанного, это не какой-то мощный инструмент для SEO, сертификаты SSL/TLS должны использоваться потому, что они являются лучшей практикой в вопросах безопасности, а не потому, что вы думаете, что они помогут вам повысить рейтинг в поисковых системах.
И, конечно, если вам нужна помощь при запуске сертификата SSL или если вы хотите воспользоваться пожизненной безопасностью SSL, свяжитесь с нами. Мы будем рады помочь!
Анна долгое время работала в сфере социальных сетей и меседжеров, но сейчас активно увлеклась созданием и сопровождением сайтов. Она любит узнавать что-то новое и постоянно находится в поиске новинок и обновлений, чтобы делиться ими с миром. Ещё Анна увлекается изучением иностранных языков. Сейчас её увлёк язык программирования!
Что такое TLS / Хабр
Данный текст является вольным переводом вот этой главы замечательной книги «High Performance Browser Networking» авторства Ильи Григорика. Перевод выполнялся в рамках написания курсовой работы, потому очень вольный, но тем не менее будет полезен тем, кто слабо представляет что такое TLS, и с чем его едят.
Общие сведения о TLS
Протокол TLS (transport layer security) основан на протоколе SSL (Secure Sockets Layer), изначально разработанном в Netscape для повышения безопасности электронной коммерции в Интернете. Протокол SSL был реализован на application-уровне, непосредственно над TCP (Transmission Control Protocol), что позволяет более высокоуровневым протоколам (таким как HTTP или протоколу электронной почты) работать без изменений. Если SSL сконфигурирован корректно, то сторонний наблюдатель может узнать лишь параметры соединения (например, тип используемого шифрования), а также частоту пересылки и примерное количество данных, но не может читать и изменять их.
Конкретное место TLS (SSL) в стеке протоколов Интернета показано на схеме:
После того, как протокол SSL был стандартизирован IETF (Internet Engineering Task Force), он был переименован в TLS. Поэтому хотя имена SSL и TLS взаимозаменяемы, они всё-таки отличаются, так как каждое описывает другую версию протокола.
Первая выпущенная версия протокола имела название SSL 2.0, но была довольно быстра заменена на SSL 3.0 из-за обнаруженных уязвимостей. Как уже упоминалось, SSL был разработан компанией Netscape, так что в январе 1999 года IETF открыто стандартизирует его под именем TLS 1.0. Затем в апреле 2006 года была опубликована версия TLS 1.1, которая расширяла первоначальные возможности протокола и закрывала известные уязвимости. Актуальная версия протокола на данный момент – TLS 1.2, выпущенная в августе 2008 года.
Как уже говорилось, TLS был разработан для работы над TCP, однако для работы с протоколами дейтаграмм, такими как UDP (User Datagram Protocol), была разработана специальная версия TLS, получившая название DTLS (Datagram Transport Layer Security).
Шифрование, аутентификация и целостность
Протокол TLS предназначен для предоставления трёх услуг всем приложениям, работающим над ним, а именно: шифрование, аутентификацию и целостность. Технически, не все три могут использоваться, однако на практике, для обеспечения безопасности, как правило используются все три:
- Шифрование – сокрытие информации, передаваемой от одного компьютера к другому;
- Аутентификация – проверка авторства передаваемой информации;
- Целостность – обнаружение подмены информации подделкой.
Для того чтобы установить криптографически безопасный канал данных, узлы соединения должны согласовать используемые методы шифрования и ключи. Протокол TLS однозначно определяет данную процедуру, подробнее это рассмотрено в пункте TLS Handshake. Следует отметить, что TLS использует криптографию с открытым ключом, которая позволяет узлам установить общий секретный ключ шифрования без каких-либо предварительных знаний друг о друге.
Также в рамках процедуры TLS Handshake имеется возможность установить подлинность личности и клиента, и сервера. Например, клиент может быть уверен, что сервер, которые предоставляет ему информацию о банковском счёте, действительно банковский сервер. И наоборот: сервер компании может быть уверен, что клиент, подключившийся к нему – именно сотрудник компании, а не стороннее лицо (данный механизм называется Chain of Trust и будет рассмотрен в соответствующем разделе).
Наконец, TLS обеспечивает отправку каждого сообщения с кодом MAC (Message Authentication Code), алгоритм создания которого – односторонняя криптографическая функция хеширования (фактически – контрольная сумма), ключи которой известны обоим участникам связи. Всякий раз при отправке сообщения, генерируется его MAC-значение, которое может сгенерировать и приёмник, это обеспечивает целостность информации и защиту от её подмены.
Таким образом, кратко рассмотрены все три механизма, лежащие в основе криптобезопасности протокола TLS.
TLS Handshake
Перед тем, как начать обмен данными через TLS, клиент и сервер должны согласовать параметры соединения, а именно: версия используемого протокола, способ шифрования данных, а также проверить сертификаты, если это необходимо. Схема начала соединения называется TLS Handshake и показана на рисунке:
Разберём подробнее каждый шаг данной процедуры:
- Так как TLS работает над TCP, для начала между клиентом и сервером устанавливается TCP-соединение.
- После установки TCP, клиент посылает на сервер спецификацию в виде обычного текста (а именно версию протокола, которую он хочет использовать, поддерживаемые методы шифрования, etc).
- Сервер утверждает версию используемого протокола, выбирает способ шифрования из предоставленного списка, прикрепляет свой сертификат и отправляет ответ клиенту (при желании сервер может так же запросить клиентский сертификат).
- Версия протокола и способ шифрования на данном моменте считаются утверждёнными, клиент проверяет присланный сертификат и инициирует либо RSA, либо обмен ключами по Диффи-Хеллману, в зависимости от установленных параметров.
- Сервер обрабатывает присланное клиентом сообщение, сверяет MAC, и отправляет клиенту заключительное (‘Finished’) сообщение в зашифрованном виде.
- Клиент расшифровывает полученное сообщение, сверяет MAC, и если всё хорошо, то соединение считается установленным и начинается обмен данными приложений.
Ясно, что установление соединения TLS является, вообще говоря, длительным и трудоёмким процессом, поэтому в стандарте TLS есть несколько оптимизаций. В частности, имеется процедура под названием “abbreviated handshake”, которая позволяет использовать ранее согласованные параметры для восстановления соединения (естественно, если клиент и сервер устанавливали TLS-соединение в прошлом). Данную процедура рассмотрена подробнее в пункте «Возобновление сессии».
Также имеется дополнительное расширение процедуры Handshake, которое имеет название TLS False Start. Это расширение позволяет клиенту и серверу начать обмен зашифрованными данными сразу после установления метода шифрования, что сокращает установление соединения на одну итерацию сообщений. Об этом подробнее рассказано в пункте “TLS False Start”.
Обмен ключами в протоколе TLS
По различным историческим и коммерческим причинам чаще всего в TLS используется обмен ключами по алгоритму RSA: клиент генерирует симметричный ключ, подписывает его с помощью открытого ключа сервера и отправляет его на сервер. В свою очередь, на сервере ключ клиента расшифровывается с помощью закрытого ключа. После этого обмен ключами объявляется завершённым. Данный алгоритм имеет один недостаток: эта же пара отрытого и закрытого ключей используется и для аутентификации сервера. Соответственно, если злоумышленник получает доступ к закрытому ключу сервера, он может расшифровать весь сеанс связи. Более того, злоумышленник может попросту записать весь сеанс связи в зашифрованном варианте и занять расшифровкой потом, когда удастся получить закрытый ключ сервера. В то же время, обмен ключами Диффи-Хеллмана представляется более защищённым, так как установленный симметричный ключ никогда не покидает клиента или сервера и, соответственно, не может быть перехвачен злоумышленником, даже если тот знает закрытый ключ сервера. На этом основана служба снижения риска компрометации прошлых сеансов связи: для каждого нового сеанса связи создаётся новый, так называемый «временный» симметричный ключ. Соответственно, даже в худшем случае (если злоумышленнику известен закрытый ключ сервера), злоумышленник может лишь получить ключи от будущих сессий, но не расшифровать ранее записанные.
На текущий момент, все браузеры при установке соединения TLS отдают предпочтение именно сочетанию алгоритма Диффи-Хеллмана и использованию временных ключей для повышения безопасности соединения.
Следует ещё раз отметить, что шифрование с открытым ключом используется только в процедуре TLS Handshake во время первоначальной настройки соединения. После настройки туннеля в дело вступает симметричная криптография, и общение в пределах текущей сессии зашифровано именно установленными симметричными ключами. Это необходимо для увеличения быстродействия, так как криптография с открытым ключом требует значительно больше вычислительной мощности.
Возобновление сессии TLS
Как уже отмечалось ранее, полная процедура TLS Handshake является довольно длительной и дорогой с точки зрения вычислительных затрат. Поэтому была разработана процедура, которая позволяет возобновить ранее прерванное соединение на основе уже сконфигурированных данных.
Начиная с первой публичной версии протокола (SSL 2.0) сервер в рамках TLS Handshake (а именно первоначального сообщения ServerHello) может сгенерировать и отправить 32-байтный идентификатор сессии. Естественно, в таком случае у сервера хранится кэш сгенерированных идентификаторов и параметров сеанса для каждого клиента. В свою очередь клиент хранит у себя присланный идентификатор и включает его (конечно, если он есть) в первоначальное сообщение ClientHello. Если и клиент, и сервер имеют идентичные идентификаторы сессии, то установка общего соединения происходит по упрощённому алгоритму, показанному на рисунке. Если нет, то требуется полная версия TLS Handshake.
Процедура возобновления сессии позволяет пропустить этап генерации симметричного ключа, что существенно повышает время установки соединения, но не влияет на его безопасность, так как используются ранее нескомпрометированные данные предыдущей сессии.
Однако здесь имеется практическое ограничение: так как сервер должен хранить данные обо всех открытых сессиях, это приводит к проблеме с популярными ресурсами, которые одновременно запрашиваются тысячами и миллионами клиентов.
Для обхода данной проблемы был разработан механизм «Session Ticket», который устраняет необходимость сохранять данные каждого клиента на сервере. Если клиент при первоначальной установке соединения указал, что он поддерживает эту технологию, то в сервер в ходе TLS Handshake отправляет клиенту так называемый Session Ticket – параметры сессии, зашифрованные закрытым ключом сервера. При следующем возобновлении сессии, клиент вместе с ClientHello отправляет имеющийся у него Session Ticket. Таким образом, сервер избавлен от необходимости хранить данные о каждом соединении, но соединение по-прежнему безопасно, так как Session Ticket зашифрован ключом, известным только на сервере.
TLS False Start
Технология возобновления сессии бесспорно повышает производительность протокола и снижает вычислительные затраты, однако она не применима в первоначальном соединении с сервером, или в случае, когда предыдущая сессия уже истекла.
Для получения ещё большего быстродействия была разработана технология TLS False Start, являющаяся опциональным расширением протокола и позволяющая отправлять данные, когда TLS Handshake завершён лишь частично. Подробная схема TLS False Start представлена на рисунке:
Важно отметить, что TLS False Start никак не изменяет процедуру TLS Handshake. Он основан на предположении, что в тот момент, когда клиент и сервер уже знают о параметрах соединения и симметричных ключах, данные приложений уже могут быть отправлены, а все необходимые проверки можно провести параллельно. В результате соединение готово к использованию на одну итерацию обмена сообщениями раньше.
TLS Chain of trust
Аутентификация является неотъемлемой частью каждого TLS соединения. Рассмотрим простейший процесс аутентификации между Алисой и Бобом:
- И Алиса, и Боб генерируют собственные открытые и закрытые ключи.
- Алиса и Боб обмениваются открытыми ключами.
- Алиса генерирует сообщение, шифрует его своим закрытым ключом и отправляет Бобу.
- Боб использует полученный от Алисы ключ, чтобы расшифровать сообщение и таким образом проверяет подлинность полученного сообщения.
Очевидно, что данная схема построена на доверии между Алисой и Бобом. Предполагается, что обмен открытыми ключами произошёл, например, при личной встрече, и, таким образом, Алиса уверена, что получила ключ непосредственно от Боба, а Боб, в свою очередь, уверен, что получил открытый ключ Алисы.
Пусть теперь Алиса получает сообщение от Чарли, с которым она не знакома, но который утверждает, что дружит с Бобом. Чтобы это доказать, Чарли заранее попросил подписать собственный открытый ключ закрытым ключом Боба, и прикрепляет эту подпись к сообщению Алисе. Алиса же сначала проверяет подпись Боба на ключе Чарли (это она в состоянии сделать, ведь открытый ключ Боба ей уже известен), убеждается, что Чарли действительно друг Боба, принимает его сообщение и выполняет уже известную проверку целостности, убеждаясь, что сообщение действительно от Чарли:
Описанное в предыдущем абзаце и есть создание «цепочки доверия» (или «Chain of trust», если по-английски).
В протоколе TLS данные цепи доверия основаны на сертификатах подлинности, предоставляемых специальными органами, называемыми центрами сертификации (CA – certificate authorities). Центры сертификации производят проверки и, если выданный сертификат скомпрометирован, то данный сертификат отзывается.
Из выданных сертификатов складывается уже рассмотренная цепочка доверия. Корнем её является так называемый “Root CA certificate” – сертификат, подписанный крупным центром, доверие к которому неоспоримо. В общем виде цепочка доверия выглядит примерно таким образом:
Естественно, возникают случаи, когда уже выданный сертификат необходимо отозвать или аннулировать (например, был скомпрометирован закрытый ключ сертификата, или была скомпрометирована вся процедура сертификации). Для этого сертификаты подлинности содержат специальные инструкции о проверке их актуальности. Следовательно, при построении цепочки доверия, необходимо проверять актуальность каждого доверительного узла.
Механизм этой проверки прост и в его основе лежит т.н. «Список отозванных сертификатов» (CRL – «Certificate Revocation List»). У каждого из центров сертификации имеется данный список, представляющий простой перечень серийных номеров отозванных сертификатов. Соответственно любой, кто хочет проверить подлинность сертификата, попросту загружает данный список и ищет в нём номер проверяемого сертификата. Если номер обнаружится – это значит, что сертификат отозван.
Здесь очевидно присутствует некоторая техническая нерациональность: для проверки лишь одного сертификата требуется запрашивать весь список отозванных сертификатов, что влечёт замедление работы. Для борьбы с этим был разработан механизм под названием «Протокол статусов сертификатов» (OCSP – Online Certificate Status Protocol). Он позволяет осуществлять проверку статуса сертификата динамически. Естественно, это снижает нагрузку на пропускную способность сети, но в то же время порождает несколько проблем:
- Центры сертификации должны справляться с нагрузкой в режиме реального времени;
- Центры сертификации должны гарантировать свою доступность в любое время;
- Из-за запросов реального времени центры сертификации получают информацию о том, какие сайты посещал каждый конкретный пользователь.
Собственно, во всех современных браузерах оба решения (OCSP и CRL) дополняют друг друга, более того, как правило имеется возможность настройки предпочитаемой политики проверки статуса сертификата.
Таким образом, в данной статье рассмотрены все ключевые средства, предоставляемые протоколом TLS для защиты информации. За некоторую отсебятину в статье прошу прощения, это издержки изначальной цели выполнения перевода.
Защита сайта по протоколу TLS
TLS (Transport Layer Security) представляет собой стандартный протокол, который используется в целях создания защищенных онлайн-соединений или во внутренних сетях предприятий. Он дает возможность клиентам проводить проверку подлинности серверов. Серверы же с его помощью выполняют проверку подлинности клиентов (когда это важно). Протокол TLS также позволяет создать защищенный канал с помощью кодирования всех передаваемых данных. Принципы работы TLS напоминают SSL, что неудивительно — протокол TLS является более поздней версией протокола SSL (SSL 3.0). Иногда протокол TLS называют «SSL 3.1».
Различия между SSL 3.0 и TLS являются очень тонкими и по большей части техническими; стоит отметить, что TLS является более свежим и более отлаженным протоколом. Безопасность текущей версии SSL — 3.0 — сопоставима с безопасностью TLS 1.0, однако версии TLS 1.1 и 1.2 значительно обходят ее в этом вопросе.
Протокол TLS может применяться для защиты соединений почти по всем популярным интернет-протоколам. К примеру, протокол https — это интернет-соединение по http, которое защищено по протоколу TLS. Также по протоколу TLS могут защищаться соединения по FTP, IMAP, POP3 и SMTP и т.д.
Протокол TLS реализуют динамические библиотеки для кодирования. Если взять в качестве примера Windows, то в этой системе данный протокол может быть реализован при помощи Microsoft CryptoAPI. Помимо всего прочего, существует ряд OpenSource-библиотек, которые позволяют реализовать протокол TLS. Среди них особо выделяются библиотеки OpenSSL и GNU TLS. Самой популярной является библиотека OpenSSL, которая входит в большинство сегодняшних операционных систем.
TLS-соединение
Что представляет собой типичная сессия TLS-соединения? Такая сессия состоит из следующих шагов:
- Handshake. Аутентификация сервера. Аутентификация клиента, создание и согласование сессионных ключей, предназначенных для кодирования данных.
- Двусторонний обмен данными. Данные кодируются программой-отправителем с помощью сессионных ключей, после чего передаются программе-получателю и уже в ней декодируются. Происходит проверка целостности данных.
- В ходе сессии могут происходить повторные handshake-соединения.
- В случае разрыва соединения автоматически производится закрытие сессии.
Как получить TLS сертификат
Чтобы сервер был аутентифицирован, ему нужно иметь сертификат и соответствующий ему закрытый ключ.
Администратор сервера может получить сертификат при помощи выполнения данных шагов:
- Воспользовавшись командой openssl req, сформировать заявку на сертификат и соответствующий закрытый ключ;
- Отправить сформированную заявку в удостоверяющий центр.
Удостоверяющий центр выполняет подпись созданной заявки при помощи своих ключей. Далее сертификат сервера пересылается обратно администратору сервера. Процесс аутентификации сервера состоит из проверки корректности выданного сертификата, проверки статуса сертификата (не просрочен, не отозван) и проверки принадлежности сертификата. Если все эти действия будут выполнены, сервер будет считаться аутентифицированным.
Любой сертификат с открытым ключом имеет информацию о том, кто является его владельцем. Для TLS сертификатов серверов домен (хост) указывается в поле CommonName.
В том случае, если сервер имеет несколько хостов, аутентификация успешно завершается только тогда, когда предъявленный сервером сертификат отвечает именно тому имени сервера, которое клиент указывал для установления соединения.
Для защиты сайта по протоколу TLS используются SSL-сертификаты. Если вы хотите приобрести сертификат для создания TLS соединения, вы всегда можете обратиться для этого к компании ЛидерТелеком.
Протокол TLS, протокол SSL что это такое | Параметры безопасности протокола TLS | REG.RU
В основе функционирования интернета лежит работа различных протоколов (TCP, IP и других). Все они работают сообща и каждый из них выполняет конкретную функцию.
В 1995 году был внедрён SSL (англ. Secure Sockets Layer) — криптографический протокол, обеспечивающий безопасную связь между пользователем и сервером. Благодаря его работе можно было безопасно передавать информацию или обмениваться данными. Однако в 2014 году в его работе обнаружили уязвимости. И на основе SSL 3.0 был разработан новый стандарт — TLS.
Протокол TLS (англ. Transport Layer Security) — криптографический протокол, который обеспечивает защищённый обмен данными между сервером и клиентом. Протокол работает на трёх уровнях защиты:
- отвечает за конфиденциальность передаваемых от компьютера к компьютеру данных,
- проводит аутентификацию,
- следит за целостностью передаваемой информации.
При разработке были учтены и исправлены все ошибки предшественника. В отличие от SSL новый протокол регулярно обновляется и продолжает развитие. В настоящее время для защиты соединения применяется только TLS-протокол. Поэтому, когда речь идёт о протоколе SSL, на самом деле подразумевается протокол TLS.
Защита данных c SSL
Установите SSL-сертификат, и ваш сайт будет работать по протоколу безопасного соединения HTTPS
TLS-протокол лежит в основе безопасного обмена информацией, но не обеспечивает его сам по себе. Чтобы защищённое соединение состоялось, нужно настроить одно из безопасных интернет-соединений, например — FTP (для передачи и загрузки файлов), IMAP/POP3/SMTP (для почтовых протоколов) и HTTPS (для интернет-страниц).
HTTPS — самый известный протокол безопасного соединения, который защищает данные на уровне браузера.
Однако, чтобы сайт заработал по безопасному соединению HTTPS, нужно выбрать и установить для сайта SSL-сертификат. Подробнее об этом читайте в статье Что такое протокол https и принципы его работы и Что такое secure sockets layer и как работает SSL.
Параметры безопасности протокола TLS
Любое действие в сети представляет собой обмен данными между компьютером (сервером) пользователя и сервером, на котором хранится информация. При каждом вводе запроса в поисковую строку, авторизации в аккаунте или переходе с одной страницы сайта на другую, пользователь и сервер взаимодействуют друг с другом. Такие взаимодействия называются транзакциями, а их совокупность — сессией. TLS отвечает за безопасность транзакций и сессии в целом.
Протокол TLS обеспечивает защиту в три этапа:
- Handshake,
- False Start,
- Chain of trust.
На этапе TLS Handshake (рукопожатие) происходит согласование параметров соединения (версии протокола, способа шифрования и соединения) между клиентом и сервером. Для этого используется обмен ключами по алгоритму RSA:
Для каждой такой проверки требуется большое количество вычислительных ресурсов. Чтобы не устанавливать новое соединение и не проверять сертификат повторно каждую транзакцию, была разработана процедура TLS False Start.
TLS False Start (фальстарт) — процедура возобновления сессии. Если транзакции выполняются в пределах одной запущенной сессии, данный этап позволяет пропустить процедуру Handshake. Протокол повторно использует те данные, которые уже были обработаны и подтверждены в начале сессии. При этом каждая сессия имеет свой срок жизни. Как только срок сессии истекает, с помощью TLS Handshake запускается новая сессия.
Также обязательная процедура TLS-соединения — TLS Chain of trust (цепочка доверия). Она отвечает за аутентификацию между клиентом и сервером. «Цепочка доверия» работает на основе регулярной проверки подлинности — соответствия сертификатов стандартам Сертификационных центров, которые их выдают. Подлинность сертификата регулярно проверяется в течение сессии. Если обнаружится, что сертификат скомпрометирован (то есть данные под его защитой были перехвачены), данные будут отозваны, транзакция не состоится и сессия будет прервана.
Таким образом, при передаче данных сначала вызывается процедура Handshake или False Start, которая согласовывает параметры, а затем Chain of trust, которая обеспечивает аутентификацию (проверку авторства передаваемой информации). Подробнее о принципах работы TLS читайте в официальной документации Datatracker.
Влияние SSL/TLS на SEO
SEO (Search Engine Optimization, поисковая оптимизация) – это всестороннее развитие и продвижение сайта для его выхода на первые позиции в результатах выдачи поисковых систем (SERPs). Поисковая оптимизация способствует увеличению посещаемости сайта.
Использование SSL-сертификата влияет на SEO-показатели, однако это влияние является скорее косвенным. С 2015 года Google отдаёт приоритет ранжирования (то есть назначения сайту места в поисковой выдаче) тем сайтам, которые работают по протоколу HTTPS. Такой же политики придерживается компании Яндекс и Mozilla.
Браузер Google Chrome — один из самых популярных браузеров в рунете. С недавнего времени Chrome отмечает HTTP-сайты как небезопасные:
Основной риск работы по HTTP заключается в том, что часть потенциальной аудитории сайта может просто испугаться предупреждения в строке браузера. Пользователи покинут страницу сайта раньше, чем она успеет загрузиться, а значит посещаемость сайта будет низкой.
Установка SSL/TLS
В компании REG.RU вы можете приобрести SSL-сертификат, который работает по TLS версии 1.2. Для этого выберите подходящий сертификат и выполните три шага — закажите, активируйте и установите его на сайт.
Если вам не удалось создать защищенный канал SSL/TLS или у вас возникли проблемы с настройкой протокола SSL, обратитесь за помощью к нашим специалистам через заявку в службу поддержки.
Проверка сайта на SSL/TLS
Помимо быстрой проверки через поисковую строку браузера, любой сайт можно дополнительно проверить на наличие безопасного соединения через специальные сервисы. В статье Как проверить SSL-сертификат мы подробно рассказали про самые популярные сервисы проверки. С их помощью также можно точно определить, по какому протоколу работает сайт.
Рассмотрим вариант проверки сайта с помощью сервиса SSL Server Test. Для этого:
-
1.
В браузере перейдите на страницу SSL Server Test. -
2.
В поле «Hostname» введите домен и нажмите Submit:
-
3.Дождитесь окончания проверки. В блоке «Configuration» вы увидите протоколы, которые поддерживает сайт:
Такой результат показывает, что сайт работает по безопасному подключению TLS версии 1.2. Если в результатах выдачи вы увидите «Yes» напротив пунктов SSL 2 или 3 — значит сайту нельзя доверять.
Защитите данные с помощью SSL
Защитите данные на вашем сайте от мошенников. Установите SSL-сертификат, чтобы сайт работал по HTTPS-протоколу.
Подробнее
Помогла ли вам статья?
12
раз уже помогла
SSL- и TLS-сертификаты, а также их особенности
Чем отличается защищенное соединение от незащищенного – знает довольно большое количество людей. А вот дальше довольно часто начинается темный лес: откуда берется сертификат, чем один сертификат отличается от другого, в чем разница между SSL и TLS и кто это вообще такие, какое отношение сертификат имеет к безопасности и так далее.
В рамках этого поста мы попробуем ответить хотя бы на часть этих и подобных вопросов, а начнем все-таки издалека – с того, что значат HTTP и HTTPS в адресной строке.
Что такое HTTP и HTTPS и чем они отличаются
Когда кто-нибудь из нас заходит на какой-нибудь сайт в Интернете, просто читает его или вводит на нем какие-то данные, происходит обмен информацией между нашим компьютером и сервером, на котором размещен сайт. Происходит он в соответствии с протоколом передачи данных — набором соглашений, определяющих порядок обмена информацией между разными программами.
Протокол, который используется для передачи данных в сети и получения информации с сайтов, называется HTTP (англ. HyperText Transfer Protocol — протокол передачи гипертекста). У него существует расширение, которое называется HTTPS (англ. HyperText Transfer Protocol Secure — безопасный протокол передачи гипертекста). Его суть — в том, что расширение позволяет передавать информацию между клиентом и сервером в зашифрованном виде. То есть информация, которой обмениваются клиент и сервер, доступна только этому клиенту и этому серверу, а не третьим лицам (например, провайдеру или администратору Wi-Fi-сети).
Шифрование данных, которые передаются от клиента к серверу, происходит, в свою очередь, в соответствии со своим, криптографическим протоколом. Сначала для этого использовался протокол под названием SSL (англ. Secure Sockets). У него было несколько версий, но все они в какой-то момент подвергались критике из-за наличия проблем с безопасностью. В итоге была выпущена та версия, которая используется сейчас — ее переименовали в TLS (англ. Transport Layer Security). Однако название SSL прижилось лучше, и новую версию протокола до сих пор часто называют так.
Для того чтобы использовать шифрование, у сайта должен быть специальный сертификат, или, как он еще называется, цифровая подпись, который подтверждает, что механизм шифрования действительно надежен и соответствует протоколу. Индикаторами того, что у сайта такой сертификат есть, являются, помимо буквы «S» в HTTPS, зеленый замочек и надпись «Защищено» или название компании в адресной строке браузера.
Как сайту получить SSL-сертификат
Существует два способа. Способ первый — веб-мастер может издать и подписать сертификат самостоятельно, сгенерировав криптографические ключи. Такой сертификат будет называться самоподписанным (англ. Self-Signed). В этом случае соединение с сайтом также будет зашифровано, но при попытке зайти на сайт с таким сертификатом пользователю будет показано предупреждение, что сертификат — недоверенный (неподтвержденный центром или устаревший). Обычно в окне браузер показывает перечеркнутый замочек и выделенные красным буквы HTTPS, или выделяет красным и перечеркивает буквы HTTPS в поисковой строке — зависит от браузера.
Второй способ (и единственный правильный) — приобрести сертификат, подписанный каким-либо из доверенных центров сертификации (Certificate authority). Сертификационные центры изучают документы владельца сайта и его право на владение доменом — ведь, по идее, наличие сертификата должно также гарантировать пользователю, что ресурс, с которым он обменивается информацией, принадлежит реальной легитимной компании, зарегистрированной в определенном регионе.
Сертификационных центров существует довольно много, но авторитетные среди них можно пересчитать по пальцам. От репутации центра зависит то, насколько ему будут доверять компании-разработчики браузеров и как они будут отображать сайт с таким сертификатом. От вида сертификата, срока его действия и репутации центра и зависит цена на сертификат.
Какими бывают SSL-сертификаты
Сертификаты, подписанные центрами, делятся на несколько видов — в зависимости от уровня надежности, того, кто и как их может получить и, соответственно, цены.
Первый называется DV (англ. Domain Validation — проверка домена). Для его получения физическому или юридическому лицу нужно доказать, что они имеют некий контроль над доменом, для которого приобретается сертификат. Проще говоря, что они либо владеют доменом, либо администрируют сайт на нем. Этот сертификат позволяет установить защищенное соединение, но в нем нет данных об организации, которой он выдан, а для его оформления не требуется никаких документов. Процесс получения такого сертификата обычно занимает несколько минут.
Сертификаты более высокого уровня — OV (англ. Organization Validation — проверка организации). Такие сертификаты выдаются только юридическим лицам, и от них требуются документы, подтверждающие существование организации, — так подтверждается не только безопасность соединения с доменом, но и то, что домен принадлежит организации, указанной в электронном сертификате. Оформление может занимать несколько дней, пока проверяются все документы. Наличие DV или OV-сертификата у сайта в браузере отображается серым или зеленым замочком, словом Secure и буквами HTTPS в адресной строке.
И еще есть EV (англ. Extended Validation — расширенная проверка) — сертификаты самого высокого уровня. Такой сертификат также могут получить только юридические лица, предоставившие все необходимые документы, а отличительной особенностью является то, что название и локация организации отображаются зеленой надписью в адресной строке после зеленого замочка. Такие сертификаты пользуются наибольшим доверием у браузеров, но они и дороже всего. В основном их приобретают крупные компании. Даже банки часто приобретают их в основном не для основного сайта, а отдельно для домена своего сервиса онлайн-платежей.
Информацию о сертификате (кем выдан, когда и сколько действует) можно посмотреть, кликнув на название организации или надпись Secure — правда, это можно сделать не во всех браузерах.
Что может быть не так с сертификатами
Один из принципов, по которым основные разработчики браузеров, такие как Google и Mozilla, выстраивают свою политику — безопасность Интернета и пользовательских данных в нем. В этой связи осенью 2017 года Google анонсировала, что отныне будет маркировать все страницы, использующие HTTP-соединение, как «незащищенные», и, по сути, блокировать пользователям доступ к ним.
Фактически, это условие вынудило все сайты на HTTP в ускоренном темпе приобретать доверенные сертификаты. Соответственно, спрос на услуги сертификационных центров вырос в разы, а время на проверку документов последним, естественно, хотелось бы сократить, чтобы выдать как можно больше этих самых сертификатов. Поэтому многие из центров стали проводить проверку гораздо менее тщательно.
Результатом этого становится то, что надежные сертификаты получают далеко не самые надежные сайты. Так, Google провела расследование, по результатам которого выяснилось, что один из самых крупных и авторитетных центров выдал более 30 тыс. сертификатов, не осуществив при этом должной проверки. Последствия для центра не радужные: Google заявила, что перестанет считать доверенными все сертификаты, выданные центром, пока тот полностью не переделает всю систему проверки и не установит новые стандарты. Mozilla также планирует ужесточить верификацию сертификатов в своих браузерах и тем самым повлиять на требования к их выдаче.
Тем не менее пока полностью уверенным в надежности сертификата и получившей его организации быть нельзя. Даже если это EV-сертификат, внешне соответствующий всем требованиям безопасности, не стоит доверять тому, что написано зеленым шрифтом, безоговорочно.
С EV-сертификатами все даже особенно плохо: злоумышленник может зарегистрировать компанию с названием, подозрительно похожим на название какой-нибудь известной компании и получить для своего сайта EV-сертификат. В этом случае зелеными буквами в адресной строке будет написано как раз-таки название компании (очень похожее на название другой известной компании), что позволит злоумышленнику повысить доверие пользователя к фишинговому сайту. Поэтому никогда не забывайте об осторожности и соблюдении правил при использовании любой веб-страницы.
Что такое SSL/TLS протокол и последняя версия TLS 1.3
Протокол TLS шифрует интернет-трафик всех видов, тем самым делая безопасными общение и продажи в интернете. Мы расскажем о том, как протокол работает и что нас ждет в будущем.
Из статьи вы узнаете:
Что такое SSL
SSL или слой защищенных сокетов было оригинальным названием протокола, который разработала компания Netscape в середине 90-х. SSL 1.0 никогда не был публично доступным, а в версии 2.0 были серьезные недостатки. Протокол SSL 3.0, выпущенный в 1996, был полностью переделан и задал тон следующей стадии развития.
Что такое TLS
Когда следующую версию протокола выпустили в 1999, ее стандартизировала специальная рабочая группа проектирования сети Интернет и дала ей новое название: защита транспортного уровня, или TLS. Как говорится в TLS-документации, «разница между этим протоколом и SSL 3.0 не критичная». TLS и SSL формируют постоянно обновляемую серию протоколов, и их часто объединяют под названием SSL/TLS.
Протокол TLS шифрует интернет-трафик любого вида. Самый распространенный вид — веб-трафик. Вы знаете, когда ваш браузер устанавливает соединение по TLS — если ссылка в адресной строке начинается с «https».
TLS также используется другими приложениями — например, в почте и системах телеконференций.
Как работает TLS
Шифрование необходимо, чтобы безопасно общаться в интернете. Если ваши данные не шифруются, любой может проанализировать их и прочитать конфиденциальную информацию.
Самый безопасный метод шифрования — это асимметричное шифрование. Для этого требуется 2 ключа, 1 публичный и 1 приватный. Это файлы с информацией, чаще всего очень большие числа. Механизм сложный, но если попросту, вы можете использовать публичный ключ, чтобы шифровать данные, но вам нужен приватный ключ, чтобы расшифровывать их. Два ключа связаны с помощью сложной математической формулы, которую сложно хакнуть.
Можно представить публичный ключ как информацию о местоположении закрытого почтового ящика с отверстием, и приватный ключ как ключ, который открывает ящик. Любой, кто знает, где находится ящик, может положить туда письмо. Но чтобы прочитать его, человеку нужен ключ, чтобы открыть ящик.
Так как в асимметричном шифровании применяются сложные математические расчеты, нужно много вычислительных ресурсов. TLS решает эту проблему, используя асимметричное шифрование только в начале сессии, чтобы зашифровать общение между сервером и клиентом. Сервер и клиент должны договориться об одном ключе сессии, который они будут вдвоем использовать, чтобы зашифровать пакеты данных.
Процесс, согласно которому клиент и сервер договариваются о ключе сессии, называется рукопожатием. Это момент, когда 2 общающихся компьютера представляются другу другу.
Процесс TLS-рукопожатия
Процесс TLS-рукопожатия довольно сложный. Шаги внизу отображают процесс в общем, чтобы вы понимали, как это работает в целом.
- Клиент связывается с сервером и запрашивает безопасное соединение. Сервер отвечает списком шифров — алгоритмическим набором для создания зашифрованных соединений — которым он знает, как пользоваться. Клиент сравнивает список со своим списком поддерживаемых шифров, выбирает подходящий и дает серверу знать, какой они будут использовать вдвоем.
- Сервер предоставляет свой цифровой сертификат — электронный документ, подписанный третьей стороной, который подтверждает подлинность сервера. Самая важная информация в сертификате — это публичный ключ к шифру. Клиент подтверждает подлинность сертификата.
- Используя публичный ключ сервера, клиент и сервер устанавливают ключ сессии, который они оба будут использовать на протяжении всей сессии, чтобы шифровать общение. Для этого есть несколько методов. Клиент может использовать публичный ключ, чтобы шифровать произвольное число, которое потом отправляется на сервер для расшифровки, и обе стороны потом используют это число, чтобы установить ключ сессии.
Ключ сессии действителен только в течение одной непрерывной сессии. Если по какой-то причине общение между клиентом и сервером прервется, нужно будет новое рукопожатие, чтобы установить новый ключ сессии.
Уязвимости протоколов TLS 1.2 и TLS 1.2
TLS 1.2 — самая распространенная версия протокола. Эта версия установила исходную платформу опций шифрования сессий. Однако, как и некоторые предыдущие версии протокола, этот протокол разрешал использовать более старые техники шифрования, чтобы поддерживать старые компьютеры. К сожалению, это привело к уязвимостям версии 1.2, так как эти более старые механизмы шифрования стали более уязвимыми.
Например, протокол TLS 1.2 стал особенно уязвимым к атакам типа активного вмешательства в соединение, в которых хакер перехватывает пакеты данных посреди сессии и отправляет их после прочтения или изменения их. Многие из этих проблем проявились за последние 2 года, поэтому стало необходимым срочно создать обновленную версию протокола.
TLS 1.3
Версия 1.3 протокола TLS, которая скоро будет финализирована, решает множество проблем с уязвимостями тем, что отказывается от поддержки устаревших систем шифрования.
В новой версии есть совместимость с предыдущими версиями: например, соединение откатится до версии TLS 1.2, если одна из сторон не сможет использовать более новую систему шифрования в списке разрешенных алгоритмов протокола версии 1.3. Однако при атаке типа активного вмешательства в соединение, если хакер принудительно попытается откатить версию протокола до 1.2 посреди сессии, это действие будет замечено, и соединение прервется.
Как включить поддержку TLS 1.3 в браузерах Google Chrome и Firefox
Firefox и Chrome поддерживают TLS 1.3, но эта версия не включена по умолчанию. Причина в том, что она существует пока только в черновом варианте.
Mozilla Firefox
Введите about:config в адресную строку браузера. Подтвердите, что вы осознаете риски.
- Откроется редактор настроек Firefox.
- Введите в поиске security.tls.version.max
- Поменяйте значение на 4, сделав двойной щелчок мышью на нынешнее значение.
Google Chrome
- Введите chrome://flags/ в адресную строку браузера, чтобы открыть панель с экспериментами.
- Найдите опцию #tls13-variant
- Нажмите на меню и поставьте Enabled (Draft).
- Перезапустите браузер.
Как проверить, что ваш браузер использует версию 1.2
Напоминаем, что версия 1.3 еще не используется публично. Если вы не хотите
использовать черновой вариант, вы можете остаться на версии 1.2.
Чтобы проверить, что ваш браузер использует версию 1.2, проделайте те же шаги, что и в инструкциях выше, и убедитесь, что:
- Для Firefox значение security.tls.version.max равно 3. Если оно ниже, поменяйте его на 3, сделав двойной щелчок мышью на нынешнее значение.
- Для Google Chrome: нажмите на меню браузера — выберите Settings — выберите Show advanced settings — опуститесь до раздела System и нажмите на Open proxy settings…:
- В открывшемся окне нажмите на вкладку Security и проверьте, чтобы для поля Use TLS 1.2 стояла галочка. Если не стоит — поставьте и нажмите OK:
Изменения войдут в силу после того, как вы перезагрузите компьютер.
Быстрый инструмент для проверки версии протокола SSL/TLS браузера
Зайдите в онлайн-инструмент проверки версии протокола SSL Labs. Cтраница покажет в реальном времени используемую версию протокола, и подвержен ли браузер каким-то уязвимостям.
Источники: перевод статьи из издания CSO и перевод статьи из технологического блога Ghacks
Что такое SSL, TLS и HTTPS?
#
256-битное шифрование Процесс шифрования электронного документа с использованием алгоритма, длина ключа которого составляет 256 бит. Чем длиннее ключ, тем он прочнее.
А
Асимметричная криптография. Это шифры, которые подразумевают пару из 2 ключей во время процессов шифрования и дешифрования. В мире SSL и TLS мы называем их открытыми и закрытыми ключами.
С
Запрос на подпись сертификата (CSR) Машиночитаемая форма приложения сертификата DigiCert.CSR обычно содержит открытый ключ и отличительное имя запрашивающей стороны.
Центр сертификации (CA) Организация, уполномоченная выдавать, приостанавливать, обновлять или отзывать сертификаты в соответствии с CPS (Заявление о практике сертификации). Центры сертификации идентифицируются по отличительному имени во всех выпускаемых ими сертификатах и списках отзыва сертификатов. Центр сертификации должен опубликовать свой открытый ключ или предоставить сертификат от ЦС более высокого уровня, подтверждающий действительность его открытого ключа, если он подчиняется первичному центру сертификации.DigiCert — это первичный центр сертификации (PCA).
Набор шифров. Это набор протоколов обмена ключами, который включает в себя алгоритмы аутентификации, шифрования и аутентификации сообщений, используемые в протоколах SSL.
Общее имя (CN) Значение атрибута в отличительном имени сертификата. Для сертификатов SSL обычным именем является имя хоста DNS сайта, который необходимо защитить. Для сертификатов издателя программного обеспечения общим названием является название организации.
Ошибка подключения Когда проблемы безопасности, препятствующие запуску безопасного сеанса, отмечаются при попытке доступа к сайту.
D
Проверка домена (DV) SSL-сертификаты Самый базовый уровень SSL-сертификата, только право собственности на доменное имя проверяется перед выдачей сертификата.
E
Elliptic Curve Cryptography (ECC) Создает ключи шифрования на основе идеи использования точек на кривой для определения пары открытого / закрытого ключей. Чрезвычайно сложно взломать методы грубой силы, часто используемые хакерами, и предлагает более быстрое решение с меньшей вычислительной мощностью, чем чистое шифрование цепочки RSA.
Шифрование Процесс преобразования читаемых (открытый текст) данных в неразборчивую форму (зашифрованный текст), так что исходные данные либо не могут быть восстановлены (одностороннее шифрование), либо не могут быть восстановлены без использования процесса обратного дешифрования (двустороннее шифрование).
SSL-сертификаты с расширенной проверкой (EV) Наиболее полная форма безопасного сертификата, который проверяет домен, требует очень строгой аутентификации компании и выделяет его в адресной строке.
К
Обмен ключами. Таким образом пользователи и сервер безопасно устанавливают предварительный секрет для сеанса.
м
Главный секрет Материал ключа, используемый для генерации ключей шифрования, секретов MAC и векторов инициализации.
Код аутентификации сообщения (MAC) Односторонняя хэш-функция, организованная для сообщения и секрета.
O
Проверка организации (OV) SSL-сертификаты Тип SSL-сертификата, который подтверждает право собственности на домен и существование организации, стоящей за ним.
-П
Предварительный главный секрет Материал ключа, используемый для деривации основного секрета.
Инфраструктура открытых ключей (PKI) Архитектура, организация, методы, практики и процедуры, которые в совокупности поддерживают реализацию и работу криптографической системы с открытым ключом на основе сертификатов. PKI состоит из систем, которые взаимодействуют друг с другом для предоставления и реализации криптографической системы с открытым ключом и, возможно, других связанных служб.
S
Secure server Сервер, который защищает веб-страницы хоста с помощью SSL или TLS. Когда используется защищенный сервер, он аутентифицируется для пользователя.Кроме того, информация о пользователе перед отправкой через Интернет шифруется протоколом SSL веб-браузера пользователя. Информация может быть расшифрована только тем хост-сайтом, который ее запросил.
SAN (альтернативное имя субъекта) SSL-сертификаты Тип сертификата, который позволяет защитить несколько доменов с помощью одного SSL-сертификата.
SSL Обозначает уровень защищенных сокетов. Протокол для веб-браузеров и серверов, который позволяет выполнять аутентификацию, шифрование и дешифрование данных, отправляемых через Интернет.
SSL-сертификат Сертификат сервера, который позволяет аутентифицировать сервер для пользователя, а также разрешает шифрование данных, передаваемых между сервером и пользователем. Сертификаты SSL продаются и выдаются непосредственно DigiCert, а также через платформу DigiCert PKI для SSL Center.
SSL Handshake Протокол, используемый в SSL для согласования безопасности.
Симметричное шифрование Метод шифрования, подразумевающий использование одного и того же ключа, используется как в процессе шифрования, так и в процессе дешифрования.
т
TCP Протокол управления передачей данных, один из основных протоколов в любой сети.
Вт
Wildcard SSL-сертификаты Тип сертификата, используемого для защиты нескольких поддоменов.
Что такое SSL, TLS? И как работает этот протокол шифрования
С первых дней Интернета протокол SSL и его потомок, TLS, обеспечивали шифрование и безопасность, которые делают возможной современную Интернет-торговлю. Многолетняя история этих протоколов отмечена постоянными обновлениями, которые направлены на то, чтобы идти в ногу со все более изощренными злоумышленниками.Следующая основная версия протокола, TLS 1.3, скоро будет завершена — и большинство тех, кто запускает веб-сайт, захотят обновить его, потому что киберпреступники догоняют его.
Что такое SSL?
Secure Sockets Layer, или SSL, было первоначальным названием протокола, когда он был разработан в середине 1990-х годов компанией Netscape, которая сделала самый популярный веб-браузер того времени. SSL 1.0 никогда не был выпущен для широкой публики, а SSL 2.0 имел серьезные недостатки. SSL 3.0, выпущенный в 1996 году, был полностью переработан и подготовил почву для того, что последовало.
TLS против SSL
Когда в 1999 году была выпущена следующая версия протокола, она была стандартизирована Инженерной группой Интернета (IETF) и получила новое имя: Transport Layer Security, или TLS. Как отмечается в спецификации TLS, «различия между этим протоколом и SSL 3.0 несущественны». Таким образом, на самом деле дело не в TLS и SSL; скорее, они образуют непрерывно обновляемую серию протоколов и часто объединяются как SSL / TLS.
Протокол TLS шифрует интернет-трафик всех типов.Самый распространенный — это веб-трафик; вы знаете, что ваш браузер подключен через TLS, если URL-адрес в вашем адресе начинается с «https», и есть индикатор с замком, говорящий вам, что соединение безопасно, как на этом снимке экрана из Chrome:
Но TLS может использоваться другими а также приложения, включая электронную почту и usenet.
Как работает SSL
Шифрование необходимо для безопасной связи через Интернет: если ваши данные не зашифрованы, любой может проверить ваши пакеты и прочитать конфиденциальную информацию.Самый безопасный метод шифрования называется асимметричной криптографией ; для правильной работы требуются два криптографических ключа — фрагменты информации, обычно очень большие числа — один открытый и один частный. Математика здесь сложна, но, по сути, вы можете использовать открытый ключ, чтобы зашифровать данные, но вам нужен закрытый ключ, чтобы расшифровать . Два ключа связаны друг с другом сложной математической формулой, которую трудно переконструировать с помощью грубой силы.Подумайте об открытом ключе как об информации о местонахождении запертого почтового ящика с прорезью на передней панели, а о закрытом ключе — как о ключе, который открывает почтовый ящик. Любой, кто знает, где находится почтовый ящик, может поместить в него сообщение; но чтобы кто-нибудь еще его прочитал, им нужен закрытый ключ.
Поскольку асимметричная криптография включает в себя эти сложные математические задачи, она требует много вычислительных ресурсов, настолько много, что, если бы вы использовали ее для шифрования всей информации в сеансе связи, ваш компьютер и соединение остановились бы.TLS решает эту проблему, используя асимметричную криптографию только в самом начале сеанса связи, чтобы зашифровать диалог, сервер и клиент должны согласовать один сеансовый ключ , который они оба будут использовать для шифрования своих пакетов с этого момента. . Шифрование с использованием общего ключа называется симметричной криптографией , и требует гораздо меньше вычислительных ресурсов, чем асимметричная криптография. Поскольку этот сеансовый ключ был установлен с использованием асимметричной криптографии, сеанс связи в целом намного безопаснее, чем был бы в противном случае.
Процесс согласования этого сеансового ключа называется рукопожатием , , поскольку это момент, когда два взаимодействующих компьютера знакомятся друг с другом, и он лежит в основе протокола TLS.
Процесс установления связи SSL
Процесс установления связи довольно сложен, и существует ряд вариаций, разрешенных протоколом. Следующие шаги представляют собой общую схему, которая должна дать вам представление о том, как это работает.
- Клиент связывается с сервером и запрашивает безопасное соединение.Сервер отвечает списком из наборов шифров — алгоритмических инструментов для создания зашифрованных соединений, — которые он знает, как использовать. Клиент сравнивает это со своим собственным списком поддерживаемых наборов шифров, выбирает один и сообщает серверу, что они оба будут его использовать.
- Затем сервер предоставляет свой цифровой сертификат , — электронный документ, выпущенный сторонним органом, подтверждающий идентичность сервера. Мы обсудим цифровые сертификаты более подробно чуть позже, но сейчас самое важное, что вам нужно знать о них, — это то, что они содержат открытый криптографический ключ сервера.Как только клиент получает сертификат, он подтверждает подлинность сертификата.
- Используя открытый ключ сервера, клиент и сервер устанавливают сеансовый ключ, который оба будут использовать до конца сеанса для шифрования связи. Для этого есть несколько методов. Клиент может использовать открытый ключ для шифрования случайного числа, которое затем отправляется на сервер для расшифровки, и обе стороны затем используют это число для установки сеансового ключа. В качестве альтернативы обе стороны могут использовать так называемый обмен ключами Диффи-Хеллмана для установления сеансового ключа.
В этой статье на SSL.com есть отличная диаграмма, описывающая каждый этап связи в процессе установления связи TLS.
Как следует из названия, сеансовый ключ годен только для одного непрерывного сеанса связи. Если по какой-либо причине связь между клиентом и сервером прервана — например, из-за сетевой проблемы или из-за того, что клиент слишком долго бездействует, — потребуется новое рукопожатие, чтобы установить новый сеансовый ключ, когда связь будет восстановлена. .
Что такое сертификат SSL?
Вернемся к концепции SSL-сертификата . Как ясно из описания в предыдущем разделе, эти сертификаты лежат в основе протокола SSL / TLS: они предоставляют клиенту открытый криптографический ключ, необходимый для инициирования безопасных соединений. Но их цель выходит за рамки простой поставки самого ключа; они также подтверждают, что ключ действительно связан с организацией, предлагающей его клиенту.
Как это работает? Сертификаты выдаются Центрами сертификации (CA), которые служат эквивалентом паспортного стола, когда дело доходит до подтверждения личности.Организации, которые хотят предлагать услуги, зашифрованные с помощью TLS, должны приобретать сертификаты у центров сертификации, которые, в свою очередь, проверяют, являются ли организации тем, кем они себя называют. Например, если вы хотите купить сертификат для защиты веб-сайта на example.com, вам придется предпринять некоторые шаги, чтобы доказать центру сертификации, что вы контролируете домен example.com. Таким образом, если кто-то подключается к example.com и получает действительный сертификат SSL, выданный доверенным центром сертификации, он может быть уверен, что общается с законным владельцем example.com. Это может предотвратить атаки человека посередине.
Обратите внимание, что в последнем абзаце мы использовали фразу «доверенный центр сертификации». Кто угодно может стать центром сертификации; как узнать, какие из них проводят комплексную проверку, необходимую для аутентификации своих клиентов? К счастью, работа по выяснению этого в основном выполняется производителями программного обеспечения. Mozilla Foundation ведет список центров сертификации, которым будет доверять Firefox; Apple и Microsoft также ведут списки, которые они внедряют на уровне ОС для Windows, macOS и iOS, которые Chrome использует на этих платформах.Решения о том, каким центрам сертификации доверять, очень высоки, поскольку в 2017 году выяснилось, что Google и Symantec разошлись по поводу слабых стандартов Symantec.
Стандарт, определяющий сертификаты SSL, называется X.509. Этот стандарт позволяет сертификатам нести большой объем информации, помимо открытого ключа и подтвержденной личности владельца сертификата; DigiCert — это центр сертификации, база знаний которого содержит подробные сведения о стандарте.
SSL checkers
Практически весь обмен и подтверждение информации, описанной выше, происходит за кулисами, когда вы общаетесь с серверами, которые предлагают соединения с шифрованием TLS.Если вы хотите добиться большей прозрачности, вы можете ввести URL-адрес SSL / TLS-зашифрованного сайта на веб-сайте SSL-checker . Средство проверки вернет множество информации о сертификате протестированного сайта, включая тип сервера, какие веб-браузеры будут доверять сертификату, а также его эмитент, серийный номер и дату истечения срока действия.
Большинство средств проверки SSL — это бесплатные услуги, предлагаемые центрами сертификации в качестве маркетинговых инструментов для своих товаров; многие, например, позволят вам установить предупреждение о том, когда истечет срок действия проверенного сертификата, при условии, что это ваш сертификат, и вы будете искать новый по мере приближения этой даты.Если вы ищете менее коммерческую альтернативу, обратите внимание на средство проверки SSL от Qualys SSL Labs, которое обеспечивает особенно надежный сбор информации об проверенных веб-сайтах.
Уязвимости TLS 1.2 и TLS 1.2
TLS 1.2 — это самая последняя определенная версия протокола, которая существует уже несколько лет. Он установил множество новых криптографических опций для связи. Однако, как и некоторые предыдущие версии протокола, он также позволял использовать старые криптографические методы для поддержки старых компьютеров.К сожалению, это открыло его для уязвимостей, поскольку эти старые методы со временем стали более уязвимыми, а вычислительные мощности стали дешевле.
В частности, TLS 1.2 становится все более уязвимым для так называемых атак «человек посередине», при которых хакер перехватывает пакеты во время обмена данными и отправляет их после прочтения или изменения. Он также открыт для атак POODLE, SLOTH и DROWN. Многие из этих проблем возникли за последние два года, что усилило чувство безотлагательности обновления протокола.
TLS 1.3
К счастью, помощь уже скоро. Версия 1.3 протокола TLS, которая в настоящее время находится в форме черновика, но скоро будет доработана, закрывает множество этих дыр, отказываясь от поддержки устаревших систем шифрования. Существует обратная совместимость в том смысле, что соединения будут возвращаться к TLS 1.2, если один конец не может использовать новые системы шифрования из утвержденного списка 1.3. Однако, если, например, атака «злоумышленник посередине» попытается принудительно переключиться на 1,2 для отслеживания пакетов, это будет обнаружено, и соединение будет разорвано.
Есть еще серверы, которые используют версии TLS даже старше 1.2 — некоторые все еще используют исходный протокол SSL. Если ваш сервер является одним из таких, вам следует обновить его сейчас, а просто прыгнуть вперед и перейти на черновую версию 1.3.
TLS Crimeware
Последнее замечание о TLS и безопасности: не только хорошие парни его используют! Многие киберпреступники используют TLS для шифрования командного трафика между своими серверами и вредоносными программами, установленными на компьютерах их жертв.Это в конечном итоге меняет обычное положение дел и заставляет жертв киберпреступлений искать способ расшифровать трафик. Существует ряд методов борьбы с этим видом зашифрованной атаки, в том числе использование сетевых метаданных о зашифрованном трафике, чтобы понять, что делают злоумышленники, не читая их.
Copyright © 2018 IDG Communications, Inc.
SSL против TLS — в чем разница?
Примечание редактора: этот пост был первоначально опубликован в июле 2016 года и был обновлен старшим менеджером по маркетингу продуктов GlobalSign Патриком Ноэ, чтобы отразить последние изменения в развитии SSL.
Если вы не работаете с ним регулярно, есть большая вероятность, что вы не знаете разницы между SSL (Secure Sockets Layers) и TLS (Transport Layer Security). И эта отрасль не окажет вам особого внимания, если в разговорной речи называть TLS SSL. Всего было четыре версии протокола TLS. SSL был (или должен быть) полностью устаревшим. Итак, в чем разница между SSL и TLS?
Вы скоро узнаете.
Краткая история SSL и TLS
SSL и TLS — это криптографические протоколы, обеспечивающие аутентификацию и шифрование данных между серверами, машинами и приложениями, работающими в сети (например,г. клиент, подключающийся к веб-серверу). На самом деле SSL всего около 25 лет. Но в годы интернета это уже давно. Первая итерация SSL, версия 1.0, была впервые разработана в 1995 году компанией Netscape, но так и не была выпущена из-за серьезных недостатков безопасности. SSL 2.0 был ненамного лучше, поэтому всего год спустя был выпущен SSL 3.0. Опять же, у него были серьезные недостатки в безопасности.
В этот момент ребята из Consensus Development взяли курс на это и разработали TLS 1.0.TLS 1.0 был невероятно похож на SSL 3.0 — на самом деле он был основан на нем — но все же достаточно отличался, чтобы потребовать перехода на более раннюю версию, прежде чем можно будет использовать SSL 3.0. Как писали создатели протокола TLS:
«Различия между этим протоколом и SSL 3.0 несущественны, но они достаточно значительны, чтобы TLS 1.0 и SSL 3.0 не взаимодействовали».
Переход на SSL 3.0 все еще был опасен, учитывая известные уязвимости, которыми можно воспользоваться. Все, что нужно было сделать злоумышленнику, чтобы атаковать веб-сайт, — это понизить протокол до SSL 3.0. Отсюда и рождение атак понижения версии. Это стало гвоздем в крышку гроба для TLS 1.0.
TLS 1.1 вышел семь лет спустя, в 2006 году, на смену TLS 1.2 в 2008 году. Это повредило принятию TLS 1.1, поскольку многие веб-сайты просто обновились с 1.0 до TLS 1.2. Сейчас мы находимся на TLS 1.3, который был завершен в 2018 году после 11 лет и почти 30 проектов IETF.
TLS 1.3 значительно лучше своих предшественников, и сейчас основные игроки в Интернете настаивают на его распространении.Microsoft, Apple, Google, Mozilla и Cloudflare объявили о планах отказаться от TLS 1.0 и TLS 1.1 в январе 2020 года, что сделает TLS 1.2 и TLS 1.3 единственной игрой в городе.
В любом случае, мы используем TLS последние пару десятилетий. На данный момент, если вы все еще используете SSL, вы отстали на несколько лет, образно говоря, живете в заброшенную эпоху, когда люди все еще используют телефонные линии для подключения к Интернету.
Что следует использовать: SSL или TLS?
Оба SSL 2.0 и 3.0 были объявлены устаревшими Инженерной группой Интернета, также известной как IETF, в 2011 и 2015 годах соответственно. На протяжении многих лет уязвимости обнаруживались и продолжают обнаруживаться в устаревших протоколах SSL (например, POODLE, DROWN). Большинство современных браузеров будут показывать ухудшенное взаимодействие с пользователем (например, линия через замок или https в строке URL-адреса или другие предупреждения безопасности), когда они сталкиваются с веб-сервером, использующим старые протоколы. По этим причинам вам следует отключить SSL 2.0 и 3.0 в конфигурации вашего сервера, а пока вы это делаете, не рекомендуется использовать TLS 1.0 и TLS 1.1 тоже.
Согласно недавнему опросу WatchGuard, почти 7% из 100 000 Alexa все еще поддерживают SSL 2.0 и / или SSL 3.0. Так что этих сайтов по-прежнему много.
Сертификаты
не совпадают с протоколами
Прежде чем кто-либо начнет беспокоиться о необходимости замены существующих сертификатов SSL на сертификаты TLS, важно отметить, что сертификаты не зависят от протоколов. То есть вам не нужно использовать сертификат TLS вместо сертификата SSL.Хотя многие поставщики склонны использовать фразу «Сертификат SSL / TLS», было бы правильнее называть их «Сертификатами для использования с SSL и TLS», поскольку протоколы определяются конфигурацией вашего сервера, а не самими сертификатами.
Это касается и надежности шифрования. Многие сертификаты заявляют о надежности шифрования, но на самом деле это определяют возможности сервера и клиента. В начале каждого подключения происходит процесс, называемый рукопожатием. Во время этого процесса клиент аутентифицирует сертификат TLS сервера, и оба выбирают взаимно поддерживаемый набор шифров.Наборы шифров — это набор алгоритмов, которые работают вместе, чтобы надежно зашифровать ваше соединение с этим веб-сайтом. Когда набор шифров согласовывается во время рукопожатия, именно тогда определяются версия протокола и поддерживающие алгоритмы. Ваш сертификат просто облегчает процесс.
Исторически сложилось так, что в наборе шифров было четыре алгоритма:
- Обмен ключами
- Цифровая подпись
- Аутентификация сообщений
- Алгоритм хеширования
(Если это покажется маловажным, это не пройдет через секунду, когда мы обсудим различия между SSL и TLS.)
На данный момент, вероятно, вы по-прежнему будете видеть сертификаты, называемые сертификатами SSL, потому что на данный момент это термин, с которым знакомо больше людей. Мы начинаем видеть более широкое использование термина TLS в отрасли, и SSL / TLS является обычным компромиссом, пока TLS не станет более широко распространенным.
Отличаются ли SSL и TLS криптографически?
Да. Разница между каждой версией протокола может быть невелика, но если вы сравнивали SSL 2.0 до TLS 1.3 между ними будет каньон. По сути, концепция одинакова во всех версиях. Это просто способ, которым разные протоколы решают задачу шифрования расходящихся соединений.
Каждая недавно выпущенная версия протокола поставляется со своими собственными улучшениями и / или новыми / устаревшими функциями. Первая версия SSL так и не была выпущена, вторая версия была выпущена, но с некоторыми серьезными недостатками, SSL версия 3 была переработкой второй версии (для исправления этих недостатков — с ограниченным успехом), а TLS версии 1 — улучшением SSL версии 3.Между TLS 1.0 и 1.1 изменения были незначительными. TLS 1.2 внес некоторые существенные изменения, а TLS 1.3 усовершенствовал и упростил весь процесс.
Здесь стоит отметить, что SSL и TLS просто относятся к рукопожатию, которое происходит между клиентом и сервером. Рукопожатие на самом деле не выполняет никакого шифрования, оно просто согласовывает общий секрет и тип шифрования, который будет использоваться. Подтверждение связи SSL использует порт для установления соединения. Это называется явным подключением.Порт 443 является стандартным портом для HTTPS, но всего имеется 65 535 портов, и лишь некоторые из них предназначены для определенной функции.
TLS, наоборот, начинает свои соединения по протоколу. Это называется неявным подключением. Самый первый шаг рукопожатия — действие, которое его начинает — называется приветствием клиента. При использовании TLS это отправляется через незащищенный канал, и соединение переключается на порт 443 (или порт, который вы указали), как только начинается рукопожатие.
Традиционно рукопожатие включает несколько циклов обмена, когда происходит аутентификация и обмен ключами.При использовании SSL это увеличивало задержку соединений. Отсюда и зародился миф о том, что SSL / HTTPS замедляет работу вашего сайта. Каждая новая итерация протокола работала над уменьшением задержки, добавляемой рукопожатием. С помощью TLS 1.2 было доказано, что HTTPS на самом деле БЫСТРЕЕ, чем HTTP, благодаря его совместимости с HTTP / 2.
TLS 1.3 еще больше усовершенствовал рукопожатие. Теперь это можно выполнить за один проход и включить нулевое возобновление приема-передачи (0-RTT). Частично это было сделано за счет уменьшения количества поддерживаемых наборов шифров с четырех алгоритмов до двух.
Теперь это просто алгоритм массового шифрования (симметричный / сеансовый) и алгоритм хеширования. Обмен ключами и согласование цифровой подписи были удалены. Обмен ключами теперь выполняется с использованием семейства Диффи-Хеллмана, которое по умолчанию обеспечивает идеальную прямую секретность и позволяет клиенту и серверу предоставлять свою часть общего секрета при первом взаимодействии. Это первое взаимодействие теперь тоже зашифровано, закрывая дверь для возможного вектора атаки.
Для получения дополнительной информации о новых функциях, выпущенных в TLS 1.3 посетите блог Cloudflare.
Отключение SSL 2.0 и 3.0 и TLS 1.0
Если вы не уверены, что ваши серверы по-прежнему поддерживают протоколы SSL, вы можете легко проверить это с помощью нашего теста SSL-сервера. Чтобы узнать, как отключить SSL 2.0 и 3.0 на популярных типах серверов, включая Apache, NGINX и Tomcat, ознакомьтесь с нашей соответствующей статьей поддержки. Если вам все еще нужно отключить TLS 1.0, мы тоже можем помочь вам в этом.
Итак, в чем разница между SSL и TLS? В вежливой беседе — немного — и многие люди продолжают использовать термины SSL и TLS как синонимы.Однако с точки зрения конфигурации вашего сервера есть некоторые существенные архитектурные и функциональные различия. И эти различия заключаются в промежутке между уязвимостями, устаревшими наборами шифров, предупреждениями безопасности браузера и безопасным сервером. Что касается ваших серверов, у вас должны быть включены только протоколы TLS.
Есть еще вопросы о настройке SSL / TLS и передовых методах? Дайте нам знать об этом в комментариях; мы рады помочь!
В чем разница? Какой из них использовать?
И TLS, и SSL — это протоколы, которые помогают безопасно аутентифицировать и передавать данные в Интернете.Но в чем разница между TLS и SSL? И вам нужно беспокоиться об этом?
В этой статье вы узнаете о ключевых различиях между TLS и SSL, а также о том, как оба протокола подключаются к HTTPS. Вы также узнаете, почему вам, как конечному пользователю, , вероятно, не нужно слишком беспокоиться о TLS и SSL или о том, используете ли вы «сертификат SSL» или «сертификат TLS».
Вы можете нажать ниже, чтобы перейти к определенному разделу или прочитать всю статью:
В чем разница между TLS и SSL?
TLS, сокращение от Transport Layer Security, и SSL, сокращение от Secure Socket Layers, являются криптографическими протоколами, которые шифруют данные и аутентифицируют соединение при перемещении данных в Интернете.
Например, если вы обрабатываете платежи по кредитной карте на своем веб-сайте, TLS и SSL могут помочь вам безопасно обработать эти данные, чтобы злоумышленники не могли получить их.
Так в чем разница между TLS и SSL?
Ну, TLS на самом деле является более поздней версией SSL . Он устраняет некоторые уязвимости безопасности в более ранних протоколах SSL.
Прежде чем вы узнаете больше об особенностях, важно понять базовую историю SSL и TLS.
SSL 2.0 был впервые выпущен в феврале 1995 года (SSL 1.0 никогда не выпускался публично из-за недостатков безопасности). Хотя SSL 2.0 был выпущен публично, он также содержал недостатки безопасности и был быстро заменен SSL 3.0 в 1996 году.
Затем, в 1999 году, была выпущена первая версия TLS (1.0) как обновление до SSL 3.0. С тех пор было выпущено еще три версии TLS, последний из которых — TLS 1.3 в августе 2018 года.
На данный момент оба общедоступных выпуска SSL устарели и имеют известные уязвимости безопасности (подробнее об этом позже).
Вот полная история выпусков SSL и TLS:
- SSL 1.0 — никогда не выпускался публично из-за проблем с безопасностью.
- SSL 2.0 — выпущен в 1995 году. Не рекомендуется в 2011 году. Известны проблемы безопасности.
- SSL 3.0 — выпущен в 1996 году. Не рекомендуется в 2015 году. Известны проблемы безопасности.
- TLS 1.0 — выпущен в 1999 году как обновление до SSL 3.0. Планируется прекращение поддержки в 2020 году.
- TLS 1.1 — выпущен в 2006 году. Планируется прекращение поддержки в 2020 году.
- TLS 1.2 — выпущен в 2008 году.
- TLS 1.3 — выпущена в 2018 году.
Как TLS и SSL работают для защиты данных?
Вот общий процесс работы SSL и TLS.
Когда вы устанавливаете сертификат SSL / TLS на свой веб-сервер ( часто просто называют «сертификатом SSL») , он включает открытый ключ и закрытый ключ, которые аутентифицируют ваш сервер и позволяют вашему серверу шифровать и дешифровать данные.
Когда посетитель заходит на ваш сайт, его веб-браузер ищет сертификат SSL / TLS вашего сайта.Затем браузер выполнит «рукопожатие», чтобы проверить действительность вашего сертификата и аутентифицировать ваш сервер. Если сертификат SSL недействителен, ваши пользователи могут столкнуться с ошибкой «ваше соединение не защищено», из-за чего они могут покинуть ваш веб-сайт.
Как только браузер посетителя определяет, что ваш сертификат действителен и аутентифицирует ваш сервер, он, по сути, создает зашифрованное соединение между ним и вашим сервером для безопасной передачи данных.
Здесь также появляется HTTPS (HTTPS означает «HTTP через SSL / TLS»).
HTTP и более поздний HTTP / 2 — это протоколы приложений, которые играют важную роль в передаче информации через Интернет.
При использовании обычного HTTP эта информация уязвима для атак. Но когда вы используете HTTP через SSL или TLS (HTTPS), вы шифруете и аутентифицируете эти данные во время транспортировки, что делает их безопасными.
Вот почему вы можете безопасно обрабатывать данные кредитной карты через HTTPS, но не , а через HTTP, а также почему Google Chrome так настойчиво продвигает HTTPS.
Почему он называется сертификатом SSL, если SSL устарел?
Выше вы узнали, что TLS — это более новая версия SSL и что обе общедоступные версии SSL устарели в течение нескольких лет и содержат известные уязвимости безопасности.
Это может вызвать у вас вопрос: почему он называется сертификатом SSL, а не сертификатом TLS? В конце концов, TLS — это современный протокол безопасности.
Например, если вы посмотрите на страницу функций Kinsta, вы увидите, что Kinsta рекламирует бесплатный сертификат SSL, а не бесплатный сертификат TLS.
Не волнуйтесь: Kinsta не использует устаревшие технологии!
Нет, причина, по которой большинство людей до сих пор называют их сертификатами SSL, в основном связана с брендингом. Большинство основных поставщиков сертификатов по-прежнему называют сертификаты SSL-сертификатами, поэтому соглашение об именах сохраняется.
На самом деле, все «SSL-сертификаты», которые вы видите в рекламе, на самом деле являются сертификатами SSL / TLS (включая бесплатные сертификаты SSL, которые мы предлагаем как часть нашей интеграции с Cloudflare).
То есть с вашим сертификатом можно использовать как протоколы SSL, так и TLS.
Не существует просто сертификата SSL или сертификата TLS, и вам не нужно беспокоиться о замене сертификата SSL на сертификат TLS.
Что следует использовать: TLS или SSL? Заменяет ли TLS SSL?
Да, TLS заменяет SSL. И да, вы должны использовать TLS вместо SSL.
Как вы узнали выше, оба общедоступных выпуска SSL устарели в значительной степени из-за известных уязвимостей в них.Таким образом, в 2019 году и далее SSL не является полностью безопасным протоколом.
TLS, более современная версия SSL, безопасна. Более того, последние версии TLS также предлагают преимущества в производительности и другие улучшения.
Подпишитесь на информационный бюллетень
Хотите узнать, как мы увеличили трафик более чем на 1000%?
Присоединяйтесь к 20 000+ другим пользователям, которые получают нашу еженедельную новостную рассылку с инсайдерскими советами по WordPress!
Подпишитесь сейчас
TLS не только стал более безопасным и производительным, но и большинство современных веб-браузеров больше не поддерживают SSL 2.0 и SSL 3.0. Например, Google Chrome прекратил поддержку SSL 3.0 еще в 2014 году, а большинство основных браузеров планируют прекратить поддержку TLS 1.0 и TLS 1.1 в 2020 году.
Фактически, Google начал показывать предупреждения ERR_SSL_OBSOLETE_VERSION в Chrome.
Так как же убедиться, что вы используете самые последние версии TLS, а не старые небезопасные протоколы SSL?
Во-первых, помните, что ваш сертификат не совпадает с протоколом, который использует ваш сервер.Вам , а не , нужно изменить свой сертификат, чтобы использовать TLS. Несмотря на то, что он может быть обозначен как «сертификат SSL», ваш сертификат уже поддерживает протоколы SSL и TLS.
Вместо этого вы контролируете, какой протокол использует ваш веб-сайт на уровне сервера .
Если вы размещаете на Kinsta, Kinsta уже включает TLS 1.3, которая является самой современной, безопасной и производительной версией, а также TLS 1.2.
Если вы размещаете в другом месте, вы можете использовать инструмент SSL Labs, чтобы проверить, какие протоколы включены для вашего сайта.
Например, если вы тестируете веб-сайт, размещенный в Kinsta, вы можете увидеть, как Kinsta включает TLS 1.2 и TLS 1.3, но отключает старые небезопасные версии SSL:
Как проверить, какие протоколы SSL / TLS использует ваш сервер.
Если вы обнаружите, что ваш сервер по-прежнему поддерживает устаревшие протоколы SSL, вы можете обратиться в службу поддержки своего хоста за помощью или выполнить следующие инструкции, чтобы отключить SSL на двух самых популярных веб-серверах (Apache и Nginx):
Почему Kinsta поддерживает несколько протоколов TLS?
Если TLS 1.3 — самый современный и производительный протокол, почему Kinsta также пытается включить немного более старый протокол TLS 1.2?
Другими словами: в чем преимущество включения нескольких протоколов?
Как вы узнали выше, квитирование SSL / TLS состоит из двух частей:
- Ваш веб-сервер
- Клиент (обычно это веб-браузер посетителя)
Для того, чтобы квитирование работало, и должны поддерживать один и тот же протокол.
Итак, основным преимуществом наличия нескольких протоколов является совместимость.
Например, в то время как Chrome и Firefox добавили поддержку TLS 1.3 почти сразу после его выпуска в 2018 году, Apple и Microsoft потребовалось немного больше времени, чтобы добавить поддержку TLS 1.3.
Даже в 2019 году следующие браузеры все еще не поддерживают TLS 1.3:
- Internet Explorer
- Opera Mini
- Браузер Android
- Opera Mobile
- UC Browser для Android
- Интернет Samsung
- Браузер Baidu
TLS 1.3 поддержка веб-браузера
Но хотя TLS 1.3 еще не получил полного внедрения, все основные браузеры поддерживают TLS 1.2 в 2019 г .:
Поддержка веб-браузера TLS 1.2
Включив на сервере TLS 1.3 и TLS 1.2, вы можете гарантировать совместимость, несмотря ни на что, и при этом получить преимущества TLS 1.3 для браузеров, которые его поддерживают, таких как Chrome и Firefox.
Если вы хотите проверить, какую версию SSL / TLS использует ваш веб-браузер, вы можете использовать инструмент How’s My SSL:
Как проверить, какие протоколы SSL / TLS использует ваш браузер
Что касается безопасности, вы везде видите SSL, TLS, HTTPS… и ты можешь заблудиться. Что вообще означают все эти аббревиатуры? Вот все ответы, которые вам нужны! 🔐😀Нажмите, чтобы написать твит
Сводка
Подводя итог, можно сказать, что TLS и SSL — это протоколы для аутентификации и шифрования передачи данных в Интернете.
Они тесно связаны, и TLS на самом деле является более современной и безопасной версией SSL.
Хотя SSL по-прежнему является доминирующим термином в Интернете, большинство людей действительно имеют в виду TLS, когда говорят о SSL, потому что обе общедоступные версии SSL небезопасны и давно устарели.
Чтобы использовать протоколы SSL и TLS, вам необходимо установить сертификат на свой сервер (вот как установить сертификат SSL на WooCommerce). Опять же, хотя большинство людей называют их «сертификатами SSL», эти сертификаты поддерживают и протоколы SSL и TLS.
Вы делаете , а не , вам нужно беспокоиться об «замене» вашего SSL-сертификата на TLS-сертификат. Если вы уже установили «SSL-сертификат», можете быть уверены, что он также поддерживает TLS.
Важно использовать последние версии TLS, потому что SSL больше не является безопасным, но ваш сертификат не определяет протокол, который использует ваш сервер. Вместо этого, получив сертификат, вы можете выбрать, какие протоколы использовать на уровне сервера.
Если вы размещаете в Kinsta, Kinsta в настоящее время поддерживает TLS 1.2 и TLS 1.3, которые безопасны и поддерживаются всеми основными браузерами.
Если вам понравилось это руководство, то вам понравится наша поддержка.Все планы хостинга Kinsta включают круглосуточную поддержку наших опытных разработчиков и инженеров WordPress. Общайтесь с той же командой, которая поддерживает наших клиентов из списка Fortune 500. Ознакомьтесь с нашими тарифами
SSL против TLS: расшифровка разницы между SSL и TLS
Знаете ли вы, как работают SSL и TLS?
протоколы отличаются? Давай узнаем, как много ты знаешь…
Черепаха против черепахи. Таблетка против таблетки. Кладбище vs кладбище. SSL против TLS. Можете ли вы сказать, что общего у всех этих пар?
Подумайте об этом
момент.Если вы думаете, что каждый из этих терминов означает одно и то же, то вы
неправильно! На самом деле они не синонимы. Да, вы правильно прочитали — вот
существенные различия между терминами в каждой паре, и большинство из нас может не
пойми. Пока мы не будем вдаваться в различия между первыми парами
в этой статье (независимо от вашего текущего уровня любопытства) мы рассмотрим
разница между безопасным уровнем сокетов и безопасностью транспортного уровня (SSL
и TLS, SSL против TLS, TLS против SSL, или как вы хотите на него ссылаться).
SSL против TLS: основные различия между этими протоколами
Когда люди говорят о сертификатах SSL / TLS, они имеют в виду цифровые файлы X.509, которые позволяют веб-сайтам обслуживаться через HTTPS (с использованием безопасного протокола TLS поверх небезопасного HTTP-соединения) с использованием шифрования с открытым ключом. Итак, SSL и TLS — это одно и то же? Не совсем. Но если они разные, то почему термины взаимозаменяемы? Что ж, ответ двоякий:
- Потому что они оба защищенные протоколы
которые устанавливают зашифрованную связь между веб-сервером и клиентом
(браузер) через HTTPS. - Люди медленно меняются, и
в ИТ нужно знать много терминов. Люди знакомы с SSL, поэтому
упрощает работу, называя TLS SSL.
Но причина их различий в том, что TLS является преемником протокола SSL. Итак, что это значит? При сравнении SSL и TLS протоколы SSL и TLS различаются по своим функциям, аутентификации сообщений, сообщениям с предупреждениями, протоколу записи и силе шифрования. Они также различаются, особенно с точки зрения процесса, известного как «рукопожатие SSL / TLS.«Этот процесс выполняется, когда обе стороны (клиент и сервер) взаимодействуют друг с другом.
Этот процесс рукопожатия в основном отвечает за:
- Определение типа шифрования, которое будет использоваться для защиты данных во время транзакции,
- Аутентификация сервера (или обеих сторон) и
- Создание / обмен сеансовыми ключами, которые будут использоваться на протяжении всей транзакции.
SSL против TLS: как SSL и TLS устанавливают соединения
Важно отметить разницу
между тем, как SSL и TLS устанавливают соединения.Например, SSL
рукопожатие устанавливает явные соединения через порт. TLS, с другой стороны,
облегчает неявные соединения через протокол.
Это рукопожатие действует на определенных
методы / алгоритмы, называемые «комплектами шифров». Хотя есть много отличий
между SSL и TLS, фундаментальное различие между SSL и TLS заключается в
эти наборы шифров, которые играют важную роль в безопасности
связь.
Набор шифров включает алгоритм обмена ключами, алгоритм аутентификации / проверки, алгоритм массового шифрования и алгоритм кода аутентификации сообщения (MAC).Каждая версия SSL / TLS имеет свой собственный поддерживаемый набор комплектов шифров, а в новых версиях появляются более безопасные комплекты шифров, которые повышают безопасность и производительность соединения.
Итак, как видите, SSL и TLS отличаются
много способов. Вот краткое изложение всех различий и того, как различать
SSL против TLS:
| SSL | TLS |
| SSL расшифровывается как «Secure Socket Layer».” | TLS означает «Безопасность транспортного уровня». |
| Netscape разработала первую версию SSL в 1995 году. | Первая версия TLS была разработана Инженерная группа Интернета (IETF) в 1999 году. |
| SSL — это криптографический протокол, использующий явные соединения, чтобы установить безопасную связь между веб-сервером и клиентом. | TLS также является криптографическим протоколом, который обеспечивает безопасная связь между веб-сервером и клиентом через неявные соединения.Это преемник протокола SSL. |
| Выпущено три версии SSL: SSL 1.0, 2.0 и 3.0. | Выпущено четыре версии TLS: TLS 1.0, 1.1, 1.2 и 1.3. |
| Все версии SSL были признаны уязвимыми, и все они устарели. | TLS 1.0 и 1.1 были «взломаны» и устарело с марта 2020 года. TLS 1.2 — наиболее широко распространенный протокол. версия. |
История SSL и TLS: с 90-х годов до наших дней
Как мы достигли нынешнего положения в терминах
TLS заменяет SSL? Мы узнаем, как использование SSL в конечном итоге превратилось в использование
TLS.
Начало 90-х: запуск SSL
С того момента, как Бернерс-Ли представил миру «всемирную паутину» (WWW) в 1990-х годах, мы стали свидетелями того, что могло быть возможным только в фильмах и научно-фантастических книгах. Мы стали свидетелями Интернета, совершенно нового мира, повсюду написанного «интриги». Появление всемирной паутины демократизировало Интернет, и к 1995 году, по оценкам, в Интернете было около 16 миллионов пользователей.
Столь быстрое распространение Интернета привело к
много новых возможностей, а также некоторые проблемы.Одна из основных проблем заключалась в
безопасность и конфиденциальность пользователей. Когда компании начали выходить в Интернет,
были массовые опасения относительно безопасности конфиденциальных данных, таких как
информация о кредитной карте, финансовая информация, пароли и т. д.
Вот что породило безопасные сокеты
Layer, или сокращенно SSL.
1995: Пришло время SSL…
Идея
SSL была придумана Тахером Эльгамалом, всемирно известным криптографом, известным как «отец SSL.«Компания, известная как Netscape, разработала SSL, когда Тахер был их главным ученым. SSL был создан, чтобы служить интернет-протоколом, который облегчил бы безопасную связь. Проще говоря, SSL был в основном набором инструкций, которые направляют клиента (обычно веб-браузер) и сервер по безопасной передаче данных.
SSL 1.0, первая версия SSL, была
никогда не публиковался, поскольку содержал серьезные недостатки безопасности. Это привело к
выпуск SSL 2.0 в 1995 г., который также включал несколько средств защиты
уязвимости — как с криптографической, так и с практической точки зрения.Эти
недостатки не были достаточно серьезными, чтобы вызвать кризис, но их было достаточно, чтобы
поиск его преемника.
В итоге третья версия (SSL 3.0)
должен был быть выпущен в 1996 году. Этот последний протокол был полностью переработан по сравнению с
его предшественники и были значительным обновлением по сравнению с предыдущими двумя версиями. В
окончательный проект SSL 3.0 был опубликован Инженерной группой Интернета (IETF).
в 1996 году.
1999: Когда SSL становится TLS — запуск TLS 1.0
Три года спустя Кристофер Аллен и
Тим Диркс из компании Consensus Development написал TLS 1.0 протокол, модернизированный
версия SSL 3.0. Хотя изменение названия предполагает существенную разницу
между ними не было много различий.
Изменение имени, по словам Диркса, было жестом сохранения лица со стороны Microsoft. Он написал:
«В рамках конного трейдинга нам пришлось внести некоторые изменения в SSL 3.0 (чтобы не выглядело, что IETF просто штамповал протокол Netscape), и нам пришлось переименовать протокол (по той же причине).Так родился TLS 1.0 (который на самом деле был SSL 3.1). И, конечно, сейчас, оглядываясь назад, все это выглядит глупо ».
2000-е-настоящее время: добавлены версии TLS 1.1, 1.2 и 1.3
в игру
С момента выпуска первой версии TLS были выпущены еще три версии TLS. Первым из них был TLS 1.1, выпущенный в 2006 году. Эта версия включала несколько значительных обновлений по сравнению с TLS 1.0. Это включает дополнительную защиту от атак с цепочкой блоков шифров (CBC) и поддержку параметров регистрации Internet Assigned Numbers Authority (IANA).Позже обе эти версии (TLS 1.0 и 1.1) были признаны уязвимыми, и обе будут прекращены в марте 2020 года.
Вскоре после выпуска TLS 1.1 в 2006 г.
TLS 1.2 был выпущен в 2008 году. Эта версия поставлялась с основными обновлениями безопасности в
условия спецификации хеша и алгоритма, используемых клиентом и сервером. Его
почти мгновенный выпуск побудил пользователей перейти непосредственно на TLS 1.2,
вместо TLS 1.1. На данный момент TLS 1.2 является наиболее широко используемым SSL / TLS.
протокол.
Благодаря предлагаемым усовершенствованиям безопасности
с помощью TLS 1.2 он зарекомендовал себя как безопасный протокол, и через десять лет после
был выпущен его выпуск, его преемник, TLS 1.3. TLS 1.3 был выпущен в 2018 году.
и предлагал важные функции безопасности, такие как удаление MD5 и SHA-224
поддержка, использование Perfect Forward Secrecy и т. д. В настоящее время мы
переход с TLS 1.2 на TLS 1.3. Все основные игроки — как центры сертификации, так и браузеры —
настаивают на его принятии.
SSL против TLS: нужно ли вам заменить сертификаты SSL
с сертификатами TLS?
Ну конечно нет.Это связано с тем, что и «сертификат SSL», и «сертификат TLS» по сути означают одно и то же: это цифровые сертификаты X.509, которые помогают аутентифицировать сервер и облегчают процесс установления связи для создания безопасного соединения.
Некоторые люди называют их «SSL
сертификаты », а другие называют их« сертификатами TLS ».
Имя не имеет большого значения, потому что сертификат — это не то же самое, что
протокол. Как бы вы их ни называли, важен протокол, которым он управляет.
на.И эти протоколы определяются конфигурацией вашего сервера, а не
цифровые сертификаты. Итак, вы должны убедиться, что ваш веб-сервер поддерживает
новейшие протоколы TLS.
Аналогичным образом необходимо также включить сервер
поддержка более высокого уровня шифрования. Почему? Поскольку надежность шифрования не
на основе сертификата — это зависит от конфигурации сервера
и клиент.
Сказав все это, эти сертификаты
чаще всего называются «SSL-сертификатами». Многие люди начали использовать термин
«Сертификат TLS», но не нужно путать их, поскольку оба означают
тоже самое.
Последние мысли: SSL и TLS связаны, но не одно и то же
Как вы узнали из этой статьи о SSL и
TLS, TLS — это просто ответвление наименования менее безопасного протокола SSL. Они
по сути выполняет те же функции с точки зрения обслуживания веб-сайта через HTTPS,
но как они туда попадают. Если бы TLS не был разработан, мы бы говорили
о чем-то вроде «SSL 5.0 против SSL 4.0» вместо «SSL против TLS».
Что такое сертификат SSL / TLS и зачем он вам нужен?
Большинство компаний, работающих в Интернете, осознают важность сертификатов SSL и делают все необходимое, чтобы поддерживать их в актуальном состоянии.Вы, наверное, знаете, что они предназначены для защиты как вашего бизнеса, так и ваших клиентов.
Возможно, вы не совсем понимаете вот что: что такое SSL-сертификат? Как это работает, зачем он вам нужен и где его взять? Вот некоторые основы, которые помогут вам лучше управлять своей безопасностью SSL.
Что такое сертификат SSL?
Что такое SSL?
Сертификаты Secure Sockets Layer (SSL), иногда называемые цифровыми сертификатами, используются для установления зашифрованного соединения между браузером или компьютером пользователя и сервером или веб-сайтом.
SSL означает уровень защищенных сокетов. Это тип технологии, используемый для создания защитного слоя шифрования информации, передаваемой между сервером и браузером. Это означает, что любая информация, отправляемая в браузер пользователя, или любая информация, отправляемая обратно в браузер, зашифрована.
Чтобы использовать безопасность SSL, вам понадобится сертификат SSL, который выдается центром сертификации (ЦС). Вам нужно будет предоставить информацию о своем бизнесе и подать заявку, после чего ЦС подтвердит ваши данные и выдаст сертификат SSL, что позволит вам защитить свой веб-сайт.После этого на вашем сайте будет использоваться протокол приложения HTTPS (вместо HTTP), где буква «S» будет означать, что ваш сайт безопасен, а также значок замка.
Как работает сертификат SSL?
Сертификат SSL состоит из двух частей: открытый ключ и закрытый ключ. Когда вы подаете заявку на сертификат SSL, вам сначала понадобится закрытый ключ для создания запроса на подпись сертификата (CSR), который содержит сведения о компании для целей проверки. Как только эта информация будет подтверждена центром сертификации, вы получите сертификат SSL.Закрытый ключ также важен, если у вас есть сертификат SSL, поскольку он помогает защищать и проверять соединения, но обязательно, чтобы вы держали этот ключ в секрете, чтобы его нельзя было использовать для кражи личных данных. Открытый ключ, связанный с вашим SSL-сертификатом, просто публичный. Это позволяет другим проверять подлинность SSL, не имея доступа к вашему закрытому ключу.
Теперь ваш веб-сервер защищен, а связь между устройствами будет зашифрована. Значение этого заключается в том, что любой, кто перехватывает связь между вашим сервером и браузерами, не сможет получить доступ к отправляемой информации, защищая любые конфиденциальные данные, которые могут содержаться в передаче.
Зачем мне нужен сертификат SSL?
В самом простом смысле вам нужен сертификат SSL для защиты вашей компании и ваших клиентов от кражи данных, мошенничества с идентификационными данными и других злонамеренных действий. Есть и другие преимущества.
Например, клиенты могут держаться подальше от веб-сайтов, на которых нет значка замка и протокола приложения HTTPS, тем более что многие браузеры теперь отображают предупреждение «небезопасно» для сайтов, которые поддерживают только HTTP (а не HTTPS).Вы также можете увидеть лучший рейтинг и конверсию, если используете сертификат SSL, чтобы показать, что ваш сайт безопасен (https://webmasters.googleblog.com/2014/08/https-as-ranking-signal.html).
Кто может помочь мне получить сертификат SSL?
Сертификат SSL, которому доверяют браузеры, можно получить только через приложение с центром сертификации. Однако вам не нужно идти в одиночку. Secure128 может помочь вам определить уровень безопасности, который подходит вам, и провести вас через процесс подачи заявки и проверки, а также управлять, обновлять и поддерживать ваши сертификаты SSL.
Почему я должен выбрать Secure128 для моих потребностей в сертификате SSL?
Теперь, когда мы ответили на вопрос «что такое сертификат SSL?», Вам нужно знать, где его получить, и Secure128 — хороший выбор. Secure128 является не только гордым партнером Symantec и нескольких других центров сертификации, но и предлагает различные услуги поддержки, чтобы гарантировать, что каждый бизнес имеет доступ к продуктам и услугам, необходимым для безопасной работы в сети.
SSL против TLS — в чем разница?
23 июня, 2021
Джейсон Пармс
TLS vs.Сертификат SSL — это криптографические протоколы, которые шифруют данные, которыми обмениваются / передаются между веб-сервером и пользователем.
Уф! Интернет-безопасность — это мир, наполненный жаргоном. Для такого новичка, как я, кошмарно понять эти термины и то, как они работают вместе.
Требуется много усилий, чтобы понять, как они работают и чем они отличаются друг от друга.
Если вы недавно читали о SSL, вы бы тоже наткнулись на TLS.
SSL относится к Secure Sockets Layer, тогда как TLS относится к безопасности транспортного уровня.По сути, это одно и то же, но совершенно разные.
Насколько они похожи? SSL и TLS — это криптографические протоколы, которые аутентифицируют передачу данных между серверами, системами, приложениями и пользователями. Например, криптографический протокол шифрует данные, которыми обмениваются веб-сервер и пользователь.
SSL был первым в своем роде криптографическим протоколом. TLS, с другой стороны, был последней обновленной версией SSL.
Зачем нужен сертификат SSL / TLS?
Кибербезопасность стала серьезной угрозой, которая распространяется по всем разделам Интернета.От школ до предприятий и частных лиц он подвергает риску пользовательские данные любого типа и размера. Риск особенно возрастает при обмене информацией через клиентские и серверные системы.
Необходима безопасная система, которая шифрует поток данных с любой стороны. В этом помогает сертификат SSL / TLS. Он действует как система шифрования конечных точек, которая шифрует данные, предотвращая несанкционированный доступ хакеров.
В наши дни SSL также приобрел важность как серьезный сигнал ранжирования в связи с объявлением Google.Веб-сайты с сертификатами SSL получают более высокий рейтинг в поисковых системах, удобнее для пользователей и не вызывают никаких проблем с безопасностью — даже во время транзакций электронной коммерции.
Краткое описание SSL
Netscape разработала протокол SSL в 1994 году. Он был задуман как система, которая обеспечит безопасную связь между клиентскими и серверными системами в сети. Постепенно IETF (Инженерная группа Интернета) подобрала протокол и стандартизировала его как протокол. За этим последовали две версии SSL, которые устранили уязвимости, обнаруженные в версии 1.Текущая версия SSL — SSL 3.0. Если мы посмотрим на приведенную ниже историю, мы можем предположить, что IETF серьезно пыталась защитить онлайн-данные с помощью надежной защиты в лучшем виде.
| SSL 1.0 | Из-за недостатка безопасности SSL 1.0 не был выпущен. |
| SSL 2.0 | SSL v2.0 был первым публичным выпуском SSL от Netscape. Он был выпущен в феврале 1995 года, но из-за недостатков в конструкции Netscape выпустила SSL v.3. Однако SSL v.2.0 устарела в 2011 году. |
| SSL 3.0 | SSL v3 был обновленной версией более ранней версии SSL v2.0, которая исправила несколько недостатков конструкции безопасности SSL v2.0. Однако SSL v3.0 считался небезопасным в 2004 году из-за атаки POODLE. |
Кратко о TLS
TLS означает безопасность транспортного уровня, которая является преемником криптографического протокола SSL 3.0, выпущенного в 1999 году.
| TLS 1.0 | TLS 1.0, который был обновлением SSL v.3.0, выпущенного в январе 1999 года, но позволяет понизить соединение до SSL v.3.0. |
| TLS 1.1 | После этого в апреле 2006 года был выпущен TLS v1.1, который был обновлением версии TLS 1.0. Он добавил защиту от атак CBC (Cipher Block Chaining). В марте 2020 года Google, Apple, Mozilla и Microsoft объявили о прекращении поддержки версий TLS 1.0 и 1.1. |
| TLS 1,2 | TLS v1.2 был выпущен в 2008 году, что позволяет указывать хэш и алгоритм, используемый клиентом и сервером.Он позволяет использовать шифрование с проверкой подлинности, для которого была добавлена дополнительная поддержка с дополнительными режимами данных. TLS 1.2 смог проверить длину данных на основе набора шифров. |
| TLS 1.3 | TLS v1.3 был выпущен в августе 2018 года и имел основные функции, которые отличают его от его более ранней версии TLS v1.2, такие как удаление поддержки MD5 и SHA-224, требование цифровой подписи при использовании более ранней конфигурации, обязательное использование идеальной прямой секретности в В случае обмена ключами на основе открытого ключа сообщения подтверждения теперь будут зашифрованы после «Server Hello». |
Различия между SSL и TLS
Однако различия между SSL и TLS очень незначительны. Фактически, только технический специалист сможет заметить различия. Заметные отличия включают:
Наборы шифров
Протокол SSL
предлагает поддержку набора шифров Fortezza. TLS не предлагает поддержки. TLS следует улучшенному процессу стандартизации, который упрощает определение новых наборов шифров, таких как RC4, Triple DES, AES, IDEA и т. Д.
Предупреждающие сообщения
SSL имеет предупреждающее сообщение «Нет сертификата». Протокол TLS удаляет предупреждающее сообщение и заменяет его несколькими другими предупреждающими сообщениями.
Протокол записи
SSL использует код аутентификации сообщения (MAC) после шифрования каждого сообщения, в то время как TLS, с другой стороны, использует HMAC — хэш-код аутентификации сообщения после каждого шифрования сообщения.
Процесс установления связи
В SSL вычисление хэшей также включает главный секрет и блокировку, в то время как в TLS хэши вычисляются по сообщению рукопожатия.
Аутентификация сообщений
Аутентификация сообщений SSL сопоставляет ключевые детали и данные приложения специальным образом, в то время как версия TLS полагается на HMAC Hash-based Message Authentication Code.
Это существенные различия между сертификатом SSL и TLS. Как я уже упоминал ранее, чтобы понять различия, нужен натренированный глаз.
В двух словах, SSL устарел, а TLS - это новое название старого протокола SSL в качестве современного стандарта шифрования, используемого всеми.Технически TLS более точен, но все знают SSL.
Несколько замечаний по протоколу TLS
- Он предотвращает вмешательство злоумышленников в обмен данными между сервером и пользователем.
- Он также предотвращает прослушивание злоумышленниками сообщений сервера.
- TLS увеличивает задержку трафика сайта.
- TLS использует асимметричное шифрование для установления соединения, тогда это позволяет симметричное шифрование для клиента и сервера для более быстрого соединения.
- С добавлением HTTP / 2 TLS ускоряет соединение.
Наконец, нужен ли вам сертификат SSL / TLS?
Если вы посмотрите на сертификат SSL и сертификат TLS, оба они выполняют одну и ту же задачу по шифрованию обмена данными. TLS был обновленной и безопасной версией SSL.