[ Silence ]
>> It is my great pleasure to introduce
Mr. Matthew Green who is going to talk
about cryptography as a system's problem.
Now, we've been looking in the course,
we've been looking at the lower level
of things starting from libraries and going down
into the kernel innards but all of that exists
to support applications, the so-called Layer
7 where bring-three [phonetic] as we know it.
And so this is going to be a look at-- about
what does-- all of those innards are really for.
>> Okay, that sounds-- that
sounds like an easy description.
So I was not even completely
aware that was an OS class.
So I'm going to confess to you
guys that this is probably going
to have the most tenuous connection to OS of any
lecture that you're going to hear in this course
but it might be very interesting, anyway, and
it might be helpful at least in terms of OS.
So, before I get started with, in terms of the
actual presentation, let me introduce myself.
My name is Matt Green.
I teach at Johns Hopkins.
I'm a research professor there.
I also, sometimes, hang out
at the University of Maryland.
My job is a little hard to describe because
a few years ago, what I did is I started
that consulting firm called Independent Security
Evaluators and I spent the next few years kind
of both being a grad student and I also work
in a consulting firm looking
at real cryptographic systems.
So I got to see a lot of kind of
really scary stuff, and good stuff too,
but mostly scary stuff, which is neat because
I was actually looking at the real world.
Now, I'm a research professor,
I do research most of the time.
I still do some of the work.
I asked, whether I should come here and give you
guys a talk about research or give you a talk
about real stuff, and real stuff won out.
So we're going to talk today about kind of this
system's aspects of crypto and, in particular,
the example I'm going to give you guys
is the SSL/TLS protocol which, I think,
is probably the most common widely
used cryptographic protocol out there.
It's what everybody thinks of when
they think of secure communications.
And that's it.
So the last thing I'm going to add is
that, as there were sounds of people here,
I was actually born in Hannover, so this is
kind of like a kind of cool thing for me.
I spent a lot of my junior high sneaking
into the computer building here at Dartmouth,
thinking that if I just looked really serious,
nobody would recognize that
I wasn't a college student.
And so I would sneak in.
I would use like that Tektronix terminals and
stuff, it was a sad time and get kicked out.
So it's kind of neat for me to actually be
in the Dartmouth college computer building
and not feel like I need to look over my
shoulder for somebody there [inaudible].
So, anyway.
So, let me start by motivating
this presentation,
why are we giving this presentation?
If you-- before I can get started, how
many of you guys have taken a crypto class?
Okay, good.
That's a good number, that's
kind of what I was expecting.
If you are not somebody who's really
an expert in crypto, probably,
you've seen quotes like this around.
Probably your exposure to
crypto, maybe it's more than this
but at least you've probably been exposed
to some statements along this line,
which is that for people who know something
about computer security and system design,
crypto is kind of a problem that we know
how to solve, software, total disaster,
secure everything else, total mess.
But cryptography, that's the
one area that really shines
because we know how to do that right.
Sometimes, people put it like
this, crypto was the strongest link
in the chain but everything else is terrible.
Let's see.
This is, I don't know who said this,
I was trying to find Bruce
Schneier saying something bad
but I couldn't get him say something
stupid, so instead, what I found is this,
where people concentrate too much
on the cryptography of the system,
which is the equivalent of the strength,
I mean, I hate this strongest link
in the chain crap, lots of people say this.
So the basic point of this is yes, if you're
not a cryptographer, this might be your view
of cryptography but everything that
these people are saying is wrong
because crypto is just as
broken as everything else.
The difference is that most people don't
know enough cryptography to realize that.
So this presentation is going to be kind
of our introduction to all the bad things
that you should know about in your-- that
you use in your day to day existence.
So when it comes to those kind of solved
problems, this is really what things look like.
We do have one solved problem, cryptographic
algorithms for the most part, for the minute,
right now these are actually, I
would say that this is a problem
that we don't absolutely need
to be focusing our time on.
But that's it.
Everything else, and this is kind of this
arrow indicates the confidence that we have
in these arrows, in these areas but kind of in
the inverse, so it will get worse as we go down.
Protocol design, not so great.
But then going beyond protocol
design implementation, terrible.
We are just bad at implementing things.
Library API design, you think
that would be simple, right?
It's encryption, decrypt, encrypt, right?
Not very good at this stuff.
Now, I'm not even going to say
anything about this because, clearly,
we don't know how to use this stuff, right, or
else we wouldn't be hearing all these stories
and the problem is that probably 80 percent of
the people on the internet don't even use crypto
which is just the whole problem that's
outside of this presentation all together.
When I was looking at these
slides this morning I felt
like maybe this did not give a proper
view of how bad things were, so,
I just illustrated a little bit with these
guys but that's kind of the situation.
I just-- to further illustration of
kind of how bad things are right now.
Looks like I didn't get all
of the headlines in here,
but just a couple of the headlines
I managed to copy over here,
lots and lots of stuff doesn't work that's why--
here you go, sorry, these
are the slides I wanted.
Lots and lots of attacks that had
happened over the last few years,
many of them implementation-related attacks,
some of them protocol-related attacks,
and unfortunately, this doesn't
seem to be kind of an anomaly,
the pace of these things is peaking
up and it's becoming more serious,
as more people actually start to rely on crypto.
Anybody read about the flame
attack of last summer?
This is a-- we'll come back
to that but this is a--
was a very, very serious attack
on the certificate authority.
Okay. We are not going to talk about all
crypto today, that's just too broad a topic.
We're going to talk about one specific
protocol which is the secure socket layer,
AKA transport layer security protocol sweep.
We care about TLS because I don't
think it's really wrong to say
that TLS is the most important security
protocol in the world, there's things like IPsec
out there, there's other kinds
of crypto but TLS is how most--
the least transport security
gets down these days.
Most people look at this and
they kind of see a vision
of how TLS works that's exactly
like this diagram.
What you do is you're an application, you
want to talk to someone, you say, "Okay,
I wouldn't normally just make a socket
connection to this person but that's unsecured
so I'll just throw TLS on it and now it's a
secure socket connection, so it's like a tunnel
and no matter what happens out
here in this cloud, I'm safe.
"This is not exactly what TLS really looks
like, but this is how people want to view it.
The other thing I should mention about
TLS is not only is it widely used
but it's becoming much more widely used.
You've probably seen things like this,
Facebook is moving to 100 percent TLS, Google,
Gmail has already moved to 100 percent SSL.
Lots of people are pushing, pushing,
pushing, to get everybody to do this.
Yes?
>> Is there a reason why they
didn't deploy them before?
>> It's hard.
It turns out to be very hard
to get these things deployed.
It takes more server hardware
to do the decryption side.
It turns out to be a nightmare when
you have things like applications,
like a distributed site, we have
like some servers running
applications and all these stuff.
Getting SSL running on everything
turns out to be a big mess.
>> Is there a factor by which
it's supposed to [inaudible].
>> It does and, actually, the
biggest problem is latency.
So the SSL handshake is a
two-round communication.
So normally, if I want to talk to you, I do
talk, you know, a TCP handshake is one round.
SSL added to the TCP handshake plus the
SSL handshake, which, when you're doing it
over like an intercontinental
cable or something like that,
it can have like a significant
fraction of a second.
So there's computation, there's
resources and there's latency.
A lot of people don't like that.
But really the big problem is just dealing
with all these other headaches that come
up like your 20 servers need the same key or
certificates, and so it becomes a big headache.
So that kind of stuff is a problem.
But the bigger companies are slowly
getting over this and they seem to be kind
of moving towards the universal
TLS-SSL framework.
The importance of this is that
the people who are pushing
for SSL everywhere are not
nuts, they're not paranoid.
We're entering an era where actually having
a secure encryption is no longer a kind
of an academic thing.
Just this September 2011, back in
2010-2011, there was a big high profile hack
of a certificate authority called
DigiNotar, where somebody stole certificates
or keys that is, and were able
to make a certificate for Google
which they then used basically for everybody or
a huge number of people in the Iranian network--
internet or connection to the internet to
do a man-in-the-middle-attack against Gmail
where they were able to steal
people's Gmail credentials.
This kind of thing is actually becoming more
common not just certificate authority attacks
but all kinds of attacks against
these systems because people want to--
now that people are finally using crypto,
people are finally attacking crypto.
So, in this presentation, we're going to look
at kind of a whole bunch of different problems
with the SSL-TLS protocol, starting not just
with the way people code it up but starting
with design, starting with even
some like the formal analysis--
some kind of what's lacking
there down to the implementation
and down to the way that people use it.
Before we get into all those details, I'll
start with a very quick history of the protocol.
So SSL was actually invented at a company that
no longer exists, but you guys should know
of Netscape Inc, way back in I think,
1995, that's kind of a rough date.
It was-- they have this proprietary
server product and a proprietary browser
at the time which became Firefox.
And they wanted a way to communicate
securely so that people could do, you know,
20-dollar credit transactions over the internet.
So they came up with this thing,
they called it Secure Sockets Layer,
they never released the first version.
A year later in 1996 or thereabout, they release
the actual first public release which was SSLv2.
And that had some very serious bugs.
And the only reason I've actually included this
picture here, is that for those of us who grew
up in the 90s, it doesn't
seem like that long ago.
But when you look at Will Smith.
[laughter] You can see, the things were
different then and in terms of a design
of photographic protocols, our understanding
of how to design these things was very,
very different and very primitive
compared to one of these today, yes?
>> Was the SSL one or two, they add
a bug where they only seeded by the--
to the second, so there are
only like 60 or 20 seeds?
>> There's-- I didn't even include
that method in this presentation
but there was a huge [inaudible] debug,
what if I include that in this presentation?
When I get to the implementation or
stop me and say, what about the--
>> I remember, one of the first releases
of the Netscape SSL, it's seeded crypto
that seeded round number with the
seconds-lock [phonetic] of their [inaudible].
>> -- That one I heard about, but I believe
you, that's-- that's, yeah, that's not good.
[laughter] Yeah, I mean it was bad.
I mean, now I mean if the implementation--
you think, okay people make coding
mistakes, but you can fix coding mistakes.
But they put a lot of bugs into the protocol
itself, and we're still fixing those today.
So, yeah, that's-- I mean, it was
not an open protocol at that time
and then eventually it became
open, they got slowly better.
But it's still getting better
today which is bad, okay?
So they have serious bugs including
apparently implementation bugs
that I didn't even include
here, which is fine, okay.
So that got fixed, we have a new
release, I don't have a date here.
SSL version 3 comes along and says we're
going to fix all these problems with SSLv2.
But it turns out that this has
some slightly less serious bugs.
However, and I did find something
by Bruce Schneier.
He says with Kelsey, he says, we conclude
that while there are still a few technical
vulnerabilities, technical wrinkles to iron up,
on a hole, SSL version 3.0 is a
valuable contribution towards practical
communication security.
So this is SSL version 3.
Okay. He was wrong, TLS version 1.0 comes out.
Now they changed the name
of the protocol to TLS.
It's confusing but that's all there is to it.
Instead of calling it SSL version 4,
they decided to call it TLS version 1.
It turns out that TLS version
1 have problems that people,
even theory people haven't discovered yet.
One of which is that the initialization vectors
in encryption are not properly generated.
I'll talk about what that means maybe later.
But the upshot is that, you can,
using a little bit of JavaScript
and some simple arithmetic using X
or you can actually decrypt cookies
that are sent over secure connections.
The attack that discovered this was by
a guy named Greg Bard at the University
of Maryland, he published a paper on this.
I mean, this have been known since maybe 2001,
but in 2006, he published a paper that said,
here is a problem with SSL,
you guys should fix it.
He was told by his adviser
that he should probably work
on more interesting publishable
work, first of all.
And then, the paper was completely
ignored by everybody.
And so and I'm looking at the date
of this till 2011 in September.
When a couple of guys actually went out and
found this paper and, you know, implemented it,
and made it better in the process.
But, they actually did this and they
called it the BEAST attack which stands
for Browser Exploit Against SSL, TLS this--
there's acronym problem, so they do this.
They called it this and they did a cool
video of doing it and it's really neat,
you can actually take an SSL connection
and watch it by-by-by pull out this cookie
out of this AES encrypted
connection which is very neat.
So it turns out that these vulnerabilities were
already baked into this back even in TLS 1.0.
Later the next year, the same guys came up
with a new attack called CRIME which stands
for Compressed Record Information-Leak
Made Easy.
And this paper took another paper from 2002 and
actually implemented it and obviously did a lot
of cool implementations up to make it work.
And they were able to do the
same thing using TLS compression.
So all of these flaws were in a speck
and nobody really thought about it.
>> What happens to these authors after-- -
>> They were killed, no, I don't know.
These guys, they're still out there,
they're working on a new attack.
I hear-- is it serious that they
really have something called terror?
>> There was a T of it, it
might be called the timing.
>> Were they joking or was that for real?
[Inaudible Remark]
>> My God.
Oh, man, we were hoping that they didn't
do a rapid password exploit or something
because who knows who's going to come with that.
>> Yeah, it's really going to try
to escalate those stupid acronyms.
>> They are, they did it longer,
and they're going to get worse.
So anyway, they have a new attack coming out,
who knows what this is, but
it could be timing-related.
Anyway, so these things exist
in there and there.
Let me give you again, this is the, what you
want to think of TLS and SSL is looking like,
you know, this nice tunnel, where you don't have
to think about the details, you just turn it on
and it works and everything you
send is encrypted and protected.
The real SSL protocol and I'm still giving you
a high level view but maybe a more accurate one.
It looks like this, it starts
with some kind of negotiation.
Where you and I say, hey, we support
these ciphers, we both do compression,
let's talk about it, let's agree on
something that we can both support,
followed by key exchange protocol where we
agree on a secret key using public key crypto.
Followed by the actual, most
important part of the protocol which is
to actually encrypt data in both directions.
Securely, followed by all kinds
of crazy stuff that can happen
when we re-negotiate at the end of it.
So I'm going to take a few minutes.
This is going to be the crypto-crypto
part of the talk.
And we're actually going to involve you
guys, doing an interactive exercise.
We're going to see how that goes.
So this is the part where we're
going to talk about crypto,
I'm going to talk about these
protocol design issues with TLS.
The best description of the problems in
SSL and TLS, the ones that are still kind
of haunting us today come from Eric Rescorla.
Well I think, he's one of the authors of
the some of the versions of SSL and TLS.
He describes the problem
here being that TLS's use
of "pre-historic cryptography,"
meaning that 1995 error stuff.
He uses a lot of bad stuff.
One of the things that it does is it uses
AS in something called CBC mode
which we can talk about later.
Using a MAC, which a MAC is
a message authentication code
that prevents tampering with the message.
He uses it in a particular construction
that we call MAC-then-Encrypt.
What I mean by that is we have this nice thing
that, oops, we have a message which I'll call M.
And we have this nice thing called a MAC.
And the only thing you need to know
about that is it protects the message.
If anybody tries to tamper with this on the
way over the wire, we'll be able to detect this
at the other side by checking the MAC.
If you don't need to know any crypto,
think of it like a checksum, okay?
But it's a cryptographically-secured one.
Then what happens is we take this
whole mess and we encrypt it.
This is called MAC-then-Encrypt,
MAC-then-Encrypt.
I'll come to why this is
a problem in just a second
but this is what happens inside
of a standard CBC mode of TLS.
It uses a mode of RSA encryption with a
padding scheme called RSA-PKCS#1 v1.5.
And I want this to go away
simply because I don't want
to ever have to say RSA-PKCS#1 v1.5 again.
But this turns out to be extremely
broken, broken to the point
that you can actually completely decrypt
an RSA ciphertext by sending in, chosen,
manipulated messages to a server.
You can decrypt an RSA ciphertext and
anywhere from a few minutes to a few hours
by doing that, so they're very bad.
It uses RC4.
I'm going to come back to why RC4 is
bad, we'll talk about that in a second.
But a lot of that, the biggest reason that
it uses all of these old obsolete crypto,
is that the people who design these protocols,
wanted them to be backwards compatible.
So they made a bad version in 1995.
And here we are in 2013,
stuck with their bad versions
because they wanted backwards compatibility and
they were not willing to break compatibility
because they thought it would scare people away.
So this is kind of the problem.
All right.
So let's talk about one specific example.
This is a very easy one to understand.
Okay, so TLS, like I just described in MACs,
the record first put the MAC on the end.
And then, it encrypts it.
Now the thing that I didn't show you up
here is that the encryption that we use
which is called CBC mode encryption
for AES for example, has a requirement.
We can only encrypt messages that are
multiple of, if we're using AES 16 bytes.
So if I encrypt a message where
this whole thing comes to a total
of 23 bytes, what am I going to do?
[Inaudible Remark] Good.
Simple answer.
That was a warm-up question,
that was not a tough one, okay?
So we're going to pad it, we're
going to stick on some bytes
at the end until we get it up to 32 bytes.
Now, we have a good message
and now we can encrypt it.
And obviously, when we decrypt the
message, what are we going to have to do?
So first, we'll strip off this encryption,
and then we'll remove the path which means,
we need a padding format that we can
recognize, so that we can always,
you know, unambiguously take it off.
That's why.
Let me actually draw in what the
padding format looks like here.
Just for fun.
The padding that they designed
for TLS looks like this.
It ends with a link byte.
So let's say 23 and 32, so that's a 9-byte pad.
So we would start by putting and 09 byte.
I always get this wrong 'cause
they do something a little weird.
Actually, you know, what they would do.
They have a length byte that
doesn't include itself.
So, they would put an 08 at the end.
And then they would put 8 bytes.
You're going to hate me for doing this.
I'm just putting a bar, so you can see
where the separation to the bytes are here.
Okay, just pretend that there's--
there's a bytes there 'cause I'm
getting-- I'm too lazy to draw them all.
And this would be, in total, a 9-byte pad
and that would get you up to 32 bytes.
So that's the problem.
So, the problem here now with padding articles,
somebody very clever back in 2002, named--
a guy named Seraj Vodney [phonetic] discovered
that you can actually use the structure
of the padding to do something very useful.
So, what happens when people decrypt
is they take off the encryption.
The first thing that they always
do is they look at the padding.
And in this case, this padding
happens to have a very specific format
which is the person doing the
decryption first looks at the length.
And then he should expect to see
8 bytes before it and because
of the way the padding is put together, all
8 of these bytes should have the value 8.
So he checks for that, simple check.
And if that works, he strips it off
and he goes on with the rest of it,
and then he checks the MAC and whatever.
If the padding doesn't check out--
if any of these bytes is not 8,
he usually returns an error and a typical
error is something like bad padding.
Now, what could you do with that
in order to take advantage of this?
Well, it turns out that the CBC mode
encryption that we use here is malleable.
And what that means is even if I only see the
ciphertext, it turns out that I can flip bits
on the ciphertext that will cause
exactly the same changes to appear
in the underlined plain text
after it's decrypted.
And so what this guy Vodney discovered is, I
want to give you a very specific example here.
Let's imagine that the last byte, I'm going
to draw a line here just to illustrate.
Let's imagine that the last byte of the message
that we want to attack are the last byte
of the MAC really, is an 09-byte.
Okay? So, what-- what can happen here is
if I send this message, I could-- I could--
tampering with the message,
I can flip this to an 09.
Will this message, is this
going to pass the padding check?
No, okay. Well, let's say that I am
going to change all of these values
to 09s, using the same tampering.
I can just flip a bit in each of these byte
positions to cause all of these to read as 09s.
Now, what's going to happen?
[Inaudible Remark] It's going to say, yes.
There's 9-byte of padding
here including this last byte.
So I can go through every
possible transformation.
I can say, "Okay, it's not an 08."
I'll flip these maybe and I'll turn them into 9.
I'll turn them into 10s.
I'll turn them into 11s, and so on.
So this is just a very simple example.
One of those values, if I'm careful in flipping
my, if I'm careful in changing this padding
around correctly, one of these padding
values will turn out to match up correctly
with the last byte of the secret encrypted
message that I actually want to find out.
So for all the wrong things,
I'll get a padding here.
But for the one that actually
matches this byte that I want
to learn about, I'll get something else.
So I get a, maybe or probably
a MAC error or something.
And just using that condition, I've
learned one byte of encrypted information.
Now, how do I take that one step further?
>> You flip that one too.
You go to the next [inaudible]
>> Exactly.
So, it turns out that I can
just basically say, "Okay."
Well, let's turn on these--
let's try incrementing all these.
Let's try turning these on to 10s and, okay,
if the last byte here is 10 then I've
learned something or I could try other bytes.
So actually, what I can do is I can flip this
byte too and I can flip it until, you know.
If this XOR-ed with a certain value
is 10 then I'll get a correct check.
And if I know the value that
I XOR it with, which I do,
then I can figure out what
original value is here.
So, this is of the world's quickest
explanation of a kind of a complicated tech,
but it's not that complicated
in man-in-the-middle-attack.
You could work this out, I mean,
this is not something you need
to be a PhD in crypto to understand.
This is a very simple attack.
And it's a fast attack because it
requires 256 decryption attempts per byte,
which is not that bad.
I mean, that's-- that's actually
pretty reasonable.
It's like Hollywood-style decryption.
They can actually like really decrypt something.
[Inaudible Remark] Yes.
And that's the-- that's the key here.
I'm not going to go to the details of
CBC because I don't think that's going
to add very much here, but that's exactly right.
You can XOR a bit into a certain
position of the ciphertext
and that same exact bit will be
changed, flipped in the decryption,
except it will be one block further on
in the decryption of the plain text.
If you look up CBC mode on
Wikipedia you'll see why that is.
Yes?
[ Inaudible Question ]
That-- well, this is true.
But it turns out that byte.
So, for example, let's say we have a case here.
Let's say this is not in that 15.
Let's say this is-- let me think of a good one.
Let's say this is FF.
Right? That's definitely not
a valid padding byte, okay?
But, let's say that I've guessed that, you know,
these are all 09 and that would include this.
So I can flip this also, this say, 09.
And then, I can XOR in a value into here.
By XOR-ing this with something.
No, let's say, I'll XOR this with some
value Y, it will come up to be equal to O9
which will give you valid padding.
So, maybe, that's not the best explanation.
So, FF, XOR with some Y equal OX10 and
we pick Y, we can try every value of Y
until we get one value of Y that causes thing
to be equal to 10 and once we know, well,
we know that the Apple's here is
10, we pick the particular value
than we can recover whatever value we
will know that the input was app, okay?
So-- so, basically, this is a
very bad explanation but yes,
it doesn't matter that its
just 15 values of padding.
This attack pretty much works against anything
and it's a very nice attack against TLS.
So, to fix this attack, there are--
there's a recommended way and
there's a way that TLS did it.
The recommended way is simple.
It's called change the order
of the way you do your MAC.
You do something called encrypt, then MAC.
All that means is encrypt your
data first with your padding
and then stick you MAC over here on the outside.
That prevents anybody from doing this crazy
XOR stuff because the MAC is like a check
and would prevent that catch
you, you'll be fine.
They didn't do that.
So, they actually implemented a bunch of
countermeasures not all at the same time.
Okay. So counter measure number one.
This is the-- if you assign-- well, I don't
want to say anything rude about undergraduates.
So, I'm not going to-- this is the--
if you assign a first semester freshman
computer science student to fix this problem
without changing too much code and they're lazy.
Well the first thing they're going to
say is they're going to say, "Well,
this padding area is the problem.
Not the encryption."
Let's just make it so that no matter
what happens here, we give one error.
Would that fix the problem?
Does that fix the problem?
>> No.
>> Okay, do you have any idea
what might cause the problem here?
[Inaudible Remark] Very good.
Yeah, exactly.
So what somebody realized is that-- so this
actually in theory, this would work except
for the fact that there's a timing attack.
What happens in most implementations, well the
first thing you do is you check the padding.
If the padding is bogus, you bail.
If it's not bad, then you go
on and you check this MAC.
That actually takes a bit of computation.
So somebody actually timing you can typically
tell that you've done this extra work
and then they know whether
the padding succeed or failed
and then they just implement the
attack the same way they did it before.
And that actually works really well
'cause these MACs are pretty fast.
But there are also cryptos that
would take a bit of computation.
So, this-- this actually turned out
to bring this attack back to life.
Okay, we need another patch, okay?
So, here's another patch.
All right, constant time decryption.
What we're going to do is we're going to make
sure that even if the padding check fails,
we're going to still compute a MAC.
That should fix the problem, right?
Can anyone tell me why that
might still be a little tricky?
>> Power.
>> No. It didn't.
It's not even that.
It's-- I'll give you a hint.
It's still timing.
Still timing problem.
This is in the spec, by the way.
It turns out that when the padding is bad,
you don't know how long the message
that you're supposed to MAC is.
>> Wait.
>> So, if the padding is bad, right?
You can have a padding-- the padding
could be up to 255 bytes long,
by the way, I should mention that.
So, if you have a valid 255-byte padding, you
might have like a one-byte message followed
by a MAC, followed by a huge amount padding.
Or if somebody totally screws up your padding,
you don't if that's 254-byte message followed
by, you know, a little bit of padding.
You just don't know because
the padding is broken.
So, the countermeasure in the spec
says, "Yeah, we know that's a problem."
So, what-- what you should do is
compute a MAC on something, you know.
Maybe just MAC the whole
message without, you know,
including whatever might be here in the padding.
Just MAC it all.
That's probably, that's a small enough time in
general, no one's going to be able to break it.
It turns out that people can break it, okay?
And then, that lead to this.
This is my favorite headline
on recent weeks just
because it includes the word buffoonery in it.
I really like that.
This is an attack and I want you guys
if you can see it from back there,
to look at the date at the
bottom of this attack.
It's February 4, 2013.
This is a new brand new TLS
attack called lucky 13.
It just came out this week.
And the attack takes advantage of this.
It turns out that the people
designing TLS thought
that nobody could possibly think
of that time in timing channel.
But by doing many, many measurements,
millions of measurements, you can detect that
and that brings these padding
article attacks back to life.
And this is the current version of
the spec. So, the patch there is
to write even more complicated code in
your decryption library to fix that.
>> At least have the moment over the internet,
the latency and the [inaudible] is too much.
>> For that moment.
>> Yes. I wouldn't count
that on a ten-year plan.
>> I wouldn't count on that
for the six-week plan.
Especially now with the terror
attack coming out, and so.
I mean, but seriously I wouldn't
count on that because I think
that there are ways probably to amplify that.
And you know, this idea that you
have to be far away from things,
that's kind of an old-fashioned view, right?
'Cause in the old-fashioned view, we put
our servers way up here-- what's that?
>> Yeah if you're on the LAN, this
is a very valid concern right now.
>> But it's wrong and it's loud, our server is
here and where the three virtual machine's over.
So, it's very possible that
we're going to be a lot closer
to the attack server than we think we are.
So these kind of things may seem theoretical,
but they probably aren't in the long run.
Yeah?
>> So, in general, this is bad ways
to fix the crypto implementation?
>> Never apply band aids, yeah.
I mean if there-- sometimes they're
not a good way and then you're stuck.
You have to find the best bad way to pick from.
This is a case where doing this, really
would have saved all of these problems.
Because here, you check the MAC, and then no
matter what somebody does to the ciphertext,
none of these padding article attacks apply.
And they actually had a chance with TLS1.1 when
they broke compatibility with the older version.
They had the chance to do this.
They chose not to do it and now we're
stuck with this kind of stuff today.
So, that's one thing.
With the last detail, another bug that I
already mentioned is called is called BEAST.
It has to do with the fact that-- this
thing called an initialization vector
in CBC mode is not picked
correctly in TLS version 1.0.
I won't talk about it too much except just to
remind you guys that it was known since 2002,
described in I guess 2005, and
nobody really cared about it.
For years, it was found or discovered in 2011.
The last thing that I want to mention in this
section is that the practical solution is
to use a cipher that doesn't have
padding of course, a cipher suite.
The one that everybody loves
today is called RC4.
Does anybody here know about RC4?
Anyone here used RC4?
>> I know it's old.
>> Its old, it's developed-- it was developed
by Ron Rivest like 1984 of something.
Its-- [Inaudible Remark] It's
not older than me, but it's--
I was young when it was out and it was--
I actually have a demo, believe it or not,
this is a crypto presentation with a demo.
I'm going to show you something about RC4
that won't kill your terror
or anything but-- you know.
I wrote a little program.
So, here's the basic idea, RC4 has biased in it.
A proper stream cipher should-- basically
what it does, is it outputs a stream of bits
and then it XORs those bits with a message.
And the idea there is that that
XOR-ing of random-looking data
with the message should protect,
you should hide the message itself.
But it turns out that RC4,
the algorithm has biases.
Certain bytes that come out of it occur
with higher probability or lower probability
than a real random generator would.
Probably the biggest example is the second
byte of the output, always close to zero
with twice the probability it should.
Now, that seems like a tiny, tiny
little thing here, 256 possible bytes.
So, it produces zero with, you know probability
1 over 128 instead of probability 1 over 256.
How could that possibly be useful?
Well, it turns out that if you
have the same message encrypted
with many different RC4 streams, you can use
that bias to actually recover what's encrypted.
I wrote a program to do this.
This is only decrypting the second output byte.
I encrypted the value A 5,000
different messages.
I looked at the second output byte.
And this program which is not a 100
percent accurate as you can see,
is recovering what byte is
encrypted to that position.
Again, crypto demos suck.
But this is the best crypto demo I've ever done.
It almost always works.
And that would be a problem if RC4 only
had a bias at the second output byte.
But that's actually not the case.
RC4 has biases here at the
first-- this is zero index.
So the second output byte, the fifth,
the sixteenth, the 32nd and the 48th.
And I think some other ones later on.
So, little tiny biases admittedly, but biases.
So RC4 is an old cipher and these things
are going to buy those eventually.
>> Oh, they already did this
in the web [phonetic].
>> Yes, RC4 really did us some web.
That's why you should not use web.
But these things are still active in TLS.
RC4 is very popular and more
people today are even moving to RC4
because they are afraid of
these kinds of attacks.
Okay, so I'll spend a lot
of time on these sections.
So I'll just pick up the pace
'cause I know you guys are--
this is an OS class and I have to say something,
systems really did at some point, right?
So-- all right, I'm going to
skip the compression stuff.
I just want to quickly talk about analysis.
Okay, so a lot of you guys are
saying, here's the problem,
academic security is fine,
academic cryptography is fine.
But for some reason we have entrusted the design
of real crypto in the real world to a bunch
of people who don't really know what
they're doing and we're telling them
to do it right and they're not listening.
That's actually not the case.
So, cryptographers have been trying to
analyze TLS for years and trying to come
up with some kind of formal
method for proving them as secure.
This is one person's summary of what the TLS
protocol looks like in an academic paper.
Anybody who's looked at TLS ever know
what is missing from this diagram?
It starts out with people thinking random
numbers and then going right to a key exchange.
There is no negotiation.
There is no certificate exchange.
There is no exchange of any messages at all.
All the stuff that actually happens in the
TLS, that's been the place where it breaks.
So, academic analysis right now, we're still
looking at like cartoon versions of TLS
and we're still not making that much
progress in trying to prove them as secure.
To give you an example of this negotiation phase
where I say, I support AES and you support this
and I support RSA and you
support Diffie-Hellman.
The way it works now, is both parties say,
here are the cipher suites that I support.
And then once we agree on them,
once we agree on the algorithm,
then we do a key agreement using the
algorithm we just decided to negotiate on.
Does anybody see any potential weaknesses
or problems with this kind of design?
>> If someone pretends they
only know the worst possible.
>> Exactly or if something in the
middle does exactly what you described.
Edits out the messages where I say, I support
great crypto system and great crypto system,
and leaves only the one where I support, gimpy,
you know, terrible crypto system then we end
up agreeing on gimpy terrible crypto system.
This is a real problem in some versions of SSL.
>> Wasn't there a null cipher
available in [inaudible].
>> There is a null cipher, there
were export weakened ciphers
that only supports a 40-bit crypto because we're
afraid of exporting it to the rest of the world.
Just bad stuff-- bad stuff.
[Inaudible Remark] But we
fixed a lot of the stuff.
We fixed it in sort of kludgy, band-aidy ways
that nobody has really formally
analyzed they probably work.
But nobody has ever actually looked
at a crypto conference and said,
can we prove this particular
pattern to be secure?
You think that we've analyzed this, right?
We have all this crypto-confidence.
We have hundreds of publications every year,
a non-malleable zero knowledge
optimal round of proofs.
But there is only one recent publication
I know of it, the big crypto conference
that analyzed TLS with Diffie-Hellman
ephemeral protocol.
Nobody has ever done a formal
analysis of the RSA handshake
which is the one that everybody actually uses.
Okay. I'm running out of time.
So I'm going to move quickly,
'cause this is the fun part.
So everything up until now was the good stuff.
This was the stuff that we know how to do well.
Now, we're going to talk about code.
All right.
We have these specs but obviously you can't use
a spec any more than you could eat a recipe.
So, when you implement TLS, you end
up typically, you do it yourself
if you hate yourself or you use a library.
Examples here, the biggest most common one
are OpenSSL, GnuTLS which nobody really uses
and NSS which I think is used in Chrome and in
Firefox but on a few servers but not so many.
>> Pidgin uses the one you said, the one users--
>> What's that?
>> Pidgin-- chat.
>> Oh, okay.
So--
[ Inaudible Remarks ]
>> And it's like, why do you use that?
It's like, well that's what
our intern implemented.
>> Yeah, okay.
So, that's-- that deserves its own slide,
that-- our intern implemented it in 1995.
That is definitely a problem.
I'm also going to look at OpenSSL today because
OpenSSL is the most popular implementation.
But you know, there are other bad ones too.
How many people have ever
looked at the OpenSSL code?
[Inaudible Remark] I can tell, there is only
a couple of lines, 'cause you don't have
that wide-staring eyed look that people have
really "looked to the OpenSSL code" look.
Let me give you a fragment.
Okay. This is a good piece of OpenSSL code.
I just want to point you to a
couple of nice features, okay.
So I like to put curly braces
on some of my ifs just
because I think it's less confusing,
but whatever, maybe I'm picky .
I have never yet put an if zero around any code.
This is a code pattern that I have never
seen but they used throughout OpenSSL
to keep you I guess from
hitting error conditions.
It's a disaster.
You look like you're about to
say, "I use that all the time."
[ Inaudible Remark ]
It's very possible.
There is a talk of cleaning
up OpenSSL to the point
where you could run an auto-indent
program on it.
But nobody can get it [inaudible].
Because if you noticed, the
indenting is also crazy.
This is an example.
But actually, I'm going to break
out and I'm going to show you 'cause
that example doesn't do it justice.
So, let's get-- let's get the next code up
here 'cause I brought my favorite piece.
Okay. So, this is a function.
A very important function in the SSL handshake.
[Inaudible Remark] Well, if I zoom it, well
you won't get the complete effect of awfulness.
But let's see if we can-- oh God--
unfortunately, I'm not even sure how
you change font sizes in [inaudible].
I probably have to go to preferences,
and, there you go, fonts, oh my God.
I tried to be dummy.
Oh man, well I'm sorry.
I just-- just--
>> You can make it full screen and--
>> Yeah, maybe I can, here--
maybe I'll make it bigger.
This is going to end up being horrible.
Come on, why can't I make it bigger?
Can I just select all, oh man.
Yes! Okay now what I'd do, here we go.
Font, here we go.
Let's get you get up to 18 point and close.
All right.
Okay. So, let's start-- here is the
top of the function, SSL3 connect,
and [inaudible] can scroll quickly and
you guys get a shout when you see the end.
Look, if open this little [inaudible].
And if you see any if zeros, let me know.
Okay. We're still not at
the end of the function.
But we are going to get there
soon, oh no we're not.
Okay, we're still not there.
Come on. Okay, this is the guy that should
get it tiring here, let's go a little faster.
There, there we go right there, that's the end.
Not even intended all the way down
to the end, but that's OpenSSL
and that's still good code,
there's worse in OpenSSL.
And it's very hard to tell
what code is even being used
and what code is buggy because it's just a mess.
>> [Inaudible] paper.
No function should be longer than you were told.
>> Yeah, this-- some functions in here are
longer than like everybody in this room,
lying down on the floor would be together.
There is a bad stuff.
There is also some really
funny comments in there.
This is my favorite, you
can't read it from back there,
blah-blah-blah-blah we should change
this, this would obviate the ugly
and illegal kludge in crypto memory-leak cb.
Otherwise, the code police will come and get us.
Some of the variable names, sometimes
they don't even bother with the comments,
they just straight up clear
what their-- their variable.
But these are all minor things.
There are a couple of actual
serious-- serious problems here.
So let's talk about a real serious problem.
A real implementation, what's that?
[Inaudible Remark] Nobody knows, nobody
will admit to being an OpenSSL developer.
It's like a weird secret club.
I know two people who would now work on it.
But the rest of them, they don't like talk
in public, they don't like it's weird.
And it's actually worse for NSS.
I don't even know who does NSS.
Okay. So, this is the spec for TLS1.2.
That's the most recent version of TLS.
Here is-- this is RSA decryption by the way.
This is a very important
part of the RSA handshake.
Step 1, generate a string of
46 random bytes, simple enough.
Step 2, decrypt, this is the RSA message
to recover the plain text M. Simple enough.
Now, this uses a padding scheme
called PKCS1 V15 padding.
If the padding is not correct
or if something else goes wrong,
what you do is you use this random string, R,
that you generate in the first step instead
of the message you would have gotten now.
This prevents a particular attack that is
very similar to this padding article attack
that we described up here
about works on RSA encryption.
This is an attack that can be
given a few a hours-- let somebody.
If they are able to find out, if the
message decrypts with bad padding,
they can actually decrypt any RSA plain text.
So this is a very serious attack.
Their countermeasure is to first
generate a string of random bytes and then
if there's a problem with the padding, just use
those random bytes silently, instead of the ones
that you'd ordinarily get
and not produce an error.
So it's very similar to what
we are talking about here,
where instead of producing a padding error,
we kind of just go ahead with the protocol.
Simple enough.
How much you attack a protocol
like this if you are an attacker.
It's not giving you an error, but you
want to find out if something went wrong.
Or you might hope that what these people are
doing is not generating the random string first,
but rather, waiting until they get a padding
error and then generating a random string.
Because that might take a little extra time
and that might lead to a timing attack.
Nobody would be stupid enough to
do that, would they-- would they?
Okay, good.
So here we go.
This is OpenSSL version 1.01C.
This was the current version
up until a few weeks ago.
It's still the current code as far as I know.
Step 1 is decrypt.
Step 2, if the decryption fails,
generate a bunch of random bytes.
And then finally-- do this stuff.
I had a grad student who runs some experiment
with the last week and he was able to get--
no, not big timings, but 20
microsecond timing, which are big enough,
that with multiple samples, you
can detect them over a network.
You can actually probably
implement a real attack
on real deployed OpenSSL today
using this vulnerability.
And certainly, any kind of embedded device
that uses this code is really in danger.
And I've notified the people
with this, but they don't care.
And they're not going to care until somebody
codes up an exploit and actually does it.
>> You need a cool acronym.
>> I know, what do you think?
Let's have-- let's have a brain storm
session about that after the presentation.
It has to be something better than terror, so.
So these are real bugs that--
>> Eagle. The American.
>> Errors in, anyway.
>> Yeah, given that these guys have been
releasing those things in Argentina.
>> Yeah, I know--
>> Juliano Rizzo?
>> Echo parks, which I can't
seem to be able to make.
>> Yeah, is that a real conference or they just
made it up so they can put it in Argentina?
>> It is in fact a real conference.
I mean, two years ago, it
was absolutely fantastic.
>> Okay.
>> Last year, you know, it was pretty damn good.
>> Okay, so it's-- you're really excited
about it, like a laser and some stuff
that they present in their SSL [inaudible].
>> Yeah and they have this strange like
communist symbol schemes, you know,
arms grabbing or red arms grabbing.
[ Inaudible Remarks ]
>> A couple of other things, I
guess I didn't finish with this.
Not only does it generate random bytes,
but there's thread-locks [phonetic] all
around this random number generator which
means if you get two of them to hit each other
on a multithreaded implementation,
you could probably expand that.
The good news is that NSS does
not have a set of thread-locks.
They have two, so this problem is
not isolated actually to OpenSSL.
It's in all in these libraries.
This one-- I'm running out
of time, just another--
this is another good how not
to implement code example.
Hard to read so I'll just example quickly.
When you're doing a signature comparison
for certain kinds of signature,
the recommendation is, you put your expected
value in a buffer, and then you do the RSA stuff
and then you get a value and
you compare the two buffers.
You do not do the RSA thing and then pars
to see if the thing is correctly formed,
not that because it's easy to get it wrong.
OpenSSL, instead of doing something that would
be two lines, does it with, you know, with 20.
So this is the kind of thing
you see throughout OpenSSL.
Now, these problems are not limited solely.
I promised that I was going to talk about APIs
and ABIs a little tiny bit,
so I'm going to try that here.
These problems are not limited to
the internals of the code which would
at least be forgivable or understandable.
The APIs OpenSSLs are still difficult to use.
And there was a paper that came out
sometime in the last few months called,
"The most dangerous code in the
world validating SSL certificate
to non-browser software" from Stanford.
And what they did basically is they
went through a huge pile of Android
and OpenSSL-using applications to look for
people who are not doing SSL correctly.
>> All of them?
>> All of them?
Essentially, they found like 99.7.
>> All day at my job.
>> Yes.
>> No one can do this right.
>> That's basically it.
So a lot of people-- I don't even know--
>> Twitter does it right?
>> Twitter does it right, okay.
>> That is one exception.
>> You think that this would
be important, so the idea is,
you have to use the API correctly,
how to check it.
If you turn on certificate verification,
you have to check all these
things, but people don't do it.
And just by doing static analysis, they were
able to find a lot of people who weren't.
The reasons are two-fold, one is
that people do testing, I guess.
And they checked to see, you know, if you
don't have an SSL certificate installed
in your server, well, what you're going
to do just for your testing, right?
You're going to flip that off.
You're going to not check the certificate
and then you're going to run your test.
And then inevitably, you're going to
forget to turn it back on and you're going
to shift the code without having it-- check
the SSL search and that happens a lot.
The other reason though, you can completely
blame an OpenSSL because you would think that,
in most places, if you had an INT enable flag
on a API, there would be two values for that.
One would be, one yes-- well
actually, there'll be two values.
One would be zero, no and then
anything else will be yes.
It turned out that there are
three values and I'll describe.
This is actually a problem with C-U-R-L CURL.
CURL is an option called SSL VERIFYHOST.
When at zero, it does exactly
what you'd expected.
It doesn't verify SSL certificates.
When it's two, it verifies SSL certificates.
When it's one, it does something really weird.
It checks the certificate kind of like half way.
It checks to see-- even to search any host names
and then accepts the certificate
no matter who gave it to you.
So it checks the certificate,
but it doesn't care
if it's actually a certificate
to the site you're visiting.
So simply bypassing one which is the expected
value, you can completely misuse this library
and make yourself vulnerable
to man-in-the-middle-attacks.
So this is just stupid and this
happens all over the place.
And part of the reason that happens is
that using any of these use of software,
even if the API level is very complicated.
Here's an example of doing
encryption with OpenSSL.
Mostly, this is involved with pulling an
RSA public key off a disc and using it.
It looks kind of like OpenSSL code does, right?
It's, you know, like crazy.
It's complicated.
This is hard to use and people make mistakes.
This is kind of a space-shuttle version
of how you get things encrypted.
A better way to do it would be something
like the library NaCl does it, which is,
don't make people think about algorithms.
Give them a low, a high-level API like this one.
It's called CryptoBox where you basically
just pass it some strings and you say,
encrypt this stuff, and it does everything
for you with the right algorithms.
You don't have to think about it.
And so this is something that hopefully
we will get better at doing in the future.
Yes?
>> Is that an issue in the real world,
and they want to optimize, you know,
Crypto and that's why they'd only use libraries?
>> I mean, no.
I mean, people wanted to use libraries, but--
[ Inaudible Remark ]
People use the library that is the most popular
one out there, and the fastest one out there.
So I guess that's what you're saying is
the one that has the best optimizations.
They don't care if it's a
terrible crappy library.
If it encrypts a yes, no, 10 percent
faster, they might go for that.
That's a reason.
That's definitely a reason.
But the real reason is there are
no good, well-supported libraries
out there that do everything right.
You have a choice of being very well-supported
with lots of people working on it in bad,
and not very well-supported and not,
you know, deployed very much and good.
And that's something that's need to change.
>> And that of course, where it develop
in time, would kill your company.
>> Yes. You can't afford-- yeah,
you can't afford to do things right
if it hurts you and cost your mind.
How much time do I have?
Am I overtime now?
>> Uh-hmm.
Technically-- technically, this is it but
you can probably have another few minutes.
>> How many guys have to run to a
class 'cause I need to-- all right.
I'm going to take two more
minutes-- two more minutes.
The last thing I want to talk about is so simple
that it'll only take a minute
and then I can say thank you.
This is kind of a typical experience
if you ever go to a secure website.
This is just human beings.
After all, even if you get all the technical
things right, this is what actually happens
when most people go to a secured website.
You don't type HTTPS American
Express dot com in.
You type in americanexpressdo.com.
And almost always what happens
is your browsers goes first
to the insecure American Express dot com site
where then it gets redirected
to the secure site.
And from there on, you're great.
Now, this is a big problem.
Anybody who's on the wire at this
point can change this redirect.
They can do anything they want to you in
between so you don't go to that secure website.
This is starting to change with the introduction
of protocols like HSTS which are hacks
that basically tell your browser,
any time you go to American Express
after the first time you go there.
Always go to the secured site and reject any
attempt to make me not go to the secure site.
So, we're fixing this problem.
But this impractice turned out to be more
important than all of these, you know,
fancy crypto attacks that I've told you about.
And then here's one last really, really
stupid one that I love, which is that,
a lot of the time, this is what a
secured website should like, right?
You want to have a little
something in the corner that says,
"I'm secured" with a little lock.
But, let me move over-- sorry.
We moved already these examples that
I have 'cause I'm in the wrong page.
This is a big example of what often
happens on websites today, which is that,
people stick a lock, you know, on the page
itself and say, it's a secured website.
This is an actual Wachovia page [inaudible] year
old, where they didn't actually serve the page
over HTTPS, but they did put a lock on the
actual HTML of the page to make you feel better.
And this kind of stuff is just you know.
>> I did check, the host is HTTPS.
>> But, it doesn't matter.
If I get the page itself, I can
make a post to anywhere I want.
>> Yeah.
>> So it's just, you know, this kind of usage
problem turns out to trump all the good stuff
that we're doing, but we're finally fixing it.
And so that gave me 30 seconds
to give you my last slide
which I think sums up this entire talk.
Actually, what I'm not saying is we're all good.
I think there's a lot of good news.
We're getting better at building these systems.
We're getting better analyzing these systems,
but I don't think that cryptographers
really take it seriously enough.
Academic cryptographers are off doing
multi-party secure round optimal zero knowledge.
They don't realize that the real world--
that cryptography is not a branch
of theoretical computer science.
And that we-- and that means all of us including
people who are, you know, not grad students,
but thinking about it someday,
should be thinking
about these problems because
they actually matter.
And so that's it.
So thank you guys.
[ Applause ]
>> In the class, we are going to
be looking at synchronization next.
And you will have fun measuring
various executing [inaudible].
And implementing the-- one of these
timing effects would make a good choice.
So long as you would appropriately instrument--
>> Yes, yes.
>> The code.
[Inaudible Remarks]
>> So, well, we're still [inaudible]
for question for people who aren't--
[ Inaudible Remarks ]
>> OpenSSL's use is so popular,
I find out there is some kind
of problem emerging trying to [inaudible].
I'm really sure there's going to
be something more secure in the--
>> So you think that should be or you--
>> I think it should be.
>> I absolutely agree with you.
I think the people who write OpenSSL
don't and I'm not joking now.
I think they really don't
want to be doing it anymore.
They want people to be using another library.
The problem is, there just isn't a good
alternative to move to it right now.
So what people should be doing is either
take it over and really fix it or find one
of the other libraries and take it over.
I agree with the problem.
[ Pause ]
[ Inaudible Question ]
I have no idea.
I don't think that they realized.
I don't think they realized how much they're
relying on OpenSSL and I think they do rely
on OpenSSL a lot more than they know.
I just don't think it's even on the
radar that these attacks were important.
So I don't know how to say to that one.
[ Inaudible Remark ]
>> Where, on most parts, it's just the
awareness that's actually mattering
and still growing 'cause we do have
some customers that are really difficult
and just don't understand that these things
are even important and they're kind of--
probably that they're even
spending money on to begin with.
>> Yeah, that's-- I mean they
have the money, but they-- right.
This is where they want to spend it.
Yeah.
But they're not shy about spending it.
It's just that they don't want
to do other things with it.
>> There must be an awareness because out
of a risk mitigation in terms of marketing,
they do not tell us they're being attacked.
>> A lot of our customers, if someone in
the organization that has influence says,
we are taking 10,000 dollars
and paying for security audit.
And then the people we have to
work with are like, this is dumb.
I don't see.
This isn't that important.
This [inaudible] can't be practically
exploited on and on and on and on.
And like, we're just here because
our manager decided we're doing this.
>> Yup. Like a lot of that too and
it's one of the reasons I don't
like to do that kind of consulting anymore.
There's people who really-- yeah.
First of all, there's an attitude that if
you can't exploit it, it doesn't exist.
Which is why people have spent all this time
developing this, you know, BEASTs and terrors
and all the stuff just to prove
that things we knew were broken
in the first place, need to be fixed.
And then the other problem is yeah, people
feel like their managers are pushing them--
at least their managers are pushing
them into getting a security audit.
At least in, you know, at least
you're looking at the good stuff.
>> Yeah.
>> The bad stuff is this
stuff that you're not seeing.
