Get best of the week

An Introduction to TLS for Patrik Patrick (Part 1)

As you may already know, this is Patrick. He is a starfish, which means that it is possible, without insulting him, to say that his hands are growing from one place. Patrick is also very practical and immediately forgets everything that he does not need - but if he needs something, he wants to know it (because he needs it!). Spoiler: here Patrick is trying to do a TLS Handshake.



This article is written for Patrick and people like him. She was born from a presentation first shown at our internal educational Plesk TechTalk, where employees in an accessible form share information with each other about interesting technologies, processes and solutions. Therefore, the pictures in this article will look like slides :) The author of the original text of the report is program manager Plesk Ruslan Kosolapov .

Typically, all TLS material covers some small aspect, but not the big picture. This is not very practical and Patrick has a headache from this. Everything will be different here: briefly, applicable “in everyday life” and as exhaustively as possible.

What is TLS and why is it to Patrick


TLS (Transport Layer Security) is a transport layer protection protocol. It is needed so that no one can "listen" to you and find out some important information (most often passwords, if we talk about working on the network). And also in order to protect themselves from falsification and traffic modification during transmission. It is in these two things that the purpose of TLS lies.

For clarity, let's consider TLS handshake as a call to Patrick SpongeBob. During a call, someone can eavesdrop on the conversation (standing next to Patrick or turning on in the middle of the line), and generally the Sponge Bob may not be on the other end - all these problems are relevant. And to solve them, Patrick wants to use TLS.

In short, the top-level handshake looks like this:

Patrick: I want to use TLS, the cipher versions are such and such.
Spongebob: Ok, let's use cipher versions such and such.

After that, SpongeBob sends the certificate, Patrick checks it, says that everything is fine, the session key is done (there are actually two of them, but it doesn’t matter). Why use a session key rather than asymmetric encryption - because it's faster. After that, they begin to speak a language incomprehensible to decryption. Thus, everything is protected.

Everything seems to be simple. How it works on hardware is not so important for us. But if you start to think - and Patrick begins to think! - that begs the question of how to generally agree that we will use TLS? After all, once there was no TLS, but there were only ordinary protocols - SMTP, HTTP. How to say what is needed on TLS? And here in our industry everything is as usual - there are many ways!

At first they wanted to use a specific port, which would imply the use of TLS on it. What are the disadvantages of this? And why then did the explicit (explicit) method for starting a TLS session appear? There are several reasons:

  1. You need a lot of ports - and ports are such a thing that you don’t want to spend. Because the more there are, the more difficult it is to configure the firewall.
  2. The server can ignore this - it has connected to port 443, and there is no TLS there, only HTTP without any HTTPS.
  3. Before the connection is established, you cannot find out if the TLS server is supported or not.

All this led to the emergence of an explicit method - when we connect to a regular port, and then upgrade our session to TLS. For different services, the protocol has different commands, for example, for SMTP there is a separate command at the level of the SMTP protocol - STARTTLS . HTTP also has such a joke, it is called Upgrade: TLS / 1.0 . At the protocol level, it is easier to understand whether a TLS server is supported or not.

Let us dwell a little more on the different types of connections and how things are with TLS for them.

Connect: HTTP


Everything would be easy if, as always, there were no nuances. In the case of HTTP, the growing security requirements provide a constant evolution of the process of working with TLS. At first there was a redirect to HTTPS, and this was done simply in the header. This left a loophole for vulnerabilities, so fellow Google came up with HSTS (HTTP Strict Transport Security). This is such a heading in the HTTP response that tells the browser: “please remember that when you come to this domain, go directly to HTTPS, even if the person told you to go to HTTP”. Thus, there is no redirect and everything happens much safer. In addition, Google has another initiative - you can leave a request so that your site is added to the list for Google Chrome “Always use HTTPS”, regardless of any headings.

Briefly: HSTS solves the redirect from HTTP to HTTPS vulnerabilities, so almost all browsers support HSTS, which is good.

Connect: exotic (new versions of HTTP and not only)


In HTTP / 2, things are good with TLS: it is always used (as browsers are now made). In addition, TLS in HTTP / 2 must be fresh - that is, have version 1.2+.

Most likely, very soon Google will sell the widespread use of HTTP / 3, now it is adopted by the IANA standard. The story of its appearance and development is rather confusing; The main thing to remember Patrick:

  • HTTP / 3 is always TLS 1.3+.
  • HTTP / 3 is based on QUIC - it is such a protocol over UDP, which, according to Google, is better than TCP. Actually, before the name HTTP / 3 was finally approved, the protocol was called HTTP-over-QUIC.

There is still an interesting SCTP protocol, which is used mainly in telecom. Above it, both TLS and DTLS are used (this is such TLS for UDP).

Briefly: in 2 years, QUIC (i.e. HTTP / 3) will be used everywhere, but now there should already be HTTP / 2 everywhere, but in reality it is not everywhere.

Connect: Mail


Many clients believe that there should be TLS on the 587th port, but there are also nuances here: someone expects TLS by default, and someone expects an explicit STARTTLS request from the client. Because of this, various combinations of mail server and mail client sometimes cause unwanted effects. For example, a client enters port 587, expecting that there will be TLS, while the server waits for the client to explicitly request STARTTLS . Having received nothing, the client rolls back to port 25. The result is a silent switch to an insecure SMTP connection. When testing and developing, it is worth remembering about such effects of client-server combinations. Autodiscaver has various options for specifying TLS: how it should be, what is expected, and what to do. Many mail clients understand these things.

Briefly: with TLS support in mail servers and mail clients everything is fine in general, but in particular cases there may be problems and TLS extensions are not very well supported.

Connect: FTP


Little can be said here. The main problem is SNI (this is when different domains are on the same IP). At the FTP level, the domain name is not transferred. In an explicit version, it cannot work, because there is nowhere to write it. There are several solution options - some offer so, others so, a general solution has not yet been adopted, there is no standard.

Briefly: there is some kind of TLS support for FTP (FTPS, SFTP - an analogue of FTP implemented through SSH), but some aspects are not covered due to the technical limitations of FTP itself.

TLS Handshake


So, now we know how to initiate communication using TLS in different connections, and Patrick was able to communicate his desire to SpongeBob. Once they have agreed that they will use TLS, TLS Handshake is produced. Its result should be an agreement between the client and server on how they encrypt it all. In addition, the client must make sure that the server is the one that is needed. Sometimes the server also checks the client (but much less frequently).

Ciphers and Versions


As already mentioned, the first step is to choose which version of TLS and which ciphers will be used for encryption. Typically, a cipher looks like this:



A set of ciphers is in the IANA registry, and in the TLS protocol in binary form is only its ID. As you can see in the figure, here is not just (and not only) the cipher, but also its operating mode and other details necessary for TLS-handshake. Patrick does not need to go into details. All that is important at this stage is to remember that these letters are good (and the rest are bad):

  • DHE
  • ECDhe
  • AES128
  • AES256
  • RSA
  • Ecdsa
  • Cbc
  • Gcm
  • SHA256
  • SHA383
  • CHACHA20
  • POLY1308

Picture for remembering good ciphers:



If it's hard to remember, there are good services that can tell you about it, for example, a service from Mozilla ssl-config.mozilla.org .



You can immediately see where and how it is supported - this is what the Mozilla guys are trying to follow.

An interesting detail: the client transfers the ciphers in order of priority according to their preferences, but the decision is up to the server - it selects the cipher that it seems to be the best from the list of supported by the client.

Both sides also indicate the maximum supported version of the protocol - in this case, Patrick is more advanced than SpongeBob.

Actually certificate


Together with the answer “Let's do it like this”, the server sends its certificate or certificates - there can be many of them.

What is a certificate? This is a relationship of information (subject) - most often it is the name of a domain or organization - and a public key (public key). That is, the certificate says: “Dude, my public key is like that. Now, with his help, we will agree on session keys. ” Also, with its help, you can check the signature of certificates or something else. That is, in principle, it would be possible to use not certificates, but registries where this relationship is indicated. And in fact, steps in this direction are continuing, because the Certificate Authority mechanism is considered not very good, there is simply nothing else.

Thus, the certificate is the structure of 'Subject: Public key' plus the signature of the ishyuer (issuer in transliteration into Russian looks awful, but the closest synonym here is not very close in context to the “issuer”) that this certificate was issued. Ishüyer also has a certificate and someone’s connection with something. You can check the certificate for correctness by taking the public key of the ishyuere and checking the signature. As a result, nothing can be faked here.

Let's go over the certificate and see what problems it might have.



Firstly, the serial Number implies uniqueness only within the limits of the ishyuere, although some software considers that it is unique in the whole universe. Fortunately, more often than not, it is truly completely unique.

The certificate also indicates which algorithms are used for encryption and signing: RSA or ECDSA - that is, which cryptography to use to work with this public key. The main difference between RSA and ECDSA is that the mathematical principle of ECDSA is based on elliptic curves, and RSA is just on natural numbers, so it is slower and huge keys bits (3-4 thousand) are used to prevent cracking it . And for ECDSA, a 300-bit key is enough and it works faster. Therefore, many are switching to ECDSA - the handshake itself is heavy and I want to reduce it. ECDSA can be asked for when issuing a certificate, and if the prospector supports it, he will do it for you. But the signature of the certificate depends on what private key ishuiur currently has, and not on whether you asked for ECDSA or RSA.Therefore, browsers can show that one is in the signature and the other in the public key, and there is no need to be afraid if the signature is not ECDSA.

How to get a certificate?


In short - like this:

Patrick tells the Certificate Authority: I need a certificate. This person (or organization) checks to see if it is Patrick. Checks can be very different. Of course, Patrick as a client may not have a certificate, but if the server does not have a certificate, then there will be no TLS. It is checked whether everything is correctly indicated in the certificate application, whether Patrick really owns the subject for which he is requesting a certificate. This is done by higher Certificate Authority centers - conditional people whom everyone believes. To issue a certificate, you need to draw up a CSR (Certificate signing request, a request for a certificate).



This is also a structure, which is quite difficult to work with, because there are few services that allow you to set, specify, verify and see everything.

Total, we generate a pair of public key: private key, but we give only the public, and hide the private. Then we generate a Certificate Signing Request and sign it with our private key. We send all this to the certification authority, and it starts the verification. It can be different, for especially cool certificates there are special tricky procedures, but we will dwell on the general case.

CAA RR



There is such a problem that people whom everyone believes are sometimes not very good. One of the reasons Symantec has become part of DigiCert is because it (Symantec) issued certificates without asking domain owners. You can’t do this, it was insulting to everyone, but most of all to Symantec itself, because you had to sell your business. To make the server less dependent on such unscrupulous comrades, there is such a thing as CAA RR - a record in DNS, where it says who the owner allows to issue certificates for his domain. This feature is also in Plesk, it is used little so far, approximately like DNSSec, but nonetheless. All certification authorities agreed to check this entry and if it says that this certification authority cannot be issued, it will say: “you did not pass validation, it’s written in CAA RR,that I can’t write out a certificate for you ”- and will not write it out. If there is no entry, then you can. Now Google is pushing the initiative so that customers check the certificate they received for compliance with CAA RR records. The debate is still ongoing.

Also, CAA RR from the moment we made their support in Plesk expanded by indicating validation methods (that is, you can also indicate here by which method you validate that this domain is yours) and Account URI (Uniform Resource Identifier). Popular among users Plesk Let's Encrypt already supports all this (well done!).

All this works for any type of certificate, and since we will talk about the differences later, it's time to talk about the types in more detail.

Certificate Types


There are three of them:

Domain validation


The subject is a domain, that is, here we check only it. Previously, when there were no automatic validators, validation took place mainly by e-mail through the Whois service. This was considered sufficient reason to believe that you are the owner of this domain. Then they thought up checking through DNS - they wrote to you by e-mail: “and add such and such a record to DNS”. Later automatic methods appeared (we will talk about ACME a little further).

Organization validation


In the “subject” field, in addition to the domain name, the name of the organization is also indicated. The check consists in validating whether the domain belongs to this organization and whether the person who came for the certificate works there. How this is done: they look for organizations on the registers, call, ask for something to be done (the phone turned out to be correct, the right person answered, which means that most likely everything is fine).

Extended validation


Same as OV, only cooler. Everything is very regulated here - a 40-page document in the spirit of "in paragraph 5.6.8 should be the following: ...", etc. A lot of things are checked - the country, the department (if indicated in the application), and sometimes a special person even leaves to see with his eyes. What is the practical difference? Almost all browsers have ceased to distinguish between OV and DV, and this is bad, because in this case the name of the organization is not displayed. As a result, no one bothers to create a domain aliepxress.ru, draw the same page and steal credit cards. And it will be absolutely legitimate to create any such domain and get a DV certificate on it.

Example with EV - the name of the organization is visible here, so if anyone steals something, the user will know that it was Valve Corp corporation, and registering the corporation is somewhat more difficult than the domain (more checks).



However, everything goes to the point where EV will cease to be different, on mobile devices it is no longer visible and you need to press a separate button, and in Safari too. Google Chrome is still holding (UPD - no longer! I had to make a screen from IE). The argumentation of those who do not show: “if you are worried, click and look,” but no one naturally presses.

Obtaining a Certificate: Automation


Now let's talk about the automated receipt of DV certificates. For clarity, let's see how our favorite Let's Encrypt does it. He generally has good documentation, if anyone is interested, and even in Russian.

ACME


ACME (Automatic Certificate Management Environment) is a protocol designed to automate and standardize the process of obtaining a certificate.

How does ACME prove you are a domain owner? You say: I want a certificate and indicate the type of automatic validation - for example, ACME HTTP-01. Let's Encrypt asks you to put the data in a file, and if you could put the files on your domain (and Let's Encrypt could pick them up from there via HTTP), you are probably its owner. Now this approach is criticized, including from Google, because it does not protect against phishing. That is, with manual validation, the aliepxress.ru domain is likely to arouse suspicion, but Let's Encrypt itself so far does not know how (or it can, but badly).

DNS challenge


In addition to ACME, there is also a DNS challenge. For example, they tell you: enter a txt record in your DNS zone, put the data in it. There are other ways, but not common, and one was canceled altogether, because it turned out to be vulnerable. What we have in Plesk: wildcard certificates (which can only be written out using the DNS challenge) do not work for many people, because very often Plesk does not manage the domain’s DNS zones and extension Let's Encrypt cannot automate the creation of a record in the DNS zone .

Two more words about Let's Encrypt


An important aspect in working with Let's Encrypt certificates is limits. In case of doubt (or suspicion that they have been achieved), it is best to follow the link: letsencrypt.org/docs/rate-limits

Sometimes they are updated. There are unobvious limits that people forget about: most often, judging by requests for support, they are faced with a limit of 100 domain names in the certificate. Let's Encrypt also has a staging server and there are more limits, but such certificates are considered non-trusted and for the browser they are similar to self-signed. In practice, with a limit of 100 names, they rarely come to us (despite the fact that sites on Plesk have a total of 1,300,000 Let's Encrypt certificates). Median, according to our statistics, is 20 names per certificate. So if something doesn’t work, look - maybe the limit is reached. Let's Encrypt has good error reporting, and you can usually understand what happened.

What's next?


So, after the certificate is received, the server transmits the session key data - this is what will be used for encryption. If the server considers that it is necessary to authenticate the client (for example, access is open only to a certain circle of persons), he may ask: the client, who are you? And then the client will need to send his certificate. After receiving the ServerHelloDone message , the client realizes that it is time to verify the certificates and work with the keys.

Everything that we talked about, before TLS 1.3 goes through an open channel, and anyone can see all these things. There are several interesting attacks that you can read about yourself.
In the second series of the article, we will learn how the client verifies the certificate.

More articles:


All Articles