Everything you always wanted to know about Certificate Transparency (33c3)

33c3 opening theme music

Herald: I'm excited to be here, I guess
you are too. We will get started with our

first talker for the day. He is a security
researcher at SBA Research, and he's also

a member of CCC Vienna. The talk we'll be
hearing today is "Everything you always

wanted to know about Certificate
Transparency" and with that, I will pass

on the stage, please give a warm welcome
to Martin Schmiedecker!

applause

Martin: Thank you very much for these kind
words and this very nice introduction.

As Ari said, I'm a member of CCC Vienna,
I'm also on twitter, so if you have a

comment afterwards, or want to ping me, if
you find a typo in the slides, or

whatever, just ping me on twitter.

So, what is this talk about? What are we going

to talk about? Certificate Transparency
is kind of a new thing in the TLS

ecosystem so not many people are familiar
that it is here. So I will present the

overview, what is CT and what it does and
will also peek under the hood and see what

it actually does, how it works, and how
you can play with it. So one of the things

I have to say about myself: I'm a keen fan
of Internet memes. So even though these

are hilarious pictures. Personally I find
hilarious pictures that I put online. Keep

in mind that HTTPS is a serious topic.
Whether you do net banking, you're

googling, or whatever you do online, HTTPS
is there to protect your privacy and to

protect your security. And in some states,
this has been shown by history, this is

not a case, so there are nation-wide
introspecting devices which break open the

TLS encryption and look at the content.
And people will get a visit from secret

police or anything and they will knock on
their door and arrest them. Just like this

week happened in Turkey, where people got
arrested for posting things on Facebook.

So even though there are some funny
pictures in there keep in mind that this

is just a means to an end for my
presentation. I personally find HTTPS is a

very important topic. I hope I can
convince you, too. And CT in particular is

fascinating. Why is there something like
Certificate Transparency? The name says it

all: if you are a certification authority,
you want to make public the certificates

you sell or you issue. As with many good
stories and many good tools it all started

with a hack. Back in 2011 there was this
Dutch certification authority called

DigiNotar, and they got pawned. They got
really, really badly fisted.

laughter

They lost everything. They lost all their
crown jewels. And as part of this hack,

there were 500-something fraudulent
certificates issued. And not just any

certificates, not just like Let's Encrypt,
where you can get a free certificate, and

and then use it for your internal systems,
or for your web site, or whatever. No,

really, really high value domains and high
value certificates. Like google.com, very

privacy-invasive, if you can read what
people are googling, or what they are

sending in their emails.
windowsupdate.com, which is like the back

door to some of the windows world.
mozilla.com, the attacker could manipulate

the Firefox download, sign it with the
certificate and ship it over a

secure-seeming website. torproject, and so
forth. This was back in 2011 and this was

not just a small incident it hasn't been a
small CA but it was a regular CA with regular

business. What's more on this hack is
that: These certificates have then been

used to intercept communication of
clients. People browsing the web, reading

their email. The company which
investigated the breach afterwards found

out that at least 300.000 IP addresses
were connecting to google.com and were

seeing this fraudulent cert. 99% of which
where from Iran. So it was kind of a

nation state attack against clients of
either ISP based or border gateway based

where people were thinking they were
browsing secured by HTTPS but they were

actually not. This is a wonderful frame
from the video. The guys from Fox IT which

investigated this breach they used the
OCSP requests. Every time you get a

certificate your browser has to somehow
figure out whether or not this certificate

is still valid. If it has been revoked, it
would be nice to not use it anymore. And

one of the approaches which is used is so
called OCSP, so the client asks the

certificate authority: "hey is this still
valid?" And this has been logged. Each of

these requests is one of the clients
seeing this fraudulent certificate and

asking DigiNotar: "Hey, is this cert still
valid?" And as you can see, most of the

connections - it's actually a movie, so
you can see the lights flickering and

popping up and down as people go to sleep
and wake up again. And most of the

people were from Iran. So how did
DigiNotar got hacked? They got really,

really, badly hacked because they had
vulnerabilities everywhere. They had a

system running which was incomprehensibly
insecure for a certification authority.

People think that if you run a
certification authority you build the

foundation for secure communication
online. You are the one securing Internet

communication. And if you run such an
entity, people think you know security.

Actually,

laughter

actually, DigiNotar did not. They had unpatched
software, which was facing the Internet.

Might happen. They didn't have anti-virus
on the machines that issued the

certificates. The didn't have a strong
password for their admin account. So like

"password" or "admin". Actually, you can
read the report online, and the

recommendations from ENISA, the European
security body, they listed all the things

that have been found and identified. Also,
all the certificate-issuing servers were

in one Windows domain. Also kind of bad
from DigiNotar: they kept the incident

secret. Of course, they did not want to
spread out onto the Internet "hey, we got

hacked, and we have had bad security".
They kept this incident hidden

for more than 2 months.

After 2 months, when it got
public, and when the Internet found out,

that actually something really, really bad
had happened, they found out, and

DigiNotar then went bankrupt. That's the sad
ending of the story. But this is not one

of the problems that certification
authorities face. If you run a

certification authority, you issue
certificates based on the identify of your

customers. You can create sub-root CAs, so
you can say Hey, Martin, he looks like a

nice guy, he looks like he knows security,
let's make him a CA and make him verify

identities. Probably not a good idea, but
this is what the business model of HTTPS

and certification authorities is. They
issue certificates and they grant the

permission to issue certificates as well.
And the entire goal of these companies is

to get into the trust stores. Every
browser, every operating system, every

thing connects over TLS has something
called like trust store, where it stores

the entities that are entitled to issue
certificates. And the problem is, those

CAs are not strictly audited. They have
their requirements that they have to

fullfil. They have to show that they have
some kind of security. But afterwards,

once they're certified, and once they're
in the trust stores, there is not such a

strong incentive to audit them, because
they are already in the trust stores, and

they've had their audits, and so forth.
This can lead to many problems. Another

CA, Trustwave, in 2011, it issued sub-CA
certificates. Anyone with a sub-CA

certificate can issue a TLS certificate
for any domain. They used it for traffic

introspection. So they were selling, I
don't know, to a company, which was

building appliances which can break open
the network connections for banks,

companies, or entire ISPs. They can look
into the traffic of it's users. Also,

there was Lenovo SuperFish, wonderful
idea. SuperFish was a local

man-in-the-middle CA, and the goal of the
SuperFish CA was to break open HTTPS

traffic, so that they can inject ads.

laughter

Even though you're using gmail and you
have this nice, slick interface without

obvious ads, SuperFish would break open
this connection, would be trusted by the

browser, and would have huge overlay ads.
Lenovo stopped cooperating with SuperFish.

This was preinstalled on Lenovo notebooks.
They had a local CA installed on the

system so they could inspect the traffic
and show ads to users. What's even more

interesting is that all these CAs had the
same key, and the private key was in RAM.

So anybody could extract the private key
of the CA, use it to sign certificates for

anything, and have an additional layer of
HTTPS injection, where you could not only

show ads, but also read the emails or do
whatever you want. Very bad. They're not doing it

allegedly anymore. Then there was, in
China, the CNNIC, they issued a sub-CA for

an introspection company. Again the
company wanted to sell appliances where

they could break open HTTPS connections
and look into the traffic of the users.

And there was another incident just this
year: Symantec was issuing "test"

certificates to a company or whatever,
among them google.com, opera.com, things

that you probably not would like to test,
and got caught. And the nice thing about

this incident is: they already had
Certificate Transparency installed. And we

will come back to this incident in a
minute. Traffic introspection is a valid

thing. If you have a fleet of planes, and
they are connected via expensive satellite

connections and you really pay a lot for
bandwidth you would like to block, for

example, Netflix, or anything which causes
a lot of traffic. One of the approaches

which was taken by Gogo, they had traffic
introspection devices in their planes and

they issued not-trusted certificates to
inspect the traffic. Bad for them:

Adrienne Porter Felt who works for Google
noticed this and Gogo is not doing this

anymore. And even though traffic
introspection sounds like a really bad

thing, I can think of use cases where this
is legit. If you run a company, if you run

a bank, and you want to prevent people
from leaking data, this can be OK. But it

has to be transparent, people have to know
that this is happening, that they're

inspecting everything. And still won't
prevent people from carrying out the USB

thumb drive with all the data on it. So
this is the big picture why we need

Certificate Transparency. We would like to
see which certificates have been issued by

a specific CA. Some minor issues, not
really minor, that additionally come to

play are that TLS has it's issues
nonetheless whether these certificates are

issued or not. One of them is certificate
revocation is tricky. It's not as easy as

just saying "this certificate is not valid
anymore". Once a certificate is issued, it

is valid until the date shown in the
certificate, which can be three years.

Happens to be, if on the first day of
using this certificate, people notice,

"uh, we should revoke it", clients that
don't get this update will be able to use

this certificate for two and more years.
Also, another limitation is that all CAs

can issue certificates for all websites.
Any of those 1,800 CAs and sub-CAs which

were in trust stores in 2013 they can all
issue a certificate for google.com or

facebook.com. This is not prevented by any
means but social means and contracts,

which state that they have to check the
legitimacy of the request. This was

published in a paper in 2013. There are
more than 1,800 CAs which can sign

certificates for any domain in regular
user devices. Another paper in 2014 found

out that one third of them, one third of
those 1,800 certification authorities,

never issued a single HTTPS certificate.
This makes you wonder: why are they then

in the trust stores and so forth. You can
claim a certain percentage of them they

are used for issuing private certificates
within networks. Still, one third of them

never issued a publicly obtainable HTTPS
certificate. Then of course there the

implementation issues. TLS has a long
history of implementation flaws. Not just

cryptographic, there's logjam, freak,
poodle, whatever. They are a completely

separate issue. But the implementation
issues are troubling the device security

at a constant pace. Famous example is:
"goto fail;" from iOS, where they had an

additional "goto fail" missing bracket and
the certificate validity wasn't checked.

Also, we have a lot of embedded devices.
Once they're powered up, they're used to

generate their private key, and they have
no access to good entropy. Entropy on

embedded devices is surprisingly hard. So
a lot of them generate the same keys. And

as already mentioned, we have different
trust stores per browser, per operating

system. Everyone has a different trust
base. Also of course, every CA tries to

get access into all of the trust stores,
get shipped with system updates to be

trusted, and we have a diversity which is
not natural. Could be much easier if

people would have the same trust base on
all their devices. And there are plenty of

deployment issues. SSLv2: everybody thinks
it dead, but apparently, it's not.

Sebastian Schinzel will give a splendid
presentation two hours from now about the

DROWN attack. The DROWN attack uses SSLv2
weaknesses in email transport. Simply

because it's activated, and it uses the
same key, you can attack top-notch TLS 1.2

encryption, because this is still here.
There's the whole shmafoo of the SHA1

certificates. Certification authorities
are not supposed to issue any SHA1

certificates anymore. Some do, some get
caught, because they back-dated their

certificates, and so forth. It's a mess.
Then there's cypher suites. There are more

than 500 cypher suites available for the
different versions of TLS. Every admin

would like to be [as] secure as possible
but which should he choose. As soon as

there is money involved, like Amazon, they
need to be compatible with Internet

Explorer 6 and so forth. It's really a
mess. And of course, email STARTTLS: Email

never had the design to incorporate
security and authentication, so as always,

they just popped it on top, and this is
STARTTLS. The problem with STARTTLS is it

can be suppressed and people will fall
back to plaintext if they cannot reach the

service with STARTTLS. Perfect forward
secrecy and so forth, deployment is another

topic which can be a talk about. And there
is this troublesome development that the

CAs, they get bought and they get sold
constantly. Just this year, Symantec

bought the company BlueCoat. Symantec is
one of the larger CAs. They run the entire

- not the entire, but they run large parts
of the certifications that are observable.

BlueCoat got popular in the Arab Spring,
because they found BlueCoat proxies which

are capable using man-in-the-middle
attacks to conduct traffic introspection,

have been used at an ISP I think in Syria
or Egypt. They found them, and they have

been deployed nationwide. So if you think
about it that Symantec, one of the largest

CAs, is buying BlueCoat, one of the larger
traffic introspection companies, things

can look really fishy or scary.

Of course they promised they
would never use the Symantec

laughter

This is the state we're in. This is fine,
but it's not. But people still think about

it that HTTPS is safe. And actually it
took a decade to teach people that they

have to search for the lock icon. But if
they do not understand - actually they do

not know how the lock icon appears. But
the entire lock icon is a farce if you dig

into the details. We're all sitting in a
room filled with flames, so to say. So,

this is where certificate transparency
comes in. Certificate transparency has the

goal to identify fraudulent certification
authorities. In a perfect world, any

certification authority would publish all
it's logs, would publish all the

certificates it issues. So as soon as I
get a certificate for schmiedecker.net,

the certification authority - this is part
of the public/private key, it can be

public - so wouldn't it be nice if the CA
would publish that it just issued a

certificate for schmiedecker.net?
Basically: yes. Of course, certification

authorities do not want this to happen, in
particular if they're selling to funky

states or funky businesses which earn
their money with traffic introspection and

so forth. So the perfect world would be
the public key of each certificate would

be published. The certification authority
could say "Hey, I just issued this

certificate" and everybody could see it,
could verify it

and it would be, well, a better world.

This would help to detect
problems very early. So if a small Dutch

certification authority would issue a
certificate for google.com or

torproject.com, this would be noticeable.
I mean, this is a small CA, they would be

really - they should be really surprised
if google.com decides to issue a

certificate for their service. This would
shorten the window of opportunity for an

attacker. Also, the idea is to have some
form of punishment for misbehaving CAs. So

at the moment, right now, if a
certification authority fucks up, and

Google is affected, they mandate that they
need to have additional steps to be

reintroduced into the trust stores. This
is what Google did. They did the Power

Ranger move, and they decided they want to
make the internet more secure. Why Google?

Well, Google is uniquely positioned in a
way that they control the clients with

their browsers with the Android system,
and they also control a large portion of

the servers. Everyone uses Google, except
for those that use Bing.

laughter

Just kidding. What Google did is, once the
DigiNotar hack got public, they pinned

their certificates. Since Chrome has a
decent update cycle they can ship the

certificates which they expect to see with
a browser update. So as soon as [the]

browser updates in the background, it can
enforce the specific certificate that it

expects to see for google.com,
youtube.com, and whatever. Also, it has a

really huge market share. 50% and more,
depending on how you count. Chrome and

Chromium are rather popular. And lastly,
they are a common target. So if some

dictator decides to introspect client
emails, user emails, usually they target

gmail.com, because they have a decent
security, they do not have any other

vulnerabilities or backdoors to allow
access to their content. Which makes the

attack to Gmail a very drastic attack.
With the changes that Google introduced

into Chrome with the certificate pinning,
they can now detect these attacks.

But this was already back in 2011. Since
then, for example, the Porter Felt tweet

I showed you, If Chrome would go to a
website google.com or youtube.com, and

would see a fraudulent certificate, they
would warn the user. And what Google then

did, was to propose a standard, to make an
RFC, how to transparently publish the logs

for certificates that have been issued.
The idea of the RFC is that every

certificate issued is public. This is
implemented in a public, append-only log.

So they have a log, they have open APIs,
and they accept every certificate. Then,

cryptographically assured, the client like
the browser can verify that this is a

publicly logged certificate. And the
entire system is open for all. So you can

go to the website, you can
get the source code,

you can run your own log for RFC 6962.

And everyone is happy.

The goals were to detect misbehaving
CAs. As I said,

they have their audits, they have their
compliance regulations, and so forth, but

not on the certificate level. With
certificate transparency, they become

audible by the public, by the browsers.
Everyone can query the logs and see

whether or not this particular
certification authority has issued a

certificate for google.com.

Alright! Upon reading the RFC,
there are three entities

which are part of certification
transparency. There are, for one,

the logs, which are like giant vacuum
cleaners. They ingest all the certificates

which are sent to them, and then
cryptographically sign them and issue the

assurance that this specific certificate
has been logged. And this has been issued

and has not been tampered with, and so
forth. Then there are monitors. They

identify suspicious certificates. Usually,
these are the certification authorities

themselves which run those monitors. And
then there are the auditors. The auditors

usually are implemented in the browser.
And they verify that the issued

certificates are really logged. Looking at
them in detail: the role of the monitor

and the auditor is kind of
interchangeable, so a monitor can be an

auditor, back and forth. What the monitor
does, it fetches all the certificates.

So you have this giant pool of certificates.
They are cryptographically assured which

we will see soon. And the monitor just
fetches them all. And they have some form

of semantic checking. They can see, has
there been a certificate for my domain,

has there been any sub-CA created, which
is able to issue certificates for traffic

introspection, and so forth. Also, what
they can then, with this data, do, they

can identify misbehaving log operators. I
said, the logs, they are just gigantic

hoovers, which collect all the
certificates, and they need auditing, too,

of course. They need - they have a
position of power, because they are

managing this huge pool of certificates.
And one needs to challenge the log to

identify misbehaviour. This can be done by
the monitors, can also be done by the

auditors. Every client - right now, it's
implemented in Chrome. Chrome checks for

these certification transparency
cryptographically signed blobs. And the

browsers and everything, they can verify
the log integrity as well. So in the

backend, the log, it creates a hash tree.
This hash tree is signed. We will come to

that in a second. I got lost here. So both
monitors and auditors, they query that the

log entity is working correctly. It
wouldn't be a good thing if China could go

to Google and say them "Hey, we would like
to have this certificate removed." Google

could then comply or could not comply but
whether they remove the certificate this

would be auditible and this would be
observable to the public. So the good

thing is anyone run any software, anyone
of you in this room can run a log entity.

You need some kind of access to some
certificates, so whether or not you are a

certification authority, you can just run
a public log, and everybody can push their

certificates to your service. Right now,
this is not the case. Usually, the CAs run

the monitors and they run the logs, but
this is not by design, anybody can run

anything. One of the problems is
availability. So even through I can set up

a log for certificates, I have the problem
that my log needs to be online 24/7. My

ISP is not happy if I ask him to guarantee
this for me, if I don't pay much much much

more. So, how does it work? Currently, if
you get a certificate, you go to the

certification authority, You say, "hey,
I'm this wonderful domain, please could I

get a certificate?" And then you get the
certificate. What's additionally happening

with certification transparency is that the
CA upon issuing the certificate - this can

be any CA, this can be Let's Encrypt, this
can be Thawte, Symantec, you name it -

what they do is they send the certificate
once they issued it, they send the

certificate to one of the logs. The log
then signs the successful reception of the

certificate, and immediately sends
something back. This blob is called the

SCT, the signed certificate timestamp, and
this can then be included in the

certificate or with other ways. Key point
here is that once the server installs the

certificate, it also installs this SCT, so
that browsers can see it and parse it.

Some people I might have lost here.
Nonetheless, everything is easier in

pictures. Right now, currently - and these
are the pictures from the certification

transparency website, thanks for making
them - my pic skills are really not that

good, so I never would have been able to
make such beautiful graphs. So currently,

there is the certification authority. It
issues a certificate, and the website then

installs it in the correct directory. The
clients check it, and encryption can

happen. The additional step, and this is
the nice thing, it can happen without any

additional steps on the server side and
the client side, it's just the

certification authority needs to do an
additional step. So instead of just

issuing the certificate, they send the
certificate to the logs, the log

immediately sends back the so-called SCT,
the signed certificate timestamp, and this

is then included in the certificate, which
is shipped to the client. And then the

client, if it supports it, can ask the
server whether or not this particular

certificate is included or not. The things
that come back from the log they are

signed, they have an ID, and they have a
timestamp. These are the important things.

They need to be included in those SCT.
Also, what will be interesting in the

future, that the certificate can have
multiple log entries. So the SCT is like a

promise. The log operator promises to
include this certificate in its logs. And

everybody can check afterwards then if
this log has really publicly logged, or if

the authority has omitted to log it. In
the future it will be the case that many

SCTs can be within a certificate. If I'm a
certification authority I can go to any

log operator, send them every certificate
I have and then include many, many SCTs.

And the SCT is not private. This is just
an ID, it's a timestamp, and it's a

signature. This is probably too much.
There's multiple ways for the client to

verify that this certificate has an SCT.
So one of the methods for example is OCSP

stapling. Right now, if you have a
certificate, instead of going to the CA,

the server can staple the OCSP request
signed by the CA. And within this OCSP

stapling there can also be the SCT
included. How does it work on the log

side? Everything there is, is a Merkle
hash tree. A Merkle hash tree is a

wonderful data structure. It's nothing
new, it's nothing fancy, and it's not the

blockchain.

laughter

The Merkle hash tree, it looks, it's a
binary tree. Every node has two children,

and the hash value of an inner node
depends on the two children. So usually

it's the concatenation of the values of
the two children. Get's hashed again, up

to the root. Makes it very space efficient
because if I want to verify the integrity

of one entire tree, all I have to check is
the hash value of the root. Then, of

course, I can get all the relevant hash
values, and then I can reconstruct it. CT

uses SHA256 Merkle tree, and as I said,
everything below a certain node is

responsible for the hash value. So if you
remove a node, if you add a node, or if

you relocate a node, the hash values of
all the upper nodes get changed. Each of

the log operators, additionally to the
promise that they will include every

certificate that it receives, it also
gives a promise on the maximum merge

delay. The SCT, the promise to include
this certificate chain into the log, it

can only finish immediately because it's a
promise to include this into the log. And

the maximum merge delay is the time the
log operator promises to include it in the

big, big Merkle hash tree. The good thing
about the Merkle hash tree is despite

being very space efficient, calculation
efficient, not that much data overhead,

and so forth, it's not possible to
backdate elements. This was interesting

for one of the certification authorities
which issued SHA1 signed certificates,

even though the browsers and everyone
agreed that this should not happen

anymore. So it's also not possible remove
elements that have been once in there. So

if Symantec decided to remove the
google.com certificate, which was a "test"

certificate, this would be noticeable as
well, because if you remove one of the

leaves, the hash values up to the root,
they all change. And it's also not

possible to add elements. if you would
like to add an element unnoticably, you

cannot do this, because the hash values of
all the upper nodes would change. So how

do the logs operate? What they usually do
is once every hour, they receive the

certificates, and once every hour they
include them into their Merkle hash tree.

Probably already too much detail. They
build a separate tree, and then include it

and recalculate the root hash value, which
is then signed and shipped. And the nice

thing about the Merkle tree is that you
have multiple ways of proving things. One

of the things that can be proved whether
or not this log operator is honest. if a

log operator removes one of the
certificates, this becomes visible by

changing all the relevant nodes. Also,
it's very efficient. Also a figure from

the project website. On the left side, you
have a Merkle tree with some added

certificates, appended certificates. And
if a monitor or an auditor decides to

challenge the log operator, at a later
point in time, whether or not these

certificates D6 and D7 have been correctly
added, all the log operator has to send

are those highlighted nodes. This is the
root, this is the thing that is signed,

for example, every hour. This is public.
The certificates, they are public because

like, they're certificates. If now someone
wants to verify that not only these have

been included, this is very easy, because
you just have to calculate all the way up,

but also verify that all the other
certificates are still there, so none of

the old certificates have been removed,
there only needs to be three hash values

transmitted. And then the challenger can
re-calculate everything. So as soon as the

challenger knows those hash values they
can concatenate everything back together

and in the end, it should have the same
hash value as the root. Another proof that

is possible is whether a specific
certificate is still in the log. So it's

not only possible to challenge the
consistency of the entire log regarding

old data, but it's also to verify that a
specific certificate is still in the logs,

or made it into the logs. Remember, the
SCT, the thing that finished immediately,

is just a promise to include it in the
logs, and at a later point in time,

anyone, any auditor can challenge the log
operator if the certificate is really in

the log. So again, if I want to verify
that a specific certificate is in the log

I have the certificate that I would like
to challenge, then I just need, in this

example, those three nodes, and everything
else, the j node can be calculated because

I have the certificate. Then I have the
hash of the certificate. I need this hash,

then I can calculate this value, and so
forth, until I am at the root. So much for

under the hood. Merkle hash trees are
gone. One of the problems of those logs

are they are every growing. You might have
noticed, there is not a single word about

deleting certificates, for valid reasons,
they are ever growing. Of course, nothing

is forever, so what log operators do is
that they rotate the logs. So at a

specific point in time, the log gets
frozen, the tree is then static, and there

is another log entity, which is brough
online and used for, including the newer

certificates. Quite recently, aviator from
Google got frozen.

It contains 46 million certificates.

Small drawback of freezing a
log: as long as one certificate in this

log, in this three is still valid, this
log needs to be reachable. As soon as all

the certificates have been expired, it can
be dumped. But until that it has to be

available for the proofs.

One of the issues is that right now
there are just a few log operators.

In the future, there should
be many more. Not hundred-thousands of

them, but maybe hundreds of them. And they
need to exchange information. Some form of

log chatter should appear. The log
operators chatter with the clients to

verify that they all see the same state of
the Merkle trees. And this has been

published in a paper last year. Right now,
the idea is not yet at a level where they

need to chatter, which we will soon see.
This happens when you create memes on the

train. Usually, they are very bad memes.
This is apparently Gossip Girl, I've never

seen it, but if you google gossip and
meme, ta-da!

laughter

Who now runs the logs? Who are the
entities who are actively running logs. Of

course, Google is running the majority of
them. They proposed the entire thing, they

wrote the code to run these things, and
they run the large, open-for-all

certificate logs. Three of them are
currently open-for-all. Another one is for

Let's Encrypt certificates, and another
one is for non Let's Encrypt certificates.

Of course, Let's Encrypt issues a lot of
certificates., thankfully. So they

separated that, apparently. If you read
the mailing list, they promise that these

free open-for-all logs are separated
geographically and administratively. The

are run by different entities, but they
all have the same boss, and it would be

better if there were more open logs.
Symantec has one, Wosign, CNNIC. Everytime

Google detects that a fraudulent
certificate for google.com has been

issued, those certification authorities
are mandated to run CT. Which is a good

thing, I mean, public and everything.
Google has tens of millions of

certificates. They really have an
open-for-all log, so everyone can push

certificates in there. DigiCert, Symantec
is kind of big, but all the other nodes

which are listed on the website, they have
a hundred-thousand-ish certificates, which

is not that much compared to 50 million or
60 millions. Right now, Google already

mandates certification transparency for
extended valiity certificates, so if you

not only see the green text up in the left
corner of your browser, but also some

fancy name and big, big green whatever,
this is an EV cert. And Google mandates

for EV certs to have two SCTs. Firefox is
in the process of including it, I think.

Also, apparently, certificate transparency
works. Because, when Symantec issued this

certificate for google.com they released a
report stating that they found 23 "test"

certificates. Symantec said that it issued
23 test certificates. But the logs are

public, anybody can query them. And within
seconds, you can see that Symantec issued

another 164 certificates for other
domains, and also 2,500 certificates for

non-exisisting domains. Just regarding
this one issue. I need to hurry, time is

running out. Some of the downsides of
certificate transparency. Of course:

privacy. People can learn your internal
hosts, so if you have NAS for example, and

this NAS is only reachable within your
LAN, and you want to get rid of the

browser warning whenever you access the
interface of your NAS, you can get a Let's

Encrypt certificate but since not only the
certificate is published, but also it's

logged, people can see in the public log
file that there is, for your domain, a

NAS. Also, log entries must contain the
entire chain up to a trusted root

certificate, which excludes everything
which is self-signed, and everything which

is DANE. DANE is for verifying TLS
certificates using DNSsec. And since these

two have no trusted root, they are currently
not working for certificate transparency.

Now, of course you want to see the data.
You're gonna play around with this.

Basically, what you can query, everything
is JSON. So, if you know JSON, you can

work with certificate transparency. The
basic URL is like this. The URL is any log

server, responds with the current root and
it's signature, using this URL. Most

interestingly, it gives you also the
number of certificates and the time stamp.

It looks then like this. JSON, so you
have, this is the aviator log from Google,

which is now frozen. Has 46 something
million certificates, the hash value of

the Merkle tree, and the signature. Also,
you can challenge the certification logs

with consistency proofs, where you have
two states of their tree, and the log has

to prove that it did not modify anything
in between them. And of course, you can

verify that specific certificate is in the
tree with the second URL. And you can just

push certificates there with a POST
request. So you push it, they send back

the SCT, if you're the log operator, then
you would include this. Any website which

right now is not using SCT all it takes is
a POST request. Nothing more. Some screens

from the internals. This is for google.com
in the net internals view. What you can

see is that signed certificate timestamp,
the SCT, is received. It is valid. And

compliance is checked. So this was for
google.com. And everything worked out.

Last but no least, just to mention it,
Comodo operates a large search engine,

crt.sh. There you can query public logs.
Also, Facebook recently added a monitor

for certificates. So if you own a domain
name, and you use an entity which - no if

you own a domain, you can get updates if
the certificate changes. The also monitor

the public logs and as soon as, for
example, facebook.com uses a new

certificate that is logged in CT, you can
get a notification for that. This is what

it looks like. Remember, Facebook can also
send PGP-encrypted mails, then nothing

leaks to anyone. This screenshot was
borrowed from Scott Helme. So, what's

next? Just a few - One month ago, Google
announced that it will mandate certificate

transparency from October 2017 on. So if
you run a website which is secured by TLS

you might want to check before that date
whether or not your certification

authority is using certificate
transparency. I would expect to have more

logs and more certificates included in the
logs. In the far future, basically, the

idea of transparency and this Merkle tree
is open for anything. You could put key

management software releases, anything in
there. The team at Google, they also

builded a prototype for that, called
Trillian, and described in the paper

"Verifiable Data Structures".

Before we
come to the end and questions,

laughter

applause

There is a distinction. Of course, you
could solve this problem with blockchain

as well. But a Merkle hash tree is much
more efficient, much more elegant. When I

talked to a colleague on the train here,
he said, of course, you can just push the

log into the blockchain.
Yeah, not the same thing.

Thank you!

applause

Herald: Thank you Martin for a very
interesting talk! We have a few more

minutes left for Q&A, so if you have a
question, please line up next to the

microphones, and ask your question.
Remember: a question has a question mark

at the end. Also, if you're exiting,
please do so silently and from the front

door, thank you. I think we have a
question over there:

Q: Can you recommend some libs or software
where I can accomplish the TLS handshake

from the client side, so I can get the
SCT, via TLS extension, via OCSP

extension, via the inherited
pre-certificate SCT.

M: Not by heart. I mean, if it's part of
TLS certificate anything will go, OpenSSL,

whatever, it's just a field. Same as for
OCSP, so anything that does OCSP will

include it, it's just that clients that do
not know the extension will just not -

they will ignore it. But anything that
does OCSP or SSL handshake will work.

H: Thank you. Question from this microphone.

Q: Hello, thank you very much for the nice
talk. Do you know how much space is needed

to store all the logs currently?

M: I had the same question, but
unfortunately not. What they store is the

tree, and they store the entire chain,
excluding the root certificates. So,

probably two, three, four certificates per
entry, which is like - I think you can buy

at the regular electronic markets a hard drive
which is able to fit a lot of those entries.

H: Next question from that mic.

Q: Yeah, thank you for the talk. Why do
you need two SCTs for extended validation?

M: Because a single entity might cheat. So
it's like - even though you can detect it,

it's still a timeframe left. And if you
have two SCTs, which are operated

independently, the idea is it's not that
likely that the two will collaborate

to make a certificate disappear.

Q: Thanks!

H: That microphone, yes.

Q: I'm actually a bit surprised, because
Google has been pushing for making the

server HELLO as small as possible, and of
course, this is increasing the server

HELLO with, in this case, an SCT, and of
course, they are also doing OCSP stapling,

so that makes it even bigger. And this is
like a SHA256, so we're talking 256 bits

there, plus another one you said that, you
know, one is not enough. Actually I've

never seen that has more than one SCT.
Have you?

M: No.

laughter

Not yet.

Q: I've looked around, but nothing.

M: Yeah.

Q: It's actually increasing the size. And
I'm just wondering, where is this going.

Are we just gonna eat the costs of having
all these SCTs and OCSP stapling? Are we

prepared to eat that cost?

M: I think the cost is small compared to
the gain you get by HTTP2. So if you pipe

anything to one singular connection. I
think it's not bad of a cost anymore. But

of course, this is a policy thing. To
require a certain amount of SCTs, to

prevent fraudulent CAs.

Q: Is the idea that this will replace
something like the SSL observatory, where

browsers send in certs they see, and then
- you nodded, so I assume yes. And then

also, how does this work for people who
can't have their certs be public?

For people who are like issuing
things for internal networks?

M: If you can't have the certificate
public, probably the better way right now

is to have a certification authority which
is not using CT. In the future, it makes

it much more expensive to operate your own
CA, incorporate it in the trust stores.

But of course, this is costly. You have to
sign the certificate and everything.

Q: But if like in October 2017, when
Chrome rejects all certs that don't have

signed timestamps like what do I do?

M: Use Edge.

laughter

I'm sure you can disable it somehow,
but it's blerg.

Q: What about if someone tries SCT with
DHT or other system.

Not blockchain, of course!

It's possible to do that without
central authorities?

M: Sorry, say again?

Q: My English is very bad, I'm sorry. I
said, it is possible to do that without

some central authority, like Google
or over SCT, but

with a distributed hash table,
like DHT technologies,

M: Yes, yes, of course.

Q: And are there existing implementations?

M: For the centralized thing, yes. Not for
the distributed thing. But I think it's

just adding a layer of DHT on top of it.
So I'm sure you can think of a browser

extension which uses the DHT to obtain
SCT. But right now it's just purely

centralized. But the source is open.

Q: OK, thank you.

Q: I was just curious how it works if you
have a certificate which gets revoked, in

context of the tree. Especially if the
tree is frozen. So how does this work?

How do you revoke a certificate with a
tree, and then how does it work if it's

frozen already.

M: Good question! The goal of CT is not
- it's not about revocation. So whether

revocation path is taken regularly. So you
ask OCSP. It's independent of the

revocation thing. It's just publicly
saying that this certificate has been

issued. So removing a certificate from the
tree, which has been removed - revoked, is

not part of the specification. This is not
the use case. It's just logging the

certificates which have been issued.

Q: But if you audit all the logs, and you
want to know if something is, like going

on that shouldn't be going on, wouldn't
you want to know whether the certificate

has been revoked at some point?

M: Yes, but not in the logs. The logs are
just to prove that the CA has issued this

certificate, and to prove that the log has
correctly logged it. Revocation is

different. Usually, OCSP stapling with the
CA, but that's a different channel. So

this is not for certificate transparency.

Q: Thank you!

H: That's all the time we have for Q&A.

Big round of applause again for
Martin for a great talk!

applause

postroll music

subtitles created by c3subtitles.de
in the year 2017. Join, and help us!