What is a TLS/SSL certificate and how does it work?
Learn all about TLS/SSL certificates, the digital files that help to authenticate and secure data transfers across the internet.
Whenever you send or receive information on the internet, it passes through a network of multiple computers to reach the destination. Historically, any of these computers could read your data because it wasn’t encrypted.
Much of your data is sensitive — and valuable to hackers. It can include private communications that aren’t end-to-end encrypted, financial information, and even login credentials (for web apps that don’t use the Secure Remote Password protocol).
To protect sensitive data, security experts developed a standard protocol to send and receive internet traffic: Secure Sockets Layer (SSL). SSL later evolved into Transport Layer Security (TLS), which has now largely replaced SSL.
We explain how TLS and TLS certificates work, their weaknesses, and the extra steps we take at Proton to secure TLS-encrypted connections.
What is TLS?
Transport Layer Security (TLS) is an encryption protocol that provides secure connections between servers and applications on the internet.
Before TLS, websites and apps used the Hypertext Transfer Protocol (HTTP) (new window) to transfer data over the internet, which wasn’t designed to be secure. Today, most use sites use the Hypertext Transfer Protocol Secure (HTTPS), an extension of HTTP that uses TLS encryption.
When you connect to a website that uses HTTPS, TLS verifies the identity of the website’s server and encrypts your connection, preventing hackers from intercepting any data transmitted between your device and the site. In this way, TLS provides privacy and security for the data transmitted between your browser and the website, and you can be sure the data hasn’t been tampered with.
How does TLS work?
TLS uses public-key cryptography (new window) to verify the authenticity of a website. Every website that uses HTTPS (TLS) generates a mathematically related key pair:
- A private key, which is kept secret and used to sign data
- A public key, which anyone can use to verify that data
When your browser tries to connect to a website (a domain name like proton.me), the server creates a digital signature using the private key, which the browser verifies using the corresponding public key. If successful, this verification proves you’re connecting to a server that belongs to the domain name you’re visiting.
But how can your browser be sure the server’s public key really belongs to that domain? To solve this problem, TLS uses TLS certificates to help verify the identity of the server you’re connecting to.
What is a TLS certificate?
A TLS certificate is a type of digital certificate issued by a certificate authority (CA) to certify the ownership of a public key.
TLS certificates usually contain the following information:
- The subject domain name (for example, proton.me)
- The name of the issuing CA
- Additional subject domain names, including subdomains, if any
- The date of issue
- The expiry date
- The public key used to verify data (the subject organization keeps the private key secret)
The CA digitally signs the certificate, so if you trust the CA, you can be sure the public key belongs to the owners of the subject domain name.
How does a TLS certificate work?
When you try to connect to a website using HTTPS, the website server sends your browser its TLS certificate.
Your browser then verifies that the certificate is valid and digitally signed by a trusted CA by comparing it with information it stores about trusted CAs. This verification process uses public-key cryptography like RSA (new window) or ECC (new window) to prove the CA signed the certificate.
The signed certificate verifies the website server’s public key, which confirms that you’re communicating with the genuine server of the website you’re visiting, like https://proton.me, and not a hacker.
The server also authenticates a key exchange, resulting in a one-time session key that is used to send encrypted and authenticated data between the clients and the server.
In simplified terms, here’s how your browser and a website server establish a secure connection using a TLS certificate.
How TLS connections work
Most browsers display a padlock to show that your connection is secure and the site’s TLS certificate is valid.
To make sure you’re securely connected to a website using HTTPS, check the following:
- The padlock is displayed: This indicates that the connection is secure.
- The URL is correct: Check it’s https://proton.me, not pr0ton.me, protan.me, or some other fake look-alike. If you’re connecting to a subdomain, like https://mail.proton.me (new window) for the Proton Mail web app, check it’s precisely mail.proton.me, not mail-proton.me or mail.proton.co.
If all the above are correct, your connection is secure, provided you can trust the certificate authority that issued the TLS certificate.
Why trust certificate authorities (CAs)?
As CAs are responsible for verifying that the data you received came from the server you expected, they play an essential role in the internet. They’re the backbone of secure internet communication, helping encrypt billions of data exchanges and transactions by issuing millions of digital certificates every year.
There are many precautions that CAs take to ensure the security of the certificate issuance process. For example, CAs store the private keys in a hardware security module (new window) so they can’t be extracted (although this doesn’t prevent certificates from being mistakenly signed).
Additionally, CAs follow various policies set by the CA/Browser Forum (new window) that establish and maintain security standards. All these measures help ensure the TLS certificate verification process is trustworthy.
The trust model of TLS relies on two major elements:
- Root certificates (also known as trusted roots)
- The server’s certificate
Your browser will automatically trust any certificates issued by a CA, provided the CA’s root certificate is installed in the certificate store of your device. Every device has a certificate store, a local collection of root certificates from trusted CAs. Only CAs that can demonstrate that they adhere to the policies set by the CA/Browser Forum are trusted by root certificate stores.
What are the weaknesses of TLS certificates?
Although TLS certificates are generally secure, here are some ways hackers can attack and potentially compromise TLS.
Certificate store poisoning
If an attacker infects your computer with malicious software (malware) (new window) , they could gain access to the digital certificates stored on your device and insert a root certificate. They could then impersonate a website by fraudulently responding to your website requests.
Someone might ask you to install a root certificate on your device, for example, to access an internal site on a corporate network. Never install a root certificate on a personal device.
Similarly, never access Proton or other important accounts from a device with a root certificate installed, or from a public or shared device you don’t own, especially if it was given to you by someone you don’t completely trust.
Attacking CAs directly
For TLS certification to work, the CA must be secure. Any breach of the CA could lead to the incorrect or fraudulent authorization of keys.
CAs have occasionally been compromised, as we saw in the data breaches at Comodo and DigiNotar (new window) in 2011, which allowed attackers to issue fraudulent certificates.
Mistakenly issued certificates
Users rely on CAs to authenticate the server they connect to. However, sometimes CAs make mistakes in issuing certificates that present a vulnerability that hackers can exploit.
When combined with an insecure internet connection, an attacker could use a mistakenly or fraudulently issued certificate to compromise your connection with a server.
If these vulnerabilities exist, can you trust CAs? Yes, but it’s sensible to take precautions to minimize these risks.
Proton’s TLS security precautions
While CAs and TLS-based encryption methods are relatively secure, there’s always scope for improvement.
At Proton, we aim to enhance privacy and security for everyone online. Here are some of the additional steps we take to secure TLS-encrypted connections.
DNS certification authority authorization (DNS CAA)
As public concern about the security of CAs grew following the CA data breaches in 2011 (new window) , work on new security measures gathered pace. One of the outcomes of that work was DNS certification authority authorization (DNS CAA), which blocks the issuance of incorrect certificates.
DNS CAA allows domain owners to use a DNS resource record to specify which CAs are allowed to issue certificates for a given domain. If a CAA record exists, only the CAs listed in that record can issue the host’s certificate.
Although this provides some protection against unintended certificate misuse, it’s very difficult for users to detect if a CA ignores the CAA advisory. That’s why we use certificate transparency.
Certificate Transparency (CT)
To ensure the validity of certificates and prevent them from being mistakenly or fraudulently issued, all CAs post the certificates they generate on public log servers known as Certificate Transparency (CT) logs. These servers send a signature to the CA promising to publish their certificate.
We serve an Expect-CT header, which tells the browser to require the presence of this signature. We also have monitoring and auditing servers that check the CT log for all promised certificates meant to be published.
Together, all these measures make it highly improbable for anyone, including a state actor, to generate a TLS certificate for proton.me and use it to intercept connections without being detected.
TLS certificate pinning
Certificate pinning is a process that links a service to its specific public key. Once a certificate is established for a particular service, it’s permanently pinned to the service.
If multiple valid certificates exist for a given service, the pins are merged into a pinset. To validate a pinset, at least one element from the service must match the elements in the pinset. We pin the public key of our certificates in all our native apps.
At Proton, our work on TLS is part of our goal to give everyone privacy and security online. That’s why we offer free end-to-end encrypted Proton Mail, Proton Calendar, Proton Drive, Proton Pass, and Proton VPN (new window) — so everyone can be free online.
Our free accounts are funded by paying members of the Proton community, not by exploiting your personal data. If you want to support our mission to give everyone privacy and security online, sign up for a paid plan.
SSL/TLS Certificate: What is it and Why You Need One
Ever since the mid-90s, protocols have been used to provide better security and privacy for internet communications. One of the most critical security features for domains is the SSL certificate. In this resource, you’ll learn all about SSL and TLS protocols and how certificates work.
What is SSL?
Secure Sockets Layer (SSL) is a protocol that digitally authenticates ownership of public keys. First developed by Netscape in 1995, SSL provides secure connections between client- and server-side internet communications. The SSL protocol was deprecated with the release of TLS 1.0 (see below).
What is TLS?
TLS stands for Transport Layer Security and is the successor to the SSL protocol. Like SSL, the purpose of TLS is encrypting and authenticating data between servers and web applications. This protocol was developed by the Internet Engineering Task Force (IETF) in 1999. The most current version of TLS is version 1.3, which was released in 2018.
Did you know?: TLS first started development by IETF as SSL 3.1 but was renamed so as not to be associated with Netscape.
SSL vs TLS: What’s the Difference?
According to IETF, there are no major differences between SSL and TLS as they both carry out the same function. That said, TLS is more secure than its predecessor. Servers using the TLS protocol not only require support for a higher level of encryption but must also support the most recent TLS protocols. Old habits die hard, though. While TLS is the preferred protocol, SSL is still used in some cases and TLS is even referred to as SSL — but the term “TLS” is catching on slowly but surely.
In regards to SSL or TLS certificates, there’s really no difference. The terms are used interchangeably regardless of which protocol is being utilized. This is because both SSL and TLS certificates follow the X.509 standard format for public keys.
Fun Fact: Despite previous attacks against the SSL protocol (BEAST and BREACH), version 3.0 was still extensively used until 2014 when the POODLE vulnerability was discovered by Google.
How SSL/TLS Certificates Work
One of the safest and widely used methods of encryption is asymmetrical cryptography, which involves two cryptographic keys: public and private. The public key is used to encrypt data while the private key decrypts it. Picture the public key as a safe with a drop slot. Anyone can add something to the safe, but only the person with the combination can see what’s inside. In this case, the private key is what holds the combination to the safe. SSL/TLS certificates utilize this type of cryptography to complete what is called a digital handshake.
HTTP vs HTTPS
HTTP and HTTP are protocols that every website uses. The only difference between them is security. Any site that uses HTTPS is also utilizing TLS/SSL to encrypt communication and is therefore much more secure than sites running over HTTP. It’s easy for anyone to determine whether a site is using encryption or not. For example, any URL that has HTTPS:// is using TLS/SSL. If it only has HTTP://, the site is not secured by encryption. Another way to spot HTTPS in a website address is the padlock to the left of the URL. If you click on the lock icon, it will confirm that the site is secure.
If you click on “Certificate,” you’ll also see the certificate authority when it was issued, and for how long it is valid.
SSL or TLS Handshake
The digital handshake for SSL/TLS represents the events that take place between clients and servers. It entails sending encrypted messages between a client and a server to guarantee the integrity of the data being sent or accessed. Most handshakes follow the below pattern but may deviate if a server is using a different handshake protocol, such as Diffie-Hellman Key Exchange.
- Client greeting (hello)
Client initiates handshake by sending a hello message to an SSL-certified website. - Server greeting (hello)
Server responds with the site’s SSL certificate. - Authentication
Client verifies the certificate - Pre-master secret
The client obtains a public key from the server’s SSL/TLS certificate, and then sends it back as an encrypted string of bytes. - Decryption
Server decrypts the public key (pre-master secret) - Session Keys
The client and server generate random session keys alongside the pre-master secret, which should receive the same results on both sides. - Client and server ready
Client and server both send encrypted “final” messages with session keys. - Secure symmetric encryption achieved
Handshake concludes and communication is continued via session keys.
Types of SSL Certificates
There are three types of SSL certificates available: Single Domain, Wildcard, and Multi-domain.
As the name implies, single domain certificates protect one domain and subdomain within its hierarchy. Wildcard SSL certificates function the same as a Single Domain certificate, except it also certifies all first-level subdomains. Multi-domain SSL certificates protect an unlimited amount of domains and subdomains.
SSL Certificate Costs
Prices for certificates range considerably and will also vary depending on the needs of your organization. The type of certificate number of domains and subdomains you have plays a large part in the cost, but other factors such as level of assurance needed, warranty, reissues, key length, and encryption strength should also be taken into consideration.
Free SSL Certificate
Free Certificate Authorities are also an option. While this can save on costs, there may be several limitations to free certificates, so you want to make sure it will meet all your requirements. For instance, many free SSL certificates are trial-based or are only for a limited time before you need to renew. Even if renewal is free, you’ll need to make sure your certificate doesn’t expire. Another caveat is that many free issuers don’t offer business or extended validation. The important thing is that you research all your options before choosing a Certificate Authority for your domain.
Common SSL Certificate Errors
Almost all modern browsers can recognize SSL certificates. But every so often, end users can encounter errors with a domain’s certificate. Knowing what the common errors are can help maintain trust in your website.
- Your connection isn’t private: This happens when a browser can’t verify your domain’s SSL certificate. Because the browser can’t confirm the domain’s identity, it blocks the user from accessing the site.
- Expired certificate: If you don’t renew your domain’s certificate before it expires, users will get an error message alerting them to the fact that your certificate is no longer valid.
- Untrusted Certificate Authority: When this error is encountered, it means that the browser was unable to locate the root certificate from a trusted source. This can also happen if a certificate is self-signed and not added to a browser’s trusted store.
Of course, this isn’t an exhaustive list of SSL certificate errors. It is highly advisable that someone on your team is familiar with how certificates work and how to troubleshoot them in case of any unforeseen issues.
SSL Certificate Checker
Luckily, there are online tools available to help troubleshoot installation problems and other issues with SSL certificates. Here’s a quick list of a few popular options:
SSL/TLS Certificates Recap
SSL certificates are an important security measure for websites. With an SSL certificate, domains can encrypt web traffic with SSL/TLS protocols for enhanced protection. While SSL is still used by some websites, the preferred and most secure protocol for internet communications is TLS. The bottom line is that certificates not only protect users from suspicious websites, but also help businesses maintain trust in their brand.
Сертификаты SSL и TLS: предназначение, отличия и проверка
Когда мы используем интернет для поиска информации, покупки вещей или бронирования билетов на самолет, мы никогда не задумываемся о безопасности сайта и защите своих данных. Да и зачем это, если перед глазами популярный сервис, который давно себя зарекомендовал.
Другое дело, когда спустя сотню запросов мы находим нужную вещь для покупки, но она расположена на сомнительном ресурсе. И тут уже возникает вопрос: «А не будет ли мне это стоить всего моего состояния?». Давайте разберемся, как уберечь себя от потери личных данных и проверить сайт на наличие SSL и TLS сертификатов.
Сертификаты SSL и TLS: зачем они нужны
Продолжим разбор ситуации с покупкой чего-либо через интернет: представим себе, что мы собрались полететь на солнечное Бали из Москвы. Мы нашли сайт, который не представляет собой ничего подозрительного, и поэтому спокойно вводим на нем все необходимые данные и бронируем билеты на самолет.
В то время, когда на сайте совершается оплата за выбранные билеты, начинают срабатывать сертификаты защиты. Их еще называют SSL и TLS, но они представляют собой развитие одной технологии.
SSL расшифровывается как Secure Socket Layer, что означает «уровень защищенных сокетов». TLS же обозначается как Transport Layer Security, «безопасность транспортного уровня». По своей сути обе технологии занимаются одним делом – защитой пользовательской информации от злоумышленников.
Их отличие состоит лишь только в том, что TLS основан на уже действующей спецификации SSL 3.0. А сам SSL уже давно устарел, разработчики редко его используют как единственную защиту. Чаще всего можно увидеть связку двух сертификатов SSL/TLS. Такая поддержка обеспечивает работу как с новыми, так и со старыми устройствами.
Использование такой защиты можно встретить в различных ситуациях: при передаче сообщений, отправке личных данных, транзакциях и т.д.
Специфика работы сертификатов SSL/TLS
Вернемся к ситуации с покупкой билетов на сайте. Как мы выяснили, при отправке личных данных начинают действовать сертификаты. Но что происходит, если защита не производится должным путем?
Без подключения SSL/TLS контакт между пользователем и веб-сайтом происходит через канал HTTP. А это означает, что вся передаваемая информация находится в открытом виде: доступ к данным лежит на поверхности. То есть, когда происходит связь между пользователем и сайтом, например, при оплате билетов на самолет, вся информация, включая паспортные данные, может быть получена злоумышленником. Такое происходит, если на сайте не используются сертификаты защиты.
При подключении SSL/TLS, пользователь устанавливает соединение с веб-сервером HTTPS, который защищает все конфиденциальные данные при передаче. Кроме того, срабатывает привязка криптографического ключа к передаваемой информации и выполняется шифровка данных, которую никто не сможет перехватить.
SSL/TLS используют ассиметричное шифрование для аутентификации пользователя и симметричное для сохранения целостности личной информации.
Как проверить сертификаты SSL/TLS
Мы рассмотрим 5 наиболее популярных онлайн-инструментов для обнаружения слабых мест веб-сайта. Что ж, давайте приступим.
SeoLik
Начнем с отечественного онлайн-сервиса, который позиционирует себя как инструмент для проверки надежности сайта. Помимо основной задачи здесь также можно выполнить сканирование портов, узнать свой IP-адрес и произвести другие действия с сайтом.
Проверяем наличие HTTPS соединения:
- Открываем в браузере сервис Seolik и вводим ссылку на необходимый сайт, затем кликаем по кнопке «Анализ».
- В результате анализа рассматриваемого ресурса, перед нами отобразится вся необходимая информация: название сертификата, срок действия, серийный номер и другие атрибуты, которые могут быть полезны для разработчиков.
Использование данного сервиса поможет проверить сайт всего за несколько минут и уберечь от потери личной информации. В данном случае мы можем быть спокойны, сертификат действителен еще 322 дня.
SSL Shopper
По сравнению с предыдущим сервисом, данный инструмент не столь функционален и поддерживает только англоязычную версию. Давайте посмотрим, как он работает:
- Переходим в онлайн-сервис и вводим ссылку, которую требуется проверить.
- После выполнения запроса мы видим, что сайт надежно защищен.
- Если пролистать немного ниже, то можно посмотреть дополнительную информацию о сертификатах.
Wormly Web Server Tester
Один из самых популярных инструментов для проверки сайтов, который помогает не только узнать о наличии SSL/TLS, но и дает возможность просмотреть данные о шифровании, различные протоколы и многое другое. Работает это следующим образом:
- Открываем сайт и вводим в запрос «Web Server URL» нужную ссылку, затем кликаем по красной кнопке.
- Далее будет запущен глубокий анализ, который можно пропустить. Уже на первых этапах тестирования будет сообщено о безопасности ресурса в строке «Expires».
Данный сервис позволяет просматривать шифры сертификатов, что может быть полезно для веб-разработчиков.
Immuni Web
Это многофункциональный гигант, который анализирует поддержку протоколов, проверяет на совместимость PCI DSS и делает много всего, что недоступно в предыдущих инструментах. Конечно, здесь можно проверить и сайт на безопасность.
- Переходим по ссылке и в строку запроса «Enter your website or mail server address here» вписываем адрес для проверки. Далее кликаем по кнопке запуска справа от строки.
- Как только появятся результаты, перед нами отобразится новая страница. Пролистываем немного вниз и находим две строчки «Valid From» и «Valid To». Первая информирует о том, когда был выдан сертификат, вторая указывает на окончание срока действия.
При необходимости можно сохранить все результаты в формате PDF. Для этого следует кликнуть по кнопке «Download report».
SSL Checker
Незаменимый инструмент для разработчиков. Особенностью данного сервиса является то, что в нем можно активировать уведомления, которые будут оповещать об истечении срока действия сертификата.
- Переходим по ссылке и вводим адрес. Справа от строки запроса кликаем по кнопке «Check».
- Перед нами отобразится вся нужная информация. Для того чтобы напомнить об истечении срока действия сертификата, достаточно кликнуть по кнопке «Remind me SSL is about to expire» и указать свою почту.
На этом моя статья подходит к концу. Теперь вы знаете, как можно проверить SSL и TLS сертификаты на сайте. Спасибо за внимание!
Протокол TLS: что это, зачем нужен и как работает
Если вы что-то оплачиваете в интернете, то мошенники до сих пор не опустошили ваши карточки именно благодаря TLS.
Иллюстрация: Оля Ежак для Skillbox Media
Давным-давно, когда интернет был ещё совсем юным, данные летали по Сети как есть — в открытом виде. Но время шло, и всё больше наших повседневных действий стало уходить на сайты: от покупок до записи к врачу, от общения до сделок с недвижимостью. Стало ясно, что весь этот трафик надо как-то шифровать.
Первой попыткой защитить ценные данные при передаче стал протокол SSL — о нём у нас уже есть отдельная статья. Сейчас из-за некоторых уязвимостей чистый SSL используют редко — зато его версия на максималках, протокол шифрования данных TLS, надёжно охраняет транзакции по всему миру. О нём и поговорим сегодня.
Из этой статьи вы узнаете:
Что такое TLS
TLS, или transport layer security, — это протокол, который защищает данные во время их передачи по Сети. Он работает на четвёртом, транспортном, уровне сетевой модели OSI, где отвечает за создание безопасных сессий обмена данными между браузером и сервером.
Изначально TLS использовали в основном для соединения со страницами оплаты — однако сейчас он работает почти на каждом уважающем себя сайте. Понять, что сайт использует TLS, легко: если его адрес начинается с https, а рядом красуется символ замочка — значит, ваши данные защищены.
Аббревиатура HTTPS означает, что сайт использует защищённую версию протокола HTTP — Hypertext Transfer Protocol Secure. По сути, это и есть обычный HTTP, только нашпигованный средствами защиты, за которые как раз и отвечает TLS.
Чтобы понять, как работает TLS, проведём аналогию с фильмом «Чёрная пантера». Если помните, у вакандийцев есть два характерных атрибута коммуникации. Во-первых, это фирменные приветствия со скрещёнными на груди руками, которые позволяют им узнавать друг друга. А во-вторых, конечно, вакандийский язык, понятный в основном жителям этой страны.
То же самое и с компьютерами. Когда вы заходите на сайт, защищённый TLS, ваш браузер и сервер сначала жмут друг другу руки: устанавливают соединение, обмениваются секретными ключами и выбирают алгоритмы шифрования. А потом начинают общение на загадочном языке, понятном только им.
Дальше в статье мы подробнее разберём процесс рукопожатия и обмена сообщениями в TLS — но перед этим обсудим ещё одну важную тему.
В чём разница между SSL и TLS
Если вы уже читали нашу статью про SSL, то наверняка заметили, что между двумя протоколами много общего: оба шифруют данные, оба используют секретные ключи, оба создают защищённые сессии. Так в чём же разница? Чтобы в этом разобраться, погрузимся ненадолго в историю.
Протокол SSL разработала компания Netscape в середине 1990-х, чтобы улучшить свой браузер Navigator (олды помнят). Для своей эпохи SSL был вполне хорош, но со временем в его безопасности нашлись серьёзные бреши. Одной из самых критичных стала небезопасная проверка паддинга.
Паддинг — это блок данных, который компьютер добавляет к исходным данным при отправке, чтобы сообщение соответствовало определённой обязательной длине, зависящей от пропускной способности сетевого оборудования.
Хакеры придумали хитрость: они вклинивались в сессию и отправляли сообщения с неправильным паддингом, при расшифровке которого сервер выдавал ошибку, где с потрохами сдавал внутренние процессы дешифрации. Эти данные мошенники использовали, чтобы вычислить исходное сообщение.
Чтобы лучше понять, как это работает, представьте, что вы пытаетесь угадать чей-то пароль. Но вместо обычного «пароль неверный» система говорит вам ещё и о том, что он слишком длинный или в нём нет каких-то символов. Тем самым система помогает хакеру сузить количество вариантов «паролей».
Исправить эту уязвимость одними обновлениями было невозможно — она была связана с самим дизайном SSL, а не конкретными реализациями. Именно из-за подобных проблем, а также из-за банкротства Netscape, разработка перешла в так называемый Инженерный совет интернета — IETF. Там протокол улучшили, исправили косяки безопасности и выпустили под новым названием — TLS.
Новый протокол обзавёлся более совершенными механизмами шифрования и аутентификации, а также проверкой добавленных блоков. Да, атаку с неправильным паддингом стало провернуть не так-то просто:
Сегодня протокол SSL считается устаревшим — использовать его не рекомендуется из-за вышеуказанных проблем. Однако термины SSL и TLS до сих пор часто путают и используют как синонимы. Но теперь вы знаете, как всё обстоит на самом деле, и можете помочь «распутаться» окружающим.
Как TLS шифрует данные
Чтобы защитить данные, TLS создаёт во время передачи специальный канал, где их нельзя прочитать или изменить без секретного ключа. Ключ — это подсказка, как именно читать сообщение. Самый простой пример ключа — это чтение первых букв в строке:
Вашими молитвами только и живём, дорогой Игорь Николаевич!
Совсем не ограничиваем себя.
Если урожай хороший народится — доведём мельницу до порядку.
Покуда в Петербурге гуляния, уж дайте себе волю.
Любуйтесь красотами и с людьми знакомьтесь.
О нас не беспокойтесь, Бог даст — Тверь не пропадёт.
Хорошо живём, ни на что не жалуемся.
Ответа скорого не ждём, но пишите уж по возможности.
В реальности ключи, конечно, намного сложнее, но смысл тот же — подсказка для правильного чтения.
В зависимости от количества ключей в TLS используется один из двух классов шифрования: симметричное и асимметричное.
Симметричное шифрование — это когда используется один и тот же ключ для шифрования и дешифрования данных. Оно работает эффективно и быстро, но требует предварительного обмена ключом между компьютером и сервером, в ходе которого ключ могут перехватить.
Асимметричное шифрование использует два ключа: публичный для шифрования и приватный для дешифровки. Публичный ключ можно свободно распространять, а приватный должен быть хорошо защищён. Асимметричное шифрование безопаснее, но требует больше вычислительных ресурсов и работает медленнее, чем симметричное.
В протоколе TLS симметричное шифрование используют для шифрования непосредственно сообщений, а асимметричное шифрование — во время рукопожатия, то есть в начале сессии для обмена ключами и аутентификации.
Ещё TLS обеспечивает проверку подлинности сервера при помощи специальных сертификатов, которые заверяет специальный центр сертификации. С таким сертификатом ваш браузер будет уверен, что не обменивается данными с хакером.
Помимо шифрования в TLS используется несколько алгоритмов хеширования.
Хеширование — это преобразование массива данных в строку фиксированной длины. Для хеш-функции неважно, что именно вы через неё пропустите: полный текст «Войны и мира», трёхзначное число или email-адрес — на выходе будет всегда строка из заранее известного количества символов. Если поменять в исходном массиве хоть один знак, то хеш тоже изменится.
Когда ваш браузер отправляет данные с помощью протокола TLS, вместе с ними автоматически отправляется их хеш. Сервер получает данные и пропускает их через ту же хеш-функцию, что и браузер. Если данные не поменяли — хеши совпадут и обмен сообщениями пройдёт успешно.
На сайте wtools.io можно сделать хеш из любого текста — мы, например, захешировали текст этой статьи:
Основной алгоритм хеширования в TLS — это SHA на 256, 512 или 384 бит. Использование MD5 и SHA-1 не рекомендуется — с современными мощностями их слишком легко взломать обычным перебором.
Основные алгоритмы шифрования в TLS
С механикой работы шифрования разобрались — теперь давайте коротко расскажем, с помощью каких алгоритмов весь этот процесс происходит.
AES (Advanced Encryption Standard). Симметричный алгоритм шифрования, использующий для защиты данных ключи длиной от 128 до 256 бит. Чем длиннее ключ, тем выше защита, но ниже производительность.
3DES (Triple Data Encryption Standard). Чуть менее безопасный алгоритм. Он делает то же самое, что и AES, но тремя разными ключами. Это как если бы вы спрятали свои данные в коробку, эту коробку в другую коробку, а её в свою очередь убрали в третью коробку. Получается сложная конструкция из коробок, которая не даёт посторонним людям узнать, что внутри.
ChaCha20-Poly1305. Симметричный алгоритм, который использует ChaCha20 для генерации ключей и Poly1305 для создания MAC — кода аутентификации сообщений. Сервер вычисляет MAC и сравнивает его с полученным значением от клиента. Если совпало — значит, данные никто не менял.
Как работает TLS
Настало время выложить карты на стол. На самом деле, TLS — это не один протокол, а целых два: протокол рукопожатия и протокол записи. Каждый из них отвечает за свой набор функций. Коротко расскажем, в чём их смысл.
Допустим, вы заходите на сайт Skillbox Media, чтобы почитать статью про ИИ общего назначения. На этом этапе ни ваш браузер, ни сервер ещё ничего друг о друге не знают. Чтобы исправить эту ситуацию, начинает свою работу протокол рукопожатия (handshake protocol). Вот из каких этапов состоит процесс его исполнения:
Приветствие
Клиент и сервер обмениваются сообщениями, в которых они представляются друг другу и договариваются, какие алгоритмы шифрования будут использовать при передаче данных.
Обмен ключами
Клиент и сервер убеждаются в подлинности друг друга и выполняют обмен ключами для дальнейшего использования при шифровании данных.
Завершение рукопожатия
Клиент и сервер подтверждают, что установка соединения прошла успешно и что они готовы к защищённой передаче данных.
Когда соединение установлено, самое время наконец отправить вам нужную статью. И тут в игру вступает протокол записи (record protocol): он отвечает за шифрование и передачу данных между сайтом и браузером. Он работает поверх установленного соединения по параметрам, о которых клиент и сервер договорились во время рукопожатия. И совершается эта магия за пять шагов:
Фрагментация
Данные разбиваются на фрагменты меньшего размера для последующего шифрования.
Компрессия
Данные сжимаются, их объём уменьшается (если применяется сжатие).
Шифрование
Фрагменты данных шифруются по выбранному алгоритму симметричного шифрования, использующему общий секретный ключ, установленный на этапе рукопожатия.
Аутентификация
Каждый фрагмент данных подписывается цифровой подписью или кодом аутентификации, чтобы соблюсти целостность и подлинность данных.
Передача данных
Зашифрованные и аутентифицированные фрагменты данных передаются по Сети между клиентом и сервером.
Как несложно догадаться, процесс обмена данными с помощью TLS — штука непростая и довольно требовательная к ресурсам компьютера. Но у инженеров и на этот счёт нашёлся выход — механизм возобновления сессий, который помогает срезать углы и пропустить этап рукопожатия.
Что такое механизм возобновления сессий
Чтобы ускорить обмен сообщениями, разработчики добавили в TLS механизм возобновления сессий — 0-RTT (zero round trip time resumption, нулевое время приёма-передачи). Он позволяет клиенту и серверу возобновить сессию, если она почему-то была прервана — например, из-за ошибки сети или бага на стороне сервера.
Работает этот механизм просто: во время обмена данными и клиент, и сервер кэшируют данные о сессии в специальные токены. Если эти токены совпадут, стороны могут пропустить этап рукопожатия и сразу перейти к обмену данными — мол, не нужны мне твои ключи, дорогой, заходи, здесь все свои 🙂
На первый взгляд, выглядит круто — но есть у этого механизма и недостатки:
❌ Недостаточная безопасность. Клиент отправляет зашифрованные данные на сервер, используя предварительно согласованные симметричные ключи. Однако если эти ключи перехватил хакер, то он может вклиниться в сессию.
❌ «Перегрузка» токенами. Если сервер обслуживает сайт с миллионами пользователей, хранить в памяти токены каждой сессии может быть проблематично. К счастью, на этот случай придумали механизм session ticket, который позволяет серверу «не держать всё в себе».
❌ Ограниченные динамические параметры. Динамические параметры — это своего рода условные знаки, которые стороны используют во время сессии, чтобы подтвердить, что они — это всё ещё они. В механизме 0-RTT эти параметры используются реже, чем в обычном режиме.
❌ Задержки в ответах. В рамках сессии 0-RTT клиент отправляет порцию данных на сервер до того, как получит ответ о «доставке» предыдущей. Это может привести к рассинхрону между сервером и клиентом — клиент может отправить несколько запросов до того, как получит ответ на первый.
Защита от атак типа man-in-the-middle
Атака типа man-in-the-middle («человек посередине») — одна из частых угроз безопасности в сетевых коммуникациях. Так называют ситуацию, когда злоумышленник внедряется в коммуникационный канал между клиентом и сервером, перехватывает и модифицирует передаваемые данные.
В TLS есть механизмы для защиты от таких атак:
- Шифрование данных. Самый очевидный пункт: протокол TLS обеспечивает шифрование данных, что делает их непригодными для прослушивания или изменения злоумышленником.
- Аутентификация сервера. Клиент проверяет подлинность сайта при помощи публичного ключа и убеждается, что связывается с нужным сервером, а не с посредником. Если сертификат не проходит проверку или отсутствует, клиент может предупредить о потенциальной атаке.
- Аутентификация клиента. В некоторых случаях, когда требуется двусторонняя аутентификация, клиент предоставляет свой собственный сертификат серверу. Сервер может проверить этот сертификат и убедиться в подлинности клиента.
- Обмен ключами по протоколу Диффи — Хеллмана. Протокол TLS позволяет клиенту и серверу согласовать общий секретный ключ с помощью протокола Диффи — Хеллмана.
- Цифровая подпись. В протоколе TLS используют цифровые подписи для проверки подлинности и целостности передаваемых данных. Цифровая подпись гарантирует, что данные не были изменены в процессе передачи.
Конечно, совершенных средств защиты нет нигде, кроме… ну, может быть, Форт-Нокса или бункера Бэтмена. Атаки типа «человек посередине» периодически случаются даже с таким навороченным протоколом, как TLS, особенно если уделить не слишком много времени его настройке.
Версии TLS: чем различаются и какую использовать
Сейчас самая быстрая и защищённая версия TLS — 1.3. Всё благодаря современным алгоритмам шифрования, отказу от устаревших функций, а также механизму возобновления сессий. В некоторых случаях допускается использование версии 1.2. Всё, что ниже, — рекомендуется применять с большой осторожностью и только для работы с совсем уж архаичными браузерами и приложениями.
Давайте посмотрим, как менялся протокол TLS и какие фишки в нём появлялись от версии к версии.
TLS 1.0 (1999 год)
Что изменилось (по сравнению с SSL 3.0):
- Добавлены новые функции, используемые для генерации ключей и вычисления MAC (message authentication code).
- Изменены форматы сообщений, завершающих рукопожатие (finished messages).
- Появились новые коды ошибок (alerts).
- Добавлена обязательная поддержка протокола Диффи — Хеллмана.
TLS 1.1 (2006 год)
Что изменилось:
- Произведена замена уязвимых алгоритмов хеширования MD5 и SHA-1 на более безопасные, такие как SHA-256.
- Внедрены продвинутые алгоритмы шифрования, такие как AES и Camellia.
- Добавлена защита от атак на паддинг с помощью генерации случайных чисел.
- Улучшена защита от атак с использованием цепочки блоков шифрования (CBC).
TLS 1.2 (2008 год)
Что изменилось:
- Добавлены новые алгоритмы шифрования, такие как AES-GCM (Advanced Encryption Standard — Galois/Counter Mode).
- Улучшена проверка целостности данных и аутентификации.
- Добавлены расширения, позволяющие клиенту и серверу согласовывать поддерживаемые функции и параметры.
TLS 1.3 (2018 год)
Что изменилось:
- Добавлен механизм возобновления сессий RTT (0-RTT), о котором мы подробно рассказывали чуть выше.
- Сократилось время установки соединения благодаря оптимизации протокола рукопожатия.
- Удалены устаревшие и уязвимые функции: алгоритмы шифрования на основе CBC, проверка подписи на основе RSA/DSA и другие.
- У клиента появилась возможность отправлять данные без ожидания подтверждения от сервера.
Уязвимости протокола TLS
Абсолютной защиты данных не существует. Как и у любой технологии, у TLS есть свои уязвимости:
- Атаки на слабые алгоритмы шифрования в старых версиях TLS. Вычислительные мощности сегодняшних компьютеров позволяют относительно легко взломать алгоритмы шифрования, которые какое-то время назад считались неприступными. Используйте современные алгоритмы шифрования.
- Уязвимости в реализации и настройке. Использование сторонних библиотек, попустительское отношение к проверкам сертификатов и обновлениям снижает защиту ваших данных.
- Социальная инженерия и фишинг. Даже с последней корректно настроенной версией TLS не нарушайте правила безопасности в Сети — не переходите по подозрительным ссылкам и не оставляйте конфиденциальные данные там, откуда их могут извлечь злоумышленники.
- Утечка информации и анализ трафика. Использование одних и тех же логина и пароля может скомпрометировать безопасность ваших данных.
- Уязвимости в ОС. Отключённый файрвол и пренебрежение обновлениями операционной системы сделают ваши данные уязвимыми.
Большинство угроз безопасности и сценариев атак, перечисленных выше, остаются актуальными и для TLS 1.3. Однако TLS 1.3 привнёс улучшения и изменения, чтобы справиться с некоторыми из этих угроз и сценариев атак.
- Улучшенная криптография. Современные алгоритмы шифрования и хеширования, которые обеспечивают более надёжную защиту данных и устойчивость к известным атакам.
- Изъятие слабых алгоритмов шифрования, таких как MD5 и SHA-1, для уменьшения рисков, связанных с их использованием.
- Обновлённый процесс установки соединения. В последней версии оптимизировали установку соединения, чтобы сократить обмен сообщениями и улучшить производительность.
- Прямая секретность (forward secrecy). Даже если долгосрочные ключи сервера или клиента скомпрометированы, предыдущие сессии останутся защищёнными.
- Улучшенная защита от атак типа MITM. Четвёртая версия протокола TLS включает ряд изменений для повышения защиты от атак MITM, таких как более строгая проверка сертификатов и использование надёжных алгоритмов аутентификации.
Хотя TLS 1.3 предлагает значительные улучшения в области безопасности, всё равно важно оставаться внимательным к новым угрозам и сценариям атак, которые могут возникнуть в будущем.
Рекомендации: как обеспечить безопасность TLS
Напоследок — несколько советов для сетевиков и администраторов сайтов о том, как правильно использовать протокол TLS, чтобы добиться максимальной безопасности своих ресурсов: