1
00:00:00,000 --> 00:00:04,300
All right. Welcome back, everybody. I know it's getting a little late in the day, so thank you

2
00:00:04,300 --> 00:00:09,680
all for turning out. I'd like to introduce our next speaker, Lee Brotherston. He'll be talking

3
00:00:09,680 --> 00:00:14,640
about, as the slide deck suggests, Blue Team TLS Hugs. Let's all give him a warm welcome.

4
00:00:18,660 --> 00:00:28,600
Hello. Okay. Hi. So I'm going to take the standard format of state a problem, say you're all

5
00:00:28,600 --> 00:00:34,460
doing it wrong, and what we should do to fix it. A quick sort of upfront disclaimer. I mention

6
00:00:34,460 --> 00:00:40,520
HTTPS a lot. It's not a talk about HTTPS, but it's the TLS implementation that most people know,

7
00:00:40,680 --> 00:00:45,640
so it's an easy example. And, you know, it's everywhere. It's pretty well understood. And

8
00:00:46,220 --> 00:00:51,800
TLS is being used everywhere. So a super quick primer, just in case anyone doesn't know what TLS

9
00:00:51,800 --> 00:00:57,580
does and not SSL. It's not a cryptographic algorithm. It's a protocol for determining

10
00:00:57,580 --> 00:00:58,580
what kind of cryptography you're using. And it's a protocol for determining what kind of

11
00:00:58,580 --> 00:01:03,520
crypto you're going to use between two endpoints that don't know what each other support. So it's

12
00:01:03,520 --> 00:01:08,580
a negotiation protocol for encryption rather than the encryption itself, although the encryption

13
00:01:08,580 --> 00:01:15,600
naturally follows in the payload afterwards. So here's how it works, or kind of how it works.

14
00:01:15,660 --> 00:01:20,780
This is really more how it works. So the client sends a client a hello packet, and that packet

15
00:01:20,780 --> 00:01:26,660
contains a bunch of information. That's things like what cryptographic protocols it supports,

16
00:01:28,580 --> 00:01:33,220
hashing algorithms it supports, what elliptic curves it has, if any. And then the server

17
00:01:33,220 --> 00:01:38,400
replies with, from that list, I also accept these things, and they can determine what they're going

18
00:01:38,400 --> 00:01:44,420
to do. They then exchange keying data, and then encrypted data, and then renegotiate, and that

19
00:01:44,420 --> 00:01:51,780
carries on in a cycle until they're done. So that said, the current state of the art, we should

20
00:01:51,780 --> 00:01:56,500
look at that to sort of see what's wrong and where we can go and do other things in the future.

21
00:01:58,580 --> 00:02:04,000
Three things that defense people can do with TLS. You can ignore it, you can break it, so that's

22
00:02:04,000 --> 00:02:09,020
man in the middle and that sort of thing, or you can embrace it. In the real world, we don't bother

23
00:02:09,020 --> 00:02:14,040
with embracing it, and we either ignore or break it. The closest to doing it right is actually

24
00:02:15,160 --> 00:02:20,180
the domestic situation in a lot of cases, not in a corporate environment. So I'll just explain

25
00:02:20,180 --> 00:02:27,460
a little about what I mean by each of these. So ignoring TLS. If you've ever run something

26
00:02:27,460 --> 00:02:28,560
like an IDS or something like that, you're going to have a lot of trouble with it. So

27
00:02:28,580 --> 00:02:33,060
if you run something like that, and you see TLS encrypted traffic on the network, it's just

28
00:02:33,060 --> 00:02:39,280
garbled up encrypted mess. I mean, that's the point. You don't see the payload. If you look at

29
00:02:39,280 --> 00:02:45,460
the snort community rules as they stood at the time, this is the clear text and TLS-enabled

30
00:02:45,460 --> 00:02:50,560
versions of each of the protocols, and that's the number of rules. You can see there's significantly

31
00:02:50,560 --> 00:02:57,780
more for the clear text, because if you've got your IDS alerting on any request that's like a

32
00:02:57,780 --> 00:02:58,560
dot-dot-slash-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot-dot

33
00:02:58,580 --> 00:03:03,380
dot-dot-slash-dot-dot-dot-slash, that will alert fine in clear text, but not in TLS. The

34
00:03:03,380 --> 00:03:10,660
TLS rules are just heartbleed and things like that. So you're largely blind to a whole sea of

35
00:03:10,660 --> 00:03:17,700
exploits, and so effectively it's just ignored. So that leads to this. Does anyone know what this

36
00:03:17,700 --> 00:03:25,560
is? I will give you a further hint. It is the universal firewall bypass port.

37
00:03:29,160 --> 00:03:34,640
Because if we don't understand crypto, we just let it through, right? Because you've seen this,

38
00:03:34,740 --> 00:03:41,740
I'm guessing. You can get out of a lot of corporate environments just by SSH-ing on port 443,

39
00:03:41,880 --> 00:03:47,320
because what are you going to do with port 443? Well, we'll come to what you can do, but right

40
00:03:47,320 --> 00:03:52,680
now we're talking it's often ignored and just left open. You can also often connect even when

41
00:03:52,680 --> 00:03:57,320
they have a proxy and just use a connect command on port 443, and it will let you straight through.

42
00:03:58,580 --> 00:04:03,240
So what do we do in the situation where we're not looking at TLS on the network?

43
00:04:04,220 --> 00:04:09,920
Most of the time that comes down to using endpoint security solutions. So antivirus,

44
00:04:10,040 --> 00:04:16,240
anti-malware, various memory protection techniques, and that sort of thing,

45
00:04:16,340 --> 00:04:22,040
to capture all the bad on the endpoint as it's coming in, rather than looking at it on the

46
00:04:22,040 --> 00:04:28,220
network. We also look at blacklists. So you've got a list of blacklisted IP

47
00:04:28,580 --> 00:04:33,460
addresses, for example. You don't know what the data is going to them, but you know they're part

48
00:04:33,460 --> 00:04:38,180
of a command and control network or something. So you know that there's bad data going there,

49
00:04:38,340 --> 00:04:44,220
you avoid it, run away, and hope that that was a good blacklist. But there are problems with

50
00:04:44,220 --> 00:04:49,740
blacklists too. Very often they're not up to date or are lacking information, but even if they have

51
00:04:49,740 --> 00:04:54,160
the information, there's a lag between it coming from the real world to the blacklist, from the

52
00:04:54,160 --> 00:04:58,280
blacklist to your environment, and your environment to you actioning it, by which time half the

53
00:04:58,580 --> 00:05:05,260
addresses are out of date. So some of the time we break TLS. So I'm talking things like where you

54
00:05:05,260 --> 00:05:10,540
have these proxies that run their own CA and they man in the middle of the traffic. To explain how

55
00:05:10,540 --> 00:05:14,580
it works, you have a client, a proxy, and the web server you're connecting to, or any other

56
00:05:14,580 --> 00:05:21,020
server, sorry. Your client makes a TLS handshake with the proxy, and then files a request, so

57
00:05:21,020 --> 00:05:28,420
sends the URL that it would like. The proxy then does a TLS handshake with the server. The request

58
00:05:28,580 --> 00:05:35,080
gets forwarded, goes to the server and it gets a response, which then gets forwarded, and sent back

59
00:05:35,080 --> 00:05:41,880
to the client. The problem is that this stuff is in the clear. That's because the proxy has its own

60
00:05:42,900 --> 00:05:50,000
SSL certificate, and what this means is that you have the actual CA on the right that uses all the

61
00:05:50,000 --> 00:05:55,640
proper signatures and all the magic that's associated, and you've got your shonky, my first

62
00:05:55,640 --> 00:05:57,980
work CA happening on the left-hand side.

63
00:05:58,580 --> 00:06:04,780
And this brings a whole ton of issues other than it's a really horrible thing to have to try and manage.

64
00:06:06,000 --> 00:06:15,440
So to explain how that works, it breaks the CA model in a bunch of ways, because although the CA model's

65
00:06:15,440 --> 00:06:22,140
kind of broken to start with, this breaks it even more because it is not one of the certificate

66
00:06:22,140 --> 00:06:27,480
authorities trusted by browsers, for example, and that causes a bunch of issues. I'm just going to go

67
00:06:27,480 --> 00:06:28,560
through a few and then we'll get to it.

68
00:06:28,580 --> 00:06:30,420
And we can get on to what you can actually do to fix it.

69
00:06:31,120 --> 00:06:37,520
So there's simple compromised appliance. If that appliance in the middle got hacked, data's going through in the

70
00:06:37,520 --> 00:06:44,820
clear. It could be manipulated. It can be sniffed and logged and all sorts of stuff. So think of online

71
00:06:44,820 --> 00:06:50,760
banking or logging in to look at medical records or something like that. Just compromising the device

72
00:06:50,760 --> 00:06:58,160
that has the cert is enough. If the key that's on there gets compromised, that's bad too, because if the

73
00:06:58,580 --> 00:07:07,680
key is lost or goes to someone else, they will be able to take that key and impersonate any website to your

74
00:07:07,680 --> 00:07:15,400
devices, because when you set up that sort of system, you set the CA as trusted in all the endpoint devices.

75
00:07:16,200 --> 00:07:22,740
And also, key management is hard. It's really, really hard to get right. If you want the closest I can get to an

76
00:07:22,740 --> 00:07:28,560
empirical study on key management is hard, if you look at ISO 27002, and I apologize for that, but if you look at the

77
00:07:29,340 --> 00:07:35,320
compliance framework type stuff, but key management alone has a higher word count than the whole of the rest of the

78
00:07:35,320 --> 00:07:41,520
cryptographic control section. And in the cryptographic control section, six of those are words key management

79
00:07:41,520 --> 00:07:50,440
referring to go look at the key management section. There's also poor certificate validation. So when you connect

80
00:07:50,440 --> 00:07:55,520
directly to something with a web browser or any other TLS-enabled client, it does a bunch of checks. It does things like

81
00:07:55,520 --> 00:07:58,260
does the host name on the certificate match what I was expecting?

82
00:07:58,580 --> 00:08:04,660
It checks the certificate chains, it looks for revoked certs, it looks to see if it's a trusted CA, all these things.

83
00:08:04,980 --> 00:08:10,480
None of these you see when you man in the middle, because all you see is the one valid cert for everything that you just

84
00:08:10,480 --> 00:08:17,220
installed on that device. That means that you are trusting that device to do all that validation for you. If any of you

85
00:08:17,220 --> 00:08:24,700
have ever run those devices, you'll know that you can't trust them to do that. If nothing else, their list of trusted

86
00:08:24,700 --> 00:08:27,400
CAs is horrifically out of date, typically.

87
00:08:28,580 --> 00:08:30,760
And they fail a bunch of the other validation checks.

88
00:08:32,040 --> 00:08:38,560
So let's talk about that trusted CA list. If you look in your browsers or your OS, in fact, as many browsers use the default OS

89
00:08:38,560 --> 00:08:46,480
one too, you will see that there's the list of trusted CAs. So that is authorities who are able to sign certificates as

90
00:08:46,480 --> 00:08:58,560
valid. But these things get revoked. You trust what the appliance trusts, right? But a few months ago, a few months ago,

91
00:09:00,080 --> 00:09:06,700
WoSign got pulled by a bunch of browsers and pulled pretty quickly because of some of the practices they were employing.

92
00:09:08,980 --> 00:09:15,080
But if you are not updating that appliance in real time, you can go to one of those sites that the certificates have been pulled from,

93
00:09:15,240 --> 00:09:20,580
and your browser will be none the wiser. It will think they're all valid because it's just getting that cert from the proxy.

94
00:09:21,780 --> 00:09:28,160
Oh, yeah, I don't know what that is. Anyway, there's also certificate unpinning.

95
00:09:28,580 --> 00:09:35,740
If anyone knows what certificate pinning is, this is where your client is pre-configured to say, when I connect to such and such a service,

96
00:09:35,840 --> 00:09:42,880
I expect to see this certificate or this certificate, which has been signed by this CA, or some combination.

97
00:09:43,160 --> 00:09:50,040
It matches this fingerprint, or it's got this intermediate one. But whatever, you can pin to one degree or another what you're

98
00:09:50,040 --> 00:09:58,280
expecting to see. This gets around the issue of things like, say, a rogue government with not many scruples somewhere,

99
00:09:59,860 --> 00:10:06,480
convinces a CA to issue a certificate, a valid certificate, for a domain that's really hosted with another CA.

100
00:10:06,700 --> 00:10:13,440
And then they can use that to man in the middle without flagging up warnings because it comes from a valid CA.

101
00:10:14,220 --> 00:10:21,500
When you install a local CA, as is the case when you're having the man-in-the-middle proxy, most browsers disable pinning.

102
00:10:22,420 --> 00:10:28,200
This is because if you're running one of these proxies, people like Google use pinning, and they don't want Gmail to just

103
00:10:28,280 --> 00:10:33,620
fail everywhere on your corporate network. Disabling pinning is bad in a number of ways.

104
00:10:35,240 --> 00:10:41,500
And finally, there's the malicious insider, just the member of staff who now, because they have access to the appliance or the

105
00:10:41,500 --> 00:10:47,200
certificate or both, has access to do all sorts of bad on your network and to your devices.

106
00:10:48,260 --> 00:10:57,960
So that is my brief TLS, we're doing it wrong. So I'm going to talk about trying to embrace it a little more and do the right thing.

107
00:10:58,780 --> 00:11:08,560
So let's embrace it. I'm going to set some goals. So if we look at all the different devices that intercept the traffic and do

108
00:11:08,560 --> 00:11:18,300
things to your traffic, they generally do this list. So it's things like content filtering, logging that content filtering, checking

109
00:11:18,300 --> 00:11:28,260
certificates, malware detection, etc., etc. In my opinion, which is largely unscientific, but I'm going to give it anyway, go team, this is

110
00:11:28,280 --> 00:11:36,760
the stuff they approximately do right, this is the stuff I don't think they do particularly well, this is the stuff they sort of do well and not so

111
00:11:36,760 --> 00:11:46,040
well, and this is what we actually want. Not many people seem to want cryptographic checks, and by that I mean checking which algorithms

112
00:11:46,040 --> 00:11:52,260
are used and not used. They're pretty happy to trust their browsers to do that. And granular content filtering, I have an argument about

113
00:11:52,260 --> 00:11:57,820
this, that people don't really need that, and by granular I mean full URL content filtering instead of hostname.

114
00:11:57,820 --> 00:12:06,280
For example, most people don't want to block one category of porn and not another category of porn. They just want to block Pornhub or not block

115
00:12:06,280 --> 00:12:16,920
Pornhub. That's pretty much where they're at. So feel free to disagree, but that's what I'm saying. Anyway, so I'm going to try and get those

116
00:12:16,920 --> 00:12:25,580
goals sorted. So I'm a believer that perfection is the enemy of good enough. People boil the ocean trying to get RFP done for 100% complete

117
00:12:25,580 --> 00:12:27,800
solution. So I'm trying to offer that.

118
00:12:27,820 --> 00:12:35,900
But a gets you a good chunk of the way there, but quickly and easily and without hassle. We have many cases in the real world where sort of half-assed

119
00:12:35,900 --> 00:12:45,600
things do work and get the job done. So we'll work with that. So I had a thought. So there's first, there's packet, there's a bunch of packet

120
00:12:45,600 --> 00:12:55,680
sniffing we can do. I did some studying a little while ago on TLS fingerprinting, and you can use that to determine all sorts of bad stuff. The long and the

121
00:12:55,680 --> 00:12:57,800
short of that, there's another talk on that if you want to know more about that. So I'm going to try and get those goals sorted.

122
00:12:57,800 --> 00:13:27,060
I'm going to learn about the in-depth stuff. But TLS fingerprinting is basically you can go through and monitor the TLS handshake and determine what client it is. That means that you can treat this like an IDS and say, oh, great, this host is connecting on Google Drive. This one's on Skype. This one's on Tor. This is using Chrome. This is using IE. If anyone uses a corporate environment, you'll know that seeing Chrome and IE is fine. Seeing Tor and things is not. And depending on your environment, Google Drive or Dropbox or something could be potentially

123
00:13:27,060 --> 00:13:27,560
bad.

124
00:13:27,800 --> 00:13:57,280
Someone losing data. But what I'm getting at really is that it gives you the opportunity to understand the encrypted connections in your environment to a good way. A good degree, sorry. You can also use it to spot bad things in general. So you can spot rogue clients. You're in a all Mac environment and you see IE. That's probably someone plugging their own laptop in. You can also spot malware. For example,

125
00:13:58,180 --> 00:14:05,220
Drydex used TLS. You can monitor the TLS connections that it makes. And you can see that

126
00:14:06,100 --> 00:14:10,240
not only which clients you have are infected, you can map out the command and control network

127
00:14:10,240 --> 00:14:16,260
real time as they talk back to it. This is Cisco saying the same thing because I can't push the

128
00:14:16,260 --> 00:14:20,460
slide advance button in a sensible order. But this is Cisco's blog that was saying,

129
00:14:20,520 --> 00:14:27,460
hey, we can't see stuff because malware uses TLS. But they do use different TLS fingerprints to a lot

130
00:14:27,800 --> 00:14:34,240
apps so you can often spot malware using it you can also do semi-automated fingerprinting so

131
00:14:34,860 --> 00:14:41,120
it's so easy to make fingerprints that you can automate creating a fingerprint for anything you

132
00:14:41,120 --> 00:14:47,060
see but have not seen before and then that can be reused when you see that fingerprint coming again

133
00:14:47,060 --> 00:14:53,120
so if it's seen once and associated with something bad and then you see it come back again you can

134
00:14:53,120 --> 00:14:58,940
often tell that it's the same something bad prime examples are botnets have their own metasploit has

135
00:14:58,940 --> 00:15:04,160
its own so you don't have to know what it is in advance if you tie it back to a previous incident

136
00:15:04,160 --> 00:15:11,700
you can still determine that it's bad and you can do pseudo anomaly based detection as well

137
00:15:11,700 --> 00:15:20,120
which is largely the same thing but it's based on on past behaviors and finally you've got

138
00:15:20,120 --> 00:15:23,080
fingerprint canaries so if you look think of being in the

139
00:15:23,080 --> 00:15:29,600
situation of being a generic ride-sharing app a bankrupting blockbuster as a service or one of the

140
00:15:29,600 --> 00:15:37,520
closed API social media services they all create their own API and their own client and they don't

141
00:15:37,520 --> 00:15:41,860
open up to third parties if you were to one of these companies you could monitor all connections

142
00:15:41,860 --> 00:15:46,500
to your API endpoint to see if it matches the fingerprint of your client if it doesn't match

143
00:15:46,500 --> 00:15:52,580
your official client you just drop it on the floor and you've then removed curl burp suite and all

144
00:15:52,580 --> 00:15:53,060
the other things that you need to do to make sure that it matches the fingerprint of your client if it doesn't match your official client you just drop it on the floor and you've then removed curl burp suite and all the other things

145
00:15:53,060 --> 00:15:56,100
that you potentially don't want in touching your API endpoints unless

146
00:15:56,100 --> 00:16:00,400
someone goes to the hassle of actually masquerading the TLS stack of that app

147
00:16:00,400 --> 00:16:06,860
to give you an example of a similar technique and Mozilla released this

148
00:16:06,860 --> 00:16:10,900
blog about checking for man-in-the-middle which is exactly what

149
00:16:10,900 --> 00:16:14,900
I'm talking about here based on the connections coming in from the browsers

150
00:16:16,520 --> 00:16:20,420
you can also sort of do incident response and attribution although

151
00:16:20,420 --> 00:16:22,680
attribution is hard and that's like a whole area

152
00:16:23,180 --> 00:16:29,060
shouldn't venture into but if you have an exploit that comes into a network

153
00:16:29,060 --> 00:16:33,620
over TLS the tools that are used to develop it if they have their own

154
00:16:33,620 --> 00:16:37,580
signatures you can reuse watch that signature propagating across the network

155
00:16:37,580 --> 00:16:41,440
and you can watch the progress of an incident as people pivot horizontally

156
00:16:41,440 --> 00:16:45,780
across the network and I'm going to just quickly demo what this actually means

157
00:16:46,320 --> 00:16:49,380
before I stop talking about fingerprinting and drive you all insane

158
00:16:49,380 --> 00:16:53,040
on that one topic just for reference though this is the best German word in

159
00:16:53,040 --> 00:16:55,940
whatever it means it doesn't look when someone's what it doesn't work when

160
00:16:55,940 --> 00:17:05,140
someone's watching so I've so I've I've recorded it so this is just a tool I

161
00:17:05,140 --> 00:17:09,520
wrote running in the terminal and this is a standard Windows VM it's from a few

162
00:17:09,520 --> 00:17:12,860
months ago so I apologize the versions are a little old but you'll you'll get

163
00:17:12,860 --> 00:17:18,280
the idea so you go visit some site and it's just at a packet sniffer at the

164
00:17:18,280 --> 00:17:22,080
end and it's picked up that you've got Firefox and signal because why not

165
00:17:23,040 --> 00:17:29,020
connect into a bunch of things and then at the same time you can go I think it's

166
00:17:29,020 --> 00:17:33,500
Google Drive or Dropbox I used my memory is terrible in this anyway yeah

167
00:17:33,500 --> 00:17:40,100
so these all use either API's or their HTTPS under the hood or whatever so as

168
00:17:40,100 --> 00:17:44,840
the file syncs up you'll see that it Dropbox comes up there as having

169
00:17:44,840 --> 00:17:50,420
connected and finally the thing that most people like to see on their network

170
00:17:50,420 --> 00:17:53,020
is Tor so I'll just leave that there.

171
00:17:53,040 --> 00:17:58,280
Let it do the Tor thing so this is Tor browser which is just a bundled Tor and

172
00:17:58,280 --> 00:18:03,440
Firefox all-in-one tool and as that connects to the Tor network without

173
00:18:03,440 --> 00:18:06,800
doing any web browsing it starts screaming all over the network I'm Tor

174
00:18:07,640 --> 00:18:10,660
if you were being a bit more active about that you could use that for

175
00:18:10,660 --> 00:18:15,780
alerting and you could pick up on malicious network traffic anyway that's

176
00:18:15,780 --> 00:18:22,940
that bit so oh thank you so enough on fingerprinting their server

177
00:18:22,940 --> 00:18:27,300
responses too so the server hello packet also has a bunch of information

178
00:18:27,300 --> 00:18:30,780
that's really useful for you first of all it lets you know what has been

179
00:18:30,780 --> 00:18:35,160
negotiated so you can tell if they're using old TLS versions weak cipher

180
00:18:35,160 --> 00:18:38,600
suites and that sort of thing I'm running a long time so I'm gonna go

181
00:18:38,600 --> 00:18:44,620
super fast you can harvest all the certificates I'm going to refer back to

182
00:18:44,620 --> 00:18:47,960
something I mentioned earlier you can log all the certificates that are

183
00:18:47,960 --> 00:18:51,860
associated with the website at the time so in the future you can go back in time

184
00:18:51,860 --> 00:18:52,500
and see what's the

185
00:18:52,940 --> 00:19:02,980
you saw why is this useful well this again will sign and Google drop China's

186
00:19:02,980 --> 00:19:08,600
route cert and I think other people may have done to this let's oh sorry and

187
00:19:08,600 --> 00:19:13,340
super fish who had its horrible difficult situation this is super easy

188
00:19:13,340 --> 00:19:21,020
to do you can use a plug-in in bro and that will do logging of certificates and

189
00:19:21,020 --> 00:19:22,380
then when someone says hey this certificate

190
00:19:22,380 --> 00:19:22,760
authority

191
00:19:22,760 --> 00:19:26,540
has been acting bad you can go back retrospectively see which sites use

192
00:19:26,540 --> 00:19:29,300
that cert and you know if your clients could have been compromised in the past

193
00:19:29,960 --> 00:19:33,760
finally I'm going to talk about inline TLS shenanigans which is actually my new

194
00:19:33,760 --> 00:19:38,620
thing so you can mess with the handshake it's in the clear it's not

195
00:19:38,620 --> 00:19:43,460
cryptographically signed so you can modify what's inside it remember this I

196
00:19:43,460 --> 00:19:49,900
suggest this know what I suggest is an alternative is a proxy that works at the

197
00:19:49,900 --> 00:19:52,520
socket layer and passes data backwards and forwards

198
00:19:52,760 --> 00:19:58,000
so it doesn't mess with the encryption, it doesn't re-sign things and fall foul of all those CA issues I mentioned.

199
00:19:59,140 --> 00:20:02,580
It can still see the server hello stuff, so it knows what's been negotiated,

200
00:20:02,880 --> 00:20:07,160
it knows what cryptographic protocol is being used, and it can see that stuff.

201
00:20:08,280 --> 00:20:13,160
Most importantly, it can fingerprint stuff, and because anything vaguely current uses SNI,

202
00:20:13,320 --> 00:20:16,120
you can pull the host name in the clear that it's connecting to.

203
00:20:16,280 --> 00:20:21,260
That gives you enough for coarse-grained content filtering, and you can also tie this together with clients.

204
00:20:21,260 --> 00:20:29,140
So you can say that Skype can access Skype servers, but Skype servers alone, i.e. can go to all sorts of other servers, whatever.

205
00:20:30,060 --> 00:20:32,160
This is also safe because it's subtractive.

206
00:20:32,260 --> 00:20:38,980
I can't put in a crappy cipher suite and trick browsers into degrading themselves to that terrible cipher suite.

207
00:20:39,140 --> 00:20:41,260
They never offered it in the first place, they won't support it.

208
00:20:41,420 --> 00:20:49,840
I can, however, pull crappy cipher suites out and force them to only negotiate the stronger cipher suites and other aspects.

209
00:20:50,320 --> 00:20:51,240
And then you've got...

210
00:20:51,260 --> 00:20:52,120
This is what the compliance is.

211
00:20:53,500 --> 00:20:58,000
Most of the compliance standards, including PCI, will say things like,

212
00:20:58,060 --> 00:21:00,560
you can't use old versions of SSL and TLS.

213
00:21:00,900 --> 00:21:04,620
Well, if you're monitoring that handshake and have a proxy in the middle,

214
00:21:04,740 --> 00:21:08,100
you can look for old versions of TLS, drop them on the floor,

215
00:21:08,180 --> 00:21:12,080
and ensure you maintain compliance on your network, irrespective of what the applications are doing.

216
00:21:13,100 --> 00:21:14,420
So there's a remaining problem.

217
00:21:14,780 --> 00:21:19,460
If you're not manning the middling, it's super hard to put that little pop-up up that goes,

218
00:21:19,540 --> 00:21:21,120
you've been blocked, you were a bad...

219
00:21:21,260 --> 00:21:21,480
person.

220
00:21:21,820 --> 00:21:24,500
So, I tried a few things.

221
00:21:24,640 --> 00:21:25,800
I put a bad certificate in.

222
00:21:26,340 --> 00:21:29,940
Shockingly, Chrome and Firefox were super not happy with that plan.

223
00:21:31,160 --> 00:21:34,260
There is a response of server hello done, which is just,

224
00:21:34,300 --> 00:21:36,240
I'm not sent a certificate, but I'm done.

225
00:21:37,140 --> 00:21:39,940
It also doesn't sound super good to the user going,

226
00:21:40,020 --> 00:21:42,400
can't provide a secure connection, and...

227
00:21:42,400 --> 00:21:43,500
This is Chrome, sorry.

228
00:21:43,680 --> 00:21:48,420
And in Firefox, saying secure connection failed also sounds bad.

229
00:21:48,700 --> 00:21:51,240
And if it's the subcomponent of another...

230
00:21:51,240 --> 00:21:55,780
page you've allowed through, it throws those SSL errors about mixed content.

231
00:21:56,280 --> 00:21:57,540
So, it's not very good.

232
00:21:57,740 --> 00:22:01,660
But I came up with a solution which is super crude, but works.

233
00:22:02,040 --> 00:22:06,520
So, I will just demonstrate how this works really quickly,

234
00:22:06,680 --> 00:22:09,960
and then I will show you how that looks in browsers for your reference.

235
00:22:10,260 --> 00:22:12,060
So, demo again.

236
00:22:12,320 --> 00:22:16,100
So, this is my tool at the top.

237
00:22:16,180 --> 00:22:16,940
This is a proxy.

238
00:22:17,080 --> 00:22:17,780
It's just written in Go.

239
00:22:19,460 --> 00:22:20,460
I'm going to curl.

240
00:22:20,660 --> 00:22:21,160
I've set it...

241
00:22:21,160 --> 00:22:23,000
There's a proxy, but it can be a transparent proxy, too.

242
00:22:23,080 --> 00:22:24,620
This is just for ease of demo purposes.

243
00:22:25,180 --> 00:22:29,000
So, if I try and curl the CryptoVillage website,

244
00:22:29,780 --> 00:22:32,740
it logs that I used curl, but I went to CryptoVillage.

245
00:22:32,760 --> 00:22:35,160
It's not on the block list, and it went through at the bottom.

246
00:22:35,480 --> 00:22:38,320
If I curl something that I'm less interested in,

247
00:22:38,880 --> 00:22:42,060
in this case, one of our favorite ad networks,

248
00:22:43,920 --> 00:22:49,880
what you'll find is that the server-aborted SSL handshake,

249
00:22:49,900 --> 00:22:51,140
that's actually not...

250
00:22:51,140 --> 00:22:52,100
Not as bad as it sounds.

251
00:22:52,160 --> 00:22:54,820
That's literally just dropped the TCP connection on the floor,

252
00:22:54,980 --> 00:22:57,180
and it got the drop on the proxy.

253
00:22:58,400 --> 00:23:02,120
This looks crude in curl, because I'm just kind of showing you,

254
00:23:02,160 --> 00:23:03,220
and it has that nasty error,

255
00:23:03,340 --> 00:23:06,400
but it actually has the valid cert come back every time,

256
00:23:06,440 --> 00:23:08,500
and the browser gets to do all their thing.

257
00:23:08,680 --> 00:23:14,000
But more importantly, it just looks like the server is down to the browser when you go direct,

258
00:23:14,300 --> 00:23:17,100
and when it's a subcomponent on a page, like an image or a script,

259
00:23:17,340 --> 00:23:19,680
it just looks like the messing little square

260
00:23:20,080 --> 00:23:20,900
in all the...

261
00:23:20,900 --> 00:23:21,840
in all the browsers.

262
00:23:22,060 --> 00:23:23,620
You don't get any SSL errors.

263
00:23:23,820 --> 00:23:25,820
You don't get big barfs or anything like that.

264
00:23:26,260 --> 00:23:27,980
So, I'm going to go as fast as I can.

265
00:23:28,120 --> 00:23:28,600
How do we do?

266
00:23:28,960 --> 00:23:31,780
I say we did course content filtering fine,

267
00:23:32,860 --> 00:23:34,540
and application detection we got,

268
00:23:34,720 --> 00:23:35,740
course logging we got,

269
00:23:35,940 --> 00:23:37,100
granular logging not really.

270
00:23:37,300 --> 00:23:39,260
I'll come back to that, but I probably won't have time, so I won't.

271
00:23:39,820 --> 00:23:40,780
Certificate checks we did.

272
00:23:41,420 --> 00:23:43,100
Malware detection we sort of did.

273
00:23:43,240 --> 00:23:45,280
We didn't do it in the AV sense,

274
00:23:45,480 --> 00:23:47,900
but you can have TLS signatures on malware,

275
00:23:48,120 --> 00:23:50,100
so you can pick up a certain amount of it.

276
00:23:51,920 --> 00:23:53,940
In-page exploits, totally didn't do that,

277
00:23:54,040 --> 00:23:55,520
but I said I was only doing 90%.

278
00:23:56,500 --> 00:23:57,600
DLP, half did.

279
00:23:57,700 --> 00:23:59,300
We don't detect documents going out,

280
00:23:59,340 --> 00:24:01,660
but we can detect things like Google Drive and Dropbox

281
00:24:01,660 --> 00:24:03,720
and things that may hint at data exfiltration,

282
00:24:04,280 --> 00:24:06,380
and data exfiltration falls under that banner.

283
00:24:07,360 --> 00:24:08,160
One more thing.

284
00:24:08,260 --> 00:24:08,660
Do I have time?

285
00:24:08,880 --> 00:24:09,700
Oh, I'm going to try and do it quick.

286
00:24:10,480 --> 00:24:11,300
Course grain login.

287
00:24:11,680 --> 00:24:13,300
This is an encrypted payload.

288
00:24:13,620 --> 00:24:15,500
It's 227 bytes long.

289
00:24:16,040 --> 00:24:20,660
There is a set ratio of algorithm clear text to ciphertext.

290
00:24:20,680 --> 00:24:20,880
There is a set ratio of algorithm clear text to ciphertext.

291
00:24:22,160 --> 00:24:22,540
There is a set ratio of algorithm clear text to ciphertext.

292
00:24:23,340 --> 00:24:24,180
You can take it.

293
00:24:24,280 --> 00:24:26,080
So, if you know the size of something,

294
00:24:26,180 --> 00:24:28,000
you can guess certain amounts of the content.

295
00:24:28,520 --> 00:24:30,260
You know the hostname that it's connected to,

296
00:24:30,360 --> 00:24:31,600
so you've got 206 left.

297
00:24:31,800 --> 00:24:34,140
You know the user agent, because I fingerprinted the OS,

298
00:24:34,380 --> 00:24:36,600
so you can roughly guess what the user agent is,

299
00:24:36,740 --> 00:24:38,540
so now you're down to 151.

300
00:24:39,200 --> 00:24:41,020
You know what that user agent accepts,

301
00:24:41,480 --> 00:24:42,820
so you're down to 95.

302
00:24:43,380 --> 00:24:44,800
You know how it encodes,

303
00:24:44,860 --> 00:24:45,940
so now you're down to 58.

304
00:24:46,500 --> 00:24:48,000
And, you've got the IP address,

305
00:24:48,260 --> 00:24:50,880
so you can probably guess that you've got 26 left.

306
00:24:50,900 --> 00:24:55,640
left you know that you're going to have the words get and http so you can guess that the remainder

307
00:24:55,640 --> 00:25:00,720
of the bytes are probably the url and narrowed down to a degree where you might be unless you

308
00:25:00,720 --> 00:25:08,480
pad so just like pad everything conclusion i'm running low on time so uh this is stuff uh related

309
00:25:08,480 --> 00:25:15,900
to this um probably the main thing to do is just look at the slide deck one uh speaker deck.com

310
00:25:15,900 --> 00:25:23,080
my name then you can find this um i was going to say any questions i've got maybe 10 no no time for

311
00:25:23,080 --> 00:25:26,600
questions i will be in a corridor or a bar or something and you're more than welcome to grab

312
00:25:26,600 --> 00:25:32,160
me and i'll do this again thank you