►
From YouTube: Enhancing Envoy: Certificate Handling at the Edge - Brian Redbeard & Bill Decoste, Red Hat
Description
Join us for KubeCon + CloudNativeCon in San Diego November 18 - 21. Learn more at https://bit.ly/2XTN3ho. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy and all of the other CNCF-hosted projects.
Enhancing Envoy: Certificate Handling at the Edge - Brian Redbeard & Bill Decoste, Red Hat
For many users the nuances of SSL/TLS engines are fuzzy and differentiation is based on marketing terminology. To understand why some users desire (or require) the use of a specific public key infrastructure (PKI) toolkit we will analyze the work recently completed around adding support for OpenSSL to Envoy. In discussing this work we will outline how it enables cryptographic conformance with regulations like the United States Federal Information Processing Standard (FIPS) 140-2 and how it benefits the community at large. Participants should have familiarity with proxy servers so that they can follow along with the presentation.
https://sched.co/Nrpj
A
So
it
is
exactly
11:45,
so
we
should
go
ahead
and
get
started,
so
we
are
here
to
continue
talking
about
envoy,
specifically
I'm,
going
to
talk
or
work
Bill
and
myself.
We're
gonna
be
talking
about
some
of
the
OpenSSL
handling
that
we've
been
doing
within
envoy
and
to
kind
of
get
into
this
a
little
bit.
That's
me
folks
tend
to
call
me
red
beard.
Red
beard
is
not
my
given
name,
but
if
anyone
can
help
me
understand
why
I
get
called
that
that
might
be
useful.
A
B
Costume
everybody
build
the
cost.
I
got
a
kick
out
of
this
picture
because
this
was
also
taken
back
in
the
openshift.
The
two
days,
pre
kubernetes
pre
containers
that
pictures
really
old,
so
I've,
been
at
Red
Hat
for
I,
actually
came
over
the
JBoss
acquisition.
So
it's
probably
14
years
now,
we've
been
around
for
a
while
and
I've,
been
the
worker
be
sort
of
the
engineer.
Who's
done,
the
the
actual
development
on
replacing
boring
SSL
in
envoy
and
NIST
EO
proxy,
with
with
Red
Hat.
This
sort
of
Red
Hat
certified
open,
SSL
libraries.
A
So,
as
mentioned,
we
are
both
from
Red
Hat.
We
are
here
to
talk
about
a
piece
of
software
that
were
here
to
talk
about
work
done
on
a
CNC
F
project,
specifically
envoy,
at
least
I
should
hope
that
you
picked
up
on
this.
Being
you
know
about
envoy,
if
that
wasn't
obvious,
there's
tragically
not
too
much
I
can
do
for
you,
but
let's
start
out
act
once
this
is
a
bit
of
a
kind
of
securities
route,
so
this
is
actually
the
tale
of
two
cryptographic
libraries.
A
These
topics
may
sound
boring.
If
so,
let's
blame
it
on
the
reason
Bill
and
I
are
even
here
talking
to
you
today,
which
is
specifically
a
library
called
boring
SSL.
So,
if
you're
like
me,
you
probably
find
cryptic
cryptography
pretty
interesting,
hopefully,
during
the
course
of
this
presentation,
some
of
the
nuances
we'll
be
talking
about
will
shed
light
on
how
one
library
can
actually
matter
so
much
we'll
also
be
talking
about
open
ssl
and
the
differences
between
that
and
boring
ssl
we'll
need
to
if
we're
gonna
make
any
sense
out
of
this.
A
So
where
are
we
going
with
this?
For
many
folks?
The
difference
is
between
these
two
pieces
of
software
lies
somewhere
between
being
transparent
and
irrelevant.
This
may
even
lead
you
to
be
asking
where
I'm
actually
going
with
this.
You
know
like
is
this
even
important?
There's
a
lot
of
great
content-
that's
happening
here
today
and
if
you
don't
care
about
the
nuances
between
boring,
ssl
and
open
ssl
I'd
ask
that
you
seek
out
a
talk
that
actually
resonates
with
you,
but
for
the
folks
that
do
stick
around.
A
I'm
sure
that
you
know
some
of
this
will
be
interesting,
even
if
you
still
don't
think
it's
important
by
the
end,
but
digressed
a
bit.
Let's
get
everything
back
on
track
and
go
back
in
time.
Specifically
we're
gonna
go
back
to
the
1990s
a
more
simple
time
before
encryption
on
the
World
Wide
Web.
So
in
the
1990s
Netscape
brought
us
SSL
secure,
socket
layer
x',
then
the
intention
was
actually
just
to
make
consumers
comfortable
with
using
the
credit
card
on
the
actual
Internet.
A
Then,
after
that
we
end
up
with
TLS,
so
the
successor
to
SSL
was
TLS
or
transport
layer.
Security
TLS
made
modest
attempts
at
being
backwards,
compatible
prior
to
TLS
version
1.3.
It
was
fundamentally
double
technology.
One
of
the
most
important
differences
is
that
all
operations,
both
clear
and
protected
in
TLS,
happen
over
a
single
port
and
that
connection
upgrades
to
secure
communications
and
SSL
and
TLS
are
fundamentally
different.
A
This
means
that
there
was
never
really
any
interoperability
between
those
which
caused
the
number
of
problems,
the
biggest
of
which,
in
my
opinion,
is
specifically
that
SSL
and
TLS
are
often
conflated
in
practice.
You
pick
one
or
you
pick
the
other
with
the
majority
of
web
components
today
using
TLS
predating.
All
of
this,
though,
we
have
two
other
sets
of
standards.
Pkcs
and
x.509.
A
Pks
pkcs
stands
for
public
key
cryptography
standards,
and
these
were
all
introduced
by
a
committee
called
RSA
corporation
pkcs
were
not
industry
standards.
They
were
kind
of
there
to
promote
the
products
from
RSA.
Fortunately,
they
paved
the
way
for
a
pretty
broad
range
of
standards.
We
use
across
computing
like
messaging
message:
encryption,
transport,
encryption
and
secure
time,
stamping,
etc.
I
am
going
to
get
a
drink
of
water
here.
A
A
A
So
pkcs1
this
is
actually
relevant,
though,
like
I
said,
Security's
room
defies
a
standardized
set
of
grammar
for
the
mathematics
and
formatting
of
RSA
keys.
Pkcs7
defines
the
basis
for
the
subsequent
cryptographic
message,
syntax
or
CMS,
which
is
the
IETF
standard
for
securing
messages
on
the
Internet
CMS
is
currently
ratified
in
RFC
56
52.
Beyond
that
we've
got
pkcs12,
it's
a
container
format
used
to
encapsulate
public
and
private
key
material.
A
It's
used
a
lot
for
bundling
those
public
and
private
keys
with
things
like
java
key
stores,
and
it's
also
known
as
a
PF
X
file
and
gets
used
by
Microsoft,
Outlook
and
web
browsers
and
whole
bunch
of
other
things.
The
big
thing
to
remember:
it's
a
container
format
so
that
you
can
bundle
the
assets
together,
but
it
is
not
that
type
of
container
format.
A
Parallel
to
all
of
this
is
mentioned.
In
addition
to
the
set
of
pkcs
standards,
we
have
x509
x.509
predates
ssl
by
almost
a
decade.
Yes,
you
know
this
is
a
thing
before
Netscape
kind
of
assembled
this,
so
that
folks
could
put
credit
cards
on
the
internet
and
it's
really
just
an
encoding
mechanism.
It
was
built
on
top
the
ideas
of
public
key
cryptography
and
utilizes
sn1
syntax
behind
the
scenes
now,
so
we
realized
that
x.509
is
just
a
structuring
and
a
grouping
mechanism.
A
It
should
start
becoming
clear
that
x.509
is
independent
of
an
orthogonal
to
SSL
and
TLS
sure
both
SSL
and
TLS
utilize
x.509,
but
x.509
can
also
be
utilized
without
SSL
and
TLS.
Why
does
it
matter
where
you
know
5-10
minutes
in
and
I've
thrown
a
wall
of
acronyms
at
you,
you're,
probably
asking
yourself.
You
know
like
assuring
you
or
assuming
that
you
did
decide
that
this
was
important.
You
know
and
you're
still
here
on
slide
13.
A
Why
does
this
matter?
Unfortunately,
it
does
matter.
A
lot
of
these
terms
are
thrown
around
and
folks
pretend
that
they're
interchangeable
in
some
ways
that
can
be,
but
if
we
can't
agree
on
what
we're
talking
about
it
makes
it
harder
to
understand
at
the
same
time,
once
we
understand
them,
it
unlocks
a
world
of
prior
art
allowing
us
to
stand
on
the
shoulders
of
those
who
have
come
before
us.
This
is
because
standards
are
important
if
less
than
ten
minutes
of
clarification
can
unlock
a
world
of
making
all
of
you
more
effective.
A
It's
an
obvious
choice
to
me
because
these
standards,
which
provide
interoperability
and
the
interoperability,
is
what
makes
it
possible
for
even
a
small
team
of
people
to
unravel
this
work.
So
where
do
we
end
up
with
with
boring,
SSL
and
open
SSL
in
all
of
this?
Well,
ultimately,
the
way
that
we
got
here
the
reason
why
these
exists
comes
down
to
heartbleed,
heartbleed
and
Google.
So
after
Hartley
was
released,
a
collaboration
began
on
a
fork
of
open
SSL.
A
The
tension
was
to
provide
a
fork
of
SSL
that
had
been
put
on
a
diet,
removing
large
swathes
of
code
to
make
it
more
straightforward
for
the
average
user
I
understand
an
Edition
became
doubly
pressing
because
of
the
threats
of
google
present
the
threats
to
Google
presented
by
the
US
government.
In
parallel
to
this,
it
is
important
to
note
that
Google's
desire
to
create
boring
SSL
stems
does
not
stem
from
actively
vulnerable
code
it
just
it's
there.
A
It
was
more
that
they
wanted
to
make
it
hard
for
users
to
know
sorry,
I
wrote
all
of
these
notes
in
to
make
it
easier
for
the
translator
and
I've
lost
my
place.
It
makes
it
harder
yeah.
The
complexity
of
open
SSL
makes
it
hard
for
users
to
know
what
they're
implementing
is
objectively
correct.
The
they
were
maintaining
an
increasingly
large
pat's
that
match
that
on
open,
SSL
and
decided
that
they'd
had
enough
at
Red
Hat
kind
of
completely
unrelated
to
Google.
A
We
have
to
make
decisions
for
millions
of
customers,
not
just
one
customer
Google
has
more
or
less
one
customer
their
internal
users.
We
have
users
that
care
about
many
many
different
things
and
for
us
one
bug
doesn't
justify,
throwing
out
years
of
expertise,
tooling,
etc
so
enter
lift.
My
lift
I
actually
mean
Twitter,
because
none
of
this
is
straightforward.
A
Twitter
had
invested
a
lot
of
time
and
effort,
developing
the
ideas
that
we
commonly
call
a
service,
mesh,
Matt,
Klein
and
some
other
folks.
You
know
William
from
buoyant,
and
you
know
some
of
the
folks
formerly
not
from
tetri
what
was
the
other
service
mesh
company
that
was
working
on
an
envoy.
I
can't
remember
their
name.
A
There
were
a
bunch
of
folks
at
Twitter
who
all
worked
on
surface
mesh
tooling,
but
the
majority
of
it
was
never
open
sourced,
so
the
developers
all
when
they
left
Twitter
had
to
start
over
and
re-implement
all
of
these
ideas.
So
it
lifts
Matt
started
working
on
the
proxy
server
that
he
wished
he
had
when
he
worked
at
Twitter,
and
that
was
envoy
and
Moundville.
Ii
actually
began
its
life
with
open
SSL,
but
then
specifically
issue
number
152.
We
end
up
with
replace
open
SSL
with
boring
as
a
cell
and
yeah.
We
have.
A
You
know
this
kind
of
decision
coming
in
from
Matt,
and
he
says
I
mainly
want
to
switch
because
I
know
that
you
all
mean
Google
will
help
make
sure
we
are
up-to-date
and
secure
if
we
happen
to
use,
boring,
SSL
and
Peter
says
well,
there's
no
reason
why
we
can't
support
both
they're,
mostly
API,
compatible,
fair
enough
sounds
reasonable.
Personally,
I,
like
that,
you
know
being
able
to
maintain
or
have
the
Google
folks
maintain
what
matters
to
them.
Other
parts
of
the
computer
community
maintain
what
matters
to
them
is
perfect.
A
Unfortunately,
time
is
a
fickle
mistress,
because
then
we
get
to
issue
number
3404,
where
it
gets
called
out
that
the
answer
around
adding
back
support
for
open
SSL
is
absolutely
not
they're
migrating
completely
away
from
it.
Folks,
mock
and
I
made
this
request,
because
this
is
the
things
that
they
need,
and
this
is
where
the
Faustian
bargain
comes
in.
Why
would
the
project
decide
to
make
such
a
turn
to
look
at
that?
A
We
actually
have
to
look
at
the
Charter
of
boring
SSL,
which
is
that
it
is
designed
to
meet
Google's
needs,
and
while
it
is
an
open-source
project,
it
is
not
intended
for
general
use
as
open
SSL
is
they
do
not
recommend
that
third
parties
depend
on
it
doing
so
is
likely
to
be
frustrating
because
there
are
no
guarantees
of
API
or
ABI
stability,
which
bill
will
touch
on
a
little
bit
now.
Why
is
the
challenge
you
know?
A
Switch
was
made
to
the
project,
which
is
not
necessarily
aligned
around
what
we
traditionally
think
of
as
community
it's
aligned
around
the
interests
and
expertise
of
a
single
corporation.
It's
understandable,
though,
and
I
don't
fault
Google
for
it.
When
the
community
was
much
smaller,
it
made
sense
to
consolidate
around
the
opinions
and
needs
of
the
specific
groups,
maintaining
specific
pieces
that,
as
we
grow
the
project,
the
nuances
of
other
members
of
the
community
become
more
apparent,
and
this
is
why
we
need
stewards
who
understand
the
technology.
A
That's
why
the
knowledge
of
the
standards
and
how
they
work
are
important,
which
is
where
we
get
into
Act
two.
So
at
Red
Hat
we
have
products
and
we
have
projects
that
we
collaborate
on.
This
is
how
we
balance
supporting
the
things
that
we
sell
as
a
company
and
the
kind
of
things
that
we
give
away
for
free
to
our
users.
This
means
every
product
has
one
or
more
up
streams.
The
case
of
OpenShift
service
mesh,
the
product
we
come.
A
Envoy
is
the
upstream
for
sto
proxy,
but
envoy
is
not
sto
proxy
and
I
don't
want
to
focus
on
sto,
since
this
is
a
scene.
This
is
a
cloud
native
con
talk
and
sto
is
not
a
cloud
native
computing
foundation
project,
but
it
carries
a
patch
set,
a
top
envoy
to
create
the
component
sto
proxy.
So
there
are
some
differences
here
and
Bill
is
going
to
spend
a
few
minutes
talking
to
us
about
these
changes
or
the
changes
that
brought
the
ISTE
of
patches
patches
along
and
now
a
word
from
Bill.
Okay,
everybody.
B
I
first
started
doing
this
about
a
year
ago,
right
and
I'll
talk
about
sort
of.
Why
why
we
did
what
we
did
and
how
we
did
what
we
did
to
to
bring
open
as
a
oak
sorry
to
bring
open
SSL
into
envoy.
Our
sort
of
mandate
was
was,
is
do
proxy,
but
99%
of
this
do
proxy
is
really
envoy
right.
The
core
of
it
is
is
really
envoy.
B
However,
there
are
some
pieces
that
if
you
go
take
a
look
at
the
source
up
and
github
under
sto
proxy
there's,
there
are
some
additions
that
they
drop
on
top
of
on
void
that
are
is
do
specific
functionality.
The
couple
that
kind
of
come
to
mind
is
system
S&I
functionality
in
there,
and
these
are
all
the
SSL
tos,
specific
ones
for
SSN
I
and
also
for
for
JSON
web
tokens
for
a
GWT.
B
Those
are
the
two
pieces,
however,
over
time,
just
over
the
last
year
that
I've
been
working
on
this
I've
seen
a
whole
bunch
of
that
stuff,
particularly
the
JWT
stuff,
get
pulled
out
of
proxy
because
now
envoy
is
is
doing
it
natively,
so
I
think
the
difference
is
over
time.
I've
seen
shrink
but
I
think
the
distinction
that
that
Redbeard
made
is
really
important,
because
a
lot
of
people
think
that
sto
proxy
is
exactly
the
same
as
envoy.
A
So
my
kind
of
plea
to
folks
is
to
ask
questions.
You
know,
but
really,
why
does
Red
Hat
care?
You
know
envoy
is
your
proxy.
Why
does
it
matter
what
SSL
library
is
actually
used?
You
know,
tragically
it
matters
because
of
this
word
salad.
So
within
the
US
there's
this
thing
called
actually
the
US
and
Canada.
It's
called
the
federal
information
processing
standards
document
number
one.
Forty
revision
number
two
also
known
as
FIPS
140.
A
What
so
the
correct
look
for
this
is
a
glassy-eyed
stare
dreaming
of
something
far
less
boring
than
government
regulation,
but
FIPS,
140
or
Phipps
defines
the
standards
around
the
agencies
of
the
federal
government,
our
wit
around
the
way.
The
agencies,
the
federal
government,
handle
information
processing,
specifically
FIPS
140-2,
focuses
on
cryptographic
mechanisms
and,
more
importantly,
may
that
may
and
may
not
be
used
beyond
that.
It
also
gets
into
the
details
of
like
how
random
number
generators
can
work,
how
tamper-evident
tamper-evident
and
tamper
proof
mechanisms,
work
on
hardware
devices
etc.
A
Beyond
that
many
governments
and
private
companies
adopt
the
guidance
of
FIPS
140
either
because
they
do
business
with
the
US
government
or
the
Canadian
government,
or
because
they
just
don't
want
to
reinvent
a
wheel.
So
you
know
aspects
of
security
divisions
within
smaller
governments
will
often
just
go.
Okay,
we're
going
to
download
all
of
the
documents
for
FIPS.
We
will
start
from
there
and
then
we
will
make
the
changes.
A
You
know
the
patches
to
the
document
that
we
need
that
way,
so
even
other
nation
states
use
these
standards
as
a
rubric
for
developing
their
own
guidelines.
So
some
examples
here
you
know
FIPS
140
2
defines
you
know
things
like
hey.
You
can
use
AES,
you
know
which
is
really
some
opinionated
RSA.
You
can
use
certain
types
of
ECC,
but
you
can't
use
DES.
You
know
you
can't
use
triple
des
with
less
than
three
keys.
You
can't
use
RSA
with
less
than
you
know,
2048
bits.
So
that
means
you
know
things
like
edy
255
19.
A
You
can't
use
it
despite
the
fact
that
it
may
be
more
secure.
You
may
not
use
it
because
it
has
not
been
proven
that
way,
so
this
all
seems
completely
reasonable
like.
But
if
you
change
the
code,
you
have
to
recertify
it
I'll
repeat
that
again,
if
you
change
the
code,
you
have
to
recertify
with
an
independent
auditor
to
reget
your
Phipps
certification.
A
It's
kind
of
weird
this
is
a
massive
pain
in
the
behind
certification
is
conducted
by
these
independent
auditors
that
are
contracted
by
the
vendor.
Who
produces
the
software.
Due
to
this,
it
generally
takes
a
minimum
of
three
to
six
months
and
can
cost
over
$100,000
so
again,
three
to
six
months
and
can
cost
over
$100,000
anytime.
You
make
a
code
change
at
Red
Hat.
We
have
an
answer
to
this
that
enables
us
to
work
around
a
little
bit.
A
It's
called
the
open,
ssl
capsule,
so
it's
a
special
way
of
running
open
ssl
which
allows
us
to
simplify
this.
It
separates
open
ssl
into
two
halves.
When
open
ssl
is
running
capsule
mode,
we
express
open
ssl
as
multiple
discrete
components.
This
means
that
all
of
the
cryptographic
code,
which,
for
example,
implements
the
mathematics
behind
RSA,
live
in
one
binary,
while
the
code
that
handles
the
sending
heartbeat
packets
in
a
malformed
way
lives
in
another
separate
shared
object.
This
means
that
the
cryptographic
code
can
be
certified
and
only
needs
to
be
recertified.
A
If
something
wasn't
implemented
correctly
mathematically.
This
is
actually
critical
for
our
certification
workflow.
By
doing
this,
it
allows
us
to
certify
an
audit
that
single
binary
for
almost
all
red
hat
products.
By
running
the
system.
You
know
literally
booting
the
colonel
with
FIPS
equals
one.
You
tell
the
colonel
the
golang
binaries
apache
HTTP
d,
OpenShift
ansible,
you
name
it
to
bypass
any
internal
cryptographic
mechanisms
that
they
have
and
instead
use
the
open,
ssl
capsule.
A
It
also
means
we
don't
have
teams,
building
their
own
cryptographic,
implementations
and
potentially
messing
that
up
so
important
points,
no
doubt
about
this
FIPS
mode.
It
is
not
used
by
default
when
enabled
it
affects
the
kernel
go
and
other
binaries.
But
enough
about
that
you've
been
listening
to
me.
Talk
about
the
non-technical
things
which
I'm
sure
it's
not
why
any
of
you
are
here.
So
let's
hear
some
more
from
Bill
about
work,
the
changes
that
were
required
and
who
else
was
involved.
B
B
Did
it
because
there's
some
it's
it's
not
as
simple
as
just
going
and
and
sort
of
being
able
to
plug
in
open
SSL
instead
of
boring,
SSL
we've
got
some
if
you
go
and
kind
of
dig
around
in
the
code
who
here,
let
me
back
up
who
here
is
actually
built
envoy,
icon
a
download
of
the
Envoy
source
and
built
it
one,
two,
three:
okay:
it
is.
It
really
is,
especially
if
you've
been
doing
SEO
right.
It's
do,
builds
really
really
easy
and
building
on
voice,
not
trivial.
B
So
there's
a
couple
when
you
go
and
take
a
look
at
the
changes
that
we've
made,
that
I'm
gonna
give
I'm
gonna
reference
a
whole
bunch
of
git
repositories.
Everything
is
all
open
and
available
that
we've
done
so
you
can
go.
Take
a
look
at
and
see
what
we've
done.
You
can
go,
run
the
exact
same
thing
and
replace
all
of
the
boring
SSL
with
open,
SSO,
I'm,
actually
gonna,
step
down.
B
Our
current
focus
right
now
is
on
sto
proxy,
but
there's
a
lot
of
stuff
going
on
too.
That
maybe
is
pure
envoy,
but
well
we
won't.
We
need
to
do
as
Red
Hat
is
support.
The
rel
version
for
the
reasons
that
Brian
just
mentioned,
for
Phipps
and
for
other
reasons,
so
we
need
to
support
open
SSL,
because
that's
that's
the
component,
that
we
have
our
expertise
and
we've
got
contributors
there.
That's
what
we're
comfortable,
supporting
going
and
supporting
a
whole
nother
crypto
standard
is
opens
up
a
whole
ton
of
risk
for
us
as
a
company.
B
Okay.
So
hopefully
that's
enough
about
sort
of
Red
Hat
as
a
company
Phipps.
He
just
talked
about
boring
SSL
over
maybe
six
months
ago,
actually
became
Phipps
compliance,
so
that's
become
sort
of
less
of
an
issue,
but
what
we
needed
to
do
is
be
able
to
take
Envoy
completely
remove
all
of
the
boring
SSL.
Okay,
it's!
If
you
go
and
build
on
boy,
it
pulls
in
there's
this
wonderful
tool
called
basil.
It
says
maybe
some
smirks
out
there
from
the
people
who
have
used
it.
B
It's
also
it's
a
it's
a
tool
that
Google
created
that
will
build
almost
anything
sort
of
regardless
of
language.
It
supports
Java
and
go
and
C++
and
all
sorts
of
other
things
to
go
and
build
whatever
kind
of
software,
you've
gotten
and
all
the
dependencies
and
manage
all
the
dependencies.
So
if
you
go
and
kind
of
take,
this
run
basil
it'll
go
and
pull
in
all
these
dependencies,
boring
ssl
being
one
of
them
when
it
pulls
in
boring
us.
So
we
need
to
go
and
completely
strip
that
out.
B
B
We
know
where
all
that
sources
and
we
can
sort
of
tag
it
and
go
look.
This
is
all
the
source.
It's
not
sort
of
online
pulling
in
dependencies
right
and
basil
sort
of
works
in
a
in
a
separate
way
that
it
kind
of
assumes
you've
got
all
this
internet
connectivity
and
it's
gonna
pull
down
every
damn
thing:
it
needs
to
build
all
the
build
tools
all
of
the
dependencies,
all
the
dependencies
of
dependencies
and
anyway,
build
the
whole
tree.
It's
a
great
tool,
but
it's
also
can
be
a
little
complex.
B
It's
really
powerful,
but
can
be
complex.
We
also
use
a
different
build
tool
set
for
those
same
kind
of
reasons:
it's
what
they
run
upstream.
So
if
you
go
and
go,
take
a
look
at
the
CI
that
envoy
runs
upstream
you,
they
use
kind
of
a
whole
different
sort
of
build
tools,
different
versions
of
the
compiler
and
that
sort
of
thing
they
also-
and
this
is
sort
of
another
interesting
conversation
that
came
up
over
the
last
couple
of
weeks-
is,
if
you
go
take
boring
SSL,
which
Brian
mentioned
is,
is
very
dynamic
right.
B
It's
changing
all
the
time.
The
API
is
changing
all
the
time,
because
it's
it's
really
targeted
at
different
sort
of
set
of
use
cases
in
a
lot
of
cases,
then
open
SSL
is
but
oggela
doesn't
care
because
they
dynamically
link
in
boring,
SSL
right
they're,
not
as
soon
as
they
statically
link
in
boring
SSL
into
the
end
of
their
envoy
binary.
So
they
don't
really
care
if
this
stuff
are
there
changing.
B
If
there's
you
know,
sitting
on
the
operating
system,
there's
another
set
of
libraries
of
boring
SSL,
because
they've
statically
linked
everything,
it's
all
bundled
up
into
there,
one
sort
of
envoy
binary
and
that's
it.
So
you
get
the
version
of
boring
SSL.
That's
gonna
work
for
that
version
of
envoy
and
they're
good,
and
that
makes
perfect
sense.
Our
case
is
a
little
bit
different.
B
B
Okay,
so
maestra
is
the
community
project
name
for
what
Red
Hat's
been
doing
with
Sto.
Think
of
this
as
just
sort
of
a
fork.
It's
our
community,
if
you
think
of
OpenShift
origin
people
who
are
familiar
with
OpenShift
yeah
okay.
So
if
you
think
of
openshift,
you
know,
kubernetes
is
sort
of
the
the
upstream
origin.
B
Is
the
community
version
that
red
hat's
behind
it's
sort
of
an
extension
of
kubernetes
and
then,
similarly,
you
know
open
ship
container
platforms,
our
product
at
Red
Hat
sells
if
you
go
think
of
the
same
way
maestra,
which
is
where
and
github
all
this
stuff
libs
all
the
work
that
we've
done
is
is
analogous
to
origin
right.
This
is
all
the
community
stuff
that
we
go
and
do
builds
for
for
Sto
images
and
builds,
and
all
that
stuff
is
up
there
again.
B
This
is
talking
to
about
Sto,
but
it
all
really
does
apply
directly
to
envoy,
because
99%
of
the
work
is
on
boy
notice
to
you
right
now.
If
anybody's
wants
to
go
and
take
a
look
and
run
any
of
the
the
proxy,
the
all
the
stuffs
available
0.11
is
the
current
tag.
That's
out
there
that's
the
first
release
that
actually
has
open
SSL.
All
the
previous
releases,
we're
running,
boring
SSL,
and
you
can
see
the
versions
there
that
correspond
to
the
upstream.
The
images
that
we're
shipping
are
now
ubi
based.
B
So
there's
you
kind
of
Universal
base
image
right.
So
that's
the
Linux
version
that
sits
underneath
all
these
images
and
we're
also
working
with
you
know,
we
were
read
out
as
a
company
is
contributing
a
whole
bunch
of
stuff
to
both
envoy
and
Sto.
But
the
key
piece
is
what
we've
been
working
for
over
a
year
now
with
with
upstream,
to
do
everything
we
can
to
go,
get
as
much
as
possible.
Pluggable
easily
pluggable
in
upstream,
the
the
upstream
and
I
think
we're
kind
of
getting
to
a
pretty
happy
place
for
everybody.
B
We
had
originally
discussed
actually
coming
up
with
an
abstraction
layer
for
all
of
the
crypto
right
that
you
could
plug
into,
and
the
decision
was
made
that,
because
boring
SSL
is,
it
has
diverged
and
it's
going
to
continue
to
diverge
at
a
pretty
good
rate
from
open
SSL
that
it
doesn't
really
make
any
sense.
It
would
put
on
such
a
burden
for
Envoy
developers
to
go
and
continue
to
move
forward
and
add
features
to
Envoy.
That
has
nothing
to
do
with
crypto.
B
That
they'd
have
to
become
experts
in
both
of
those
and
have
to
deal
with
this
API.
Maintaining
the
API
for
the
crypto
abstraction
would
become
sort
of
a
nightmare
over
time.
So
what
we've
decided
to
do
is
kind
of
take
a
kind
of
a
least
common
denominator
of
what
we
can
pull
out
of
the
core
of
Envoy
and
move
that
into
extensions
and
that
work.
B
B
The
latest
version
stuff
is
leaked
back
in
right,
so
and
I'll
have
to
go
back
and
there
against
a
boring,
SSL
API
and
they
break
the
work
that
we've
done
and
have
to
go
back
and
refactor
all
the
the
replacement
work.
So
this
is
it's
been
sort
of
a
sickle
process,
but
I
don't
like
an
kind
of
see
the
light
at
the
end
of
the
tunnel.
At
this
point,
a
perfect
example
of
that
is
for
the
quick
protocol.
They
recently
went
and
added
support.
B
They've
been
had
support
for
quick,
but
they
actually
pull
in
quiche
now,
which
is
a
library
from
chrome
that
the
chrome
guys
came
up
with
that
has
very
specific,
boring
SSL
there,
including
include
boring,
SSL,
slash
blah
blah
blah
like
it's
very.
It's
not
even
open
SSL,
slash,
something
that
happens
to
be
a
boring,
SSL
library,
they're
really
specifically
got
in
the
code,
boring
SSL.
So
this
is
a
problem
for
us,
but
this
is.
B
This
is
sort
of
just
one
of
the
challenges
we've
got
because
there
are
dependencies
that
that
envoy
pulls
in
that
do
have
boring
SSL
dependencies.
Here's
the
really
the
good
news.
This
is
last
Friday
right.
If
you
look
at
the
date
on
Friday,
the
upstream
guys
Matt
Klein
agreed
to
they,
they
have
opened.
B
B
It's
not
gonna
block
a
merge
if
it
fails,
but
it's
gonna
start
the
flag
stuff
right
so
and
it
for
this
is
huge
right
because
then,
if
you
have
a
conscientious
developer,
who
goes
and
says,
hey,
I
went
and
maybe
I
shouldn't
have
leaked
this
SSL
code.
I
put
it
in
the
wrong
place.
They'll
probably
accept
my
merge
because
I
want
to
keep
things
moving,
but
maybe
I
can
rework
my
pull
request
right
and
put
it,
maybe
where
it
belongs,
and
so
that's
a
that's
a
big
one
for
us.
B
B
To
three
minutes
these,
so
these
are
all
just
sort
of
for
reference
right.
So
what
we've
done
is
is
for
each
one
of
the
components
and
for
each
one
of
the
dependencies
we've
gone
and
created
sort
of
a
similar
pattern
of
how
to
replace
the
the
boring
SSL
with
all
the
open
SSL.
So
we've
got
sort
of
a
process
on
the
next
slide
and
we're
probably
not
going
to
have
the
time
because
I'll
give
a
couple
minutes
for
questions.
But
what
happens
is
yeah
the.
C
B
One-
and
this
is
where
we
two
other
repositories
where
we've
had
to
go
and
create
it,
became
so
problematic
to
go
in
and
talk
directly
to
the
OpenSSL
API
for
what
they
can
do
in
boring
SSL.
So
we've
had
to
sort
of
simulate
some
openness
of
some
boring
SSL
functionality
in
on
top
of
open
SSL
and
that's
what
these
two
guys
are
split.
B
So
what
happens
is
we'll
go
and
pull
an
envoy
and
we
run
a
script
for
each
one
of
the
core
components
and
from
each
one
other
dependencies
and
that
will
go
and
update
it'll
it'll
change.
The
basal
configuration
for
the
build
it'll
go
pull
out
all
the
boring
SSL
specifics,
replace
it
with
the
open,
SSL,
the
corresponding,
open,
SSL
code
and
then
go
kind
of
go.
Do
the
whole
build,
so
the
this
is
definitely
for
reference
and
the
counter
key
point
of
all
this
is
if
you're
interested
all
this
stuff
is
upstream,
it's
good.
B
It's
all
available,
it's
all
in
maestra
up
and
github,
and
hopefully
very
very
soon,
like
by
the
end
of
this
week,
a
lot
of
this
by
the
end
of
next
week.
Hopefully,
a
lot
of
this
stuff
will
be,
and
actually
on
boy
proxy
upstream
and
it'll
be
available
there
and
be
hooked
into
their
CI
soon
thereafter,
I
think
we've
got
one
minute:
okay,.
A
So
bill
has
documented
the
placement
process
here
and
talked
to
a
little
bit
about
that.
We
are
going
to
publish
the
slides
on
sched.
I
do
want
to
take
a
second
to
say
this
work
is
not
just
being
done
by
Red
Hat,
you
know,
there's,
as
you
saw,
there
was
the
request
from
folks
at
Akamai.
You
know
for
this
sort
of
support.
You
know
where
there's
also
some
support
coming
from
Intel
and
VMware.
A
You
know
every
there
are
a
number
of
organizations
that
want
to
see
this
for
very
similar
reasons,
as
the
FIPS
reasons
that
we
talked
about.
So
to
summarize,
what
we've
been
talking
about
here
today,
the
choice,
events,
SSL
or
TLS
implementation
that
you
have
used
has
profound
effects,
understand
why
you're
making
the
choice
that
you
are
and
join
us
in
helping
to
work
on
this
and
collaborate.
Thank
you
very,
very
much
very
honored.
To
present
you
you
here
today,
yeah
thank
you
and
I.