 Okay, hi, I'm Robert. I'm from your University Bochon and I'm presenting our work on scalability scanning an automatic classification of tears padding or occur vulnerabilities this joint work with the people you can see on the slide and So before we start I would like to get you on the same page what this talk is about so that we all can understand What I'm talking about later. So stock is about tears that's the protocol which you use in your browser for example if you make an HTTPS connection and We are today trying to attack this protocol and for example steer cookie to break a user session and The protocol itself consists of mainly two phases a handshake phase and an application data phase and in the handshake phase The cryptographic algorithms are negotiated in the cryptographic keys while the keys and algorithms are then used in the application data phase to actually encrypt the application data and Today we try to attack the application data so we can actually steer the cookies for example So the tears uses this concept of cipher suits on most of you probably know But cipher suit is a set of cryptographic algorithms which you can negotiate in the tears session So this is an example cipher suit and in this example We choose RSA as a key exchange algorithm We use a as is a block cipher and this block cipher is used in the mode of operations CBC and We use sha one as an HMAC and in the pseudo random function So this talk is mainly about CBC padding or occurred So we will focus on all the cipher suits which use CBC So if you are negotiating a cipher suit, which is not CBC you are not vulnerable But if you do you might be so Let's talk about the CBC mode first So this tears and CBC mode uses a concept of Mac then pet then encrypt This means that your data is if you have some data you want to encrypt you first compute an HMAC And then you'd have to fill this data up with additional padding bytes So you had some padding and depending on how long your padding is your pending look a padding looks a little bit different So for example, if you have one bite of padding just add a zero bite If you have two bites of padding you just add two one bites and if you have three bites You had three two bites and so on So it's the basis structure and the padding so after that you put all your data into the CBC encryption function And then you get some cipher text when which you can then transmit But how does the CBC encryption look like so I have a CBC decryption you sorry So this is the decryption So if you want to decrypt block of cipher text what you can do is you can just put it through a block cipher And then you compute the exclusive or with some initialization vector And then you get the resulting plain text And if you have more than one by a block of cipher text what you do is you use the previous block Exoid with a result of a block cipher operation to get the next place in text message block and you continue with that to get all the plain text message block and Eventually there will be some padding at the end of the message because You have to fill the message up So the CBC mode has an interesting property meaning that it's Malibu what does this mean that if an attacker flips a bit in the cipher text He will know that he will also flip the corresponding a bit in the plain text of the next block so you can inject arbitrary Bit flips in the plain text. So why is this problematic? What an attacker can do is he can just cut off for example the last part of a Cipher text and then suddenly the receiving server will interpret the message as padding and this can get quite dangerous So This is an example of a padding Oracle where a server receives Malfold message from a attacker and what he can if a server responds with If either if the message was invalid of the message was valid an attacker can deduce Information about the plain text of the message in this case namely that m2 x on this modification from the attacker is a valid padding and This can allow the attacker if he Continues to send method messages to the oracle to decrypt the whole message and this is obviously bad. So we don't want that so Why is this applicable in TS? So if you may have noticed yes has an HMAC so you would think oh if you manipulate the cipher text the HMAC gets invalidated this might be true, but usually you cannot Tell if the HMAC is valid or invalid before you have checked the padding This is because The HMAC is in an arbitrary position in this plain text Do you have to check the padding to find out where the HMAC is before you can check it? so in TS and Wunderbar server actually does not leak valid padding invalid padding, but he leaks usually invalid HMAC Invalid padding so you can still deduce the information if the padding was valid or invalid A secure server should always respond the same way and should not give an attacker the opportunity To know if the padding was valid or invalid So this is actually an implementation vulnerability. It's not a vulnerability in the standard in TS So we have been quite a few padding oracles in the past in TS and I'm quickly going to talk about the various types So the first one is the Vodane padding oracle tech and it's basically the first padding oracle tech on cbc mode and was Discovered in 2002 and it was originally not really exploitable in TS because in TS if you Receive an error like the HMAC was invalid the connection is closed and Additionally the error messages are encrypted. So even if the server sends different error messages, you could not tell that Which error message you actually got so There were later improvements to this attack which use timing to deduce the different error states and so on But this was the first kind of this attack Then later on there was the Poodle attack. So maybe you have heard of this attack It's a tech against sv3, which is an early version of the TS protocol and Sv3 has the vulnerability that it does not enforce the padding to be very strict So you have a lot of freedoms and the other padding bytes to choose and this can be exploited by an attacker So what an attacker does if he sees if you see some Message which looks like data HMAC padding what he can do is he can transform this message and cut off the padding bytes in the end and Move a block from the plain text he wants to decrypt into the end and the receiving server Will interpret the data in the end as padding and if this worked and the HMAC is still valid He knows or he knows some information about the data So this is quite dangerous, but this attack also affects some TS versions And there's nothing in TS which forces a server to validate that each padding byte was actually valid So the server can actually just check the last padding byte and then just happily continue ever on work perfectly fine Without any problems, but this can again be exploited for the Poodle attack. So This was actually found in a lot of implementations in the past so there are many names for these attacks and they are mostly oftentimes usually off by one errors and what These attacks taught us that you need to check each byte of the padding and you also need to check each byte of the HMAC So some implementations do not check all the HMAC bytes, which is quite weird, but this and then this does happen so Then I would like to talk about this CVE. This is an open SCV from three years ago and It was introduced when we tried to fix the Lucky 13 attack, which I'm going to talk about later and The problem here is that TS allows you to do more padding bytes when you actually want a need So if you just need 13 padding bytes and you use a yes, you could also use 29 padding bytes Yeah, the idea was that you could hide the length of the message with this feature and This CVE taught us that you could also create for messages which only contain padding so they do not contain an HMAC at all and this could When be exploited also in a padding Oracle tech So if your normal message looks like this, you could also construct messages which look like this So they contain two blocks of padding and an HMAC and the receiver of such a message cannot tell that there's no Data in it before he checked the padding so you might be able to trick the implementation into showing different behavior And it also taught us that you could do this so you could also Get rid of the HMAC and just send padding bytes and the receiver Has no possibility to tell before because He cannot check the HMAC so this was quite dangerous and There's another open SCV. I want to talk about which was quite surprising to me it was from last year and The important part of this TV is this year so there was an implementation bug in some mem compare function and it effectively reduced to only comparing the least significant bit of each byte and I was always like, okay, this is some weird architecture So this is not affecting all the open message implementations, but I thought like okay I thought it does not matter which bit you actually check but This gave us the idea that you actually need to check that the implementation checks each bit because maybe they only check the most Significant bits. Maybe they choose and check the least significant bits. Maybe they only chose to check those bits so this was quite interesting for us and Then I want to talk about the lucky 13 attack so the lucky 13 attack is also a padding oracle attack and Exploits a side channel which is actually present in the TS specification And the core idea of attack is that if you have longer padding this might result in a faster h make Computation and if you have shorter padding in this result might result in a slower h make computation The reason for this is that if the padding is longer you actually have to h make less data But if the padding is shorter you have to h make more data and this can result in this timing difference So in order to fix this vulnerability You have to have a constant time implementation, which is quite hard to achieve in practice if you will still want to be reasonably fast So but these timing attacks Like in the lucky 13 where you have to measure some h make computation timing It's not relevant for the stock. So this is quite hard as you can imagine There's a lot of room for errors because there's some network intolerances and so on So we do not consider any timing at this level at also our timings are in the second range So like 10 seconds or something so you can see it with your bear eyes And finally I want to talk about the robot attack and the robot attack is not a cbc padding oracle vulnerability but it's a bleichenbacher vulnerability that was presented last year at usenix and The interesting part for our research from this attack was that they found some new side channels So they found that some servers do not show different error messages when you send invalid messages But they actually show different behavior on the underlying layer so on the TCP layer So namely they could see that some times the server was still leaving the TCP connection open So he didn't reclose it other times he normally closed the TCP connection with the TCP finished message and other times He terminated the connection with the TCP RST So there are different interfaces you can call in the operating system to show these different behaviors and This was quite nice and we thought oh, they might be also relevant for padding oracle vulnerabilities cbc padding oracle vulnerabilities so Let's now talk about our research and padding oracles in mobile so We know that these padding oracles are known since 2002. So it's quite a lot of time for developers and engineers to Figure this attack out, but we asked us how common are we today in 2018 2019? So our idea was let's scan the Alexa top one million list and find out how many servers actually vulnerable to this attack But then we asked ourselves also how how would you actually do this? So we're quite a few ways to do this So first of what we wanted to know is which map or messages should be sent So as I've already introduced there are multiple message formats which you could do So with H make without H make only padding you could flip different bits and bytes in the padding You could different flip different bytes bits and bytes in the H makes so we were not entirely sure which messages So we should actually send when we ask ourselves Doesn't matter if he tests different versions So if a service vulnerable on TS 1.2 is it also vulnerable on TS 1.0 or maybe the other way around or other some Some statistical properties here do we need to test actually everything so other servers which are only vulnerable on one version The same for block cipher. So if you are vulnerable on triple desk, are you also vulnerable on a yes So in our minds naturally you would think probably yes, but we were not so sure We have some indication that this is actually not the case and we asked us have doesn't matter which key exchange Algorithms you use so usually it should be independent if you use RSA or elliptic curft if you hang on if you are vulnerable either You should not be vulnerable in the other Or you should if you're vulnerable in one you should also want to be vulnerable in the other and we have a very round so But the robot paper had some indication that this is also not the case for all servers for blightmacher So it might also not be the case for padding or cbc padding or occurs So what we did is we did some brainstorming session and we came up with different math or messages Which I would like to present here. So the most trivial ones is this here So it has some data is that has some HMAC and it has some padding and the padding is actually flipped in the last position And we created variations of this attacks or what we could find was bit flip Errors so we flipped once a bit in the middle of the padding and once a bit in the end of the padding or We also did the same for the HMAC. So maybe some limitations are not checking the entire HMAC So we create the variance of that too and we also created combinations of the two so Some flip bit flip in the HMAC some bit flip in the padding When we came up with those special vectors Which do not contain Application data, but they still do contain padding and they are all actually the same length So a receiver of such a method messages would not be able to tell if it's one of these messages Or one of from the slide before before you can it has decrypted the message When we came up with these two messages So what we thought is so maybe if there is not after you deep headed the message There's not enough room for the complete HMAC. Maybe some servers would leak different behavior and what we did is we removed the first byte of the HMAC and once the last byte of the HMAC so So there's a partially valid HMAC in the record and Finally we came up with was mail from messages from CV I talked about earlier which contain only padding and once where they only contain valid padding and once where they Contown only padding but even that padding is invalid. So there's not enough room in the message to fit for whole padding So we came up with 25 mail from messages in total Then we built a tool based on TS attacker, which is the framework which was developed by URI in 2016 on for CCS and it allows you to send arbitrary TS Messages with arbitrary TS contents in an arbitrary order and this is quite nice for so we developed this framework since Three years now at our chair. So it's quite mature now and based on our tool we built on top of TS attacker we built TS crawler which is Distributed crawling infrastructure I'm not going to go into the details because not very interesting a lot of engineering just and it's built on top of MongoDB and Redis to basically crawl a large amount of service at the same time so Now I want to talk about some difficulties we had during scanning how we take it those problems So first off I wanted to talk about non-determinism So we had the problem that some servers if you send a mail from message to them They might respond with a bad record Mac, but if I send another mail from messages You might get no response. So It's the server vulnerable because we did not receive an answer yet. So maybe we should just wait longer Maybe it will answer eventually So this is quite bad if you want to scan a large amount of servers. So what we did is we said, okay We wait always one second after we send a mail for messages or whatever the server responded with we will take as the answer from the server So but this still has a problem It might be that the server was just on a high load and it eventually answers with a bad record Mac So it's actually not vulnerable even after one second. So it's not a silver bullet here So this confuses us if we want to say that service vulnerable or not But even worse we had servers which responded to a mail from message a with a bad record Mac And if you send the same message again, we suddenly get a different alert message So this makes it even worse for us and we are totally confused what we should say in this case It's the server vulnerable. I don't know So what we did is What we believe the reason for this is that there's some content distribution network or some router or no behind the scenes which is actually Distributing our packets to and our handshakes to different servers and these servers are Maintained in different configurations. So the one server might be not vulnerable and respond always with bad record Mac The other server might be not vulnerable and always respond with record overflow But we sometimes get this weird non-determinism our scanning results. So it was quite bad So if we think during the scanning process that the server is vulnerable We rescan the server twice and we check that he responded on each and every message every time identical And if he did this we consider the server is actually vulnerable and if it's not if it says some variants in its answers we consider it as Not relevant for the study. So we exclude it And we had another problem So if you have 25 messages and you want to scan all the available cipher suits to find all the possible vulnerabilities and Maybe to supported versions you end up with already a lot of handshakes You have to do for each server and with a rescanning on vulnerable servers Which gets even worse and if you want to scan the Alexa top 1 million list which may contain 1 million servers You end up with a lot of handshakes. So what we asked ourselves is actually necessary to scan all the different cipher suits This is necessary to scan with all 25 messages or maybe our messages Just bad and we did just choose them wrong. So we came up with a minute brainstorming session after all and our solution was that we test 50,000 servers and Check what is actually necessary to scan so maybe we can cut some corners for the larger skin of Alexa top 1 million list So what we did is with within this prescanning phase We scan with TS 1.0 and eva TS 1.1 or TS 1.2 because they look very similar We scan with all available cbc cipher suits from the server and we scan with all the 25 method messages and check for check the results for Yeah, so From the results with it shows that yes, you actually do need to check different TS version So some servers are only vulnerable on TS 1.2, but not vulnerable on TS 1.0 so If we want to find other routes, we need to check that Block ciphers. Yes, some servers are only vulnerable on triple desk for example and not on AES And the other way around but they still support the other mode so This bad and key exchange algorithms sadly. Yes So there are some servers which are only vulnerable if you use AES CBC and RSA, but they are not vulnerable or if you use AES CBC on ecliptic curved if you have one so if you want to find all the vulnerabilities also a key exchange algorithms have to be scanned and Finally, we looked at the messages which were required to find all the vulnerabilities So if you we would have sent only those four messages during the evaluation We would still found the same vulnerable servers. So there's quite a lot of Improvement we can do here. So all the other messages are not entirely relevant if you just want to know if the servers vulnerable or not So when we go went to scanning by Lexa top on million is with exactly this configuration so all the cipher suits two sets of versions and These four for messages and looked at those results. So this took us roughly 72 hours with all the rescanning and Roughly 78 percent of the servers responded on port 443 So they wanted to speak TS with us and from both servers at at least 1.83 percent are considered vulnerable So they responded identically to three rescans the same and they were vulnerable on all three of them in the exact same way and This is quite a lot for 2018-2019 so 17 year old vulnerability So what we asked ourselves is how many actually different vulnerable implementations that we had so this is all just one Vulnerable implementation are they actually multiple implementations at work So what we then did is we think I printed all the vulnerable servers in a way with where we send all the 25 mail from messages and Create some sort of finger print which you could use to compare the vulnerabilities so These fingerprints look like this so for in this example on the left side You can see the message we send and on the right side you can see response from the server so in this case it responded with a bad record Mac and the TCP thin and If you add all the other messages you suddenly get something like this and you can see that There the server is actually vulnerable because it has a behavior difference So it responds different to our mail for messages. So an attacker can observe this also In this case with a record overflow So in total we found 93 different vulnerable finger prints So if you assume that there's no possibility in implementation to change your fingerprint because why would there? This means that we are likely 93 different vulnerable implementations deployed in the Lexa top 1 million So this was quite bad, but we wanted to cluster those vulnerabilities even more So we've discovered that some servers are Not vulnerable in the same way even all if they have the same vulnerable fingerprint So in this example all the servers have the same vulnerability fingerprint So they all respond to the same mail from messages and they're exactly the same way But they are not vulnerable on all the cipher suits of their support in this example server a is only vulnerable on AES 256 cbc char and this is not vulnerable on triple desk, but it supports triple desk So the B is vulnerable on both cipher suits and server C is only vulnerable on AES 256 but it does not support triple desk. So we could not test if he's vulnerable at all So what do we know from this? So we know that server a is clearly not server B because You cannot configure your triple desk implementation to not be vulnerable. So they are likely using a different implementation And we also know that a could be the same server server C and B could be the same server services So they are not contradicting each other So what we did is to find even more vulnerabilities as we Rent some clustering. So what we did is we draw some graph where each node in the graph Is a server we scan for and when we drew an edge between these nodes if the server could be the same Implementation so if they could not be no edge if they could be the same They all drew an edge So then we asked ourselves, okay, there are quite a lot of service. How do you actually visualize this? So to do this we used the Gafi software, which is a graph software, which you can manipulate large graphs and the force at this to algorithm The force at this two algorithm is a simulation based Graph-trying algorithm. So what it does is it rent some sort of physical simulation where each nodes generally repel each other while edges force the nodes to attract each other and then it's just Let's the weights run out and there's some Distribution and this is what I'm actually going to show you now How this looks like so This is the Gafi software and here are is our graph and as you can see you can see not a lot because There are a lot of edges and a lot of nodes, but you can actually pull them aside So you get an idea of how many edges there and what I want to do now is I want to color these nodes So that you can actually seek a little bit more and what I'm going to do is I'm gonna color these nodes based on their degree So based on their number of edges So all the nodes which have the same number of edges get the same color and I can do this like this And suddenly you can still see not quite a lot, but a little bit more But now you can run the force at this to algorithm and I'm actually going to run its slow motion Because it looks quite cool if you do this But it will actually cluster the vulnerabilities for us, so I'm going to start this now And you get something like this As you can see this is a physical simulation sort of so you can see still see some movement So it will never stop to wiggle around But what we can actually see is that there are at least two big groups of servers and I'm going to analyze them now on the slides back again, so Okay, so this is basically our example. I just rotated it and shows different colors and What you can see is that the top group so the green group is actually the ones which is vulnerable on both surface suits While the tier group between the two bigger groups of the ones which are only vulnerable on triple desk So there could be an either group so either the big green group or the purple group So we have edges with both so we are torn apart by those larger groups and the group below is Not vulnerable on a yes, it's only one of the on triple desk So it clearly is not the same implementation as the green group But it could be the same as the tier group and also there's the one some service in red and at the bottom You can see so they are red because they have a different degree because they do not share Edges with the tier group. So they are very likely purple, but they are very likely not tier so You can use this information now To pick the biggest sides of each group and to contact the vendor to try to ask them Politely if they tell you which implementation is responsible for this So now let me talk quickly about exploitability. So a Big factor of if you're actually vulnerable to this the techniques actually apply to this the fact if it's observable, so This is an example of a vulnerable server So sometimes responds with a bad record Mac sometimes responds with record overflow, but in TS in general Those alert messages we during the scanning process We have the keys for the for those messages so we can decrypt them, but not during the exploitation phase So if we had the keys, we could also decrypt the message. So we have to See this difference without having the keys So what we actually see is we see two encrypted alerts and we as an attacker have to differentiate them So it's not trivially in some cases But in other cases we actually get some side channel for example this case We get the two encrypted alerts in both cases, but sometimes we get a TCP thin and sometimes we get none So in this case, it's clearly for an attacker You can just scan and look at the behavior of the server and then he knows if he receives a thin the padding was What was it a record overflow and in the other case? It was a bad record Mac So this can be explored by an attacker. So this is observable recall this and there are other cases where you have something like This so sometimes you get only one alert or two alerts. This is also clearly observed by by an attacker He does not need imperfect side channels to deduce if The padding was valid or invalid. He can directly see this So if you open wireshark, you can also see this. So there's no no sub nanosecond side channel or something So and then we classified our padding oracles in different groups namely weak strong and poodle oracles so the poodle oracles usually do not check all the padding bytes of the method messages and But they still require invalid h-max. So if you would want to exploit them You would need to run some poodle style attack so it's always differs a little bit depending on the exact vulnerability, but this is your general attack strategy here and They are definitely exploitable because the poodle oracle attack actually works. So This is definitely true and then there's the strong Oracles so these can be exploited with a classic Padding or okay as you would see it in a textbook. So there's no not much magic here But then there's the weak oracles and the weak oracles oftentimes require more than one block of padding to be To show this behavior difference And if you want to exploit this this can get quite problematic as I want to show you now So when I showed you this graphic where I showed you that an attacker can introduce bit flips I actually liked it quite a little bit. So maybe I've seen it because if an attacker flips a bit in C1 He also flips the plain text of message M1 to something completely random Which he cannot control and this makes it quite hard for the attacker to construct all arbitrary mail-for-messages from an HTTP request so And this is just one example So sometimes this attacker is limited in a way to create this mail-for-messages which create Show the behavior difference. So we call these oracle weak oracles and we consider them not exploitable because they oftentimes allow you only to reduce To decrypt one block of plain text or something and not consecutive blocks So in total we consider a server to be a padding oracle to be exploitable It's either a poodle or strong oracle and it is observable So an attacker does not need any additional side channels or tricks to see the behavior difference and from our scanning We could show that sixty one point four percent of a vulnerable source actually observable So most of them and in total fifty seven Fifty-seven percent of the vulnerable source are practically exploitable So they have won't either a poodle oracle or strong oracle and they are also observable so Let me go to our findings now. So We found quite a few CVE. So we found over which is an open as C tricks a five sonic war oracle and We could not attribute all our vulnerability. So we politely ask the website owners if they could tell us which implementations They use but sometimes we tell told us sometimes we didn't and then we cooperate with the vendors to Actually fix the one to get a fix for vulnerability and the most prominent one is here the open as a vulnerability and it was actually found with help of the Amazon security team and This one which is very special because we obviously scanned open as a before in a lab setting. So we actually Checked and it was not vulnerable because there's an exam application with open as a which we tested and everything was fine So we were quite surprised when Amazon told us that this is actually open as a which was vulnerable and the problem is that Open as a response differently if you use the API in a certain unintended way so And this is how we saw the open as a vulnerability So you may you may be able to spot the vulnerability So as you can see the response from the servers There's the TCP finished message missing and the messages which do not contain application data but do contain valid padding but an invalid HMAC, so it's the Poodle style vulnerability and This is quite bad, but there might be other vulnerabilities which just showed to us differently because depending on the application They might respond a little bit differently, but the general pattern is the same so during this closure process we notified the biggest sites and and Try to get those problems resolved and as you can see we were quite unsuccessful with that So from five reports, we got to No response or they just didn't care and we have two times we get Non-applicable, which means You get negative points. You should not bother them with such attacks again and actually only one side Fix the vulnerability by disabling cbc cipher suits and they gave us seven points. So in total we got minus minus three points on Hacker one so If you also want to get minus points on Hacker one You can download our tool TS scanner. It's on Github You can also check for padding Oracle vulnerabilities and maybe you can help attribute those vulnerabilities because there's certainly a lot of vulnerabilities which are not attributed yet and What I'm going to do now is I'm going to show you a demo office to us. So you get an idea how this looks like So Yeah, I have Open a cell and an old vulnerable version So it's not the one that we found but it works quite well in this demo and on the left side You can see our tool TS scanner and what I'm going to do it's written in Java So excuse me, but what you can do is to specify to which server you want to connect So I'm running local hosts. I'm scanning that and When I say I want detailed Reports so we can actually look at the padding Oracle vulnerability so if I run this it will take some time because I'm running it in single-threaded mode because I Do not want to over them the single-threaded OpenSSS server with requests and After some time we should get a report if the server is vulnerable or not So let's wait some seconds. Yeah, it's quite a lot of handshake. Yes Okay, actually, I think I'm not going to let it run to the end. I think it takes like two minutes What I'm going to show you is this year. So this is the finished report. So So it gets a lot of noisy input because there are a lot of Cypher suits so you can see basic information from the tool like which Cypher suits it's a part similar to other TS can ask and it also reports you about the Vulnerability to service and as you can see this one has a lot of vulnerabilities But for us the most interesting one is this year and it's vulnerable to padding Oracle sets true And what you can see is oh, it could not identify which server this year was but I scanned and show you something like this So you can see the different Cypher suits will we scan for you can see the different version We scan for and you can see if we found a different behavior difference. So in this case RSA EDR and CBC mode seems not to be vulnerable but if you look here There's an AES Cypher suit and it's actually vulnerable because it says you can differentiate the alert message contents So it's vulnerable and what you can see below is the actual response fingerprint. We got so On the left side. There's this graphics I showed you before encoded in some strings and on the right side you can see the actual responses so to most messages it responded with a bad record Mac alert and it's In the Mac alert was encrypted and then it closed the connection with the TCP fin but for these two records it's responded with a record overflow and Also close the connection. So it's not observable But it's definitely one of them Okay, I think with time for another demo or I think I skipped it. So So let me come now to our contributions and conclusions. So we found 93 different vulnerabilities in that extra top 1 million We will try to responsibly disclose our findings as good as possible to the affected vendors and websites and We released open source tools that you can actually reproduce our research and Find the vulnerabilities yourself So in conclusion, I hope we are convinced you that large scale scans can help to uncover new vulnerabilities which do not show in lab settings because actually servers sometimes use for software in a different way and What I also want to emphasize is that cbc With an end Mac then in crypt scheme is really really hard to implement correctly So it has to be side-channel free completely. It has to be constant time. It's quite hard And so maybe it's time for us as a community to remove cbc support entirely from the client software as well as from the server software And with that, I'm Ready for questions Okay, if you have any questions, please come to the micro and maybe introduce yourself So I'm John Kelsey. Hi nice to you So I just wanted to ask you said that there were 93 different fingerprints that you found It's hard for me to imagine that there are really 93 entirely different implementations of TLS. Maybe that's just me being naive I'm a cryptographer. I'm not a software guy, but I was kind of wondering if it sounds like you found an instance Where just the same toolkit was being used slightly different ways Giving you like with open SSL I was wondering if you think that you where you think this large number comes from like could it be hardware, you know like I know sometimes you'll have assembly language Implementations for different hardware that seems like that's a place for you to get very different behavior. Yeah, so I think the most probably Reason for this is there's a long history of TS version. So even if you run a Now secure version and maybe run an order version of that same one which is one of them Maybe the vulnerability changed among different versions, but the most thing I learned Just recently is that there are some vendors which have multiple products in combination So they have some application firewall and some servers and maybe both are vulnerable and very do produce some weird combination of Vulnerability and this is why we sometimes see those those large numbers But if you would look at the distribution of our vulnerabilities, most of us have the same one which is so they're like 10 prominent ones or something And then there's a large number of vulnerabilities which are only affected by force or something I don't have any question. I just bought at your mistake on one of the slide. Can you go to the results slide? Excuse me. Can you can speak up? Sorry, I don't have question, but I just bought at your mistake in your one of your slide. Can you go to the results slide to which slide results? The narrating the results you are talking about, right? The previous one. Yeah, the third one six four nine three is probably is not a fi CVE. I think it's six five nine three Okay Okay, thank you, okay, thank you very much. I think we have to correct it on our website Okay, thank you, please think about again