1
00:00:00,000 --> 00:00:04,740
Hey, folks. Thanks for being here at the Crypto and Privacy Village. We have another fantastic

2
00:00:04,740 --> 00:00:11,360
talk lined up. Our very own Jake Williams, Malware Jake from Rendition Info Sec. He's going

3
00:00:11,360 --> 00:00:17,480
to be talking about the semantic SSL debacle, lessons learned and future steps. So please give

4
00:00:17,480 --> 00:00:26,840
it up for Jake. And now you're going to give me a minute to readjust this mic because

5
00:00:26,840 --> 00:00:32,180
apparently we only have one, which is cool. And it's not cordless. So if I trip on this,

6
00:00:32,220 --> 00:00:36,640
somebody be prepared. Does anybody know first aid? No? Okay. I can't stand behind a podium

7
00:00:36,640 --> 00:00:40,280
for half an hour or an hour or whatever we're going to do here. I think we've got like 45

8
00:00:40,280 --> 00:00:46,580
minutes or something. So this is something that was really, really interesting to me when it

9
00:00:46,580 --> 00:00:51,120
first hit. I'm really, really interested in SSL in the first place. I think SSL is a

10
00:00:51,120 --> 00:00:56,700
dumpster fire. And hopefully by the end of this talk you share some of those same opinions

11
00:00:56,700 --> 00:01:01,960
and if not, you at least understand why I think SSL is a dumpster fire and kind of what we need

12
00:01:01,960 --> 00:01:08,360
to be thinking about as InfoSec people. And I look around here and I'm guessing that maybe I've

13
00:01:08,360 --> 00:01:13,620
got 10ish percent decision makers and a lot of influencers, a lot of technical influencers,

14
00:01:13,840 --> 00:01:17,960
right? So my goal here is for the decision makers to make sure you understand what's going on

15
00:01:17,960 --> 00:01:22,460
and for the influencers to give you some of the arguments to go back and talk to folks and

16
00:01:22,460 --> 00:01:26,200
communicate effectively with your decision makers so they can make the right decisions.

17
00:01:26,700 --> 00:01:32,100
So I want to talk about the Symantec SSL issue. Originally I wasn't going to do a lot of this. I

18
00:01:32,100 --> 00:01:36,500
was just going to kind of assume everybody knew. And over the last couple of weeks I've been

19
00:01:36,500 --> 00:01:40,660
teaching SANS around the world, actually in three different countries over the last month. And I

20
00:01:40,660 --> 00:01:46,860
found out that by polling InfoSec people, I found out that almost nobody understands this. So I

21
00:01:46,860 --> 00:01:54,040
revamped the slide deck a lot. Then this week Google pulled a nasty on me. And they reached a

22
00:01:54,040 --> 00:01:56,600
tentative agreement with Symantec on how the

23
00:01:56,700 --> 00:02:01,260
data sets were going to move forward. So then I had to overhaul a bunch of stuff in the slide deck.

24
00:02:01,400 --> 00:02:05,240
Because obviously then I've got, you know, can't talk about like, well, we don't know how this is

25
00:02:05,240 --> 00:02:10,300
going to end. We actually have some idea how it's going to end. Of course we'll have to see how

26
00:02:10,300 --> 00:02:16,240
that all plays out. We at least have an idea, right? So I've been pulling data, too. I'm a data

27
00:02:16,240 --> 00:02:22,160
guy. I really, really like data. I'll make my data sets publicly available later. If anybody's

28
00:02:22,160 --> 00:02:26,160
really interested, follow me on Twitter. I promise you I'll tweet out links to the data sets when I

29
00:02:26,160 --> 00:02:30,760
get them up in GitHub. But basically over the last several months we've been pulling certificates.

30
00:02:31,060 --> 00:02:34,520
And I'll talk more about some of our methods here. We've been going out and pulling SSL

31
00:02:34,520 --> 00:02:40,200
certificates from the Alexa top 1 million. Now I know that this is not necessarily the best data

32
00:02:40,200 --> 00:02:46,040
set. But it's a consistent data set. So back in April this whole thing started in March. Back in

33
00:02:46,040 --> 00:02:50,400
April we went ahead and grabbed early April, grabbed the Alexa top 1 million. We haven't

34
00:02:50,400 --> 00:02:55,400
updated that since because I want a consistent set of sites. I want to be able to watch the drift

35
00:02:56,160 --> 00:03:00,500
across basically how certificates change and what are people doing with certificates that are

36
00:03:00,500 --> 00:03:05,780
different. Because I would think that this industry wide announcement of intent to deprecate

37
00:03:05,780 --> 00:03:10,740
trust in Symantec would force change in people. For those that don't know me, I'm a big

38
00:03:10,740 --> 00:03:14,860
psychology guy, too. I actually minored in psych back in the day in my undergrad. And I love

39
00:03:14,860 --> 00:03:19,840
psychology. So I'm really interested in the psychological aspect of this. Some of these messages

40
00:03:20,300 --> 00:03:25,900
came out and people are renewing certificates. Did they do stuff differently? And unfortunately the

41
00:03:26,160 --> 00:03:31,880
answer there is not a lot actually. It's kind of scary. I want to talk about some of the stuff

42
00:03:31,880 --> 00:03:35,960
that we're dealing with here. This is not the first time we've dealt with the intent to deprecate a

43
00:03:35,960 --> 00:03:41,780
cert. And it's definitely not the first time that we've dealt with not only an intent to deprecate a

44
00:03:41,780 --> 00:03:46,660
cert but the need for mass cert revocation. And yet we're treating it like it's the first time.

45
00:03:47,440 --> 00:03:52,080
Someone have a couple closing thoughts and kind of fire away on a couple of ideas. I'll give you a

46
00:03:52,080 --> 00:03:56,140
little trigger warning here. If you think at the end I've got a solution for this, I do not. I'm a

47
00:03:56,160 --> 00:04:01,980
smart guy. I like that. I tend to want to provide a solution, provide a problem, talk about the

48
00:04:01,980 --> 00:04:07,360
problem space and then show up with a solution. I'm not smart enough apparently because I've been

49
00:04:07,360 --> 00:04:11,160
racking my brain, I've been talking to a lot of other really smart people and nobody that I've

50
00:04:11,160 --> 00:04:15,520
talked to has a good solution for this. So the issue. Why are we even having the talk in the

51
00:04:15,520 --> 00:04:21,400
first place? The start of this is that Symantec, their subordinate CAs, Symantec and or their

52
00:04:21,400 --> 00:04:26,060
subordinate CAs, they misissued a number of certificates. And originally the

53
00:04:26,160 --> 00:04:30,520
number was found through an audit and originally it was about 12 certificates and now we know

54
00:04:30,520 --> 00:04:37,340
that it's somewhere on the order of 30,000 certificates. And part of the problem that Google

55
00:04:37,340 --> 00:04:43,660
had was that over time the number kept growing and growing and growing and there were addendums

56
00:04:43,660 --> 00:04:50,520
upon addendums upon addendums to the final report. Obviously this is never a good thing. You

57
00:04:50,520 --> 00:04:55,460
have a final report and again we're not talking about a final report. We all work in InfoSec I

58
00:04:55,460 --> 00:05:00,860
presume most of you work in InfoSec somewhere. And you know that when you perform an audit, for

59
00:05:00,860 --> 00:05:06,600
goodness sakes, there's always data that skeletons in the closet, stuff that was swept under the

60
00:05:06,600 --> 00:05:11,760
rug, stuff that you find during an audit that you didn't find otherwise. But it's rare that I

61
00:05:11,760 --> 00:05:16,780
ever go back and I have to issue an addendum to my final report and it's rare that I have to issue

62
00:05:16,780 --> 00:05:21,100
an addendum to the addendum to the final report and I've never issued an addendum to the

63
00:05:21,100 --> 00:05:24,880
addendum to the addendum to the final report which is what Symantec continued to do here.

64
00:05:25,960 --> 00:05:33,200
Separately from this, this is not a regular audit. Part of this key here is that when you operate a

65
00:05:33,200 --> 00:05:38,960
certificate authority, you are bound by a number of regulations to track data. This would be like

66
00:05:38,960 --> 00:05:43,200
going into a bank audit and asking them, for instance, how much money is in the vault and

67
00:05:43,200 --> 00:05:49,540
they're like, hold on a second while we go count that stuff. That's not okay. And it's not okay

68
00:05:49,540 --> 00:05:55,280
here either. We're talking about the web of trust for the entire Internet. What else? Symantec failed to

69
00:05:55,460 --> 00:06:00,100
track the activities of its affiliated CAs and the really cool part here is if you read into this or

70
00:06:00,100 --> 00:06:05,800
read through this a little bit, they have this geo, basically this geo trust or geo root

71
00:06:05,800 --> 00:06:12,120
initiative and basically in this geo root initiative, they are signing basically certificates

72
00:06:12,520 --> 00:06:17,780
for what they call registration authorities, RAs. And these RAs, basically their job is to

73
00:06:17,780 --> 00:06:22,540
validate that you are who you say you are. So picture for a moment you have this whole proxy

74
00:06:22,540 --> 00:06:25,440
arrangement, right? I can vouch for you. I can vouch for you. I can vouch for you. I can vouch for

75
00:06:25,460 --> 00:06:30,020
you. But I might vouch for you without even knowing you and it's the registration authority

76
00:06:30,540 --> 00:06:35,240
that's actually validating that you are who you say you are and they say, hey, Jake. Of course I

77
00:06:35,240 --> 00:06:39,620
know this person. I say, hey, Jake, go vouch for this guy and I just do it. Now here's where

78
00:06:39,620 --> 00:06:44,480
things get interesting because over the years Symantec has bought a lot of RAs. They've bought a

79
00:06:44,480 --> 00:06:50,000
lot of other certificate authorities. VeriSign, for instance, is one that they bought. Thought is

80
00:06:50,000 --> 00:06:54,120
another one that they bought that used to be just absolutely huge, right? What's really, really

81
00:06:55,460 --> 00:07:01,720
interesting is that Symantec in one of their audits failed to disclose one of their

82
00:07:01,720 --> 00:07:08,200
registration agents, one of their RAs. And in the later audit they found out as Google challenged

83
00:07:08,200 --> 00:07:13,100
them and said, hey, you forgot to put this in your transparency report, they were like, that's

84
00:07:13,100 --> 00:07:18,780
not ours. And Google is like, oh, no, you're signing certs for these people. Now when you step

85
00:07:18,780 --> 00:07:24,000
back and you think how bad is this, right? Now I'm paraphrasing a lot here. Go read the docs. I

86
00:07:24,440 --> 00:07:25,440
understand. This stuff is tricky. But I think it's really interesting. And I think it's really

87
00:07:25,460 --> 00:07:29,320
dry. But it's important and it's dry. Hopefully I'll get enough out there that you can speak

88
00:07:29,320 --> 00:07:33,720
intelligently to this anyway. Symantec cross signed a root certificate used by the U.S. federal

89
00:07:33,720 --> 00:07:38,560
government. And look, initially this is probably not bad if you live in the U.S. and 100% trust

90
00:07:38,560 --> 00:07:43,840
the U.S. government. Of course I do. Right? I mean, I live in the U.S. and I don't trust the U.S.

91
00:07:43,840 --> 00:07:48,240
government. It's ridiculous, right? Symantec issued test certificates and certs for unregistered

92
00:07:48,240 --> 00:07:54,260
domains. Now some folks, and particularly Symantec, have tried to move the narrative along that

93
00:07:55,460 --> 00:08:00,980
one of the reasons Google is so mad about this is that one of the test certificates that they

94
00:08:00,980 --> 00:08:07,000
issued, I don't even know what a test certificate, well, what Symantec says a test certificate is, is

95
00:08:07,000 --> 00:08:11,920
a certificate they legitimately signed for a domain that they do not own that they use for

96
00:08:11,920 --> 00:08:18,200
testing. One of them that they signed was for Google. And you can imagine this made Google a

97
00:08:18,200 --> 00:08:25,240
little annoyed because what would one do with this? Who the knows, right? And so they, now

98
00:08:25,240 --> 00:08:29,620
Symantec comes back and says, look, these certs never, ever made it out of the wild and yet Google

99
00:08:29,620 --> 00:08:36,640
figured it out. So anyway, there's like some interesting crosstalk going on there and some, I

100
00:08:36,640 --> 00:08:42,180
will tell you that as you read this, you cannot come, as a rational person, as a rational analyst,

101
00:08:42,320 --> 00:08:47,540
you cannot come to any other conclusion reading Symantec's responses than they were 100% asleep at

102
00:08:47,540 --> 00:08:52,700
the wheel. And rather than saying, hey, guys, we were asleep at the wheel, we don't know what we're

103
00:08:52,700 --> 00:08:55,220
going to do now. Help us out. At every turn, we're going to have to move the narrative around. And

104
00:08:55,240 --> 00:08:59,520
in turn, they deny, deny, deny. It's like watching politicians debate. It's absolutely nuts.

105
00:09:00,400 --> 00:09:06,120
So our CA is officially too big to fail. Look, the issues with Symantec were serious. Google

106
00:09:06,120 --> 00:09:10,180
earlier dumped WoSign and StartCom. They said, look, we're not going to trust these guys

107
00:09:10,180 --> 00:09:14,280
anymore. And they gave us about a month to knock this stuff out, a month and a half to knock out

108
00:09:14,800 --> 00:09:20,400
WoSign and StartCom. Admittedly, WoSign and StartCom are relatively small. And if you read the

109
00:09:20,400 --> 00:09:25,180
Google document, basically from Chrome or the Chrome team basically saying that they're ready to

110
00:09:25,180 --> 00:09:29,720
dump support for Symantec, but we're going to phase it out over a period of more than a year,

111
00:09:30,320 --> 00:09:35,620
you can see throughout that they talk about how big Symantec is, what the impact is going to be if

112
00:09:35,620 --> 00:09:43,580
they just go bam and drop it. And I step back and I have to say, look, Symantec is apparently too

113
00:09:43,580 --> 00:09:48,480
big to fail in the context of, in the context at least as far as Google and then Mozilla, which is

114
00:09:48,480 --> 00:09:54,060
following suit with Google, is concerned. I think this is a big issue because if it's a security

115
00:09:54,060 --> 00:10:01,220
issue, it's a security issue no matter how big the CA is. I might actually argue that if the CA is

116
00:10:01,220 --> 00:10:06,340
that large, the certificate authority is that large, the security issue is actually more serious

117
00:10:06,340 --> 00:10:11,180
because they're signing more certificates. And hence, we need to be ready to move faster with

118
00:10:11,180 --> 00:10:15,920
large certificate authorities than we need to with small certificate authorities that sign a very,

119
00:10:16,040 --> 00:10:22,400
very small number of certs. I'll finally say that InfoSec, as we're talking about this, when I do

120
00:10:22,400 --> 00:10:24,040
security audits and I'm looking at different types of security audits and I'm looking at different

121
00:10:24,060 --> 00:10:30,180
best practices for organizations, I rate organizations that, let's say, have a $10 billion

122
00:10:30,180 --> 00:10:35,380
a year market cap differently than somebody that has a $2 billion a year market cap. You have a

123
00:10:35,380 --> 00:10:41,420
different level of resources. Here, Symantec, my friends, has no excuse. And I'm going to be very

124
00:10:41,420 --> 00:10:45,700
careful so I don't get sued because I'm sure there's someone from Symantec in here taking notes

125
00:10:45,700 --> 00:10:51,300
and ready to go. That's cool, no problem. But look, the originally proposed solution, basically,

126
00:10:52,940 --> 00:10:54,040
there was the, there was a, there was a, there was a, there was a, there was a, there was a, there

127
00:10:54,060 --> 00:10:59,600
was the goal to go phase out over a number of releases and basically phase out trust for the

128
00:10:59,600 --> 00:11:05,620
Symantec certs that were signed during what we'll call the trouble period. So by the beginning of

129
00:11:05,620 --> 00:11:11,460
the year, by about February, it seems, at least, and there's some missing transparency, I think,

130
00:11:11,480 --> 00:11:17,200
here from Google as well as Symantec, but it seems that everybody's confident that whatever the

131
00:11:17,200 --> 00:11:22,640
issues were, well, not whatever they were, but among the many, many issues, and I don't have all

132
00:11:22,640 --> 00:11:24,040
of them listed on the original slide. There's a lot of them listed on the original slide that I'm

133
00:11:24,040 --> 00:11:28,980
there. There are many, many more. Those are the most serious. Based on the many issues that they

134
00:11:28,980 --> 00:11:35,560
found, they said, hey, we think we're good going forward, but that leaves us in a position where,

135
00:11:35,640 --> 00:11:41,000
during the trouble period, we know we misissued around 30,000 certs. Well, at the time, it was 100

136
00:11:41,000 --> 00:11:46,760
certs and then it was many certs and then it eventually was 30,000 certs. And so the question

137
00:11:46,760 --> 00:11:51,580
then becomes, what do you do with those? Because some of those have lifetimes of five years easily.

138
00:11:51,820 --> 00:11:54,020
All right? You can go in and you can select if you're going to go in and you can select if you're

139
00:11:54,040 --> 00:11:58,240
willing to pay the $15 a year or whatever it happens to be, depending on who your reseller is.

140
00:11:58,740 --> 00:12:03,060
You can go ahead and pay that and you can get a ridiculously long certificate life. Should you do

141
00:12:03,060 --> 00:12:07,640
that? That's a whole different security question, whole different security discussion. Google

142
00:12:07,640 --> 00:12:12,240
appeared to be interested then in, even as they reissued certs, they wanted to lower the

143
00:12:12,240 --> 00:12:18,660
validity. Symantec came back and said, look, this is punitive because nobody else is going to be

144
00:12:18,660 --> 00:12:23,460
bound by these timelines. And they're right. Google, to their credit, came back and said, hey,

145
00:12:24,040 --> 00:12:32,100
we get it, totally, but you guys have been negligent, I think, as well. Wait, wait, wait. If

146
00:12:32,100 --> 00:12:37,480
there's a lawyer in the crowd for Symantec, I didn't use the word negligent. I was paraphrasing

147
00:12:37,480 --> 00:12:43,860
there. Maybe negligent isn't the word. You have been demonstrably careless in, that sounds

148
00:12:43,860 --> 00:12:49,380
better. I'm not a lawyer, but mine reviewed this talk. So anyway, so the basically

149
00:12:49,380 --> 00:12:54,000
demonstrably careless in doing this, we think you're going to do it again. Kind of like I've

150
00:12:54,040 --> 00:12:57,440
got a dieting problem, I ate too many cookies, and odds are good I'm going to do it tonight,

151
00:12:57,580 --> 00:13:03,400
too. So look, seriously, that kind of thing going. And so they drop this down, and they say,

152
00:13:03,460 --> 00:13:08,040
look, you know, consistently you're going to have lower and lower validity periods here, and

153
00:13:08,040 --> 00:13:12,020
you're going to have to live with that. Symantec then says, look, we've got predatory vendors

154
00:13:12,420 --> 00:13:18,420
jumping up and down, basically contacting customers, and look, if I'm a vendor, I totally

155
00:13:18,420 --> 00:13:23,580
would be doing this. If I'm an SSL vendor, I would totally be contacting Symantec customers for

156
00:13:23,580 --> 00:13:29,380
two reasons. One, the majority of Symantec customers have no idea this is going on, or very

157
00:13:29,380 --> 00:13:34,860
limited idea this is going on, at least initially. And to be fair, if the proposed solution

158
00:13:34,860 --> 00:13:39,440
rolls through, it's going to be difficult for you to, more difficult for you to stay with

159
00:13:39,440 --> 00:13:44,660
Symantec than it is to go with literally anybody else. And if I'm a vendor, that seems like a

160
00:13:44,660 --> 00:13:50,420
really good market differentiation, and I would totally be pitching that to people there. Look,

161
00:13:50,460 --> 00:13:53,560
this is either dirty pool or good business, depending on where you sit and the kind of

162
00:13:53,580 --> 00:13:58,720
how you feel, and I don't know, if I'm Symantec, I call foul. If I'm every other vendor, I'm

163
00:13:58,720 --> 00:14:03,360
like, heck yeah, I'm totally getting in on that game. Regardless, know that it happened, know

164
00:14:03,360 --> 00:14:08,980
that it's still happening because the proposed solution, proposed now, new proposed solution was

165
00:14:08,980 --> 00:14:15,700
just ratified this week. So know that it's nowhere near done, and I would still expect other

166
00:14:15,700 --> 00:14:20,400
vendors to capitalize on this and try to capitalize it. If you are a Symantec customer, be

167
00:14:20,400 --> 00:14:23,560
very, very careful about what you do next. Make a good investment. If you are a Symantec

168
00:14:23,580 --> 00:14:28,000
customer, make an informed decision. My personal take, and I'll go ahead and, in case anybody

169
00:14:28,000 --> 00:14:32,820
needs to cut out quickly, and you are a Symantec customer, my personal take is I just wouldn't

170
00:14:32,820 --> 00:14:37,080
continue with them. And this has nothing to do with whether or not I believe they're doing good

171
00:14:37,080 --> 00:14:40,860
CA work today. My honest to goodness opinion there is no, they're not, but that's a whole

172
00:14:40,860 --> 00:14:48,460
separate issue. The reality is that they're already on probation, right? And I feel like

173
00:14:48,460 --> 00:14:53,340
everything else that happens from here is probably going to be viewed with a, or a

174
00:14:53,340 --> 00:14:57,920
responded to basically with a sledgehammer rather than a coddling like they've had so far.

175
00:14:59,160 --> 00:15:02,720
Regardless, just so you know what's happening, let's talk about the cross signed federal route

176
00:15:02,720 --> 00:15:06,380
because this is cool. I like this, right? Well, no, actually I don't like this at all, but

177
00:15:06,380 --> 00:15:11,020
Symantec cross signed a bridge certificate for the U.S. federal government. So the period of

178
00:15:11,020 --> 00:15:16,100
nearly five years, by the way, Symantec, when they sign a route, this is not a certificate that

179
00:15:16,100 --> 00:15:20,880
they sign. I want to be very clear about this so everybody understands this. It's not a regular

180
00:15:20,880 --> 00:15:23,320
certificate. It's not like they have for DOJ.gov. It's not like they have for DOJ.gov,

181
00:15:23,340 --> 00:15:27,640
they signed a certificate so you go to the website and get a little trusted icon there. They

182
00:15:27,640 --> 00:15:33,600
signed a route for the federal government. Cross signed a route for the federal government and

183
00:15:33,600 --> 00:15:40,220
failed to report it. Now, any CA that's trusted is required, absolutely required by the CA

184
00:15:40,220 --> 00:15:44,660
standards, by the browser alliance. Actually, that sounds like the force or something, but you

185
00:15:44,660 --> 00:15:51,720
get the idea there, right? So Mozilla, Opera, or Mozilla, Apple, Google, and Microsoft to

186
00:15:51,720 --> 00:15:53,240
report when they sign new routes.

187
00:15:53,340 --> 00:15:59,200
They signed a route for the federal government, for the U.S. federal government. And this

188
00:15:59,200 --> 00:16:06,220
certificate could be used without any further interaction from Symantec to sign certificates for

189
00:16:06,220 --> 00:16:13,800
anything. And you have to understand the severity of that. Because as much as I trust the federal

190
00:16:13,800 --> 00:16:18,620
government in the U.S., right, I think looking out here, the majority of you are probably from the

191
00:16:18,620 --> 00:16:23,320
U.S. That's fine. Step back and ask yourself, what would you be doing if you were to sign a route for

192
00:16:23,340 --> 00:16:29,980
anything if this was China? If Symantec had signed a bridge certificate for China, how would you

193
00:16:29,980 --> 00:16:38,700
feel about that? Well, so hold on a second. China has roots. The Chinese government doesn't

194
00:16:38,700 --> 00:16:44,580
have. Now you're arguing with me about is it China? Now, I'm getting there. So you're jumping ahead

195
00:16:44,580 --> 00:16:49,800
with me here. So, okay, look. If it was the Chinese government or the Somali government, they

196
00:16:49,800 --> 00:16:53,320
don't have a CA. The Somali government were owned a. . .

197
00:16:53,340 --> 00:16:58,080
And then we had certificate pirates running around. Sounds actually like a new whiskey pirates

198
00:16:58,080 --> 00:17:03,320
kind of thing. But regardless, look, bottom line, try not to put your tinfoil hats on here, but this

199
00:17:03,320 --> 00:17:08,300
is serious because we're talking about the same government that oversees NSA, CIA, and lots of

200
00:17:08,300 --> 00:17:14,360
organizations you probably don't trust. And when I step back and ask, realistically, if you got

201
00:17:14,360 --> 00:17:21,560
redirected to a website that now had a brand-new certificate signed by a trusted CA, would you know?

202
00:17:23,340 --> 00:17:26,760
Well, that's like one guy that would know because he constantly is looking at certs and doing

203
00:17:26,760 --> 00:17:32,140
research on certs. And that's like the one guy, I.E. Brotherson. And that's about it. I can't

204
00:17:32,140 --> 00:17:36,040
imagine any. . . I wouldn't notice. I'll be the first to tell you. Most of our organizations

205
00:17:36,040 --> 00:17:42,700
wouldn't notice either. And these can facilitate man-in-the-middle attacks. And so once the

206
00:17:42,700 --> 00:17:46,520
transgression was discovered, and again, this is important to know this ran for five years, and

207
00:17:46,520 --> 00:17:52,200
once it was discovered, they didn't fix it. They waited. And they went back and forth about like

208
00:17:52,200 --> 00:17:53,320
the, hey, we're working on this. . . . . . . . . . . . . . . . . . . .

209
00:17:53,340 --> 00:17:56,400
. . . what? I thought nobody planned on revoking this. This is too easy. It's literally, you

210
00:17:56,400 --> 00:18:01,600
just revoke it. There's a process in place for this. It's called CRL. It took them five months to

211
00:18:01,600 --> 00:18:07,380
correct the issue. I have a couple of ideas. Why did it happen. General laziness? I don't know.

212
00:18:07,800 --> 00:18:12,080
Give it to Fed's time to react to a PKI, change. I don't know why this is necessary in the first

213
00:18:12,080 --> 00:18:17,240
place. The federal government on the browsers that they are, sorry, sorry on the sites they use,

214
00:18:17,380 --> 00:18:22,340
they issue their own certs, anyway. If you've ever been in the military or worked with any of

215
00:18:22,340 --> 00:18:25,140
of those folks, you know you have to go install root, which is

216
00:18:25,140 --> 00:18:27,800
weird anyway, but you got to go install the root. They didn't

217
00:18:27,800 --> 00:18:30,920
need to deal with this. Give the feds time to react to the PKI

218
00:18:30,920 --> 00:18:33,580
change. Maybe Symantec doesn't want to be a CA and the five

219
00:18:33,580 --> 00:18:38,960
months seemed like a great way to bridge that. It's kind of like

220
00:18:38,960 --> 00:18:41,680
a polite no-bid. Somebody comes up, asks you to work a job and

221
00:18:41,680 --> 00:18:45,160
your normal rate is here and you're like, I'm going to go bid

222
00:18:45,160 --> 00:18:48,220
it way up here. You don't want to tell them no, but maybe

223
00:18:48,220 --> 00:18:50,700
Symantec is like that. They're like, we're done with the CA

224
00:18:50,700 --> 00:18:53,720
business, but I'm going to piss off all our customers, so we'll

225
00:18:53,720 --> 00:18:58,860
just get beat down. I don't know. Or possibly it's to give

226
00:18:58,860 --> 00:19:03,380
feds time to abuse the soon to be lost capability. And I'm not

227
00:19:03,380 --> 00:19:05,700
going to tell you which one I think it is, because I don't

228
00:19:05,700 --> 00:19:11,320
want to put a tin foil hat on up here. But if you knew you had a

229
00:19:11,320 --> 00:19:14,260
capability and you had a very, very limited time left to use

230
00:19:14,260 --> 00:19:18,700
it, what would you do with it? Anyway. The issue with test

231
00:19:18,700 --> 00:19:20,680
certificates. So Symantec issued me a test certificate.

232
00:19:20,700 --> 00:19:22,820
They issued test certificates for legitimate in the wild

233
00:19:22,820 --> 00:19:26,100
domains. They also did it for thousands of domains that were

234
00:19:26,100 --> 00:19:30,520
unregistered. And this is a huge separate issue. Because if I'm

235
00:19:30,520 --> 00:19:34,720
able to get a cert for a site that you may register later, or

236
00:19:34,720 --> 00:19:37,060
domain that you may register later, and then I already have

237
00:19:37,060 --> 00:19:39,980
the valid cert, you can see I could be abused for man in the

238
00:19:39,980 --> 00:19:42,020
middle activity. I might actually have a cert for a

239
00:19:42,520 --> 00:19:44,680
domain that you own and you don't have any cert for the

240
00:19:44,680 --> 00:19:49,180
domain. Imagine that. That's wow. Symantec says these test

241
00:19:49,180 --> 00:19:50,680
certificates were never actively in use because they were not

242
00:19:50,700 --> 00:19:52,560
in use. Google, of course, was able to discover it. There's no

243
00:19:52,560 --> 00:19:55,600
legitimate purpose for this. And particularly for a site as big as

244
00:19:55,600 --> 00:19:58,920
Google.com. There's no legitimate use for this. There's

245
00:19:58,920 --> 00:20:01,500
no legitimate use for this. By the way, I feel it's probably

246
00:20:01,500 --> 00:20:05,240
appropriate to mention that Symantec, the owner of a very,

247
00:20:05,340 --> 00:20:08,840
very large root CA who has cross signed certificates against

248
00:20:08,840 --> 00:20:12,700
guidance without reporting previously, now also owns some

249
00:20:12,700 --> 00:20:16,360
very interesting HTTPS interception software stuff.

250
00:20:16,720 --> 00:20:19,320
Anyway, I'll just throw that out there. I think they reached a

251
00:20:19,320 --> 00:20:20,680
deal with Blue Coat last year. I think they reached a deal with

252
00:20:20,700 --> 00:20:25,180
Blue Coat last year. Wow. Gosh. That just hit me. Anyway. So

253
00:20:25,920 --> 00:20:31,200
improperly revoking certificates. So Symantec, even though these

254
00:20:31,200 --> 00:20:34,980
weren't related to Google, Symantec this month, so I want

255
00:20:34,980 --> 00:20:37,920
to put this in perspective. Because if you don't already

256
00:20:37,920 --> 00:20:41,360
feel like Symantec is a dumpster fire, and again, lawyer

257
00:20:41,360 --> 00:20:45,600
in the room, I know you're here. I know you're here. I'm not

258
00:20:45,600 --> 00:20:47,860
calling Symantec a dumpster fire. I'm just saying if these

259
00:20:47,860 --> 00:20:50,620
people aren't convinced that it's a dumpster fire, by now,

260
00:20:50,700 --> 00:20:53,900
maybe this will convince you. Because while Symantec's already

261
00:20:53,900 --> 00:20:57,760
on probation, because this whole thing kicks off in February, in

262
00:20:57,760 --> 00:21:01,820
early July, a gentleman named Hanno Bock, I think Bock. I

263
00:21:01,820 --> 00:21:04,680
don't know. It sounds German. Anyway, he went and bought some

264
00:21:04,680 --> 00:21:07,100
certificates for a couple of domains that he owns. He went

265
00:21:07,100 --> 00:21:10,500
out and registered a couple of crazy named domains and then went

266
00:21:10,500 --> 00:21:14,040
and bought some certificates. And so there are four domains

267
00:21:14,040 --> 00:21:16,420
that he owns. And he bought some through Symantec and he bought

268
00:21:16,420 --> 00:21:20,380
some through Komodo. And I think there was one other registrant,

269
00:21:20,700 --> 00:21:23,660
one other certificate provider he bought them through. And then

270
00:21:23,660 --> 00:21:27,600
he did something cool. He went and he revoked the certificate.

271
00:21:27,860 --> 00:21:31,240
He said, hey, my keys have been compromised. I need you to

272
00:21:31,240 --> 00:21:33,420
revoke the certificate. He used a different e-mail to contact

273
00:21:33,420 --> 00:21:37,700
them. Basically said, hey, here's my private keys. I need

274
00:21:37,700 --> 00:21:39,660
you to revoke these because they've been compromised. Now,

275
00:21:39,660 --> 00:21:42,900
a CA, according to the browser alliance, has 24 hours upon

276
00:21:42,900 --> 00:21:45,920
notification of compromise of a private key to revoke the

277
00:21:45,920 --> 00:21:50,620
certificate. The kicker is they're supposed to validate the

278
00:21:50,700 --> 00:21:55,260
private key. And see if you can figure out where this is going.

279
00:21:57,580 --> 00:22:01,280
Oh. Oh, sorry. A gap was identified. This is Symantec's

280
00:22:01,280 --> 00:22:03,340
response. A gap was identified in the public and private key

281
00:22:03,340 --> 00:22:06,540
matching process, also known as we forgot to validate the key.

282
00:22:07,480 --> 00:22:11,800
And what this means is that while Symantec is unaware of

283
00:22:11,800 --> 00:22:17,140
anybody having done this in the wild, that up until mid-July, up

284
00:22:17,140 --> 00:22:20,680
until two weeks ago, you could have sent them something that

285
00:22:20,700 --> 00:22:24,160
had some random binary string and said, hey, this is the

286
00:22:24,160 --> 00:22:28,020
private key for blah domain. It's been compromised. I need you

287
00:22:28,020 --> 00:22:31,960
to revoke the cert. Now, there's math that you can do to validate

288
00:22:31,960 --> 00:22:34,400
this. Symantec knows all about this. That's how they create the

289
00:22:34,400 --> 00:22:36,440
certs in the first place. I presume they know about this.

290
00:22:36,520 --> 00:22:38,800
That's how they create the certs. Actually, you know what?

291
00:22:38,820 --> 00:22:41,260
Forget it. I don't even presume they know this anymore. But,

292
00:22:41,760 --> 00:22:44,240
look, that's how they create the certs in the first place. And

293
00:22:44,240 --> 00:22:47,080
you can mathematically validate that this private key is the

294
00:22:47,080 --> 00:22:50,680
real private key. And so picture the power that you have when you

295
00:22:50,680 --> 00:22:55,860
had in your hands to shut down operations. Because suppose for a

296
00:22:55,860 --> 00:22:58,880
minute that we take a large provider like Amazon or

297
00:22:58,880 --> 00:23:02,140
something and we go and validate their cert, their private key,

298
00:23:02,200 --> 00:23:05,420
do it a private key compromise. Now, I think Symantec would have

299
00:23:05,420 --> 00:23:07,480
been smarter not to do it for Symantec, but you can picture

300
00:23:07,480 --> 00:23:10,220
other, or sorry, Symantec wouldn't do it for Amazon. They

301
00:23:10,220 --> 00:23:12,380
seem pretty big. Seems like somebody might have gone,

302
00:23:12,500 --> 00:23:15,440
really? Amazon? Seriously? They don't want a key reissue or

303
00:23:15,440 --> 00:23:19,260
anything? I think they'd have been smarter to see that, right?

304
00:23:19,320 --> 00:23:20,660
But there are some mid-range things that you can do to

305
00:23:20,680 --> 00:23:22,720
manage sites that I think you could do some really serious

306
00:23:22,720 --> 00:23:26,200
damage with here. Obviously nobody has gone back and tested

307
00:23:26,200 --> 00:23:29,060
this again. I'm not encouraging you to test it again because it

308
00:23:29,060 --> 00:23:32,240
sounds all like fraudulent activity to me. But if you're

309
00:23:32,240 --> 00:23:37,160
so inclined, who am I to stop you? So, no joke, though, by the

310
00:23:37,160 --> 00:23:40,540
way, this is a neat attack vector. And it's something that

311
00:23:40,540 --> 00:23:44,280
you ought to try with whoever, wait, you should talk to your

312
00:23:44,280 --> 00:23:47,640
general counsel and then you should try this with whoever

313
00:23:47,640 --> 00:23:50,660
your SSL providers are. Because this is something that you should

314
00:23:50,680 --> 00:23:53,800
be serious because once they revoke the cert, everybody gets an

315
00:23:53,800 --> 00:23:56,560
SSL warning, you know, this is a brand damage issue or possibly a

316
00:23:56,560 --> 00:23:59,320
business loss issue. So, again, it's something that you should

317
00:23:59,320 --> 00:24:01,640
check, something you should know. So I want to talk about

318
00:24:01,640 --> 00:24:04,040
trust issues because I have lots of trust issues. This gentleman

319
00:24:04,040 --> 00:24:07,320
in the front row does as well. And I want to talk about who is

320
00:24:07,320 --> 00:24:11,040
your browser trusting anyway? Because the entire SSL model is

321
00:24:11,040 --> 00:24:15,880
based on trust in a lot of certs that I think if you looked at the

322
00:24:15,880 --> 00:24:20,140
people who own those certs, I think you would look and go, for

323
00:24:20,680 --> 00:24:23,100
instance, and I want to put this into perspective, when I consult

324
00:24:23,100 --> 00:24:26,540
with clients, and feel free to steal my analogies here, when I

325
00:24:26,540 --> 00:24:30,360
consult with clients, I open up the list, we talk about this a

326
00:24:30,360 --> 00:24:33,580
lot for the browser trust, and we open up the list of

327
00:24:33,580 --> 00:24:37,820
certificates and we look in Firefox and we look in Chrome and

328
00:24:37,820 --> 00:24:44,180
we just say, look, would you hand them $1,000 and trust that

329
00:24:44,180 --> 00:24:46,420
in six months you're going to get it back? And they're like, no, I

330
00:24:46,420 --> 00:24:49,940
wouldn't. I'm like, good. Then pull trust. Because what you're

331
00:24:49,940 --> 00:24:50,660
asking for is trust. And I'm like, no, I wouldn't. I'm like,

332
00:24:50,680 --> 00:24:52,540
no, I wouldn't. There is something way worse than that.

333
00:24:52,940 --> 00:24:56,560
You are asserting that these people can sign trusted

334
00:24:56,560 --> 00:25:01,000
certificates for literally anything. Many nation states, as

335
00:25:01,000 --> 00:25:04,000
this gentleman correctly pointed out, have virtual control over

336
00:25:04,000 --> 00:25:06,720
businesses operating on their borders. This does not align

337
00:25:06,720 --> 00:25:09,660
well with very complex threat models that most organizations

338
00:25:09,660 --> 00:25:12,980
have. Now, I know what you're thinking. If you're a Chinese

339
00:25:12,980 --> 00:25:15,940
telecom, I'm just going to use China as an example, because

340
00:25:15,940 --> 00:25:18,480
it's always China. Actually, recently it's been always Russia,

341
00:25:18,560 --> 00:25:20,660
but whatever. Chinese telecom, I'm going to use China as an

342
00:25:20,660 --> 00:25:22,340
example. If you're a Chinese telecom and you go sign a

343
00:25:22,340 --> 00:25:25,140
certificate, how does my traffic, if I'm just a U.S.

344
00:25:25,160 --> 00:25:28,980
company, how does it even get there in the first place? Before

345
00:25:28,980 --> 00:25:31,220
we talk about that, let's talk about a couple of concerning

346
00:25:31,220 --> 00:25:34,840
ones, because Hong Kong Post does not look like somebody that I

347
00:25:34,840 --> 00:25:38,900
want to have. Why does the Hong Kong Post Office operate a C.A.

348
00:25:38,980 --> 00:25:41,740
that Firefox in the United States trusts? And is this

349
00:25:41,740 --> 00:25:44,720
necessary? And should you leave this talk and remove this from

350
00:25:44,720 --> 00:25:48,280
your browser for your set of accepted certificates? Right?

351
00:25:48,440 --> 00:25:50,640
Totally. And I feel fine saying that. I don't think it's a good

352
00:25:50,640 --> 00:25:52,660
idea. If there's a lawyer from the Hong Kong Post in here, game

353
00:25:52,660 --> 00:25:58,020
on, right? So, look, I'm just not down with this. Is it being

354
00:25:58,020 --> 00:26:01,340
used? Yeah, absolutely. 38 of the top 1 million sites are

355
00:26:01,340 --> 00:26:04,180
secured with these. That's not the issue. If you're looking at

356
00:26:04,180 --> 00:26:07,560
that and you're hearing only 38 and 1, that's not the issue.

357
00:26:07,720 --> 00:26:10,260
It's not that it's 38 and 1 million. They can sign certs for

358
00:26:10,260 --> 00:26:14,380
anybody. That's the whole point of the trust, right? You are

359
00:26:14,380 --> 00:26:18,560
trusting them to sign a cert for literally anyone, right? And so,

360
00:26:18,580 --> 00:26:20,620
of course, then if we get that man in the middle, we're going

361
00:26:20,640 --> 00:26:24,300
to have a lot of trouble. Well, you get the idea. Okay. What

362
00:26:24,300 --> 00:26:28,580
about the Chung Wah Telecom in Taiwan? Right? Again, this is

363
00:26:28,580 --> 00:26:30,960
another CA trusted by Mozilla and all the major browsers.

364
00:26:32,020 --> 00:26:35,020
Microsoft actually goes a step further because they're cool and

365
00:26:35,020 --> 00:26:37,820
they trust the China Financial Certification Authority, the

366
00:26:37,820 --> 00:26:40,460
CFCA. I don't even know who these people are, but they sound

367
00:26:40,460 --> 00:26:44,340
bad. And I don't mean bad from a I don't like China, just China is

368
00:26:44,340 --> 00:26:47,440
part of my threat model because like half the intrusions I do

369
00:26:47,440 --> 00:26:50,620
are China, right? And it's just a reality. I operate here and I

370
00:26:50,640 --> 00:26:53,740
operate in Southeast Asia where, as you can imagine, China has

371
00:26:53,740 --> 00:26:57,200
got a lot of vested interest in what's going on. And, yeah, I

372
00:26:57,200 --> 00:27:01,160
mean, so is it fear mongering, right? No. No, this isn't fear

373
00:27:01,160 --> 00:27:03,820
mongering. People have accused me of this. It's definitely not.

374
00:27:04,220 --> 00:27:06,600
I'm a low FUD, fear, uncertainty, and doubt kind of

375
00:27:06,600 --> 00:27:09,860
person. You combine this trusted CA with the ability to do man in

376
00:27:09,860 --> 00:27:13,240
the middle. If you're in a foreign country, ISP, man in the

377
00:27:13,240 --> 00:27:15,880
middle, should definitely be a thing you are concerned with.

378
00:27:16,600 --> 00:27:20,420
DNS cache poisoning. I don't know if Dan Kaminsky is here. I haven't

379
00:27:20,420 --> 00:27:23,460
seen him tweeting yet since he's been here. If he is, don't fall

380
00:27:23,460 --> 00:27:27,260
asleep near Dan. That's a losing move. Or pass out near Dan.

381
00:27:27,360 --> 00:27:29,660
It's a losing move. Dan's an awesome guy, though. And Dan

382
00:27:29,660 --> 00:27:32,580
walked through a number of years ago DNS cache poisoning. And, of

383
00:27:32,580 --> 00:27:36,180
course, vendors rushed out to fix that over the last several

384
00:27:36,180 --> 00:27:41,860
years. And so he presented it here like in what? Was it 2008?

385
00:27:43,100 --> 00:27:45,520
2007? All right. So it's been nearly a decade since Dan

386
00:27:45,520 --> 00:27:49,320
presented how to do DNS cache poisoning. And trust me, it works.

387
00:27:50,420 --> 00:27:53,800
And so as we look at this, with DNS cache poisoning, they can

388
00:27:53,800 --> 00:27:59,180
route traffic basically from you in the U.S. out to wherever it is

389
00:27:59,180 --> 00:28:01,780
they need to. Or, realistically, they don't even need to route it

390
00:28:01,780 --> 00:28:05,640
outside of the U.S. They just pick up a server in Amazon, the

391
00:28:05,640 --> 00:28:09,400
Amazon Cloud or in Azure and throw one of their trusted certs

392
00:28:09,400 --> 00:28:12,020
there and game on. But if you want to get into the really,

393
00:28:12,100 --> 00:28:15,280
really scary stuff, take a look, my friends, at BGP hijacking.

394
00:28:16,140 --> 00:28:20,400
Because this is where stuff gets crazy scary. And you talk a

395
00:28:20,420 --> 00:28:23,940
bout the SSL trust thing being an absolute dumpster fire, BGP is

396
00:28:23,940 --> 00:28:29,060
far worse. And if you're not looking at this, go take a look.

397
00:28:29,260 --> 00:28:31,440
I don't know how I missed the E there. That's probably the

398
00:28:31,440 --> 00:28:38,300
British spelling. Anyway, BGP route hijacking is probably the

399
00:28:38,300 --> 00:28:41,860
easiest of these to track. If you're not following BGP stream

400
00:28:41,860 --> 00:28:44,760
on Twitter, go check this out. It is an absolutely awesome

401
00:28:44,760 --> 00:28:48,620
account. And it tracks when somebody either intentionally or

402
00:28:48,620 --> 00:28:50,400
accidentally steals your data. So if you're not following BGP

403
00:28:50,420 --> 00:28:51,860
rules, it just automatically steals prefixes in the BGP

404
00:28:51,860 --> 00:28:55,660
system. Basically when some router somewhere says, oh, hey,

405
00:28:55,760 --> 00:28:59,440
I own these, go and route that stuff over here. Sometimes I'm

406
00:28:59,440 --> 00:29:05,380
sure that's a mistype. Sometimes I'm sure that's an actual error.

407
00:29:05,640 --> 00:29:08,500
It's not a typo. Just a flat out error. And typos happen.

408
00:29:08,700 --> 00:29:11,680
Right? Amazon took down a big chunk of S3 earlier this year

409
00:29:11,680 --> 00:29:16,660
with a typo. That was obviously them having a typo. But there's

410
00:29:16,660 --> 00:29:19,400
also some really interesting stuff. We saw all the traffic in

411
00:29:19,400 --> 00:29:22,900
Europe. Germany is a big fiber switching hub. We saw basically

412
00:29:22,900 --> 00:29:24,840
all the traffic that goes through the route through St.

413
00:29:24,880 --> 00:29:27,900
Petersburg for about an hour earlier this year. That was just

414
00:29:27,900 --> 00:29:31,400
accidental, I'm sure. It was no big deal. And so we've seen

415
00:29:31,400 --> 00:29:35,300
stuff route from Japan or Korea into China. We've seen a lot of

416
00:29:35,300 --> 00:29:40,080
really weird temporary disruptions in the force, if you

417
00:29:40,080 --> 00:29:43,240
will. And again, this is based on a trust model. When you

418
00:29:43,240 --> 00:29:46,720
combine this with certificate authorities, you have the

419
00:29:46,720 --> 00:29:49,380
ultimate power for man in the middle. Because a lot of our,

420
00:29:49,480 --> 00:29:52,400
when we talk about controls for this stuff, for BGP route

421
00:29:52,400 --> 00:29:55,200
hijacking, for DNS cache poisoning, it's that you don't

422
00:29:55,200 --> 00:29:59,060
own a legitimate cert. But here you do own a legitimate cert or

423
00:29:59,060 --> 00:30:02,060
the equivalent of one because, again, we're trusting some of

424
00:30:02,060 --> 00:30:04,760
the wrong people, in my opinion, to sign this. So they could

425
00:30:04,760 --> 00:30:07,380
steal secure only cookies, harvest credentials, exploit

426
00:30:07,380 --> 00:30:12,920
user trust, serve malicious updates to software. We've seen

427
00:30:12,920 --> 00:30:16,440
that recently? Yeah, we have. That's right. So look,

428
00:30:16,560 --> 00:30:16,700
technology is the ultimate power for man in the middle.

429
00:30:16,720 --> 00:30:20,980
This is where I had to rework a huge chunk of my presentation

430
00:30:21,460 --> 00:30:25,300
because freaking Google. Anyway, so they came to an agreement and

431
00:30:25,300 --> 00:30:28,780
the tentative solution says that basically, first off, it's

432
00:30:28,780 --> 00:30:31,060
important because it allows both sides to claim victory.

433
00:30:31,960 --> 00:30:35,780
Symantec can say, you didn't totally shut us down. We can

434
00:30:35,780 --> 00:30:40,900
still issue certs, sort of. And Google can say, we found issues,

435
00:30:41,120 --> 00:30:43,760
we corrected the issues, there was some punitive action taken.

436
00:30:44,480 --> 00:30:46,700
Everybody else in the room, you're definitely not going to

437
00:30:46,720 --> 00:30:49,300
get away with this. Don't try this if you're another

438
00:30:49,300 --> 00:30:52,880
certificate authority. This is ridiculous, right? They're letting

439
00:30:52,880 --> 00:30:56,440
Symantec off with at best a slap on the wrist, but game on. The

440
00:30:56,440 --> 00:30:59,060
proposed solution has three phases. First off is register a

441
00:30:59,060 --> 00:31:02,800
subordinate CA. Then there's a partial followed by a complete

442
00:31:02,800 --> 00:31:05,880
distrust of all Symantec certificates. So Symantec is

443
00:31:05,880 --> 00:31:09,000
going to partner with another CA no later than December 1, 2017.

444
00:31:09,500 --> 00:31:13,120
This original timeline, we were supposed to be done trusting

445
00:31:13,120 --> 00:31:15,720
Symantec certs. So as of February, we're supposed to be

446
00:31:15,720 --> 00:31:16,700
done by December. So we're supposed to be done by December.

447
00:31:16,720 --> 00:31:20,740
Here we've negotiated a lot. And look, over time, between

448
00:31:20,740 --> 00:31:23,920
February, or sorry, between March and now, things have only

449
00:31:23,920 --> 00:31:26,520
gotten worse, meaning we only know more and more and more

450
00:31:26,520 --> 00:31:31,540
about mis-issuance and other issues with Symantec. So the

451
00:31:31,540 --> 00:31:34,020
picture has gotten worse. And then simultaneously, we've moved

452
00:31:34,020 --> 00:31:37,240
the timeline back. And this does not sound like a winning piece

453
00:31:37,240 --> 00:31:39,800
for security. This sounds like a lot when we talk about like

454
00:31:39,800 --> 00:31:44,640
security plus and CISSP, where we've compromised basically

455
00:31:44,640 --> 00:31:46,280
convenience for security.

456
00:31:46,860 --> 00:31:49,220
And that's effectively what we've done, but cool.

457
00:31:49,740 --> 00:31:52,600
Regardless, Symantec's going to partner with another CA, and the

458
00:31:52,600 --> 00:31:55,220
subordinate CA is going to be entirely responsible for issuing

459
00:31:55,220 --> 00:31:57,920
certificates. And I do give Google mad props here, because

460
00:31:57,920 --> 00:32:01,700
they say, look, if Symantec gets out of line and starts issuing

461
00:32:01,700 --> 00:32:04,620
certificates, or if they press a button there and they issue

462
00:32:04,620 --> 00:32:08,360
certificates on your behalf, it's your butt. We'll delist you

463
00:32:08,360 --> 00:32:13,760
too. So that's good. I like that. And they basically say, hey,

464
00:32:13,780 --> 00:32:16,280
look, you're entirely accountable. Now, I don't know what

465
00:32:16,280 --> 00:32:16,700
this actually means. I don't know what this actually means, but I'm

466
00:32:16,720 --> 00:32:19,800
I say accountability for the win, but I don't know what

467
00:32:19,800 --> 00:32:22,260
accountability means in this case, because realistically,

468
00:32:23,160 --> 00:32:25,720
Symantec isn't being held accountable for this. They're

469
00:32:25,720 --> 00:32:28,560
being stripped of their ability to issue certs on their own, but

470
00:32:28,560 --> 00:32:30,940
they're being given a way out to continue making money issuing

471
00:32:30,940 --> 00:32:35,060
certificates. And I don't see this as a real punishment, you

472
00:32:35,060 --> 00:32:39,420
know, compared to, you know, compared to the crime. So, and

473
00:32:39,420 --> 00:32:42,400
by the way, lawyers, it's not a crime. It was a phrase of

474
00:32:42,400 --> 00:32:45,080
speech, right? So tentative solution phase two, partial

475
00:32:45,080 --> 00:32:46,700
distrust. April 28th, we're going to talk about the

476
00:32:46,720 --> 00:32:49,060
fact that by 2018, Symantec certificates issued before June

477
00:32:49,060 --> 00:32:52,640
1st are going to start displaying SSL errors. The

478
00:32:52,640 --> 00:32:55,280
thought is that by 2018, most of these certificates are going to

479
00:32:55,280 --> 00:32:58,080
expire anyway, and so this shouldn't be an issue. I'll

480
00:32:58,080 --> 00:33:01,360
talk a little about the reality of this a little bit later. In

481
00:33:01,360 --> 00:33:04,580
October 2018, Symantec certificates issued before

482
00:33:04,580 --> 00:33:09,860
December 1st, 2017, now will start showing SSL errors. So

483
00:33:09,860 --> 00:33:12,800
the idea here is phase one comes in, we've got the older piece,

484
00:33:12,980 --> 00:33:15,840
and then phase two comes in and we basically completely

485
00:33:16,920 --> 00:33:20,780
distrust Symantec certs, except for the ones signed by or issued

486
00:33:20,780 --> 00:33:25,120
by that new subordinate CA. So I did some analysis here, and I

487
00:33:25,120 --> 00:33:28,300
started with the Alexa top one million sites, and we went and

488
00:33:28,300 --> 00:33:31,540
retrieved SSL certificates, and we can start to look at

489
00:33:31,540 --> 00:33:34,540
certificate changes over time. We grabbed the full certificates,

490
00:33:34,740 --> 00:33:37,380
we wanted to allow the analysis of the data that we didn't think

491
00:33:37,380 --> 00:33:40,000
was relevant before, and I'm happy I did this because what I

492
00:33:40,000 --> 00:33:42,660
thought was relevant at first was not the full set of data

493
00:33:42,660 --> 00:33:45,640
that I wanted. There's a number of limitations of the

494
00:33:45,840 --> 00:33:48,180
standard approach, though. Number one is that I didn't make

495
00:33:48,180 --> 00:33:52,440
any attempts to discover HTTPS on anything but 443. So if you're

496
00:33:52,440 --> 00:33:56,240
running on some nonstandard port, I got nothing. Only HTTPS

497
00:33:56,240 --> 00:33:58,480
certs were examined. There are certainly other certs that

498
00:33:58,480 --> 00:34:02,840
exist, secure SMTP, you name it. Websites with SSL certs that

499
00:34:02,840 --> 00:34:05,820
aren't in the Alexa top one million, I know a lot of these

500
00:34:05,820 --> 00:34:09,080
exist. My mom registered something on GoDaddy recently,

501
00:34:09,260 --> 00:34:11,720
and she has an HTTPS cert. I don't have it because she's not

502
00:34:11,720 --> 00:34:13,740
in the Alexa top one million. She's not that interesting.

503
00:34:14,600 --> 00:34:15,820
Symantec is the most popular search engine in the industry.

504
00:34:15,840 --> 00:34:18,820
They're in the U.S., or is most popular in the U.S., but the

505
00:34:18,820 --> 00:34:21,380
Alexa top one million is international. And I think

506
00:34:21,380 --> 00:34:24,520
they're probably, Symantec is probably underrepresented in my

507
00:34:24,520 --> 00:34:28,800
data set, but I don't know how to fix this. So I kind of

508
00:34:28,800 --> 00:34:31,060
kicked around some ideas originally, and then we finally

509
00:34:31,060 --> 00:34:33,320
said forget it. We'll just go with what we know is an

510
00:34:33,320 --> 00:34:36,100
imperfect solution. Like all academics, document the

511
00:34:36,100 --> 00:34:40,580
limitations and go, go, go. How prevalent is SSL? Over the top

512
00:34:40,580 --> 00:34:45,820
one million, 60 percent. So 625,000 had SSL certs, and

513
00:34:45,840 --> 00:34:49,200
as of two days ago, three days ago, and we've been continuously

514
00:34:49,200 --> 00:34:52,860
updating this as we go, 112,000 of those were signed with

515
00:34:52,860 --> 00:34:56,820
Symantec certs. So originally the thought was, and I think the

516
00:34:56,820 --> 00:34:59,940
hyperbole that we saw initially was one in six certs in the

517
00:34:59,940 --> 00:35:02,860
Internet is signed by Symantec. It turns out that's actually

518
00:35:02,860 --> 00:35:08,780
close to true. And this may be the case that it's even

519
00:35:08,780 --> 00:35:11,280
disproportionately the top one million, because that's better

520
00:35:11,280 --> 00:35:14,340
than one in six. Symantec's actually not the biggest in the

521
00:35:14,340 --> 00:35:15,820
Alexa top one million. I thought it was the biggest in the Alexa

522
00:35:15,840 --> 00:35:17,420
top one million, but I thought they would be. Komodo actually

523
00:35:17,420 --> 00:35:21,000
accounts for slightly more certs, GlobalSign and GoDaddy. I

524
00:35:21,000 --> 00:35:24,980
cannot fathom getting a GoDaddy cert, but okay. I guess Danica

525
00:35:24,980 --> 00:35:28,660
Patrick comes in and signs those herself. Regardless, when we

526
00:35:28,660 --> 00:35:32,120
took a look at the web, basically Net Trust, I think, or

527
00:35:32,120 --> 00:35:35,320
NetCraft, SSL survey, you can see our numbers are kind of

528
00:35:35,320 --> 00:35:38,460
falling in line, give or take, and NetCraft doesn't use the

529
00:35:38,460 --> 00:35:41,260
Alexa top one. I mean, I'm sure they do use the Alexa top one

530
00:35:41,260 --> 00:35:43,700
million, but they've got a ton of other sites that they're

531
00:35:43,700 --> 00:35:45,820
indexing as well. Meh, I didn't know that. So we're going to

532
00:35:45,840 --> 00:35:49,100
talk about that. I didn't do that because I was lazy. But you

533
00:35:49,100 --> 00:35:51,300
can see here Symantec has a bigger slice of the pie

534
00:35:51,300 --> 00:35:54,040
according to what they're reporting than what we're

535
00:35:54,040 --> 00:35:55,960
reporting. We're showing about one in six. They're showing

536
00:35:55,960 --> 00:36:02,200
about, it looks like, one in three-ish, give or take. So we

537
00:36:02,200 --> 00:36:04,220
talk about how prevalent is Symantec and how do they break

538
00:36:04,220 --> 00:36:07,900
out, because Symantec has a lot of CAs. It's not just Symantec.

539
00:36:08,140 --> 00:36:10,700
This is one of the problems. If you take nothing else away from

540
00:36:10,700 --> 00:36:13,940
this talk, go back and talk to your business, not just your

541
00:36:13,940 --> 00:36:15,820
business, but your business partners or your business

542
00:36:15,840 --> 00:36:19,020
partners, all the people that you coordinate with. And I know

543
00:36:19,020 --> 00:36:22,380
some of you in here are working for Fortune 500s and you're

544
00:36:22,380 --> 00:36:24,460
coordinating with these little mom and pop shops. And you

545
00:36:24,460 --> 00:36:28,300
probably have this taken care of and they do not. It's your job

546
00:36:28,300 --> 00:36:33,020
as good Internet citizens and for your security to actually go

547
00:36:33,020 --> 00:36:37,060
and kind of follow up on this. Symantec operates a lot of CAs.

548
00:36:37,240 --> 00:36:40,800
It's something like 15 or 16 different CAs that we found as

549
00:36:40,800 --> 00:36:43,580
we started doing this research that are signed by Symantec

550
00:36:43,580 --> 00:36:45,820
Roots. This is a huge deal because all of them are

551
00:36:45,840 --> 00:36:49,060
going to be impacted. As we look at this, probably the

552
00:36:49,060 --> 00:36:52,720
biggest two are GeoTrust and Rapid SSL, neither of which bear

553
00:36:52,720 --> 00:36:56,320
the Symantec name directly. So there are a lot of people here.

554
00:36:56,420 --> 00:36:58,380
You can see Symantec is way down on the list. And we've

555
00:36:58,380 --> 00:37:01,580
talked to several clients who said, no problem. Thanks for

556
00:37:01,580 --> 00:37:03,880
bringing this to my attention. We don't use Symantec. And we're

557
00:37:03,880 --> 00:37:07,580
like, ha, ha, ha, ha. Actually, you do, as it turns out. And

558
00:37:07,580 --> 00:37:10,740
they're like, we use Rapid SSL. I'm like, let me explain to you

559
00:37:10,740 --> 00:37:14,220
how PKI works. Come over to the white board here real quick. And

560
00:37:14,220 --> 00:37:15,820
we kind of draw out and show them how it works. And they're

561
00:37:15,840 --> 00:37:16,980
like, oh, I'm going to show them how indeed this is signed by

562
00:37:16,980 --> 00:37:20,340
Symantec. And it is going away, too, at exactly the same pace.

563
00:37:21,520 --> 00:37:25,840
So my question, my theory here is that Google was really going

564
00:37:25,840 --> 00:37:28,540
to shake Symantec customers. Because if I'm in the Fortune

565
00:37:28,540 --> 00:37:32,820
500, if I'm in, forget Fortune 500, if I'm in any business, I'm

566
00:37:32,820 --> 00:37:35,040
not buying a Symantec cert at this point because of

567
00:37:35,040 --> 00:37:38,800
uncertainty. I don't like uncertainty. If I can go with

568
00:37:38,800 --> 00:37:41,640
somebody else that I have a good feeling about who's not already

569
00:37:41,640 --> 00:37:45,100
in the penalty box, or I can go with Symantec, I would go with

570
00:37:45,100 --> 00:37:45,820
somebody else. That's just how I feel. So, I'm not going to go

571
00:37:45,840 --> 00:37:48,820
with Symantec. It's just me. It's not advice, by the way. It's

572
00:37:48,820 --> 00:37:53,200
just me. And we did some analysis here. We did our first polls in

573
00:37:53,200 --> 00:37:58,640
the very beginning of April. We look at 112,000 as of two days

574
00:37:58,640 --> 00:38:02,980
ago. 115,000 in April. It's 2.3% market shift. And

575
00:38:02,980 --> 00:38:06,280
initially I thought, wow, that's huge, right? 2.3% of your

576
00:38:06,280 --> 00:38:09,600
business is actually pretty significant. I'm going to tell

577
00:38:09,600 --> 00:38:12,960
you that I thought it was going to be more. I thought by this

578
00:38:12,960 --> 00:38:15,760
time we'd be looking at somewhere in the 10 to 20%

579
00:38:15,840 --> 00:38:21,060
market shift, to be honest. I thought 2.3%. And it turns out I

580
00:38:21,060 --> 00:38:25,820
was extra, extra disappointed because it's not really 2.3%.

581
00:38:25,820 --> 00:38:28,240
I'll talk about that in just a second. The numbers are kind of

582
00:38:28,240 --> 00:38:30,700
lying here. I'll tell you this is less than I would have

583
00:38:30,700 --> 00:38:33,900
predicted. I don't have data on normal SSL certificate market

584
00:38:33,900 --> 00:38:37,000
shifts. I don't think anybody does. Well, some of the CAs

585
00:38:37,000 --> 00:38:40,100
probably do. But I don't know over time how do people change

586
00:38:40,100 --> 00:38:43,100
certificate authorities. I mean, the lazy thing to do is literally

587
00:38:43,100 --> 00:38:45,620
just to pay them again and get a brand-new cert issued. You don't

588
00:38:45,840 --> 00:38:48,440
change anything. It just kind of works. It's the easiest

589
00:38:48,440 --> 00:38:51,380
possible thing to do. It's why I think so many people have

590
00:38:51,380 --> 00:38:53,700
domains registered with GoDaddy. They went and they registered

591
00:38:53,700 --> 00:38:56,020
once and the easiest possible thing to do is let them charge

592
00:38:56,020 --> 00:38:59,780
their credit card again. Game on. A lot of people moved away

593
00:38:59,780 --> 00:39:03,120
from Symantec, but other people moved to Symantec. And this, my

594
00:39:03,120 --> 00:39:06,360
friends, is absolutely mind-blowing. I think, although I

595
00:39:06,360 --> 00:39:10,600
have no data to support it, this is the problem. Because the

596
00:39:10,600 --> 00:39:14,580
majority of them that moved came in via rapid SSL. And I think

597
00:39:14,580 --> 00:39:15,820
that's probably what we're going to have to deal with in the next

598
00:39:15,840 --> 00:39:16,520
look at some of the other things that we're seeing there is

599
00:39:16,520 --> 00:39:20,600
people are, if they're cognizant at all of the Symantec issue,

600
00:39:20,760 --> 00:39:23,760
they don't understand that these are also Symantec. So, literally,

601
00:39:23,900 --> 00:39:26,620
if you take nothing away from this talk, one, these are

602
00:39:26,620 --> 00:39:30,380
Symantec, right? And two, Symantec signed a federal

603
00:39:30,380 --> 00:39:32,920
government cert that they could use for man-in-the-middle for a

604
00:39:32,920 --> 00:39:35,440
period of five years, then failed to do anything about it

605
00:39:35,440 --> 00:39:38,040
for five months, right? That's probably the other thing that I

606
00:39:38,040 --> 00:39:41,260
would take away from this, because I don't know. Anyway. So,

607
00:39:41,940 --> 00:39:45,400
moving away from Symantec, we saw 4,400 domains move in that

608
00:39:45,400 --> 00:39:48,260
period. Where did they go? Largely Komodo and Let's

609
00:39:48,260 --> 00:39:50,280
Encrypt. I'm actually really excited about Let's Encrypt.

610
00:39:50,420 --> 00:39:53,800
They sign a lot of certs for malicious domains. I mean,

611
00:39:53,820 --> 00:39:57,020
that's just a reality. A lot. By the way, if you're looking to

612
00:39:57,020 --> 00:39:59,340
do good cyber threat intelligence type stuff, early

613
00:39:59,340 --> 00:40:03,780
warning, go pull the certs that Let's Encrypt is, they're very

614
00:40:03,780 --> 00:40:05,900
transparent about it, the domains that they're signing

615
00:40:05,900 --> 00:40:08,920
certs for, and look, because you can see a lot of them, like,

616
00:40:08,920 --> 00:40:13,140
grep for the words PayPal or iPhone. And, brother, there are

617
00:40:13,140 --> 00:40:15,380
some crazy numbers of domains that they're signing certs

618
00:40:15,380 --> 00:40:19,280
there. So, while Let's Encrypt does a lot of malicious signing

619
00:40:19,280 --> 00:40:21,620
there, they do it the way they're supposed to for the

620
00:40:21,620 --> 00:40:23,840
browser alliance. They're verifying that you own the

621
00:40:23,840 --> 00:40:26,640
domain. The fact that the domain itself you probably

622
00:40:26,640 --> 00:40:29,500
shouldn't own is a separate issue. They don't deal with

623
00:40:29,500 --> 00:40:33,420
that. So, as far as the movement to Symantec, where do

624
00:40:33,420 --> 00:40:36,340
people leave from, right? Turns out a lot of them left from

625
00:40:36,340 --> 00:40:39,900
Komodo. A few of them graduated from Let's Encrypt. But,

626
00:40:39,980 --> 00:40:43,040
overall, woe sign, right, now that they're untrusted. Some

627
00:40:43,040 --> 00:40:45,200
people finally got on the bandwagon between April and

628
00:40:45,200 --> 00:40:45,360
July. So, let's take a look at that. So, let's take a look at

629
00:40:45,360 --> 00:40:47,100
what happened in July. Realized they've been running on an

630
00:40:47,100 --> 00:40:49,740
untrusted cert for a number of months and said, hey, where

631
00:40:49,740 --> 00:40:53,920
should we go? The next untrusted cert, right? Anyway, so

632
00:40:54,340 --> 00:40:57,480
shouldn't certificate lifetimes be going down, right? We saw in

633
00:40:57,480 --> 00:41:00,620
the beginning where the initial plan, the initial plan, as it

634
00:41:00,620 --> 00:41:03,660
were, was to lower the lifetime, right, of these certs.

635
00:41:03,720 --> 00:41:06,900
I would expect, then, that as people go and renew these certs,

636
00:41:06,900 --> 00:41:10,320
that Symantec would be, like, jumping through hoops to tell

637
00:41:10,320 --> 00:41:13,120
people, like, hey, don't register for three years,

638
00:41:13,240 --> 00:41:15,340
right, because we can't support that because, because, you know,

639
00:41:15,340 --> 00:41:19,280
the Google plan says so. When we started, the certificate

640
00:41:19,280 --> 00:41:22,540
lifetime was 656 days. In the July data set, it drops to a

641
00:41:22,540 --> 00:41:27,180
whopping 652. I am thoroughly disappointed here. I really am.

642
00:41:27,260 --> 00:41:31,460
I'm extremely disappointed that we're not seeing a decrease in

643
00:41:31,460 --> 00:41:35,260
the lifetime of the certs. And, again, I can only ascribe two

644
00:41:35,260 --> 00:41:37,420
things to this, right? One, people don't understand they

645
00:41:37,420 --> 00:41:40,900
have Symantec certs, although I have to say, as people are

646
00:41:40,900 --> 00:41:45,080
reissuing certs through normal expirations, it really irks me

647
00:41:45,340 --> 00:41:47,700
that Symantec isn't advising customers, and maybe they are,

648
00:41:47,800 --> 00:41:51,020
I don't know. Customers could be ignoring them. But it would seem

649
00:41:51,020 --> 00:41:52,880
to me that Symantec would be, like, hey, this is on the

650
00:41:52,880 --> 00:41:56,260
horizon, and we think you might need to deal with the

651
00:41:56,260 --> 00:41:59,100
possibility that this is going to happen. So. .

652
00:42:01,400 --> 00:42:03,560
No, I know what they're telling their customers. So,

653
00:42:03,620 --> 00:42:06,160
the comment here is they're telling their customers, we're

654
00:42:06,160 --> 00:42:08,620
too big to fail. We're not going to fail. Don't worry about it.

655
00:42:09,260 --> 00:42:12,020
I've seen that correspondence through my own customers. It's,

656
00:42:13,060 --> 00:42:15,200
yes. Anyway. So, I think, you know, I think, you know, we're

657
00:42:15,660 --> 00:42:18,540
doing this better. How can we not screw this up again, right?

658
00:42:19,120 --> 00:42:21,960
Look, it's easy to ignore the potential impact. People come

659
00:42:21,960 --> 00:42:25,280
back and say there's not a single example of malicious activity as

660
00:42:25,280 --> 00:42:28,860
a result of this. That's fine. It's fine for you to say you

661
00:42:28,860 --> 00:42:32,420
don't have proof of any of this activity, but we never will,

662
00:42:32,640 --> 00:42:36,040
right? This is kind of one of these spots where we don't know

663
00:42:36,040 --> 00:42:39,480
what the damage is, and we likely never will. I don't think

664
00:42:39,480 --> 00:42:42,520
we can say it's okay, nothing happened here, because, again,

665
00:42:42,560 --> 00:42:45,080
we don't know if anything actually did happen. One, and

666
00:42:45,200 --> 00:42:48,660
two, the risk here is the entire Internet ecosystem. And I'm not

667
00:42:48,660 --> 00:42:52,200
trying to do hyperbole here. It really is the entire Internet

668
00:42:52,200 --> 00:42:55,580
ecosystem. This is not our first certificate fire drill. We dealt

669
00:42:55,580 --> 00:42:58,120
with this in Heartbleed where we had to invalidate lots of

670
00:42:58,120 --> 00:43:03,500
certs. And we sucked at it. We did. And here again, we're in a

671
00:43:03,500 --> 00:43:06,320
position where one of Symantec's arguments consistently over the

672
00:43:06,320 --> 00:43:09,720
last several months has been we can't invalidate and reissue

673
00:43:09,720 --> 00:43:13,060
certs. The global ecosystem is not set up to do this. And

674
00:43:13,060 --> 00:43:15,180
they're right. That's the one thing I'm going to back up on.

675
00:43:15,200 --> 00:43:18,340
They're right. Our ecosystem is not ready for this. We need to

676
00:43:18,340 --> 00:43:20,880
plan for dealing with mass certificate revocation and

677
00:43:20,880 --> 00:43:24,760
reissue. Because if it's the CA that's being untrusted, you need

678
00:43:24,760 --> 00:43:28,020
then to validate yourself with another CA. This takes time, it

679
00:43:28,020 --> 00:43:31,360
takes resources, and CA's don't just scale orders of magnitude

680
00:43:31,360 --> 00:43:36,460
larger overnight. So possible solutions. These are admittedly

681
00:43:36,460 --> 00:43:38,460
flawed, but they're possible solutions. We could have a

682
00:43:38,460 --> 00:43:42,140
trusted third party pre-validate organizations in case a CA shuts

683
00:43:42,140 --> 00:43:47,300
down unexpectedly. Kind of like a global brain trust of CA's. We

684
00:43:47,300 --> 00:43:52,140
kind of have something ish global browser alliance type thing. Could

685
00:43:52,140 --> 00:43:56,000
we have this too? I think that's ripe for abuse as well. So I don't

686
00:43:56,000 --> 00:43:59,060
necessarily recommend that. But it's a thought. We could buy

687
00:43:59,060 --> 00:44:01,980
multiple certificates and have them on standby in case our CA gets

688
00:44:01,980 --> 00:44:05,680
shut down. So I could buy from Symantec and Komodo. I think this

689
00:44:05,680 --> 00:44:08,600
is also a bad plan. I've actually had customers recommend, well,

690
00:44:08,600 --> 00:44:12,460
hedge our bets, we bought an extra private key from Komodo. No,

691
00:44:12,600 --> 00:44:17,380
no, no. Where is that thing? Is it online someplace? Is it an HSM?

692
00:44:17,720 --> 00:44:21,220
Because I'm worried about keeping control. If it's hard to control

693
00:44:21,220 --> 00:44:24,840
your keys as it is, doubling the number of keys makes it twice as hard.

694
00:44:25,520 --> 00:44:29,060
That's just math. We could have third party CA SWAT teams that can

695
00:44:29,060 --> 00:44:31,820
jump in and run a certificate authority when issues are discovered

696
00:44:31,820 --> 00:44:36,160
or surge support is needed. So if Symantec or if the browser

697
00:44:36,160 --> 00:44:38,580
alliance, if there were this magic, you know, magic magic

698
00:44:38,600 --> 00:44:40,920
group that had a SWAT team, they could have jumped in here and done

699
00:44:40,920 --> 00:44:44,640
this. Of course, realistically, all these cost money, all of them

700
00:44:44,640 --> 00:44:47,760
are going to increase costs. I don't have an answer here. Somebody

701
00:44:47,760 --> 00:44:50,220
smarter than me is probably sitting in this room who does have the

702
00:44:50,220 --> 00:44:53,580
answer. Totally let me know what that is after we're done with the talk.

703
00:44:54,360 --> 00:44:57,520
So I'll give you a couple parting thoughts here. It's 2017. We should

704
00:44:57,520 --> 00:45:01,200
not be talking about this. We should not be talking about this. We

705
00:45:01,200 --> 00:45:03,460
definitely shouldn't be talking about this months after the initial

706
00:45:03,460 --> 00:45:06,700
release. Symantec should not be telling their customers it's okay,

707
00:45:06,780 --> 00:45:08,580
we're too big to fail. We should not be talking about this months

708
00:45:08,600 --> 00:45:10,900
after the release. I would as a personal thing, not as a legal

709
00:45:10,900 --> 00:45:15,320
thing, Mr. Lawyer, whoever you are. As a personal thing, I think

710
00:45:15,320 --> 00:45:19,280
it's abhorrent that Symantec is talking about the too big to fail

711
00:45:19,280 --> 00:45:23,040
piece and not talking about the very real security issues that have

712
00:45:23,040 --> 00:45:25,980
been introduced. I think that that's just bad for the community

713
00:45:25,980 --> 00:45:30,800
overall. I will also say that Google's handling of Symantec is not

714
00:45:30,800 --> 00:45:33,560
good either. I think Google deserves to be in the penalty box here.

715
00:45:33,740 --> 00:45:37,320
They identified a security issue. They have the power to take action

716
00:45:37,320 --> 00:45:41,660
and they are valuing user convenience and customer convenience over

717
00:45:41,660 --> 00:45:46,700
security. And we in InfoSec routinely tell people don't do that. There's

718
00:45:46,700 --> 00:45:49,820
a hardware hacking village with the voting machines right down the hall

719
00:45:49,820 --> 00:45:53,860
here where that's the whole reason it's there is because of this garbage.

720
00:45:54,240 --> 00:45:58,040
Right? Symantec should have been rapidly untrusted just like woe sign.

721
00:45:58,320 --> 00:46:01,000
Forget this too big to fail stuff. It didn't work for the government,

722
00:46:01,200 --> 00:46:05,980
didn't work for the banks, it's not working for CAs either. And then

723
00:46:05,980 --> 00:46:07,300
finally, review the CAs that you're working for. You're working for the

724
00:46:07,320 --> 00:46:10,960
government, you trust in your browsers. This is nuts. Most of them don't need to be

725
00:46:10,960 --> 00:46:14,780
there. And the way you can convince your management of this is run Bro. Bro

726
00:46:14,780 --> 00:46:19,000
network security monitor, NSM. Go through, you can configure Bro with Bro

727
00:46:19,000 --> 00:46:23,560
scripts to log all of your SSL certificates. And find out who's signing those things.

728
00:46:23,920 --> 00:46:28,500
And if you go through over a 30, 60, 90 day period, whatever works for you, 30 is fine for me.

729
00:46:28,920 --> 00:46:33,120
And you look and you find out there's only five or six of those trusted CAs signing the

730
00:46:33,120 --> 00:46:37,300
certs that you are actually using, get rid of the rest. That's what I'm saying.

731
00:46:37,320 --> 00:46:43,740
Maybe you cause one pop up someplace. I will tell you, and I can't share the stories here,

732
00:46:43,840 --> 00:46:47,340
but I will tell you, and somebody else sitting in the audience saw an example of this,

733
00:46:47,480 --> 00:46:54,120
where we actually are fairly confident that based on some good net witness data that we got

734
00:46:54,120 --> 00:46:58,920
popped like this. And it was a big company, it was a big target, and they were having trouble

735
00:46:58,920 --> 00:47:03,480
getting in and we're pretty sure that's how they got in. Because something served a certificate

736
00:47:03,480 --> 00:47:07,300
that was trusted but not trusted. And I'll just leave it there. And I'll just leave it there.

737
00:47:08,080 --> 00:47:13,600
That's it. I got like five minutes tops for questions. Sir, speak into the mic,

738
00:47:13,740 --> 00:47:17,320
because otherwise they can't. There's a mic right there. I think it's a mic, but.

739
00:47:17,620 --> 00:47:21,720
Hello? Yeah, that's good. Okay, it works. So there was a slide that mentioned that

740
00:47:22,800 --> 00:47:28,040
performed a modular comparison between the private key and the public key in the cert. Yep.

741
00:47:28,240 --> 00:47:32,160
To validate, but they did not do something else. What is that something else? Do we know?

742
00:47:32,920 --> 00:47:37,200
Oh, no, that was it. They actually didn't validate the private key. So the question is did

743
00:47:37,320 --> 00:47:41,740
they, what else didn't they do besides validating the private key? We're talking about here.

744
00:47:42,200 --> 00:47:48,220
Yes, this one. It says perform the modular comparison, which I thought was the whole key of

745
00:47:48,220 --> 00:47:52,000
this mathematical comparison between the public and the private key. What did they not do?

746
00:47:52,360 --> 00:47:57,460
I, it's my understanding they were doing some mathematical shortcut. I know whatever they did

747
00:47:57,460 --> 00:48:01,520
is not a full comparison of the key. Because what he sent them was not the private key.

748
00:48:05,760 --> 00:48:07,300
. Yeah, so they validated the private key, but they didn't do anything else. So

749
00:48:07,320 --> 00:48:16,740
they validated the module as part of. Okay, so just to preserve this on the video here.

750
00:48:17,320 --> 00:48:21,320
Again, basically that what we're thinking here, although I don't know that we're 100% sure in

751
00:48:21,320 --> 00:48:25,660
this case, is that they generated another key with the same modulus. They validated the modulus

752
00:48:25,660 --> 00:48:31,420
rather than validating the key itself. Again, you can't fake that. If you can, I totally want to

753
00:48:31,420 --> 00:48:35,620
work with you, because that's going to be awesome, right? We're going to get stuff taken down. Sir?

754
00:48:35,840 --> 00:48:37,300
Do you know if the, if the, if the, if the, if the, if the, if the, if the, if the, if the,

755
00:48:37,320 --> 00:48:41,820
if the revocation of the U.S. Federal Government Certificate actually had any effect? My

756
00:48:41,820 --> 00:48:46,860
understanding the revocation process is kind of not working as we wanted it to. Yeah, so did the

757
00:48:46,860 --> 00:48:51,960
revocation of the U.S. Government Cert have any effect. The revocation process definitely is not

758
00:48:51,960 --> 00:48:56,920
working the way it's supposed to. The cert eventually expired. So it's less of an issue now

759
00:48:57,360 --> 00:49:02,200
than it was. But no, you're right. The revocation process is not working the way it's supposed

760
00:49:02,200 --> 00:49:07,300
to. I don't think it had any effect. It eventually expired off anyway. But it was a cross-examination

761
00:49:07,300 --> 00:49:11,680
signed route and that was one of the arguments that Symantec made

762
00:49:11,680 --> 00:49:14,560
is that a lot of government sites were signed with this and

763
00:49:14,560 --> 00:49:18,760
revoking could potentially cause issues there. Again, I don't

764
00:49:18,760 --> 00:49:21,200
think they understand the math behind this. Or some of the

765
00:49:21,200 --> 00:49:23,140
people making arguments don't understand the math behind it.

766
00:49:23,340 --> 00:49:26,540
Sir? What are your thoughts on cert pinning as a possible

767
00:49:26,540 --> 00:49:31,580
solution? So what are my thoughts on cert pinning as a

768
00:49:31,580 --> 00:49:35,700
possible solution for some of these issues? I will say that

769
00:49:35,700 --> 00:49:40,180
cert pinning is neat, but from a blue team standpoint, I need

770
00:49:40,180 --> 00:49:44,020
SSL interception. I need SSL interception. If you're doing

771
00:49:44,020 --> 00:49:48,160
cert pinning, I consistently then am overriding that in group

772
00:49:48,160 --> 00:49:51,540
policy, I'm overriding that in browser settings because I need

773
00:49:51,540 --> 00:49:55,040
to be able to do SSL interception. I can't run a large

774
00:49:55,040 --> 00:49:57,540
organization today and do data loss prevention without being

775
00:49:57,540 --> 00:50:01,720
able to see into your Gmail. This is just a reality. If I

776
00:50:01,720 --> 00:50:05,340
can't see it, the attackers know that they can use that.

777
00:50:05,700 --> 00:50:08,360
John Strand and his team over at Black Hills put together Gcat.

778
00:50:08,640 --> 00:50:11,620
I don't know if anybody has seen this, but it's like Netcat except

779
00:50:11,620 --> 00:50:15,580
it does basically data exfil. It's a free framework for doing

780
00:50:15,580 --> 00:50:19,580
data exfil and command and control over Gmail. What's that?

781
00:50:20,540 --> 00:50:23,840
I thought somebody mentioned Gcat. I did drop smack a couple

782
00:50:23,840 --> 00:50:27,400
years ago. Same thing with Dropbox. So if you're doing cert

783
00:50:27,400 --> 00:50:29,840
pinning, that's great. It solves one problem but creates a brand

784
00:50:29,840 --> 00:50:32,540
new one because we can't see into that and attackers are going to

785
00:50:32,540 --> 00:50:33,980
use those types of techniques.

786
00:50:35,960 --> 00:50:37,760
I don't have the right answer here, unfortunately.

787
00:50:40,180 --> 00:50:43,960
Couple of things. With the modulus, I'm not sure you can

788
00:50:43,960 --> 00:50:46,000
actually generate another key unless you've got the totient.

789
00:50:46,100 --> 00:50:48,060
If you've got the totient, you can factor in the first place

790
00:50:48,060 --> 00:50:52,140
and get anything, right? I am not 100 percent sure on the

791
00:50:52,140 --> 00:50:57,560
off. If anybody has PNQ, they can make any key. Totally

792
00:50:58,020 --> 00:51:01,520
understood, right? And again, this is a spot where his blog

793
00:51:01,520 --> 00:51:05,280
post is not 100 percent detailed for obvious attack

794
00:51:05,280 --> 00:51:05,680
repeaters. I don't have the right answer here, unfortunately.

795
00:51:05,700 --> 00:51:11,080
But he confirms that he sent them not the private key and they

796
00:51:11,080 --> 00:51:15,840
revoked it anyway. That's the key. Not to overload the word the

797
00:51:15,840 --> 00:51:19,660
key, but that's the point is they revoked a key they shouldn't

798
00:51:19,660 --> 00:51:23,520
have. Symantec admits as much. I think they were doing some

799
00:51:23,520 --> 00:51:27,040
mathematical short cut there that is not the full analysis.

800
00:51:27,620 --> 00:51:35,120
Then RSA security, if we get quantum or advances in factoring,

801
00:51:35,120 --> 00:51:38,540
we have to be better handling certificate revocation generally

802
00:51:38,540 --> 00:51:41,080
and shouldn't that have been baked in in the beginning? Yeah

803
00:51:41,080 --> 00:51:44,080
sure. So if we have advances in factoring, kind of repeat this

804
00:51:44,080 --> 00:51:46,580
for everybody, if we have advances in factoring, you know

805
00:51:46,580 --> 00:51:50,460
RSA basically, a lot of the security kind of rotates around

806
00:51:50,460 --> 00:51:52,560
that. We have to get better at revoking this stuff in the first

807
00:51:52,560 --> 00:51:55,320
place. So I agree with that wholeheartedly. You're right.

808
00:51:55,900 --> 00:51:59,240
Obviously the SHA-1 apocalypse taught us a lot about that. We

809
00:51:59,240 --> 00:52:03,160
accelerated the death of SHA-1 for certificate signing because

810
00:52:03,160 --> 00:52:06,680
of advances in, well not factoring specifically there, but

811
00:52:06,680 --> 00:52:10,820
advances in combinatorial mathematics there. We're looking

812
00:52:10,820 --> 00:52:15,240
at the collision vectors in SHA-1. So again, I think you're

813
00:52:15,240 --> 00:52:17,540
100% right on that. We have to have a better way to do this and

814
00:52:17,540 --> 00:52:21,820
we don't. Okay, I think it's a good spot to cut it. I'll hang

815
00:52:21,820 --> 00:52:24,220
out here if anyone wants to talk, like in the back or out

816
00:52:24,220 --> 00:52:26,520
in the hall or whatever. Thanks for coming. Appreciate your

817
00:52:26,520 --> 00:52:27,760
time. See you next year.