TLS 1.3: Co nowego?

Hello everyone, my name is Miłosz Kaniewski I am a programmer, I work in the company Wheel Systems I deal with products that use TLS and I would like to tell you about TLS today In particular about the upcoming big steps of the new version of TLS number 1.3 First, a few words about what TLS is. In short, it is a security protocol that provides us with the following things: First, it provides us with the trust of the transmission. It is about making sure that no one can see the data that we send through the communication channel. Second, it provides us with the credibility. So, TLS guarantees us that the person we are connecting with is actually the person who is

being given the last thing is integrality, i.e. TLS guarantees us that the data we send and the data we receive will not be modified in any way so what we actually receive is what the sender wanted to send us you probably know TLS from the HTTPS protocol, i.e. the HTTP protocol which is used under the TLS. In short, TLS is this green pad. A few information about how the development of TLS has been going so far. TLS was created in the 90s by Nescape for the needs of their reviewers. The first version was released in 1995, it's a pretty old version 2.0, then in 1996 there was a version 3.0, then it was called SSL, and only in 1999

there was something called TLS 1.0. This change in name is because TLS is the first version of IETF, which is the organization that publishes all RFCs. So TLS is the first general standard. SSL is a standard created by one company. As a curiosity I can say that a company that is responsible for changing its name. This is a bit problematic. We use both terms to this day. The question is often asked: what is SSL different from TLS? Apparently, the company responsible for changing its name was Microsoft, which was competing with Netscape at the time. And he decided that he doesn't want it to be called SSL any longer. that we need to change the name. Because TLS 1.0 did not

differ from SSL 3.0 in principle. These protocols were similar. SSL development was also important, at least that's how it can be found in many sources, because it allowed for e-commerce market development. It allowed for online trading. Previously, there was no way to do it safely, and TLS gave us such a possibility. However, my memories are a little different, and I think it wasn't as beautiful as it was. I mean, introducing a salabue, However, many years later, many things on the Internet were not done using the HTTPS protocol, but were done using the usual HTTP. You may remember that until recently, often on various login forms, logging on SSL was an option, an addition, but we were

logging on HTTP on purpose. I will use the term TLS, at least I will try to do it in the next part of this presentation. In fact, TLS has been a very common protocol for a long time. It seems that we have already come out of the stage when our problem was that TLS was not used. Now our problems are somewhere else, because TLS is used everywhere. This also results in the fact that if there are any problems in TLS, they affect many services. This graph on the bottom shows the TLS version again, when they were issued. On the above chart, there are selected attacks on the taxable assets that were detected in TLS. As you can

see, there is some thickening in the last years. The last years were difficult for TLS. there were a lot of different attacks. These attacks, of course, did not apply to the whole TLS as a protocol. Many of these attacks, many of these vulnerabilities were related to, for example, the bad implementation of TLS. And also some of these attacks were related to the fact that the cryptographic bases on which TLS is based, the encryption, the shortcut function, what we call and cryptographic primitives. There were also vulnerabilities in them. And it's not the fault of TLS anymore, that the cryptography used in it, with time, turned out to be not completely safe. Therefore, TLS must continue to

develop. It has to develop in order to react to the vulnerabilities that are discovered in it. That's why in a short time a new version of TLS should appear. TLS 1.3, perhaps. More on that in a moment. What are the basic goals for creating a new version of TLS? These are the goals that would appear in every version of TLS, but it is worth mentioning them. First of all, we would like to make TLS in the new version simpler. Until now, every new version of TLS added new things. And with each new version of TLS we had a greater complexity of this protocol. In the case of the new version, the creators assumed that it would be worth to make TLS thinner. It would be

worth to simplify it. First of all, because a simpler protocol is easier to analyze, it has fewer possible vulnerabilities and therefore it should be safer. Very often, when reading mailing lists of people who are involved in the development of TLS, you can find various forms of formulating: "Let's make it easier", "Let's simplify it", "Let's throw out a lot of things". At some point, TLS was also attached to a framework as a free protocol. A protocol that is heavily burdening. um... Tom What is the burden resulting from TLS? It can be divided into two categories. The first is the burden that comes from cryptography, which must be performed. And this is mainly a hardware burden. However, in this aspect, a lot has changed in recent

times. Many things are supported now in terms of hardware, when it comes to cryptographic operations. And it seems that the burden Hardware is not as a problem as it was before. However, there is still a burden on the network level. That is, there is time needed to set a TLS session. And this time is not short. And here the creators of the new version also set a goal for themselves: simplifying the network aspect of TLS in such a way that it would work faster.

And of course, what is in the TLS from the very beginning, it is supposed to be safe, and that is the most important goal. Here, too, a lot is related to simplifying this new version of the protocol, because a lot of things have been thrown away. A lot of things that we knew were already completely unsafe or we assume that in a short time they will become unsafe. These things will not be in the new version of TLS. In theory, everything, especially when it comes to cryptography, which will be in the new version of TLS, there should be things that we consider completely safe.

A few words about how the development of such a protocol looks like and how it looks from the technical side that a new protocol is being created. As I said, the IETF organization is responsible for TLS. This is an organization that is responsible for the development of the Internet in short. They do a lot. This is an interesting organization. It is very informal. I mean, there is some There is a secretariat, which manages it, but it is a few people. However, the whole of this organization, how it works, is based primarily on authorities. There are simply working groups, in which there are people, whom one trusts, who have experience, have this authority and they control the work of these groups. And the same is

the case of TLS. There is simply a group of people, which created previous versions, which works. in the TLS environment and these people are the ones who direct all this development. Work on TLS 1.3 started in 2014. They are being extended, no one has said how long it will last, but initial assumptions were that in 2015 the protocol will be ready. The year 2016 is coming and we still don't know when the new version of TLS will be. What's interesting, the development of the protocol itself This is called a draft, which will later be translated into full-fledged RFC, but it is on GitHub. All changes are fully visible. Generally, the whole process is very transparent.

The main development takes place either on mailing lists or on the e-mail. These lists are available, of course. Everyone can sign up, everyone can take a vote. In addition, there are also regular meetings. They are well documented, there are video recordings, there are notes, so everything is absolutely obvious. Currently we have draft number 17, it was shown a few days ago. The assumption is that this will be the last draft. And one more thing, I'm talking about TLS 1.3, because so far everyone has been talking about TLS 1.3. However, some time ago there was a proposal to name this new version of TLS 2.0, because changes in the protocol are fundamental, which I hope I will show in the next part.

And it seems that there is some consensus and that this TLS will be marked as 2.0. One more thing I would like to point out at the beginning is that we don't have the full protocol ready yet. It is still developing. Changes are still possible, so everything I say today may turn out to be completely different tomorrow. It shouldn't be like that, but please keep that in mind. If someone watches this video in a year, it is worth making sure that the information provided here is up to date. As I said, the creators decided to throw away a lot of things from TLS. To simplify it and throw away what is known to be dangerous. The

first thing that has been in TLS for a long time is the use of the RSA algorithm to exchange the key. RSA is used in TLS so far, in versions 1 and 2, for two uses. The first is key exchange. This is the magic of the public key, which allows two parties to exchange the key, so that no one listening to the connection is not able to know the key that the transmission is encrypted with. The second application is signature of RSA packages. It can be used to create signatures. The second application is better known to us, because this is what we use RSA certificates for. Most of us probably needed such certificate for HTTPS and nothing changes in this case. Such certificate will

be important, but the new protocol will not change anything. However, the first use of RSA, i.e. key exchange, will not be available anymore. Instead of RSA, Diffie-Hellman will be used. Why do we give up RSA? Because RSA does not offer us a functionality called Forward Secrecy. This functionality is based on the fact that for every TLS connection, there is a session key that is not associated with RSA certificate. The problem with RSA is that We use RSA key exchange algorithm and someone records our traffic, traffic from our server or traffic from our customer base and let's say that in a year, he will record this traffic and in a year he will be able to steal private key of RSA certificate which was on the server,

then he will be able to decrypt the whole communication which was going on for a year. However, newer algorithms, the ones that will be used now, for example Diffie-Hellman, guarantee us that the key is unique for each session. Therefore, even if someone steals a certificate and a private key, they won't be able to use it to decode the back-recorded communication. However, the removal of the RS RSA was always used as a key exchange algorithm. There are some problems with it. Firstly, it will not be possible to decrypt a copy of encrypted traffic. In most companies, they use solutions that are based on the fact that HTTPS traffic is decrypted so that you can look at the

traffic generated by the employees of the company, so that you can look at this traffic and see, for example, if there is no malware or if some data is not leaked in this way. Some of these devices are based on copy of the traffic. We just send them a copy of the traffic. And these devices could only work if RSA was used to exchange the key. Because we just entered a private key of RSA certificate into such a device and we could decrypt this traffic. Now we won't be able to do that. One alternative will be devices for decryption that work on the "man in the middle" principle. So they are not based on a copy of the traffic but on live traffic The

second problem that may arise is the debugging, traffic analysis Sometimes it is useful if we want to, for example, we have our own protocol that is packed in TLS and there are some problems with it and we would like to catch this movement in a certain part of the network and look at it. But of course we want to look at what is already above the TLS, i.e. this movement from our protocol. It will be a bit complicated. So far we could do something like this. Wireshark has been able to insert private key of RSA for a long time. So if communication was done using RSA key exchange algorithm, then we could insert a dump in Wireshark, insert

private key of RSA certificate and we could see encrypted transmission. Fortunately, there is an alternative for other algorithms, for example, Diffie-Hellman. Since some time This is the NSS library used by Firefox and Chrome, so the most popular browsers. It is possible to run these browsers in such a way that they will throw the session key into the text file, i.e. the key that is already used to encrypt the session. It will be different for each connection. However, having this key, They are saved in plain text form. Having this key, you can also add it to Wireshark. And this way you can access this type of TLS session and decrypt it. However, it is a bit more difficult, because we have to select the

customer's station, start, for example, a browser in this way. It's worse if it's not a browser, but it's even written by our program. Then we'll have to get to this session key ourselves. I think so. I don't know exactly how the environment in Windows works, but I think I saw an example for Windows. The question is whether it requires the administrator to be licensed. I don't know how on Windows. I had no problems with Linux, the browser was normally throwing away the things, I didn't have to run it with any special regulations. I don't think it requires it, because it's the app itself. It holds the key, so it depends on the app whether it wants to throw it away. Yes, but the question was probably

about Windows, since we are talking about administrators.

What else disappears from the new TLS? The RC4 encryption algorithm disappears, which is now considered to be not entirely safe. The CBC mode disappears. the mode in which symmetric algorithms encrypt further data blocks and this mode turned out to be not entirely safe. There were a few attacks in recent times that used the vulnerabilities in this mode. The function of the shayaden md5 shortcut disappears, which is no longer considered completely safe. I mean, shayaden is still safe, but with a lot of computing power In theory, it is possible that it will soon be broken. That's why the creators of TLS are trying to move forward. Even if something is still relatively safe, we don't want such things in the new

protocol. We want to have what is completely safe. These are differences in terms of TLS 1.2, which is the most popular one at the moment. Negotiation is no longer possible. It was a feature in the previous versions of TLS. During the transmission, you could request to generate a new key for the session. This will no longer be possible. You will simply have to create a completely new session. Compression is also no longer possible. The main argument was that we simply don't know how to make a safe compression. The compression was added in one of the previous versions of TLS and it turned out to be very problematic and is now not used at all. To understand what the changes in the new

TLS are about, we must understand how the TLS handshake works in the previous one. Handshake is a basic operation that takes place in TLS. It is an operation that allows two parties to communicate about what encryption will be used, about which version of TLS we want to use and about setting the key, i.e. what is the most important, the key to which the further transmission will be encrypted. In TLS 1 and 2, the client initiates the connection, sends the client hello package, the server responds to this package with the server hello package, it also returns its certificate and returns their own part of the key. To put it simply, if we are talking about Diffie-Hellman, it works

in such a way that one side sends its own half of the key, the other side sends its own half of the key, and each of the pages on the basis of these two halves is able to generate a key for the session, but no one on the other side is able to do it. So, the server sends the certificate, sends its half of the key, then the client sends its half of the key and finally sends the finished package. The finished package is a summary. There is, among other things, a summary of all the existing packages. which took part in handshake and it is also the first package that is encrypted with a set session key because only at this point the client is able to generate this

session key. He has a half that he got from the server, he has his half, so at this point he can start a encrypted transmission. Then you need to confirm from the server, which also sends its encrypted finished package. And at this point, the actual data transmission can start. The client can send a request, for example, HTTP. Now, what changes in TLS 1.3? So, the question arose: can this model from TLS 1.2 be simplified somehow? It can be simplified. We can simply put the half of Diffie Hellman in the first package that the client sends. We don't have to wait any longer. And in this way, after receiving this half and generating its half, the server can immediately start

the encrypted connection. What is on the red is encrypted. Therefore, the whole process is significantly simplified, because it is not divided into so many stages. And what is the main profit here? The profit is that we have half less packages that we have to send. In TLS 1 and 2 we had to send 4 packages to all the pages, so round time trip was 2 We had to do the same thing twice. In TLS 1 and 3 it's half. We will have handshake that needs only one round time trip. And this is a big profit, of course. This is a big profit for servers, especially for those who serve a large amount of data. These are valuable milliseconds

that we just gain here and we don't lose anything. And as a bonus, we get the fact that the certificate is encrypted. In TLS 1 and 2, the first encrypted package was finished. So everything that was previously was public. Which can also create some problems. We want to encrypt as much as possible. And TLS 1.3 will allow us to do this. A very small part of handshakes will be encrypted, will be sent in public. Okay, but in TLS 1.2 there was also such a functionality as resuming the session. The idea is that the client joins us for the first time. We perform all these expensive cryptographic operations, we send all these packages, 4 packages are sent, double

round time trip. However, the question is whether we must perform this time-consuming operation with each next connection. Perhaps there is no such need. And indeed, we can assume that The key that we negotiate with the first connection will also be used with the next connections. This is how resumption worked in TELES 1.2. At the first connection, the client received an ID from the server and then he could use this ID at the next connection. He simply sent this ID, the server had the status of the previous connection saved, i.e. the session key was saved, which was previously negotiated. And thanks to that there was no need to change the key again, there was no need to change the halves of

Diffie-Hellman. Therefore, we managed to obtain simplified model, which again gave us roundtrip in the form of... we could create a connection by doing only one roundtrip. Ok, so if in TLS 1 and 2 we had a double round-trip, in the case of rescheduling the session we had a single round-trip, then if in TLS 1 and 3 the default round-trip is 1, then what will be the round-trip in the case when we also decide to reschedule the session in TLS 1 and 3? we get a very interesting solution, namely Zero-Round-Train-Trip. This means that we can send the data we actually want to send without having to perform any previous operations. Just like in TELES 1 and 2, the client can have some ID,

a recorded ID of the session and during the next connection, it sends this ID to the target server, but in addition, in the same package, it already sends data to the target server. What it actually wants to do, for example, HTTP request. This requires the client to have the session key that was previously negotiated in his own account. He uses this session key from the previous session to encrypt the data he wants to send to the server. The server also contains the server sees such a package, sees the ID that it has saved, finds the key that was previously saved for this ID, is able to decrypt such a message right away, is able to immediately serve the client's request and immediately

respond. So here, in fact, apart from the costs of some kind of charge, these packages are, let's say, are bigger, because we still have to send client hello, server hello, server must answer, server hello, then we don't lose any round-trip, to wait until we can send a request to the server. And I think it can be very useful. However, -

I have a question, are the data from the client in the interface encrypted with the old key? Yes, it is a special key that, at the first connection, the server generates a special key that it sends to the client and tells the client: "Listen, if you want to use this 0RTT next time, you can use this key." However, this key is used only to send this first package. As you can see, in this client.hello, half of Diffie Hellman is also being sent, which will be used again to generate a new key for the session. All subsequent packages will be encrypted with a unique key for this session. However, there is a problem with this because the first

package is not secured by forward secrecy. If we use this key several times, then if someone has this key, they will be able to decrypt the few requests that have been sent in this way. So it collides with the idea that everything should be forward secrecy Unfortunately, we are not able to get this functionality in this case But it is better than TLS 1 and 2 If we used session refresh, then the key there which was saved, was used for the whole session. It wasn't like here, where half of Diffie-Hellman was mentioned and only the first package was encrypted this way. The whole communication was encrypted with this key. Yes, I'm listening. Is there any possibility of a specific package being sent

during the session to avoid sending any reliable data? Just because there is no forward secrecy here. It's hard to say from the application level and it's also hard to say what kind of implementation of this new TLS is I guess that the programmer will have the possibility to influence it whether he will want these data to be sent in this way so that they are sent when using this 0RTT mode because it is an opt-in it will not be default, it will be a function that you can use But still, the default action will be the handshake I've shown before, the one-RTT, one-round-time-trip. So the first problem is the lack of forward secrecy. The second problem

is the repeated attacks. It will be difficult to ensure that someone will not send, will not repeat such a request. There is no good solution to this problem. And here it will probably work in such a way that we will use this zero RTT only if we have to send We will have to be aware that if someone resists, they will be able to repeat the operation. For example, making a GET from the www page should not be a problem. The fact that someone will repeat it should not pose any threat. However, making a post, modifying something using this data, using this 0RTT mode is problematic. Someone gave an example that in such a package there will be information about a transfer to

Miłosz for an account of 50 PLN and then I will be able to break in between this traffic, intercept this package and then repeat this package 100 times. If I do it in a tricky way, the server will not be able to confirm that the next requests for 50 PLN are repetitions of the previous request and in this way it will be possible to use it So we will see how this feature will work in practice. However, I think it is interesting that the claim made by TLS in theory will be simplified. It will be zero. I have a question. This is a very interesting aspect, since already at the stage of the IETF group, such problems are noticed, then why is

the implementation or use of this option in TLS 1.3 considered further? Because it's a bit of a shock to me, again, the conspiracy theory that NSA may try to introduce something on the side that they already have a solution for. I would look at it more like that, that the creators of TLS realize that TLS will be everywhere soon, HTTPS will be everywhere and this is some kind of a relief attempt. They just came up with something like that. There are some scenarios where it seems that using it is safe. However, I agree that it imposes a certain responsibility on the programmer, who, using it, if he does it wrong, will actually be able to harm himself or others. I think this matter

will be discussed, but as I said, it is optional. We'll see. But in fact it is controversial, maybe that's how you could call it. Although I would rather say that it is innovative. And finally, any questions? I think that the solution would be to add a nonce in the first message and then check on the other side if the nonce has appeared. If it was a regular counter, it would be a problem for later verification of the message that comes if the session is repeated simultaneously by several different numbers. through several connections in different threads. Then there could be a problem with the race condition. But if the nose was stored in a map, or

in a set, it would be difficult to implement it. There would be a lot of remakes and memory would be lost. But it can be limited. I think there are some mitigations, maybe just for the first glance, not for a deeper analysis of this problem, I think that some mitigations could be possible. I guess there are some, but I also guess that there were some reasons for which, at least for now, This problem is still there. I think it's quite complicated, I didn't go into it in detail. I refer you to mailing lists, there's a lot of discussion going on there and I think there's a lot of interesting things there to find.

As for the current state of implementation of TLS 1.3, as I said, it is not ready, so what is implemented is the drafts that are currently being implemented. There are versions of Firefox and Chrome that support TLS 1.3. When it comes to libraries, there is NSS library, Boring SSL, there is also a library specially created by Mint, which implements TLS 1.3. However, generally it is very difficult to test something. They implement different versions of these drafts. It took me a lot of time before I managed to create any TLS 1.3 connection that I managed to create. So if someone would like to play, I think it's worth waiting a bit longer. It's worth waiting until the protocol is ready, everyone will know what to implement. Then I

encourage you to do it. As for interesting things, Cloudflare, which is responsible for 30% of HTTPS traffic, has already turned on its version of TLS 1.3 on its servers. which is very cool, because if we have this protocol ready, a large part of the Internet will be available right away. Thank you very much. Maybe someone has any questions? I have a question, because I will use the fact that I have a microphone. Do you realize what the discussions on the ITF labor group website looked like? while designing TLS A1-3, in connection with the use of elliptical curve cryptography. I will remind you that last year the American Institute of Standards NIST issued a recommendation not to use such

cryptography, to stop using it. This caused a lot of discussion in the cryptographic world. Did this type of discussion also lead to the design of 1.3? I know that in 1.3 there were curves that were not NIST-like. There is a group of NIST curves and in previous versions of Telesa there were probably only those. However, now there are also other curves that are not from NIST. That's all I know about it.