WEBVTT 00:00.000 --> 00:12.480 So, let's come to the next talk, which is mine, and the title of this talk, I like it very much. 00:12.480 --> 00:19.480 It's worth implementing StarTierless, and I like the title very much because it's a bit ambiguous, 00:19.480 --> 00:28.240 because on one hand, if who was last year here also at the modern Eme Teflon, oh, yeah, I would try. 00:28.240 --> 00:34.000 Okay, so last year I invited the colleague from mine, and asked him if he can do a talk on StarTierless, 00:34.000 --> 00:40.520 until the audience how bad it is, and this year it's kind of funny that I did a talk to tell you how to implement it, 00:40.520 --> 00:47.360 but there was a catch, and to awake myself up a bit, who knows what StarTierless is, can we race, can there race the hand? 00:47.360 --> 00:56.680 Okay, now can you keep the hand up, and everyone who doesn't implement it, put the hand down, so only the ones who implemented it, keep it up. 00:56.920 --> 01:06.520 Okay, and from this person, like who thought they like it, or wanted, and who, or did you feel that you need it to implement it? 01:06.520 --> 01:11.640 Like if, so only keep your hand up, if you felt like it's a great protocol, I will, I will. 01:12.840 --> 01:22.840 Okay, one, okay, now I mean if you require to do it, then it doesn't count, so only what you think it's a good thing to do, and... 01:22.840 --> 01:46.840 Okay, yes, example people talking, okay, maybe something else, yes, yes, I will come to that, yes, okay, so, and from those people who implemented it, you can come to me after the talk and tell me if you did like, I tell you to do, or what I propose, not tell, but I have a proposal, so you can tell me if you like it, or if you did it differently. 01:47.800 --> 02:11.880 So the catch is, I want to avoid most of Stateles, not fully, because there are some providers like Microsoft for example, and for submission, they only have Stateles, so you, yeah, but you have to do it, so there will come a time in your life that some, some user of your libraries asking you desperately to support Stateles, and you can ask like, why do you need it, do you really need it? 02:11.880 --> 02:41.800 Ask your provider, please, to do something better, but in the end it's a fight that you may lose, because some people just bigger than you, and then you are in a position that you need to implement it, so let's try to, to do it, but the short recap, like when you think about Stateles, when we look into the Stateles, it's look super simple, right, so I would do it with IMAP, because this is the protocol where it's, in general, more, most complicated to do, so I will use this, but when you connect to, to an IMAP, 02:41.800 --> 03:10.800 server, the first thing that happens is that the server sends you it's greeting, and in this case, the server is very nice to you, and it tells you I can do Stateles, and please don't lock in, because this would reveal your password, in, in the clear text to the internet, so at this point already, you know that Stateles is, Stateles is supported, so you sent the Stateles command, and the server says, I'm fine with that, and then both, this sounds real good, 03:10.800 --> 03:39.800 and then both can do the TLS handshake, so client hello, server hello, key exchanges, finished message, and then we continue just as normal with the normal protocol, but encrypted now, so it's bold on the bottom, so this means it's encrypted, so this is the happy path, we have a plain text face, that is bad, and we have a TLS face, that is good, because authenticated encrypted, this is a good stuff, then comes the little bit more realistic path, 03:39.800 --> 03:55.800 is that not every server is nice to you, or implements the implements Stateles or capabilities as you like it, so maybe you don't know, just by looking at the greeting, so you need to ask for it, so if you want to implements Stateles is a really defensive way, 03:55.800 --> 04:05.800 like to not issue the command if you're not allowed to, then you first have to ask for the capabilities, and then you get the capabilities, then you check the capabilities, and then you do the command, 04:05.800 --> 04:19.800 but some servers also do something like this, I saw this in the real world, they sent you the greeting, and then the next message tells you the capabilities, so maybe if you want to be more performant, you also have to look if you see the second message already, 04:19.800 --> 04:29.800 but what happens here now is that you already expose quite a bit of the item of passing logics, already to this, like if you think from code surface, only this to messages, 04:29.800 --> 04:38.800 greeting in the response, expose almost your full passing logic to the server, at this point already, this will become important. 04:39.800 --> 05:07.800 And the sad part is that you should forget about anything of this, because this is non authenticated, not authenticated code, this means you don't know if you are talking with an attacker, so the attacker can just strip these things to tell you the server doesn't do Stateles, and in the worst case, you will continue with plain text, it's normal Stateles stripping attack, it can say in the last message, oh well no, I cannot do it, it can even hear, tell you, oh well, you have a gazillion, 05:07.800 --> 05:36.800 you have gazillions of new messages, it can tell you here, there was a new folder created, so you might think about what clients would process this, but it's really not obvious that you should not do it, so for example, he was in case in Thunderbird, that you can just create messages, like a fold us really before Stateles in a completely different state, you can send alerts already, there are some very helpful clients like outlook, they will show it to you and saying it's really high importance, 05:36.800 --> 05:48.800 so you can imagine if you just sent an attacker alert message that says you should do an outlook update, you will get this message and maybe it's very convincing to do it, 05:48.800 --> 06:01.800 and then there can be a situation like this here, which is kind of now it gets really confusing, like what should this mean, like is this now TLS data, or not what should I do with it, so things come here that are not really clear, 06:01.800 --> 06:18.800 and we did a paper on it a few years ago, and the black circles are bad, so as you can see from, like I think it was almost 30 clients that we tested, in all of them, but two, it's bad that Katty is not here there, okay, nine, Thunderbird guy, 06:18.800 --> 06:25.800 because this was almost the only client that had no issues, so they were from 30 clients only two had no starting decisions, 06:25.800 --> 06:38.800 so they can see, so it's really a systemic problem, but you can look up the details in this paper, okay, so now my line of thought was, 06:38.800 --> 06:50.800 the data we fought TLS cannot be trusted, this means the data we fought TLS needs to be ignored, to avoid these attacks that are showed to you, 06:50.800 --> 07:00.800 which means the data we fought TLS may be, if we take the seriously, it doesn't have to be passed at all, because why are we already exposing our paths to untrust the data, 07:00.800 --> 07:10.800 which means, for me, start TLS is basically just a prefix that I want to skip as fast as possible to get to this good TLS encrypted face, 07:10.800 --> 07:22.800 it doesn't matter how, just skip it in a good way, so the idea here is now, let's consider we are only implementing plain text, like no encryption at all, 07:22.800 --> 07:32.800 we do some TCP connection, this is like rust, pseudocode, we do a TCP connection, and then we move this connection to some client, 07:32.800 --> 07:41.800 that then does either, this works, if this would be an implicit TLS connection, which means like directly doing TLS on port 99 freefrog example, 07:41.800 --> 07:49.800 then we have an extra step, we first do TCP, then we shovel the TCP streamer part, and then we shovel the TLS wrapper into our client, 07:49.800 --> 07:59.800 which doesn't, it's not aware that TLS was even used, so this one extra line, and what I want to propose is that for start TLS, we also have just one extra line, 07:59.800 --> 08:08.800 which is this do start TLS prefix, so we connect on one for free, which is the start TLS port, the plain text port, then we do prefix code, 08:08.800 --> 08:16.800 just one function, no context, no status, nothing, just one function, and then we continue as it would have been a secure connection, 08:16.800 --> 08:24.800 like just give it to the TLS layer, and now we can discuss how this start TLS prefix function can look like, 08:24.800 --> 08:33.800 with less, it's a little code as possible, we first need to skip the greeting, and the good thing about command, and as you may notice, 08:33.800 --> 08:39.800 we don't care what the server centers, because we don't trust the server anyway, we just send the start TLS command, 08:39.800 --> 08:48.800 and then, okay, so this is the start TLS, and then you may wonder, I said first comes the greeting and then comes start TLS, 08:48.800 --> 08:53.800 and you may notice, we have these three gibberish lines in there, so what happened with that? 08:53.800 --> 08:59.800 I think you should think about IMF, as having two separate connections, you have the client stream and the server stream, 08:59.800 --> 09:06.800 and you need to sort them, and they should still make sense, so how you should think about this really is that we read the greeting, 09:06.800 --> 09:13.800 then we let the rest be as it is, so the state that we are in this actually, that we then can send the start TLS command, 09:13.800 --> 09:23.800 and now we can try to care what happens with the rest of the data, and task for us is now to just try to skip it as fast as we can, or as easily as we can, 09:23.800 --> 09:32.800 and we can do it easily, because we can just, when we look here, we have it in our hand, what the tag was for our start TLS command, 09:32.800 --> 09:39.800 and we used S, the S tag, so what we can do is just, we read lines, as many lines as we need, 09:39.800 --> 09:48.800 and when one line starts with S and white space, this is the end of the start TLS command, so this is the code that we should use for that. 09:48.800 --> 09:54.800 Okay, so basically this skips all this block, and then comes this trailing data thing, 09:54.800 --> 10:01.800 and our paper we called it a buffering class of the text, you can do command injections and response injections with it, 10:02.800 --> 10:12.800 but this trailing data, I would would propose just forget it, if we do nothing about it, it will be interpreted as TLS data, and the TLS handshake will crash. 10:12.800 --> 10:20.800 Let us just crash the TLS handshake, there is no problem in doing so, so we ignore it and just doesn't handle this case. 10:21.800 --> 10:33.800 And yeah, well, and why does it work? So, this works because we just proceeded with the connection to a point where TLS would be made, so this is the second line, 10:33.800 --> 10:42.800 and if this is the point, we can just assume that we have a fresh implicit TLS connection and just proceed as we did before, so this is the point. 10:42.800 --> 10:51.800 There's one caveat though, because if we look on the differences of the start TLS connection and an implicit TLS connection, 10:51.800 --> 11:00.800 what you will notice in the start TLS case, the server sends us the greeting, but after the TLS handshake, there is no second greeting, 11:00.800 --> 11:08.800 so this means when we strip all this prefix, we need here to be a bit more careful because this greeting will not happen here. 11:08.800 --> 11:17.800 So, when we do this scripting, we have to say our client that it doesn't need to await the greeting anymore. 11:17.800 --> 11:25.800 So, this is the one thing that I think is needed somehow, to tell the client that it should not await the greeting because it will not come. 11:26.800 --> 11:40.800 And yes, when we look on this table again, this is why I choose IMAF to do to explain this procedure, because I think it's the protocol where most people are doing mistakes, 11:40.800 --> 11:53.800 because in IMAF you have to handle responses at any time, it's very complicated, so this are the clusters that you see, and for example, in this tampering attack, it's mostly IMAF related and negotiation was also full of errors in IMAF, 11:53.800 --> 12:02.800 but there are some other clusters, for example, with buffering, and this we will avoid too, but just to make it complete. 12:02.800 --> 12:11.800 The idea that I tell you, you can apply them to submission, pop free, LDAP, XMPP, even HTTP, and this material told me DNS, 12:11.800 --> 12:24.800 started in DNS was a thing, I didn't do it, yes, so it started as a kind of everywhere, but you kind of apply their ideas also to other protocols, so for here, for example, in submission, 12:24.800 --> 12:36.800 you will need to know the service sense you're greeting, the greeting is multi line, but you can just read the lines as soon as you get the 2, 2, 0 and then white space and just strip it. 12:36.800 --> 12:46.800 Then, sadly, by the standard, you are required to do the ELO before start L, if you like it or not, so if you try just try out some popular service, you will see that you cannot do start L, 12:46.800 --> 12:57.800 as directly you have to do the ELO, so, yes, a bit sad, but you need to do it, but the skipping is basically the same, and submission is simpler than an IMAF. 12:57.800 --> 13:07.800 And then comes pop free, and the pop free is really simple, you just read the line, write the line, read the line, and then you do the tailors, so this is the pop free case. 13:07.800 --> 13:17.800 Okay, and now I'm happy to get some questions because I left some things out by intent, and I'm happy if someone spots them, okay, that's it. 13:17.800 --> 13:27.800 I think you are touched. 13:27.800 --> 13:54.800 So, I'm just wondering about, I noticed that you do very, very simple here, but maybe a slide in this simple room where you would have a free logith answer, but I only have the spam stop, but you want to understand free logith, and then you would use that to ask the date, so you would be able to do a slide in more, like, pretty possibly, you get everything that you might need in the next phase. 13:54.800 --> 14:17.800 Okay, so you're suggesting what's basically to use a subset of this full-fledged passing routines, to just get some meaningful information or important information from this prefix phase. 14:17.800 --> 14:27.800 I would say why, because you cannot trust anything of them, and I would even say, don't make it so simple for an etiquette to strip your connection. 14:27.800 --> 14:35.800 If the etiquette can just do a bit flip and say, start it, let's know, or just strip the start it, let's capability, don't listen to them. 14:35.800 --> 14:41.800 Do your thing and let them really break your connection, let them work for it, so let them let it be so simple. 14:41.800 --> 14:44.800 Yeah, I think you are second. 14:44.800 --> 14:50.800 Yeah, so avoid start-tales. 14:50.800 --> 15:08.800 I hope not, so I try to, so in my software, I have it feature-gated, so you need to enable start-tales with a compile flag, because I want to not, our whole community to not use it at all. 15:08.800 --> 15:17.800 But it will happen, if you have a project that is a bit more popular, there will be this university that has an administrator that didn't configure implicit TLS for IMAP. 15:17.800 --> 15:26.800 And what do you do? I mean, this is why I say you can then ask your, the ones who file the issue to you, you can ask them, like, why do you need it? 15:26.800 --> 15:35.800 Can you please ask your service provider maybe to enable implicit TLS? But if they say, no, if there's someone unreasonable, what do you do? 15:35.800 --> 15:46.800 So you cannot let your users hang in. So this presentation is, if you really, really need to do start-tales, try to avoid as much of it and just do the minimum amount to use it. 15:46.800 --> 15:52.800 But try to avoid it whenever you can. 15:52.800 --> 16:02.800 And you wouldn't do anything before, you know. 16:02.800 --> 16:21.800 So the question, not sure I can repeat the question, even. So the proposal was that that we not should use us, and this allows specific commands, if start-tales was not made. 16:21.800 --> 16:27.800 That's what's not made, right? 16:27.800 --> 16:41.800 Yeah, yeah sure. So this thing is there. So if you are on the beginning, there was this lock in this Abelit thing somewhere that I showed in this happy path. 16:41.800 --> 16:50.800 Yeah, this thing, for example, log in this Abelit, this is an attempt to do it, because this, this, when this capability is present, it tells you you must not log in. 16:50.800 --> 17:01.800 And when you try to log in, you will get an error. 17:01.800 --> 17:12.800 Yeah, it should not do it. So yes. But then why do you want to keep start-tales then? So just don't you start-tales then, because I'm not sure I get the point. 17:12.800 --> 17:18.800 But maybe you can come after to me and then we can discuss it. 17:18.800 --> 17:25.800 Okay, did someone spot things that can go wrong with a B9 server, maybe? 17:25.800 --> 17:35.800 Are you convinced that this is a good idea? Maybe asking where's aunt, don't know where he is, okay. 17:35.800 --> 17:51.800 So what will happen is the assumption is always that you don't listen to the server, and the TLS handshake will always fail. 17:51.800 --> 18:05.800 So if for some case, like here, if this no response would be a B9 response, like the server just for some really good reason, I cannot do start-tales, but now if this would be a B9 response. 18:05.800 --> 18:13.800 What would happen in this case is that you still try to do start-tales, because you would assume that the server told you it's okay. 18:13.800 --> 18:20.800 You will send your client hello, and then you will get an IMAT message back that tells you that in the TLS handshake will totally fail. 18:20.800 --> 18:30.800 Because the passers will fail, the handshake will fail, etc. So yeah, but this is a good point that you say, because one downside of this solution is that you might get weird errors, 18:30.800 --> 18:37.800 because now instead of saying the server didn't support start-tales, the error message would be TLS handshake fail. 18:37.800 --> 18:46.800 So the thing that you also have to keep in mind is that you report some generic start-tales failed error in any of these cases. 18:46.800 --> 18:54.800 So you do your thing, but in any of these cases you just ignore it and say start-tales failed for some reason, and maybe then you have a debug clock to see what really happened. 18:54.800 --> 18:56.800 Like for the users that can do it. 18:56.800 --> 18:58.800 Yeah. 19:26.800 --> 19:37.800 So this was one of the candidates, congratulations. 19:37.800 --> 19:45.800 So there is one case with the preoff, but what was it? 19:45.800 --> 19:46.800 Yeah. 19:46.800 --> 19:52.800 So what a server can do, it can tell you, in the greeting, you don't have to authenticate, because you're already authenticated. 19:52.800 --> 20:00.800 And this can be, can make sense, for example, you're connecting to, I'm a VSH or something, or locally just to manage your server. 20:00.800 --> 20:09.800 But when we did this research, this preoff thing was a very common attack that was where we were able to do a start-tales stripping attack. 20:09.800 --> 20:15.800 Because when you look in the standout, it says that the start-tales command is not allowed in the authenticated state. 20:15.800 --> 20:20.800 So when the server says preoff, and the client says I want to do start-tales, you have a conflict. 20:20.800 --> 20:23.800 And this thing doesn't work together. 20:23.800 --> 20:31.800 So preoff always excludes start-tales, which is why I think that preoff must be an extra configuration in your client. 20:31.800 --> 20:38.800 You must say this, I know that this connection is preauthenticated, don't do like start-tales or any encryption. 20:38.800 --> 20:44.800 I think this is the only way, because otherwise you don't know, it's a weird state to be in. 20:44.800 --> 20:49.800 Like wanting to do start-tales, but not being able to, because preoff forbids it to you. 20:49.800 --> 20:51.800 Yeah. 20:51.800 --> 21:07.800 In such a case, when it makes sense, in the configuration of the client, then it expects a TLS or a connection, and it gets pre-authenticated. 21:07.800 --> 21:11.800 Yes, this would be one way to do it. 21:11.800 --> 21:18.800 So you can decide like, this is a suggestion, you can do when you feel like it, you can do slight passing of it. 21:18.800 --> 21:24.800 Just the aware, this is all lower case, the casing is important, you can just do like if start with preoffs. 21:24.800 --> 21:30.800 You have to lower case it first, and then preoff, you can do a bit of passing to make better error messages. 21:30.800 --> 21:36.800 But I would still say if you put in the configuration, I want to do start-tales for example, then it must not be preoff. 21:36.800 --> 21:46.800 But let it crash, and then you will figure out, because there will be some configuration issue, and it's starting less related, so I think maybe a generic message would be still enough. 21:46.800 --> 21:49.800 Yeah. 21:49.800 --> 21:58.800 When you will figure out if you apply to a computer account, if you don't want to say, you know, TLS or start-tales or, you know, that is basically a letter. 21:58.800 --> 22:05.800 So if you don't want to have it in any client, you specify the start-tales, you know, for the variable, you know, that is pretty much all. 22:05.800 --> 22:11.800 Yeah, so when I showed this table, it depends. 22:11.800 --> 22:22.800 Yes, so a lot like not a lot, but so I think there was a shift in this start-tales opportunistic community, opportunistic encryption community. 22:22.800 --> 22:31.800 In past times, we thought that start-tales would be opportunistic, like just do it when it's available, but this is the thing of the past since I don't know 10 years or so. 22:31.800 --> 22:37.800 I verified some software, I don't know the software from 10 years ago, and even then it wasn't fast. 22:37.800 --> 22:45.800 But still some clients, I think, to a free of them, were just like, oh, I cannot do start-tales, okay, they're not, and then it just put the password in practice. 22:45.800 --> 22:55.800 So depending on the client, some cloud may provide us still did it too, so it's the thing that keeps reappearing over time somehow. 22:55.800 --> 23:12.800 Yes, you can look up in the paper, yeah, there's a table and it tells you, so if it was one of them, but I think it's not maintained anymore, so at least it seems that the issue check was taken over by bot selling you stuff, so it looks not maintained anymore, but this was one of them, but there were, 23:12.800 --> 23:17.800 I think, two others that had similar issues, and the cloud may provide us. 23:17.800 --> 23:18.800 Yes? 23:18.800 --> 23:19.800 Yes. 23:19.800 --> 23:22.800 Would you have, I'd call this, do you have any questions? 23:22.800 --> 23:29.800 Can you tell us, by default, I don't have any questions? 23:29.800 --> 23:30.800 Yes. 23:30.800 --> 23:31.800 Yes. 23:31.800 --> 23:32.800 Yes. 23:32.800 --> 23:41.800 I mean, there can be situations, I also experienced one, where there was some, as some user fight and issue, 23:41.800 --> 23:47.800 and this user set, they cannot connect to the provider to their provider anymore. 23:47.800 --> 23:51.800 And the reason why this happened is because Mat made simplicity less than that. 23:51.800 --> 23:54.800 And now I need to think how it was. 23:54.800 --> 24:01.800 And how this issue was resolved is that some flag was changed that made it optional. 24:01.800 --> 24:09.800 And when I looked into the connection in detail, what I saw is that the provider had a corporate proxy that stripped out the starter as prefix. 24:10.800 --> 24:16.800 So what this fix actually did in Mat was to allow an attack on this user because it allowed the downward attack. 24:16.800 --> 24:21.800 And this was one thing, and I know also, like, I don't know which presentation it was, I think, in an art. 24:21.800 --> 24:25.800 In an art presentation about starter less dripping in the country. 24:25.800 --> 24:30.800 Oh, yes, it happened. 24:30.800 --> 24:43.800 Somebody, you state certificates to note just giant man-made attack in 2017, in Thailand. 24:43.800 --> 24:44.800 Mm. 24:44.800 --> 24:45.800 You're looking for it. 24:45.800 --> 24:47.800 Oh, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah, yeah. 24:47.800 --> 24:52.800 Because I had also pay pass, and there was a group, I think this paper was called, 24:52.800 --> 24:55.800 me that neither snow nor rain nor man in the middle. 24:55.800 --> 25:01.800 And they did some calculations, and there were some countries where 90% of starter less connections were stripped. 25:01.800 --> 25:04.800 And this is like a fact like they did the measurement, as well. 25:04.800 --> 25:10.800 You can't say it was a wrongly configured router or something, but they just stripped these connections. 25:10.800 --> 25:14.800 And, yeah, yeah, yeah, yeah, yeah. 25:14.800 --> 25:17.800 Not sure it was this group, but, you know. 25:17.800 --> 25:23.800 Yeah, so I would say you should not use it on the server, but depends on your special use cases. 25:23.800 --> 25:29.800 There's a corporate firewall and it doesn't allow other ports could be different, but this is the thing we should aim for. 25:29.800 --> 25:32.800 Yeah. 25:32.800 --> 25:34.800 Okay. 25:34.800 --> 25:44.800 The thing I skipped a bit was this S thingy, because if you've implemented IMAP, you know, 25:44.800 --> 25:49.800 maybe that there is a thing called literates, and literates can contain multiple lines. 25:49.800 --> 25:55.800 And if you are really, really bad, if you have bad luck, the server can send you a message that have a literal, 25:55.800 --> 26:01.800 and by chance some friend of you sent you a message that contains S white space in the mail body, 26:01.800 --> 26:04.800 and then you will get false results in this. 26:04.800 --> 26:11.800 But my reasoning not to hand, let's specifically, is that no same server should send this stuff before TLS. 26:11.800 --> 26:14.800 So this is already something that is super broken. 26:14.800 --> 26:21.800 And if you still want to be very secure for this case that should not happen, you can just use a random text. 26:21.800 --> 26:28.800 So you can just generate like eight bytes of random, and then just listen for the eight bytes of random until they are reflected, 26:28.800 --> 26:34.800 and then you will also adjust as an argument, I would still, I would not even do this, but because I think it would be a broken server. 26:34.800 --> 26:39.800 But if you want to be really secure, you can do it with a canary reflection or talking reflection, 26:39.800 --> 26:42.800 and then you make it really solid. 26:42.800 --> 26:43.800 Yeah. 26:43.800 --> 26:45.800 Okay. 26:45.800 --> 26:46.800 Cheers.