*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!