►
From YouTube: How Many CPU Cycles I Need to Invest in Cloud Native Security? - Ben Hirschberg, CyberArmor
Description
Don’t miss out! Join us at our upcoming events: EnvoyCon Virtual on October 15 and KubeCon + CloudNativeCon North America 2020 Virtual from November 17-20. Learn more at https://kubecon.io. The conferences feature presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
How Many CPU Cycles I Need to Invest in Cloud Native Security? - Ben Hirschberg, CyberArmor
TLS is the de-facto standard protocol for creating point-to-point secure communication between applications. Ideally, it should be used on every application all the time; however, the industry has a love-hate relationship toward TLS. Now, we need to protect traffic between our microservices. TLS presents additional deployment complexity and operational costs, such as considerable CPU use and high maintenance of keys and certificates. How do sidecar proxies fare against native application implementations? Which TLS implementation to use? How can TLS be optimized to deliver security and performance? In this talk, we will present an in-depth performance review of TLS over different cryptographic suites, different implementations, and different deployment models from the perspective of practicality.
https://sched.co/ZerP
A
A
A
A
A
Okay,
so
what
is
tls?
I
don't
want
to
speak
too
much
about
it,
because
this
is
not
a
security
lecture.
I
assume
that
you
have
some
knowledge
of
tls,
but
just
for
the
sake
of
of
the
discussion,
centia's
security
communication
protocol
today
it
it
contains
nearly
all
almost
interesting,
secure,
proto
security
features
which
we
need
in
a
secure
connection
protocol.
We
have
confidentiality
encryption
integrity,
which
is
message,
authentication
authenticity
where
we
can
validate
the
communicate.
A
And
going
forward,
what
we
need
to
understand
is
what
are
the
parts
which
are
building
up
tls
in
order
to
understand
how
much
we
need
to
invest?
We
have
to
break
the
protocol
into
the
into
the
part,
its
parts
and
see
which
parts
does
what
and
how
much
time
it
takes.
So
the
handshake
protocol
is
is
the
first
part
of
anything
as
connection
establishment.
A
A
What
it
does
is
is
authenticate
that
we
are.
We
are
really
talking
to
one
to
whom
we
wanted
to
talk,
and
the
second
important
part
is
that
it
creates
what
we
call
a
session
key,
so
handshake
protocol
is,
is
results
in
two
things
main
things,
one
is
the
authentication
of
the
peer.
The
second
is
the
creation
of
a
session
key
now.
The
session
key
is
a
symmetric
key.
A
Point
of
view
of
the
tls
protocol,
is
actually
the
part
where,
where
tls
takes
the
application
data,
let's
be
html
or
grpc
or
any
other
kind
of
tcp
based
protocol
and
wraps
it
in
a
secure
enclosing,
encrypts
the
data
and
and
creates
a
message,
authenticating
authentication
code,
which
enables
the
other
side
to
validate.
They
really
got
the
original
message
it
wanted
to
get,
and
this
is
done
using
symmetric
cryptography
using
the
session
key
created
in
the
handshake
protocol.
A
The
third
part
of
of
the
cs
protocol
is
alert
protocol,
which
is
not
really
interesting.
For
the
sake
of
of
our
discussion
today,
but
but
for
the
completeness,
I'm
telling
you
that
there
it
exists
in
our
particular,
it
doesn't
have
to
really
do
something
with
cryptography.
It's
only
a
way
to
alert
the
other
side
that
something
really
went
wrong
with
with
the
signatures
or
or
other
parts
of
of
of
the
henship
or
the
application
protocol.
A
So,
as
I
told
you,
we
are
going
to
mostly
talk
about
about
cpu
today
and
I
wanted
to
give
you
an
outline
of
of
in
computational
in
intensity
of
of
the
ng
protocol
application
protocol
as
the
opening
of
our
discussion.
If
you
look,
we
look
at
tenshi
pro
coins.
How
much
cpu
it
needs,
as
I
told
you
before,
it
is
based
on
asymmetric,
cryptography
and
asymmetric
cryptography
takes
time
and
it
takes
cpu.
A
So
it's
for
a
short
time,
but
it
loads
the
cpu
really
pretty
heavily
relatively
and
and
and
this
has
been
taken
into
account.
On
the
other
hand,
the
handshake
protocol
itself
doesn't
use
a
really
much
ram.
I
mean
it
uses
a
few
kilobytes,
but
but
it's
not
something
that
really
worry
us
all
together
and
also
from
networks
perspective.
The
handshake
proco
is,
is
taking
a
a
few
kilobytes
at
the
beginning
of
every
session,
opening
which,
if
we
compare
against
pure
tcp
connections,
which
was
you
know,
a
few
tens
of
bytes.
A
On
the
other
hand,
if
you
look
at
the
application
protocol-
as
I
told
you
before
this,
a
symmetric
cryptography
of
the
application
protocol
is
rather
relatively
less
cpu
intensive,
but
obviously
this
has
to
take
into
account
the
the
the
number
of
bytes
which
is
being
transferred
over
the
application
protocol.
So
if
we
take
the
handshake
protocol
is
given
every
connection
open
is
this
is
a
constant
number
application
protocol
cpus.
It
depends
on
the
number
of
bytes,
which
is
meant
to
be
transferred
over
the
connection.
A
A
A
They
want
to
verify
that
they
are
talking
to
the
right
server
and
there
is
no
real
point
on
validating
the
endpoint
identity
at
this
stage,
so
it's
one-sided,
tls
and
and
and
usually
we
terminated
somewhere
at
the
beginning,
because
usually
application
load,
balancers
ingress
controllers,
usually
want
to
look
into
the
tls
traffic
into
the
traffic,
the
application
level
of
the
traffic
in
order
to
do
intelligent
stuff.
On
the
other
side,
we
have
the
east-west
traffic,
okay
and
up
until
the
cloud
transition.
Okay,
we
usually
is
closed.
A
The
east-west
traffic,
within
a
firewall
in
into
a
perimeter,
but
today
going
into
the
cloud
native
world.
Okay,
these
old
parameter,
setups
and
concepts
are
less
and
less
elastic
and
expandable.
And
therefore
we
are.
We
see
that
more
and
more
that
that
the
east-west
traffic
needs
to
be
protected,
because
there
is
no
clear
perimeter
around
it.
There
are
three.
I
three
examples
which
I
brought
in:
how
to
do
east
west
set
up.
A
And
therefore
we
have
our
service
mesh
solutions
like
istio,
which
are
using
side
cars
and
within
cyber
armor.
We
are
using
for
the
same
purpose.
We
are
using
what
you
call
the
inline
based
setup,
where
we
are
not
using
a
a
sidecar
proxy,
but
we
are
adding
an
extra
component
to
to
the
to
the
process
in
order
to
upgrade
existing
connections
to
tls
and
both
in
history
and
our
case.
We
are
managing
the
certificates
and
and
private
keys
instead
of
the
application
developers
or
the
operators.
A
Okay.
Well,
in
this
east-west
case,
we
see
more
dominance
of
of
mutual
tls
use
case
where
both
services,
which
are
talking
to
each
other
authenticating
themselves
to
each
other.
Okay,
and
we
have
to
know
here
that
both
mutual
tls
are
adding
extra
cpu
usage
because
of
the
secondary
authentication
and
the
sidecar
proxy
is
adding
sram
and
cpu
usage
to
the
system.
A
So
my
simple
setup
started
from
from
adding
using
apache
j
meter
against
a
simple
nginx
static
web
server.
I've
used
different
file
sizes
in
the
static
web
servers,
one
byte,
one
kilobyte,
one
megabyte
and
hundred
megabytes,
and
I
gave
it
four
cpus
per
per
microservice
and
I
started
to
run
my
bench.
My
first
benchmark
and
I
got
to
image
a
really
dramatic
initial
results,
because
what
I
saw
that
that,
if
we
are
going
moving
from
from
clear
to
to
to
tls
are
our
performance
is
dropping
very
rapidly.
A
A
This
is
for
for
server
certificate
validation,
but
if
we
are
doing
mutual
certificate
validation
by
two
sides,
then
obviously
the
client
cpu
time
goes
up.
Also
server.
Cpu
time
goes
up
a
little
bit
and
I
got
a
to
sorry.
I
got
to
the
measurements
of
of
2.5
milliseconds
per
side,
calculating
the
tls
handshake.
A
I
did
the
same:
try
to
them
make
up
same
rough
numbers
for
for
the
application
protocol
when,
in
the
application
protocol
we
do
encrypt
every
byte
and
and
hash
them
also
to
create
a
message:
authentication
code.
I
got
to
the
numbers
of
of
of
250
megabytes
per
second
for
an
as
256
per
bandwidth
and
for
message,
authentication
like
300
megabytes
per
second
for
shell
3
to
56,
okay,
and
these
are
rough
numbers
and
we'll
try
to
improve
it
at
the
end.
A
A
So-
and
this
is
sorry
this
is
going
to
be
the
hardest
part
of
of
our
discussion.
I
hope
it
is
not
that
hard,
but
I've
created
a
small
and
simple
simple
formula
for
calculating
this
ts:
overhead.
Okay,
I
took
into
account
the
number
of
transactions
I
want
to
make,
which
is
m.
The
h
is
the
client
or
the
server
side,
the
cpu
time
we
need
for
the
handshake
s
is
the
encryption.
A
Bandwidth
and
t
is
the
bytes
in
one
transaction
and
using
this
formula
I
want
to
calculate
the
overheads
of
tls
of
how
much
time
I
need
for
ex
for
n
transactions
to
calculate
tls
or
on
the
other
hand,
I
can
calculate
also
an
invert
this
this
formula
and
I
calculated
how
many
transactions
I
can
make
make
in
a
given
time.
So
using
using
this
formula,
I
could
represent
what
we
need
to
know
and
what
you
need
to
calculate.
A
A
A
A
When
I'm
using
my
formula,
I've
got
a
and
calculated
how
much
time
I
need
cpu
time
I
need
to
to
for
these
transactions.
I
saw
that
I
got
a
25
seconds
for
5
000
requests,
which
is
you
know
it's
if
you
for
the
first
blink?
It's
it
it's
a
lot
of
a
lot
of
overhead
and
we
understand
that
the
main
component
here
is
the
handshake
protocol
itself.
A
Now,
if
we
look
into
the
handshake
protocol,
how
we
can
improve
the
handshake
protocol
itself
at
the
first
step,
we
have
to
understand
what
kind
of
of
algorithms
we
are
using
in
the
handshake
protocol
and,
as
I
told
you
before,
we
are
using
eptic
curve
dp
element
for
the
key
exchange
algorithm.
There
is
no
real
contest
here,
because
the
other
we
could
use
rsa
but
are
using
rsa
for
key
exchange.
Algorithm
has
what
we
call
forward
secrecy
problems.
A
My
old
traffic,
if
I'm
using
what
I
could,
what
we
call
forward
secrecy
algorithms,
like
diffie
element,
it
means
that,
even
if
someone
steals
my
key
in
the
in
a
year,
it
won't
be
able
to
decrypt
all
all
the
traffic,
and
this
is
obviously
very,
very
preferable
today.
So
therefore
it
is,
we
prefer
to
use
optic
curved
dpl.
A
Also,
the
keysight
key
exchange.
Signing
algorithm
is
rsa
with
the
with
key
size
of
of
two
kilobits,
with
sha256
the
same
for
the
certificate
validation,
and
these
are
the
smallest.
These
are
actually
more
or
less
the
default
numbers
today,
and
I
have
to
tell
you
that
that
going
from
down
there
using
a
smaller
key
sizes
and
all
their
hashes
is,
is
really
going
to
hurt
your
security.
Therefore,
there
is
not
really
much
space
here
to
to
to
improve
your
handshake.
A
A
But
on
the
other
hand,
after
the
creation
of
the
phone
first
handshake,
you
don't
really
need
to
add
more
to
your
to
your
current
transactions
and
it's
very
very
fast.
The
same
with
the
pre-shared
keys.
The
pre-shared
keys
is
a
is
a
protocol
where
you
can
use
tls
with
symmetric
trees
pre-shared
among
the
parties.
It
is
very
fast.
A
The
same
enables
also
even
the
first
connection
to
be
done
without
the
full
key
full
key
exchange,
but
but
it
really
has
a
big
burden
of
of
pre-sharing
symmetric
keys,
and
it's
it's
a
really
big.
It's
not
an
easy
solution,
so
I
it's
not
really
good
for
for
our
cloud
native
environment,
so
just
to
show
you
that
if
we
assume
I
returned
to
my
previous
calculation
with
the
formula
and
assume
that
we
have
a
session
ticket
and
our
handshake
time
is
going
down
by
an
order
of
magnitude.
A
Okay
from
at
two
and
a
half
milliseconds
to
to
the
10th
time,
we
can
see
that
also
the
the
time
we
need
to
complete
the
full
5000
handshake.
5000
connections
is
2.1
seconds,
which
is
less
than
obviously
a
very
good
improvement
here.
So
so
appreciation
tickets
are
really
really
good
for
for
performance.
A
Talking
about
the
application
protocol,
the
application
protocol
is
is,
on
the
one
hand,
it
can
be
improved
and
it
has
a
big
effect,
especially
on
on
on
applications
which
uses
big
big
chunk
of
memories
transferred
between
the
two
parties.
Mostly
today,
more
most
new
cpu
is
supporting
asni,
which
gives
you
a
fantastic
throughput
as
hardware
supported
in
most
intel
chips.
Make
sure
that
your
applications
are
are
using
it
and
and
using
asni,
because
it
improves
your
performance
very
much
in
the
application
protocol.
A
A
The
the
questioner
asked
that
says
that
I
heard
that
ecdsa
is
less
cpu
intensive
on
the
server
side,
but
more
intensive
on
the
client
side.
So
this
scenario
where
so
in
a
scenario
where
both
of
the
client
and
server
is
located
in
our
data
center
service,
the
service
mutual
tls
is
ecdsa
really
beneficial
over
tsa
or
rsa.
A
So
it's
a
really
good
question.
There
are
actually
two
two
things
to
to
think
about.
One
is
the
security.
Okay,
as
I
said
in
the
presentation,
are
using
ecl
dsa
for
for
a
key
exchange
algorithm.
It
has
a
big
benefit
from
the
security
side.
So
you
don't.
You
have
forward
secrecy,
which
means
that
if
someone
records
today,
your
conversation
cannot
decrypt
it
but
will
be
able
to
take
your
keys
steal
them
in
a
later
phase.
He
will
able
to
decrypt
them
if
you
are
using
rsa.
A
A
But
again,
the
question
here
relates
more
to
service
to
service
mutual
tls
case
where
in
the
same
data
center,
I
think
that
that
that
using
rsa
elliptic
curves
doesn't
really
have
a
beginner
effect,
because
on
the
other
hand
the
server
will
work
harder,
and
if
this
is
a
symmetric
case,
I
I
would
say
that
there
won't
be
here.
A
big
performance
improvement.
A
A
A
But
if
we
can
say
that
that
the
that
we
are
holding
one
side
of
the
conversation-
and
we
want
to
take
its
performance
into
the
context
like
if
you
have
an
endpoint,
which
is
low
power,
consumption
device
or
any
kind
of
other
device
which
is
limited
from
the
computational
perspective,
rsa
has
a
good
tweak.
So
there
is
here
no
a
black
and
white
answer,
but
really
you
know
it's
a
nice
engineering
question
which,
where
the
application,
the
specific
parameters
of
the
specific
application
has
to
be
taken
into
the.