SSL 1.0, 2.0, 3.0 и TLS[править]
Версия 1.0 никогда не была обнародована. Версии 2.0 была выпущена в феврале 1995 года, но содержала много недостатков по безопасности, которые привели к разработке SSL 3.0 версии.
Как только различные компании (Microsoft) начали предпринимать попытки разработки собственных безопасных протоколов транспортировки, IETF решило вмешаться и определить стандарт протокола шифрования. Впоследствии, при поддержке множества компаний, на основании протокола SSL 3.0 был разработан и принят стандарт RFC, получивший имя TLS 1.0. Его также часто называют SSL 3.1.
Хотя TLS и SSL имеют существенные различия в реализации, разработчики обычно замечают лишь немногие из них, а конечные пользователи вовсе их не различают. Тем не менее TLS 1.0 и SSL 3.0 несовместимы. Значительное различие состоит в том, что TLS требует определенные алгоритмы шифрования, которые SSL не поддерживает. Таким образом TLS сервер должен “откатиться” (downgrade) до SSL 3.0 для работы с клиентами, использующими SSL 3.0.
Издержки TLS-рукопожатия
Исторически одна из претензий к SSL/TLS заключалась в том, что он перегружал серверы дополнительными издержками. Это повлияло на ныне несуществующее представление, что HTTPS медленнее, чем HTTP.
Рукопожатия до TLS 1.2 требовали много ресурсов и в больших масштабах могли серьёзно нагрузить сервер. Даже рукопожатия TLS 1.2 могут замедлить работу, если их происходит много в один момент времени. Аутентификация, шифрование и дешифрование — дорогие процессы.
На небольших веб-сайтах это скорее всего не приведёт к заметному замедлению работы, но для корпоративных систем, куда ежедневно приходят сотни тысяч посетителей, это может стать большой проблемой. Каждая новая версия рукопожатия существенно облегчает процесс: TLS 1.2 совершает две фазы, а TLS 1.3 укладывается всего в одну и поддерживает 0-RTT.
Шифронаборы TLS-рукопожатия
Шифронабор — это набор алгоритмов, определяющих параметры безопасного соединения.
В начале любого соединения самое первое взаимодействие, «Client Hello», представляет собой список поддерживаемых шифронаборов. Сервер выбирает лучший, наиболее безопасный вариант, который поддерживается им и отвечает его требованиям. Вы можете посмотреть на шифронабор и выяснить все параметры рукопожатия и соединения.
Шифронаборы TLS 1.2
- TLS — протокол.
- ECDHE — алгоритм обмена ключами.
- ECDSA — алгоритм аутентификации.
- AES 128 GCM — алгоритм симметричного шифрования.
- SHA256 — алгоритм хеширования.
В приведённом выше примере используется эфемерная система Диффи-Хеллмана (DH) с эллиптической кривой для обмена ключами и алгоритм цифровой подписи эллиптической кривой для аутентификации. DH также может быть соединен с RSA (функционирующим как алгоритм цифровой подписи) для выполнения аутентификации.
Вот список наиболее широко поддерживаемых шифронаборов TLS 1.2:
Шифронаборы TLS 1.3
- TLS — протокол.
- AES 256 GCM — алгоритм аутентифицированного шифрования с присоединёнными данными (AEAD).
- SHA384 — алгоритм функции формирования хешированного ключа (HKFD).
Мы уже знаем, что будем использовать какую-то версию обмена эфемерными ключами Диффи-Хеллмана, но не знаем параметров, так что первые два алгоритма в шифронаборе TLS 1.2 больше не нужны. Эти функции всё ещё выполняются, их просто больше не нужно согласовывать во время рукопожатия.
Из приведённого выше примера видно, что используется AES (Advanced Encryption Standard) для шифрования большого объёма данных. Он работает в режиме счётчика Галуа с использованием 256-битных ключей.
Вот пять шифронаборов, которые поддерживаются в TLS 1.3:
- TLS_AES_256_GCM_SHA384;
- TLS_CHACHA20_POLY1305_SHA256;
- TLS_AES_128_GCM_SHA256;
- TLS_AES_128_CCM_8_SHA256;
- TLS_AES_128_CCM_SHA256.
Cipher Suite Mismatch
This is incredibly similar to the protocol mismatch — just a bit more granular. SSL/TLS isn’t just one algorithm that handles everything (though ECC is close), it’s actually a collection of algorithms that serve different functions and work in conjunction to make up SSL/TLS.
SSL/TLS is like the Megazord and the cipher suite is like the Power Rangers.
What? You try to make a grouping of algorithms sound more interesting.
Anyway, while the cipher suites used by TLS 1.3 have been refined, traditionally a Cipher Suite has had algorithms that handle:
- Asymmetric public key encryption
- Symmetric session key encryption
- Key generation
- Signature hashing
Different industries and government agencies have different encryption standards that suggest different cipher suites. Generally, there’s a lot of overlap there, and most websites support a handful of cipher suites so that clients have several options and will generally be able to find a mutually agreeable cipher. Obviously, the odds of successful negotiation would decrease substantially if a site only supported a single cipher suite.
Oftentimes this can happen within a network if you’re performing SSL bridging, where an edge device receives and decrypts HTTPS traffic, then re-encrypts it so send along to the application server. If the edge device and the application server don’t share a mutually supported cipher suite, it will cause errors.
Much like with protocol versions, you should only ever move forward with cipher suites — never backwards. Remember, when a protocol version or cipher suite is deprecated it’s not because the industry is trying to be difficult — it’s because a vulnerability has been found or is imminent. So, going backwards only makes your connections potentially less safe.
§Encryption, Authentication, and Integrity
The TLS protocol is designed to provide three essential services to
all applications running above it: encryption, authentication, and data
integrity. Technically, you are not required to use all three in every
situation. You may decide to accept a certificate without validating its
authenticity, but you should be well aware of the security risks and
implications of doing so. In practice, a secure web application will
leverage all three services.
- Encryption
-
A mechanism to obfuscate what is sent from one host to another.
- Authentication
-
A mechanism to verify the validity of provided identification
material. - Integrity
-
A mechanism to detect message tampering and forgery.
In order to establish a cryptographically secure data channel, the
connection peers must agree on which ciphersuites will be used and the
keys used to encrypt the data. The TLS protocol specifies a well-defined
handshake sequence to perform this exchange, which we will examine in
detail in .
The ingenious part of this handshake, and the reason TLS works in
practice, is due to its use of public key cryptography (also known as
asymmetric key cryptography), which allows the peers to negotiate a
shared secret key without having to establish any prior knowledge of each
other, and to do so over an unencrypted channel.
As part of the TLS handshake, the protocol also allows both peers to
authenticate their identity. When used in the browser, this
authentication mechanism allows the client to verify that the server is
who it claims to be (e.g., your bank) and not someone simply pretending
to be the destination by spoofing its name or IP address. This
verification is based on the established chain of trust — see
. In addition, the server can also optionally
verify the identity of the client — e.g., a company proxy server can
authenticate all employees, each of whom could have their own unique
certificate signed by the company.
Finally, with encryption and authentication in place, the TLS protocol
also provides its own message framing mechanism and signs each message
with a message authentication code (MAC). The MAC algorithm is a one-way
cryptographic hash function (effectively a checksum), the keys to which
are negotiated by both connection peers. Whenever a TLS record is sent, a
MAC value is generated and appended for that message, and the receiver is
then able to compute and verify the sent MAC value to ensure message
integrity and authenticity.
Шифрование[править]
Существует два основных способа шифрования данных: симметричный ключ (общий секретный ключ) и асимметричный ключ (открытый ключ).
Открытый ключправить
Суть асимметричного шифрования заключается в том, что используется пара ключей. Один из них используется в качестве открытого (как правило, он публикуется в самом сертификате владельца), второй ключ называется секретным — он держится в тайне и никогда никому не открывается. Оба ключа работают в паре: один используется для запуска противоположных функций другого ключа. Если открытый ключ используется для того, чтобы зашифровать данные, то расшифровать их можно только секретным ключом и наоборот. Такая взаимосвязь позволяет делать две важные вещи.
Любой пользователь может получить открытый ключ по назначению и использовать его для шифрования данных, расшифровать которые может только пользователь, владеющий секретным ключом. (RSA)
Если заголовок шифрует данные, используя свой секретный ключ, каждый может расшифровать данные, используя соответствующий открытый ключ. Именно это является основой для цифровых подписей. (DSA)
RSA — самый распространенный алгоритм шифрования с использованием асимметричных ключей.
Комбинированный подходправить
Алгоритмы симметричного шифрования часто включают установленное число добавок и сдвигов. Такие алгоритмы часто используют ключ для помощи при битовых манипуляциях или для того, чтобы шифруемые данные стали более случайными. Другими словами, при увеличении размера секретного ключа может увеличиться случайность шифруемых данных, но не обязательно возрастет сложность вычислений при расшифровке.
Однако, шифрование открытым ключом использует ключ как экспоненту, поэтому значительное увеличения ключа сильно увеличивает количество вычислений, требуемых для шифрования / дешифрования данных.
Таким образом хотя алгоритмы шифрования открытым ключом не сталкиваются с проблемой распределения, с которой сталкиваются алгоритмы шифрования секретным ключом, они требует значительно больше вычислительной мощности. Для использования сильных сторон обоих типов алгоритмов протоколы безопасности обычно используют шифрование открытым ключом для передачи секретных ключей. Как только секретный ключ доставлен начинается передача данных с использованием симметричного шифрования.
Почему TLS использует как симметричную, так и асимметричную криптографию?
Почему бы просто не использовать только какую-то одну? Легко показать, что
симметричная криптография не может обеспечить аутентификацию, поскольку
существует единственный секретный ключ для клиента и сервера, то есть
они никак не могут проверить подлинность друг друга. Не говоря уже о том, что
тяжело реализовать обмен ключами, предотвратив его утечку, при передаче через
публичную сеть. А что если использовать асимметричную криптографию? На первый
взгляд хорошее решение. К сожалению, она работает намного медленнее
симметричной. Под «намного» я имею в виду от 100 до 10000 раз медленнее. Таким
образом, оно явно не подходит для шифрования больших объемов данных.
История SSL/TLS
SSL был первоначально разработан Netscape и впервые опубликован в 1995 году
сразу с версии 2.0. Версия 1.0 не была выпущена из-за ряда серьезных
недостатков безопасности. В 1996 году вышел SSL 3.0 — полностью
переработанная версия протокола. Затем, 3 года спустя, в RFC 2246 инженерным
советом Интернета (IETF) впервые был определен TLS 1.0 в виде обновления для
SSL 3.0. На обновление до версии 1.1 в 2006 году ушло 7 лет. TLS 1.2 вышел
сразу же после него в 2008. Затем, наконец, после 10 лет разработки, в 2018
вышел TLS 1.3, содержащий множество улучшений. Так какие версии SSL/TLS всё
ещё существуют на данный момент?
SSL 2.0 был признан устаревшим в 2011 году, SSL 3.0 — в 2015 году, а недавно
в марте 2020 года эта же участь постигла TLS 1.0 и TLS 1.1. Таким образом, в
настоящее время рабочими версиями являются только TLS 1.2 и 1.3.
Рисунок 1 — История SSL/TLS.
Цифровые сертификаты[править]
Протокол SSL использует сертификаты для проверки соединения. Сертификаты расположены на безопасном сервере и используются для шифрования данных и идентификации Web-сайта.
Способы получения SSL-сертификата:
- Использовать самоподписанный сертификат
- Использовать «пустой» сертификат
Самоподписанный сертификат — сертификат, созданный самим пользователем — в этом случае издатель сертификата совпадает с владельцем сертификата. «Пустой» сертификат — сертификат, содержащий фиктивную информацию, используемую в качестве временной для настройки SSL и проверки его функциональности в данной среде.
Принцип работы SSL[править]
Принцип работы SSL состоит из двух фаз: фаза рукопожатия и фаза передачи данных. Во время фазы рукопожатия клиент и сервер используют шифрование открытым ключом для того, чтобы определить параметры секретного ключа, используемого клиентом и сервером для шифрования во время фазы передачи данных.
Клиент инициирует рукопожатие посылая “hello”-сообщение серверу. Такое сообщение содержит список алгоритмов симметричного шифрования (cipher specs), поддерживаемых клиентом. Сервер отвечает похожим “hello”-сообщением, выбрав при этом наиболее подходящий алгоритм шифрования из полученного списка. Далее сервер отправляет сертификат, который содержит его публичный ключ.
Сертификат — это набор данных, который подтверждает подлинность. Подтвержденная третья сторона, известная как центр сертификации (CA), генерирует сертификат и проверяет его подлинность. Чтобы получить сертификат сервер должен использовать безопасные каналы для отправки своего публичного ключа в центр сертификации. Он генерирует сертификат, который содержит его собственный ID, ID сервера, публичный ключ сервера и другую информацию. А также центр сертификации создает отпечаток (digest) сертификата, который, по сути, является контрольной суммой. Далее центр сертификации создает подпись сертификата (certificate signature), которая формируется путем шифрования отпечатка сертификата приватным ключом центра сертификации.
Для проверки сертификата сервера клиент использует публичный ключ центра сертификации для расшифровки подписи. Затем клиент самостоятельно считает отпечаток сертификата сервера и сверяет с расшифрованным. Если они не совпадают, то сертификат был подделан.
Естественно, для расшифровки подписи у клиента должен быть публичный ключ центра авторизации. Поэтому клиент хранит у себя список публичных ключей подтвержденных центров сертификации. По факту, многие браузерные приложения имеют подобный список, находящийся непосредственно в их коде. Когда клиент установил подлинность сервера (сервер также может запросить сертификат у клиента), сервер использует шифрование открытым ключом для определения секретного ключа для обмена информацией.
Фаза рукопожатия завершается отправкой “finished”-сообщений, как только обе стороны готовы начать использование секретного ключа. Начинается фаза передачи данных, в ходе которой каждая сторона разбивает исходящие сообщения на фрагменты и прикрепляет к ним коды авторизации сообщений MAC (message authentication code). Код авторизации сообщения это зашифрованный отпечаток, вычисленный на основе содержимого сообщений. Из соображений безопасности, он не совпадает с секретным ключом и вычисляется вместе с секретным ключом на стадии рукопожатия. Для получения полноценного SSL пакета каждая из сторон объединяет данные фрагмента, код авторизации сообщения, заголовки сообщения и шифруют с использованием секретного. При получении пакета, каждая из сторон расшифровывает его и сверяет полученный код авторизации сообщения со своим. Если они не совпадают, то пакет был подделан.
Преимущества и недостатки протокола TLS
Еще в 1999 году, когда в SSL обнаружили уязвимости, было очевидно, что необходим обновленный протокол защиты данных. Это обстоятельство задало курс и тенденцию протоколу TLS. В 2014 POODLE успешно атаковал SSL 3.0, не оставив протоколу малейшего шанса. Что уж говорить о ранних версиях SSL.
Осенью 2014 Бодо Мёллер и его коллеги из Google Security Team обнаружили уязвимость в архитектуре протокола SSL 3.0. Атака POODLE подменяет пользовательские данные, и байт за байтом расшифровывает содержимое защищенного канала. Не существует способа обойти кодовую уязвимость, единственное логичное решение — блокировка использования протокола SSL 3.0 на всех рабочих системах.
Дизайн протоколов во многом идентичен: протокол TLS создавался по мотивам SSL, но в отличие от последнего параметры безопасности протокола TLS постоянно обновляется, в нем нет критических кодовых уязвимостей, что обеспечивает надежную защиту при транспорте данных.
Протокол TLS имеет ряд концептуальных отличий от SSL-протокола:
- В TLS используются другие ключи и увеличенный набор шифров.
- Улучшены стандарты формирования ключа на основе пароля.
- Есть различия в хэшировании HMAC, которое выполняет функцию создания блока симметричных ключей.
- Введены алгоритмы, увеличивающие безопасность канала.
Начинающие веб-разработчики сталкиваются с непростым вопросом: какой протокол выбрать? Для специалиста со стажем выбор очевиден – настройка протокола TLS идентична SSL, при этом безопасность шифрования на несколько порядков выше. Более того, специалисты по безопасности Google настоятельно рекомендуют не использовать SSL-протокол, отдавая предпочтение TLS.
Тем не менее, огромное количество пользователей ошибочно называют TLS «SSL-шифрованием». Откуда пошла путаница: поставщики сертификатов и веб-браузеры «застряли» в термине, который давно и плотно укоренился.
Знайте: когда вам предлагают «SSL-шифрование» — подразумевают TLS.
Протокол обеспечивает безопасность различных каналов связи: веб-трафик, электронную почту, систему телеконференций. Если в адресной строке виднеется шифровальная магия, имя которой — в вашем браузере устанавливается соединение по протоколу TLS.
Self-Signed Replacements
On the public internet, a self-signed certificate will return an error 100% of the time if the client hasn’t manually installed your private root in their root store. But, on internal networks self-signed certificates are fairly common. And if you swap them out enough, that can cause problems.
Most browsers will cache certificates so that upon return to a website it makes the handshake go faster. But if you’re generating new certificates at regular intervals, continuously adding all of those newly-generated certificates to the local database is going to cause confusion. Eventually, the browser will struggle with path-building and crash.
In the past, Firefox has struggled with this considerably — to the point where 7-8 certificate re-issues will cause significant latency, and 10 or more can cause the handshake to take upwards of 30 seconds.
Устройство протокола SSL[править]
Работу протокола можно разделить на два уровня:
- Слой протокола подтверждения подключения (Handshake Protocol Layer)
- Слой протокола записи
Первый слой, в свою очередь, состоит из трех подпротоколов:
- Протокол подтверждения подключения (Handshake Protocol)
- Протокол изменения параметров шифра (Cipher Spec Protocol)
- Предупредительный протокол (Alert Protocol)
Протокол подтверждения подключения производит цепочку обмена данными, что в свою очередь начинает аутентификацию сторон и согласовывает шифрование, хэширование и сжатие. Следующий этап — аутентификация участников, которая осуществляется также протоколом подтверждения подключения.
Протокол изменения параметров шифра используется для изменения данных ключа (keying material) — информации, которая используется для создания ключей шифрования. Протокол состоит всего из одного сообщения, в котором сервер говорит, что отправитель хочет изменить набор ключей.
Предупредительный протокол содержит сообщение, которое показывает сторонам изменение статуса или сообщает о возможной ошибке. Обычно предупреждение отсылается тогда, когда подключение закрыто и получено неправильное сообщение, сообщение невозможно расшифровать или пользователь отменяет операцию.
Протокол записиправить
Протокол записи (Record Layer) — это уровневый протокол. На каждом уровне сообщения включают поля для длины, описания и проверки. Протокол записи принимает сообщения, которые нужно передать, фрагментирует данные в управляемые блоки, разумно сжимает данные, применяя MAC (message authentication code), шифрует и передаёт результат. Полученные данные он расшифровывает, проверяет, распаковывает, собирает и доставляет к более верхним уровням клиента.
Существует четыре протокола записи:
- Протокол рукопожатия (handshake protocol);
- Протокол тревоги (alert protocol);
- Протокол изменения шифра (the change cipher spec protocol);
- Протокол приложения (application data protocol);
Ключевые отличия SSL и TLS[править]
- Аутентификация сообщений: в TLS используется HMAC, работающий с любой хэш-функцией (а не только с MD5 или SHA, как в SSL).
- Генерация ключа: в TLS при создании ключа используется псевдослучайная функция стандарта HMAC; в SSL — RSA, Diffie-Hellman или Fortezza/DMS.
- Проверка сертификата: в SSL проверка требует передачи сложной последовательности сообщений; в TLS информация о проверке полностью передается в сообщениях во время handshake.
- Методы шифрования: SSL поддерживает только алгоритмы RSA, Diffie-Hellman и Fortezza/DMS. В TLS отказались от поддержки Fortezza/DMS, но возможно добавление новых методов шифрования в последующих версиях.
Что изменилось в TLS 1.3 по сравнению с TLS 1.2?
Важно помнить, что при создании версии 1.3 главным было повышение безопасности и производительности. Для этого в TLS 1.3 был переработан алгоритм генерация ключей и исправлены известные уязвимости
В рукопожатии TLS 1.3 также стали лучше некоторые процессы, например аутентификация сообщений и цифровые подписи.
Наконец, в дополнение к постепенному отказу от старых алгоритмов генерации ключей или обмена ими, TLS 1.3 устраняет старые симметричные шифры. В TLS 1.3 полностью исключили блочные шифры. Единственный разрешённый в TLS 1.3 тип симметричных шифров называется шифрованием с проверкой подлинности с использованием дополнительных данных (AEAD). Он объединяет шифрование и проверку подлинности сообщений (MAC) в одну функцию.
What Is an SSL/TLS Handshake?
An SSL/TLS handshake is a negotiation between two parties on a network – such as a browser and web server – to establish the details of their connection. It determines what version of SSL/TLS will be used in the session, which cipher suite will encrypt communication, verifies the server (and sometimes also the client), and establishes that a secure connection is in place before transferring data.
This all happens in the background, thankfully – every time you direct your browser to a secure site a complex interaction takes place to make sure that your data is safe.
That’s the simple version. You might notice that any dozen descriptions will hew more or less to this format, while differing in detail a dozen different ways – sometimes confusingly so. Let’s throw a chart up that shows a broad model of how a TLS handshake works, shall we?
Need a certificate? SSL.com has you covered. Compare options here to find the right choice for you, from S/MIME and code signing certificates and more.
Клиентский сертификат
Клиентский сертификат может быть сгенерирован как для использования в устройствах, так и для использования пользователями. Обычно такие сертификаты используются при двусторонней верификации, когда клиент верифицирует, что сервер действительно тот, за кого себя выдает, и сервер в ответ делает то же самое. Такое взаимодействие называется двусторонней аутентификацией или mutual authentication. Двусторонняя аутентификация позволяет повысить уровень безопасности по сравнению с односторонней, а также может служить заменой аутентификации с использованием логина и пароля.
