0:00:00.160,0:00:13.499
33c3 opening theme music
0:00:13.499,0:00:20.460
Herald: I'm excited to be here, I guess[br]you are too. We will get started with our
0:00:20.460,0:00:26.670
first talker for the day. He is a security[br]researcher at SBA Research, and he's also
0:00:26.670,0:00:32.668
a member of CCC Vienna. The talk we'll be[br]hearing today is "Everything you always
0:00:32.668,0:00:37.250
wanted to know about Certificate[br]Transparency" and with that, I will pass
0:00:37.250,0:00:41.848
on the stage, please give a warm welcome[br]to Martin Schmiedecker!
0:00:41.909,0:00:46.361
applause
0:00:48.740,0:00:53.720
Martin: Thank you very much for these kind[br]words and this very nice introduction.
0:00:54.071,0:00:58.820
As Ari said, I'm a member of CCC Vienna,[br]I'm also on twitter, so if you have a
0:00:58.820,0:01:02.730
comment afterwards, or want to ping me, if[br]you find a typo in the slides, or
0:01:02.730,0:01:05.220
whatever, just ping me on twitter.
0:01:05.220,0:01:08.720
So, what is this talk about? What are we going
0:01:08.720,0:01:13.010
to talk about? Certificate Transparency[br]is kind of a new thing in the TLS
0:01:13.010,0:01:19.680
ecosystem so not many people are familiar[br]that it is here. So I will present the
0:01:19.680,0:01:24.910
overview, what is CT and what it does and[br]will also peek under the hood and see what
0:01:24.910,0:01:32.060
it actually does, how it works, and how[br]you can play with it. So one of the things
0:01:32.060,0:01:38.150
I have to say about myself: I'm a keen fan[br]of Internet memes. So even though these
0:01:38.150,0:01:44.690
are hilarious pictures. Personally I find[br]hilarious pictures that I put online. Keep
0:01:44.690,0:01:48.700
in mind that HTTPS is a serious topic.[br]Whether you do net banking, you're
0:01:48.700,0:01:53.670
googling, or whatever you do online, HTTPS[br]is there to protect your privacy and to
0:01:53.670,0:01:59.690
protect your security. And in some states,[br]this has been shown by history, this is
0:01:59.690,0:02:05.350
not a case, so there are nation-wide[br]introspecting devices which break open the
0:02:05.350,0:02:11.400
TLS encryption and look at the content.[br]And people will get a visit from secret
0:02:11.400,0:02:16.010
police or anything and they will knock on[br]their door and arrest them. Just like this
0:02:16.010,0:02:21.650
week happened in Turkey, where people got[br]arrested for posting things on Facebook.
0:02:21.650,0:02:25.720
So even though there are some funny[br]pictures in there keep in mind that this
0:02:25.720,0:02:34.030
is just a means to an end for my[br]presentation. I personally find HTTPS is a
0:02:34.030,0:02:39.270
very important topic. I hope I can[br]convince you, too. And CT in particular is
0:02:39.270,0:02:46.900
fascinating. Why is there something like[br]Certificate Transparency? The name says it
0:02:46.900,0:02:52.650
all: if you are a certification authority,[br]you want to make public the certificates
0:02:52.650,0:02:59.860
you sell or you issue. As with many good[br]stories and many good tools it all started
0:02:59.860,0:03:06.150
with a hack. Back in 2011 there was this[br]Dutch certification authority called
0:03:06.150,0:03:10.850
DigiNotar, and they got pawned. They got[br]really, really badly fisted.
0:03:10.850,0:03:11.850
laughter
0:03:11.850,0:03:17.680
They lost everything. They lost all their[br]crown jewels. And as part of this hack,
0:03:17.680,0:03:23.650
there were 500-something fraudulent[br]certificates issued. And not just any
0:03:23.650,0:03:27.370
certificates, not just like Let's Encrypt,[br]where you can get a free certificate, and
0:03:27.370,0:03:32.350
and then use it for your internal systems,[br]or for your web site, or whatever. No,
0:03:32.350,0:03:38.870
really, really high value domains and high[br]value certificates. Like google.com, very
0:03:38.870,0:03:43.290
privacy-invasive, if you can read what[br]people are googling, or what they are
0:03:43.290,0:03:48.360
sending in their emails.[br]windowsupdate.com, which is like the back
0:03:48.360,0:03:56.069
door to some of the windows world.[br]mozilla.com, the attacker could manipulate
0:03:56.069,0:04:03.140
the Firefox download, sign it with the[br]certificate and ship it over a
0:04:03.140,0:04:11.050
secure-seeming website. torproject, and so[br]forth. This was back in 2011 and this was
0:04:11.050,0:04:19.180
not just a small incident it hasn't been a[br]small CA but it was a regular CA with regular
0:04:19.180,0:04:24.960
business. What's more on this hack is[br]that: These certificates have then been
0:04:24.960,0:04:29.690
used to intercept communication of[br]clients. People browsing the web, reading
0:04:29.690,0:04:34.850
their email. The company which[br]investigated the breach afterwards found
0:04:34.850,0:04:42.240
out that at least 300.000 IP addresses[br]were connecting to google.com and were
0:04:42.240,0:04:50.400
seeing this fraudulent cert. 99% of which[br]where from Iran. So it was kind of a
0:04:50.400,0:04:56.570
nation state attack against clients of[br]either ISP based or border gateway based
0:04:56.570,0:05:04.070
where people were thinking they were[br]browsing secured by HTTPS but they were
0:05:04.070,0:05:12.220
actually not. This is a wonderful frame[br]from the video. The guys from Fox IT which
0:05:12.220,0:05:19.949
investigated this breach they used the[br]OCSP requests. Every time you get a
0:05:19.949,0:05:23.450
certificate your browser has to somehow[br]figure out whether or not this certificate
0:05:23.450,0:05:30.880
is still valid. If it has been revoked, it[br]would be nice to not use it anymore. And
0:05:30.880,0:05:38.060
one of the approaches which is used is so[br]called OCSP, so the client asks the
0:05:38.060,0:05:45.870
certificate authority: "hey is this still[br]valid?" And this has been logged. Each of
0:05:45.870,0:05:53.360
these requests is one of the clients[br]seeing this fraudulent certificate and
0:05:53.360,0:05:59.790
asking DigiNotar: "Hey, is this cert still[br]valid?" And as you can see, most of the
0:05:59.790,0:06:03.580
connections - it's actually a movie, so[br]you can see the lights flickering and
0:06:03.580,0:06:08.699
popping up and down as people go to sleep[br]and wake up again. And most of the
0:06:08.699,0:06:15.860
people were from Iran. So how did[br]DigiNotar got hacked? They got really,
0:06:15.860,0:06:21.229
really, badly hacked because they had[br]vulnerabilities everywhere. They had a
0:06:21.229,0:06:27.400
system running which was incomprehensibly[br]insecure for a certification authority.
0:06:27.400,0:06:31.900
People think that if you run a[br]certification authority you build the
0:06:31.900,0:06:37.449
foundation for secure communication[br]online. You are the one securing Internet
0:06:37.449,0:06:42.690
communication. And if you run such an[br]entity, people think you know security.
0:06:42.690,0:06:43.960
Actually,
0:06:43.960,0:06:45.600
laughter
0:06:45.600,0:06:52.100
actually, DigiNotar did not. They had unpatched[br]software, which was facing the Internet.
0:06:52.100,0:06:55.990
Might happen. They didn't have anti-virus[br]on the machines that issued the
0:06:55.990,0:07:01.860
certificates. The didn't have a strong[br]password for their admin account. So like
0:07:01.860,0:07:05.040
"password" or "admin". Actually, you can[br]read the report online, and the
0:07:05.040,0:07:11.600
recommendations from ENISA, the European[br]security body, they listed all the things
0:07:11.600,0:07:18.700
that have been found and identified. Also,[br]all the certificate-issuing servers were
0:07:18.700,0:07:27.040
in one Windows domain. Also kind of bad[br]from DigiNotar: they kept the incident
0:07:27.040,0:07:31.690
secret. Of course, they did not want to[br]spread out onto the Internet "hey, we got
0:07:31.690,0:07:37.760
hacked, and we have had bad security".[br]They kept this incident hidden
0:07:37.760,0:07:39.900
for more than 2 months.
0:07:39.900,0:07:45.380
After 2 months, when it got[br]public, and when the Internet found out,
0:07:45.380,0:07:49.820
that actually something really, really bad[br]had happened, they found out, and
0:07:49.820,0:07:59.640
DigiNotar then went bankrupt. That's the sad[br]ending of the story. But this is not one
0:07:59.640,0:08:05.620
of the problems that certification[br]authorities face. If you run a
0:08:05.620,0:08:10.860
certification authority, you issue[br]certificates based on the identify of your
0:08:10.860,0:08:17.310
customers. You can create sub-root CAs, so[br]you can say Hey, Martin, he looks like a
0:08:17.310,0:08:22.960
nice guy, he looks like he knows security,[br]let's make him a CA and make him verify
0:08:22.960,0:08:31.710
identities. Probably not a good idea, but[br]this is what the business model of HTTPS
0:08:31.710,0:08:36.599
and certification authorities is. They[br]issue certificates and they grant the
0:08:36.599,0:08:45.470
permission to issue certificates as well.[br]And the entire goal of these companies is
0:08:45.470,0:08:50.910
to get into the trust stores. Every[br]browser, every operating system, every
0:08:50.910,0:08:56.879
thing connects over TLS has something[br]called like trust store, where it stores
0:08:56.879,0:09:02.499
the entities that are entitled to issue[br]certificates. And the problem is, those
0:09:02.499,0:09:07.199
CAs are not strictly audited. They have[br]their requirements that they have to
0:09:07.199,0:09:13.369
fullfil. They have to show that they have[br]some kind of security. But afterwards,
0:09:13.369,0:09:17.709
once they're certified, and once they're[br]in the trust stores, there is not such a
0:09:17.709,0:09:23.130
strong incentive to audit them, because[br]they are already in the trust stores, and
0:09:23.130,0:09:31.269
they've had their audits, and so forth.[br]This can lead to many problems. Another
0:09:31.269,0:09:38.959
CA, Trustwave, in 2011, it issued sub-CA[br]certificates. Anyone with a sub-CA
0:09:38.959,0:09:46.199
certificate can issue a TLS certificate[br]for any domain. They used it for traffic
0:09:46.199,0:09:50.249
introspection. So they were selling, I[br]don't know, to a company, which was
0:09:50.249,0:09:55.670
building appliances which can break open[br]the network connections for banks,
0:09:55.670,0:10:05.170
companies, or entire ISPs. They can look[br]into the traffic of it's users. Also,
0:10:05.170,0:10:11.749
there was Lenovo SuperFish, wonderful[br]idea. SuperFish was a local
0:10:11.749,0:10:17.070
man-in-the-middle CA, and the goal of the[br]SuperFish CA was to break open HTTPS
0:10:17.070,0:10:20.510
traffic, so that they can inject ads.
0:10:20.510,0:10:22.040
laughter
0:10:22.040,0:10:27.239
Even though you're using gmail and you[br]have this nice, slick interface without
0:10:27.239,0:10:34.160
obvious ads, SuperFish would break open[br]this connection, would be trusted by the
0:10:34.160,0:10:44.199
browser, and would have huge overlay ads.[br]Lenovo stopped cooperating with SuperFish.
0:10:44.199,0:10:51.889
This was preinstalled on Lenovo notebooks.[br]They had a local CA installed on the
0:10:51.889,0:10:57.720
system so they could inspect the traffic[br]and show ads to users. What's even more
0:10:57.720,0:11:03.470
interesting is that all these CAs had the[br]same key, and the private key was in RAM.
0:11:03.470,0:11:12.889
So anybody could extract the private key[br]of the CA, use it to sign certificates for
0:11:12.889,0:11:19.660
anything, and have an additional layer of[br]HTTPS injection, where you could not only
0:11:19.660,0:11:27.160
show ads, but also read the emails or do[br]whatever you want. Very bad. They're not doing it
0:11:27.160,0:11:34.709
allegedly anymore. Then there was, in[br]China, the CNNIC, they issued a sub-CA for
0:11:34.709,0:11:38.649
an introspection company. Again the[br]company wanted to sell appliances where
0:11:38.649,0:11:46.209
they could break open HTTPS connections[br]and look into the traffic of the users.
0:11:46.209,0:11:51.220
And there was another incident just this[br]year: Symantec was issuing "test"
0:11:51.220,0:11:57.399
certificates to a company or whatever,[br]among them google.com, opera.com, things
0:11:57.399,0:12:04.230
that you probably not would like to test,[br]and got caught. And the nice thing about
0:12:04.230,0:12:08.709
this incident is: they already had[br]Certificate Transparency installed. And we
0:12:08.709,0:12:15.490
will come back to this incident in a[br]minute. Traffic introspection is a valid
0:12:15.490,0:12:21.839
thing. If you have a fleet of planes, and[br]they are connected via expensive satellite
0:12:21.839,0:12:26.739
connections and you really pay a lot for[br]bandwidth you would like to block, for
0:12:26.739,0:12:33.259
example, Netflix, or anything which causes[br]a lot of traffic. One of the approaches
0:12:33.259,0:12:40.309
which was taken by Gogo, they had traffic[br]introspection devices in their planes and
0:12:40.309,0:12:48.899
they issued not-trusted certificates to[br]inspect the traffic. Bad for them:
0:12:48.899,0:12:54.829
Adrienne Porter Felt who works for Google[br]noticed this and Gogo is not doing this
0:12:54.829,0:13:02.200
anymore. And even though traffic[br]introspection sounds like a really bad
0:13:02.200,0:13:07.910
thing, I can think of use cases where this[br]is legit. If you run a company, if you run
0:13:07.910,0:13:15.039
a bank, and you want to prevent people[br]from leaking data, this can be OK. But it
0:13:15.039,0:13:18.120
has to be transparent, people have to know[br]that this is happening, that they're
0:13:18.120,0:13:22.660
inspecting everything. And still won't[br]prevent people from carrying out the USB
0:13:22.660,0:13:29.929
thumb drive with all the data on it. So[br]this is the big picture why we need
0:13:29.929,0:13:34.899
Certificate Transparency. We would like to[br]see which certificates have been issued by
0:13:34.899,0:13:42.889
a specific CA. Some minor issues, not[br]really minor, that additionally come to
0:13:42.889,0:13:49.189
play are that TLS has it's issues[br]nonetheless whether these certificates are
0:13:49.189,0:13:54.790
issued or not. One of them is certificate[br]revocation is tricky. It's not as easy as
0:13:54.790,0:14:01.109
just saying "this certificate is not valid[br]anymore". Once a certificate is issued, it
0:14:01.109,0:14:08.040
is valid until the date shown in the[br]certificate, which can be three years.
0:14:08.040,0:14:12.230
Happens to be, if on the first day of[br]using this certificate, people notice,
0:14:12.230,0:14:17.999
"uh, we should revoke it", clients that[br]don't get this update will be able to use
0:14:17.999,0:14:28.019
this certificate for two and more years.[br]Also, another limitation is that all CAs
0:14:28.019,0:14:35.149
can issue certificates for all websites.[br]Any of those 1,800 CAs and sub-CAs which
0:14:35.149,0:14:41.750
were in trust stores in 2013 they can all[br]issue a certificate for google.com or
0:14:41.750,0:14:46.620
facebook.com. This is not prevented by any[br]means but social means and contracts,
0:14:46.620,0:14:54.640
which state that they have to check the[br]legitimacy of the request. This was
0:14:54.640,0:15:02.869
published in a paper in 2013. There are[br]more than 1,800 CAs which can sign
0:15:02.869,0:15:10.379
certificates for any domain in regular[br]user devices. Another paper in 2014 found
0:15:10.379,0:15:16.089
out that one third of them, one third of[br]those 1,800 certification authorities,
0:15:16.089,0:15:21.100
never issued a single HTTPS certificate.[br]This makes you wonder: why are they then
0:15:21.100,0:15:26.759
in the trust stores and so forth. You can[br]claim a certain percentage of them they
0:15:26.759,0:15:34.499
are used for issuing private certificates[br]within networks. Still, one third of them
0:15:34.499,0:15:44.220
never issued a publicly obtainable HTTPS[br]certificate. Then of course there the
0:15:44.220,0:15:49.109
implementation issues. TLS has a long[br]history of implementation flaws. Not just
0:15:49.109,0:15:54.109
cryptographic, there's logjam, freak,[br]poodle, whatever. They are a completely
0:15:54.109,0:16:01.799
separate issue. But the implementation[br]issues are troubling the device security
0:16:01.799,0:16:06.820
at a constant pace. Famous example is:[br]"goto fail;" from iOS, where they had an
0:16:06.820,0:16:12.660
additional "goto fail" missing bracket and[br]the certificate validity wasn't checked.
0:16:12.660,0:16:19.629
Also, we have a lot of embedded devices.[br]Once they're powered up, they're used to
0:16:19.629,0:16:25.369
generate their private key, and they have[br]no access to good entropy. Entropy on
0:16:25.369,0:16:33.010
embedded devices is surprisingly hard. So[br]a lot of them generate the same keys. And
0:16:33.010,0:16:37.399
as already mentioned, we have different[br]trust stores per browser, per operating
0:16:37.399,0:16:41.910
system. Everyone has a different trust[br]base. Also of course, every CA tries to
0:16:41.910,0:16:47.379
get access into all of the trust stores,[br]get shipped with system updates to be
0:16:47.379,0:16:54.670
trusted, and we have a diversity which is[br]not natural. Could be much easier if
0:16:54.670,0:17:01.490
people would have the same trust base on[br]all their devices. And there are plenty of
0:17:01.490,0:17:07.609
deployment issues. SSLv2: everybody thinks[br]it dead, but apparently, it's not.
0:17:07.609,0:17:12.099
Sebastian Schinzel will give a splendid[br]presentation two hours from now about the
0:17:12.099,0:17:19.129
DROWN attack. The DROWN attack uses SSLv2[br]weaknesses in email transport. Simply
0:17:19.129,0:17:26.720
because it's activated, and it uses the[br]same key, you can attack top-notch TLS 1.2
0:17:26.720,0:17:32.850
encryption, because this is still here.[br]There's the whole shmafoo of the SHA1
0:17:32.850,0:17:37.780
certificates. Certification authorities[br]are not supposed to issue any SHA1
0:17:37.780,0:17:41.760
certificates anymore. Some do, some get[br]caught, because they back-dated their
0:17:41.760,0:17:47.380
certificates, and so forth. It's a mess.[br]Then there's cypher suites. There are more
0:17:47.380,0:17:54.610
than 500 cypher suites available for the[br]different versions of TLS. Every admin
0:17:54.610,0:18:00.060
would like to be [as] secure as possible[br]but which should he choose. As soon as
0:18:00.060,0:18:04.910
there is money involved, like Amazon, they[br]need to be compatible with Internet
0:18:04.910,0:18:16.140
Explorer 6 and so forth. It's really a[br]mess. And of course, email STARTTLS: Email
0:18:16.140,0:18:22.220
never had the design to incorporate[br]security and authentication, so as always,
0:18:22.220,0:18:27.750
they just popped it on top, and this is[br]STARTTLS. The problem with STARTTLS is it
0:18:27.750,0:18:33.080
can be suppressed and people will fall[br]back to plaintext if they cannot reach the
0:18:33.080,0:18:39.530
service with STARTTLS. Perfect forward[br]secrecy and so forth, deployment is another
0:18:39.530,0:18:46.770
topic which can be a talk about. And there[br]is this troublesome development that the
0:18:46.770,0:18:52.340
CAs, they get bought and they get sold[br]constantly. Just this year, Symantec
0:18:52.340,0:19:00.040
bought the company BlueCoat. Symantec is[br]one of the larger CAs. They run the entire
0:19:00.040,0:19:07.150
- not the entire, but they run large parts[br]of the certifications that are observable.
0:19:07.150,0:19:13.100
BlueCoat got popular in the Arab Spring,[br]because they found BlueCoat proxies which
0:19:13.100,0:19:18.700
are capable using man-in-the-middle[br]attacks to conduct traffic introspection,
0:19:18.700,0:19:23.320
have been used at an ISP I think in Syria[br]or Egypt. They found them, and they have
0:19:23.320,0:19:28.820
been deployed nationwide. So if you think[br]about it that Symantec, one of the largest
0:19:28.820,0:19:34.690
CAs, is buying BlueCoat, one of the larger[br]traffic introspection companies, things
0:19:34.690,0:19:38.620
can look really fishy or scary.
0:19:39.580,0:19:44.180
Of course they promised they[br]would never use the Symantec
0:19:44.180,0:19:46.600
laughter
0:19:46.600,0:19:53.140
This is the state we're in. This is fine,[br]but it's not. But people still think about
0:19:53.140,0:19:59.561
it that HTTPS is safe. And actually it[br]took a decade to teach people that they
0:19:59.561,0:20:05.060
have to search for the lock icon. But if[br]they do not understand - actually they do
0:20:05.060,0:20:11.910
not know how the lock icon appears. But[br]the entire lock icon is a farce if you dig
0:20:11.910,0:20:20.860
into the details. We're all sitting in a[br]room filled with flames, so to say. So,
0:20:20.860,0:20:26.520
this is where certificate transparency[br]comes in. Certificate transparency has the
0:20:26.520,0:20:38.050
goal to identify fraudulent certification[br]authorities. In a perfect world, any
0:20:38.050,0:20:43.140
certification authority would publish all[br]it's logs, would publish all the
0:20:43.140,0:20:48.700
certificates it issues. So as soon as I[br]get a certificate for schmiedecker.net,
0:20:48.700,0:20:54.160
the certification authority - this is part[br]of the public/private key, it can be
0:20:54.160,0:20:59.840
public - so wouldn't it be nice if the CA[br]would publish that it just issued a
0:20:59.840,0:21:05.740
certificate for schmiedecker.net?[br]Basically: yes. Of course, certification
0:21:05.740,0:21:11.300
authorities do not want this to happen, in[br]particular if they're selling to funky
0:21:11.300,0:21:18.440
states or funky businesses which earn[br]their money with traffic introspection and
0:21:18.440,0:21:23.920
so forth. So the perfect world would be[br]the public key of each certificate would
0:21:23.920,0:21:28.160
be published. The certification authority[br]could say "Hey, I just issued this
0:21:28.160,0:21:30.990
certificate" and everybody could see it,[br]could verify it
0:21:30.990,0:21:35.200
and it would be, well, a better world.
0:21:37.740,0:21:43.200
This would help to detect[br]problems very early. So if a small Dutch
0:21:43.200,0:21:47.330
certification authority would issue a[br]certificate for google.com or
0:21:47.330,0:21:52.300
torproject.com, this would be noticeable.[br]I mean, this is a small CA, they would be
0:21:52.300,0:21:57.280
really - they should be really surprised[br]if google.com decides to issue a
0:21:57.280,0:22:04.540
certificate for their service. This would[br]shorten the window of opportunity for an
0:22:04.540,0:22:12.560
attacker. Also, the idea is to have some[br]form of punishment for misbehaving CAs. So
0:22:12.560,0:22:18.020
at the moment, right now, if a[br]certification authority fucks up, and
0:22:18.020,0:22:23.970
Google is affected, they mandate that they[br]need to have additional steps to be
0:22:23.970,0:22:32.800
reintroduced into the trust stores. This[br]is what Google did. They did the Power
0:22:32.800,0:22:41.650
Ranger move, and they decided they want to[br]make the internet more secure. Why Google?
0:22:41.650,0:22:46.610
Well, Google is uniquely positioned in a[br]way that they control the clients with
0:22:46.610,0:22:53.820
their browsers with the Android system,[br]and they also control a large portion of
0:22:53.820,0:22:58.340
the servers. Everyone uses Google, except[br]for those that use Bing.
0:22:58.340,0:23:00.530
laughter
0:23:00.530,0:23:08.140
Just kidding. What Google did is, once the[br]DigiNotar hack got public, they pinned
0:23:08.140,0:23:13.620
their certificates. Since Chrome has a[br]decent update cycle they can ship the
0:23:13.620,0:23:19.241
certificates which they expect to see with[br]a browser update. So as soon as [the]
0:23:19.241,0:23:27.510
browser updates in the background, it can[br]enforce the specific certificate that it
0:23:27.510,0:23:34.670
expects to see for google.com,[br]youtube.com, and whatever. Also, it has a
0:23:34.670,0:23:40.330
really huge market share. 50% and more,[br]depending on how you count. Chrome and
0:23:40.330,0:23:46.060
Chromium are rather popular. And lastly,[br]they are a common target. So if some
0:23:46.060,0:23:53.860
dictator decides to introspect client[br]emails, user emails, usually they target
0:23:53.860,0:23:59.640
gmail.com, because they have a decent[br]security, they do not have any other
0:23:59.640,0:24:10.180
vulnerabilities or backdoors to allow[br]access to their content. Which makes the
0:24:10.180,0:24:15.700
attack to Gmail a very drastic attack.[br]With the changes that Google introduced
0:24:15.700,0:24:21.190
into Chrome with the certificate pinning,[br]they can now detect these attacks.
0:24:21.190,0:24:29.940
But this was already back in 2011. Since[br]then, for example, the Porter Felt tweet
0:24:29.940,0:24:37.520
I showed you, If Chrome would go to a[br]website google.com or youtube.com, and
0:24:37.520,0:24:44.200
would see a fraudulent certificate, they[br]would warn the user. And what Google then
0:24:44.200,0:24:52.840
did, was to propose a standard, to make an[br]RFC, how to transparently publish the logs
0:24:52.840,0:25:01.350
for certificates that have been issued.[br]The idea of the RFC is that every
0:25:01.350,0:25:11.460
certificate issued is public. This is[br]implemented in a public, append-only log.
0:25:11.460,0:25:16.900
So they have a log, they have open APIs,[br]and they accept every certificate. Then,
0:25:16.900,0:25:22.180
cryptographically assured, the client like[br]the browser can verify that this is a
0:25:22.180,0:25:27.640
publicly logged certificate. And the[br]entire system is open for all. So you can
0:25:27.640,0:25:30.190
go to the website, you can[br]get the source code,
0:25:30.190,0:25:36.490
you can run your own log for RFC 6962.
0:25:36.490,0:25:40.610
And everyone is happy.
0:25:40.870,0:25:45.960
The goals were to detect misbehaving [br]CAs. As I said,
0:25:45.960,0:25:51.500
they have their audits, they have their[br]compliance regulations, and so forth, but
0:25:51.500,0:25:55.010
not on the certificate level. With[br]certificate transparency, they become
0:25:55.010,0:26:00.950
audible by the public, by the browsers.[br]Everyone can query the logs and see
0:26:00.950,0:26:04.730
whether or not this particular[br]certification authority has issued a
0:26:04.730,0:26:07.290
certificate for google.com.
0:26:10.200,0:26:15.390
Alright! Upon reading the RFC,[br]there are three entities
0:26:15.390,0:26:20.260
which are part of certification[br]transparency. There are, for one,
0:26:20.260,0:26:27.680
the logs, which are like giant vacuum[br]cleaners. They ingest all the certificates
0:26:27.680,0:26:34.170
which are sent to them, and then[br]cryptographically sign them and issue the
0:26:34.170,0:26:40.620
assurance that this specific certificate[br]has been logged. And this has been issued
0:26:40.620,0:26:45.640
and has not been tampered with, and so[br]forth. Then there are monitors. They
0:26:45.640,0:26:49.860
identify suspicious certificates. Usually,[br]these are the certification authorities
0:26:49.860,0:26:55.930
themselves which run those monitors. And[br]then there are the auditors. The auditors
0:26:55.930,0:27:02.870
usually are implemented in the browser.[br]And they verify that the issued
0:27:02.870,0:27:10.190
certificates are really logged. Looking at[br]them in detail: the role of the monitor
0:27:10.190,0:27:14.080
and the auditor is kind of[br]interchangeable, so a monitor can be an
0:27:14.080,0:27:21.350
auditor, back and forth. What the monitor[br]does, it fetches all the certificates.
0:27:21.350,0:27:27.720
So you have this giant pool of certificates.[br]They are cryptographically assured which
0:27:27.720,0:27:33.220
we will see soon. And the monitor just[br]fetches them all. And they have some form
0:27:33.220,0:27:39.920
of semantic checking. They can see, has[br]there been a certificate for my domain,
0:27:39.920,0:27:47.059
has there been any sub-CA created, which[br]is able to issue certificates for traffic
0:27:47.059,0:27:53.590
introspection, and so forth. Also, what[br]they can then, with this data, do, they
0:27:53.590,0:28:00.160
can identify misbehaving log operators. I[br]said, the logs, they are just gigantic
0:28:00.160,0:28:05.150
hoovers, which collect all the[br]certificates, and they need auditing, too,
0:28:05.150,0:28:09.390
of course. They need - they have a[br]position of power, because they are
0:28:09.390,0:28:18.300
managing this huge pool of certificates.[br]And one needs to challenge the log to
0:28:18.300,0:28:24.400
identify misbehaviour. This can be done by[br]the monitors, can also be done by the
0:28:24.400,0:28:32.490
auditors. Every client - right now, it's[br]implemented in Chrome. Chrome checks for
0:28:32.490,0:28:43.110
these certification transparency[br]cryptographically signed blobs. And the
0:28:43.110,0:28:47.460
browsers and everything, they can verify[br]the log integrity as well. So in the
0:28:47.460,0:28:56.860
backend, the log, it creates a hash tree.[br]This hash tree is signed. We will come to
0:28:56.860,0:29:05.650
that in a second. I got lost here. So both[br]monitors and auditors, they query that the
0:29:05.650,0:29:10.570
log entity is working correctly. It[br]wouldn't be a good thing if China could go
0:29:10.570,0:29:16.530
to Google and say them "Hey, we would like[br]to have this certificate removed." Google
0:29:16.530,0:29:22.670
could then comply or could not comply but[br]whether they remove the certificate this
0:29:22.670,0:29:28.340
would be auditible and this would be[br]observable to the public. So the good
0:29:28.340,0:29:33.690
thing is anyone run any software, anyone[br]of you in this room can run a log entity.
0:29:33.690,0:29:38.430
You need some kind of access to some[br]certificates, so whether or not you are a
0:29:38.430,0:29:45.340
certification authority, you can just run[br]a public log, and everybody can push their
0:29:45.340,0:29:53.710
certificates to your service. Right now,[br]this is not the case. Usually, the CAs run
0:29:53.710,0:30:00.230
the monitors and they run the logs, but[br]this is not by design, anybody can run
0:30:00.230,0:30:06.470
anything. One of the problems is[br]availability. So even through I can set up
0:30:06.470,0:30:15.140
a log for certificates, I have the problem[br]that my log needs to be online 24/7. My
0:30:15.140,0:30:22.870
ISP is not happy if I ask him to guarantee[br]this for me, if I don't pay much much much
0:30:22.870,0:30:31.350
more. So, how does it work? Currently, if[br]you get a certificate, you go to the
0:30:31.350,0:30:36.070
certification authority, You say, "hey,[br]I'm this wonderful domain, please could I
0:30:36.070,0:30:42.860
get a certificate?" And then you get the[br]certificate. What's additionally happening
0:30:42.860,0:30:50.350
with certification transparency is that the[br]CA upon issuing the certificate - this can
0:30:50.350,0:30:55.610
be any CA, this can be Let's Encrypt, this[br]can be Thawte, Symantec, you name it -
0:30:55.610,0:31:02.090
what they do is they send the certificate[br]once they issued it, they send the
0:31:02.090,0:31:13.500
certificate to one of the logs. The log[br]then signs the successful reception of the
0:31:13.500,0:31:18.000
certificate, and immediately sends[br]something back. This blob is called the
0:31:18.000,0:31:24.309
SCT, the signed certificate timestamp, and[br]this can then be included in the
0:31:24.309,0:31:32.990
certificate or with other ways. Key point[br]here is that once the server installs the
0:31:32.990,0:31:42.860
certificate, it also installs this SCT, so[br]that browsers can see it and parse it.
0:31:42.860,0:31:49.540
Some people I might have lost here.[br]Nonetheless, everything is easier in
0:31:49.540,0:31:53.771
pictures. Right now, currently - and these[br]are the pictures from the certification
0:31:53.771,0:31:58.570
transparency website, thanks for making[br]them - my pic skills are really not that
0:31:58.570,0:32:03.960
good, so I never would have been able to[br]make such beautiful graphs. So currently,
0:32:03.960,0:32:10.020
there is the certification authority. It[br]issues a certificate, and the website then
0:32:10.020,0:32:17.059
installs it in the correct directory. The[br]clients check it, and encryption can
0:32:17.059,0:32:23.240
happen. The additional step, and this is[br]the nice thing, it can happen without any
0:32:23.240,0:32:28.850
additional steps on the server side and[br]the client side, it's just the
0:32:28.850,0:32:33.650
certification authority needs to do an[br]additional step. So instead of just
0:32:33.650,0:32:39.920
issuing the certificate, they send the[br]certificate to the logs, the log
0:32:39.920,0:32:45.800
immediately sends back the so-called SCT,[br]the signed certificate timestamp, and this
0:32:45.800,0:32:51.830
is then included in the certificate, which[br]is shipped to the client. And then the
0:32:51.830,0:32:57.570
client, if it supports it, can ask the[br]server whether or not this particular
0:32:57.570,0:33:05.680
certificate is included or not. The things[br]that come back from the log they are
0:33:05.680,0:33:11.010
signed, they have an ID, and they have a[br]timestamp. These are the important things.
0:33:11.010,0:33:18.440
They need to be included in those SCT.[br]Also, what will be interesting in the
0:33:18.440,0:33:27.160
future, that the certificate can have[br]multiple log entries. So the SCT is like a
0:33:27.160,0:33:36.380
promise. The log operator promises to[br]include this certificate in its logs. And
0:33:36.380,0:33:40.140
everybody can check afterwards then if[br]this log has really publicly logged, or if
0:33:40.140,0:33:45.260
the authority has omitted to log it. In[br]the future it will be the case that many
0:33:45.260,0:33:52.800
SCTs can be within a certificate. If I'm a[br]certification authority I can go to any
0:33:52.800,0:34:00.000
log operator, send them every certificate[br]I have and then include many, many SCTs.
0:34:00.000,0:34:04.080
And the SCT is not private. This is just[br]an ID, it's a timestamp, and it's a
0:34:04.080,0:34:12.969
signature. This is probably too much.[br]There's multiple ways for the client to
0:34:12.969,0:34:21.289
verify that this certificate has an SCT.[br]So one of the methods for example is OCSP
0:34:21.289,0:34:26.389
stapling. Right now, if you have a[br]certificate, instead of going to the CA,
0:34:26.389,0:34:34.149
the server can staple the OCSP request[br]signed by the CA. And within this OCSP
0:34:34.149,0:34:44.109
stapling there can also be the SCT[br]included. How does it work on the log
0:34:44.109,0:34:48.489
side? Everything there is, is a Merkle[br]hash tree. A Merkle hash tree is a
0:34:48.489,0:34:52.940
wonderful data structure. It's nothing[br]new, it's nothing fancy, and it's not the
0:34:52.940,0:34:54.418
blockchain.
0:34:54.418,0:34:55.899
laughter
0:34:55.899,0:35:05.400
The Merkle hash tree, it looks, it's a[br]binary tree. Every node has two children,
0:35:05.400,0:35:10.570
and the hash value of an inner node[br]depends on the two children. So usually
0:35:10.570,0:35:14.600
it's the concatenation of the values of[br]the two children. Get's hashed again, up
0:35:14.600,0:35:19.859
to the root. Makes it very space efficient[br]because if I want to verify the integrity
0:35:19.859,0:35:27.799
of one entire tree, all I have to check is[br]the hash value of the root. Then, of
0:35:27.799,0:35:36.260
course, I can get all the relevant hash[br]values, and then I can reconstruct it. CT
0:35:36.260,0:35:45.460
uses SHA256 Merkle tree, and as I said,[br]everything below a certain node is
0:35:45.460,0:35:51.509
responsible for the hash value. So if you[br]remove a node, if you add a node, or if
0:35:51.509,0:36:02.490
you relocate a node, the hash values of[br]all the upper nodes get changed. Each of
0:36:02.490,0:36:06.920
the log operators, additionally to the[br]promise that they will include every
0:36:06.920,0:36:12.400
certificate that it receives, it also[br]gives a promise on the maximum merge
0:36:12.400,0:36:18.890
delay. The SCT, the promise to include[br]this certificate chain into the log, it
0:36:18.890,0:36:26.069
can only finish immediately because it's a[br]promise to include this into the log. And
0:36:26.069,0:36:32.400
the maximum merge delay is the time the[br]log operator promises to include it in the
0:36:32.400,0:36:41.150
big, big Merkle hash tree. The good thing[br]about the Merkle hash tree is despite
0:36:41.150,0:36:46.369
being very space efficient, calculation[br]efficient, not that much data overhead,
0:36:46.369,0:36:50.869
and so forth, it's not possible to[br]backdate elements. This was interesting
0:36:50.869,0:36:55.470
for one of the certification authorities[br]which issued SHA1 signed certificates,
0:36:55.470,0:36:59.670
even though the browsers and everyone[br]agreed that this should not happen
0:36:59.670,0:37:05.440
anymore. So it's also not possible remove[br]elements that have been once in there. So
0:37:05.440,0:37:09.780
if Symantec decided to remove the[br]google.com certificate, which was a "test"
0:37:09.780,0:37:14.359
certificate, this would be noticeable as[br]well, because if you remove one of the
0:37:14.359,0:37:20.739
leaves, the hash values up to the root,[br]they all change. And it's also not
0:37:20.739,0:37:26.690
possible to add elements. if you would[br]like to add an element unnoticably, you
0:37:26.690,0:37:34.160
cannot do this, because the hash values of[br]all the upper nodes would change. So how
0:37:34.160,0:37:39.989
do the logs operate? What they usually do[br]is once every hour, they receive the
0:37:39.989,0:37:48.319
certificates, and once every hour they[br]include them into their Merkle hash tree.
0:37:48.319,0:37:52.069
Probably already too much detail. They[br]build a separate tree, and then include it
0:37:52.069,0:38:01.480
and recalculate the root hash value, which[br]is then signed and shipped. And the nice
0:38:01.480,0:38:07.829
thing about the Merkle tree is that you[br]have multiple ways of proving things. One
0:38:07.829,0:38:18.359
of the things that can be proved whether[br]or not this log operator is honest. if a
0:38:18.359,0:38:21.989
log operator removes one of the[br]certificates, this becomes visible by
0:38:21.989,0:38:32.099
changing all the relevant nodes. Also,[br]it's very efficient. Also a figure from
0:38:32.099,0:38:39.279
the project website. On the left side, you[br]have a Merkle tree with some added
0:38:39.279,0:38:47.039
certificates, appended certificates. And[br]if a monitor or an auditor decides to
0:38:47.039,0:38:53.699
challenge the log operator, at a later[br]point in time, whether or not these
0:38:53.699,0:39:00.509
certificates D6 and D7 have been correctly[br]added, all the log operator has to send
0:39:00.509,0:39:07.329
are those highlighted nodes. This is the[br]root, this is the thing that is signed,
0:39:07.329,0:39:13.079
for example, every hour. This is public.[br]The certificates, they are public because
0:39:13.079,0:39:20.539
like, they're certificates. If now someone[br]wants to verify that not only these have
0:39:20.539,0:39:25.599
been included, this is very easy, because[br]you just have to calculate all the way up,
0:39:25.599,0:39:30.279
but also verify that all the other[br]certificates are still there, so none of
0:39:30.279,0:39:36.510
the old certificates have been removed,[br]there only needs to be three hash values
0:39:36.510,0:39:42.190
transmitted. And then the challenger can[br]re-calculate everything. So as soon as the
0:39:42.190,0:39:46.950
challenger knows those hash values they[br]can concatenate everything back together
0:39:46.950,0:39:57.079
and in the end, it should have the same[br]hash value as the root. Another proof that
0:39:57.079,0:40:02.790
is possible is whether a specific[br]certificate is still in the log. So it's
0:40:02.790,0:40:07.359
not only possible to challenge the[br]consistency of the entire log regarding
0:40:07.359,0:40:14.369
old data, but it's also to verify that a[br]specific certificate is still in the logs,
0:40:14.369,0:40:21.109
or made it into the logs. Remember, the[br]SCT, the thing that finished immediately,
0:40:21.109,0:40:27.190
is just a promise to include it in the[br]logs, and at a later point in time,
0:40:27.190,0:40:35.619
anyone, any auditor can challenge the log[br]operator if the certificate is really in
0:40:35.619,0:40:45.569
the log. So again, if I want to verify[br]that a specific certificate is in the log
0:40:45.569,0:40:51.300
I have the certificate that I would like[br]to challenge, then I just need, in this
0:40:51.300,0:40:57.259
example, those three nodes, and everything[br]else, the j node can be calculated because
0:40:57.259,0:41:02.330
I have the certificate. Then I have the[br]hash of the certificate. I need this hash,
0:41:02.330,0:41:12.430
then I can calculate this value, and so[br]forth, until I am at the root. So much for
0:41:12.430,0:41:17.470
under the hood. Merkle hash trees are[br]gone. One of the problems of those logs
0:41:17.470,0:41:22.630
are they are every growing. You might have[br]noticed, there is not a single word about
0:41:22.630,0:41:31.949
deleting certificates, for valid reasons,[br]they are ever growing. Of course, nothing
0:41:31.949,0:41:39.279
is forever, so what log operators do is[br]that they rotate the logs. So at a
0:41:39.279,0:41:46.119
specific point in time, the log gets[br]frozen, the tree is then static, and there
0:41:46.119,0:41:51.920
is another log entity, which is brough[br]online and used for, including the newer
0:41:51.920,0:41:58.069
certificates. Quite recently, aviator from[br]Google got frozen.
0:41:58.069,0:42:00.719
It contains 46 million certificates.
0:42:00.719,0:42:09.060
Small drawback of freezing a[br]log: as long as one certificate in this
0:42:09.060,0:42:16.279
log, in this three is still valid, this[br]log needs to be reachable. As soon as all
0:42:16.279,0:42:22.680
the certificates have been expired, it can[br]be dumped. But until that it has to be
0:42:22.680,0:42:25.680
available for the proofs.
0:42:28.099,0:42:34.529
One of the issues is that right now[br]there are just a few log operators.
0:42:34.529,0:42:39.240
In the future, there should[br]be many more. Not hundred-thousands of
0:42:39.240,0:42:46.840
them, but maybe hundreds of them. And they[br]need to exchange information. Some form of
0:42:46.840,0:42:53.460
log chatter should appear. The log[br]operators chatter with the clients to
0:42:53.460,0:43:01.349
verify that they all see the same state of[br]the Merkle trees. And this has been
0:43:01.349,0:43:08.940
published in a paper last year. Right now,[br]the idea is not yet at a level where they
0:43:08.940,0:43:14.440
need to chatter, which we will soon see.[br]This happens when you create memes on the
0:43:14.440,0:43:19.790
train. Usually, they are very bad memes.[br]This is apparently Gossip Girl, I've never
0:43:19.790,0:43:24.579
seen it, but if you google gossip and[br]meme, ta-da!
0:43:24.579,0:43:27.190
laughter
0:43:28.650,0:43:33.219
Who now runs the logs? Who are the[br]entities who are actively running logs. Of
0:43:33.219,0:43:37.650
course, Google is running the majority of[br]them. They proposed the entire thing, they
0:43:37.650,0:43:43.970
wrote the code to run these things, and[br]they run the large, open-for-all
0:43:43.970,0:43:50.369
certificate logs. Three of them are[br]currently open-for-all. Another one is for
0:43:50.369,0:43:54.559
Let's Encrypt certificates, and another[br]one is for non Let's Encrypt certificates.
0:43:54.559,0:44:00.470
Of course, Let's Encrypt issues a lot of[br]certificates., thankfully. So they
0:44:00.470,0:44:05.119
separated that, apparently. If you read[br]the mailing list, they promise that these
0:44:05.119,0:44:11.700
free open-for-all logs are separated[br]geographically and administratively. The
0:44:11.700,0:44:21.170
are run by different entities, but they[br]all have the same boss, and it would be
0:44:21.170,0:44:30.190
better if there were more open logs.[br]Symantec has one, Wosign, CNNIC. Everytime
0:44:30.190,0:44:34.410
Google detects that a fraudulent[br]certificate for google.com has been
0:44:34.410,0:44:44.109
issued, those certification authorities[br]are mandated to run CT. Which is a good
0:44:44.109,0:44:50.050
thing, I mean, public and everything.[br]Google has tens of millions of
0:44:50.050,0:44:54.160
certificates. They really have an[br]open-for-all log, so everyone can push
0:44:54.160,0:45:00.640
certificates in there. DigiCert, Symantec[br]is kind of big, but all the other nodes
0:45:00.640,0:45:05.849
which are listed on the website, they have[br]a hundred-thousand-ish certificates, which
0:45:05.849,0:45:14.320
is not that much compared to 50 million or[br]60 millions. Right now, Google already
0:45:14.320,0:45:22.359
mandates certification transparency for[br]extended valiity certificates, so if you
0:45:22.359,0:45:28.160
not only see the green text up in the left[br]corner of your browser, but also some
0:45:28.160,0:45:35.660
fancy name and big, big green whatever,[br]this is an EV cert. And Google mandates
0:45:35.660,0:45:44.190
for EV certs to have two SCTs. Firefox is[br]in the process of including it, I think.
0:45:44.190,0:45:53.450
Also, apparently, certificate transparency[br]works. Because, when Symantec issued this
0:45:53.450,0:45:59.950
certificate for google.com they released a[br]report stating that they found 23 "test"
0:45:59.950,0:46:06.910
certificates. Symantec said that it issued[br]23 test certificates. But the logs are
0:46:06.910,0:46:12.970
public, anybody can query them. And within[br]seconds, you can see that Symantec issued
0:46:12.970,0:46:20.839
another 164 certificates for other[br]domains, and also 2,500 certificates for
0:46:20.839,0:46:29.260
non-exisisting domains. Just regarding[br]this one issue. I need to hurry, time is
0:46:29.260,0:46:34.960
running out. Some of the downsides of[br]certificate transparency. Of course:
0:46:34.960,0:46:40.799
privacy. People can learn your internal[br]hosts, so if you have NAS for example, and
0:46:40.799,0:46:46.289
this NAS is only reachable within your[br]LAN, and you want to get rid of the
0:46:46.289,0:46:51.210
browser warning whenever you access the[br]interface of your NAS, you can get a Let's
0:46:51.210,0:46:56.779
Encrypt certificate but since not only the[br]certificate is published, but also it's
0:46:56.779,0:47:04.230
logged, people can see in the public log[br]file that there is, for your domain, a
0:47:04.230,0:47:10.210
NAS. Also, log entries must contain the[br]entire chain up to a trusted root
0:47:10.210,0:47:15.099
certificate, which excludes everything[br]which is self-signed, and everything which
0:47:15.099,0:47:23.660
is DANE. DANE is for verifying TLS[br]certificates using DNSsec. And since these
0:47:23.660,0:47:30.150
two have no trusted root, they are currently[br]not working for certificate transparency.
0:47:30.150,0:47:35.970
Now, of course you want to see the data.[br]You're gonna play around with this.
0:47:35.970,0:47:42.849
Basically, what you can query, everything[br]is JSON. So, if you know JSON, you can
0:47:42.849,0:47:52.769
work with certificate transparency. The[br]basic URL is like this. The URL is any log
0:47:52.769,0:48:00.719
server, responds with the current root and[br]it's signature, using this URL. Most
0:48:00.719,0:48:05.180
interestingly, it gives you also the[br]number of certificates and the time stamp.
0:48:05.180,0:48:11.740
It looks then like this. JSON, so you[br]have, this is the aviator log from Google,
0:48:11.740,0:48:18.759
which is now frozen. Has 46 something[br]million certificates, the hash value of
0:48:18.759,0:48:28.109
the Merkle tree, and the signature. Also,[br]you can challenge the certification logs
0:48:28.109,0:48:35.339
with consistency proofs, where you have[br]two states of their tree, and the log has
0:48:35.339,0:48:41.280
to prove that it did not modify anything[br]in between them. And of course, you can
0:48:41.280,0:48:49.900
verify that specific certificate is in the[br]tree with the second URL. And you can just
0:48:49.900,0:48:54.940
push certificates there with a POST[br]request. So you push it, they send back
0:48:54.940,0:49:00.859
the SCT, if you're the log operator, then[br]you would include this. Any website which
0:49:00.859,0:49:10.799
right now is not using SCT all it takes is[br]a POST request. Nothing more. Some screens
0:49:10.799,0:49:18.509
from the internals. This is for google.com[br]in the net internals view. What you can
0:49:18.509,0:49:28.130
see is that signed certificate timestamp,[br]the SCT, is received. It is valid. And
0:49:28.130,0:49:33.180
compliance is checked. So this was for[br]google.com. And everything worked out.
0:49:33.180,0:49:39.960
Last but no least, just to mention it,[br]Comodo operates a large search engine,
0:49:39.960,0:49:50.229
crt.sh. There you can query public logs.[br]Also, Facebook recently added a monitor
0:49:50.229,0:49:58.180
for certificates. So if you own a domain[br]name, and you use an entity which - no if
0:49:58.180,0:50:04.739
you own a domain, you can get updates if[br]the certificate changes. The also monitor
0:50:04.739,0:50:10.920
the public logs and as soon as, for[br]example, facebook.com uses a new
0:50:10.920,0:50:19.579
certificate that is logged in CT, you can[br]get a notification for that. This is what
0:50:19.579,0:50:23.619
it looks like. Remember, Facebook can also[br]send PGP-encrypted mails, then nothing
0:50:23.619,0:50:31.790
leaks to anyone. This screenshot was[br]borrowed from Scott Helme. So, what's
0:50:31.790,0:50:41.700
next? Just a few - One month ago, Google[br]announced that it will mandate certificate
0:50:41.700,0:50:49.650
transparency from October 2017 on. So if[br]you run a website which is secured by TLS
0:50:49.650,0:50:53.790
you might want to check before that date[br]whether or not your certification
0:50:53.790,0:50:58.680
authority is using certificate[br]transparency. I would expect to have more
0:50:58.680,0:51:07.049
logs and more certificates included in the[br]logs. In the far future, basically, the
0:51:07.049,0:51:12.869
idea of transparency and this Merkle tree[br]is open for anything. You could put key
0:51:12.869,0:51:17.759
management software releases, anything in[br]there. The team at Google, they also
0:51:17.759,0:51:24.779
builded a prototype for that, called[br]Trillian, and described in the paper
0:51:24.779,0:51:26.879
"Verifiable Data Structures".
0:51:26.879,0:51:29.279
Before we[br]come to the end and questions,
0:51:30.569,0:51:31.460
laughter
0:51:32.270,0:51:33.140
applause
0:51:37.660,0:51:41.579
There is a distinction. Of course, you[br]could solve this problem with blockchain
0:51:41.579,0:51:49.930
as well. But a Merkle hash tree is much[br]more efficient, much more elegant. When I
0:51:49.930,0:51:53.599
talked to a colleague on the train here,[br]he said, of course, you can just push the
0:51:53.599,0:51:57.539
log into the blockchain.[br]Yeah, not the same thing.
0:51:58.309,0:51:59.539
Thank you!
0:51:59.979,0:52:00.979
applause
0:52:10.769,0:52:13.899
Herald: Thank you Martin for a very[br]interesting talk! We have a few more
0:52:13.899,0:52:17.890
minutes left for Q&A, so if you have a[br]question, please line up next to the
0:52:17.890,0:52:24.390
microphones, and ask your question.[br]Remember: a question has a question mark
0:52:24.390,0:52:29.840
at the end. Also, if you're exiting,[br]please do so silently and from the front
0:52:29.840,0:52:34.650
door, thank you. I think we have a[br]question over there:
0:52:43.150,0:52:55.789
Q: Can you recommend some libs or software[br]where I can accomplish the TLS handshake
0:52:55.789,0:53:02.190
from the client side, so I can get the[br]SCT, via TLS extension, via OCSP
0:53:02.190,0:53:07.039
extension, via the inherited[br]pre-certificate SCT.
0:53:07.039,0:53:14.920
M: Not by heart. I mean, if it's part of[br]TLS certificate anything will go, OpenSSL,
0:53:14.920,0:53:21.589
whatever, it's just a field. Same as for[br]OCSP, so anything that does OCSP will
0:53:21.589,0:53:25.410
include it, it's just that clients that do[br]not know the extension will just not -
0:53:25.410,0:53:31.989
they will ignore it. But anything that[br]does OCSP or SSL handshake will work.
0:53:35.229,0:53:37.029
H: Thank you. Question from this microphone.
0:53:37.029,0:53:42.210
Q: Hello, thank you very much for the nice[br]talk. Do you know how much space is needed
0:53:42.210,0:53:45.070
to store all the logs currently?
0:53:45.070,0:53:54.009
M: I had the same question, but[br]unfortunately not. What they store is the
0:53:54.009,0:54:02.009
tree, and they store the entire chain,[br]excluding the root certificates. So,
0:54:02.009,0:54:09.700
probably two, three, four certificates per[br]entry, which is like - I think you can buy
0:54:09.700,0:54:17.969
at the regular electronic markets a hard drive[br]which is able to fit a lot of those entries.
0:54:20.199,0:54:21.739
H: Next question from that mic.
0:54:21.739,0:54:27.650
Q: Yeah, thank you for the talk. Why do[br]you need two SCTs for extended validation?
0:54:27.650,0:54:36.170
M: Because a single entity might cheat. So[br]it's like - even though you can detect it,
0:54:36.170,0:54:40.940
it's still a timeframe left. And if you[br]have two SCTs, which are operated
0:54:40.940,0:54:45.919
independently, the idea is it's not that[br]likely that the two will collaborate
0:54:45.919,0:54:48.239
to make a certificate disappear.
0:54:48.239,0:54:50.019
Q: Thanks!
0:54:50.019,0:54:51.499
H: That microphone, yes.
0:54:51.499,0:54:55.229
Q: I'm actually a bit surprised, because[br]Google has been pushing for making the
0:54:55.229,0:55:00.209
server HELLO as small as possible, and of[br]course, this is increasing the server
0:55:00.209,0:55:06.839
HELLO with, in this case, an SCT, and of[br]course, they are also doing OCSP stapling,
0:55:06.839,0:55:11.469
so that makes it even bigger. And this is[br]like a SHA256, so we're talking 256 bits
0:55:11.469,0:55:15.690
there, plus another one you said that, you[br]know, one is not enough. Actually I've
0:55:15.690,0:55:19.459
never seen that has more than one SCT.[br]Have you?
0:55:22.749,0:55:23.580
M: No.
0:55:23.580,0:55:24.010
laughter
0:55:24.100,0:55:25.390
Not yet.
0:55:25.390,0:55:26.589
Q: I've looked around, but nothing.
0:55:26.589,0:55:27.710
M: Yeah.
0:55:27.710,0:55:31.580
Q: It's actually increasing the size. And[br]I'm just wondering, where is this going.
0:55:31.580,0:55:39.319
Are we just gonna eat the costs of having[br]all these SCTs and OCSP stapling? Are we
0:55:39.319,0:55:40.319
prepared to eat that cost?
0:55:40.319,0:55:46.609
M: I think the cost is small compared to[br]the gain you get by HTTP2. So if you pipe
0:55:46.609,0:55:52.029
anything to one singular connection. I[br]think it's not bad of a cost anymore. But
0:55:52.029,0:55:57.319
of course, this is a policy thing. To[br]require a certain amount of SCTs, to
0:55:57.319,0:56:01.849
prevent fraudulent CAs.
0:56:01.849,0:56:07.859
Q: Is the idea that this will replace[br]something like the SSL observatory, where
0:56:07.859,0:56:13.900
browsers send in certs they see, and then[br]- you nodded, so I assume yes. And then
0:56:13.900,0:56:18.589
also, how does this work for people who[br]can't have their certs be public?
0:56:18.589,0:56:21.359
For people who are like issuing[br]things for internal networks?
0:56:21.359,0:56:27.329
M: If you can't have the certificate[br]public, probably the better way right now
0:56:27.329,0:56:33.650
is to have a certification authority which[br]is not using CT. In the future, it makes
0:56:33.650,0:56:39.930
it much more expensive to operate your own[br]CA, incorporate it in the trust stores.
0:56:39.930,0:56:43.969
But of course, this is costly. You have to[br]sign the certificate and everything.
0:56:43.969,0:56:52.180
Q: But if like in October 2017, when[br]Chrome rejects all certs that don't have
0:56:52.180,0:56:54.470
signed timestamps like what do I do?
0:56:56.570,0:56:57.579
M: Use Edge.
0:56:58.209,0:57:00.369
laughter
0:57:01.949,0:57:06.670
I'm sure you can disable it somehow,[br]but it's blerg.
0:57:08.470,0:57:15.949
Q: What about if someone tries SCT with[br]DHT or other system.
0:57:15.949,0:57:18.169
Not blockchain, of course!
0:57:18.169,0:57:21.289
It's possible to do that without[br]central authorities?
0:57:21.289,0:57:24.440
M: Sorry, say again?
0:57:24.440,0:57:31.670
Q: My English is very bad, I'm sorry. I[br]said, it is possible to do that without
0:57:31.670,0:57:36.799
some central authority, like Google[br]or over SCT, but
0:57:36.799,0:57:41.409
with a distributed hash table,[br]like DHT technologies,
0:57:41.409,0:57:42.739
M: Yes, yes, of course.
0:57:42.739,0:57:47.290
Q: And are there existing implementations?
0:57:47.290,0:57:53.079
M: For the centralized thing, yes. Not for[br]the distributed thing. But I think it's
0:57:53.079,0:58:00.269
just adding a layer of DHT on top of it.[br]So I'm sure you can think of a browser
0:58:00.269,0:58:06.039
extension which uses the DHT to obtain[br]SCT. But right now it's just purely
0:58:06.039,0:58:08.039
centralized. But the source is open.
0:58:08.039,0:58:09.229
Q: OK, thank you.
0:58:10.669,0:58:15.369
Q: I was just curious how it works if you[br]have a certificate which gets revoked, in
0:58:15.369,0:58:19.930
context of the tree. Especially if the[br]tree is frozen. So how does this work?
0:58:19.930,0:58:24.859
How do you revoke a certificate with a[br]tree, and then how does it work if it's
0:58:24.859,0:58:26.690
frozen already.
0:58:26.690,0:58:37.339
M: Good question! The goal of CT is not[br]- it's not about revocation. So whether
0:58:37.339,0:58:43.900
revocation path is taken regularly. So you[br]ask OCSP. It's independent of the
0:58:43.900,0:58:48.019
revocation thing. It's just publicly[br]saying that this certificate has been
0:58:48.019,0:58:56.789
issued. So removing a certificate from the[br]tree, which has been removed - revoked, is
0:58:56.789,0:59:01.390
not part of the specification. This is not[br]the use case. It's just logging the
0:59:01.390,0:59:03.089
certificates which have been issued.
0:59:03.089,0:59:07.950
Q: But if you audit all the logs, and you[br]want to know if something is, like going
0:59:07.950,0:59:11.380
on that shouldn't be going on, wouldn't[br]you want to know whether the certificate
0:59:11.380,0:59:12.650
has been revoked at some point?
0:59:12.650,0:59:20.279
M: Yes, but not in the logs. The logs are[br]just to prove that the CA has issued this
0:59:20.279,0:59:26.640
certificate, and to prove that the log has[br]correctly logged it. Revocation is
0:59:26.640,0:59:32.680
different. Usually, OCSP stapling with the[br]CA, but that's a different channel. So
0:59:32.680,0:59:34.760
this is not for certificate transparency.
0:59:34.760,0:59:36.520
Q: Thank you!
0:59:36.520,0:59:38.789
H: That's all the time we have for Q&A.
0:59:38.789,0:59:41.479
Big round of applause again for[br]Martin for a great talk!
0:59:41.479,0:59:42.859
applause
0:59:43.339,0:59:45.599
postroll music
0:59:45.599,1:00:08.000
subtitles created by c3subtitles.de[br]in the year 2017. Join, and help us!