1 00:00:01,020 --> 00:00:04,340 Welcome, everyone, to the Crypto and Privacy Village. 2 00:00:04,840 --> 00:00:08,400 This is our seventh year and DEF CON 28 here in safe mode. 3 00:00:08,400 --> 00:00:09,220 I am Haim Cohen. 4 00:00:09,220 --> 00:00:10,620 I'm one of the hosts here. 5 00:00:11,200 --> 00:00:13,120 Let's just get some stuff out of the way. 6 00:00:13,120 --> 00:00:14,700 You can join us at Discord. 7 00:00:15,800 --> 00:00:17,200 You can find us there. 8 00:00:17,200 --> 00:00:18,800 We have a couple channels. 9 00:00:19,080 --> 00:00:25,840 The gold bug just opened up, so if you're interested in the gold bug puzzle, we did that very well. 10 00:00:28,940 --> 00:00:34,940 And let's just introduce our first speaker, Hanno Berg, and he's going to go. 11 00:00:36,000 --> 00:00:37,340 Yeah, hi. 12 00:00:37,920 --> 00:00:40,000 Let's switch these slides. 13 00:00:42,480 --> 00:00:45,180 Okay, you can go full screen and you can go. 14 00:00:49,440 --> 00:00:51,460 Okay, do you see the slides? 15 00:00:51,580 --> 00:00:53,020 I see them. 16 00:00:53,200 --> 00:00:54,840 Yeah, okay, great. 17 00:00:54,840 --> 00:00:57,220 Yeah, hello. 18 00:00:57,220 --> 00:01:02,640 So I'm Hanno and I'm going to talk about StartTLS today. 19 00:01:04,590 --> 00:01:12,340 This is some research that I've been doing together with Damian Hodebniak, Fabian Ising and Sebastian Schinzel. 20 00:01:12,340 --> 00:01:16,980 And we are soon going to publish a paper on this. 21 00:01:17,420 --> 00:01:29,720 Yeah, we kind of figured out that StartTLS seems to not be very well researched and it has some issues that are not very well known and we looked a bit deeper into this. 22 00:01:32,100 --> 00:01:44,200 So, from the general idea, I guess most people are roughly aware what StartTLS is, but if we talk about TLS connections, there's two ways to do a TLS connection. 23 00:01:45,260 --> 00:01:55,220 One way is that we have an extra port for the encrypted version of protocol where we directly start a TLS connection on that port. 24 00:01:55,300 --> 00:02:04,060 And this is called implicit TLS because we kind of implicitly are using TLS based on the port number. 25 00:02:04,060 --> 00:02:06,940 We already know that this is an encrypted connection. 26 00:02:06,940 --> 00:02:23,780 And then there's this other way which is StartTLS where we start with some protocol that is not encrypted and then we have some special command which is usually StartTLS command that upgrades this connection to be encrypted. 27 00:02:25,080 --> 00:02:30,780 And in the web we are only using implicit TLS basically. 28 00:02:30,780 --> 00:02:42,920 So what we usually do is that we have HTTPS which is kind of its own protocol on its own port which is HTTP protocol with a TLS wrapped around it. 29 00:02:44,400 --> 00:02:50,140 But StartTLS, the most common usage is in the context of emails. 30 00:02:52,320 --> 00:03:00,560 And in this talk I am mostly going to talk about the connection between an email client and the server. 31 00:03:00,560 --> 00:03:18,040 I will talk a bit about server to server connections later but also we haven't focused so much on this because this is kind of a different issue because the considerations for server to server are quite different than from client to server. 32 00:03:19,880 --> 00:03:27,420 So all email protocols we use, I guess you are aware of that, we have SMTP, POP3 and IMAP. 33 00:03:27,420 --> 00:03:37,040 We use SMTP to send emails, POP3 to fetch emails or IMAP also kind of to fetch emails but also to manage a mailbox on the server. 34 00:03:37,040 --> 00:03:39,740 All of these protocols support StartTLS. 35 00:03:39,740 --> 00:03:47,420 And for the client to server communication these protocols also all support implicit TLS. 36 00:03:47,420 --> 00:03:51,640 So we kind of, as a user we can choose which one we use. 37 00:03:51,640 --> 00:03:58,680 So if we can choose between the two then the obvious question is which one is better and which one is more secure. 38 00:04:00,940 --> 00:04:05,560 So how does this StartTLS work? 39 00:04:06,100 --> 00:04:11,880 So these email protocols, they are all kind of relatively simple text protocols. 40 00:04:11,880 --> 00:04:18,840 So it's a line-based protocol where a client sends a command to a server and gets some kind of answer. 41 00:04:18,840 --> 00:04:22,800 So this is an SMTP session here. 42 00:04:23,080 --> 00:04:27,540 The S and C at the beginning that is server and client. 43 00:04:27,960 --> 00:04:42,940 So if you connect to an SMTP server, the first thing is the server sends this line which is basically a hello message which contains its host name and a special code number. 44 00:04:43,560 --> 00:04:51,340 And then you send this elo command that is basically from the client, always the first command which is kind of introducing the client. 45 00:04:51,340 --> 00:04:55,670 And then the server usually gets back with a list of features that the server supports. 46 00:04:56,280 --> 00:05:08,840 And here you can see in this list that it ends with this 250 star TLS which means okay, the server just told us that it supports star TLS. 47 00:05:09,360 --> 00:05:11,980 And then the client can use this star TLS. 48 00:05:11,980 --> 00:05:14,960 This is simply a text command. 49 00:05:14,960 --> 00:05:17,760 It gives them this command star TLS. 50 00:05:17,760 --> 00:05:23,500 Then the server answers with a 220 code which means everything is all right . 51 00:05:23,640 --> 00:05:26,660 And the okay behind that is basically meaningless. 52 00:05:26,660 --> 00:05:28,600 That's more or less like a comment. 53 00:05:29,760 --> 00:05:31,900 And then we do a handshake. 54 00:05:31,900 --> 00:05:38,220 And for the colors here, the gray thing is the plain text part of the protocol. 55 00:05:38,400 --> 00:05:40,320 And then we have a TLS handshake. 56 00:05:40,320 --> 00:05:49,240 And the green thing here, that is then encrypted and authenticated with all the properties that we usually expect from a TLS connection. 57 00:05:49,240 --> 00:05:56,300 So we expect that there's some sense of security here while the thing at the beginning, it's plain text. 58 00:05:56,300 --> 00:05:59,700 So an attacker can read it, an attacker can manipulate it. 59 00:06:00,200 --> 00:06:07,900 And then basically we start over because kind of all the information we got before the TLS handshake, we don't really trust it. 60 00:06:07,900 --> 00:06:10,200 So we send this elo command again. 61 00:06:10,420 --> 00:06:13,600 And then maybe we can do a login and send an email. 62 00:06:14,000 --> 00:06:18,080 And you don't need to understand the details of how the protocol works. 63 00:06:18,080 --> 00:06:22,560 But the basic idea just that should stick here is we have a plain text protocol. 64 00:06:22,660 --> 00:06:25,620 We have a command that starts a TLS connection. 65 00:06:25,620 --> 00:06:29,480 Then we do a handshake and then we kind of move this protocol into TLS. 66 00:06:31,560 --> 00:06:40,220 Now, first, something which is obvious, that if you use start TLS in an opportunistic way, this is insecure. 67 00:06:40,300 --> 00:06:52,920 So there is some email clients implement start TLS in a way where they will say, okay, if the server offers start TLS, then I will use it. 68 00:06:52,920 --> 00:06:57,820 And if the server does not offer it, then I will just stay in plain text mode. 69 00:06:58,440 --> 00:07:04,040 So we will use start TLS if we can, but if not, then we will just do plain text. 70 00:07:04,360 --> 00:07:09,560 And a network attacker can attack this. 71 00:07:11,200 --> 00:07:14,840 We figured out that this is actually not that common anymore. 72 00:07:14,840 --> 00:07:21,660 This used to be the case maybe 10 years ago, but today most clients don't really do this anymore. 73 00:07:21,920 --> 00:07:37,320 And it's obvious that an attacker can in such a scenario, an attacker can just they can pretend to be the server and then they can say, yeah, I don't support start TLS and then the client logs in and then the attacker knows the username and password. 74 00:07:37,320 --> 00:07:47,420 So that is obviously insecure, but that's not really what our research was about because that's, yeah. 75 00:07:49,840 --> 00:07:50,620 Yeah. 76 00:07:50,620 --> 00:07:55,240 But this turns out to be not the only security problem with start TLS. 77 00:07:55,240 --> 00:08:07,000 So you could think, okay, this is a problem, but if we implement a client in a way that it always forces this start TLS connection and will just refuse to connect if it cannot do that, then this is secure. 78 00:08:07,000 --> 00:08:09,660 But it turns out that this is not the case. 79 00:08:11,800 --> 00:08:21,040 So if you look at what start TLS is, then it's kind of a form of state transition where you have the protocol, which can be in two states. 80 00:08:21,040 --> 00:08:26,860 It can be in a plain text state and in an encrypted state after the TLS handshake. 81 00:08:29,860 --> 00:08:33,980 And this raises quite a few questions. 82 00:08:34,800 --> 00:08:45,300 So at first you can ask, okay, we have the state transition, but which protocol features can we use before we turn the encryption on? 83 00:08:45,300 --> 00:08:48,380 What can happen in the plain text part? 84 00:08:48,620 --> 00:09:04,800 And also how should we treat the data that we got before the handshake, for example, server features or if there's any login, because we cannot really trust that data as it's obviously not secured. 85 00:09:04,800 --> 00:09:12,640 And also you could ask, do the implementations, do they have a clear understanding what is encrypted and not encrypted? 86 00:09:12,640 --> 00:09:15,540 And do they clearly separate that? 87 00:09:17,820 --> 00:09:32,140 So just one example, which is a relatively obvious problem, the IMAP protocol has a feature which is called alerts, which is basically the server sends a message to the client and the client is supposed to show this to the user. 88 00:09:32,140 --> 00:09:36,040 And these alerts, it turns out, they can be sent at any time. 89 00:09:36,140 --> 00:09:52,680 So they can be sent in the plain text part, which is interesting because this is a screenshot from Outlook where the IMAP server sends a message to the user and this message is not secure. 90 00:09:52,680 --> 00:09:59,640 It is sent in plain text, even though the mail client is configured to use a secure connection. 91 00:09:59,640 --> 00:10:04,180 And here you can even see, you can even include a link which will be highlighted. 92 00:10:04,280 --> 00:10:15,760 So we have here, your IMAP server wants to alert you to the following, please download my post something something and then the attacker can put in a link where he provides a malicious file. 93 00:10:15,900 --> 00:10:22,620 So we have an alert sent in plain text but to the user it looks like this is a legitimate message from his mail server. 94 00:10:22,620 --> 00:10:25,660 So he may want to trust it. 95 00:10:25,660 --> 00:10:32,360 So yeah, this is just a design problem of the protocol, how it is specified. 96 00:10:34,740 --> 00:10:39,900 But then we came upon the issue of buffering bugs. 97 00:10:39,900 --> 00:10:42,900 And this is something that has been known for a while. 98 00:10:43,920 --> 00:10:48,980 And the question here is really, is something part of the TLS session or not? 99 00:10:48,980 --> 00:10:52,360 And do clients and servers have a good idea about this? 100 00:10:53,620 --> 00:11:05,480 So there was a vulnerability in 2011 already, so this is nine years ago, which was named plain text command ejection in multiple implementations of star TLS. 101 00:11:05,480 --> 00:11:08,660 This was discovered by the author of Postfix. 102 00:11:10,000 --> 00:11:30,040 And what happened here is, like if we look again at this star TLS connection and this is like only the, I've shortened this a bit, I've cut away the stuff that currently doesn't matter, like we have this client sends the star TLS command, gets an answer from the server and then there's a handshake happening. 103 00:11:30,640 --> 00:11:49,120 Now, what can happen if we do something like this, where a client sends the star TLS command and then sends something else in plain text and then gets the answer from the server that he can now start the TLS handshake and then they do the TLS handshake. 104 00:11:49,140 --> 00:12:05,280 So it turns out that there are quite a few implementations of servers that will then process both of these commands, the star TLS and the whatever other command you sent together with the star TLS in a single TCP packet. 105 00:12:06,480 --> 00:12:19,460 That it will put this in some kind of buffer and process every command after another and then it will answer to this command that was appended to the star TLS in the TLS session. 106 00:12:19,820 --> 00:12:27,120 So we kind of have something here that traverses from the plain text part of the protocol to the TLS part of the protocol. 107 00:12:27,180 --> 00:12:34,560 Like we send something in plain text but the server kind of thinks that this is part of the TLS connection. 108 00:12:36,900 --> 00:12:41,620 Yeah, so that's basically what I just said. 109 00:12:43,160 --> 00:12:55,100 So this bug was originally found in Postfix but it turned out it affected multiple mail servers including Cyrus, Courier, Qmail and various proprietary mail stacks. 110 00:12:55,100 --> 00:13:02,720 So there's an advisory by US CERT from that time which contains a long list of affected servers. 111 00:13:02,720 --> 00:13:05,900 So this turned out to be a very widespread problem. 112 00:13:06,880 --> 00:13:25,980 Now you may wonder how you can attack this and this is kind of, I think this is maybe part of the reason why this bug is not very well known because the Postfix authors, they have described very well what the problem is but they haven't really published any exploit or explained how you could actually attack this. 113 00:13:25,980 --> 00:13:38,780 So it was kind of seen by and there was some email discussions from mail server developers where people were like, yeah, this is kind of a weird behavior but it's not really a security problem. 114 00:13:38,780 --> 00:13:56,240 But you can actually attack this pretty easily and this takes a bit of thinking what's going on here but so this is the first part of the attack which is we start a connection that is in plain text. 115 00:13:56,240 --> 00:14:02,500 So we have again this start message that's not really the interesting part. 116 00:14:02,500 --> 00:14:09,660 The interesting part begins where we have the start TLS and then this red stuff, this is injected by an attacker. 117 00:14:09,660 --> 00:14:17,260 So the attacker is injecting here another elo command which is, that is just always the first command that comes after start TLS. 118 00:14:17,260 --> 00:14:19,260 That's why we have to send that. 119 00:14:19,320 --> 00:14:22,400 And then the attacker locks in with its own credentials. 120 00:14:22,400 --> 00:14:30,800 So our assumption here is the attacker also has an account on this mail server but it could be something like a public email provider address. 121 00:14:30,800 --> 00:14:32,740 So that is a plausible assumption. 122 00:14:33,220 --> 00:14:47,740 And then the attacker is starting to send an email like he's setting a from address and a to address and the to address particularly is his own address and then it sends this data command which is basically now the email content starts. 123 00:14:49,360 --> 00:14:52,680 And then we get an answer from the server. 124 00:14:52,680 --> 00:14:55,540 This is now the answer to the start TLS command. 125 00:14:55,740 --> 00:15:01,580 So now we're doing a TLS handshake the client and the server but we have these injected commands. 126 00:15:03,200 --> 00:15:07,700 And then the server will answer to these injected commands. 127 00:15:07,700 --> 00:15:17,860 So it will send this normal greeting that always comes after the elo command and then it will authenticate the user and then it will say okay now the email starts. 128 00:15:18,100 --> 00:15:23,320 And now what happens is that the client doesn't know about any of this. 129 00:15:23,320 --> 00:15:26,960 It doesn't read from the server because it doesn't expect it to send anything. 130 00:15:26,960 --> 00:15:33,040 It sends its own elo command, it authenticates and then it starts sending a mail. 131 00:15:33,260 --> 00:15:45,060 Now what happens is that all this stuff, all this blue stuff which the client sends, this ends up being part of this email that we started sending to ourselves as an attacker. 132 00:15:45,280 --> 00:15:56,440 So the attacker now gets an email and that contains the authentication data from the victim, so this is a pretty severe attack. 133 00:15:56,440 --> 00:16:04,480 Like if you're a network attacker and we have a server vulnerable to this, we can force the client to send his credentials to us. 134 00:16:07,260 --> 00:16:18,020 There's a similar attack with IMAP that is a bit more tricky because like you can, in IMAP you can kind of store a mail into a mailbox and then it's the same idea. 135 00:16:18,020 --> 00:16:24,980 One problem with that was that in order to do that you need to know the exact size of the message that's going to come. 136 00:16:25,120 --> 00:16:39,240 That means you kind of need to guess how long the password of the user is, but you may be able to see that with a side channel attack and also it turns out that many mail servers on failed login attempts, they will just try to reconnect. 137 00:16:39,240 --> 00:16:45,360 So you have kind of as an attacker, you have multiple tries to do this so it's still a feasible attack. 138 00:16:45,360 --> 00:16:49,040 But it is a bit more difficult than the SMTP attack. 139 00:16:51,180 --> 00:16:55,440 Okay, so this bug was discovered in 2011. 140 00:16:55,740 --> 00:17:04,540 So you would hope that people have fixed this, but as probably no one is surprised, it's actually not fixed everywhere. 141 00:17:04,760 --> 00:17:11,220 So we did some scans and we found out that, yeah, in SMTP servers 1.5% are vulnerable. 142 00:17:12,920 --> 00:17:17,040 In IMAP and POP3 it's more, it's around 2.5%. 143 00:17:18,360 --> 00:17:27,360 I guess the reason why this is different is because this was originally described in an SMTP server, so that's probably where people had it on the radar. 144 00:17:27,620 --> 00:17:34,340 But the very same class of bug can happen in basically every protocol that supports StarTLS. 145 00:17:35,280 --> 00:17:45,760 Although I have to say for POP3, we didn't really find an exploit to attack this, but it's still kind of something that should be fixed. 146 00:17:48,580 --> 00:17:57,060 Now there's another question you can ask and that is, can we have the same kind of bug, but the other way around? 147 00:17:57,060 --> 00:17:59,640 That is, on the client side. 148 00:17:59,880 --> 00:18:06,740 So can we confuse the client to get data that was sent in plain text and the client thinks it's TLS data? 149 00:18:07,280 --> 00:18:09,340 And in turns out, yes, we can do that. 150 00:18:09,340 --> 00:18:11,560 So the idea is pretty much the same. 151 00:18:11,560 --> 00:18:21,920 The client sends a StarTLS command, then the server sends this 220 code, which is kind of the just approving that, yeah, I got the StarTLS, now we can do TLS. 152 00:18:22,620 --> 00:18:30,920 And then we can append additional data that's coming from the server and then the client will interpret that as part of the TLS session. 153 00:18:31,400 --> 00:18:37,220 So yes, this attack also, this vulnerability also exists on the client side. 154 00:18:40,860 --> 00:18:51,100 So clients can be vulnerable to the same class of bug and we have called this a response injection because the other thing was called a command injection and here we call it a response injection. 155 00:18:54,380 --> 00:19:01,420 This is not that severe, but for example it can be used by an attacker to spoof mailbox content. 156 00:19:01,580 --> 00:19:08,740 You kind of have to guess what commands the client will send, but if you know which mail client it is, you can usually know that. 157 00:19:08,740 --> 00:19:15,900 So for example, you can show the user an IMAP inbox that is not his own and that contains other data. 158 00:19:17,920 --> 00:19:20,820 So it's still an issue. 159 00:19:21,040 --> 00:19:28,860 And the really surprising thing was that more than half of the mail clients that we tested were vulnerable to this bug. 160 00:19:28,860 --> 00:19:31,480 So this is a very very widespread issue. 161 00:19:34,720 --> 00:19:51,320 So to sum that up a bit, this DartTLS command injection, it was discovered in 2011 and it affected multiple implementations and even though many implementations were found back then, they are still widely used vulnerable implementations. 162 00:19:53,540 --> 00:20:03,400 Also, the same bug class exists on the client and the majority of implementations are vulnerable or were until we have reported it to them. 163 00:20:05,760 --> 00:20:23,160 And just very generally, if you're doing an implementation of DartTLS and you're not aware of this bug and you're doing a naive implementation, then you will have some kind of command buffer where you read the commands line by line and then you will usually have this bug too. 164 00:20:23,240 --> 00:20:30,140 So it's kind of one of these things where you have to actively be aware of this bug in order to prevent it. 165 00:20:32,220 --> 00:20:45,380 And this, in my opinion, is a clear sign that this is not something where we should say this is a flaw in the mail client, but this is a systemic problem in the standard. 166 00:20:45,400 --> 00:21:07,280 Like if you have a situation where the same bug appears again and again and again and in multiple different implementations, then you should wonder if this is something where we can just... if we can do better on the level of the standard and not say it's the flaw of the implementations. 167 00:21:09,440 --> 00:21:10,760 Yeah. 168 00:21:11,560 --> 00:21:14,300 There's more issues with DartTLS. 169 00:21:16,040 --> 00:21:22,280 One, the IMAP protocol has a feature which is called pre-auth. 170 00:21:22,400 --> 00:21:37,260 The idea here is that an IMAP server can, send a line which basically tells the client you're already logged in, you don't have to authenticate. 171 00:21:38,540 --> 00:21:55,200 So the idea here is, for example, if you have a controlled network where you do authentication based on IP addresses, maybe then you can say, okay, if a connection comes from this IP address, then we just assume that this is already authenticated and the user is already logged in. 172 00:21:55,200 --> 00:22:03,960 So now, DartTLS, the standard clearly says that it must not be performed in an authenticated state. 173 00:22:04,920 --> 00:22:20,120 So if we take these two things together, like we have a feature, DartTLS, that you must not use when in an authenticated state, but the server answers with this pre-auth line which says you are already authenticated. 174 00:22:20,280 --> 00:22:22,200 Now, what should a client do? 175 00:22:22,200 --> 00:22:30,600 Like we have a client that connects to a server, it gets this response, it's configured to use DartTLS, then we kind of have a contradiction here. 176 00:22:30,600 --> 00:22:34,640 Like this is kind of a logical inconsistency in the standard. 177 00:22:35,280 --> 00:22:38,640 The standard doesn't really say anything about this. 178 00:22:38,640 --> 00:22:43,400 This is just where the standard has an internal conflict. 179 00:22:45,400 --> 00:22:57,800 And after all, the only reasonable way for a client to react to this is to just terminate the connection, because it cannot do DartTLS in this situation. 180 00:22:59,360 --> 00:23:07,900 So there's no way to secure this connection and if it's configured to have a secure connection, it should just not accept this. 181 00:23:09,820 --> 00:23:18,500 Now, not surprisingly, some clients will allow pre-auth connection and then just don't do DartTLS because they can't. 182 00:23:19,160 --> 00:23:22,920 And this is also a security flaw. 183 00:23:22,920 --> 00:23:35,620 You also obviously can do mailbox content spoofing, like you're a network attacker person in the middle and then client connects, you send this pre-auth response and then you're kind of the upstream server for that client. 184 00:23:35,620 --> 00:23:45,360 So you cannot steal credentials because the client is already authenticated, but you can forge the content of the inbox. 185 00:23:45,360 --> 00:23:55,560 And also, you can sometimes steal mail, for example, if you're using IMAP then usually a sent mail is stored in the send folder, so that you can steal. 186 00:23:55,560 --> 00:24:04,880 And some clients also, when they connect to an IMAP server, they start synchronizing folders, so there you may be able to steal mailbox content. 187 00:24:07,680 --> 00:24:11,940 Then there's an IMAP feature which is called mailbox referrals. 188 00:24:12,120 --> 00:24:17,880 And the idea here is that the server can tell a client that it should use another server. 189 00:24:17,900 --> 00:24:27,540 So it's something like a forward feature, where a server can say, yeah, like I'm forwarding you to this other server if you want to access this mailbox. 190 00:24:29,580 --> 00:24:38,840 And now the interesting thing is if you combine these two things, you have this pre-auth, which means you can prevent the client from starting a TLS connection. 191 00:24:39,020 --> 00:24:43,480 And then you can do this referral, which refers the client to another server. 192 00:24:43,560 --> 00:24:45,680 And this can be our attacker server. 193 00:24:45,860 --> 00:24:50,680 So we prevent the TLS connection from happening as an attacker. 194 00:24:50,740 --> 00:24:54,800 Then we forward the user to a server and we control that server. 195 00:24:54,800 --> 00:24:58,340 So this can have TLS and the client logs in. 196 00:24:58,500 --> 00:25:00,540 And then we have the client's credentials. 197 00:25:00,940 --> 00:25:03,480 So this is also a pretty severe attack. 198 00:25:05,100 --> 00:25:13,760 We have to say here that this mailbox referrals feature, and there's a similar feature called login referrals, these are not widely supported. 199 00:25:13,760 --> 00:25:18,420 So we only found one mail client where we could perform this attack. 200 00:25:18,420 --> 00:25:20,680 This was a mail client called Alpine. 201 00:25:21,060 --> 00:25:26,040 So most mail clients, they just don't support these features, so they are not affected by this. 202 00:25:27,380 --> 00:25:36,840 But still it shows kind of that there are features in IMAP where it's not really thought through what that means in combination with StartTLS. 203 00:25:38,540 --> 00:25:45,640 So yeah, to summarize that, so StartTLS has a systemic problem with buffering bugs. 204 00:25:45,640 --> 00:25:48,740 They can appear both on the server and the client sites. 205 00:25:48,940 --> 00:25:55,960 There are several features in IMAP that are problematic or insecure if you combine them with StartTLS. 206 00:25:56,020 --> 00:26:03,560 And also StartTLS does not really provide any security advantage over normal implicit TLS connection. 207 00:26:04,640 --> 00:26:11,980 So our conclusion is you should not use StartTLS for mail connections, for email client connections, I guess. 208 00:26:11,980 --> 00:26:27,460 So if you are using email, which I guess most of you do, and if you're using a mail client, then you should change its configuration to use the implicit TLS pods and not to use StartTLS. 209 00:26:28,000 --> 00:26:31,540 And then you will not be affected by most of these attacks. 210 00:26:31,540 --> 00:26:39,580 Some can still happen, but because some it's enough when the server is supporting StartTLS, but most of these attacks will be prevented. 211 00:26:41,180 --> 00:26:47,160 If you run a mail server, you should definitely make sure that you support implicit TLS. 212 00:26:47,360 --> 00:27:02,220 I mean, there's an RFC that says that you should use the implicit TLS pods, but there are, for example, the Microsoft SMTP servers, they don't support implicit TLS for SMTP. 213 00:27:03,360 --> 00:27:06,200 And if you can, then disable StartTLS. 214 00:27:06,320 --> 00:27:12,160 Now we are aware that this is not an easy thing, particularly if you have existing customers. 215 00:27:12,160 --> 00:27:21,680 Like if you have an existing user base, then telling them, yeah, sorry, half of your mail configurations will break next week, that's a tough thing to do. 216 00:27:21,740 --> 00:27:32,740 So I'll say it would be ideal to just disable it on the server, but this is probably not feasible for people who have existing user bases. 217 00:27:32,740 --> 00:27:40,080 But if you start like a new mail server setting, then you can start right away without StartTLS. 218 00:27:43,020 --> 00:27:50,140 So then I want to talk a bit about the special case, the server-to-server or MTA-to-MTA connection. 219 00:27:50,140 --> 00:27:55,960 In case you don't know, MTA stands for Mail Transfer Agent, which is another word for mail server. 220 00:27:57,800 --> 00:28:00,780 So this situation there is a bit different. 221 00:28:01,380 --> 00:28:07,220 For one, there's currently no way to use implicit TLS on MTA-to-MTA connections. 222 00:28:07,220 --> 00:28:09,700 That's just not part of the standards. 223 00:28:09,700 --> 00:28:12,140 There's no RFC how to do this. 224 00:28:12,140 --> 00:28:19,940 And it would not be easy to implement that. 225 00:28:20,700 --> 00:28:27,720 And also, traditionally, the server-to-server connections are purely opportunistic. 226 00:28:27,720 --> 00:28:35,120 So usually mail server doesn't validate a certificate because also usually the certificate host is not the host of the email address. 227 00:28:35,120 --> 00:28:38,520 So even validating the set doesn't make much sense. 228 00:28:38,520 --> 00:28:42,500 And you usually don't have an expectation against active attackers. 229 00:28:43,060 --> 00:28:46,680 Now, this is changing a bit. 230 00:28:46,680 --> 00:29:01,480 So there are two standards that one is based on DNSSEC and called DAIN and the other is called MTA-STS, which is kind of a trust on first use kind of mechanism that are trying to secure these server-to-server connections . 231 00:29:02,180 --> 00:29:07,380 It would be a different talk to talk about the advantages and disadvantages of those. 232 00:29:07,380 --> 00:29:16,960 My personal opinion is that MTA-STS is the more promising mechanism, but that's a controversial discussion. 233 00:29:16,960 --> 00:29:18,880 Let's just put it like this. 234 00:29:20,320 --> 00:29:29,720 But so yeah , it would be challenging to introduce an implicit TLS mode into MTA -to-MTA connections. 235 00:29:29,720 --> 00:29:32,480 Like right now, we are just using star TLS. 236 00:29:32,480 --> 00:29:36,740 Even if we use this advanced mechanism, we are still using star TLS. 237 00:29:37,160 --> 00:29:42,700 And the problem here is like that we have a lot of compatibility issues here. 238 00:29:42,700 --> 00:29:54,860 Like in email, it's a very old protocol and things are very established and probably a lot of mail servers have a firewall that they don't allow other ports than port 25. 239 00:29:54,880 --> 00:30:01,240 So it would be very challenging to change the protocol to support an implicit TLS mode. 240 00:30:01,240 --> 00:30:04,400 So I don't see that happening anytime soon. 241 00:30:05,780 --> 00:30:21,020 So if we want to secure these MTA-to-MTA connections, like if we talk about something like MTA-STS, then we should really need to make sure that we fix these buffering bugs, like these command injection and response injection that I've talked about earlier. 242 00:30:22,320 --> 00:30:28,420 If you think that you want to secure these server-to-server connections, then you also need to think about this. 243 00:30:30,120 --> 00:30:34,760 And you need to basically audit the implementation so they don't have these bugs. 244 00:30:36,560 --> 00:30:51,100 Then just quickly also start TLS is used in many other protocols like XMPP, FTP, then managed sieve, which is a mail filtering thing, then LDAP, MySQL, NNTP. 245 00:30:51,600 --> 00:31:06,000 And I guess this is obvious, but the kind of bugs that we found, they can be present in implementations of all protocols that support start TLS or something like start TLS. 246 00:31:06,640 --> 00:31:10,300 So there's lots of potential for future research here. 247 00:31:10,300 --> 00:31:14,960 Like this is something that should be tested in more settings. 248 00:31:18,560 --> 00:31:29,340 And also our general recommendation that if you have a choice between start TLS and implicit TLS, then you should prefer implicit TLS. 249 00:31:29,340 --> 00:31:37,140 And for future protocols, maybe you should just only support implicit TLS. 250 00:31:38,240 --> 00:31:46,940 And then something that is kind of not on the security side, but we can also ask what about performance? 251 00:31:46,940 --> 00:31:48,560 What about speed? 252 00:31:49,940 --> 00:31:52,920 Because I don't know. 253 00:31:52,920 --> 00:31:57,660 I come from Germany and Germany is known for having pretty bad mobile Internet. 254 00:31:57,780 --> 00:32:02,300 Not sure if you're aware of that, but if you ever go to Germany, that's what you will experience. 255 00:32:02,540 --> 00:32:08,460 So if you try to send an email with a bad Internet connection, it's pretty annoying. 256 00:32:08,460 --> 00:32:19,020 Like you have these things that you may get a connection error or the email may be sent, but it's not stored in your send folder because these are two different connections. 257 00:32:19,020 --> 00:32:24,300 So having a better performance here is good and also more reliability. 258 00:32:24,300 --> 00:32:29,220 If we need fewer connection roundtrips, then it's more reliable. 259 00:32:30,720 --> 00:32:32,820 This I also find interesting. 260 00:32:32,820 --> 00:32:36,580 There's been a lot of effort to reduce roundtrips in TLS. 261 00:32:36,820 --> 00:32:45,280 In TLS 1.3, by design, if you make a new connection, it has one roundtrip less than older TLS versions. 262 00:32:45,460 --> 00:32:49,140 And there's also a zero RTT mode, which is kind of... 263 00:32:50,360 --> 00:32:58,620 there are some security concerns about this, but the TLS community has decided that they still want to do this despite these security concerns. 264 00:32:58,920 --> 00:33:07,340 And I find this interesting that so much effort has been put into reducing TLS roundtrips, but it seems nobody has tried to optimize email protocols the same way. 265 00:33:08,820 --> 00:33:24,260 And if we look at startTLS, then all the information that is exchanged before we do startTLS is kind of meaningless, because we cannot trust it anyway, so we need to retransmit everything after the TLS handshake anyway. 266 00:33:24,280 --> 00:33:30,720 So for example, the server capabilities, you're always getting them again after the handshake. 267 00:33:30,740 --> 00:33:37,440 So you can think about this, that everything that is happening before we do this handshake, it is just wasted. 268 00:33:37,440 --> 00:33:39,360 It doesn't have any meaning. 269 00:33:39,360 --> 00:33:47,080 So this kind of directly leads to that if you use startTLS, you need more roundtrips. 270 00:33:47,080 --> 00:33:56,580 It depends on the protocol and also a bit depends on the implementation, but it's usually two or three roundtrips more than if you directly use implicit TLS. 271 00:33:57,300 --> 00:34:03,300 So avoiding startTLS is not just more secure, it's also just faster. 272 00:34:03,300 --> 00:34:05,220 Which is, I guess, good. 273 00:34:05,220 --> 00:34:08,780 And there are some other ways. 274 00:34:08,780 --> 00:34:16,880 This is kind of now going a bit into other topics, but there are other easy ways to improve email protocol roundtrips. 275 00:34:17,980 --> 00:34:21,720 So email authentication uses something called Zazzle. 276 00:34:23,460 --> 00:34:29,180 Zazzle is an authentication framework that is used in all three email protocols. 277 00:34:29,900 --> 00:34:33,320 And it's kind of an abstraction of different authentication methods. 278 00:34:33,320 --> 00:34:38,900 Although most of the time everyone uses username and password, but there are different authentication methods. 279 00:34:39,960 --> 00:34:49,080 And if you look at this, how this looks like in IMAP, we can have something like the above, where we have an authenticate plane and then we have some Base64. 280 00:34:49,080 --> 00:34:55,600 And this Base64, it is basically, it's a zero byte, then a username, then another zero byte and a password. 281 00:34:56,800 --> 00:34:58,700 And that is our login. 282 00:34:58,700 --> 00:35:01,040 So this is one roundtrip to login. 283 00:35:01,580 --> 00:35:07,940 And we can have this thing below where we have authenticate login, then we have a new line. 284 00:35:08,080 --> 00:35:10,400 So this is kind of optional. 285 00:35:10,400 --> 00:35:15,800 We can, in this authenticate line, we can already send data or we can just not. 286 00:35:17,740 --> 00:35:20,660 And then the server asks for a username. 287 00:35:20,660 --> 00:35:24,020 This is also Base64 encoded and asks for a password. 288 00:35:24,480 --> 00:35:26,500 So this is three roundtrips. 289 00:35:26,500 --> 00:35:36,120 So there's quite some difference here and it's quite varying what will happen depending on what client and server configuration you use. 290 00:35:37,080 --> 00:35:45,720 So the first thing is that IMAP has a feature called SASL IR, which basically means you can initiate an authentication right away with data. 291 00:35:45,720 --> 00:35:54,940 So this is the thing that you have this authenticate plane and send something in the same line where... or you can also not do that. 292 00:35:54,940 --> 00:35:56,600 And of course, this is faster. 293 00:35:56,600 --> 00:36:01,880 This saves you a roundtrip if you can send data right away with the authentication command. 294 00:36:03,520 --> 00:36:09,080 And also, Zazzle has two different modes for username password authentication. 295 00:36:09,080 --> 00:36:10,960 They are called plain and login. 296 00:36:13,120 --> 00:36:24,260 To make matters even more complicated, both POP3 and IMAP, they have a built-in authentication that is not part of Zazzle, which is kind of part of their protocol itself. 297 00:36:24,860 --> 00:36:27,060 In IMAP, this has one roundtrip. 298 00:36:27,060 --> 00:36:30,140 In POP3, it has two roundtrips. 299 00:36:32,760 --> 00:36:40,780 So this login method, this is not standardized and it is also declared obsolete by the IANA. 300 00:36:40,780 --> 00:36:47,260 So the IANA has a registry of Zazzle authentication methods and there it's declared as obsolete. 301 00:36:47,740 --> 00:36:55,980 And what it basically does is it sends the username and the password base64 encoded in two roundtrips or just two lines in other words. 302 00:36:56,760 --> 00:37:04,680 And then there's this plain authentication method, which is a standard and it sends username and password encoded in one roundtrip. 303 00:37:04,780 --> 00:37:07,280 So you save another roundtrip here. 304 00:37:09,360 --> 00:37:14,860 So the plain method is standardized and it's faster than login. 305 00:37:14,860 --> 00:37:17,480 So it's clearly the better method. 306 00:37:17,680 --> 00:37:20,440 And from the security, it doesn't really matter. 307 00:37:20,980 --> 00:37:23,600 It's a normal username and password authentication. 308 00:37:23,600 --> 00:37:25,600 There's nothing fancy about it. 309 00:37:27,340 --> 00:37:34,860 So almost everyone supports both, like both servers and clients, but there's not really a reason to support login. 310 00:37:36,120 --> 00:37:42,860 So if you want to have faster email, then you should use implicit TLS and not start TLS. 311 00:37:42,860 --> 00:37:47,620 You should support the sessil-ir, which is specifically in IMAP. 312 00:37:47,760 --> 00:37:51,080 And you should disable the sessil-login method. 313 00:37:51,280 --> 00:37:54,800 Like for example, I figured out my own mail server, it supported both. 314 00:37:54,800 --> 00:38:01,060 And my client, if it supported both, it used login because that was the first in the client. 315 00:38:01,680 --> 00:38:03,080 It's in class mail. 316 00:38:03,080 --> 00:38:05,880 It's the first method that it supports. 317 00:38:06,080 --> 00:38:09,020 So it's slower for no gain. 318 00:38:09,080 --> 00:38:12,120 And I disabled it on the server and now I'm saving. 319 00:38:14,940 --> 00:38:16,460 So yeah. 320 00:38:17,020 --> 00:38:19,200 Yeah, that was it. 321 00:38:19,920 --> 00:38:21,960 Yeah, don't use TLS. 322 00:38:22,100 --> 00:38:26,960 Thanks for listening and I guess we have some time for Q&A now. 323 00:38:31,040 --> 00:38:31,980 Hold on. 324 00:38:31,980 --> 00:38:33,760 Welcome back, everybody. 325 00:38:35,120 --> 00:38:40,280 Can you, Hanno, can you unshare your screen maybe so we can just see you? 326 00:38:40,280 --> 00:38:43,360 I just want to put my background on. 327 00:38:47,070 --> 00:38:48,070 Okay. 328 00:38:48,790 --> 00:38:51,650 So we have, I think we have three questions for you. 329 00:38:51,650 --> 00:38:52,990 Can you hear me? 330 00:38:53,770 --> 00:38:54,770 Okay. 331 00:38:55,790 --> 00:39:03,370 So is the implication that the clients in the SMTP case for ease just ignore responses from the server? 332 00:39:03,370 --> 00:39:06,990 I expect them to be a state machine that says, wait, what? 333 00:39:06,990 --> 00:39:08,870 I haven't started sending them yet. 334 00:39:08,870 --> 00:39:09,970 What do you mean? 335 00:39:11,250 --> 00:39:13,270 No, that's not the implication. 336 00:39:13,270 --> 00:39:20,070 So the client is not ignoring these answers, but it is like it is processing these line by line. 337 00:39:20,230 --> 00:39:26,690 So it is sending a command to the server and then it's reading a line from the server and processing that. 338 00:39:26,730 --> 00:39:36,610 And that is why if you do this attack, you kind of have to inject all the commands that the client will send so it will get the answers that it expects. 339 00:39:37,750 --> 00:39:40,130 Is this understandable? 340 00:39:40,130 --> 00:39:41,230 I hope so. 341 00:39:41,870 --> 00:39:43,690 We are monitoring the discord. 342 00:39:43,690 --> 00:39:47,330 So if they reply back, I can do it. 343 00:39:47,590 --> 00:39:48,170 Yeah. 344 00:39:50,350 --> 00:39:52,030 Actually, give me one second. 345 00:39:52,030 --> 00:39:55,930 I think we are going to try and share the slides with you so everyone can see it. 346 00:39:58,300 --> 00:40:00,040 Give me one second. 347 00:40:00,160 --> 00:40:01,220 Share this. 348 00:40:01,220 --> 00:40:02,320 I did that. 349 00:40:05,140 --> 00:40:06,340 Sorry, everybody. 350 00:40:06,340 --> 00:40:07,520 Let's see. 351 00:40:14,680 --> 00:40:17,020 So they want me to... let's see. 352 00:40:24,690 --> 00:40:26,150 I know we have dead air. 353 00:40:29,340 --> 00:40:31,700 Let's see if I can share the screen. 354 00:40:31,820 --> 00:40:34,400 I am now also in the discord. 355 00:40:35,240 --> 00:40:36,480 That's okay. 356 00:40:36,480 --> 00:40:39,740 I will be able to see questions later if they are. 357 00:40:51,180 --> 00:40:53,300 I see your screen now. 358 00:40:53,480 --> 00:40:54,420 Okay. 359 00:41:10,290 --> 00:41:13,530 The second 360 00:41:17,590 --> 00:41:27,850 question I have, in the context of SMTP, do you see MTA STS having positive, negative, no change to the start TLS risks? 361 00:41:31,010 --> 00:41:32,530 It doesn't... 362 00:41:34,510 --> 00:41:37,650 I think the question is framing it wrong. 363 00:41:37,650 --> 00:41:45,890 The thing is, MTA STS is introducing an expectation that we didn't have previously. 364 00:41:45,890 --> 00:41:49,530 That is that these connections are secure against active attackers. 365 00:41:49,910 --> 00:41:53,230 And these attacks can compromise this expectation. 366 00:41:53,670 --> 00:42:00,930 So before, we could say these attacks don't matter for MTA to MTA because we don't expect it to be secure anyway. 367 00:42:00,990 --> 00:42:05,430 And now we want to introduce connection security for that. 368 00:42:05,650 --> 00:42:07,750 So now we have to care about these attacks. 369 00:42:07,750 --> 00:42:10,570 But it doesn't really change the risk. 370 00:42:10,570 --> 00:42:16,670 It's just that what we try to achieve with MTA STS that is compromised if we have these vulnerabilities. 371 00:42:19,010 --> 00:42:20,710 Does that make sense? 372 00:42:21,270 --> 00:42:22,350 I mean... 373 00:42:23,350 --> 00:42:25,130 Yes, I understand it. 374 00:42:25,710 --> 00:42:32,850 Again, we can be in the Slack Discord and maybe later, if people have more questions, you can join in there. 375 00:42:33,570 --> 00:42:34,890 Last one that I have. 376 00:42:34,890 --> 00:42:38,530 In what kind of issues does the speaker see with implicit TLS? 377 00:42:41,070 --> 00:42:48,970 So I think if you compare start TLS and implicit TLS, there are no added issues by implicit TLS. 378 00:42:49,010 --> 00:42:51,550 Because it's just the simpler thing. 379 00:42:51,870 --> 00:43:00,610 Like with start TLS, we start in plain text and then we do a state transition and that introduces potential for errors. 380 00:43:00,610 --> 00:43:03,630 And with implicit TLS, we just don't have that. 381 00:43:03,630 --> 00:43:09,790 So I don't see any risk in implicit TLS that you wouldn't have with start TLS. 382 00:43:10,050 --> 00:43:14,550 Of course, it has all the risks that you can have otherwise with TLS. 383 00:43:16,030 --> 00:43:24,110 If there's a bad implementation, if there's bad randomness or vulnerable algorithms, then you have all the same risks. 384 00:43:24,110 --> 00:43:27,150 But you would have the same risks with start TLS as well. 385 00:43:28,250 --> 00:43:30,510 We're getting another question. 386 00:43:30,510 --> 00:43:34,090 Any thoughts on Telnet start TLS? 387 00:43:35,150 --> 00:43:37,450 I have no idea, sorry. 388 00:43:37,710 --> 00:43:43,550 I have seen that it exists, but I'm not sure if anyone is using that. 389 00:43:43,650 --> 00:43:45,910 I would be curious if anyone is using that. 390 00:43:45,910 --> 00:43:51,110 I feel that people use SSH there usually. 391 00:43:52,030 --> 00:43:56,890 And then our final question, just thanking you for the talk. 392 00:43:56,890 --> 00:44:01,610 Is anyone working on email POP3 replacements with something more secure? 393 00:44:05,410 --> 00:44:06,530 I'm not sure. 394 00:44:06,530 --> 00:44:09,150 There's not really a problem with POP3. 395 00:44:09,570 --> 00:44:17,330 This is not the issue of the talk, but I feel POP3 is a really simple protocol and I kind of like that. 396 00:44:18,150 --> 00:44:22,510 I'm also one of these weird people that I'm still using POP3. 397 00:44:22,510 --> 00:44:25,450 I like to have the mails on my laptop locally. 398 00:44:30,770 --> 00:44:34,170 If you use it with TLS, then it's a fine protocol. 399 00:44:35,570 --> 00:44:39,270 Well, again, we would like to thank you for your talk. 400 00:44:40,050 --> 00:44:44,410 If anybody has any more questions, you can hang out in the Discord. 401 00:44:45,130 --> 00:44:48,790 We'll try and relate them to you, anything like that. 402 00:44:48,790 --> 00:44:59,090 I want to thank everyone who's watching the live stream for sitting with us through the first ever DEF CON Safe Mode and the Glitch Crypto and Privacy Village. 403 00:44:59,090 --> 00:45:03,910 I want to remind everyone again that we have the Gold Bug Challenge that's still there. 404 00:45:04,170 --> 00:45:09,930 And I would like to, again, thank you for your talk and I hope you enjoyed yourself. 405 00:45:12,660 --> 00:45:14,120 I guess we wait. 406 00:45:17,000 --> 00:45:19,960 Okay, I can leave here now?