wwwoldi.ru

About Me

Dashy

Hello word I am dashy Guy

Разное

Tls это: Что такое TLS-рукопожатие и как оно устроено

alexxlab
No Comments

Содержание

What is: SSL/TLS в деталях

Протоколы криптографии предоставляют возможность установления защищённых соединений между двумя удалёнными хостами.

Два наиболее часто встречающихся набора протоколов — SSL/TLS, основная задача которых заключается в обеспечении конфидициальности передаваемых данных, обеспечении целостности данных (т.е. гарантирование того, что данные не были изменены или подменены во время доставки между узлами), а так же в обеспечении идентификации и аутенфикации ресурсов и хостов с использованием цифровых сертификатов.

Каждый протокол SSL/TLS включает в себя набор внутренних протоколов (subprotocols), которые рассмотрены в разделе Обзор SSL/TLS соединения.

Задачи SSL/TLS соединения:

  • обеспечение приватности с помощью шифрования передаваемых данных
  • аутентификация с помощью сертификатов
  • обеспечение достоверности данных с помощью проверки целостности данных

Ниже будут рассмотрены основные аспекты SSL/TLS. К сожалению, как бы ни хотелось — всего описать не получится, но постарался собрать и хотя бы кратко описать самое важное (плюс ссылки в тексте и в конце поста).

TSL vs SSL: история

Основное отличие между ними — TLS является наследником протокола SSL, и использует более безопасные способы обеспечения безопасности.

Аббревиатуры:

  • SSL — Secure Socket Layer
  • TLS — Transport Layer Security

Краткая история SSL/TLS:

  1. SSL был разработан компанией Netscape, но версия 1.0 не была опубликована и использована из-за проблем безопасности в её реализации
  2. SSL 2.0 была выпущена в феврале 1995, но так же содержала уязвимости, потому:
  3. в 1996 появилась версия SSL 3.0

SSL 2.0 официально признан устаревшей версией в 2011 году (см. RFC 6176), а SSL 3.0 — в 2015 (RFC 7568), хотя версия 3.0 была объявлена небезопасной для использования ещё в 2004 году из-за обнаружения уязвимости POODLE.

Из-за проблем с безопасностью, а так же из-за проблем с Netscape, связанных с юридическими вопросами, в 1999 на смену SSL пришёл протокол TLS, основанный на SSL v3.0.

TLS являлся окрытым стандартном (в отличии от SSL, поддерживаемого компанией Netscape) и в результате полностью заменил собой SSL.

  1. TLS 1.0 выпущен в январе 1999, RFC 2246, и использовался вплоть до 2016 года, когда первый раз был объявлен устаревшим (позже его «устаревание» продлили до 2018 года).
  2. TSL 1.1 выпущен в апреле 2006, RFC 4346, с 30-го июня 2018 полностью заменит TLS 1.0
  3. TLS 1.2 появился в августе 2008, RFC 5246, с 30-го июня 2018 полностью заменит TLS 1.0 и будет являться рекомендуемым протоколом для использования
  4. TLS 1.3 ещё находится в состоянии черновика

Аббревиатуры SSL и TLS используются взаимозаменяемы, и под SSL как правило подразумевается TLS, т.к. в большистве случаев (а особенно в 2018) клиенты предлагают (см ClientHello) использовать версии TLS 1.1 и 1.2.

По теме:

SSL/TLS: основные понятия

Прежде, чем перейти к соединению и TLS Handshake части — рассмотрим некоторые основные понятия.

SSL certificate

Сертификат открытого ключа (public key certificate, digital certificate или identity certificate, а так же сертификат, сертификат ключа подписи, сертификат ключа проверки электронной подписи) — электронный документ, подтверждающий принадлежность публичного ключа его владельцу.

Сертификат выдаётся и подписывается Certificate Authorities, которые подписывают выданные сертификаты своей цифровой подписью, подтверждая, что владелец сертификата (и публичного ключа, включённого в этот сертификат) был проверен:

TLS сертификат как правило включает в себя поля:

  • Version Number: версия сертификата ( см X.509)
  • Serial Number: используется для идентификации сертификата его Certificate Authorities
  • Signature Algorithm: алгоритм, использованный для подписи публичного ключа
  • Issuer: кем выдан и подписан сертификат (Certificate Authority)
  • Not Before и Not After: срок действия (валидности) сертификата
  • Subject name: кому принадлежит сертификат
  • Subject Public Key Info
    • Public Key Algorithm: алгоритм, использованный для подписи публичного ключа
    • Subject Public Key: сам публичный ключ владельца сертификата
  • Certificate Signature Algorithm: алгоритм, использованный для подписи сертификата
  • Certificate Signature: цифровая подпись сертификата

Например сертификат для RTFM выглядит так:

echo | openssl s_client -servername rtfm.co.ua -connect rtfm.co.ua:443 2>/dev/null | openssl x509 -text

Certificate:

Data:

Version: 3 (0x2)

Serial Number:

03:af:86:47:72:69:53:70:5b:ee:b6:76:73:a6:f3:56:8f:f4

Signature Algorithm: sha256WithRSAEncryption

Issuer: C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3

Validity

Not Before: Feb  6 09:07:34 2018 GMT

Not After : May  7 09:07:34 2018 GMT

Subject: CN = rtfm.co.ua

Subject Public Key Info:

Public Key Algorithm: rsaEncryption

Public-Key: (2048 bit)

Modulus:

00:b2:05:69:79:41:19:b7:43:50:d9:03:a9:50:b7:

…

X509v3 Subject Alternative Name:

DNS:rtfm.co.ua, DNS:www.rtfm.co.ua

…

Signature Algorithm: sha256WithRSAEncryption

49:1c:cc:48:f3:8c:6e:05:7e:c7:94:bf:33:e0:05:d7:98:11:

…

Получить только публичный ключ из сертификата можно так:

openssl s_client -servername rtfm.co.ua -connect rtfm.co.ua:443 | openssl x509 -pubkey -noout 2>/dev/null

depth=2 O = Digital Signature Trust Co., CN = DST Root CA X3

verify return:1

depth=1 C = US, O = Let’s Encrypt, CN = Let’s Encrypt Authority X3

verify return:1

depth=0 CN = rtfm.co.ua

verify return:1

——BEGIN PUBLIC KEY——

MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsgVpeUEZt0NQ2QOpULcJ

8Pe2pTpTFzflNfeMOLT2tFUKFPkEU4Qasu5FoL1p5RzWyGh8kOu7sN5F6Up5U1V+

5EAghuG8amGcx3oUXSDlv/TUkesiVPtYil87qfj8q5Sm561oTx4Q5pch3JWYyWjb

uCIRNeB7FuA+Ts7iEfIc1dXtj2wHIp6wqwsCcBPa/xFUAjN1yWc2+rmZSs4ctaEL

9BwVx3kMhwkWsU4nwEQygGZR+ofeVjKIxu2fjWLhlX9xx4LQePO+fNTu4iMOrVok

M4Ch/T33Z44bxjGwsaMY7tZgMZhbPRBhAkA8RNx8f1Jmk/tSQOMFkghsdaq7kVP4

FwIDAQAB

——END PUBLIC KEY——

CipherSuites

Cipher suite — это комбинация криптографических алгоритмов, которые будут использованы для обеспечения безопасности сессии.

Как правило, в неё входят алгоритмы для:

  • алгоритм обмена ключами
  • аутентификации сервера
  • шифрования данных
  • алгоритм контроля целостности (Message Authentication Code, MAC)

Например — для соединения с RTFM клиент (браузер) выбирает набор TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384:

Тут:

  • TLS: используемый протокол
  • ECDHE: алгоритм обмена ключами сессии (Elliptic curve Diffie–Hellman ephemeral)
  • RSA: алuоритм аутентификации (RSA)
  • AES_256_GCM: алгоритм шифрования данных (Advanced Encryption Standard 256 bit Galois/Counter Mode)
  • SHA384: алгоритм Message Authentication Code (MAC) (Secure Hash Algorithm 384 bit)

См. по теме:

Message Authentication Code (MAC)

Message Authentication Code, или криптографическая контрольная сумма сообщения — способ аутентификации и проверки целостности сообщения, основанный на цифровой подписи сообщения (или блока данных на Record Layer).

Подпись создаётся с помощью секретного ключа (client_write_MAC_key и server_write_MAC_key в ChangeCipherSpec и Finish) и самого сообщения.

Hash Based Message Authentication Code (HMAC) — тип MAC, основанный на хешировании (hash function).

Пример получения такой контрольной суммы с использованием SHA384:

echo -n «message» | openssl dgst -sha384 -hmac «client_write_MAC_key»

(stdin)= b7d9a7f344e90379bc16123754d17697b0c5cd86bb524fd11cda9654c245773eb7503457f59a2e748259539a563af259

Симметричное шифрование

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

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

Если этот ключ будет перехвачен злоумышленником — он получит возможность расшировать все данные, зашифрованные этим ключём.

Именно поэтому передача такого ключа должна осуществляться по уже зашированному соединению.

Преимущества

  • быстрое, низкое потребление ресурсов системы
  • простые операции
  • безопасно

Недостатки

  • один ключ для шифрования/дешифрования
  • передача ключа должна быть выполнена по уже защищённому соединению
  • нет возможности авторизации пользователей
Ассиметричное шифрование

Asymmetric encryption (также Public Key Cryptography — криптография по открытому ключу) использует пары ключей — публичный и приватный. Эти ключи связаны друг с другом таким образом, что данные, зашифрованные с помощью одного ключа (как правило публичного) могут быть расшифрованы другим (приватным).

Асссиметричное шифрование так же может применяться для авторизации отправителя: если Боб подписывает и шифрует сообщение, используя свой приватный ключ, то любой, у кого есть публичная часть ключа и кто смог расшифровать такое сообщение может быть уверен, что его зашифровал и отправил только Боб (при условии, что Боб не слил свой приватный ключ в Github…).

Преимущества

  • простая передача ключа
  • аутентификация пользователей
  • проверка целостности

Недостатки

  • медлененее, чем симметричное шифрование
  • потребляет больше ресурсов

Теперь можно перейти к рассмотрению непосредственно SSL/TLS соединения.

Обзор SSL/TLS соединения

Любое SSL-соединение использует набор протоколов, описанных в RFC 5246 (тут и ниже рассматривается TLS v 1.2 и этот RFC, как последняя актуальная версия на момент написания этого поста — март 2018).

В RFC 5246 они описаны в обратном порядке, но тут рассмотрим их начиная с Handshake Protocol, т.к. именно в нём описывается процесс установления сессии и создания ключей, которые далее используются в TLS Record Protocol.

Структура получается следующая:

  • The TLS Handshaking Protocols
    • Handshake Protocol
    • Change Cipher Spec Protocol
    • Alert Protocol
  • The TLS Record Protocol

Сейчас рассмотрим протоколы кратко, далее рассмотрим общий процесс рукопожатия (раздел SSL Handshake кратко), после чего все его шаги будут описаны детально (раздел SSL Handshake в деталях).

TLS Handshaking Protocols

Описан в разделе 7 RFC.

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

Опять-таки — в RFC они описаны в другом порядке, но тут для удобства понимания кратко рассмотрим их в порядке «важности» — Handshake Protocol, Change Cipher Spec Protocol и Alert Protocol.

Выполняется на Presentation Layer модели OSI:

Handshake Protocol

Описан в разделе 7.4 RFC 5246.

Ключевой протокол, описывающий процесс установления сессии и согласования параметров, которые будут использоваться во время сессии. Он включает в себя 9 основных «сообщений рукопожатия» (handshake messages), которые используются для создания сессии — их мы в деталях и рассмотрим далее (Процесс установления SSL сессии – базовый SSL Handshake).

Эти сообщения передаются на TLS Record layer, который передаёт далее, вниз по стеку протоколов OSI.

Change Cipher Spec Protocol

Описан в разделе 7.1.

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

Состоит из единственного сообщения, которое содержит 1 байт со значением 1, которое отправляется и клиентом и сервером на стадии рукопожатия.

Alert Protocol

Описан в разделе 7.2.

Этот протокол описывает Alert тип данных, в котором передаются сообщения для управления соединением. Алерты содержат два поля — уровень предупреждения и его описание.

Уровень fatal приводит к немедленному уничтожению соединения. В этому случае другие соединения в этой сессии (см. C: libssh – пример SSH-“клиента”) могут оставаться активными до их завершения, но идентификатор сессии (Session ID, будет рассмотрен ниже) должен быть удалён, предотвращая создание новых соединений в рамках этой сессиии.

The TLS Record Protocol

Описан в разделе 6.

TLS Record Protocol включает принимает сообщения для передачи от Application Layer модели OSI, разбивает их на блоки, при необходимости выполняет сжатие, добавляет Message authentication code (MAC), выполняет шифрование и передаёт результат вниз по стеку на TCP протокол.

Полученные «снизу» данные (т.е. пришедшие «из интернета») расшифровываются, выполняется проверка их целостности, распаковка, сборка целого сообщения из блоков и выполняется доставка вышележащим клиентам на Application уровне.

TLS Record Protocol выполняется над Transport Layer, который обеспечивает передачу блоков данных между узлами сети, и под Application уровнем, обеспечивая передачу данных приложениям:

Record Layer

На TLS Record Layer выполняется фрагментация (6.2.1), сжатие и распаковка (6.2.2) и защита целостности (6.2.3) передаваемых данных.

Процесс установления SSL сессии — SSL Handshake

Ключевой момент установления защищенного соединения — SSL Handshake, или «рукопожатие», в процессе которого осуществляется согласование используемой версии TLS, верификация узлов (аутентификация сервера и опционально клиента), алгоритмов шифрования, обмен ключами, сертификатами и собственно установдение и начало обмена уже зашифрованными данными.

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

Выше упоминалось про 9 сообщений при выполнении TLS Handshake — они предоставлены на изображении ниже:

SSL Handshake кратко

Прежде, чем углубиться в детали реализации TLS Handshake — рассмотрим процесс кратко.

Процесс рукопожатия можно разбить на три условных фазы — привествие (Hello), обмен сертификатами (Certificate Exchange) и обмен ключами (Key Exchange):

  1. Hello: рукопожатие начинается с того, что клиент, который хочет подключиться к серверу используя TLS, отправляет сообщение ClientHello. В нём содержится вся информация, необходимая для создания (или восстановления) TLS-сессии, например — наборы предпочитаемых методов шифрования (Cipher Suites), версия SSL/TLS и т.д. Сервер в свою очередь отвечает сообщением ServerHello, в котором содержится информация, основанная на запросе клиента, например выбранная сервером версия SSL/TLS, ID создаваемой сессии, выбранный метод шифрования.
  2. Certificate Exchange: после того, как контакт установлен — сервер должен доказать клиенту, что он именно тот, за кого он себя выдаёт — пройти аутентификацию, которая выполняется с помощью предоставления сервером SSL сертификата. В сертификате содержится информация о владельце, домене, на который выдан, публичный ключ, цифровая подпись, дата выдачи срок действия сертификата. Клиент выполняет проверку сертификата — либо он может доверять ему безоговорночно, либо может выполнить проверку через Certificate Authorities (CA), которым клиент доверяет. Сервер так же может запросить сертификат клиента для его аутентификации.
  3. Key Exchange: шифрование передаваемых по защищённому соединению данных выполняется с помощью симметричного шифрования, которое было согласовано во время Hello фазы. Симметричное шифрование использует один ключ для шифрования и дешифрования, в отличии от ассиметричного шифрования, в котором используется пара публичного/приватного ключей. Обеим сторонам — клиенту и серверу, необходимо создать ключ для симметричного шифрования («master key«), а процесс его создания выполняется с помощью ассиметричного шифрования и приватного/публичного ключа сервера плюс рандомные строки, созданные во время Hello фазы.

Далее клиент генерирует pre-master secret key, который будет использоваться для вычисления master key, шифрует его с помощью выбранного в Hello фазе алгоритма используя публичный ключ севера, который передаётся в его сертификате в фазе Certificate Exchange и отправляет его серверу.

Сервер дешифрует pre-master secret key, используя свой приватный ключ и вычисляет master key на своей стороне.

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

SSL Handshake в деталях
Hello, фаза согласования
ClientHello

Клиент отправляет ClientHello сообщение серверу, в котором указываются:

  • client_version: желаемая клиентом версия TLS (последняя из доступных — This SHOULD be the latest (highest valued) version supported by the client)
  • random: структура, содержащая:
  • session_id: ID сессии, если клиент пытается возобновить TLS сессию
  • cipher_suites: поддерживаемые CipherSuites (методы шифрования, см. Appendix A.5), с указанием методов, предпочитаемых клиентом.
  • compression_methods: список методов сжатия, поддерживаемых клиентом (см. RFC-3749 — Transport Layer Security Protocol Compression Methods)
  • extensions: (опционально) клиент может запросить расширенную функциональность от сервера, указав её в этом поле (см. Hello Extensions)

Сама структура ClientHello (см. Appendix-A.4.1):

   struct {
       ProtocolVersion client_version;
       Random random;
       SessionID session_id;
       CipherSuite cipher_suites<2..2^16-2>;
       CompressionMethod compression_methods<1..2^8-1>;
       select (extensions_present) {
           case false:
               struct {};
           case true:
               Extension extensions<0..2^16-1>;
       };
   } ClientHello;

ClientHello описывается в разделе 7.4.1.2.

Пример ClientHello в Wireshark для RTFM:

ServerHello

Сервер отвечает сообщением ServerHello, в котором указываются:

  • server_version: выбранная сервером версия TLS, основываясь на переданном значении client_version из ClientHello
  • random: аналогично random клиента — 4 байта времени и даты на сервере + 28 байта случайного числа. random клиента и random сервера далее будут использованы для генерации ключа шифрования
  • session_id: если поле ClientHello.session_id содержало ID сессии — сервер проверит свой кеш на предмет поиска этого ID. Если ID найден — дальнейшие шаги будут пропущены, и рукопожатие перейдёт сразу к стадии Finished.
  • cipher_suite: метод шифрования, выбранный сервером из списка, предложенного клиентом в его ClientHello.cipher_suite
  • compression_method: метод сжатия, выбранный из ClientHello.compression_methods. Если сессия восстанавливается (в кеше сервера найдён session_id) — использует метод из старой сессии
  • extensions: список расширений из списка, отправленного клиентом

Структура ServerHello:

      struct {
          ProtocolVersion server_version;
          Random random;
          SessionID session_id;
          CipherSuite cipher_suite;
          CompressionMethod compression_method;
          select (extensions_present) {
              case false:
                  struct {};
              case true:
                  Extension extensions<0..2^16-1>;
          };
      } ServerHello;

Описывается в разделе 7.4.1.3.

ServerHello в Wireshark:

Например, тут видно что в Cipher Suite содержится уже не целый список методов, а только один, выбранный сервером из предложенных клиентом, по которому будет далее и выполняться шифрование.

Certificate Exchange, обмен сертификатами
Certificate

Сервер отправляет сообщение Certificate, в котором в поле certificate_list передаётся список сертификатов (certificate chain), где первым идёт сертификат самого сервера, за ним сертификаты цепочки доверия (chain of trust) в порядке очереди. Корневые сертификаты не передаются, т.к. предполагается, что клиент уже ими располагает.

Например — в  Linux они располагаются в каталоге /etc/ssl/certs/:

ls -l /etc/ssl/certs | head -5

total 1384

lrwxrwxrwx 1 root root   64 Mar 12 12:12 00673b5b.0 -> ../../ca-certificates/extracted/cadir/thawte_Primary_Root_CA.pem

lrwxrwxrwx 1 root root   83 Mar 12 12:12 02265526.0 -> ../../ca-certificates/extracted/cadir/Entrust_Root_Certification_Authority_-_G2.pem

lrwxrwxrwx 1 root root   61 Mar 12 12:12 02756ea4.0 -> ../../ca-certificates/extracted/cadir/Certplus_Root_CA_G1.pem

lrwxrwxrwx 1 root root   74 Mar 12 12:12 03179a64.0 -> ../../ca-certificates/extracted/cadir/Staat_der_Nederlanden_EV_Root_CA.pem

У браузеров политика валидации сертификатов и поиска корневых сертификатов отличается. Для Chrome/Crhomium — см тут>>> и тут>>>.

Сообщение Certificate описывается в разделе 7.4.2.

Certificate в результатах Wireshark:

Тут хорошо просматривается цепочка:

  1. сертификат сервера RTFM: Certificate: (id-at-commonName=rtfm.co.ua)
  2. который пописан Certificate: (id-at-commonName=Let’s Encrypt Authority X3,id-at-organizationName=Let’s Encrypt,id-at-countryName=US)
  3. а сертификат Let’s Encrypt Authority выдан и подписан (id-at-commonName=DST Root CA X3,id-at-organizationName=Digital Signature Trust Co.)

Корневой сертификат DST Root CA X3 расположен в системе, в /etc/ssl/certs:

ls -l /etc/ssl/certs/ | grep DST_Root

lrwxrwxrwx 1 root root   56 Mar 12 12:12 12d55845.0 -> ../../ca-certificates/extracted/cadir/DST_Root_CA_X3.pem

lrwxrwxrwx 1 root root   56 Mar 12 12:12 2e5ac55d.0 -> ../../ca-certificates/extracted/cadir/DST_Root_CA_X3.pem

lrwxrwxrwx 1 root root   56 Mar 12 12:12 DST_Root_CA_X3.pem -> ../../ca-certificates/extracted/cadir/DST_Root_CA_X3.pem

ServerKeyExchange

Cервер отправляет сообщение ServerKeyExchange, опционально, в зависимости от используемого алгоритма шифрования для передачи ключа, если  данных в сообщении Certificate недостаточно для создания pre-master secret ключа (т.е. в случае использования DHE_DSS, DHE_RSA, DH_anon, другие алогритмы должны явно указать на необходимость передачи ServerKeyExchange).

В ServerKeyExchange может передаваться публичный ключ Diffie-Hellman (DF), с помощью которого клиент может завершить обмен pre-master ключём

Описывается в 7.4.3.

Публичный ключ DF в сообщенииServerKeyExchangeв результатах Wireshark:

ServerHelloDone

Сервер отправляет сообщение ServerHelloDone, которое указывает на то, что сервер закончил передачу своего ServerHello и ждёт ответа клиента.
После получения ServerHelloDone клиент выполняет проверку цифровой подписи сертификата сервера (Digital signatures in SSL and TLS), проверяет цепочку сертификатов (How certificate chains work), дату выдачи и срок действия сертификата, и статус сертификата — не был ли он отозван Central Authority, который выдал этот сертификат (Working with revoked certificates).

ServerHelloDone в Wireshark:

ClientKeyExchange

Клиент отправляет сообщение ClientKeyExchange, в котором вырабатывается pre-master secret key.

В случае использования RSA — pre-master ключ отправляется серверу зашифрованным с помощью публичного ключа сервера. В случае использования алгоритма Diffie-Hellman — передаются DF параметры со стороны клиента, позволяющие согласовать pre-master ключ.

В случае использования EDF (ephemeral Diffie-Hellman) — клиент передаёт публичный ключ. В случае использования DF (static Diffie-Hellman) — поле ClientDiffieHellmanPublic передаётся пустым.

Структура ClientKeyExchange:

      struct {
          select (KeyExchangeAlgorithm) {
              case rsa:
                  EncryptedPreMasterSecret;
              case dhe_dss:
              case dhe_rsa:
              case dh_dss:
              case dh_rsa:
              case dh_anon:
                  ClientDiffieHellmanPublic;
          } exchange_keys;
      } ClientKeyExchange;

Описывается в разделе 7.4.7.

Wireshark и публичный ключ клиента для DF:

На этом фаза Key Exchange завершена, и начинается процесс «активации» защищённого соединения.

ChangeCipherSpec и Finish

Обе стороны — и клиент, и сервер, вычисляют общий master key длиной 48 байт, используя строки из ClientRandom и ServerRandom + pre_master_secret, используя Pseudorandom Function (PRF):

master_secret = PRF(pre_master_secret, "master secret", ClientHello.random + ServerHello.random) [0..47];

Далее этот master_key используется для генерации набора ключей (см. 6.3. Key Calculation):

  • client_write_MAC_key – аутентификация и проверка целосности данных клиентом
  • server_write_MAC_key – аутентификация и проверка целосности данных сервером
  • client_write_key – шифрование сообщения клиентом, используя симметричный ключ
  • server_write_key – шифрование сообщения сервером, используя симметричный ключ
  • client_write_IV – Initialization Vector используемый некоторыми AEAD алгоритмами
  • server_write_IV –Initialization Vector используемый некоторыми AEAD алгоритмами

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

Клиент отправляет серверу сообщение ChangeCipherSpec, указывая серверу на то, что все данные, начиная с этого сообщения, будут зашифрованы.

После отправки ChangeCipherSpec — клиент отправляет сообщение Finished, в которой в поле finished_label содержится строка «client finished», которую сервер должен расшифровать и проверить целостность самого сообщения.

После успешной проверки Finished сообщения от клиента — сервер отправляет своё сообщение ChangeCipherSpec, а затем своё сообщение Finished, в котором в поле finished_label содержится строка «server finished», которую клиент должен расшифровать и проверить целостность самого сообщения.

В результатах Wireshark — ChangeCipherSpec и зашифрованная строка:

С этого момента все остальные данные (Application data) передаются в зашифрованном виде.

UPD

Интересный сайт, показывает пошагово процесс TLS-соединеия: https://tls.ulfheim.net/

Ссылки по теме

Transport Layer Security

The Transport Layer Security (TLS) Protocol Version 1.2

Secure Sockets Layer (SSL) and Transport Layer Security (TLS) concepts

SSL Introduction with Sample Transaction and Packet Exchange

TLS/SSL Explained – TLS/SSL terminology and basics, Part 3

TLS/SSL Explained – Establishing a TLS Connection, Part 5

How does HTTPS actually work?

Symmetric vs. Asymmetric Encryption – What are differences?

The First Few Milliseconds of an HTTPS Connection (2009 год)

Выбор ciphersuites для TLS и уязвимость Logjam. Опыт Яндекса

Обзор SSL-сертификатов: типы, выбор, приемущества.

Цифровые SSL сертификаты. Разновидности, как выбрать?

 

SSL/TLS протокол что это такое | Параметры безопасности протокола TLS

Протокол SSL/TLS обеспечивает защиту интернет-соединений по HTTP (для интернет-страниц), FTP (файлового менеджера), IMAP, POP3 и SMTP (почтовых протоколов).

SSL (англ. Secure Sockets Layer) — криптографический протокол, устанавливающий связь между сервером и клиентом по безопасному каналу. SSL-сертификат позволяет использовать соединение по HTTPS. Подробнее о преимуществах применения SSL читайте в статье: В чём фишка HTTPS, или зачем мне SSL-сертификат?

В 2014 году в работе SSL обнаружили уязвимость, кроме того он стал устаревать, поэтому на основе SSL 3.0 создали стандарт TLS.

TLS (англ. Transport Layer Security) — криптографический протокол, который обеспечивает защищённую передачу данных от сервера к клиенту. В основе работы TLS симметричное шифрование для конфиденциальности, асимметричная криптография для аутентификации, коды аутентичности для сохранения целостности передаваемой информации. Он учитывает ошибки своего предшественника и продолжает развитие.

По сути различия в принципах работы SSL и TLS минимальны, поэтому когда говорят об SSL, подразумевается TLS.

Протокол безопасности TLS. Принцип работы

Процесс работы TLS можно разбить на несколько этапов:

  • TLS Handshake
  • TLS False Start
  • TLS Chain of trust

TLS Handshake — согласует параметры соединения между клиентом и сервером (способ шифрования, версию протокола), а также проверяет сертификаты. Данная процедура использует большое количество вычислительных ресурсов, поэтому, чтобы каждый раз не устанавливать новое соединение и не проверять сертификаты повторно, была разработана процедура TLS False Start.

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

TLS Chain of trust — обязательная процедура TLS-соединения. Она обеспечивает аутентификацию между клиентом и сервером. Она строится на «цепочке доверия», которая основана на сертификатах подлинности, выдаваемых Сертификационными центрами. Центр сертификации проверяет подлинность сертификата и, если он скомпрометирован, данные отзываются. Благодаря данной процедуре и происходит проверка подлинности передаваемых данных.

Таким образом, при передаче данных сначала вызывается процедура TLS Handshake или TLS False Start, которая согласовывает параметры, а затем TLS Chain of trust, которая обеспечивает аутентификацию (проверку авторства передаваемой информации).

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

Параметры безопасности протокола TLS

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

Установка SSL/TLS

В компании REG.RU вы можете приобрести SSL-сертификат, который работает по TLS 1.2.

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

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

Онлайн-сервис для проверки SSL/TLS

Проверить, какой протокол поддерживает ваш сайт с установленным SSL-сертификатом, возможно с помощью сервиса SSL Server Test. Для этого:


  1. 1.
    В браузере перейдите на страницу SSL Server Test.



  2. 2.
    В поле «Hostname» введите домен и нажмите Submit:





  3. 3.
    Дождитесь окончания проверки. В блоке «Configuration» вы увидите протоколы, которые поддерживает ваш сайт:




Помогла ли вам статья?

6
раз уже
помогла

Сертификаты TLS/SSL: что это такое

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

Мы решили ответить на основные вопросы об SSL и простыми словами рассказать о них именно тем людям, которые принимают решение об установке сертификата на сайт.

Зачем нужен этот сертификат

В последнее время остается все меньше сайтов, у которых нет сертификата SSL. Но когда возникает вопрос: а зачем он нужен, первый ответ – ну Google же требует. Ответ на самом деле формальный. На деле же речь идет об очень важных вещах – безопасности и защите информации. Сегодня пользователи оставляют на сайтах не только разнообразные персональные данные, но и более «опасную» информацию, например, номера счетов или реквизиты банковских карт. Задача владельца сайта – сделать так, чтобы эти данные не попали в руки злоумышленников. Именно поэтому Google отдает предпочтение тем сайтам, которые защищают персональную информацию от «угона».

Защищенное соединение и сертификат SSL

Почему сертификат защищает от этой опасности? Как все это работает?

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

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

Именно поэтому важно получить подтверждение, что мы отправляем данные именно туда, куда ожидаем. Это и вопрос доверия к сайту, и фактической безопасности его пользователей, и поисковые системы придают большое значение наличию такого сертификата. Более того, Google Ads (рекламная система Google) может ограничивать показы рекламы сайта, его не имеющего.

Как происходит подтверждение сайта с помощью сертификатов

При соединении браузер проверяет, соответствуют ли данные в сертификате тому узлу, куда отправляются данные.

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

И замочек и информацию о компании для сертификата, где она указана:

Если же что-то пошло не так, то вы увидите такое предупреждение:

​​

При проверке:

  • если компьютер, на котором установлен браузер, не знает такого центра сертификации, будет выдано предупреждение;


  • если такой центр этот сайт не сертифицировал, также будет предупреждение;


  • если мы подключились не к тому сайту, для которого выдавался сертификат, тоже будет предупреждение;


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

Шифрование данных и https

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

Какие типы сертификатов бывают и как выбрать нужный?

Domain Validation (DV)

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

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

Organization Validation (OV)

Такой сертификат подтверждает организацию, владеющую сайтом. Выпускается такой сертификат в течение недели, +/- 3 дня. Важно: при таком способе сертификации для домена обязательно должны быть указаны данные о организации (отображаться в whois). Если же вы являетесь физлицом, то такой сертификат для вас получить попросту невозможно.

Кому подойдут такие сертификаты — сказать сложно. Дело в том, что для конечного пользователя (посетителя сайта) разницы между OV и DV нет. Неплохо иметь такой тип сертификата в случае, если с сайта осуществляются платежи, а бюджета на EV нет. Но в подобной ситуации обычно используются интегрируемые решения (например, https://www.robokassa.ru), которые переводят посетителя на сайт сервиса (там обычно EV). Сертификаты OV, например, используются Яндексом и Google.

Extended Validation (EV)

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

Если вы делаете что-то глобальное, вам нужен такой сертификат: например, если вы банк, если вы платежная система, если у вас собственный сервис приема платежей (данные карты вводятся на вашем сайте) и так далее. Такие сертификаты дороги. Даже у Сбербанка этот сертификат стоит только для https://online.sberbank.ru/, а для https://www.sberbank.ru/ используется простой OV.

Что еще может понадобиться

Кроме типа подтверждения, сертификат может иметь ряд опций. Обычно они пишутся в названии карточки товара при покупке сертификата, например, Wildcard-сертификат, который защищает сразу все поддомены сайта, SAN-сертификат на несколько доменов, которые находятся на одном сервере, и так далее. Хотелось бы обратить внимание на очень важную для кириллических сайтов опцию – IDN (Internationalized Domain Names). Таким сайтам она необходима.

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

А вот список сертификационных центров, чьи сертификаты наиболее распространены: Thawte, Comodo, GlobalSign, GeoTrust, DigiCert, Symantec.

О самоподписанных сертификатах

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

Это примерно как позвонить в дверь и сказать «это я» – если непонятно кто это, то это «я» ни о чем не скажет. Браузер предупредит, что он не знает организацию, выдавшую сертификат, однако если пользователь согласится с тем, что доверяет этому сайту, подключение будет работать.

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

Как получить этот самый сертификат

Мы рекомендуем установку сертификата всем компаниям, с которыми работаем, советуем задуматься над этим и читателям. Как это сделать проще всего?

Многие хостинги имеют в себе интегрированные услуги по установке SSL-сертификатов, некоторые даже предоставляют сертификаты бесплатно при заказе хостинга. Такие решения наиболее удобны, так как процесс установки сертификата для этого хостинга уже поставлен на поток. Если же сайт расположен на собственном сервере, или на виртуальном частном сервере (VPS), или на виртуальном выделенном сервере (VDS), то установкой сертификата должен заниматься системный администратор. Также при переходе на https не забудьте поставить в известность всех, кто имеет отношение к привлечению трафика на ваш сайт. SEO-специалисту важно будет добавить сайт с новым протоколом в Вебмастер и сделать перенаправления с небезопасного подключения на безопасное, а специалистам по баннерной и контекстной рекламе может понадобиться поменять адреса посадочных страниц. 

Обзор протокола TLS 1.3 и его возможностей

Со времени последнего обновления протокола шифрования прошло более восьми лет, но окончательная версия TLS 1.3 была опубликована по состоянию на август 2018 года . 👏 Интересной частью для сообщества WordPress здесь является то, что TLS 1.3 включает в себя множество улучшений безопасности и производительности. С обновлением протокола HTTP/2 в конце 2015 года и теперь TLS 1.3 в 2018 году зашифрованные соединения стали более безопасными и быстрыми, чем когда-либо. Подробнее об изменениях в TLS 1.3 и о том, как это может помочь вам как владельцу сайта WordPress, читайте ниже.

Что такое TLS?

TLS означает безопасность транспортного уровня и является преемником SSL (Secure Sockets Layer). TLS обеспечивает безопасную связь между веб-браузерами и серверами. Само соединение является безопасным, потому что симметричная криптография используется для шифрования передаваемых данных. Ключи уникально генерируются для каждого соединения и основаны на общем секрете, согласованном в начале сеанса, также известном как квитирование TLS.

Многие IP-протоколы, такие как HTTPS, SMTP, POP3, FTP поддерживают TLS для шифрования данных.

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

Различия между SSL и TLS / Блог компании Varonis Systems / Хабр

Хроническая эпидемия расстройства восприятия лиц у жителей Метрополиса, из-за которой никто не замечает, что Кларк Кент и чудаковатый летающий пришелец, похожий на него как две капли воды, — это в действительности одно и то же лицо, распространяется и на технический сектор, где мы постоянно спорим о том, насколько строго нужно различать протоколы SSL и TLS.


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

Более 20 лет назад компания Netscape разработала версию 1.0 протокола SSL (Secure Sockets Layer), чтобы в браузерах можно было просматривать страницы Geocities и обмениваться ASCII-графикой по мотивам «Звездного пути», не беспокоясь о безопасности.

Версии SSL 1.0–3.0, как и все первые попытки создать эффективный алгоритм шифрования, подверглись критике из-за наличия серьезных проблем с безопасностью, в связи с чем потребовался выпуск нескольких доработанных версий с улучшенной архитектурой системы безопасности.

В 1999 году была выпущена версия 1.0 протокола TLS (Transport Layer Security): tools.ietf.org/html/rfc2246. Название было изменено для того, чтобы подчеркнуть открытый характер стандарта, благодаря чему кто угодно мог использовать его в своих проектах, и тем самым отделить его от фирменного продукта компании Netscape (которая на тот момент еще продавала программное обеспечение для веб-серверов Netscape Enterprise Server, использующее SSL для шифрования данных из внешних каналов). Кроме того, протокол TLS разрабатывался как протокол, независимый от приложений, тогда как SSL изначально планировалось использовать только для подключений HTTP.

В лингвистическом противостоянии («Как называется протокол, при использовании которого появляется зеленый замочек?») победил термин SSL. Если вам нужно доказательство, посмотрите сравнение «SSL и TLS» на сайте Google Trends.

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

При обсуждении _протокола_ как такового и версий SSL/TLS, которые должны быть включены, более правильным будет термин TLS.

Однако на практике специалисту по обеспечению безопасности и администрированию необходимо знать следующее.

• Существуют различные версии SSL/TLS.

• При несовпадении протоколов более старые системы не могут обмениваться данными с более новыми. Если вы когда-либо задумывались над тем, почему браузер Internet Explorer при установке Windows 95 на новом компьютере не открывает сайты HTTPS, то теперь вы знаете ответ.

• Необходимо создать корпоративную политику, позволяющую включать только более поздние версии TLS (номер текущей версии — 1.2).

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

В общем и целом вопрос «В чем заключается разница между SSL и TLS?» очень интересен, если обсуждать только практические моменты и доказывать, почему мелкие различия между протоколами безопасности так важны.

TLS 1.3 признан стандартом / Блог компании ИТ-ГРАД / Хабр

Ранее мы писали, что Инженерный совет Интернета (IETF) одобрил новую версию TLS — 1.3. На прошлой неделе протокол был признан стандартом. Сегодня — поговорим о его возможностях.

/ фото Charles Dyer CC

Особенности TLS 1.3

Над обновлением протокола начали работать еще в 2014 году. Неофициально работа над TLS 1.3 закончилась в марте этого года, однако инженерам понадобилось еще несколько месяцев на проведение дополнительных проверок.

Создатели утверждают, что итоговый вариант TLS 1.3 — более безопасный и производительный: в его алгоритмах шифрования закрыты все известные (на сегодняшний день) уязвимости TLS 1.2, а процесс «рукопожатия» проходит в два раза быстрее, чем у предшественника. Разработчики также добавили forward secrecy и новые фичи вроде 0-RTT.

В TLS 1.3 внесли самое большое количество значимых изменений за всю историю протокола. По этой причине некоторые даже предлагали назвать его TLS 2.0.

Теперь, когда новая версия протокола TLS 1.3 (RFC 8446) официально одобрена, осталось реализовать его для всех подключений по сети.

Сложности с реализацией

TLS обладает своеобразной обратной совместимостью. При установлении соединения между клиентом и сервером происходит обмен поддерживаемыми версиями протокола и выбирается та, с которой могут работать обе стороны. Однако эта возможность используется не везде. С появлением TLS 1.3 более 3% серверов с поддержкой TLS 1.2 просто разрывали соединение вместо того, чтобы отправлять клиенту номер поддерживаемой версии.

Похожая проблема возникла с промежуточными узлами (middlebox). Из-за того, что TLS особо не менялся, штуки вроде файрволов, NAT и балансировщиков нагрузки отказались работать с новой версией протокола.

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

/ фото Christopher Sessums CC

Получается, что предыдущий протокол устарел, но внедрить новый по умолчанию не получится. Больше по теме можно почитать, например, в прошлогоднем исследовании от IEEE (PDF).

Решение проблемы нашел Дэвид Бенджамин (David Benjamin), работающий над Chromium. Он предложил замаскировать первое сообщение от клиента, поддерживающего TLS 1.3, под сообщение TLS 1.2. И это сработало: упомянутые 3% серверов перестали разрывать соединение. Для узлов-посредников Кайл Некритц (Kyle Nekritz) из Facebook предложил использовать тот же подход. Это позволило сократить число сбоев на 6,5% в Chrome и на 2% в Firefox.

Чтобы проверить, совместимы ли middlebox’ы с новой версией протокола, можно воспользоваться тестом, разработанным в Cloudflare.

Как упростить внедрение

Как утверждает Эрик Рескорла (Eric Rescorla), один из разработчиков спецификаций для TLS и HTTPS, в целом внедрить TLS 1.3 не так уже и сложно. Инженерный совет старался сделать этот процесс максимально простым. TLS 1.3 использует те же ключи и сертификаты, что и TLS 1.2. Это позволяет клиенту и серверу автоматически устанавливать соединение по TLS 1.3, если они оба поддерживают новую версию протокола.

Кроме того, есть ряд библиотек, которые помогут развернуть протокол быстрее. К примеру, в начале прошлой недели Facebook передали свою библиотеку TLS 1.3 Fizz в open source. Fizz уменьшает латентность при трансляции данных, а также нагрузку на CPU.

Разработчики подготовили руководство, как начать пользоваться Fizz на Ubuntu 16.04 LTS. Оно находится в официальном репозитории на GitHub (там также есть руководство для MacOS).

Сперва нужно установить необходимые зависимости folly и libsodium:

sudo apt-get install \
	g++ \
	cmake \
	libboost-all-dev \
	libevent-dev \
	libdouble-conversion-dev \
	libgoogle-glog-dev \
	libgflags-dev \
	libiberty-dev \
	liblz4-dev \
	liblzma-dev \
	libsnappy-dev \
	make \
	zlib1g-dev \
	binutils-dev \
	libjemalloc-dev \
	libssl-dev \
	pkg-config \
	libsodium-dev

Далее нужно собрать и установить folly:

git clone https://github.com/facebook/folly
mkdir folly/build_ && cd folly/build_
cmake configure ..
make -j $(nproc)
sudo make install

Затем можно переходить к установке Fizz:

cd ../..
git clone https://github.com/facebookincubator/fizz
mkdir fizz/build_ && cd fizz/build_
cmake configure ../fizz
make -j $(nproc)
sudo make install

Помимо Fizz в сети есть и другие библиотеки, например, wolfSSL, GnuTLS или rustls.

Будущее протокола

Чтобы окончательно разрешить проблему с «окостенением» протокола, Дэвид Бенджамин предложил помимо официальной версии стандарта использовать ряд его вариаций, которые будут выпускаться каждые шесть недель (вместе с релизами новых версий Chrome). Таким образом, серверы и промежуточные узлы будут обязаны соблюдать все правила установления соединения, иначе большая часть клиентов не сможет подключаться к сервисам.

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

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

P.S. Другие материалы из нашего блога о корпоративном IaaS:

Чем мы занимаемся в ИТ-ГРАД — основные направления:

Виртуальная инфраструктура (IaaS) | PCI DSS хостинг | Облако ФЗ-152

Защита сайта по протоколу 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 сертификат


Чтобы сервер был аутентифицирован, ему нужно иметь сертификат и соответствующий ему закрытый ключ.

Администратор сервера может получить сертификат при помощи выполнения данных шагов:


  1. Воспользовавшись командой openssl req, сформировать заявку на сертификат и соответствующий закрытый ключ;


  2. Отправить сформированную заявку в удостоверяющий центр.

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

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

В том случае, если сервер имеет несколько хостов, аутентификация успешно завершается только тогда, когда предъявленный сервером сертификат отвечает именно тому имени сервера, которое клиент указывал для установления соединения.

Для защиты сайта по протоколу TLS используются SSL-сертификаты. Если вы хотите приобрести сертификат для создания TLS соединения, вы всегда можете обратиться для этого к компании ЛидерТелеком.

Что такое безопасность транспортного уровня? | Протокол TLS

Поддержка
|
Продажи:
+1 650 319 8930
+1 650 319 8930
|
Русский ▶ ▼

  • английский
  • Английский (Великобритания)
  • Английский (Канада)
  • Английский (Австралия)
  • Английский (Индия)
  • Deutsch
  • Español (Испания)
  • Español (Латиноамерика)
  • Français
  • Italiano
  • 日本語
  • 한국어
  • Português
  • 繁體 中文
  • 简体 中文
  • Продукты
  • Решения
  • Ресурсы
  • Разработчики

  • Для предприятия

  • Ценообразование

  • Авторизоваться

  • Подписаться

  • Под атакой?
  • Решения
  • Продукты
  • Документация
  • Ресурсы
  • Партнеры

  • Для предприятия

  • Ценообразование

  • Авторизоваться

  • Подписаться

  • Под атакой?

ДЛЯ ИНФРАСТРУКТУРЫ

Расширенная безопасность

.

TLS Security 1: что такое SSL / TLS

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

SSL и TLS обычно используются веб-браузерами для защиты соединений между веб-приложениями и веб-серверами. Многие другие протоколы на основе TCP также используют TLS / SSL, включая электронную почту (SMTP / POP3), обмен мгновенными сообщениями (XMPP), FTP, VoIP, VPN и другие. Обычно, когда служба использует безопасное соединение, к имени протокола добавляется буква S, например HTTP S , SMTP S , FTP S , SIP S . В большинстве случаев реализации SSL / TLS основаны на библиотеке OpenSSL.

SSL и TLS — это фреймворки, которые используют множество различных криптографических алгоритмов, например, RSA и различные алгоритмы Диффи – Хеллмана. Стороны договариваются о том, какой алгоритм использовать при первоначальном общении. Последняя версия TLS (TLS 1.3) указана в документе IETF (Internet Engineering Task Force) RFC 8446, а последняя версия SSL (SSL 3.0) указана в документе IETF RFC 6101.

Конфиденциальность и целостность

Протоколы

SSL / TLS позволяют зашифровать соединение между двумя средами (клиент-сервер).Шифрование позволяет убедиться, что никакая третья сторона не сможет прочитать данные или вмешаться в них. Незашифрованная связь может раскрыть конфиденциальные данные, такие как имена пользователей, пароли, номера кредитных карт и многое другое. Если мы используем незашифрованное соединение и третья сторона перехватывает наше соединение с сервером, они могут видеть всю информацию, которой обмениваются, в виде простого текста. Например, если мы обращаемся к панели администрирования веб-сайта без SSL, а злоумышленник перехватывает трафик локальной сети, он видит следующую информацию.

Файл cookie, который мы используем для аутентификации на нашем веб-сайте, отправляется в виде обычного текста, и любой, кто перехватывает соединение, может его увидеть. Злоумышленник может использовать эту информацию для входа в панель администрирования нашего сайта. С этого момента возможности злоумышленника резко расширяются. Однако, если мы получаем доступ к нашему веб-сайту с помощью SSL / TLS, злоумышленник, перехватывающий трафик, видит совсем другое.

В этом случае информация бесполезна для злоумышленника.

Идентификатор

Протоколы

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

Когда устанавливается безопасное соединение, сервер отправляет клиенту свой сертификат SSL / TSL. Затем сертификат проверяется клиентом с помощью доверенного центра сертификации, подтверждая личность сервера.Такой сертификат нельзя подделать, поэтому клиент может быть на сто процентов уверен, что общается с нужным сервером.

Perfect Forward Secrecy

Идеальная прямая секретность (PFS) — это механизм, который используется для защиты клиента в случае компрометации закрытого ключа сервера. Благодаря PFS злоумышленник не может расшифровать предыдущие TLS-сообщения. Чтобы обеспечить идеальную прямую секретность, мы используем новые ключи для каждой сессии. Эти ключи действительны только до тех пор, пока сеанс активен.

Часто задаваемые вопросы

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

Узнайте, как работает TLS.

SSL расшифровывается как Secure Sockets Layer.Это предшественник TLS. Все версии SSL небезопасны. Ни вы, ни какие-либо приложения никогда не должны использовать SSL. Он упоминается только из-за его исторического значения.

Прочтите об истории SSL и TLS.

Если вы общаетесь без TLS, кто-то может легко выполнить атаку типа «человек посередине» и перехватить ваше общение. Они могут, например, узнать ваши пароли или украсть ваш файл cookie сеанса, чтобы выдать себя за вас.Вот почему многие веб-сайты и веб-приложения позволяют общаться только с использованием TLS (HTTPS).

Подробнее об атаках типа «злоумышленник посередине».

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

АВТОР

Агатоклис Продрому
Администратор / разработчик веб-систем

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

Что такое рукопожатие SSL / TLS? Как работает TLS?

  • SSL-бренды Только самые надежные
  • SSL-продукты Какой тип вам нужен?
    • DV SSL-сертификатов
      • Защитите свой сайт за 5 минут
      • Наша самая низкая цена: 5,45 $ / год
    • Wildcard SSL-сертификаты
      • Безопасное неограниченное количество поддоменов
      • Наша самая низкая цена: 52 $.95 / год

      • SSL-сертификаты

    • EV
      • Показать название вашей компании в адресной строке
      • Наша самая низкая цена: 69,85 $ / год

.

В чем разница?

SSL по сравнению с TLS

TLS (Transport Layer Security) и SSL (Secure Sockets Layer) — это протоколы, которые обеспечивают шифрование данных и аутентификацию между приложениями и серверами в сценариях, когда эти данные отправляются через небезопасную сеть, например при проверке вашей электронной почты (как работает Secure Socket Слой работает?). Термины SSL и TLS часто используются взаимозаменяемо или в сочетании друг с другом (TLS / SSL), но на самом деле один из них является предшественником другого — SSL 3.0 послужил основой для TLS 1.0, который, как результат, иногда называют SSL 3.1. С учетом сказанного, есть ли на самом деле практическая разница между ними?

См. Также нашу инфографику, в которой резюмируются эти различия.

Что безопаснее — SSL, TLS или TLS v1.x?

Раньше считалось, что TLS v1.0 ненамного безопаснее, чем SSL v3.0, его предшественник. Однако SSL v3.0 очень старый, и такие атаки, как уязвимость POODLE, показали, что SSL v3.0 теперь полностью небезопасен (особенно для веб-сайтов, использующих его). Еще до того, как POODLE был выпущен, правительство США уже постановило, что SSL v3 не будет использоваться для конфиденциальной правительственной связи или для связи, совместимой с HIPAA. Если этого было недостаточно… POODLE, конечно, был. Фактически, в результате POODLE SSL v3 был отключен на веб-сайтах по всему миру, а также для многих других служб.

SSL v3.0 фактически «мертв» как полезный протокол безопасности. Места, которые все еще позволяют использовать его для веб-хостинга, подвергают свои «безопасные веб-сайты» чрезвычайно высокому риску.Организации, которые позволяют использовать SSL v3 для других протоколов (например, IMAP), должны принять меры для удаления этой поддержки в ближайшее время обслуживания обновления программного обеспечения.

Последующие версии TLS — v1.1, v1.2 и v1.3 — значительно более безопасны и исправляют многие уязвимости, присутствующие в SSL v3.0 и TLS v1.0. Например, атака BEAST, которая может полностью взломать веб-сайты, использующие старые протоколы SSL v3.0 и TLS v1.0. Более новые версии TLS при правильной настройке предотвращают BEAST, другие векторы атак и предоставляют множество более надежных шифров и методов шифрования.

На момент написания этой статьи (май 2018 г.) 11% веб-сайтов все еще поддерживают SSL v3.0. Однако подавляющее большинство 92% уже поддерживают TLS v1.2 +. Проверьте последнюю статистику на SSLLabs.

Разумеется, тенденция состоит в том, чтобы отказаться от старых протоколов в пользу новых. Например, использование TLS 1.0 веб-сайтами, которые принимают кредитные карты (и услуги, используемые правительством США), должно быть прекращено до 30 июня 2018 г. Вместо этого они должны использовать TLS 1.1 с TLS 1.2+ , настоятельно рекомендуется ).Еще в 2014 году NIST (Национальный институт стандартов и технологий) пересмотрел свои рекомендации и рекомендует использовать только TLS 1.1+ для правительственной связи. NIST указывает, что TLS v1.0 подходит для негосударственных коммуникаций … даже в его последних черновых обновлениях от 2018 года. По возможности всем следует использовать TLS 1.2 и 1.3. Однако во многих организациях все еще используются старые компьютеры (старше 5 лет), поэтому полное отключение поддержки TLS 1.0 и 1.1 может вызвать серьезные сбои.В результате мы рассматриваем переход к TLS 1.2 как более постепенный… где лидируют сайты и системы, которым это необходимо (для PCI и правительственной работы), а за ними следуют те, пользователи которых, вероятно, будут иметь более современные вычислительные системы. Вероятно, в ближайшие несколько лет поддержка TLS 1.0 в Интернете будет неуклонно снижаться. Однако, как мы видим с SSL 3.0, он не исчезнет в ближайшее время.

Но подождите: разве TLS и SSL не разные механизмы шифрования?

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

По правде говоря, это обозначение неправильное обозначение . Вы фактически не выбираете , какой метод использовать (SSL v3 или TLS v1.x), когда делаете этот выбор. Вы просто выбираете одну из опций, которые определяют , как будет инициировать безопасное соединение .

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

Если выбор SSL против TLS не — SSLv3 против TLS v1.0 +, что это такое?

Существует два различных способа, которыми программа может инициировать безопасное соединение с сервером:

  1. По портам (также известное как явное) : Подключение к определенному порту означает, что следует использовать безопасное соединение. Например, порт 443 для https (безопасный Интернет), 993 для безопасного IMAP, 995 для безопасного POP и т. Д. Эти порты настроены на сервере, готовым сначала согласовывать безопасное соединение, а затем делать все, что вы хотите, .
  2. По протоколу (также известное как неявное) : эти соединения сначала начинаются с небезопасного «приветствия» серверу и только затем переключаются на защищенную связь после успешного установления связи между клиентом и сервером. Если это рукопожатие не удается по какой-либо причине, соединение разрывается. Хорошим примером этого является команда «STARTTLS», используемая в соединениях исходящей электронной почты (SMTP).

Метод « по порту » обычно упоминается как « SSL » или « явный », а метод « по протоколу » обычно упоминается как « TLS » или « неявный ». »Во многих областях конфигурации программы.

Иногда у вас есть только возможность указать порт и установить безопасное соединение или нет, а сама программа угадывает , исходя из этого, какой метод следует использовать… многие старые почтовые программы, такие как Outlook и Mac Mail, сделали это. В таких случаях вам необходимо знать, будет ли программа пытаться установить явное или неявное соединение, чтобы инициировать безопасность, и соответствующим образом выбрать ваш порт (иначе соединение может завершиться ошибкой).

Для просмотра : В программах электронной почты и других системах, где вы можете выбрать SSL или TLS и выбрать порт, на котором будет установлено соединение:

  1. SSL означает явное соединение «по портам» с портом, который ожидает начала сеанса с согласованием безопасности.
  2. TLS означает соединение «по протоколу», при котором программа сначала подключается «небезопасно» и использует специальные команды для включения шифрования (неявно).
  3. Использование любого из них может привести к соединению, зашифрованному с помощью либо SSL v3, либо TLS v1.0 +, в зависимости от того, что установлено на сервере и что поддерживается вашей программой.
  4. Оба метода подключения (неявный и явный) приводят к одинаково безопасному (или небезопасному) обмену данными .

Боковая панель : Непонятно, почему метод «По протоколу» упоминается как «TLS», поскольку он может привести к фактическому использованию TLS или SSL.Скорее всего, потому, что разработчики протокола SMTP решили назвать свою команду переключения на SSL / TLS в протоколе SMTP на «STARTTLS» (используя «TLS» в имени, поскольку это имя нового протокола). Затем почтовые программы начали указывать «TLS» рядом с этим и «SSL» рядом со старой опцией «По портам», которая была первой. Как только они начали маркировать вещи таким образом, это расширилось до общего использования в конфигурации других протоколов (таких как POP и IMAP) для «согласованности». Я не уверен, что это настоящая причина, но, исходя из моего опыта работы со всеми версиями почтовых программ и серверов за последние 15 лет, это кажется очень правдоподобным.

Оба метода обеспечивают шифрование ваших данных при их передаче через Интернет. Они также позволяют вам быть уверенными в том, что сервер, с которым вы общаетесь, является сервером, с которым вы собираетесь связаться, а не каким-то «посредником-перехватчиком». Это возможно, потому что серверы, поддерживающие SSL и TLS, должны иметь сертификаты, выданные им доверенной третьей стороной, например Comodo. Эти сертификаты подтверждают, что доменное имя, для которого они выдаются, действительно принадлежит серверу (все о сертификатах SSL).Ваш компьютер выдаст вам предупреждения, если вы попытаетесь подключиться к серверу, а сертификат, который он получит, не является доверенным или не соответствует сайту, к которому вы пытаетесь подключиться.

Так что же мне выбрать: TLS или SSL?

Если вы настраиваете сервер , вам необходимо установить программное обеспечение , которое поддерживает последние версии стандарта TLS, и правильно его настроить. Это гарантирует, что соединения, которые устанавливают ваши пользователи, будут максимально безопасными.Также очень поможет использование отличного сертификата безопасности — например, один с 2048+ битовыми ключами, расширенной проверкой и т. д. Вам следует избегать использования SSL v3 и использовать только надежные шифры, особенно если требуется какое-либо соответствие.

Если вы настраиваете программу (особенно программу электронной почты) и имеете возможность безопасно подключаться через SSL или TLS, вы можете смело выбирать либо один …. если он поддерживается вашим сервером.

Примечание: многие веб-браузеры имеют специальные (обычно скрытые) настройки, которые позволяют вам специально включать / отключать SSL v2, SSL v3, TLS v1.0 и т. Д. В этих случаях вы фактически сообщаете браузеру, какие версии этих протоколов безопасности разрешите вашему браузеру использовать при установлении безопасных соединений. Мы рекомендуем отключить SSL v2 и SSL v3 (они не обеспечивают реальной безопасности). Некоторые веб-сайты по-прежнему поддерживают только SSL v3; Если вы столкнетесь с одним из них … сообщите им, что они серьезно отстают от времени и оказывают себе и своим посетителям серьезную медвежью услугу, делая вид, что обеспечивают безопасность, но на самом деле предоставляют только взломанное древнее шифрование.

Что произойдет, если я не выберу ни один из них?

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

Поддерживает ли LuxSci эти протоколы безопасности?

SSL / TLS составляет основу защиты клиент-сервер, которую LuxSci использует для всех своих услуг.Наши веб-серверы не поддерживают SSL v3.0 и поддерживают TLS v1.2; наши веб-сайты защищены от атак BEAST и POODLE. Мы используем только надежные шифры, рекомендованные NIST из соображений соответствия. Мы предлагаем различные порты для безопасного подключения к POP, IMAP и SMTP, используя как неявные, так и явные методы для установления TLS-шифрования. LuxSci также предлагает веб-почту через SSL и предоставляет SSL для клиентов веб-хостинга.

Для обеспечения целостности и безопасности ваших данных LuxSci настоятельно рекомендует воспользоваться нашими безопасными возможностями, такими как принудительное использование протоколов PGP, S / MIME, TLS и условного депонирования электронной почты.

А как насчет TLS v1.3?

TLS v1.3 — последняя и лучшая версия TLS. Он стал стандартом Интернета 25 марта 2018 года. Согласно NIST, организации должны разработать планы поддержки TLS v1.3 к 1 января 2020 года или раньше.

TLS v1.3 привносит много значительных изменений по сравнению с TLS v1.2. Некоторые из них включают:

  • Все шифры новые. Шифры, которые будут использоваться с TLS v1.3, несовместимы с предыдущими версиями TLS
  • Отбросьте слабую защиту. Многие известные криптографически слабые вещи, такие как MD5, RC4 и слабые эллиптические кривые, были полностью отброшены, поэтому их невозможно будет использовать с TLS v1.3.
  • Отбросьте редко используемые элементы . Функции, которые мало используются, такие как сжатие и шифры «смены шифра», были упразднены, чтобы упростить и усилить протокол.
  • Быстрее . TLS v1.3 ускоряет согласование безопасности клиент-сервер, делая безопасные соединения более быстрыми для инициирования.
  • Отсутствие подслушивания корпоративных / интернет-провайдеров . С TLS v1.3 организации больше не могут беспрепятственно отслеживать безопасные соединения путем их пассивного дешифрования и повторного шифрования.

Что дальше? Кто знает, возможно, «TLS v1.4» начнет включать в себя некоторые из постквантовых алгоритмов Google New Hope.

Есть вопросы? Спросите Эрика

См. Также

.

No related posts.

Share :

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

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