 Okay, thank you very much for the introduction. I'm Sebastian. I used to be a penetration tester and so on and so on Now I went back to the to the University and now I'm a professor at Munzer University of Applied Sciences where I teach and I and I do research in information security. I did two former talks at CCC at this very premise one was three years ago time is on my side and one was two years ago and Both are have a related topic because we're gonna look at at timing attacks in this talk as well This talk is based on an academic paper and I've linked it over here If you just Google it you will find a link to the presentation of the academic paper if you're interested in that Obviously, it's joint work what I'm presenting here. So this is not solely my work that I'm presenting here but there's like a large amount of people who helped and Basically what I was doing is is the timing part of the attack, but you will we will see that later on Okay, so there were lots and lots of SSL TLS box in the in the last years So you all probably have heard of of heartbleed and poodle and crime and beast and so on So there's like a huge amount of SSL research and breaking SSL research in the last years It's not a thing of only the last few years But also like maybe something like 10 years ago or so or more than 10 years ago There we saw other types of attacks so for example the Bramley Bonnet attack which was a timing attack against SSL and Also Bleichenbacher's attack. It's named after Daniel Bleichenbacher. I think he's from Switzerland and He found this attack in 1998 Against a very early version of of SSL and what we are going to do today in this talk is We will have a look whether the attack is the exact same attack still works Some of the bugs that were discovered like in the in the past some of them were protocol level bugs and some of them were implementation level bugs That's an interesting distinction. So can we fix a bug just from the implementation side or do we have to fix the protocol? Generally speaking people refrain from Fixing a crypto protocol because it requires a lot of work and it's not compatible to all the versions and so on and so on But generally speaking when you design a crypto protocol It will pretty much stay the same or it has to be supported for the upcoming years and also Depending how you design the the crypto protocol Decides how much effort it is to implement the protocol and not I'm not speaking about effort in terms of lines or lines of code but Something like how fragile is the protocol to implement? So how careful have to do you have to be at the at the implementation level and What we're going to see today is some kind of a so we have like in 1995 when SSL was proposed the SSL version 3 was proposed They made some decisions that we now know are vulnerable and they never changed it So the SSL protocol itself is still protocol against the Bleichenbach attack if you don't Be very careful in the in the implementation phase And we're gonna look at the implementation So just a quick primer of how SSL really looks like this is really a very short introduction. There's a new book by Ivan Ristich He's explaining very well all the foundations of SSL and how it works and so on So if you want to take a deep look at SSL, you might want to look at this at this book I'm just going to present these parts which are relevant for this talk So what is relevant for this talk is a TLS is some kind of a hybrid Protocol so it has some as a metric crypto and some symmetric crypto and Generally The symmetric crypto is used for for encycling the the actual content So when we use as HTTPS for example the HTTP traffic itself will be encrypted with a symmetric cipher for example AES and With a random session key and this random session key will be exchanged between client and server using as a metric crypto So this is like the client sends a client hello the server sends a Server hello he sends a certificate and this certificate contains a public key So the client receives the public key then he Randomly randomly chooses a session key It's really just random and encrypts it with a public key of the server and sends it over to the server Now both have the same session key and can talk Encrypted When an attacker is able to somehow decipher this session key obviously the broader the this session is broken Because the attacker can then decrypt the whole session and you don't have confidentiality anymore this session ticket as I was saying is called the pre-master secret or PMS and Yeah, as I said the the client encrypts it with a service public key and sends it over to the server And then the actual session key is the master secret and this depends on the pre-master secret, right? So this is the most this is anything that you have to understand in order to to to follow this talk You don't have to know more on on TLS Okay, the the attack that I'm going to present here is old. It's 14 years old It was developed by Daniel Bleichenbach in 98 and it works like this You have a TLS client and a TLS server and they do they do a TLS handshake and they exchange the pre-master secret Right, so the session key for if you want the attacker is a passive man in the middle Which means he just eavesdrops on the on the connection and now has like he has recorded the encrypted TLS handshake and what he wants to do now is break this Like the the pre-master secret the session key and He does that solely by requesting but by doing certain requests to the TLS server And measuring response times for example or analyzing error codes and anything that comes from from the server So that's our attacker scenario and that's a very general attacker scenario if you look at attacker scenarios for example for crime or Beast which were former attacks in the in the last few years. They have a very different attacker model So that it only works in the HDDPS context for example because the attacker has to force the victim to perform Many encrypted connections over the same TLS channel, right? So he requires that we don't need this in a bleichenbach attack We just need to record the TLS handshake and we have to we must be able to issue Request to the server and measure something right and what we what we measure that we're gonna see it later on and this Scenario means that our attack is not only applicable to HDPS but also to pop3 s or IMAP s so anywhere in any context where TLS is used Our attack can be applied potentially depending on the implementation Now it's not that we have broken all the ciphers that that are used in TLS. That's not the case. So there's Like various ways of doing the encryption and doing the handshake and so on and so on and what we can break With our attack is this list of ciphers. Most of them are still used quite often at least before like like It changed in the last one or two years since Snowden Told us what what the NSA is capable of so since then things change But before that those were I guess the most used ciphers everywhere Basically, we can break all the ciphers But none of the elliptic curve suites because they have a different type of of key exchange and None of the Divya helman suits So if you're using these and you should use these because they're in generally more secure and also At least ecc is more is more performant Okay The RSA encryption algorithm. It's really it's really very elegant very short, right? So when you want to encrypt something you take your message Raise it to the power of e and e is the public key mod n And when you want to decrypt M you just take the ciphertext Raise it to the power of D and D is the private key Modulus N and then you get the then you get the message back One thing that is also very important in order to understand bleichenbach as a tech is that RSA is malleable malleable in German Form bar Means that an attacker can make predictable changes to the ciphertext without knowing the clear text So I give you a ciphertext or you give me a ciphertext Let's let's put it this way then I can make changes to the ciphertext that have predictable effects on the clear text Even though I don't know the clear text and even though I don't know the result of my computation that I just did right? So you can for example do a multiplication So that's an important That's an important thing that we have to keep in mind when we when we go further Another thing that is a very important. That's I guess the second thing that is very important We need to use some kind of padding because the The pre-master secret that we use for symmetric encryption is very short. We just we just need 48 bytes So it's very short, but RSA is some kind of a block cipher. So when we have 2048 bits RSA keys we always have to encrypt to 2040 2048 bits right So we have a 40 by 48 bits over here But the whole thing is like 256 bytes. So we need to use some kind of padding and In TLS the decision was made in 1995 to use a standard a padding standard That is called pkcs1 in version 1.5 and always when I say pkcs1 in this talk I mean version 1.5. There's also a version 2 which is much more secure But always when I when I say so it's like pkcs1 In version 2 right, so this is secure, but always when I say pkcs1 I mean version 1.5. Okay, so just that you know and the the padding scheme is very very easy actually It always has to start with a 0 0 0 2 at least for the encryption type Type so you always have 0 0 0 2 then you have 205 bytes with non-zero padding and this this is supposed to be random Right, whatever comes in here should be somehow a little bit random And it must not contain zeros because the the end of the padding will be denoted by by a zero byte and Right then then comes the pre-master secret and the pre-master secret is 46 bytes of Random string like that's the session key that we use that we use for the symmetric encryption And this is the part that the attacker wants to want to break. This is the important part The 0 3 0 1 is Somehow deterministic it means in this case that the protocol version was TLS 1.0 right So very easy very easy to understand Now what does Bleichenbach's attack mean and I'm Unfortunately, I don't have enough time to go very deeply into into Bleichenbach's attack but only From a bird's eye view it means When when a service is susceptible to Bleichenbach's attack it allows Bleichenbach Who's in procession of an RSA ciphertext I call it C to recover the plaintext of it M0 under certain conditions and The condition for this is that it requires an oracle So you need to have we call it a Bleichenbach oracle and this Bleichenbach oracle Does a very specific thing it decrypts the ciphertext and Responds with one or zero or true or false you can take whatever Boolean Answer you want depending on whether the decrypted message starts with 0 0 0 2 or not That's a remember PKCS 1 in version 1.5 requires that it always starts with a 0 0 0 2 and And when we can construct from this a Bleichenbach oracle that tells us exactly this so true or false Does this ciphertext start with 0 0 0 2 then we can decrypt the whole ciphertext just by issuing many requests All right, so we have to agree with the oracle many times and the reason for that is When the oracle answers with one the adversary knows something about the About the range the possible range of the RSA clear text and It will be in this range and you don't have to understand exactly why this here is the case The important part is here is a two and here's a three and we know that When when the oracle tells us one. Yes, this was PKCS one complied it starts with 0 0 0 2 Then we know That the clear text which is just an integer RSA with works with integers is larger than Something something with with two Right, so it starts with a leading two and it's a smaller than something with a low with a with a leading three Because otherwise it would be 0 0 0 3 that's not the case Right, so we have to issue many Many oracle requests and for each request we learn a little bit more about the clear text Okay, this was the theory part now. We come to the to the practical part We have to talk about the strength of the oracle in an ideal world We just want to have an oracle that we can feed any cipher text in and it will tell us yes It starts with 0 0 0 2 or not in In reality, this is a bit this is a bit different Because I told you PKCS one the format it starts with 0 0 0 2 But it performs some more so there's non-zero padding and when there's non-zero padding You should check whether there's a zero byte in the non-zero padding because otherwise it would be not a non-zero padding Right, so we just want to have one oracle that tells us yes This starts with 0 0 0 2, but what happens when we have a Zero in here then this might fail or if this Zero byte here is not there this might fail or if this 0 3 0 1 is not there then it might also fail So these are all additional checks that a TLS server might perform In order to find out whether The ciphertext decrypts to a PKCS one conformant clear text That's the problem and the more checks that we have the worse performs the oracle because we could have ciphertext That decrypt to a to a plain text that starts with 0 0 0 2 but because of the additional checks the oracle says no this was not pkss conformant So fewer checks Result and stronger oracle and it's better for the attacker and the other way around the more checks We perform the worse is the attack right Okay, so now 1998 let's go back to 1998 Daniel Beichenbach came with his with his famous paper What did people in the TLS consortium say well they said okay? Let's just stick to pkss one in version 1.5 padding for compatibility reasons, right? Everything is for compatibility reasons. That's a problem, right? That's really a problem But they made the decision. No, we just stick to the padding We know that it's vulnerable, but let's just look whether we can find an implementation that is not vulnerable and this is what they did They just said we make the requirement for the Implementations that pkcs one conformant and non-conformant Messages must be treated equally. They must be indistinguishable for the attacker so that means for example, we had to unify all error conditions because the in the In the first bleichenbacher Paper in the original bleichenbacher paper. He exploited error messages So the SSL implementations told the attacker specifically. No, this was invalid padding No, this was valid padding, but it worked because of something else. It didn't work right so They prevented this by saying okay We just send one error message and the error message just says something went wrong So we sent over a ciphertext The server makes this thing and does all the checking it just says not something went wrong But we don't know which right we don't know whether the padding was correct or not But something else could have could have gone wrong something like this, right? So this is what they said unify all error conditions We checked for this so we tried So we created a lot of test cases something like fuzzing you might you might call it fuzzing And tried to find out whether we can find oracle in different TLS implementations So this is an example for Java for example where we can provoke some error condition where we can create a bleichenbacher oracle Right and this is a very weird oracle in a sense, right? So it will throw a very specific error and it's called an internal error If the clear takes starts with 0 0 0 2 and the clear takes contains a zero byte proceeded with a non-zero byte and Somewhere in in this area here, so it's only valid if it if it happens in this area So some programming error that happened there because of this we could apply the straight 14 year old bleichenbacher attack against this against this server But we have to talk about the oracle strength, right oracle strength. You remember we have a clear text That starts with 0 0 0 2. That's the one that we want to have for the bleichenbacher attack But we do additional checks and because of these additional checks the oracle might still say no It's not valid or something like this And here it the oracle strength really depends on the bit size on like on the key size of the RSA keys, so for 1024 bits we have only two two promille success rate that means for Let's just say for for 1000 ciphertext that all start with 0 0 0 2 we only have two where it really says Okay, this is a this is a pkcs one compliant a pkcs one compliant key and The interesting thing is the oracle strength increases with a bit size, so that means when you use 4096 bit keys which is the most secure This is the the worst in in our case because the oracle is very good So in three of four ciphertexts that start with 0 0 0 2 the oracle tells us. Yes, this is pkcs one compliant All right, so Usually people tell you that For bits like the bigger the bit the bit sizes the bigger the key sizes The the more secure an encryption scheme is and here it's just the other way around This is often the case for for sectional effects, right? So the attack performance we couldn't attack in reality 1000 bit keys because it just has a very low ratio. So the the oracle is very bad It required us 12 hours for to recover premaster secret of a 2048 bit key and as only six hours for 4096 bit keys Okay So here we just checked for the obvious So we just took the a 1998 paper and Created a few test cases did some fuzzing and try to find out whether it worked or it didn't When you look closely at Bleichenbacher's paper from 1998 He will tell you that he created his his oracle using Arrow messages, so he just only looked at the error messages and nothing more and there's a small sentence Where he said in a theory it could be possible to make one of these Bleichenbacher oracles over a timing side channel and This is where we got the motivation to look to dig a little deeper and look whether we could construct Bleichenbacher oracles just from timing information We had some experience with Timing-based Bleichenbacher attacks because we applied it against a standard called XML encryption You will find the details in my In the talk three years ago, so from 28 28 C3 was it But just in a nutshell I will explain you how this worked so basically XML encryption is a standard that allows you to To cut out a part of an of an XML tree Encrypted symmetrically, let's say with AES and a random key and then you take this random key encrypted with the Receiver's public key and put it to the to the same document and this is what you see here So down here you have the actual symmetrically encrypted Part that you want to hide that is the way you want to guarantee the confidentiality and over here you have this random the random session key quotes That is itself encrypted with a public key of the receiver right, so We could attack this because all the implementations that we looked at worked as follows Decrypt the session key in the first snap. So this is this part return an error M if If M does not comply with PKCS one Else decrypt C data and C data is this part down here so the whole symmetric decryption only happens if The key that was that was used there was PKCS one conformant Which is great because we can measure the timing between Between these two steps, right? So when we can measure this then we have one and we can construct a Bleichenbacher oracle from this the good thing is We can the attacker can influence how long it takes for the for the decryption to finish Because he can just put arbitrary garbage down here megabyte wise So it will take hundreds of milliseconds even seconds and to decrypt And it just it can be garbage. It doesn't have to Like be parsable at all or something like this because it will be parsed later on We just want the the decryption to be happening and this is where we constructed the the timing the timing oracle right and here you see just This not only worked over the over local network, but also over the internet So we did some measurements over the internet and that also worked I'd say that was just a short Short yeah, it's course Okay, so we have already experienced timing based bleichenbacher attacks Bleichenbacher attack was applied against TLS So it's it's somehow natural to go back to TLS and try with the timing based thing Works against TLS as well Let's look at the standard what the people said how to How to prevent time timing attacks against bleichenbacher and we take the last standard of TLS in version 1.2 and They said well we make the processing of valid records and invalid records indistinguishable and this is just a snippet of the standard So they had some kind of some kind of pseudo code Where they explain how the pkcs one verification is supposed to be happening so that no timing So no timing to a channel can arise So we generate a random string R of 48 random bytes This is the a random PMS that will be generated any time Then we decrypt the message to recover the plaintext and if the Pkcs one cat padding in the plaintext is not correct We use R that is the randomly Generated string as the pre-master secret and just continue with with deep with the SSL protocol This has the advantage that it will well Server and client now have different keys. So as soon as they start Like talking on a on a on a symmetric level it will fail and what will also fail is like the HMAC Authentication so there's one part that I haven't explained yet and that is also not necessary just know That it will it will fail later on somewhere in the protocol it will later fail and This failure does not correspond to whether it's pkcs one conformant or not All right, so that's a good thing what they proposed here. This is how it's supposed to work Here's just I want to repeat this one more as we generate a random key a Random PMS PMS R and in case of a pkcs one in ballot C proceed with PMS R in in the protocol The good thing here is the random PMS will always be generated always independently whether The the key that was received from the client was pkcs one conformant or not It provokes an error condition in the later stage Okay, but what about TLS 1.1 and 1.1.0? These are older, right? So right now. I have shown you the the newest Version of the standard in the older standards. There was no pseudocode listed. It was just this sentence that was in here So the best way to avoid vulnerability to this attack is to treat incorrectly formatted messages in a manner Indistinguishable from correctly formatted RSA blocks this this we all understood, right? So there must not be any difference between a pkcs one conformant a ciphertext and a pkcs one conforming ciphertext and Then they said thus when it receives an incorrectly formatted RSA block a server should generate a random 48 byte value and proceed using It and there's a difference Right. Do you see the difference? Exactly, so only when it receives an incorrectly formatted RSA block a server should generate a random 48 byte value and proceed using it So the 48 random bytes will only be received if the key that was coming in is not pkcs one conforming So that's interesting What does it mean, right? So we have it differently we decrypt the ciphertext we do all these pkcs one padding checks and If they fail we generate a random pre-master secret and proceed with this Random pre-master secret and if it's not the case if it is pkcs one conformant then we just proceed with this particular PMS this has one advantage that is That makes it clear for me why they chose This approach and the former standards It's much more efficient or maybe not much more efficient, but if but more efficient So when it comes to TLS performance is very important and when all of a sudden for each and every incoming TLS handshake you have to get a 48 Bite random string. This will take some time depending on the hardware and so on and so on But this might be in a millisecond area, right can be a few microseconds can be a few milliseconds and this this Obviously if they inform our versions of the standards, they thought no, it's not worth it, right? So nobody can construct a timing channel from this and we checked Right, let's do some timing measurements How to perform Timing channels itself is a talk is a whole talk isn't over right and I always keep saying this Right, so there's I should do an own talk the good thing is I did an own talk for this, right? So you can just look at the video recordings From 28 see three there I explain how to do timing measurements with a normal computer over a network and how do you cancel out the the jitter and how Can you deal with statistics and so on and so on? How can you not prevent timing channels, right? That's the The talk that came that came later if you're interested in that you can have a look at this as well and The first thing that we did is we used a TLS testing framework. It's it's called time. I don't know what the abbreviation really really means But it's credit to Christopher Meyer He did this in his PhD thesis and it's basically a framework for fuzzing TLS implementations So you can generate Various requests And and do testing so it's very easy and convenient to do testing for TLS The problem is it's written in Java That's really a problem right and I mean I was expecting some trouble when it's written in Java But I so basically I didn't know that it's that difficult to do time timing measurements in in Java right, so we had to do a different approach and Here is just I try to condense all the things that I've learned in between Like in the years of doing timing attacks over networks What should you do in when you want to do a timing attacks, right? So no memory managed programming languages no Java no Python or Pearl. No you name it just you see just use a sampler Where you have a single thread that's exactly what you want and and so on and so on and there you have already Some you might have some issues there as well, right, but you have these in memory managed programming languages as well Choose your part of the network wisely So there's really no issue There's really no use of doing it over Wi-Fi or your 3g modem or whatever Just go as near as you can to the target that you want to attack when your attack is somewhere buried in a In a data center you might want to rent hardware in the same data center for example, right? short paths It's very good Disable the power management on your on your measurement machine. So when you use Linux as As measuring platform You should like disable for example Intel speedstep and there's some equivalent from AMD It just it goes under a different name, but it has the same effects There you can use the CPU frag utils its user land so you can just install them and Set your CPU to a fixed frequency And there's also something which are called a CPU C states or sleep states They will just like put here or certain they would put certain cores To sleep and in order for them to wake up this takes some some time and adds jitter to your measurements So you can just disable this with a kernel boot parameter on Linux What I haven't put on this list is you can also fix a Process to a certain core so you can disable certain cores and So that it only that your measurement script only runs on this particular core. You should do this as well Don't use fancy server Hardware because they do something that is called interrupt coalescing an interrupt coalescing means Or in the old days When one packet arrived at your at your at your network card It sent an interrupt to your kernel for each and every packet and you want exactly this The modern hardware and not only in the server hardware, but also in laptops. It's built in and so on and so on And there's something called interrupt coalescing. So whenever a packet comes in The hardware will still wait for for some microseconds. That's configurable Where the other packets are also coming in so that it only sends one interrupt for many packets, right? And you don't want this So use very old and cheap network interfaces and we did this Stop all tasks and demons on your local machine know your eye This should be self-explanatory and what you also want to do you want to so with timing measurements You have to repeat the same measurements over and over again in order to do statistics on it in order to filter out the the noise You want to skip the first few hundred measurements because usually you have some some cash is warming up, right? So you want to skip these? Okay Start and end point for measurements is also something that that can be quite quite interesting So for example when the request that you're sending is very big You don't want to press the the timer, right? And and then start sending sending sending sending sending sending and then waiting waiting waiting and then come The first packets come in of the response and then you then you set the timer down here You don't want to do this What you what you can do if if you have the possibility is you send all the bytes of the request that you want to measure You sent all the bytes But not the last one so n minus one if the message is n bytes big You send n minus one then you start the timer then you start to send the last byte of the request Then you wait for the receiver of the nth byte of the response Could be the first byte or something else and then you stop the timer and then you receive the rest of it okay This is our measurement setup and basically it's our time framework just Showed in a in a in a different angle and the timing critical part is somewhere somewhere over here and I told you it's like time is written in Java, which is very convenient for for programming but not very good for timing measurements and so we decided to just cut out the critical the timing critical part and And and build a module that is written in C and assembly So I Didn't want to write a full-blown TLS client in C So I looked around what was there and then I looked at open SSL right for maybe an hour or two Then I closed the editor and went for a walk right The reason the reason for that is it's really Yeah, it's I mean Crypto is difficult right and you see that a crypto is very difficult when you look at the at the code of SSL of open SSL The API is very It's very hard to understand right and obviously there's no API for doing a timing attack on TLS in open SSL Right, so I wanted to reuse a part of an oven of another client and I found this with a very tiny Embedded SSL implementation called matrix SSL I've been written here and we just patched this so it's GPL the code of matrix SSL is GPL It's very small and the good thing is there's no weird API thingy happening there. You just have Send and receive for example. So you're doing operations really on a socket level, which is exactly what we want Very clean cold base or maybe not very clean, but it's it's a clean cold base no complex API wrappers and They even come with a client and a server just as an example Right, so they bring they ship with examples and we just patched the client so that it does whatever you want And what we want is we want this client to do a TLS handshake with a pre-master secret that we sent him Right, and so it was just we just created this command line tool that does a TLS handshake with a base 64 encoded PMS that we just generated and It will it will just it takes the PMS and then you have just a lock here And then you grab over the lock and just get out the timings that you want So you see it is very inefficient what we what we coded here, but it's just research right So we just so we called for each and every measurement that we did We called a new process From Java land to the sea land here and no right so it's so all the numbers that I'm showing to you Obviously, I'm not very not very good. You could probably Make them faster by factor 2. I guess but still come on. It's research Right, so how did I do so? This is really this is really a code that I patched in there You have some while loop where it gets some data that he wants to send over to the Over to the server and here you have your send syscall and after that we just We we measure the CPU ticks if you're interested in the in the details here Just look looked my my talk from three years ago and then we get like the the start ticks like How many clock cycles were Have passed Until this until the CPU was initialized at this point as it's now in start and here we have the end Here we have just to receive rights. It's very easy. Just basic socket programming very nice and Down here we get the end now We have like the start ticks and the end ticks we just subtract them and then we get the amount of ticks that passed And that it took for for the server to just do do his thing so that was pretty much the setup Now let's look at the code. Let's look at OpenSSL Right Okay, this is a real source code of OpenSSL I think it's half a year ago or so in one dot zero dot one dot e or I and Everything that is relevant for a Bleichenbach attack happens within let's say 50 lines of code or so So here this line is Important because there we decrypt whatever came from the from from the client So the client sends the encrypted PMS this will be decrypted over here and we have some status here that is passed as e and This will be used over here and then we just check in this particular If statement here whether some some decryption failure happened and if this decryption failure happened What do we do? We get some pseudobytes as we got some random bytes we generate a random pre-master secret and Generate the master key. So this is really the old way of preventing the Bleichenbach attack. So if and only if The pre-master secret that came in was not pksas one conformant then we gene then we generate a random Key and continue with that. So how does this look like when we look at the measurements? We found that it's this generation of 40 of 48 bits of random data is One and a half microseconds. This obviously depends on the On on the platform that is used and so on and so on but one and a half microseconds This is something that we can measure in a local network and this is what we did The problem that we found was Open SSL did something very good. You don't hear this very often, right? But this is a presentation where we say they did something very good because they did a very strict pkcs one checking So they not only checked for does it start with zero zero zero two. They also checked. That's a non-zero padding Not contain any zero bytes. It is the zero byte on the on on the right space and so on and so on and so on So they did everything right and this led to the fact that the oracle strength itself is very weak That means even if we send a cipher text that decrypts to a plain text starting with zero zero zero two We still have a very low probability that the oracle will tell us. It's it's a valid. It's it's pkcs one valid So therefore we couldn't attack open SSL, right? So we we didn't even try we just did the math and said that it it will As a successful attack will require us Four times ten to the power of 12 requests and this is not not practical anymore This is not something where I would sleep very well, right? So this should be fixed and it is fixed in the meantime, but still it's not something practical that we could do in our lab Let's look at the third channel and this time again. We look at the Java implementation of of TLS So these were the same guys That had this like the different error message, right 20 slides ago or so And when you look at this so we have some master secret here and we want to generate the master secret We we get some information and try to generate the master secret over here and what you see here is there's a lot of a lot of exception handling, right? So what they did here is actually textbook Java implementation. This is how I teach programming Beginners how to do how to do object oriented coding, right? The problem is this is not a really good idea to do this in a timing critical sense, right? so It basically means you don't see this at the code here I only show this to to show you that there's a lot of Exception handling and catching and throwing new exceptions and so on and so on It led to the fact that We could exploit this so there we could execute a timing based Bleichenbach attack against JSE the Oracle strength was very strong. So they do very few checks So when you send over a ciphertext and it decrypts to a plain text starting with 0 0 0 2 we have a 60% chance that the Oracle will tell us yes This is a pks s1 perform it and it means that we could like break one single TLS handshake Within just about 18,000 requests and 20 hours, which is pretty good The fourth channel and maybe the most critical channel was When we looked at some hardware TLS accelerators Concretely at those from there from the company caveat So whenever you buy a big appliance for big money that does the SSL termination for you So let's assume you have a lot of requests that you have to process And you have a lot of application servers and a load balancer then usually the the service Behind the load balancer. They don't terminate a TLS It makes some box before that does it and if you buy such a box It is often it often contains a hardware acceleration for for TLS or at least for the underlying crypto primitives Such as AES and RSA and things like that So that the pros the expensive part of the crypto operations is performed on separate hardware This comes in various flavors For service you can you can also buy this and plug it in by a PCI then you need a driver and so on and so on So yeah, and it's then relevant when you have like a big installation and you have to deal with many thousands of Incoming TLS handshakes and connections and so on and so on Then you need an appliance like this. So we analyze this as well and Concretely we looked at the approach a pros products F5 big IP on and IBM data power So we didn't have the actual card. We just use products or measured against products that have these cards installed and This is very interesting a very interesting behavior what we found here. So It for example, it doesn't verify whether the clear text begins with 0 0 0 2 It just verifies that it starts with something 0 2 Which is weird? but One possible explanations. I mean, we have talked to the developers, but we have we didn't ask them about this But I guess it's again something performance, right? So they wanted they didn't care about the the first bite They only cared about the second bite This brings this brought us a little trouble Because the Bleichenbach's algorithm the textbook algorithm requires that something starts with 0 0 0 2 So we had to adapt this Bleichenbach's algorithm so that it also works with something or 0 2 which makes the oracle somewhat weaker but we could still apply the attack and We required a 4 million queries, which is which is which is a lot But it took 41 hours right to decipher a TLS handshake of one like one single TLS handshake Okay Let's just make a summary So the first thing that this is not something new but not many people have achieved this so far Timing attacks against single-digit microsecond delays in TCP connections are practical So there are other papers who did this against DTLS for example That is a datagram based service. So like UDP for example, you send something and something comes back It's a bit more involved when you want to do the same over over TCP connections But we found that it still works, which is good a Bad design and I should have quotes here in in bad design a cryptographic protocols met on to you for decades to come When in 1995 they make the decision that RSA and PK says one in version 1.5 is a good idea They brought a lot of trouble right said they didn't know that this is can be exploited that easily During that time they had to wait until 1998 and until bleichenbacher showed this But the problem is we have been living with a protocol that is known to be broken for 14 years and Now I hope it makes sense when you when you remember the thing that I said on my on one of my first slides Where said protocol decisions? Like it can be very fragile right so everything that you have seen here like the implementation of TLS in this Specific part is very very fragile and you have to be very very careful to do exactly the the right thing and Then also What is taunting us is a magnet and crypt? so obviously It's not possible in the TLS protocol to just send them random Cypher text over there and expect a server to do something useful with it right also You have a thing that guarantees your authenticity So you have a message authentication code and this is where it where it will fail any time, but the problem here is You have Mac then encrypt that means the message authentication code is Appendent to the clear text and then encrypt it Which me Sorry Yeah, so yeah, so yeah, thank you very much So the problem here obviously is in order to check the message authentication code You have to decrypt the cipher text beforehand So there's a lot of code running before you can actually check whether this is a valid message Right, so this is bad. What you want to do is encrypt than Mac So you'll make like you encrypt your clear text You have a cipher text and then you do your message authentication code on this and then the message authentication code is appended to the to the cipher text and sent over to treat to the receiver Yeah, implementing TLS is a is a minefield and this may explain Why everyone keeps complaining on the code quality of open SSL for example, right? so Look at the Java code. It looks much better Jesus is really nicely object-oriented and everything but it can also be broken and it's broken in more ways I think then then open SSL was Okay, guys, thank you very much. I'll be around at Until the 30s. So if you if you want to talk to me just just do it. I'm happy. Thank you very much Thank you very much. Now. It's a little bit time for questions I know that there's a one question in the internet and They were discussing this question for some time now. So even if they managed to answer it Maybe it's interesting for everybody else. So I think we should start with this. Yes There was some discussion going on about how hard is it to prevent this kind of attack and Is it possible to do some random sleep in the code to prevent The attacks. Okay. So the question was is it is it possible to fix it with just a random delay, right? No, that's really a bad idea I've spoken this at length at my 20 93 a talk so you can can have a look at that The reason for that is you will decrease the performance and the attack will still be possible. So this is not not a good idea You should just fix it in a code. It's possible and at least for open source code you have you have like the source code So there are some more questions and I ask everybody who's leaving to be a little bit more silent so that People who want to get the answers can hear them. Thank you Honored to think I Specifically I'm interested in hearing about how to mitigate these problems in the future You you were referring to sort of they the guys who worked on TLS Standardization they did make some mistake, but on the other hand the work is taking place in an open forum So there's a possibility for people to engage and that would obviously help But what are other ways to deal with those issues in the future? So the problem is really So TLS was in 1995 XML encryption did exactly the same errors in in someone in the 2000s when it was long known that this is vulnerable There's a new thing that is called Jason web encryption. Josie They did the same errors over and over again So we just see the same errors in protocol design over and over again, and they always argue that you need to You need to support these broken ciphers for compatibility reasons So they have like the they have the problem if they don't support the broken ciphers nobody will use the standard That's the problem Which is a pity sorry the last question from there In your presentation you talked a lot about pkcs1 1.5 Did you have a look at the PSS signature scheme as well and can you tell us if this is somehow affected by This problem as well like the the signature theme that is pkcs1 in version 1.5 I Don't think this is part of 1.5. The question is if the PSS signature scheme has this has a similar problem Not not that I know of