WEBVTT 00:01.020 --> 00:04.340 Welcome, everyone, to the Crypto and Privacy Village. 00:04.840 --> 00:08.400 This is our seventh year and DEF CON 28 here in safe mode. 00:08.400 --> 00:09.220 I am Haim Cohen. 00:09.220 --> 00:10.620 I'm one of the hosts here. 00:11.200 --> 00:13.120 Let's just get some stuff out of the way. 00:13.120 --> 00:14.700 You can join us at Discord. 00:15.800 --> 00:17.200 You can find us there. 00:17.200 --> 00:18.800 We have a couple channels. 00:19.080 --> 00:25.840 The gold bug just opened up, so if you're interested in the gold bug puzzle, we did that very well. 00:28.940 --> 00:34.940 And let's just introduce our first speaker, Hanno Berg, and he's going to go. 00:36.000 --> 00:37.340 Yeah, hi. 00:37.920 --> 00:40.000 Let's switch these slides. 00:42.480 --> 00:45.180 Okay, you can go full screen and you can go. 00:49.440 --> 00:51.460 Okay, do you see the slides? 00:51.580 --> 00:53.020 I see them. 00:53.200 --> 00:54.840 Yeah, okay, great. 00:54.840 --> 00:57.220 Yeah, hello. 00:57.220 --> 01:02.640 So I'm Hanno and I'm going to talk about StartTLS today. 01:04.590 --> 01:12.340 This is some research that I've been doing together with Damian Hodebniak, Fabian Ising and Sebastian Schinzel. 01:12.340 --> 01:16.980 And we are soon going to publish a paper on this. 01:17.420 --> 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. 01:32.100 --> 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. 01:45.260 --> 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. 01:55.300 --> 02:04.060 And this is called implicit TLS because we kind of implicitly are using TLS based on the port number. 02:04.060 --> 02:06.940 We already know that this is an encrypted connection. 02:06.940 --> 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. 02:25.080 --> 02:30.780 And in the web we are only using implicit TLS basically. 02:30.780 --> 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. 02:44.400 --> 02:50.140 But StartTLS, the most common usage is in the context of emails. 02:52.320 --> 03:00.560 And in this talk I am mostly going to talk about the connection between an email client and the server. 03:00.560 --> 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. 03:19.880 --> 03:27.420 So all email protocols we use, I guess you are aware of that, we have SMTP, POP3 and IMAP. 03:27.420 --> 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. 03:37.040 --> 03:39.740 All of these protocols support StartTLS. 03:39.740 --> 03:47.420 And for the client to server communication these protocols also all support implicit TLS. 03:47.420 --> 03:51.640 So we kind of, as a user we can choose which one we use. 03:51.640 --> 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. 04:00.940 --> 04:05.560 So how does this StartTLS work? 04:06.100 --> 04:11.880 So these email protocols, they are all kind of relatively simple text protocols. 04:11.880 --> 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. 04:18.840 --> 04:22.800 So this is an SMTP session here. 04:23.080 --> 04:27.540 The S and C at the beginning that is server and client. 04:27.960 --> 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. 04:43.560 --> 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. 04:51.340 --> 04:55.670 And then the server usually gets back with a list of features that the server supports. 04:56.280 --> 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. 05:09.360 --> 05:11.980 And then the client can use this star TLS. 05:11.980 --> 05:14.960 This is simply a text command. 05:14.960 --> 05:17.760 It gives them this command star TLS. 05:17.760 --> 05:23.500 Then the server answers with a 220 code which means everything is all right . 05:23.640 --> 05:26.660 And the okay behind that is basically meaningless. 05:26.660 --> 05:28.600 That's more or less like a comment. 05:29.760 --> 05:31.900 And then we do a handshake. 05:31.900 --> 05:38.220 And for the colors here, the gray thing is the plain text part of the protocol. 05:38.400 --> 05:40.320 And then we have a TLS handshake. 05:40.320 --> 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. 05:49.240 --> 05:56.300 So we expect that there's some sense of security here while the thing at the beginning, it's plain text. 05:56.300 --> 05:59.700 So an attacker can read it, an attacker can manipulate it. 06:00.200 --> 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. 06:07.900 --> 06:10.200 So we send this elo command again. 06:10.420 --> 06:13.600 And then maybe we can do a login and send an email. 06:14.000 --> 06:18.080 And you don't need to understand the details of how the protocol works. 06:18.080 --> 06:22.560 But the basic idea just that should stick here is we have a plain text protocol. 06:22.660 --> 06:25.620 We have a command that starts a TLS connection. 06:25.620 --> 06:29.480 Then we do a handshake and then we kind of move this protocol into TLS. 06:31.560 --> 06:40.220 Now, first, something which is obvious, that if you use start TLS in an opportunistic way, this is insecure. 06:40.300 --> 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. 06:52.920 --> 06:57.820 And if the server does not offer it, then I will just stay in plain text mode. 06:58.440 --> 07:04.040 So we will use start TLS if we can, but if not, then we will just do plain text. 07:04.360 --> 07:09.560 And a network attacker can attack this. 07:11.200 --> 07:14.840 We figured out that this is actually not that common anymore. 07:14.840 --> 07:21.660 This used to be the case maybe 10 years ago, but today most clients don't really do this anymore. 07:21.920 --> 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. 07:37.320 --> 07:47.420 So that is obviously insecure, but that's not really what our research was about because that's, yeah. 07:49.840 --> 07:50.620 Yeah. 07:50.620 --> 07:55.240 But this turns out to be not the only security problem with start TLS. 07:55.240 --> 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. 08:07.000 --> 08:09.660 But it turns out that this is not the case. 08:11.800 --> 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. 08:21.040 --> 08:26.860 It can be in a plain text state and in an encrypted state after the TLS handshake. 08:29.860 --> 08:33.980 And this raises quite a few questions. 08:34.800 --> 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? 08:45.300 --> 08:48.380 What can happen in the plain text part? 08:48.620 --> 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. 09:04.800 --> 09:12.640 And also you could ask, do the implementations, do they have a clear understanding what is encrypted and not encrypted? 09:12.640 --> 09:15.540 And do they clearly separate that? 09:17.820 --> 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. 09:32.140 --> 09:36.040 And these alerts, it turns out, they can be sent at any time. 09:36.140 --> 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. 09:52.680 --> 09:59.640 It is sent in plain text, even though the mail client is configured to use a secure connection. 09:59.640 --> 10:04.180 And here you can even see, you can even include a link which will be highlighted. 10:04.280 --> 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. 10:15.900 --> 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. 10:22.620 --> 10:25.660 So he may want to trust it. 10:25.660 --> 10:32.360 So yeah, this is just a design problem of the protocol, how it is specified. 10:34.740 --> 10:39.900 But then we came upon the issue of buffering bugs. 10:39.900 --> 10:42.900 And this is something that has been known for a while. 10:43.920 --> 10:48.980 And the question here is really, is something part of the TLS session or not? 10:48.980 --> 10:52.360 And do clients and servers have a good idea about this? 10:53.620 --> 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. 11:05.480 --> 11:08.660 This was discovered by the author of Postfix. 11:10.000 --> 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. 11:30.640 --> 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. 11:49.140 --> 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. 12:06.480 --> 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. 12:19.820 --> 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. 12:27.180 --> 12:34.560 Like we send something in plain text but the server kind of thinks that this is part of the TLS connection. 12:36.900 --> 12:41.620 Yeah, so that's basically what I just said. 12:43.160 --> 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. 12:55.100 --> 13:02.720 So there's an advisory by US CERT from that time which contains a long list of affected servers. 13:02.720 --> 13:05.900 So this turned out to be a very widespread problem. 13:06.880 --> 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. 13:25.980 --> 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. 13:38.780 --> 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. 13:56.240 --> 14:02.500 So we have again this start message that's not really the interesting part. 14:02.500 --> 14:09.660 The interesting part begins where we have the start TLS and then this red stuff, this is injected by an attacker. 14:09.660 --> 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. 14:17.260 --> 14:19.260 That's why we have to send that. 14:19.320 --> 14:22.400 And then the attacker locks in with its own credentials. 14:22.400 --> 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. 14:30.800 --> 14:32.740 So that is a plausible assumption. 14:33.220 --> 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. 14:49.360 --> 14:52.680 And then we get an answer from the server. 14:52.680 --> 14:55.540 This is now the answer to the start TLS command. 14:55.740 --> 15:01.580 So now we're doing a TLS handshake the client and the server but we have these injected commands. 15:03.200 --> 15:07.700 And then the server will answer to these injected commands. 15:07.700 --> 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. 15:18.100 --> 15:23.320 And now what happens is that the client doesn't know about any of this. 15:23.320 --> 15:26.960 It doesn't read from the server because it doesn't expect it to send anything. 15:26.960 --> 15:33.040 It sends its own elo command, it authenticates and then it starts sending a mail. 15:33.260 --> 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. 15:45.280 --> 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. 15:56.440 --> 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. 16:07.260 --> 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. 16:18.020 --> 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. 16:25.120 --> 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. 16:39.240 --> 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. 16:45.360 --> 16:49.040 But it is a bit more difficult than the SMTP attack. 16:51.180 --> 16:55.440 Okay, so this bug was discovered in 2011. 16:55.740 --> 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. 17:04.760 --> 17:11.220 So we did some scans and we found out that, yeah, in SMTP servers 1.5% are vulnerable. 17:12.920 --> 17:17.040 In IMAP and POP3 it's more, it's around 2.5%. 17:18.360 --> 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. 17:27.620 --> 17:34.340 But the very same class of bug can happen in basically every protocol that supports StarTLS. 17:35.280 --> 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. 17:48.580 --> 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? 17:57.060 --> 17:59.640 That is, on the client side. 17:59.880 --> 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? 18:07.280 --> 18:09.340 And in turns out, yes, we can do that. 18:09.340 --> 18:11.560 So the idea is pretty much the same. 18:11.560 --> 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. 18:22.620 --> 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. 18:31.400 --> 18:37.220 So yes, this attack also, this vulnerability also exists on the client side. 18:40.860 --> 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. 18:54.380 --> 19:01.420 This is not that severe, but for example it can be used by an attacker to spoof mailbox content. 19:01.580 --> 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. 19:08.740 --> 19:15.900 So for example, you can show the user an IMAP inbox that is not his own and that contains other data. 19:17.920 --> 19:20.820 So it's still an issue. 19:21.040 --> 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. 19:28.860 --> 19:31.480 So this is a very very widespread issue. 19:34.720 --> 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. 19:53.540 --> 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. 20:05.760 --> 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. 20:23.240 --> 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. 20:32.220 --> 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. 20:45.400 --> 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. 21:09.440 --> 21:10.760 Yeah. 21:11.560 --> 21:14.300 There's more issues with DartTLS. 21:16.040 --> 21:22.280 One, the IMAP protocol has a feature which is called pre-auth. 21:22.400 --> 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. 21:38.540 --> 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. 21:55.200 --> 22:03.960 So now, DartTLS, the standard clearly says that it must not be performed in an authenticated state. 22:04.920 --> 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. 22:20.280 --> 22:22.200 Now, what should a client do? 22:22.200 --> 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. 22:30.600 --> 22:34.640 Like this is kind of a logical inconsistency in the standard. 22:35.280 --> 22:38.640 The standard doesn't really say anything about this. 22:38.640 --> 22:43.400 This is just where the standard has an internal conflict. 22:45.400 --> 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. 22:59.360 --> 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. 23:09.820 --> 23:18.500 Now, not surprisingly, some clients will allow pre-auth connection and then just don't do DartTLS because they can't. 23:19.160 --> 23:22.920 And this is also a security flaw. 23:22.920 --> 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. 23:35.620 --> 23:45.360 So you cannot steal credentials because the client is already authenticated, but you can forge the content of the inbox. 23:45.360 --> 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. 23:55.560 --> 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. 24:07.680 --> 24:11.940 Then there's an IMAP feature which is called mailbox referrals. 24:12.120 --> 24:17.880 And the idea here is that the server can tell a client that it should use another server. 24:17.900 --> 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. 24:29.580 --> 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. 24:39.020 --> 24:43.480 And then you can do this referral, which refers the client to another server. 24:43.560 --> 24:45.680 And this can be our attacker server. 24:45.860 --> 24:50.680 So we prevent the TLS connection from happening as an attacker. 24:50.740 --> 24:54.800 Then we forward the user to a server and we control that server. 24:54.800 --> 24:58.340 So this can have TLS and the client logs in. 24:58.500 --> 25:00.540 And then we have the client's credentials. 25:00.940 --> 25:03.480 So this is also a pretty severe attack. 25:05.100 --> 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. 25:13.760 --> 25:18.420 So we only found one mail client where we could perform this attack. 25:18.420 --> 25:20.680 This was a mail client called Alpine. 25:21.060 --> 25:26.040 So most mail clients, they just don't support these features, so they are not affected by this. 25:27.380 --> 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. 25:38.540 --> 25:45.640 So yeah, to summarize that, so StartTLS has a systemic problem with buffering bugs. 25:45.640 --> 25:48.740 They can appear both on the server and the client sites. 25:48.940 --> 25:55.960 There are several features in IMAP that are problematic or insecure if you combine them with StartTLS. 25:56.020 --> 26:03.560 And also StartTLS does not really provide any security advantage over normal implicit TLS connection. 26:04.640 --> 26:11.980 So our conclusion is you should not use StartTLS for mail connections, for email client connections, I guess. 26:11.980 --> 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. 26:28.000 --> 26:31.540 And then you will not be affected by most of these attacks. 26:31.540 --> 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. 26:41.180 --> 26:47.160 If you run a mail server, you should definitely make sure that you support implicit TLS. 26:47.360 --> 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. 27:03.360 --> 27:06.200 And if you can, then disable StartTLS. 27:06.320 --> 27:12.160 Now we are aware that this is not an easy thing, particularly if you have existing customers. 27:12.160 --> 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. 27:21.740 --> 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. 27:32.740 --> 27:40.080 But if you start like a new mail server setting, then you can start right away without StartTLS. 27:43.020 --> 27:50.140 So then I want to talk a bit about the special case, the server-to-server or MTA-to-MTA connection. 27:50.140 --> 27:55.960 In case you don't know, MTA stands for Mail Transfer Agent, which is another word for mail server. 27:57.800 --> 28:00.780 So this situation there is a bit different. 28:01.380 --> 28:07.220 For one, there's currently no way to use implicit TLS on MTA-to-MTA connections. 28:07.220 --> 28:09.700 That's just not part of the standards. 28:09.700 --> 28:12.140 There's no RFC how to do this. 28:12.140 --> 28:19.940 And it would not be easy to implement that. 28:20.700 --> 28:27.720 And also, traditionally, the server-to-server connections are purely opportunistic. 28:27.720 --> 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. 28:35.120 --> 28:38.520 So even validating the set doesn't make much sense. 28:38.520 --> 28:42.500 And you usually don't have an expectation against active attackers. 28:43.060 --> 28:46.680 Now, this is changing a bit. 28:46.680 --> 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 . 29:02.180 --> 29:07.380 It would be a different talk to talk about the advantages and disadvantages of those. 29:07.380 --> 29:16.960 My personal opinion is that MTA-STS is the more promising mechanism, but that's a controversial discussion. 29:16.960 --> 29:18.880 Let's just put it like this. 29:20.320 --> 29:29.720 But so yeah , it would be challenging to introduce an implicit TLS mode into MTA -to-MTA connections. 29:29.720 --> 29:32.480 Like right now, we are just using star TLS. 29:32.480 --> 29:36.740 Even if we use this advanced mechanism, we are still using star TLS. 29:37.160 --> 29:42.700 And the problem here is like that we have a lot of compatibility issues here. 29:42.700 --> 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. 29:54.880 --> 30:01.240 So it would be very challenging to change the protocol to support an implicit TLS mode. 30:01.240 --> 30:04.400 So I don't see that happening anytime soon. 30:05.780 --> 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. 30:22.320 --> 30:28.420 If you think that you want to secure these server-to-server connections, then you also need to think about this. 30:30.120 --> 30:34.760 And you need to basically audit the implementation so they don't have these bugs. 30:36.560 --> 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. 30:51.600 --> 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. 31:06.640 --> 31:10.300 So there's lots of potential for future research here. 31:10.300 --> 31:14.960 Like this is something that should be tested in more settings. 31:18.560 --> 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. 31:29.340 --> 31:37.140 And for future protocols, maybe you should just only support implicit TLS. 31:38.240 --> 31:46.940 And then something that is kind of not on the security side, but we can also ask what about performance? 31:46.940 --> 31:48.560 What about speed? 31:49.940 --> 31:52.920 Because I don't know. 31:52.920 --> 31:57.660 I come from Germany and Germany is known for having pretty bad mobile Internet. 31:57.780 --> 32:02.300 Not sure if you're aware of that, but if you ever go to Germany, that's what you will experience. 32:02.540 --> 32:08.460 So if you try to send an email with a bad Internet connection, it's pretty annoying. 32:08.460 --> 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. 32:19.020 --> 32:24.300 So having a better performance here is good and also more reliability. 32:24.300 --> 32:29.220 If we need fewer connection roundtrips, then it's more reliable. 32:30.720 --> 32:32.820 This I also find interesting. 32:32.820 --> 32:36.580 There's been a lot of effort to reduce roundtrips in TLS. 32:36.820 --> 32:45.280 In TLS 1.3, by design, if you make a new connection, it has one roundtrip less than older TLS versions. 32:45.460 --> 32:49.140 And there's also a zero RTT mode, which is kind of... 32:50.360 --> 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. 32:58.920 --> 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. 33:08.820 --> 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. 33:24.280 --> 33:30.720 So for example, the server capabilities, you're always getting them again after the handshake. 33:30.740 --> 33:37.440 So you can think about this, that everything that is happening before we do this handshake, it is just wasted. 33:37.440 --> 33:39.360 It doesn't have any meaning. 33:39.360 --> 33:47.080 So this kind of directly leads to that if you use startTLS, you need more roundtrips. 33:47.080 --> 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. 33:57.300 --> 34:03.300 So avoiding startTLS is not just more secure, it's also just faster. 34:03.300 --> 34:05.220 Which is, I guess, good. 34:05.220 --> 34:08.780 And there are some other ways. 34:08.780 --> 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. 34:17.980 --> 34:21.720 So email authentication uses something called Zazzle. 34:23.460 --> 34:29.180 Zazzle is an authentication framework that is used in all three email protocols. 34:29.900 --> 34:33.320 And it's kind of an abstraction of different authentication methods. 34:33.320 --> 34:38.900 Although most of the time everyone uses username and password, but there are different authentication methods. 34:39.960 --> 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. 34:49.080 --> 34:55.600 And this Base64, it is basically, it's a zero byte, then a username, then another zero byte and a password. 34:56.800 --> 34:58.700 And that is our login. 34:58.700 --> 35:01.040 So this is one roundtrip to login. 35:01.580 --> 35:07.940 And we can have this thing below where we have authenticate login, then we have a new line. 35:08.080 --> 35:10.400 So this is kind of optional. 35:10.400 --> 35:15.800 We can, in this authenticate line, we can already send data or we can just not. 35:17.740 --> 35:20.660 And then the server asks for a username. 35:20.660 --> 35:24.020 This is also Base64 encoded and asks for a password. 35:24.480 --> 35:26.500 So this is three roundtrips. 35:26.500 --> 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. 35:37.080 --> 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. 35:45.720 --> 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. 35:54.940 --> 35:56.600 And of course, this is faster. 35:56.600 --> 36:01.880 This saves you a roundtrip if you can send data right away with the authentication command. 36:03.520 --> 36:09.080 And also, Zazzle has two different modes for username password authentication. 36:09.080 --> 36:10.960 They are called plain and login. 36:13.120 --> 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. 36:24.860 --> 36:27.060 In IMAP, this has one roundtrip. 36:27.060 --> 36:30.140 In POP3, it has two roundtrips. 36:32.760 --> 36:40.780 So this login method, this is not standardized and it is also declared obsolete by the IANA. 36:40.780 --> 36:47.260 So the IANA has a registry of Zazzle authentication methods and there it's declared as obsolete. 36:47.740 --> 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. 36:56.760 --> 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. 37:04.780 --> 37:07.280 So you save another roundtrip here. 37:09.360 --> 37:14.860 So the plain method is standardized and it's faster than login. 37:14.860 --> 37:17.480 So it's clearly the better method. 37:17.680 --> 37:20.440 And from the security, it doesn't really matter. 37:20.980 --> 37:23.600 It's a normal username and password authentication. 37:23.600 --> 37:25.600 There's nothing fancy about it. 37:27.340 --> 37:34.860 So almost everyone supports both, like both servers and clients, but there's not really a reason to support login. 37:36.120 --> 37:42.860 So if you want to have faster email, then you should use implicit TLS and not start TLS. 37:42.860 --> 37:47.620 You should support the sessil-ir, which is specifically in IMAP. 37:47.760 --> 37:51.080 And you should disable the sessil-login method. 37:51.280 --> 37:54.800 Like for example, I figured out my own mail server, it supported both. 37:54.800 --> 38:01.060 And my client, if it supported both, it used login because that was the first in the client. 38:01.680 --> 38:03.080 It's in class mail. 38:03.080 --> 38:05.880 It's the first method that it supports. 38:06.080 --> 38:09.020 So it's slower for no gain. 38:09.080 --> 38:12.120 And I disabled it on the server and now I'm saving. 38:14.940 --> 38:16.460 So yeah. 38:17.020 --> 38:19.200 Yeah, that was it. 38:19.920 --> 38:21.960 Yeah, don't use TLS. 38:22.100 --> 38:26.960 Thanks for listening and I guess we have some time for Q&A now. 38:31.040 --> 38:31.980 Hold on. 38:31.980 --> 38:33.760 Welcome back, everybody. 38:35.120 --> 38:40.280 Can you, Hanno, can you unshare your screen maybe so we can just see you? 38:40.280 --> 38:43.360 I just want to put my background on. 38:47.070 --> 38:48.070 Okay. 38:48.790 --> 38:51.650 So we have, I think we have three questions for you. 38:51.650 --> 38:52.990 Can you hear me? 38:53.770 --> 38:54.770 Okay. 38:55.790 --> 39:03.370 So is the implication that the clients in the SMTP case for ease just ignore responses from the server? 39:03.370 --> 39:06.990 I expect them to be a state machine that says, wait, what? 39:06.990 --> 39:08.870 I haven't started sending them yet. 39:08.870 --> 39:09.970 What do you mean? 39:11.250 --> 39:13.270 No, that's not the implication. 39:13.270 --> 39:20.070 So the client is not ignoring these answers, but it is like it is processing these line by line. 39:20.230 --> 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. 39:26.730 --> 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. 39:37.750 --> 39:40.130 Is this understandable? 39:40.130 --> 39:41.230 I hope so. 39:41.870 --> 39:43.690 We are monitoring the discord. 39:43.690 --> 39:47.330 So if they reply back, I can do it. 39:47.590 --> 39:48.170 Yeah. 39:50.350 --> 39:52.030 Actually, give me one second. 39:52.030 --> 39:55.930 I think we are going to try and share the slides with you so everyone can see it. 39:58.300 --> 40:00.040 Give me one second. 40:00.160 --> 40:01.220 Share this. 40:01.220 --> 40:02.320 I did that. 40:05.140 --> 40:06.340 Sorry, everybody. 40:06.340 --> 40:07.520 Let's see. 40:14.680 --> 40:17.020 So they want me to... let's see. 40:24.690 --> 40:26.150 I know we have dead air. 40:29.340 --> 40:31.700 Let's see if I can share the screen. 40:31.820 --> 40:34.400 I am now also in the discord. 40:35.240 --> 40:36.480 That's okay. 40:36.480 --> 40:39.740 I will be able to see questions later if they are. 40:51.180 --> 40:53.300 I see your screen now. 40:53.480 --> 40:54.420 Okay. 41:10.290 --> 41:13.530 The second 41:17.590 --> 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? 41:31.010 --> 41:32.530 It doesn't... 41:34.510 --> 41:37.650 I think the question is framing it wrong. 41:37.650 --> 41:45.890 The thing is, MTA STS is introducing an expectation that we didn't have previously. 41:45.890 --> 41:49.530 That is that these connections are secure against active attackers. 41:49.910 --> 41:53.230 And these attacks can compromise this expectation. 41:53.670 --> 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. 42:00.990 --> 42:05.430 And now we want to introduce connection security for that. 42:05.650 --> 42:07.750 So now we have to care about these attacks. 42:07.750 --> 42:10.570 But it doesn't really change the risk. 42:10.570 --> 42:16.670 It's just that what we try to achieve with MTA STS that is compromised if we have these vulnerabilities. 42:19.010 --> 42:20.710 Does that make sense? 42:21.270 --> 42:22.350 I mean... 42:23.350 --> 42:25.130 Yes, I understand it. 42:25.710 --> 42:32.850 Again, we can be in the Slack Discord and maybe later, if people have more questions, you can join in there. 42:33.570 --> 42:34.890 Last one that I have. 42:34.890 --> 42:38.530 In what kind of issues does the speaker see with implicit TLS? 42:41.070 --> 42:48.970 So I think if you compare start TLS and implicit TLS, there are no added issues by implicit TLS. 42:49.010 --> 42:51.550 Because it's just the simpler thing. 42:51.870 --> 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. 43:00.610 --> 43:03.630 And with implicit TLS, we just don't have that. 43:03.630 --> 43:09.790 So I don't see any risk in implicit TLS that you wouldn't have with start TLS. 43:10.050 --> 43:14.550 Of course, it has all the risks that you can have otherwise with TLS. 43:16.030 --> 43:24.110 If there's a bad implementation, if there's bad randomness or vulnerable algorithms, then you have all the same risks. 43:24.110 --> 43:27.150 But you would have the same risks with start TLS as well. 43:28.250 --> 43:30.510 We're getting another question. 43:30.510 --> 43:34.090 Any thoughts on Telnet start TLS? 43:35.150 --> 43:37.450 I have no idea, sorry. 43:37.710 --> 43:43.550 I have seen that it exists, but I'm not sure if anyone is using that. 43:43.650 --> 43:45.910 I would be curious if anyone is using that. 43:45.910 --> 43:51.110 I feel that people use SSH there usually. 43:52.030 --> 43:56.890 And then our final question, just thanking you for the talk. 43:56.890 --> 44:01.610 Is anyone working on email POP3 replacements with something more secure? 44:05.410 --> 44:06.530 I'm not sure. 44:06.530 --> 44:09.150 There's not really a problem with POP3. 44:09.570 --> 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. 44:18.150 --> 44:22.510 I'm also one of these weird people that I'm still using POP3. 44:22.510 --> 44:25.450 I like to have the mails on my laptop locally. 44:30.770 --> 44:34.170 If you use it with TLS, then it's a fine protocol. 44:35.570 --> 44:39.270 Well, again, we would like to thank you for your talk. 44:40.050 --> 44:44.410 If anybody has any more questions, you can hang out in the Discord. 44:45.130 --> 44:48.790 We'll try and relate them to you, anything like that. 44:48.790 --> 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. 44:59.090 --> 45:03.910 I want to remind everyone again that we have the Gold Bug Challenge that's still there. 45:04.170 --> 45:09.930 And I would like to, again, thank you for your talk and I hope you enjoyed yourself. 45:12.660 --> 45:14.120 I guess we wait. 45:17.000 --> 45:19.960 Okay, I can leave here now?