[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:10.620] I am Haim Cohen. 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:18.800] You can find us there. We have a couple channels. [00:19.080 --> 00:22.020] The gold bug just opened up, [00:22.020 --> 00:24.320] so if you're interested in the gold bug puzzle, [00:24.320 --> 00:25.840] we did that very well. [00:28.940 --> 00:32.300] And let's just introduce our first speaker, [00:32.300 --> 00:34.940] 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:00.720] So I'm Hanno and I'm going to talk about [01:00.720 --> 01:02.640] StartTLS today. [01:04.590 --> 01:07.040] This is some research that I've been doing [01:07.040 --> 01:10.480] together with Damian Hodebniak, Fabian Ising [01:10.480 --> 01:12.340] and Sebastian Schinzel. [01:12.340 --> 01:16.980] And we are soon going to publish a paper on this. [01:17.420 --> 01:19.420] Yeah, we kind of figured out that [01:19.420 --> 01:23.460] StartTLS seems to not be very well [01:23.460 --> 01:26.940] researched and it has some issues that are not very well known [01:26.940 --> 01:29.720] and we looked a bit deeper into this. [01:32.100 --> 01:33.120] So, [01:33.120 --> 01:35.880] from the general idea, I guess most people are [01:35.880 --> 01:38.140] roughly aware what StartTLS is, but [01:38.140 --> 01:41.440] if we talk about TLS connections, there's [01:41.440 --> 01:44.200] two ways to do a TLS connection. [01:45.260 --> 01:47.520] One way is that we have an extra [01:47.520 --> 01:50.420] port for the encrypted version of protocol [01:50.420 --> 01:53.840] where we directly start a TLS connection [01:53.840 --> 01:56.440] on that port. And this is called [01:56.440 --> 01:59.420] implicit TLS because we [01:59.420 --> 02:02.200] kind of implicitly are using TLS [02:02.200 --> 02:05.780] based on the port number. We already know that this is an encrypted [02:05.780 --> 02:08.700] connection. And then there's this other way [02:08.700 --> 02:11.560] which is StartTLS where we start with some [02:11.560 --> 02:14.660] protocol that is not encrypted and then we [02:14.660 --> 02:17.800] have some special command which is usually StartTLS [02:17.800 --> 02:21.040] command that upgrades [02:21.040 --> 02:23.780] this connection to be encrypted. [02:25.080 --> 02:26.920] And in the web [02:26.920 --> 02:29.660] we are only using implicit TLS [02:29.660 --> 02:33.040] basically. So what we usually do is that we have [02:33.040 --> 02:36.080] HTTPS which is kind of its own protocol [02:36.080 --> 02:38.440] on its own port which is [02:38.440 --> 02:42.920] HTTP protocol with a TLS wrapped around it. [02:44.400 --> 02:44.800] But [02:44.800 --> 02:47.820] StartTLS, the most common usage is [02:47.820 --> 02:50.140] in the context of emails. [02:52.320 --> 02:52.900] And [02:53.560 --> 02:56.900] in this talk I am mostly going to talk [02:56.900 --> 03:00.560] about the connection between an email client and the server. [03:00.560 --> 03:02.880] I will talk a bit about server to [03:02.880 --> 03:05.060] server connections later but also [03:05.800 --> 03:09.280] we haven't focused so much on this because this is kind of [03:10.600 --> 03:12.160] a different issue because [03:12.160 --> 03:15.340] the considerations for server to server are [03:15.340 --> 03:18.040] quite different than from client to server. [03:19.880 --> 03:21.260] So all email [03:21.260 --> 03:24.340] protocols we use, I guess you are aware [03:24.340 --> 03:27.420] of that, we have SMTP, POP3 and IMAP. [03:27.420 --> 03:30.240] We use SMTP to send emails, POP3 to [03:30.240 --> 03:32.940] fetch emails or IMAP also kind of to fetch [03:32.940 --> 03:36.260] emails but also to manage a mailbox on the [03:36.260 --> 03:39.740] server. All of these protocols support StartTLS. [03:39.740 --> 03:43.020] And for the client to server communication [03:43.420 --> 03:46.120] these protocols also all support [03:46.120 --> 03:49.420] implicit TLS. So we kind of, as a user [03:49.420 --> 03:52.380] we can choose which one we use. So if [03:52.380 --> 03:55.160] we can choose between the two then the obvious question is [03:55.160 --> 03:58.680] which one is better and which one is more secure. [04:00.940 --> 04:01.580] So [04:01.580 --> 04:03.740] how does this StartTLS [04:04.280 --> 04:07.280] work? So these email [04:07.280 --> 04:10.380] protocols, they are all kind of relatively simple [04:10.380 --> 04:12.700] text protocols. So it's a line-based [04:13.840 --> 04:16.560] protocol where a client sends a [04:16.560 --> 04:19.320] command to a server and gets some kind of answer. So [04:19.860 --> 04:23.600] this is an SMTP session here. [04:23.600 --> 04:25.580] The S and C at the beginning [04:25.580 --> 04:28.540] that is server and client. So [04:28.540 --> 04:31.480] if you connect to an SMTP server, the first thing [04:31.480 --> 04:34.400] is the server sends this line which [04:34.400 --> 04:37.360] is basically a hello message which contains its [04:37.360 --> 04:39.920] host name and a special [04:41.260 --> 04:43.640] code number. And [04:43.640 --> 04:46.580] then you send this elo command that is basically [04:46.580 --> 04:49.560] from the client, always the first command which is kind of [04:49.560 --> 04:52.520] introducing the client. And then the server usually [04:52.520 --> 04:55.670] gets back with a list of features that the server supports. [04:56.280 --> 04:58.400] And here you can see in this list [04:59.440 --> 05:01.420] that it ends with this [05:01.420 --> 05:04.440] 250 star TLS which means [05:04.440 --> 05:07.560] okay, the server just told us that it supports [05:07.560 --> 05:10.620] star TLS. And then the client can [05:10.620 --> 05:13.820] use this star TLS. This is simply a [05:13.820 --> 05:16.700] text command. It gives them this command [05:16.700 --> 05:20.440] star TLS. Then the server answers with [05:20.440 --> 05:22.860] a 220 code which means everything is [05:22.860 --> 05:25.960] all right. And the okay behind that [05:25.960 --> 05:28.600] is basically meaningless. That's more or less like a comment. [05:29.760 --> 05:32.720] And then we do a handshake. And for the [05:32.720 --> 05:35.560] colors here, the gray thing is [05:35.560 --> 05:38.700] the plain text part of the protocol. And [05:38.700 --> 05:41.120] then we have a TLS handshake. And the green [05:41.120 --> 05:44.620] thing here, that is then encrypted and authenticated [05:44.620 --> 05:47.500] with all the properties that we usually [05:47.500 --> 05:50.560] expect from a TLS connection. So we expect that there's [05:51.160 --> 05:53.460] some sense of security here [05:53.460 --> 05:56.440] while the thing at the beginning, it's plain text. So [05:56.440 --> 05:59.700] an attacker can read it, an attacker can manipulate it. [06:00.200 --> 06:02.540] And then basically we start over because [06:02.540 --> 06:05.740] kind of all the information we got before the TLS [06:05.740 --> 06:08.760] handshake, we don't really trust it. So we send this [06:08.760 --> 06:12.160] elo command again. And then maybe we can do a [06:12.160 --> 06:14.960] login and send an email. And you [06:14.960 --> 06:18.080] don't need to understand the details of how the protocol [06:18.080 --> 06:21.100] works. But the basic idea just that should stick here is [06:21.220 --> 06:23.840] we have a plain text protocol. We have a command that [06:23.840 --> 06:26.780] starts a TLS connection. Then we do a handshake and [06:26.780 --> 06:29.480] then we kind of move this protocol into TLS. [06:31.560 --> 06:33.000] Now, first, something [06:33.000 --> 06:35.960] which is obvious, that if you use [06:35.960 --> 06:38.880] start TLS in an opportunistic way, [06:38.880 --> 06:40.400] this is insecure. So [06:41.880 --> 06:44.180] there is some email clients [06:44.860 --> 06:48.020] implement start TLS in a way where they will say, [06:48.020 --> 06:51.240] okay, if the server offers start TLS, [06:51.240 --> 06:55.040] then I will use it. And if the server does not offer it, [06:55.040 --> 06:57.820] then I will just stay in plain text mode. [06:58.440 --> 07:00.560] So we will use start TLS [07:00.560 --> 07:04.040] if we can, but if not, then we will just do plain text. [07:04.360 --> 07:07.520] And a [07:07.520 --> 07:11.720] network attacker can attack this. [07:11.720 --> 07:12.660] We figured out that [07:12.660 --> 07:15.660] this is actually not that common anymore. This used to [07:15.660 --> 07:18.060] be the case maybe 10 years ago, but [07:18.060 --> 07:21.660] today most clients don't really do this anymore. [07:21.920 --> 07:24.200] And it's obvious that an attacker can [07:24.200 --> 07:26.820] in such a scenario, an attacker can just [07:27.400 --> 07:30.420] they can pretend to be the server and then they can say, [07:30.420 --> 07:33.020] yeah, I don't support start TLS and then [07:33.020 --> 07:36.500] the client logs in and then the attacker knows the username [07:36.500 --> 07:39.020] and password. So that is obviously [07:39.020 --> 07:42.120] insecure, but that's not really [07:42.120 --> 07:44.320] what our research was about because [07:44.320 --> 07:47.420] that's, yeah. [07:49.840 --> 07:50.620] Yeah. [07:50.620 --> 07:53.360] But this turns out to be not the only [07:53.360 --> 07:56.520] security problem with start TLS. So you could think, okay, [07:56.520 --> 07:59.460] this is a problem, but if we implement a client in a way [07:59.460 --> 08:02.580] that it always forces this start TLS connection [08:02.580 --> 08:05.940] and will just refuse to connect if it cannot do that, [08:05.940 --> 08:08.540] then this is secure. But it turns out that this is [08:08.540 --> 08:09.660] not the case. [08:11.800 --> 08:14.020] So if you look at what start TLS [08:14.020 --> 08:17.500] is, then it's kind of a form of state transition [08:17.500 --> 08:21.040] where you have the protocol, which can be in two states. [08:21.040 --> 08:23.740] It can be in a plain text state and [08:23.740 --> 08:26.860] in an encrypted state after the TLS handshake. [08:29.860 --> 08:30.820] And this [08:30.820 --> 08:33.980] raises quite a few questions. [08:34.800 --> 08:36.820] So at first you can ask, okay, [08:36.820 --> 08:40.140] we have the state transition, [08:40.140 --> 08:42.820] but which protocol features can we use before [08:42.820 --> 08:45.900] we turn the encryption on? What can [08:45.900 --> 08:49.200] happen in the plain text part? And also [08:49.200 --> 08:51.740] how should we treat the data that [08:51.740 --> 08:55.100] we got before the handshake, for example, server features [08:55.100 --> 08:58.160] or if there's any login, because we cannot [08:58.160 --> 09:00.820] really trust that data as it's [09:02.920 --> 09:04.800] obviously not secured. [09:04.800 --> 09:08.500] And also you could ask, do the implementations, [09:08.500 --> 09:11.160] do they have a clear understanding what is encrypted [09:11.160 --> 09:14.020] and not encrypted? And do they clearly [09:14.020 --> 09:15.540] separate that? [09:17.820 --> 09:20.100] So just one example, which is [09:20.440 --> 09:23.120] a relatively obvious problem, the IMAP protocol [09:23.120 --> 09:25.960] has a feature which is called alerts, [09:25.960 --> 09:29.140] which is basically the server sends a message to the client [09:29.140 --> 09:32.140] and the client is supposed to show this to the user. [09:32.140 --> 09:35.220] And these alerts, it turns out, they can be sent at any [09:35.220 --> 09:38.580] time. So they can be sent in the plain text [09:38.580 --> 09:41.180] part, which is [09:41.180 --> 09:44.100] interesting because this is a screenshot from [09:44.100 --> 09:47.560] Outlook where the [09:47.560 --> 09:50.500] IMAP server sends a message to the user and this [09:50.500 --> 09:53.080] message is not secure. It is [09:53.760 --> 09:56.040] sent in plain text, even though the [09:56.040 --> 09:59.640] mail client is configured to use a secure connection. [09:59.640 --> 10:02.620] And here you can even see, you can even include a link [10:02.620 --> 10:05.700] which will be highlighted. So we have here, [10:05.700 --> 10:08.580] your IMAP server wants to alert you [10:08.580 --> 10:11.260] to the following, please download my post something something [10:11.260 --> 10:14.540] and then the attacker can put in a link where he provides [10:14.720 --> 10:17.980] a malicious file. So we have an alert sent in plain text [10:17.980 --> 10:20.600] but to the user it looks like this is a legitimate [10:20.600 --> 10:23.460] message from his mail server. So he may [10:23.960 --> 10:25.660] want to trust it. [10:25.660 --> 10:28.840] So yeah, this is just a design [10:28.840 --> 10:32.360] problem of the protocol, how it is specified. [10:34.740 --> 10:37.760] But then we came upon the issue [10:37.760 --> 10:41.000] of buffering bugs. And this is something that [10:41.000 --> 10:42.900] has been known for a while. [10:43.920 --> 10:46.340] And the question here is really, is [10:46.340 --> 10:49.540] something part of the TLS session or not? And do [10:49.540 --> 10:52.360] clients and servers have a good idea about this? [10:53.620 --> 10:55.320] So there was a vulnerability [10:55.320 --> 10:58.980] in 2011 already, so this is nine years [10:58.980 --> 11:01.840] ago, which was named [11:01.840 --> 11:04.960] plain text command ejection in multiple implementations of [11:04.960 --> 11:07.600] star TLS. This was discovered by the author of [11:07.600 --> 11:10.460] Postfix. And [11:11.460 --> 11:13.660] what happened here is, like if we look [11:13.660 --> 11:16.640] again at this star TLS connection and [11:16.640 --> 11:19.720] this is like only the, I've shortened this a bit, I've [11:19.720 --> 11:22.820] cut away the stuff that currently doesn't matter, [11:22.820 --> 11:25.700] like we have this client sends the star [11:25.700 --> 11:28.680] TLS command, gets an answer from the server and then there's [11:28.820 --> 11:31.820] a handshake happening. Now, what [11:31.820 --> 11:34.920] can happen if we do something like this, where a client [11:34.920 --> 11:38.080] sends the star TLS command and [11:38.080 --> 11:40.380] then sends something else in plain text [11:41.300 --> 11:43.860] and then gets the answer [11:43.860 --> 11:46.800] from the server that he can now start the TLS handshake [11:46.800 --> 11:50.040] and then they do the TLS handshake. So it turns out [11:50.040 --> 11:53.140] that there are quite a few implementations of servers [11:53.140 --> 11:55.800] that will then process [11:56.340 --> 11:59.260] both of these commands, the star TLS and the [11:59.260 --> 12:02.180] whatever other command you sent together [12:02.180 --> 12:05.280] with the star TLS in a single TCP packet. [12:06.480 --> 12:07.480] That it will [12:07.480 --> 12:11.140] put this in some kind of buffer and process every command [12:11.140 --> 12:13.700] after another and then it will answer to this [12:14.300 --> 12:17.580] command that was appended to the star TLS [12:17.580 --> 12:21.080] in the TLS session. So we kind of have something [12:21.080 --> 12:24.200] here that traverses from the plain text part of the [12:24.200 --> 12:27.120] protocol to the TLS part of the protocol. [12:27.180 --> 12:29.660] Like we send something in plain text but the server [12:29.660 --> 12:32.960] kind of thinks that this is part [12:32.960 --> 12:34.560] of the TLS connection. [12:36.900 --> 12:37.900] Yeah, so [12:39.420 --> 12:41.620] that's basically what I just said. [12:43.160 --> 12:46.260] So this bug was originally found in Postfix [12:46.260 --> 12:49.240] but it turned out it affected multiple mail servers [12:49.240 --> 12:52.220] including Cyrus, Courier, Qmail [12:52.220 --> 12:55.100] and various proprietary mail stacks. [12:55.100 --> 12:58.320] So there's an advisory by [12:58.320 --> 13:01.360] US CERT from that time which contains a long list of [13:01.360 --> 13:04.120] affected servers. So this turned out to be a very [13:04.120 --> 13:05.900] widespread problem. [13:06.880 --> 13:10.020] Now you may wonder how you can attack this and this is [13:10.020 --> 13:12.780] kind of, I think this is maybe part of the reason why this [13:12.780 --> 13:15.960] bug is not very well known because the Postfix [13:15.960 --> 13:18.880] authors, they have described very well what [13:18.880 --> 13:21.580] the problem is but they haven't really [13:21.580 --> 13:25.080] published any exploit or explained how you could actually [13:25.080 --> 13:27.280] attack this. So it was kind of seen by [13:28.020 --> 13:30.200] and there was some [13:30.820 --> 13:33.920] email discussions from mail server developers where people were [13:33.920 --> 13:36.780] like, yeah, this is kind of a weird behavior but it's not really [13:36.900 --> 13:39.860] a security problem. But you can actually [13:39.860 --> 13:41.820] attack this pretty easily and [13:43.500 --> 13:44.920] this takes a bit of [13:45.660 --> 13:47.340] thinking what's going on here but [13:48.060 --> 13:51.720] so this is the first part [13:51.720 --> 13:54.740] of the attack which is we start a connection [13:54.740 --> 13:57.520] that is in plain text. So we have again [13:57.520 --> 14:00.160] this start message [14:00.780 --> 14:03.520] that's not really the interesting part. The interesting part begins [14:03.520 --> 14:06.460] where we have the start TLS and then this red [14:06.460 --> 14:09.660] stuff, this is injected by an attacker. [14:09.660 --> 14:12.040] So the attacker is injecting here another [14:12.040 --> 14:15.480] elo command which is, that is just always the first command [14:15.480 --> 14:19.260] that comes after start TLS. That's why we have to send that. [14:19.320 --> 14:21.460] And then the attacker locks in with its own [14:21.460 --> 14:24.620] credentials. So our assumption here is the attacker also [14:24.620 --> 14:27.760] has an account on this mail server but it could be something [14:27.760 --> 14:30.620] like a public email provider [14:30.620 --> 14:33.500] address. So that is a plausible assumption. And then [14:33.500 --> 14:36.480] the attacker is starting to send an email like [14:37.620 --> 14:39.780] he's setting a from address and a to [14:39.780 --> 14:42.680] address and the to address particularly is his own address [14:42.680 --> 14:45.560] and then it sends this data command which is basically [14:45.560 --> 14:47.740] now the email content starts. [14:49.360 --> 14:51.860] And then we get an answer [14:51.860 --> 14:54.740] from the server. This is now the answer to the start TLS [14:54.740 --> 14:57.820] command. So now we're doing a TLS handshake [14:57.820 --> 15:01.580] the client and the server but we have these injected commands. [15:03.200 --> 15:03.560] And then [15:04.960 --> 15:06.740] the server will answer to these [15:06.740 --> 15:09.840] injected commands. So it will send this normal greeting that always [15:09.840 --> 15:12.700] comes after the elo command and then it will [15:12.700 --> 15:15.640] authenticate the user and then it will say [15:15.640 --> 15:18.980] okay now the email starts. And now what happens [15:18.980 --> 15:21.940] is that the client doesn't know [15:21.940 --> 15:24.860] about any of this. It doesn't read from the server because [15:24.860 --> 15:27.720] it doesn't expect it to send anything. It sends its own [15:27.720 --> 15:30.200] elo command, it authenticates [15:30.800 --> 15:33.980] and then it starts sending a mail. Now what happens [15:33.980 --> 15:36.740] is that all this stuff, all this blue stuff [15:36.740 --> 15:39.920] which the client sends, this ends up being part [15:39.920 --> 15:42.800] of this email that we started sending [15:42.800 --> 15:45.980] to ourselves as an attacker. So the attacker [15:45.980 --> 15:49.160] now gets an email and that contains the [15:49.160 --> 15:53.000] authentication data from the victim, [15:53.860 --> 15:56.440] so this is a pretty severe attack. [15:56.440 --> 15:59.160] Like if you're a network attacker and we have a server vulnerable [15:59.160 --> 16:02.020] to this, we can force the client to send [16:02.020 --> 16:04.480] his credentials to us. [16:07.260 --> 16:10.180] There's a similar attack with IMAP that is [16:10.520 --> 16:13.300] a bit more tricky because like you can, in IMAP [16:13.300 --> 16:16.400] you can kind of store a mail into a mailbox and then [16:16.400 --> 16:19.240] it's the same idea. One problem with that [16:19.240 --> 16:22.180] was that in order to do that you need to know the exact [16:22.180 --> 16:24.980] size of the message that's going to come. [16:25.120 --> 16:28.220] That means you kind of need to guess how long [16:28.220 --> 16:31.160] the password of the user is, but you may be [16:31.160 --> 16:33.820] able to see that with a side channel attack and also [16:33.820 --> 16:37.140] it turns out that many mail servers on failed login [16:37.140 --> 16:40.080] attempts, they will just try to reconnect. So you have kind of [16:40.080 --> 16:43.300] as an attacker, you have multiple tries to do this [16:43.300 --> 16:46.060] so it's still a feasible attack. But it is [16:46.480 --> 16:49.040] a bit more difficult than the SMTP attack. [16:51.180 --> 16:53.740] Okay, so this bug was discovered [16:53.740 --> 16:56.760] in 2011. So you would hope [16:56.760 --> 16:59.980] that people have fixed this, but as probably [16:59.980 --> 17:02.540] no one is surprised, it's actually not [17:02.540 --> 17:06.140] fixed everywhere. So we did some scans [17:06.140 --> 17:08.860] and we found out that, yeah, in SMTP servers [17:08.860 --> 17:11.220] 1.5% are vulnerable. [17:12.920 --> 17:14.660] In IMAP and POP3 [17:14.660 --> 17:17.040] it's more, it's around 2.5%. [17:18.360 --> 17:21.100] I guess the reason why this is different is [17:21.100 --> 17:23.980] because this was originally described in an SMTP [17:23.980 --> 17:27.360] server, so that's probably where people had it on the radar. [17:27.620 --> 17:30.140] But the very same class of [17:30.140 --> 17:33.240] bug can happen in basically every protocol that supports [17:33.240 --> 17:36.180] StarTLS. Although I have [17:36.180 --> 17:38.200] to say for POP3, we [17:38.840 --> 17:42.220] didn't really find an exploit to attack [17:42.220 --> 17:45.760] this, but it's still kind of something that should be fixed. [17:48.580 --> 17:51.020] Now there's another question you can ask [17:51.020 --> 17:53.680] and that is, can we have the same [17:53.680 --> 17:57.060] kind of bug, but the other way around? [17:57.060 --> 17:59.640] That is, on the client side. [17:59.880 --> 18:02.980] So can we confuse the client to get data [18:02.980 --> 18:06.740] 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:12.000] So the idea is pretty much the same. The client [18:12.000 --> 18:14.780] sends a StarTLS command, then the server sends this [18:14.780 --> 18:17.780] 220 code, which is kind of the [18:17.780 --> 18:21.040] just approving that, yeah, I got the StarTLS, now we can do [18:21.040 --> 18:23.040] TLS. And then [18:23.780 --> 18:26.880] we can append additional data that's coming from the server [18:26.880 --> 18:30.040] and then the client will interpret that as part of the TLS [18:30.040 --> 18:32.900] session. So yes, this attack [18:32.900 --> 18:35.780] also, this vulnerability also exists [18:35.780 --> 18:37.220] on the client side. [18:40.860 --> 18:41.900] So clients [18:41.900 --> 18:44.820] can be vulnerable to the same class of bug and we have [18:44.820 --> 18:47.840] called this a response injection because the other thing was [18:47.840 --> 18:51.100] called a command injection and here we call it a response injection. [18:54.380 --> 18:57.040] This is not that severe, but for example [18:57.040 --> 18:59.920] it can be used by an attacker to spoof [18:59.920 --> 19:02.800] mailbox content. You kind of have to guess [19:02.800 --> 19:05.700] what commands the client will send, but if you know [19:05.700 --> 19:08.740] which mail client it is, you can usually know that. [19:08.740 --> 19:11.800] So for example, you can show the user an [19:11.800 --> 19:14.820] IMAP inbox that is not his own and that contains [19:14.820 --> 19:15.900] other data. [19:17.920 --> 19:20.820] So it's still an issue. [19:21.040 --> 19:23.320] And the really [19:23.960 --> 19:26.760] surprising thing was that more than half of the mail clients [19:26.760 --> 19:29.900] that we tested were vulnerable to this bug. So this is a very [19:29.900 --> 19:31.480] very widespread issue. [19:34.720 --> 19:35.960] So to sum [19:35.960 --> 19:39.040] that up a bit, this DartTLS command injection, it was [19:39.040 --> 19:41.780] discovered in 2011 and it affected multiple [19:42.720 --> 19:45.220] implementations and even though many [19:45.220 --> 19:47.700] implementations were found back then, they are still [19:47.700 --> 19:51.320] widely used vulnerable implementations. [19:53.540 --> 19:54.380] Also, [19:54.380 --> 19:57.140] the same bug class exists on the client and the [19:57.140 --> 19:59.340] majority of implementations are vulnerable [19:59.960 --> 20:03.400] or were until we have reported it to them. [20:05.760 --> 20:07.840] And just very generally, [20:07.840 --> 20:10.660] if you're doing an implementation of DartTLS [20:10.660 --> 20:13.460] and you're not aware of this bug and you're doing a naive [20:13.460 --> 20:16.600] implementation, then you will have some kind of command [20:16.600 --> 20:19.580] buffer where you read the commands line by line [20:19.580 --> 20:23.160] and then you will usually have this bug too. [20:23.240 --> 20:25.820] So it's kind of one of these things where [20:25.820 --> 20:28.960] you have to actively be aware of this bug in order to [20:28.960 --> 20:30.140] prevent it. [20:32.220 --> 20:34.340] And this, in my [20:34.340 --> 20:37.520] opinion, is a clear sign that [20:37.520 --> 20:40.340] this is not something where we should say [20:40.340 --> 20:43.760] this is a flaw in the mail client, but this is a systemic [20:43.760 --> 20:46.720] problem in the standard. Like if you have a situation [20:46.720 --> 20:49.800] where the same bug appears again and again and [20:49.800 --> 20:53.280] again and in multiple different implementations, [20:53.280 --> 20:55.180] then you should wonder [20:55.180 --> 20:58.660] if this is something where we can [20:59.480 --> 21:02.820] just... if we can do better on the level of the standard [21:02.820 --> 21:05.680] and not say it's the flaw of the [21:05.680 --> 21:07.280] implementations. [21:09.440 --> 21:10.760] Yeah. [21:11.560 --> 21:14.300] There's more issues with DartTLS. [21:16.040 --> 21:17.900] One, the IMAP [21:17.900 --> 21:20.900] protocol has a feature which is called [21:20.900 --> 21:24.280] pre-auth. The idea here is [21:24.280 --> 21:28.640] that an IMAP server can, [21:28.640 --> 21:32.860] send a line which basically tells [21:32.860 --> 21:36.040] the client you're already logged in, you don't have to [21:36.040 --> 21:37.260] authenticate. [21:38.540 --> 21:41.320] So the idea here is, for example, if you have a controlled [21:41.320 --> 21:44.820] network where you do authentication based on IP [21:44.820 --> 21:47.780] addresses, maybe then you can say, okay, if a connection [21:47.780 --> 21:50.880] comes from this IP address, then we just assume [21:50.880 --> 21:53.880] that this is already authenticated and the user is [21:53.880 --> 21:55.200] already logged in. [21:55.200 --> 21:59.160] So now, DartTLS, [21:59.160 --> 22:01.900] the standard clearly says that it must not be performed [22:01.900 --> 22:03.960] in an authenticated state. [22:04.920 --> 22:08.480] So if we take these two things together, [22:08.480 --> 22:11.220] like we have a feature, DartTLS, [22:11.220 --> 22:13.980] that you must not use when in an authenticated [22:13.980 --> 22:16.980] state, but the server answers with this pre-auth line [22:16.980 --> 22:20.120] which says you are already authenticated. [22:20.280 --> 22:23.060] Now, what should a client do? Like we have a client [22:23.060 --> 22:25.860] that connects to a server, it gets this response, it's [22:25.860 --> 22:29.180] configured to use DartTLS, then we kind of have [22:29.320 --> 22:31.160] a contradiction here. Like this is [22:31.980 --> 22:34.640] 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:41.080] This is just where the standard [22:41.080 --> 22:43.400] has an internal conflict. [22:45.400 --> 22:45.500] And [22:47.520 --> 22:49.980] after all, the only reasonable way [22:49.980 --> 22:53.000] for a client to react to this is to just [22:53.000 --> 22:56.160] terminate the connection, because it cannot do DartTLS [22:56.160 --> 22:57.800] in this situation. [22:59.360 --> 23:02.100] So there's no way to secure this connection [23:02.100 --> 23:05.000] and if it's configured to have a secure connection, [23:05.000 --> 23:07.900] it should just not accept this. [23:09.820 --> 23:10.840] Now, [23:10.840 --> 23:13.980] not surprisingly, some clients will allow pre-auth [23:13.980 --> 23:17.020] connection and then just don't do DartTLS because [23:17.020 --> 23:18.500] they can't. [23:19.160 --> 23:22.920] And this is also a security flaw. [23:22.920 --> 23:25.780] You also obviously can do mailbox content spoofing, [23:25.780 --> 23:29.100] like you're a network attacker person in the middle [23:29.100 --> 23:31.900] and then client connects, you send this pre-auth [23:31.900 --> 23:34.740] response and then you're kind of the upstream server [23:34.740 --> 23:37.860] for that client. So you cannot steal credentials because [23:37.860 --> 23:40.780] the client is already authenticated, but [23:40.780 --> 23:44.140] you can forge the content [23:44.140 --> 23:47.280] of the inbox. And also, you can sometimes steal [23:47.280 --> 23:50.460] mail, for example, if you're using IMAP [23:50.460 --> 23:52.940] then usually a sent mail is stored in the [23:52.940 --> 23:56.200] send folder, so that you can steal. And some clients [23:56.200 --> 23:59.040] also, when they connect to an IMAP server, they start [23:59.040 --> 24:01.640] synchronizing folders, so [24:01.640 --> 24:04.880] there you may be able to steal mailbox content. [24:07.680 --> 24:08.240] Then [24:08.240 --> 24:10.920] there's an IMAP feature which is called mailbox [24:10.920 --> 24:13.960] referrals. And the idea here is that [24:13.960 --> 24:16.960] the server can tell a client that it should use another [24:16.960 --> 24:19.740] server. So it's something like a forward [24:19.740 --> 24:23.100] feature, where a server can say, yeah, [24:23.100 --> 24:25.960] like I'm forwarding you to this other server if you want [24:25.960 --> 24:27.540] to access this mailbox. [24:29.580 --> 24:31.920] And now the interesting thing is [24:31.920 --> 24:34.900] if you combine these two things, you have this pre-auth, which [24:34.900 --> 24:37.860] means you can prevent the client from starting a TLS [24:37.860 --> 24:40.800] connection. And then you can do this referral, which [24:40.800 --> 24:43.840] refers the client to another server. And this [24:43.840 --> 24:46.080] can be our attacker server. So [24:46.080 --> 24:49.820] we prevent the TLS connection from happening as an [24:49.820 --> 24:52.820] attacker. Then we forward the user to a server [24:52.820 --> 24:55.960] and we control that server. So this can have [24:55.960 --> 24:58.840] TLS and the client logs in. And then [24:58.840 --> 25:01.880] we have the client's credentials. So this is also [25:02.020 --> 25:03.480] a pretty severe attack. [25:05.100 --> 25:06.800] We have to say here that [25:06.800 --> 25:09.960] this mailbox referrals feature, and there's a similar [25:09.960 --> 25:12.880] feature called login referrals, these are not widely [25:12.880 --> 25:15.760] supported. So we only found one [25:15.760 --> 25:18.780] mail client where we could perform this attack. This was [25:18.940 --> 25:21.740] a mail client called Alpine. So most [25:21.740 --> 25:24.560] mail clients, they just don't support these features, so they are not [25:24.560 --> 25:28.080] affected by this. But still [25:28.080 --> 25:30.940] it shows kind of that there are features in IMAP [25:30.940 --> 25:33.800] where it's not really thought through what that [25:33.800 --> 25:36.840] means in combination with StartTLS. [25:38.540 --> 25:39.880] So yeah, [25:39.880 --> 25:43.040] to summarize that, so StartTLS [25:43.040 --> 25:45.960] has a systemic problem with buffering bugs. They can [25:45.960 --> 25:49.080] appear both on the server and the client sites. There [25:49.080 --> 25:51.760] are several features in IMAP that are problematic [25:51.760 --> 25:55.960] or insecure if you combine them with StartTLS. [25:56.020 --> 25:57.800] And also StartTLS does not [25:57.800 --> 26:00.720] really provide any security advantage over [26:00.720 --> 26:03.560] normal implicit TLS connection. [26:04.640 --> 26:06.960] So our conclusion is you should [26:06.960 --> 26:09.940] not use StartTLS for mail connections, for [26:09.940 --> 26:12.420] email client connections, I guess. So [26:14.160 --> 26:15.640] if you are [26:15.640 --> 26:18.780] using email, which I guess most of you do, and if you're using [26:18.940 --> 26:21.820] a mail client, then you should change [26:21.820 --> 26:24.880] its configuration to use the implicit TLS [26:24.880 --> 26:27.460] pods and not to use StartTLS. [26:28.000 --> 26:30.820] And then you will not be affected by most of these [26:30.820 --> 26:34.060] attacks. Some can still happen, but because some [26:34.060 --> 26:37.020] it's enough when the server is supporting StartTLS, [26:37.020 --> 26:39.580] but most of these attacks will be prevented. [26:41.180 --> 26:42.880] If you run a mail server, [26:42.880 --> 26:45.720] you should definitely make sure that you support [26:45.720 --> 26:48.780] implicit TLS. I mean, there's [26:48.780 --> 26:51.580] an RFC that says that you should use the implicit [26:51.580 --> 26:55.620] TLS pods, but there are, for example, [26:55.620 --> 26:57.960] the Microsoft SMTP [26:57.960 --> 27:00.780] servers, they don't support implicit TLS [27:00.780 --> 27:03.800] for SMTP. And if [27:03.800 --> 27:06.620] you can, then disable StartTLS. Now [27:06.620 --> 27:09.980] we are aware that this is not an easy thing, [27:09.980 --> 27:12.880] particularly if you have existing customers. Like if you have [27:12.880 --> 27:15.640] an existing user base, then telling them, [27:15.640 --> 27:18.820] yeah, sorry, half of your mail configurations will [27:18.820 --> 27:21.680] break next week, that's a tough thing to do. [27:21.740 --> 27:24.900] So I'll say it would be ideal to just disable it [27:24.900 --> 27:27.360] on the server, but this [27:28.040 --> 27:30.800] is probably not feasible for people [27:30.800 --> 27:33.260] who have existing user bases. But if you [27:33.900 --> 27:36.820] start like a new mail server setting, then [27:36.820 --> 27:40.080] you can start right away without StartTLS. [27:43.020 --> 27:43.620] So [27:43.620 --> 27:46.360] then I want to talk a bit about the special case, [27:46.360 --> 27:49.020] the server-to-server or MTA-to-MTA [27:49.020 --> 27:52.280] connection. In case you don't know, MTA stands [27:52.280 --> 27:55.960] for Mail Transfer Agent, which is another word for mail server. [27:57.800 --> 27:58.320] So [27:58.320 --> 28:00.780] this situation there is a bit different. [28:01.380 --> 28:04.360] For one, there's currently no way to use implicit [28:04.360 --> 28:07.220] TLS on MTA-to-MTA connections. [28:07.220 --> 28:10.160] That's just not part of the standards. There's no [28:10.160 --> 28:12.140] RFC how to do this. [28:12.140 --> 28:12.880] And [28:15.080 --> 28:17.800] it would not be easy to [28:17.800 --> 28:19.940] implement that. [28:20.700 --> 28:24.460] And also, traditionally, the server-to-server [28:24.460 --> 28:27.720] connections are purely opportunistic. [28:27.720 --> 28:30.380] So usually mail server doesn't validate a certificate [28:30.380 --> 28:33.160] because also usually the certificate host is [28:33.160 --> 28:36.440] not the host of the email address. So even validating [28:36.440 --> 28:39.520] the set doesn't make much sense. And you usually [28:39.520 --> 28:42.500] don't have an expectation against active attackers. [28:43.060 --> 28:44.720] Now, this is [28:45.480 --> 28:48.000] changing a bit. So there are two standards [28:48.560 --> 28:51.360] that one is based on DNSSEC and called DAIN [28:51.360 --> 28:55.080] and the other is called MTA-STS, which is kind of a [28:55.080 --> 28:57.520] trust on first use kind of mechanism [28:58.120 --> 29:00.960] that are trying to secure these server-to-server [29:00.960 --> 29:04.100] connections. It would be a different [29:04.100 --> 29:06.660] talk to talk about the advantages and disadvantages of [29:06.660 --> 29:10.340] those. My personal opinion is that MTA-STS [29:10.340 --> 29:12.620] is the more promising [29:12.620 --> 29:16.320] mechanism, but that's a [29:16.320 --> 29:20.540] controversial discussion. Let's just put it like this. [29:20.540 --> 29:21.660] But so [29:23.300 --> 29:25.420] yeah, it would be challenging [29:25.420 --> 29:28.100] to introduce an implicit TLS mode into [29:28.100 --> 29:31.160] MTA-to-MTA connections. Like right now, [29:31.160 --> 29:33.600] we are just using star TLS. Even if we use this [29:33.600 --> 29:36.740] advanced mechanism, we are still using star TLS. [29:37.160 --> 29:38.960] And the problem here is like that [29:39.980 --> 29:42.700] we have a lot of compatibility issues here. [29:42.700 --> 29:45.680] Like in email, it's a very old [29:45.680 --> 29:47.880] protocol and things are very established and [29:48.500 --> 29:51.620] probably a lot of mail servers have a firewall [29:51.620 --> 29:54.860] that they don't allow other ports than port 25. [29:54.880 --> 29:57.640] So it would be very challenging to [29:57.640 --> 30:01.240] 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:07.480] So if we want to secure [30:07.480 --> 30:10.300] these MTA-to-MTA connections, like if we talk about [30:10.300 --> 30:13.140] something like MTA-STS, then we should really [30:13.140 --> 30:16.080] need to make sure that we fix these buffering [30:16.080 --> 30:19.240] bugs, like these command injection and response injection [30:19.240 --> 30:21.020] that I've talked about earlier. [30:22.320 --> 30:25.360] If you think that you want to secure [30:25.360 --> 30:28.420] these server-to-server connections, then you also need to think about this. [30:30.120 --> 30:32.560] And you need to basically audit the implementation [30:32.560 --> 30:34.760] so they don't have these bugs. [30:36.560 --> 30:38.740] Then just quickly also [30:38.740 --> 30:41.600] start TLS is used in many other protocols like [30:41.600 --> 30:44.560] XMPP, FTP, then managed [30:44.560 --> 30:47.320] sieve, which is a mail filtering thing, then [30:47.320 --> 30:51.100] LDAP, MySQL, NNTP. [30:51.600 --> 30:53.640] And I guess [30:53.640 --> 30:55.780] this is obvious, but the [30:56.480 --> 31:00.200] kind of bugs that we found, they can be present [31:00.200 --> 31:03.360] in implementations of all protocols that support [31:03.360 --> 31:06.000] start TLS or something like start TLS. [31:06.640 --> 31:08.840] So there's lots of potential for [31:08.840 --> 31:11.720] future research here. Like this is something that [31:11.720 --> 31:14.960] should be tested in more settings. [31:18.560 --> 31:21.980] And also our general recommendation [31:21.980 --> 31:25.020] that if you have a choice between [31:25.020 --> 31:27.960] start TLS and implicit TLS, then you should prefer [31:27.960 --> 31:29.340] implicit TLS. And [31:31.340 --> 31:34.060] for future protocols, maybe you should [31:34.060 --> 31:37.140] just only support implicit TLS. [31:38.240 --> 31:39.220] And then [31:40.020 --> 31:42.840] something that is kind of not [31:42.840 --> 31:46.100] on the security side, but we can also ask what about [31:46.100 --> 31:48.560] performance? What about speed? [31:49.940 --> 31:50.580] Because [31:50.580 --> 31:54.300] I don't know. I come from Germany and [31:54.300 --> 31:57.660] Germany is known for having pretty bad mobile Internet. [31:57.780 --> 32:00.620] Not sure if you're aware of that, but if you ever go to Germany, [32:00.620 --> 32:02.820] that's what you will experience. So [32:03.320 --> 32:07.240] if you try to send an email with a bad Internet connection, [32:07.240 --> 32:09.780] it's pretty annoying. Like you have these things that [32:10.400 --> 32:13.140] you may get a connection error or the [32:13.140 --> 32:15.720] email may be sent, but it's not stored in your [32:15.720 --> 32:19.020] send folder because these are two different connections. [32:19.020 --> 32:22.100] So having a better performance here is good [32:22.100 --> 32:24.960] and also more reliability. If we need [32:24.960 --> 32:28.180] fewer connection roundtrips, then it's more [32:28.180 --> 32:29.220] reliable. [32:30.720 --> 32:34.100] This I also find interesting. There's been a lot of effort [32:34.100 --> 32:36.580] to reduce roundtrips in TLS. [32:36.820 --> 32:39.720] In TLS 1.3, by design, [32:39.720 --> 32:42.980] if you make a new connection, it has one roundtrip less [32:42.980 --> 32:46.140] than older TLS versions. And there's also [32:46.320 --> 32:49.140] a zero RTT mode, which is kind of... [32:50.360 --> 32:52.340] there are some security concerns [32:52.340 --> 32:55.300] about this, but the TLS community has decided that [32:55.300 --> 32:58.620] they still want to do this despite these security concerns. [32:58.920 --> 33:01.280] And I find this interesting that so much effort has been put [33:01.280 --> 33:04.200] into reducing TLS roundtrips, but it seems nobody has [33:04.200 --> 33:07.340] tried to optimize email protocols the same way. [33:08.820 --> 33:10.320] And if we look at [33:10.320 --> 33:13.040] startTLS, then all the information that is [33:13.040 --> 33:16.080] exchanged before we do startTLS is kind of [33:16.080 --> 33:19.220] meaningless, because we cannot [33:19.220 --> 33:22.080] trust it anyway, so we need to retransmit everything [33:22.080 --> 33:24.940] after the TLS handshake anyway. So for example, [33:24.940 --> 33:27.820] the server capabilities, you're [33:27.820 --> 33:30.720] always getting them again after the handshake. [33:30.740 --> 33:33.960] So you can think about this, that everything that is happening [33:33.960 --> 33:37.440] 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:42.800] So this kind of [33:42.800 --> 33:45.660] directly leads to that if you use startTLS, [33:45.660 --> 33:48.440] you need more roundtrips. It depends on the protocol [33:48.440 --> 33:51.480] and also a bit depends on the implementation, but [33:51.480 --> 33:54.240] it's usually two or three roundtrips more than if you [33:54.240 --> 33:56.580] directly use implicit TLS. [33:57.300 --> 34:00.300] So avoiding startTLS [34:00.300 --> 34:03.300] 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:12.260] This is kind of now going a bit into other topics, [34:12.260 --> 34:14.460] but there are other easy ways to improve [34:14.460 --> 34:16.880] email protocol roundtrips. [34:17.980 --> 34:20.600] So email authentication uses something [34:20.600 --> 34:21.720] called Zazzle. [34:23.460 --> 34:26.620] Zazzle is an authentication framework that is used [34:26.620 --> 34:29.180] in all three email protocols. [34:29.900 --> 34:32.540] And it's kind of an abstraction of different authentication [34:32.540 --> 34:35.480] methods. Although most of the time everyone uses [34:35.480 --> 34:38.900] username and password, but there are different authentication methods. [34:39.960 --> 34:42.020] And if you look at this, how this looks like [34:42.020 --> 34:44.640] in IMAP, we can have something like the above, [34:44.640 --> 34:47.580] where we have an authenticate plane and then [34:47.580 --> 34:50.900] we have some Base64. And this Base64, [34:50.900 --> 34:53.640] it is basically, it's a zero byte, then a username, [34:53.640 --> 34:55.600] then another zero byte and a password. [34:56.800 --> 34:59.680] And that is our login. So this is one [34:59.680 --> 35:03.060] roundtrip to login. And we can have this [35:03.060 --> 35:06.360] thing below where we have authenticate login, [35:06.360 --> 35:07.940] then we have a new line. [35:08.080 --> 35:11.960] So this is kind of optional. We can, in this authenticate [35:11.960 --> 35:14.780] line, we can already send data or we can [35:14.780 --> 35:15.800] 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:28.800] So there's quite some difference here and [35:29.880 --> 35:32.800] it's quite varying what will happen depending [35:32.800 --> 35:36.120] on what client and server configuration you use. [35:37.080 --> 35:38.740] So the first thing is that IMAP [35:38.740 --> 35:41.820] has a feature called SASL IR, which basically [35:41.820 --> 35:44.820] means you can initiate an authentication right away [35:44.820 --> 35:47.600] with data. So this is the thing that you have this [35:48.180 --> 35:50.540] authenticate plane and send something in the same line [35:52.280 --> 35:54.940] where... or you can also not do that. [35:54.940 --> 35:58.060] And of course, this is faster. This saves you a roundtrip if you can [35:58.060 --> 36:00.820] send data right away with the authentication [36:00.820 --> 36:01.880] command. [36:03.520 --> 36:06.920] And also, Zazzle has two different modes for [36:06.920 --> 36:09.860] username password authentication. They are called plain [36:09.860 --> 36:10.960] and login. [36:13.120 --> 36:15.880] To make matters even more complicated, both [36:15.880 --> 36:19.260] POP3 and IMAP, they have a built-in authentication [36:19.260 --> 36:22.200] that is not part of Zazzle, which is kind of [36:22.200 --> 36:25.660] part of their protocol itself. In IMAP, [36:25.660 --> 36:28.760] this has one roundtrip. In POP3, it has [36:28.760 --> 36:30.140] two roundtrips. [36:32.760 --> 36:34.880] So this login method, [36:34.880 --> 36:37.240] this is not standardized and [36:37.240 --> 36:40.780] it is also declared obsolete by the IANA. [36:40.780 --> 36:43.200] So the IANA has a registry of [36:43.760 --> 36:46.360] Zazzle authentication methods and there it's declared as [36:46.360 --> 36:49.320] obsolete. And what it basically does is [36:49.320 --> 36:52.320] it sends the username and the password base64 encoded [36:52.320 --> 36:55.980] in two roundtrips or just two lines in other words. [36:56.760 --> 36:58.600] And then there's this plain authentication [36:58.600 --> 37:01.580] method, which is a standard and it sends [37:01.580 --> 37:04.680] username and password encoded in one roundtrip. [37:04.780 --> 37:07.280] So you save another roundtrip here. [37:09.360 --> 37:09.960] So [37:10.680 --> 37:13.680] the plain method is standardized and it's [37:13.680 --> 37:16.600] faster than login. So it's clearly the better [37:16.600 --> 37:20.440] method. And from the security, it doesn't really matter. [37:20.980 --> 37:22.660] It's a normal username and password [37:22.660 --> 37:25.600] authentication. There's nothing fancy about it. [37:27.340 --> 37:28.840] So almost everyone [37:28.840 --> 37:31.960] supports both, like both servers and clients, but [37:31.960 --> 37:34.860] there's not really a reason to support login. [37:36.120 --> 37:37.680] So if you want to [37:37.680 --> 37:40.720] have faster email, then you should [37:40.720 --> 37:43.760] use implicit TLS and not start TLS. You should support [37:43.760 --> 37:47.620] the sessil-ir, which is specifically in IMAP. [37:47.760 --> 37:50.140] And you should disable the sessil-login [37:50.140 --> 37:53.120] method. Like for example, I figured out my own [37:53.120 --> 37:56.140] mail server, it supported both. And my client, [37:56.140 --> 37:58.760] if it supported both, it used login because [37:58.760 --> 38:01.060] that was the first in the client. [38:01.680 --> 38:04.900] It's in class mail. It's the first method that it [38:04.900 --> 38:07.940] supports. So it's slower for [38:07.940 --> 38:10.880] no gain. And I disabled it on the server and [38:10.880 --> 38:12.120] 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:23.180] Yeah, don't use TLS. Thanks for listening [38:23.180 --> 38:26.960] 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:37.900] Can you, Hanno, can you unshare your screen [38:37.900 --> 38:40.280] 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:58.010] Okay. So is the implication [38:58.010 --> 39:01.050] that the clients in the SMTP case for ease [39:01.050 --> 39:03.950] just ignore responses from the server? I expect [39:03.950 --> 39:06.990] them to be a state machine that says, wait, what? [39:06.990 --> 39:09.970] I haven't started sending them yet. What do you mean? [39:11.250 --> 39:13.270] No, that's not the implication. [39:13.270 --> 39:16.210] So the client is not ignoring these answers, but it is [39:16.750 --> 39:19.110] like it is processing these line [39:19.110 --> 39:22.190] by line. So it is sending [39:22.410 --> 39:25.090] a command to the server and then it's reading a line from the server [39:25.090 --> 39:28.210] and processing that. And that is why if you do this [39:28.210 --> 39:31.170] attack, you kind of have to inject all the [39:31.170 --> 39:34.330] commands that the client will send so it will get [39:34.330 --> 39:36.610] the answers that it expects. [39:37.750 --> 39:41.230] Is this understandable? 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.750] Actually, give me one second. I think we are going to try [39:52.750 --> 39:55.930] 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:02.320] Share this. 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:19.070] The second question I have, [41:19.070 --> 41:21.270] in the context of SMTP, [41:21.270 --> 41:24.550] do you see MTA STS having positive, [41:24.550 --> 41:27.850] negative, no change to the start TLS risks? [41:31.010 --> 41:32.530] It doesn't... [41:34.510 --> 41:36.090] I think the question [41:36.090 --> 41:37.650] is framing it wrong. [41:37.650 --> 41:39.230] The thing is, [41:40.550 --> 41:43.550] MTA STS is introducing an expectation [41:43.550 --> 41:45.890] 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 --> 41:55.510] So before, we could say these attacks [41:55.510 --> 41:57.370] don't matter for MTA to MTA [41:57.370 --> 42:00.930] 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:14.030] It's just that what we try to achieve with MTA STS [42:14.030 --> 42:16.670] 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:27.830] Again, we can be in the Slack Discord [42:28.350 --> 42:31.330] and maybe later, if people have more questions, [42:31.330 --> 42:32.850] 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:45.130] So I think if you compare start TLS and implicit TLS, [42:45.130 --> 42:48.970] there are no added issues by implicit TLS. [42:49.010 --> 42:51.550] Because it's just the simpler thing. [42:51.870 --> 42:53.510] Like with start TLS, [42:53.510 --> 42:56.810] we start in plain text and then we do a state transition [42:56.810 --> 43:00.610] 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:06.810] So I don't see any risk in implicit TLS [43:06.810 --> 43:09.790] that you wouldn't have with start TLS. [43:10.050 --> 43:12.750] Of course, it has all the risks that you can have [43:12.750 --> 43:14.550] otherwise with TLS. [43:16.030 --> 43:18.310] If there's a bad implementation, [43:18.310 --> 43:22.810] if there's bad randomness or vulnerable algorithms, [43:22.810 --> 43:24.110] 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:39.450] I have seen that it exists, [43:39.450 --> 43:43.550] 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:55.130] And then our final question, [43:55.130 --> 43:56.890] just thanking you for the talk. [43:56.890 --> 43:59.850] Is anyone working on email POP3 replacements [43:59.850 --> 44:01.610] 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:13.190] This is not the issue of the talk, [44:13.190 --> 44:15.390] but I feel POP3 is a really simple protocol [44:15.390 --> 44:17.330] and I kind of like that. [44:18.150 --> 44:20.170] I'm also one of these weird people [44:20.170 --> 44:22.510] 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:36.690] Well, again, [44:36.690 --> 44:39.270] we would like to thank you for your talk. [44:40.050 --> 44:42.830] If anybody has any more questions, [44:42.830 --> 44:44.410] 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:51.010] I want to thank everyone who's watching the live stream [44:51.010 --> 44:55.170] for sitting with us through the first ever [44:55.170 --> 44:59.090] DEF CON Safe Mode and the Glitch Crypto and Privacy Village. [44:59.090 --> 45:01.110] I want to remind everyone again that we have [45:01.110 --> 45:03.910] the Gold Bug Challenge that's still there. [45:04.170 --> 45:06.550] And I would like to, again, thank you for your talk [45:06.550 --> 45:09.930] 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?