Playback: a TLS 1.3 story
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Number of Parts | 322 | |
| Author | ||
| License | CC Attribution 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor. | |
| Identifiers | 10.5446/39671 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
00:00
Transport Layer SecurityAlgebraRevision controlPresentation of a groupInformation securityMusical ensembleCommunications protocolRoundness (object)Fitness functionMultiplication signLatent heatTransport Layer Security
00:40
Transport Layer SecurityMusical ensembleObservational studyVector potentialMiniDiscContext awarenessMultiplication signType theoryView (database)
01:09
Transport Layer SecurityMathematical analysisFormal grammarInformation securityCommunications protocolMathematical analysisApproximationVideo gameImplementationInformationMathematicsOrder (biology)SoftwareTelecommunicationData compressionInformation technology consultingWindowSoftware testingPhysical lawState of matterForm (programming)3 (number)Group actionComplex (psychology)Projective planeVirtual machineHydraulic jumpLink (knot theory)Tape driveRevision controlGoodness of fitServer (computing)Perfect groupPresentation of a groupAsynchronous Transfer ModeField (computer science)Information securityGraphical user interfacePoint (geometry)CuboidCommunications protocolWordData conversionFocus (optics)Scripting languageFrame problemTraffic reportingView (database)Mixed realityWebsiteComputing platformSymbol tableCycle (graph theory)Multiplication signAnnihilator (ring theory)PRINCE2Default (computer science)Software developer1 (number)IterationBitSeries (mathematics)Formal grammarEncryptionLatent heatKey (cryptography)Transport Layer Security
06:11
MathematicsOrder (biology)Combinational logicPhase transitionInternetworkingWater vaporPerfect groupMiniDiscMessage passing
06:57
Type theoryTransport Layer SecurityWeb browserDirect numerical simulationImplementationTouch typingGroup actionIntelPlanningSpecial unitary groupDiscounts and allowancesWeb browserExpressionMixed realityComputing platformRoyal NavyMultiplication signDefault (computer science)FacebookBitRevision controlGraphical user interfaceTransport Layer Security
08:11
Transport Layer SecurityCryptographyMathematicsSoftwareTelecommunicationComputer configurationLine (geometry)Server (computing)Water vaporComplete metric spaceWaveSpecial unitary groupCartesian coordinate systemLattice (order)Computing platformMessage passingPublic key certificateOrder (biology)Proof theoryBitInformation securityClient (computing)Key (cryptography)
09:16
Transport Layer SecurityEncryptionWeb browserType theoryExtension (kinesiology)Server (computing)MathematicsMedical imagingTime zoneGoodness of fitWeb browserStability theoryMiniDiscCodecWeb applicationBitMessage passingInformationDescriptive statisticsContent (media)Server (computing)Dependent and independent variablesGoogolClient (computing)Computing platformMultiplication signEncryptionKey (cryptography)Diagram
10:10
Game theoryDigitizingCartesian coordinate systemData conversionInformation securityMathematicsServer (computing)Flynn's taxonomy19 (number)Validity (statistics)Message passing
10:45
Transport Layer SecurityMedical imagingDiagramBuildingForm (programming)Heat transferGoodness of fitWater vaporHand fanWordCartesian coordinate systemWeb browserWeb 2.0PressureMessage passingDiagram
11:21
Transport Layer SecurityWeb browserType theoryCryptographyProfil (magazine)Line (geometry)Table (information)Heat transferServer (computing)Dependent and independent variablesPlanningProcess (computing)Musical ensembleRAIDPixelWeb browserMultiplication sign2 (number)Web applicationSoftware developerPressureKey (cryptography)Message passingRight angle
12:21
Single-precision floating-point formatOrder (biology)Level (video gaming)Functional (mathematics)Group actionInformation securityType theoryVector potentialGame theoryDecision theoryMultiplicationPhysical systemServer (computing)Food energyEmbargoWeb browserBit rateFile viewerComputing platformMultiplication signMessage passingDatabaseWindowIntegrated development environmentSingle-precision floating-point format
13:46
WindowServer (computing)Process (computing)Food energyMusical ensembleElectronic mailing listRow (database)Type theoryIntegrated development environmentClient (computing)Multiplication signMessage passingComputer animation
14:24
Client (computing)Single-precision floating-point formatPerspective (visual)Server (computing)WeightLatent heatCue sportsTimestampAbstract syntax treeClient (computing)Multiplication signMessage passingDigital electronicsChief information officerProfil (magazine)WindowDimensional analysisFunctional (mathematics)Sampling (statistics)AreaWater vaporMusical ensembleHand fanHash functionSpecial unitary groupArithmetic progressionCommunications protocolCartesian coordinate systemFrame problemDifferent (Kate Ryan album)Annihilator (ring theory)Tablet computerType theoryTransport Layer SecurityJSONComputer animation
15:39
ACIDDifferent (Kate Ryan album)Type theoryDefault (computer science)Euler anglesInformation securityAnnihilator (ring theory)Video gameRow (database)Profil (magazine)WindowDimensional analysisComputer configurationTotal S.A.State of matterPower (physics)Maxima and minimaMoment (mathematics)MultiplicationSampling (statistics)QuadrilateralIndependence (probability theory)Parameter (computer programming)Beat (acoustics)Vector potentialMusical ensembleOpen setCartesian coordinate systemWeb browserPoint cloudMixed realityMultiplication signForestWeb applicationDefault (computer science)ImplementationOrder (biology)Type theoryLevel (video gaming)Arithmetic meanTable (information)EmailServer (computing)Normal (geometry)Graphical user interfaceClient (computing)Disk read-and-write headDifferent (Kate Ryan album)Single-precision floating-point formatMessage passingWeb 2.0Game controllerSoftware developer
18:16
Computer networkType theoryServer (computing)Web browserTransport Layer SecurityWindowTelecommunicationVideoconferencingDimensional analysisSubject indexingConnected spaceGroup actionHeat transferMachine visionRevision controlGoodness of fitServer (computing)WeightState observerVector potentialPoint (geometry)WordCartesian coordinate systemWeb browserFile formatFilm editingView (database)BlogWeb serviceTesselationSpacetimeWeb 2.0Default (computer science)Type theoryMultiplication signMessage passing
20:25
QuantumData managementInformationTelecommunicationSubject indexingArithmetic meanRadical (chemistry)Point (geometry)EncryptionPlastikkarteTesselationWeb 2.0PRINCE2Type theoryEmailCartesian coordinate systemDomain nameMessage passingSource codeXMLComputer animation
21:30
Artificial neural networkSoftwareLink (knot theory)Metropolitan area networkPoint (geometry)Web browserDomain nameType theoryServer (computing)Multiplication signPublic key certificateWeb 2.0Computer animation
23:02
Game theoryMachine visionWeightMultiplication signWeb browser
23:32
Demo (music)Web browserMathematicsEncryptionServer (computing)Unruh effectDependent and independent variablesWeb browserGame controllerOrder (biology)Semiconductor memoryWindowVideoconferencingConnected spaceServer (computing)Thread (computing)Stability theoryPrincipal idealWeb 2.0Type theoryMereologyTransport Layer SecurityJSONXMLComputer animation
24:55
VideoconferencingTemplate (C++)Asynchronous Transfer ModeDivision (mathematics)MereologyHeat transferDependent and independent variablesSocial classEuler anglesDemo (music)YouTubeType theory
26:49
Asynchronous Transfer ModeHeat transferMultiplication signJSON
27:19
Client (computing)User profileSingle-precision floating-point formatMathematicsDatabase transactionHeat transferServer (computing)WordCartesian coordinate systemElectronic mailing listSingle-precision floating-point formatMultiplication signImplementationClient (computing)Source code
28:00
Library (computing)Server (computing)Transport Layer SecurityType theoryWeb browserPower (physics)Dependent and independent variablesWeb 2.0Video game3 (number)Connected spaceGroup actionMoment (mathematics)Projective planeHeat transferDivisorSimilarity (geometry)Server (computing)PlanningPoint (geometry)Set (mathematics)Direction (geometry)Web browserReflection (mathematics)Address spaceView (database)Sinc functionFreewareType theoryVideoconferencingComputer animationJSONUMLProgram flowchart
31:13
Demo (music)Asynchronous Transfer ModeVideoconferencingCombinational logicLevel (video gaming)Uniqueness quantificationDatabase transactionHeat transferRevision controlPlanningComputer fontOpen setCartesian coordinate systemOnline helpWeb browserElectronic mailing listProxy serverSmith chartType theoryReverse engineeringSingle-precision floating-point formatJSONXMLUMLComputer animation
33:19
Computer networkPresentation of a groupWater vaporMetropolitan area networkDemonSpring (hydrology)Web browserScripting languageAddress spaceDifferent (Kate Ryan album)SmartphoneWeb 2.0Asynchronous Transfer ModeSoftware repositoryComputer animation
34:33
Context awarenessIndependence (probability theory)Communications protocolTransport Layer SecurityType theorySound effectTouch typingTransmitterForm (programming)Time zoneRevision controlDependent and independent variablesCartesian coordinate systemMultiplication signAnnihilator (ring theory)Web applicationType theorySound effect
35:14
Type theoryUser profileService (economics)Software developerTransport Layer SecuritySound effectContext awarenessConfiguration spaceKey (cryptography)Order (biology)Network topologyProfil (magazine)Category of beingWell-formed formulaFunctional (mathematics)Configuration spaceServer (computing)Presentation of a groupMetropolitan area networkMusical ensemblePoint (geometry)Cartesian coordinate systemWeb browserGoogolSound effectBit rateGUI widgetService (economics)Web 2.0Cross-site scriptingType theoryLevel (video gaming)Form (programming)Group actionSoftware developer
Transcript: English(auto-generated)
00:00
Alright, so please join me in welcoming Alfonso and Alejo. Hi DEFCON, our presentation today is about TLS 1.3 which is going to be the next major version of TLS, which will be released soon. It has a new feature which is called
00:24
zero RTT, zero round trip time resumption, which speeds up the session resumption. However, it has some security impacts. This is a known issue that has been acknowledged by the protocol specification. So our intent today is to give you a better understanding of TLS 1.3
00:49
and this new feature, zero RTT. Two is to raise awareness across the audience about the potential risks of using zero RTT. And three is to provide you recommendations about how to
01:02
mitigate those risks of using zero RTT. Finally, a minor disclaimer, what we are going to discuss here is just our own opinion and does not reflect the view of our employer. Hi DEFCON, my name is Alfonso Garcia Alguazil. I work for Cisco as a senior security
01:24
consultant. I mostly do penetration testing and some research and development focused on offensive security and I'm glad to be here for the first time. Hi, my name is Alejo
01:42
Murillo-Moya. I am a senior security consultant at Cisco. I am the red team lead for EMEA, Europe, Middle East, Africa, and Russia. I have more than 10 years of experience in the security field and as Alfonso said, we are really happy to be here at DEFCON. So, once we have introduced ourselves, let's introduce TLS 1.3. So, first a bit of
02:08
history. So, four years ago, a working group was created and that working group had a mission. That mission was to develop the new version of TLS, TLS 1.3. There has been 28
02:22
iterations of the protocol specification and as you can imagine, that has been a long journey. So, now with this introduction, let's move on to some of the good things that TLS is going to bring to us, 1.3. One of the good things is that it has followed a keep the simple approach. So, only five ciphers are going to be defined in the TLS 1.3
02:42
specification. That means that the implementation is going to be easier and also that will reduce the complexity of the protocol. If we compare this to previous version of TLS, that's a huge improvement because if you recall, those previous versions support dozens of ciphers. Another good thing is that TLS 1.3 is not going to be vulnerable to previous
03:05
known attacks against previous version of TLS. So, for example, you can think about RC4, RSA, series encryption mode or even compression attacks. Good luck finding them on TLS 1.3 because you are not going to find them. Also, another good thing is that it
03:22
supports perfect forward secrecy by default. It's by default enabled. And that's something that is not going to be optional like on previous version of TLS. Just a quick recap about the forward secrecy. Imagine that an attacker is able to store all your secure communications. Perfect forward secrecy is going to ensure that even if the attacker
03:44
managed to steal the server private keys, he wouldn't be able to decrypt your secure communications because ephemeral session keys were used. Also, the TLS 1.3 protocol went through some formal security analysis which basically it took and the protocol
04:03
specification, its machine state, its security assumption and those were analyzed and some witnesses were identified. With that information, the protocol was refined and improved before its final release. Let's talk now about the compatibility issues. So,
04:23
last year, Chrome and Firefox were doing some field tests and what they found is that around 5% of the users were not able to connect to the website using TLS 1.3. They analyzed the data and they found that that behavior was caused by something called middle boxes. A middle box is a corporate networking device that is inspecting or
04:46
intercepting HTTPS. What happened in the end is that they made some modifications to the protocol. Specifically, they changed the TLS 1.3 handshake in order to look like, one, looks like a TLS 1.2 session resumption and that fixed the issues with the middle
05:06
boxes. So, at the end, the protocol, it may not be as pure as it could be, but given the circumstances, I think it was the right thing to do. Then, let's focus on the topic for
05:22
this conversation, or this presentation, sorry. So, one of the things that the working group wanted to do is to have a faster TLS and that's especially important on mobile networks due to the latency. So, ZeroRTT was created. ZeroRTT is a session resumption
05:41
that can push data to the server, also called early data. Basically, and from the important things about the ZeroRTT is that it should have a session ticket, the message, and also the early data will be encrypted using a pre-shared key. And then, when the server receives that message, if he can decrypt it, he will process that data. So, it seems that
06:03
ZeroRTT is making things faster because it's pushing data to the server. However, it has some secret implications. So, which are those secret implications? The first one is that we lose perfect forward secrecy on ZeroRTT messages. And the second thing is that ZeroRTT
06:22
messages could be vulnerable to replay attacks. Yes, and that's something really important because we know TLS and replay attacks was never one of our concerns. But, that's going to change with ZeroRTT. So, you may be wondering, hopefully, I have convinced you or take
06:42
your attention on the previous slide, but maybe you can say that, okay, you're not going to use TLS 1.3 or that TLS is not yet an official internet standard, which is true. But, however, you should, at least I would like to convince you because TLS is going to be present in your browsers, implementations, or even CDNs right now. So, for example,
07:04
if we look at Firefox, you will see that Firefox has been supporting TLS 1.3 and ZeroRTT by default for months. Also, Chrome is supporting TLS 1.3. If we move to the implementations, we can see that OpenSSL, on the next version of OpenSSL, which is
07:22
going to be 1.1.1, is on pre-release status and will support TLS 1.3 with ZeroRTT. Same goes for BoringSSL. And, maybe you have heard the news, but Facebook has just released their own implementation of TLS 1.3, which also supports ZeroRTT. And, then, we
07:42
have the CDNs and the CDNs may be supporting or planning to be supporting the ZeroRTT also. Just going back a bit about Facebook and their implementation, they mentioned on that announcement that they are receiving around 50% of all the traffic that they are receiving is using TLS 1.3, which is a lot. So, that means that TLS 1.3 is already
08:05
with us and its use is going to be increased over the upcoming weeks and months. So, let's think a bit more about TLS, specifically on the TLS 1.3 handshake. So, first, the client will send a client hello message to the server, making some educated guesses
08:23
about which options the server will prefer. The server will receive that message and then will send back the required cryptographic material in order to complete the handshake, including the certificate and a proof that he has the secret keys of that certificate. The
08:41
client will receive that message. It will verify that the certificate is valid in order to ensure that he is talking with the right endpoint. It will also check for that proof of knowledge and then it will send a finished message saying, okay, we have finished the TLS handshake. Let's start the security communications. And, as you can see here, after the
09:02
TLS 1.3 handshake has been completed, application data can be transmitted securely. We have also added the new session ticket message because that's important and it will be used in the future. So, now, let's discuss the CRDT message, which is used to do session
09:22
resumptions. So, imagine that we have a browser that needs to resume the previous established session with a web application. What it's going to do is it's going to create a CRDT message. But the bit that is interesting to us is that it will contain a session ticket and it will contain data that is going to be pushed to the server that will be encrypted
09:44
using a pre-shared key. That will be sent to the server. The server will process that information. We will try, we will check if the session ticket is a valid one and also, we'll try to decrypt the data. If the encryption is successful, it will push that data to the web application and then it will send the response back to the client, including
10:06
a new session ticket. And then, the client will receive the message and will say, okay, we have done this session resumption, then I'm not going to send you any more early data. Let's continue the conversation. And, as you can see there, the application
10:20
data will be sent securely. So, hopefully, as you can see, it may be feasible to do AAA attacks. And, that's because the only thing that an attacker needs to have is to have that message that can be replaced to the server. And, the server will just check that it has a valid session ticket and that he can decrypt the data. So, let's see
10:42
how a real attacker may look like. So, imagine that we have a banking application and there is a customer that is using that banking application because he wants to do a money transfer to one of his friends. However, he doesn't know that this friend is not really trustworthy because he's the attacker that is on that diagram. Okay, so, the customer,
11:05
when he clicks submit on the browser form, the browser is going to create a ZRTT message that will include that HTTP request of transfer funds. And, that message will have a session ticket and then this data encrypted with a pressure key. Oops, sorry,
11:22
that message will be sent to the server. In this case, the attacker is not going to do anything with it. He will only copy that message because he plans to replace it later on. So, then, the server will receive the message. It will decrypt because it has the right pressure key and will send that message out to the web application which will
11:44
perform the first money transfer. And then, the server will send back the response to the browser. So, what could happen if the, if the attacker replaced that original message? Let's see. So, as that message has the right session ticket and is
12:01
encrypted with the right pressure key, the server will receive it, process it, send to the web application which would perform the second money transfer. And then, as we can see, the attacker can do this as many times as he wants. He just needs to keep repaying that original message again and again. So, is it everything as bad as this looks
12:24
like? Not really. Okay. The working group put a lot of effort in order to describe these potential security risks and security implications regarding the zero RTT functionality. And they also added within the RFC the recommended protections and even
12:41
mitigations. One of those two protections is single use tickets. With single use tickets, the server is able to prevent replay attacks because it has a database of fresh session tickets. How it will work is when the server sends a session ticket to the browser, it will add to his database. And when he receives a zero RTT message with a
13:04
session ticket, he will verify that that session ticket is on the database and then he will accept the message and then will remove that session ticket from the database of fresh session tickets. The next time he receives a second message, zero RTT message, he will check again that session ticket and will find that it's no longer in the database
13:23
and then he will reject that message because it means that it is a replay attack. So, it seems that this protection is quite good. However, it has one potential issue and it's how you keep that database synchronized in medium or big environments. And that's the
13:40
challenge here, is to synchronize the database across multiple systems without allowing and without creating an opportunity window that an attacker can take advantage of. Another protection will be the client hello recording. Similar to before, in this instance, the server will keep a list of all the client hello that he is receiving. So, the first
14:03
time that he receives a zero RTT message, he will store that client hello on his list and if he receives that message again, he will see that that client hello has been already processed. So, he will create that zero RTT message. Same as before, the challenge here is how you synchronize that list on global and distributed environments. Another
14:28
mitigation that is specified within the RFC is called freshness checks. So, when the client is sending zero RTT messages to the server, it's including a time stamp, which is basically from the perspective of the client when that message was sent. So, what
14:44
a server can do is he can just create any messages that has arrived outside an acceptable time frame window. Another protection that is mentioned in the RFC is application profiles and according to the TLS 1.3 specification or to the RFC, let me see if I can quote
15:04
it properly, application protocols must not use zero RTT data unless it has a profile that defines its use. Which basically means that the application should be able to define which functionality or which paths are going to be exposed over zero RTT. Application
15:23
profiles is a RFC which is related to TLS, but it's still a work in progress. And other types of protections or mitigations. For example, OpenSSL has decided to have segregated APIs for the traditional TLS and this new zero RTT TLS feature. And
15:46
that means that if a developer wants to use zero RTT, it's because he really wants to do it and because he ideally knows what, which are the potential security risks. Other security controls can be added also at the browser or at the server level.
16:01
Like for example, not allowing zero RTT on, only allowing zero RTT messages on HTTP safe methods, which will be GET, HEAD or OPTION methods. Finally, what also can be done is just for example, for the requests that are being sent to the web application, make sure
16:20
that those requests are idempotent. What means that? It means that the final state of the web application or backend, it will be the same independently or how many times you receive the same request. If it's once or multiple times, it shouldn't matter. Now let's see here a table that we have put together after our research of what
16:42
we have seen so far. So the first two columns are basically related to the two protections that are mentioned on the RFC, single use tickets and client hello recordings. You don't need to implement both. You just need to implement one of those two. Then the third column is for application profile. Finally, we have a fourth column
17:01
for some interesting notes. So you can see here, OpenSSL is using single use tickets. And as I mentioned before, it has different APA in order to handle the zero RTT and normal TLS. BoringSSL has a support for zero RTT, but is disabled by default. Cloudflare is working to implement single use
17:24
tickets. They have implemented application profiles using HTTP headers and they have zero RTT disabled by default. You can enable it, but you need to go to the dashboard and doing that explicitly. And even if you enable that zero RTT will only be available on HTTP safe methods like GET. And they added on top of that
17:47
another protection, which is that they are only allowing GET methods without parameters for zero RTT messages. Then we have Chrome. Chrome has no zero RTT at the moment support. Firefox is support zero RTT by default. And as we can see here, it will
18:03
only send zero RTT messages on safe methods. In this case, GET request will be over zero RTT, but not POST request. Okay, so we are going to show the potential impact of zero RTT when an attacker is in the middle of the communications path
18:26
between the web browser and the web server. Of course, both the web browser and the web server will have TLS 1.3 and zero RTT enabled. As a web browser, we are going to use
18:41
Firefox with HTTP 2 enabled, which is already enabled by default. As a victim application, we are going to use our own banking application, which uses a GET request with REST format to perform a money transfer. Firefox only uses zero RTT for safe
19:04
methods. However, how many applications use GET to perform actions which should be made using POST or other methods? Well, we see a lot of them while we are performing web service assessments. In a normal situation in which the web browser, well, in which there is
19:26
not any attacker in the middle of the communications, the web browser will only show a message or will only, sorry, will only send a request using zero RTT, the first one. Then, the
19:43
TLS connection would be established and the following request will be sent using this create and created secure channel until the keepalive time turns out. So, this is why we think that it is highly unlikely that an attacker could catch a tempting request to be
20:05
replayed only with passive techniques. But, let's see this with a video. As I mentioned before, we are going to use the latest Firefox version. This is the tool that
20:35
we created to test the replay attacks. The tool is in the middle of the communications and, uh, in
20:44
this first mode, it will only show a message when zero RTT is detected. The tool is not, uh, HTTPS proxy, it is only a TCP proxy, which means that it is not the TLS termination point. And, therefore, it cannot see the unencrypted data. However, it is not the
21:05
user. It can see the TCP, the, um, TLS packet headers and using this information, it can detect when zero RTT is used. This is our banking application. The domain points directly to
21:40
the web server and, as you can see, the certificate was correctly, uh, validated by the
21:47
web browser. So, it will not note that we are performing the man in the middle. So,
22:07
as you can see, although we are performing the request, nothing is shown by the tool because nothing is sent using the RTT. As seen on the timer, we go forward three minutes without
22:23
perform any request to consume the keep-alive time. Now that the keep-alive time has
22:50
been consumed, the first request and only the first request that the user performs will be sent using zero RTT. This is the request and this request could be potentially
23:08
replayed. But, the next request until the keep-alive time, times out, again, will be sent using the established secure, uh, channel. This is why we think that, um, passive attack
23:22
is unlikely to work. Okay, but can we control when the web browser uses zero RTT? So, can
23:45
we improve this attack? The response is, let's see. This is the TLS handshake that Alejo already explained. After a full TLS handshake or a zero RTT handshake, we want the server
24:03
to receive the HTTP request and the browser to receive the server response. After that, if we don't do anything, the next request will be sent using the established secure channel, like we saw before. However, we can finish the connection at the TCP layer by
24:28
sending fins or reset packets and then the browser will send the next HTTP request using zero RTT. If we do this for every new TLS connection, um, there will be much more
24:43
chances that the attacker can replay the request that he wants, because the most part of the request will be sent using zero RTT. But, let's see this with another video. Well,
25:05
now, the tool is configured to, to do this technique. However, now is hosted behind Cloudflare with zero RTT enabled. As you can see now, the most part of the requests are
25:56
sent using zero RTT. Well, due to the use of HTTP2, some of the GET requests are not
26:05
really sent over zero RTT. Only the HTTP2 preface is sent over it and the real request is sent later in the established secure channel. However, we have noticed that for
26:20
the requests initiated by Ajax, the most part of the, of them are sent using zero RTT. Now, we perform a money transfer of $2, but we don't want to replay it, just to demonstrate that
26:48
we are not tricking you. And, as you can see, we have one money transfer. Now, we perform a
27:09
money transfer of $3, and this time, we want to replay it three times. And, refreshing the
27:25
transaction list, it can be seen that the attack was successful because, well, the only, the user only sent one money transfer, but we have four. Okay, but, now we have seen that, uh,
27:48
replay attack can work against a vulnerable application which is hosted behind the server. It doesn't implement single use ticket or client hello. What about, what about a server
28:04
that, these, uh, techniques. Is it possible to replay it? Well, as you can imagine, the response is yes. And, I'm going to try to explain how. In this situation, the web
28:22
browser will send, um, money transfer request using zero RTT. The attacker intercepts it and sends it to the web server. The web server will accept it because, uh, it is a fresh
28:42
zero RTT. At this moment, the web browser is waiting for the server confirmation that the zero RTT was accepted. But, the attacker sends, sends this message. The attacker sends
29:06
well, opening a new TCP connection, but he sends again the same zero RTT packets to the web browser, to the web server, sorry. And now, uh, the web server rejects it because it
29:21
is implementing single use ticket and, uh, simple reply like this one doesn't work because it is a non-fresh zero RTT. The attacker now sends back the rejection request to the web browser. From the point of view of the web browser, the zero RTT was rejected
29:44
and no money transfer was made. However, in reality, one money transfer was made. According to the TLS 1.3 RFC, after a zero RTT rejection, a full handshake has to be
30:02
done. So, the web browser and the web server, uh, do the, the full handshake and after that, the web browser, since it thinks that the money transfer was not made at the first
30:20
time, now it repeats the, the request, the HTTP request. And the, the web server accepts it because now, uh, it is not using zero RTT. It is using the established secure channel. So, after the attack, the, from the point of view of the web browser, only one
30:45
money transfer has been made. But, uh, really, what has happened is that two money transfers has been made. With, uh, this, we can, uh, basically, uh, we can, uh, perform only, uh, one replay. But, at least, we can, uh, perform one replay against a
31:08
server which has, uh, these anti-replay protections. Let's see this in a new video.
31:29
The tool is now configured to perform this last, uh, replay technique in combination with the killing technique of zero RTT. The banking application is, is, is, is, uh,
31:41
application is now hosted behind a reverse proxy which has enabled, uh, zero RTT. This reverse proxy uses OpenSSL, the pre-release version, which implements single use tickets. Like in
32:17
the previous video, we perform a money transfer of two dollars without replying,
32:25
replying, sorry. And, refreshing the transactions list can be seen that only one money transfer was made because we didn't perform any replay attack. However, now we perform a
32:45
money transfer of three dollars and we, uh, perform this last replay technique in which the
33:03
attack was successful. You can see here, instead of, uh, having, uh, one money transfer, we have two money transfers. So, the attack was successful. Okay, this brings me to tell you
33:21
that, uh, we are going to release this tool, and, um, if you want to use it, you have to redirect somehow the traffic from the web browser to the tool. Um, as usual, in the, in the demos, we were using tags for the HTTP requests, like, for example, send
33:47
money. The tags are based on the encrypted packet's length, and, uh, you can create them in the monitor mode of the tool. The tool, uh, also provides two other modes to
34:03
perform the two different replay techniques, and also with the kill part, which is parameter, it performs the killing technique to force the web browser to use zero RTT, and all. The tool should be available now at this, uh, GitHub repo. So, let's talk about the
34:35
side effects of zero RTT. When we deploy previous version of TLS, how the data is being
34:42
transmitted is totally transparent to the web application. However, with zero RTT, that's going to change because it creates a dependency between the TLS and the application layer, which was not present before. So, that means that the application will need to, to know if zero RTT has been used so he can prevent replay attacks. And, at the end, the
35:05
ultimate responsibility would be on the application itself to prevent replay attacks. And you can ask how we can do that. Let's see what we can do. So, first thing that you can do, and you should do, is disable zero RTT, and only enable it if you are really,
35:22
really, really sure of what you're doing. All the things that can be done is just, uh, for example, you can try to make sure that your application is, and is replay safe, but that can be, uh, quite a challenge. But, if you go there, what you can do is you can apply a street cross-eyed request for a great policy, not only at the session level, not
35:42
only at the form level, but at the request level. Another mitigation that you can, that you can deploy is to migrate those get requests that are not replay safe to post requests. And why? Because most likely the browsers are not going to send zero RTT
36:01
data on post requests. Also, you can make sure, uh, regarding the web services, and you need to make sure that those are developed properly, and that get, post, put, and delete are used properly. And with regarding the get methods, you need to make sure that
36:22
those actions are either read-only or idempotent. And finally, you should deploy in a street application profile, which basically defines which are the, uh, functionality that you really, really want to expose over zero RTT. To finish this presentation, we have
36:44
some, uh, takeaways. The first one is that TLS 1.3 is awesome, and all of us will use it, but take care with zero RTT. The second one is that your application, uh, should,
37:02
should be zero RTT, uh, web, to prevent side effects. And the last one is that, uh, maybe you need to change your application or your server configuration in order to prevent replay attacks. Thank you so much, and if you have any questions, we will be around.