start	end	text
1020	4340	Welcome, everyone, to the Crypto and Privacy Village.
4840	8400	This is our seventh year and DEF CON 28 here in safe mode.
8400	10620	I am Haim Cohen. I'm one of the hosts here.
11200	13120	Let's just get some stuff out of the way.
13120	14700	You can join us at Discord.
15800	18800	You can find us there. We have a couple channels.
19080	22020	The gold bug just opened up,
22020	24320	so if you're interested in the gold bug puzzle,
24320	25840	we did that very well.
28940	32300	And let's just introduce our first speaker,
32300	34940	Hanno Berg, and he's going to go.
36000	37340	Yeah, hi.
37920	40000	Let's switch these slides.
42480	45180	Okay, you can go full screen and you can go.
49440	51460	Okay, do you see the slides?
51580	53020	I see them.
53200	54840	Yeah, okay, great.
54840	57220	Yeah, hello.
57220	60720	So I'm Hanno and I'm going to talk about
60720	62640	StartTLS today.
64590	67040	This is some research that I've been doing
67040	70480	together with Damian Hodebniak, Fabian Ising
70480	72340	and Sebastian Schinzel.
72340	76980	And we are soon going to publish a paper on this.
77420	79420	Yeah, we kind of figured out that
79420	83460	StartTLS seems to not be very well
83460	86940	researched and it has some issues that are not very well known
86940	89720	and we looked a bit deeper into this.
92100	93120	So,
93120	95880	from the general idea, I guess most people are
95880	98140	roughly aware what StartTLS is, but
98140	101440	if we talk about TLS connections, there's
101440	104200	two ways to do a TLS connection.
105260	107520	One way is that we have an extra
107520	110420	port for the encrypted version of protocol
110420	113840	where we directly start a TLS connection
113840	116440	on that port. And this is called
116440	119420	implicit TLS because we
119420	122200	kind of implicitly are using TLS
122200	125780	based on the port number. We already know that this is an encrypted
125780	128700	connection. And then there's this other way
128700	131560	which is StartTLS where we start with some
131560	134660	protocol that is not encrypted and then we
134660	137800	have some special command which is usually StartTLS
137800	141040	command that upgrades
141040	143780	this connection to be encrypted.
145080	146920	And in the web
146920	149660	we are only using implicit TLS
149660	153040	basically. So what we usually do is that we have
153040	156080	HTTPS which is kind of its own protocol
156080	158440	on its own port which is
158440	162920	HTTP protocol with a TLS wrapped around it.
164400	164800	But
164800	167820	StartTLS, the most common usage is
167820	170140	in the context of emails.
172320	172900	And
173560	176900	in this talk I am mostly going to talk
176900	180560	about the connection between an email client and the server.
180560	182880	I will talk a bit about server to
182880	185060	server connections later but also
185800	189280	we haven't focused so much on this because this is kind of
190600	192160	a different issue because
192160	195340	the considerations for server to server are
195340	198040	quite different than from client to server.
199880	201260	So all email
201260	204340	protocols we use, I guess you are aware
204340	207420	of that, we have SMTP, POP3 and IMAP.
207420	210240	We use SMTP to send emails, POP3 to
210240	212940	fetch emails or IMAP also kind of to fetch
212940	216260	emails but also to manage a mailbox on the
216260	219740	server. All of these protocols support StartTLS.
219740	223020	And for the client to server communication
223420	226120	these protocols also all support
226120	229420	implicit TLS. So we kind of, as a user
229420	232380	we can choose which one we use. So if
232380	235160	we can choose between the two then the obvious question is
235160	238680	which one is better and which one is more secure.
240940	241580	So
241580	243740	how does this StartTLS
244280	247280	work? So these email
247280	250380	protocols, they are all kind of relatively simple
250380	252700	text protocols. So it's a line-based
253840	256560	protocol where a client sends a
256560	259320	command to a server and gets some kind of answer. So
259860	263600	this is an SMTP session here.
263600	265580	The S and C at the beginning
265580	268540	that is server and client. So
268540	271480	if you connect to an SMTP server, the first thing
271480	274400	is the server sends this line which
274400	277360	is basically a hello message which contains its
277360	279920	host name and a special
281260	283640	code number. And
283640	286580	then you send this elo command that is basically
286580	289560	from the client, always the first command which is kind of
289560	292520	introducing the client. And then the server usually
292520	295670	gets back with a list of features that the server supports.
296280	298400	And here you can see in this list
299440	301420	that it ends with this
301420	304440	250 star TLS which means
304440	307560	okay, the server just told us that it supports
307560	310620	star TLS. And then the client can
310620	313820	use this star TLS. This is simply a
313820	316700	text command. It gives them this command
316700	320440	star TLS. Then the server answers with
320440	322860	a 220 code which means everything is
322860	325960	all right. And the okay behind that
325960	328600	is basically meaningless. That's more or less like a comment.
329760	332720	And then we do a handshake. And for the
332720	335560	colors here, the gray thing is
335560	338700	the plain text part of the protocol. And
338700	341120	then we have a TLS handshake. And the green
341120	344620	thing here, that is then encrypted and authenticated
344620	347500	with all the properties that we usually
347500	350560	expect from a TLS connection. So we expect that there's
351160	353460	some sense of security here
353460	356440	while the thing at the beginning, it's plain text. So
356440	359700	an attacker can read it, an attacker can manipulate it.
360200	362540	And then basically we start over because
362540	365740	kind of all the information we got before the TLS
365740	368760	handshake, we don't really trust it. So we send this
368760	372160	elo command again. And then maybe we can do a
372160	374960	login and send an email. And you
374960	378080	don't need to understand the details of how the protocol
378080	381100	works. But the basic idea just that should stick here is
381220	383840	we have a plain text protocol. We have a command that
383840	386780	starts a TLS connection. Then we do a handshake and
386780	389480	then we kind of move this protocol into TLS.
391560	393000	Now, first, something
393000	395960	which is obvious, that if you use
395960	398880	start TLS in an opportunistic way,
398880	400400	this is insecure. So
401880	404180	there is some email clients
404860	408020	implement start TLS in a way where they will say,
408020	411240	okay, if the server offers start TLS,
411240	415040	then I will use it. And if the server does not offer it,
415040	417820	then I will just stay in plain text mode.
418440	420560	So we will use start TLS
420560	424040	if we can, but if not, then we will just do plain text.
424360	427520	And a
427520	431720	network attacker can attack this.
431720	432660	We figured out that
432660	435660	this is actually not that common anymore. This used to
435660	438060	be the case maybe 10 years ago, but
438060	441660	today most clients don't really do this anymore.
441920	444200	And it's obvious that an attacker can
444200	446820	in such a scenario, an attacker can just
447400	450420	they can pretend to be the server and then they can say,
450420	453020	yeah, I don't support start TLS and then
453020	456500	the client logs in and then the attacker knows the username
456500	459020	and password. So that is obviously
459020	462120	insecure, but that's not really
462120	464320	what our research was about because
464320	467420	that's, yeah.
469840	470620	Yeah.
470620	473360	But this turns out to be not the only
473360	476520	security problem with start TLS. So you could think, okay,
476520	479460	this is a problem, but if we implement a client in a way
479460	482580	that it always forces this start TLS connection
482580	485940	and will just refuse to connect if it cannot do that,
485940	488540	then this is secure. But it turns out that this is
488540	489660	not the case.
491800	494020	So if you look at what start TLS
494020	497500	is, then it's kind of a form of state transition
497500	501040	where you have the protocol, which can be in two states.
501040	503740	It can be in a plain text state and
503740	506860	in an encrypted state after the TLS handshake.
509860	510820	And this
510820	513980	raises quite a few questions.
514800	516820	So at first you can ask, okay,
516820	520140	we have the state transition,
520140	522820	but which protocol features can we use before
522820	525900	we turn the encryption on? What can
525900	529200	happen in the plain text part? And also
529200	531740	how should we treat the data that
531740	535100	we got before the handshake, for example, server features
535100	538160	or if there's any login, because we cannot
538160	540820	really trust that data as it's
542920	544800	obviously not secured.
544800	548500	And also you could ask, do the implementations,
548500	551160	do they have a clear understanding what is encrypted
551160	554020	and not encrypted? And do they clearly
554020	555540	separate that?
557820	560100	So just one example, which is
560440	563120	a relatively obvious problem, the IMAP protocol
563120	565960	has a feature which is called alerts,
565960	569140	which is basically the server sends a message to the client
569140	572140	and the client is supposed to show this to the user.
572140	575220	And these alerts, it turns out, they can be sent at any
575220	578580	time. So they can be sent in the plain text
578580	581180	part, which is
581180	584100	interesting because this is a screenshot from
584100	587560	Outlook where the
587560	590500	IMAP server sends a message to the user and this
590500	593080	message is not secure. It is
593760	596040	sent in plain text, even though the
596040	599640	mail client is configured to use a secure connection.
599640	602620	And here you can even see, you can even include a link
602620	605700	which will be highlighted. So we have here,
605700	608580	your IMAP server wants to alert you
608580	611260	to the following, please download my post something something
611260	614540	and then the attacker can put in a link where he provides
614720	617980	a malicious file. So we have an alert sent in plain text
617980	620600	but to the user it looks like this is a legitimate
620600	623460	message from his mail server. So he may
623960	625660	want to trust it.
625660	628840	So yeah, this is just a design
628840	632360	problem of the protocol, how it is specified.
634740	637760	But then we came upon the issue
637760	641000	of buffering bugs. And this is something that
641000	642900	has been known for a while.
643920	646340	And the question here is really, is
646340	649540	something part of the TLS session or not? And do
649540	652360	clients and servers have a good idea about this?
653620	655320	So there was a vulnerability
655320	658980	in 2011 already, so this is nine years
658980	661840	ago, which was named
661840	664960	plain text command ejection in multiple implementations of
664960	667600	star TLS. This was discovered by the author of
667600	670460	Postfix. And
671460	673660	what happened here is, like if we look
673660	676640	again at this star TLS connection and
676640	679720	this is like only the, I've shortened this a bit, I've
679720	682820	cut away the stuff that currently doesn't matter,
682820	685700	like we have this client sends the star
685700	688680	TLS command, gets an answer from the server and then there's
688820	691820	a handshake happening. Now, what
691820	694920	can happen if we do something like this, where a client
694920	698080	sends the star TLS command and
698080	700380	then sends something else in plain text
701300	703860	and then gets the answer
703860	706800	from the server that he can now start the TLS handshake
706800	710040	and then they do the TLS handshake. So it turns out
710040	713140	that there are quite a few implementations of servers
713140	715800	that will then process
716340	719260	both of these commands, the star TLS and the
719260	722180	whatever other command you sent together
722180	725280	with the star TLS in a single TCP packet.
726480	727480	That it will
727480	731140	put this in some kind of buffer and process every command
731140	733700	after another and then it will answer to this
734300	737580	command that was appended to the star TLS
737580	741080	in the TLS session. So we kind of have something
741080	744200	here that traverses from the plain text part of the
744200	747120	protocol to the TLS part of the protocol.
747180	749660	Like we send something in plain text but the server
749660	752960	kind of thinks that this is part
752960	754560	of the TLS connection.
756900	757900	Yeah, so
759420	761620	that's basically what I just said.
763160	766260	So this bug was originally found in Postfix
766260	769240	but it turned out it affected multiple mail servers
769240	772220	including Cyrus, Courier, Qmail
772220	775100	and various proprietary mail stacks.
775100	778320	So there's an advisory by
778320	781360	US CERT from that time which contains a long list of
781360	784120	affected servers. So this turned out to be a very
784120	785900	widespread problem.
786880	790020	Now you may wonder how you can attack this and this is
790020	792780	kind of, I think this is maybe part of the reason why this
792780	795960	bug is not very well known because the Postfix
795960	798880	authors, they have described very well what
798880	801580	the problem is but they haven't really
801580	805080	published any exploit or explained how you could actually
805080	807280	attack this. So it was kind of seen by
808020	810200	and there was some
810820	813920	email discussions from mail server developers where people were
813920	816780	like, yeah, this is kind of a weird behavior but it's not really
816900	819860	a security problem. But you can actually
819860	821820	attack this pretty easily and
823500	824920	this takes a bit of
825660	827340	thinking what's going on here but
828060	831720	so this is the first part
831720	834740	of the attack which is we start a connection
834740	837520	that is in plain text. So we have again
837520	840160	this start message
840780	843520	that's not really the interesting part. The interesting part begins
843520	846460	where we have the start TLS and then this red
846460	849660	stuff, this is injected by an attacker.
849660	852040	So the attacker is injecting here another
852040	855480	elo command which is, that is just always the first command
855480	859260	that comes after start TLS. That's why we have to send that.
859320	861460	And then the attacker locks in with its own
861460	864620	credentials. So our assumption here is the attacker also
864620	867760	has an account on this mail server but it could be something
867760	870620	like a public email provider
870620	873500	address. So that is a plausible assumption. And then
873500	876480	the attacker is starting to send an email like
877620	879780	he's setting a from address and a to
879780	882680	address and the to address particularly is his own address
882680	885560	and then it sends this data command which is basically
885560	887740	now the email content starts.
889360	891860	And then we get an answer
891860	894740	from the server. This is now the answer to the start TLS
894740	897820	command. So now we're doing a TLS handshake
897820	901580	the client and the server but we have these injected commands.
903200	903560	And then
904960	906740	the server will answer to these
906740	909840	injected commands. So it will send this normal greeting that always
909840	912700	comes after the elo command and then it will
912700	915640	authenticate the user and then it will say
915640	918980	okay now the email starts. And now what happens
918980	921940	is that the client doesn't know
921940	924860	about any of this. It doesn't read from the server because
924860	927720	it doesn't expect it to send anything. It sends its own
927720	930200	elo command, it authenticates
930800	933980	and then it starts sending a mail. Now what happens
933980	936740	is that all this stuff, all this blue stuff
936740	939920	which the client sends, this ends up being part
939920	942800	of this email that we started sending
942800	945980	to ourselves as an attacker. So the attacker
945980	949160	now gets an email and that contains the
949160	953000	authentication data from the victim,
953860	956440	so this is a pretty severe attack.
956440	959160	Like if you're a network attacker and we have a server vulnerable
959160	962020	to this, we can force the client to send
962020	964480	his credentials to us.
967260	970180	There's a similar attack with IMAP that is
970520	973300	a bit more tricky because like you can, in IMAP
973300	976400	you can kind of store a mail into a mailbox and then
976400	979240	it's the same idea. One problem with that
979240	982180	was that in order to do that you need to know the exact
982180	984980	size of the message that's going to come.
985120	988220	That means you kind of need to guess how long
988220	991160	the password of the user is, but you may be
991160	993820	able to see that with a side channel attack and also
993820	997140	it turns out that many mail servers on failed login
997140	1000080	attempts, they will just try to reconnect. So you have kind of
1000080	1003300	as an attacker, you have multiple tries to do this
1003300	1006060	so it's still a feasible attack. But it is
1006480	1009040	a bit more difficult than the SMTP attack.
1011180	1013740	Okay, so this bug was discovered
1013740	1016760	in 2011. So you would hope
1016760	1019980	that people have fixed this, but as probably
1019980	1022540	no one is surprised, it's actually not
1022540	1026140	fixed everywhere. So we did some scans
1026140	1028860	and we found out that, yeah, in SMTP servers
1028860	1031220	1.5% are vulnerable.
1032920	1034660	In IMAP and POP3
1034660	1037040	it's more, it's around 2.5%.
1038360	1041100	I guess the reason why this is different is
1041100	1043980	because this was originally described in an SMTP
1043980	1047360	server, so that's probably where people had it on the radar.
1047620	1050140	But the very same class of
1050140	1053240	bug can happen in basically every protocol that supports
1053240	1056180	StarTLS. Although I have
1056180	1058200	to say for POP3, we
1058840	1062220	didn't really find an exploit to attack
1062220	1065760	this, but it's still kind of something that should be fixed.
1068580	1071020	Now there's another question you can ask
1071020	1073680	and that is, can we have the same
1073680	1077060	kind of bug, but the other way around?
1077060	1079640	That is, on the client side.
1079880	1082980	So can we confuse the client to get data
1082980	1086740	that was sent in plain text and the client thinks it's TLS data?
1087280	1089340	And in turns out, yes, we can do that.
1089340	1092000	So the idea is pretty much the same. The client
1092000	1094780	sends a StarTLS command, then the server sends this
1094780	1097780	220 code, which is kind of the
1097780	1101040	just approving that, yeah, I got the StarTLS, now we can do
1101040	1103040	TLS. And then
1103780	1106880	we can append additional data that's coming from the server
1106880	1110040	and then the client will interpret that as part of the TLS
1110040	1112900	session. So yes, this attack
1112900	1115780	also, this vulnerability also exists
1115780	1117220	on the client side.
1120860	1121900	So clients
1121900	1124820	can be vulnerable to the same class of bug and we have
1124820	1127840	called this a response injection because the other thing was
1127840	1131100	called a command injection and here we call it a response injection.
1134380	1137040	This is not that severe, but for example
1137040	1139920	it can be used by an attacker to spoof
1139920	1142800	mailbox content. You kind of have to guess
1142800	1145700	what commands the client will send, but if you know
1145700	1148740	which mail client it is, you can usually know that.
1148740	1151800	So for example, you can show the user an
1151800	1154820	IMAP inbox that is not his own and that contains
1154820	1155900	other data.
1157920	1160820	So it's still an issue.
1161040	1163320	And the really
1163960	1166760	surprising thing was that more than half of the mail clients
1166760	1169900	that we tested were vulnerable to this bug. So this is a very
1169900	1171480	very widespread issue.
1174720	1175960	So to sum
1175960	1179040	that up a bit, this DartTLS command injection, it was
1179040	1181780	discovered in 2011 and it affected multiple
1182720	1185220	implementations and even though many
1185220	1187700	implementations were found back then, they are still
1187700	1191320	widely used vulnerable implementations.
1193540	1194380	Also,
1194380	1197140	the same bug class exists on the client and the
1197140	1199340	majority of implementations are vulnerable
1199960	1203400	or were until we have reported it to them.
1205760	1207840	And just very generally,
1207840	1210660	if you're doing an implementation of DartTLS
1210660	1213460	and you're not aware of this bug and you're doing a naive
1213460	1216600	implementation, then you will have some kind of command
1216600	1219580	buffer where you read the commands line by line
1219580	1223160	and then you will usually have this bug too.
1223240	1225820	So it's kind of one of these things where
1225820	1228960	you have to actively be aware of this bug in order to
1228960	1230140	prevent it.
1232220	1234340	And this, in my
1234340	1237520	opinion, is a clear sign that
1237520	1240340	this is not something where we should say
1240340	1243760	this is a flaw in the mail client, but this is a systemic
1243760	1246720	problem in the standard. Like if you have a situation
1246720	1249800	where the same bug appears again and again and
1249800	1253280	again and in multiple different implementations,
1253280	1255180	then you should wonder
1255180	1258660	if this is something where we can
1259480	1262820	just... if we can do better on the level of the standard
1262820	1265680	and not say it's the flaw of the
1265680	1267280	implementations.
1269440	1270760	Yeah.
1271560	1274300	There's more issues with DartTLS.
1276040	1277900	One, the IMAP
1277900	1280900	protocol has a feature which is called
1280900	1284280	pre-auth. The idea here is
1284280	1288640	that an IMAP server can,
1288640	1292860	send a line which basically tells
1292860	1296040	the client you're already logged in, you don't have to
1296040	1297260	authenticate.
1298540	1301320	So the idea here is, for example, if you have a controlled
1301320	1304820	network where you do authentication based on IP
1304820	1307780	addresses, maybe then you can say, okay, if a connection
1307780	1310880	comes from this IP address, then we just assume
1310880	1313880	that this is already authenticated and the user is
1313880	1315200	already logged in.
1315200	1319160	So now, DartTLS,
1319160	1321900	the standard clearly says that it must not be performed
1321900	1323960	in an authenticated state.
1324920	1328480	So if we take these two things together,
1328480	1331220	like we have a feature, DartTLS,
1331220	1333980	that you must not use when in an authenticated
1333980	1336980	state, but the server answers with this pre-auth line
1336980	1340120	which says you are already authenticated.
1340280	1343060	Now, what should a client do? Like we have a client
1343060	1345860	that connects to a server, it gets this response, it's
1345860	1349180	configured to use DartTLS, then we kind of have
1349320	1351160	a contradiction here. Like this is
1351980	1354640	kind of a logical inconsistency in the standard.
1355280	1358640	The standard doesn't really say anything about this.
1358640	1361080	This is just where the standard
1361080	1363400	has an internal conflict.
1365400	1365500	And
1367520	1369980	after all, the only reasonable way
1369980	1373000	for a client to react to this is to just
1373000	1376160	terminate the connection, because it cannot do DartTLS
1376160	1377800	in this situation.
1379360	1382100	So there's no way to secure this connection
1382100	1385000	and if it's configured to have a secure connection,
1385000	1387900	it should just not accept this.
1389820	1390840	Now,
1390840	1393980	not surprisingly, some clients will allow pre-auth
1393980	1397020	connection and then just don't do DartTLS because
1397020	1398500	they can't.
1399160	1402920	And this is also a security flaw.
1402920	1405780	You also obviously can do mailbox content spoofing,
1405780	1409100	like you're a network attacker person in the middle
1409100	1411900	and then client connects, you send this pre-auth
1411900	1414740	response and then you're kind of the upstream server
1414740	1417860	for that client. So you cannot steal credentials because
1417860	1420780	the client is already authenticated, but
1420780	1424140	you can forge the content
1424140	1427280	of the inbox. And also, you can sometimes steal
1427280	1430460	mail, for example, if you're using IMAP
1430460	1432940	then usually a sent mail is stored in the
1432940	1436200	send folder, so that you can steal. And some clients
1436200	1439040	also, when they connect to an IMAP server, they start
1439040	1441640	synchronizing folders, so
1441640	1444880	there you may be able to steal mailbox content.
1447680	1448240	Then
1448240	1450920	there's an IMAP feature which is called mailbox
1450920	1453960	referrals. And the idea here is that
1453960	1456960	the server can tell a client that it should use another
1456960	1459740	server. So it's something like a forward
1459740	1463100	feature, where a server can say, yeah,
1463100	1465960	like I'm forwarding you to this other server if you want
1465960	1467540	to access this mailbox.
1469580	1471920	And now the interesting thing is
1471920	1474900	if you combine these two things, you have this pre-auth, which
1474900	1477860	means you can prevent the client from starting a TLS
1477860	1480800	connection. And then you can do this referral, which
1480800	1483840	refers the client to another server. And this
1483840	1486080	can be our attacker server. So
1486080	1489820	we prevent the TLS connection from happening as an
1489820	1492820	attacker. Then we forward the user to a server
1492820	1495960	and we control that server. So this can have
1495960	1498840	TLS and the client logs in. And then
1498840	1501880	we have the client's credentials. So this is also
1502020	1503480	a pretty severe attack.
1505100	1506800	We have to say here that
1506800	1509960	this mailbox referrals feature, and there's a similar
1509960	1512880	feature called login referrals, these are not widely
1512880	1515760	supported. So we only found one
1515760	1518780	mail client where we could perform this attack. This was
1518940	1521740	a mail client called Alpine. So most
1521740	1524560	mail clients, they just don't support these features, so they are not
1524560	1528080	affected by this. But still
1528080	1530940	it shows kind of that there are features in IMAP
1530940	1533800	where it's not really thought through what that
1533800	1536840	means in combination with StartTLS.
1538540	1539880	So yeah,
1539880	1543040	to summarize that, so StartTLS
1543040	1545960	has a systemic problem with buffering bugs. They can
1545960	1549080	appear both on the server and the client sites. There
1549080	1551760	are several features in IMAP that are problematic
1551760	1555960	or insecure if you combine them with StartTLS.
1556020	1557800	And also StartTLS does not
1557800	1560720	really provide any security advantage over
1560720	1563560	normal implicit TLS connection.
1564640	1566960	So our conclusion is you should
1566960	1569940	not use StartTLS for mail connections, for
1569940	1572420	email client connections, I guess. So
1574160	1575640	if you are
1575640	1578780	using email, which I guess most of you do, and if you're using
1578940	1581820	a mail client, then you should change
1581820	1584880	its configuration to use the implicit TLS
1584880	1587460	pods and not to use StartTLS.
1588000	1590820	And then you will not be affected by most of these
1590820	1594060	attacks. Some can still happen, but because some
1594060	1597020	it's enough when the server is supporting StartTLS,
1597020	1599580	but most of these attacks will be prevented.
1601180	1602880	If you run a mail server,
1602880	1605720	you should definitely make sure that you support
1605720	1608780	implicit TLS. I mean, there's
1608780	1611580	an RFC that says that you should use the implicit
1611580	1615620	TLS pods, but there are, for example,
1615620	1617960	the Microsoft SMTP
1617960	1620780	servers, they don't support implicit TLS
1620780	1623800	for SMTP. And if
1623800	1626620	you can, then disable StartTLS. Now
1626620	1629980	we are aware that this is not an easy thing,
1629980	1632880	particularly if you have existing customers. Like if you have
1632880	1635640	an existing user base, then telling them,
1635640	1638820	yeah, sorry, half of your mail configurations will
1638820	1641680	break next week, that's a tough thing to do.
1641740	1644900	So I'll say it would be ideal to just disable it
1644900	1647360	on the server, but this
1648040	1650800	is probably not feasible for people
1650800	1653260	who have existing user bases. But if you
1653900	1656820	start like a new mail server setting, then
1656820	1660080	you can start right away without StartTLS.
1663020	1663620	So
1663620	1666360	then I want to talk a bit about the special case,
1666360	1669020	the server-to-server or MTA-to-MTA
1669020	1672280	connection. In case you don't know, MTA stands
1672280	1675960	for Mail Transfer Agent, which is another word for mail server.
1677800	1678320	So
1678320	1680780	this situation there is a bit different.
1681380	1684360	For one, there's currently no way to use implicit
1684360	1687220	TLS on MTA-to-MTA connections.
1687220	1690160	That's just not part of the standards. There's no
1690160	1692140	RFC how to do this.
1692140	1692880	And
1695080	1697800	it would not be easy to
1697800	1699940	implement that.
1700700	1704460	And also, traditionally, the server-to-server
1704460	1707720	connections are purely opportunistic.
1707720	1710380	So usually mail server doesn't validate a certificate
1710380	1713160	because also usually the certificate host is
1713160	1716440	not the host of the email address. So even validating
1716440	1719520	the set doesn't make much sense. And you usually
1719520	1722500	don't have an expectation against active attackers.
1723060	1724720	Now, this is
1725480	1728000	changing a bit. So there are two standards
1728560	1731360	that one is based on DNSSEC and called DAIN
1731360	1735080	and the other is called MTA-STS, which is kind of a
1735080	1737520	trust on first use kind of mechanism
1738120	1740960	that are trying to secure these server-to-server
1740960	1744100	connections. It would be a different
1744100	1746660	talk to talk about the advantages and disadvantages of
1746660	1750340	those. My personal opinion is that MTA-STS
1750340	1752620	is the more promising
1752620	1756320	mechanism, but that's a
1756320	1760540	controversial discussion. Let's just put it like this.
1760540	1761660	But so
1763300	1765420	yeah, it would be challenging
1765420	1768100	to introduce an implicit TLS mode into
1768100	1771160	MTA-to-MTA connections. Like right now,
1771160	1773600	we are just using star TLS. Even if we use this
1773600	1776740	advanced mechanism, we are still using star TLS.
1777160	1778960	And the problem here is like that
1779980	1782700	we have a lot of compatibility issues here.
1782700	1785680	Like in email, it's a very old
1785680	1787880	protocol and things are very established and
1788500	1791620	probably a lot of mail servers have a firewall
1791620	1794860	that they don't allow other ports than port 25.
1794880	1797640	So it would be very challenging to
1797640	1801240	change the protocol to support an implicit TLS mode.
1801240	1804400	So I don't see that happening anytime soon.
1805780	1807480	So if we want to secure
1807480	1810300	these MTA-to-MTA connections, like if we talk about
1810300	1813140	something like MTA-STS, then we should really
1813140	1816080	need to make sure that we fix these buffering
1816080	1819240	bugs, like these command injection and response injection
1819240	1821020	that I've talked about earlier.
1822320	1825360	If you think that you want to secure
1825360	1828420	these server-to-server connections, then you also need to think about this.
1830120	1832560	And you need to basically audit the implementation
1832560	1834760	so they don't have these bugs.
1836560	1838740	Then just quickly also
1838740	1841600	start TLS is used in many other protocols like
1841600	1844560	XMPP, FTP, then managed
1844560	1847320	sieve, which is a mail filtering thing, then
1847320	1851100	LDAP, MySQL, NNTP.
1851600	1853640	And I guess
1853640	1855780	this is obvious, but the
1856480	1860200	kind of bugs that we found, they can be present
1860200	1863360	in implementations of all protocols that support
1863360	1866000	start TLS or something like start TLS.
1866640	1868840	So there's lots of potential for
1868840	1871720	future research here. Like this is something that
1871720	1874960	should be tested in more settings.
1878560	1881980	And also our general recommendation
1881980	1885020	that if you have a choice between
1885020	1887960	start TLS and implicit TLS, then you should prefer
1887960	1889340	implicit TLS. And
1891340	1894060	for future protocols, maybe you should
1894060	1897140	just only support implicit TLS.
1898240	1899220	And then
1900020	1902840	something that is kind of not
1902840	1906100	on the security side, but we can also ask what about
1906100	1908560	performance? What about speed?
1909940	1910580	Because
1910580	1914300	I don't know. I come from Germany and
1914300	1917660	Germany is known for having pretty bad mobile Internet.
1917780	1920620	Not sure if you're aware of that, but if you ever go to Germany,
1920620	1922820	that's what you will experience. So
1923320	1927240	if you try to send an email with a bad Internet connection,
1927240	1929780	it's pretty annoying. Like you have these things that
1930400	1933140	you may get a connection error or the
1933140	1935720	email may be sent, but it's not stored in your
1935720	1939020	send folder because these are two different connections.
1939020	1942100	So having a better performance here is good
1942100	1944960	and also more reliability. If we need
1944960	1948180	fewer connection roundtrips, then it's more
1948180	1949220	reliable.
1950720	1954100	This I also find interesting. There's been a lot of effort
1954100	1956580	to reduce roundtrips in TLS.
1956820	1959720	In TLS 1.3, by design,
1959720	1962980	if you make a new connection, it has one roundtrip less
1962980	1966140	than older TLS versions. And there's also
1966320	1969140	a zero RTT mode, which is kind of...
1970360	1972340	there are some security concerns
1972340	1975300	about this, but the TLS community has decided that
1975300	1978620	they still want to do this despite these security concerns.
1978920	1981280	And I find this interesting that so much effort has been put
1981280	1984200	into reducing TLS roundtrips, but it seems nobody has
1984200	1987340	tried to optimize email protocols the same way.
1988820	1990320	And if we look at
1990320	1993040	startTLS, then all the information that is
1993040	1996080	exchanged before we do startTLS is kind of
1996080	1999220	meaningless, because we cannot
1999220	2002080	trust it anyway, so we need to retransmit everything
2002080	2004940	after the TLS handshake anyway. So for example,
2004940	2007820	the server capabilities, you're
2007820	2010720	always getting them again after the handshake.
2010740	2013960	So you can think about this, that everything that is happening
2013960	2017440	before we do this handshake, it is just wasted.
2017440	2019360	It doesn't have any meaning.
2019360	2022800	So this kind of
2022800	2025660	directly leads to that if you use startTLS,
2025660	2028440	you need more roundtrips. It depends on the protocol
2028440	2031480	and also a bit depends on the implementation, but
2031480	2034240	it's usually two or three roundtrips more than if you
2034240	2036580	directly use implicit TLS.
2037300	2040300	So avoiding startTLS
2040300	2043300	is not just more secure, it's also just faster.
2043300	2045220	Which is, I guess, good.
2045220	2048780	And there are some other ways.
2048780	2052260	This is kind of now going a bit into other topics,
2052260	2054460	but there are other easy ways to improve
2054460	2056880	email protocol roundtrips.
2057980	2060600	So email authentication uses something
2060600	2061720	called Zazzle.
2063460	2066620	Zazzle is an authentication framework that is used
2066620	2069180	in all three email protocols.
2069900	2072540	And it's kind of an abstraction of different authentication
2072540	2075480	methods. Although most of the time everyone uses
2075480	2078900	username and password, but there are different authentication methods.
2079960	2082020	And if you look at this, how this looks like
2082020	2084640	in IMAP, we can have something like the above,
2084640	2087580	where we have an authenticate plane and then
2087580	2090900	we have some Base64. And this Base64,
2090900	2093640	it is basically, it's a zero byte, then a username,
2093640	2095600	then another zero byte and a password.
2096800	2099680	And that is our login. So this is one
2099680	2103060	roundtrip to login. And we can have this
2103060	2106360	thing below where we have authenticate login,
2106360	2107940	then we have a new line.
2108080	2111960	So this is kind of optional. We can, in this authenticate
2111960	2114780	line, we can already send data or we can
2114780	2115800	just not.
2117740	2120660	And then the server asks for a username.
2120660	2124020	This is also Base64 encoded and asks for a password.
2124480	2126500	So this is three roundtrips.
2126500	2128800	So there's quite some difference here and
2129880	2132800	it's quite varying what will happen depending
2132800	2136120	on what client and server configuration you use.
2137080	2138740	So the first thing is that IMAP
2138740	2141820	has a feature called SASL IR, which basically
2141820	2144820	means you can initiate an authentication right away
2144820	2147600	with data. So this is the thing that you have this
2148180	2150540	authenticate plane and send something in the same line
2152280	2154940	where... or you can also not do that.
2154940	2158060	And of course, this is faster. This saves you a roundtrip if you can
2158060	2160820	send data right away with the authentication
2160820	2161880	command.
2163520	2166920	And also, Zazzle has two different modes for
2166920	2169860	username password authentication. They are called plain
2169860	2170960	and login.
2173120	2175880	To make matters even more complicated, both
2175880	2179260	POP3 and IMAP, they have a built-in authentication
2179260	2182200	that is not part of Zazzle, which is kind of
2182200	2185660	part of their protocol itself. In IMAP,
2185660	2188760	this has one roundtrip. In POP3, it has
2188760	2190140	two roundtrips.
2192760	2194880	So this login method,
2194880	2197240	this is not standardized and
2197240	2200780	it is also declared obsolete by the IANA.
2200780	2203200	So the IANA has a registry of
2203760	2206360	Zazzle authentication methods and there it's declared as
2206360	2209320	obsolete. And what it basically does is
2209320	2212320	it sends the username and the password base64 encoded
2212320	2215980	in two roundtrips or just two lines in other words.
2216760	2218600	And then there's this plain authentication
2218600	2221580	method, which is a standard and it sends
2221580	2224680	username and password encoded in one roundtrip.
2224780	2227280	So you save another roundtrip here.
2229360	2229960	So
2230680	2233680	the plain method is standardized and it's
2233680	2236600	faster than login. So it's clearly the better
2236600	2240440	method. And from the security, it doesn't really matter.
2240980	2242660	It's a normal username and password
2242660	2245600	authentication. There's nothing fancy about it.
2247340	2248840	So almost everyone
2248840	2251960	supports both, like both servers and clients, but
2251960	2254860	there's not really a reason to support login.
2256120	2257680	So if you want to
2257680	2260720	have faster email, then you should
2260720	2263760	use implicit TLS and not start TLS. You should support
2263760	2267620	the sessil-ir, which is specifically in IMAP.
2267760	2270140	And you should disable the sessil-login
2270140	2273120	method. Like for example, I figured out my own
2273120	2276140	mail server, it supported both. And my client,
2276140	2278760	if it supported both, it used login because
2278760	2281060	that was the first in the client.
2281680	2284900	It's in class mail. It's the first method that it
2284900	2287940	supports. So it's slower for
2287940	2290880	no gain. And I disabled it on the server and
2290880	2292120	now I'm saving.
2294940	2296460	So yeah.
2297020	2299200	Yeah, that was it.
2299920	2303180	Yeah, don't use TLS. Thanks for listening
2303180	2306960	and I guess we have some time for Q&A now.
2311040	2311980	Hold on.
2311980	2313760	Welcome back, everybody.
2315120	2317900	Can you, Hanno, can you unshare your screen
2317900	2320280	maybe so we can just see you?
2320280	2323360	I just want to put my background on.
2327070	2328070	Okay.
2328790	2331650	So we have, I think we have three questions for you.
2331650	2332990	Can you hear me?
2333770	2338010	Okay. So is the implication
2338010	2341050	that the clients in the SMTP case for ease
2341050	2343950	just ignore responses from the server? I expect
2343950	2346990	them to be a state machine that says, wait, what?
2346990	2349970	I haven't started sending them yet. What do you mean?
2351250	2353270	No, that's not the implication.
2353270	2356210	So the client is not ignoring these answers, but it is
2356750	2359110	like it is processing these line
2359110	2362190	by line. So it is sending
2362410	2365090	a command to the server and then it's reading a line from the server
2365090	2368210	and processing that. And that is why if you do this
2368210	2371170	attack, you kind of have to inject all the
2371170	2374330	commands that the client will send so it will get
2374330	2376610	the answers that it expects.
2377750	2381230	Is this understandable? I hope so.
2381870	2383690	We are monitoring the discord.
2383690	2387330	So if they reply back, I can do it.
2387590	2388170	Yeah.
2390350	2392750	Actually, give me one second. I think we are going to try
2392750	2395930	and share the slides with you so everyone can see it.
2398300	2400040	Give me one second.
2400160	2402320	Share this. I did that.
2405140	2406340	Sorry, everybody.
2406340	2407520	Let's see.
2414680	2417020	So they want me to... let's see.
2424690	2426150	I know we have dead air.
2429340	2431700	Let's see if I can share the screen.
2431820	2434400	I am now also in the discord.
2435240	2436480	That's okay.
2436480	2439740	I will be able to see questions later if they are.
2451180	2453300	I see your screen now.
2453480	2454420	Okay.
2470290	2479070	The second question I have,
2479070	2481270	in the context of SMTP,
2481270	2484550	do you see MTA STS having positive,
2484550	2487850	negative, no change to the start TLS risks?
2491010	2492530	It doesn't...
2494510	2496090	I think the question
2496090	2497650	is framing it wrong.
2497650	2499230	The thing is,
2500550	2503550	MTA STS is introducing an expectation
2503550	2505890	that we didn't have previously.
2505890	2509530	That is that these connections are secure against active attackers.
2509910	2513230	And these attacks can compromise this expectation.
2513670	2515510	So before, we could say these attacks
2515510	2517370	don't matter for MTA to MTA
2517370	2520930	because we don't expect it to be secure anyway.
2520990	2525430	And now we want to introduce connection security for that.
2525650	2527750	So now we have to care about these attacks.
2527750	2530570	But it doesn't really change the risk.
2530570	2534030	It's just that what we try to achieve with MTA STS
2534030	2536670	that is compromised if we have these vulnerabilities.
2539010	2540710	Does that make sense?
2541270	2542350	I mean...
2543350	2545130	Yes, I understand it.
2545710	2547830	Again, we can be in the Slack Discord
2548350	2551330	and maybe later, if people have more questions,
2551330	2552850	you can join in there.
2553570	2554890	Last one that I have.
2554890	2558530	In what kind of issues does the speaker see with implicit TLS?
2561070	2565130	So I think if you compare start TLS and implicit TLS,
2565130	2568970	there are no added issues by implicit TLS.
2569010	2571550	Because it's just the simpler thing.
2571870	2573510	Like with start TLS,
2573510	2576810	we start in plain text and then we do a state transition
2576810	2580610	and that introduces potential for errors.
2580610	2583630	And with implicit TLS, we just don't have that.
2583630	2586810	So I don't see any risk in implicit TLS
2586810	2589790	that you wouldn't have with start TLS.
2590050	2592750	Of course, it has all the risks that you can have
2592750	2594550	otherwise with TLS.
2596030	2598310	If there's a bad implementation,
2598310	2602810	if there's bad randomness or vulnerable algorithms,
2602810	2604110	then you have all the same risks.
2604110	2607150	But you would have the same risks with start TLS as well.
2608250	2610510	We're getting another question.
2610510	2614090	Any thoughts on Telnet start TLS?
2615150	2617450	I have no idea, sorry.
2617710	2619450	I have seen that it exists,
2619450	2623550	but I'm not sure if anyone is using that.
2623650	2625910	I would be curious if anyone is using that.
2625910	2631110	I feel that people use SSH there usually.
2632030	2635130	And then our final question,
2635130	2636890	just thanking you for the talk.
2636890	2639850	Is anyone working on email POP3 replacements
2639850	2641610	with something more secure?
2645410	2646530	I'm not sure.
2646530	2649150	There's not really a problem with POP3.
2649570	2653190	This is not the issue of the talk,
2653190	2655390	but I feel POP3 is a really simple protocol
2655390	2657330	and I kind of like that.
2658150	2660170	I'm also one of these weird people
2660170	2662510	that I'm still using POP3.
2662510	2665450	I like to have the mails on my laptop locally.
2670770	2674170	If you use it with TLS, then it's a fine protocol.
2675570	2676690	Well, again,
2676690	2679270	we would like to thank you for your talk.
2680050	2682830	If anybody has any more questions,
2682830	2684410	you can hang out in the Discord.
2685130	2688790	We'll try and relate them to you, anything like that.
2688790	2691010	I want to thank everyone who's watching the live stream
2691010	2695170	for sitting with us through the first ever
2695170	2699090	DEF CON Safe Mode and the Glitch Crypto and Privacy Village.
2699090	2701110	I want to remind everyone again that we have
2701110	2703910	the Gold Bug Challenge that's still there.
2704170	2706550	And I would like to, again, thank you for your talk
2706550	2709930	and I hope you enjoyed yourself.
2712660	2714120	I guess we wait.
2717000	2719960	Okay, I can leave here now?