I'm very excited to be here. I guess you are, too. And 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 Schmidiker.

Thank you very much for this kind words and this very nice introduction. As I already 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 the 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 also, we'll 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. So, 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, and this has been shown by history, this is not a case. So, there are nationwide 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 to and CT in particular is fascinating.

So, why is there something like certificate transparency? Like the name says it all. If you are a certification authority, you want to make public the certificates you sell or you issue. And with many good stories and with many good tools, it all started with a hack.

Back in 2011, there was this Dutch certification authority called Diginotar and they got pwned. They got really badly fisted. 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 then use it for your internal systems or for your website 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, motila.com. The attacker could manipulate the Firefox download, sign it with the certificate

and ship it over a securely seeming website to a project and so forth. So, this was back in 2011 and this was not just a small incident. It's what just 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 and 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 certificate. 99% of them which were from Iran. So, it was kind of a nation state attack against clients of either ISP based or border gateway based where people were browsing, were thinking they were browsing secured by HTTPS, but they were actually not.

This is a wonderful frame from the video. So, the guys from FoxIT which investigated this breach, they used the OCSP request. So, 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 locked. So, each of these requests is one of the clients seeing this certificate, this fraudulent certificate and asking Diginotar, hey, is this certificate 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. So, 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, Diginotar did not. So, they had unpatched software which was phasing the internet, might happen. They didn't have antivirus on the machines that issued this certificate. They didn't have a strong password for their admin accounts, so like password or admin.

Actually, you can read the report online and the recommendations from ENISA, from the European security body. They listed all the things that have been found and identified. Also, all the certification issuing servers were in one Windows domain.

And also, what kind of bad from Diginotar, they kept the incident secret. Of course, they did not want to spread out, to spoo into the internet. Hey, we got hacked and we have had bad security. They kept this incident hidden for more than two months. And after two months, when it got public and when the internet found out,

then actually something really, really bad happened. They found out and Diginotar then went bankrupt. That's a sad ending of the story. But this is not one of the problems that certification authorities face.

So, if you run a certification authority, you issue certificates based on the identity of your customers. So, you can create sub route CAs, so you can say, Martin, he looks like a nice guy. He looks like he knows security. Let's make him a CA, make him verify identities.

Probably not a good idea, but this is what the business model of HTTPS and certification authority 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. So, every browser, every operating system, every thing that connects over TLS has something like a called Trust Store, where it stores the entities which are entitled to issue certificates.

And the problem is, those CAs are not strictly audited. They have their requirements that they have fulfilled. They have to show that they have some kind of security. But afterwards, once they are certified and once they are in the trust stores, there is not such a strong incentive to audit them,

because they are already in trust stores and they had their audits and so forth. And this can lead to many problems. Another CA trust wave in 2011, it issued a sub-CA certificate. Anyone with a sub-CA certificate can issue a TLS certificate for any domain.

And they used it for traffic introspection. So, they were selling to a company which was building appliances, which can break open the network connections for banks, companies or entire ISPs, so that they can look into the traffic of its 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.

So, even though you are 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.

I think this was pre-installed on Lenovo notebooks. So, they had the 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 this CA, use it to sign certificates for anything, and have an additional layer of HTTPS injection, where it 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 CNN-IC. They issued a sub-CA for introspection companies. 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. Simon Tak was issuing test certificates to a company or whatever. Among them, Google.com, Opera.com, so things you probably would not like to test, 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. So, traffic introspection is a valid thing. So, 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 a traffic introspection device in their planes

and they issued not trusted certificates to inspect the traffic. Bad for them. Adrian Porterfeld, 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 okay, but it has to be transparent. People have to know that this is happening, that they are 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 place that TLS has its issues, nonetheless whether these certificates are issued or not. One of them is certificate revocation is tricky. So, 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. So, happens to be if on the first day of using this certificate, people notice, we should revoke it. Clients that don't get this update will be able to use this certificate for two and more years, so forth.

Also, another limitation is that all CAs can issue certificates for all websites. So, 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 states that they have to check the legitimacy of the request. This was published in a paper in 2013. So, there were 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 store

and so forth. You can claim a certain percentage of them. They are used for issuing private certificates, so within networks or whatever. Still, one third of them never issued a publicly obtainable HTTPS certificate.

Then, of course, there are 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

on a constant pace. A famous example is GoToFail from iOS, where they had an additional GoToFail missing bracket and the certificate validity wasn't checked. Also, we have a lot of embedded devices. Once they are powered up, they 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. As already mentioned, we have different trust stores per browser, per operating system. Everyone has a different trust base.

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. It could be much easier if people would have the same trust base on all their devices.

And there are plenty of deployment issues. SSL v2, everybody thinks it's that, but apparently it's not. Sebastian Schinzel will give a splendid presentation two hours from now about the Drowned Attack, and the Drowned Attack uses SSL v2 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 shmafu of the SHA-1 certificates, so certification authorities are not supposed to issue any SHA-1 certificates anymore. Some do, some get caught

because they backdated their certificates and so forth. It's a mess. Then there are cipher suits, so there are more than 500 cipher suits available for the different version of TLS. Every admin would like to be secure as possible, but which should he choose? As soon as there's money involved,

like Amazon, they need to be compatible with Internet Explorer 6 and so forth. It's really a mess. Yes, and of course, email STAR-TLS. Email never had the design to incorporate security and authentication.

So, as always, they just popped it on top, and this is STAR-TLS. Problem with STAR-TLS is it can be suppressed and people will fall back to plain text if they cannot reach the service with STAR-TLS. Perfect. Forward secrecy and so forth. Deployment is another topic which can be talked about.

And there's this troublesome development that the CAs, they get bought and they get sold constantly. So, just this year, Symantec bought the company Bluecode. 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. Bluecode got popular in the Arab Spring because they found Bluecode proxies which are capable of 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 larger CAs, is buying a Bluecode. One of the larger traffic introspection companies, things can look really fishy or scary.

Of course, they promised they will never use the Symantec. So, this is the state we're in. This is fine. 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 need to know how the lock icon appears. But the entire lock icon is a farce if you dig into the details. And we're all sitting in a room filled with flames, so to say.

So, this is where certificate transparency comes into play. Certificate transparency has the goal to identify fraudulent certificate certification authorities. In a perfect world, any certification authority would publish all its logs,

would publish all the certificates it issues. So, as soon as I get a certificate for schmideker.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 schmideker.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 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, I don't know, 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. Yeah, so 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 the browsers, with the android system, and they also control a large portion of the service. So, everyone uses Google except for those that use Bing. And other... No, just kidding.

What Google did is, once the DigiNotar hack got public, they pinned their certificates. So, since Chrome has a decent update cycle, they can ship the certificates which they expect to see with the browser update. So, as soon as 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. And 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 Feldt 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. So, 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.

And 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 auditable 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. All right, now, 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. 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 interchangeably. So, monitor can be an auditor back and forth. What the monitor does is it fetches all the certificates.

You have this giant pool of certificates. They are cryptographically assured, which we will see soon. 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-CAA created which is able to issue certificates

for traffic introspection and so forth. Also, what they can then with this data do is they can identify misbehaving log operators. I said the logs, they are just gigantic hovers

which collect all the certificates and they need auditing too, of course. They have a position of power because they are managing this huge pool of certificates and one needs to challenge the log to identify misbehavior

and this can be done by the monitors, can also be done by the auditors. So, every client right now, it's implemented in Chrome. Chrome checks for these certification transparency, cryptographically signed blogs 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 and we will come to that in a second. I got lost here.

Yes, 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 to 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 auditable and this would be observable to the public. So, the good thing is anyone can run any software. Any one of you in this room can run a log entity. You need to have some kind of access to certificates. So, whether or not you're a certification authority or 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 though I can set up a log for certificates, I have the problem that my log needs to be online 24-7 and 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 Thoughtly, 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. But the key point here is that once the server installs this certificate, it also installs this SCT so that browsers can see it and parse it.

Yeah, some people I might have lost here. Nonetheless, everything is easier in pictures. So right now, currently, and these are the pictures from the certification transparency website. Thanks for making them. My TIC skills are really not that good. So I would never have been able to make such beautiful graphs.

So currently, there's 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 that the certification authority needs to do an additional step. So instead of just issuing the certificate, they send the certificate to the logs. The logs immediately send 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 is that a 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. So 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. Yeah, this is probably too much. There are multiple ways for the client to verify that this certificate has an SCT. So one of the methods, for example, is OCSB stapling.

Right now, if you have a certificate, instead of going to the CA, the server can staple the OCSB request signed by the CA. And within this OCSB 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. The Merkle hash tree, it's a binary tree,

so 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, gets 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. SCT uses SHA-256 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.

So each of the log operators, additionally to the promise that it will include every certificate that it receives, it also gives a promise on the maximum merge delay. So the SCT, this 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 that 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 SHA-1 signed certificates, even though the browsers and everyone agreed that this should not happen anymore.

It's also not possible to remove elements that have been once in there. So if Sumitac 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.

So if you would like to add an element unnoticeably, 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, but 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. So one of the things that can be proved is that whether or not this log operator is honest. So 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's website. So on the left side you have a Merkle tree with some added certificates, some 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 they are certificates. And if now someone wants to verify that not only these have been included,

this is very easy because they 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 has been removed. There only needs to be three hash values transmitted and then the challenger can recalculate 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 that 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 SET, the thing that finishes immediately,

is just the 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'm at the root. So much for under the hood, Merkle hash trees are gone. One of the problems of those logs are they are ever-growing. You might have noticed there is not a single word

of deleting a certificate for valid reasons, they are ever-growing and 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 brought online and used for including the newer certificate. Quite recently, Eviator from Google got frozen, it contains 46 million certificates.

Small drawback of freezing a log is that as long as one certificate in this log industry is still valid, this log needs to be reachable. As soon as all the certificates in the log 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 hundreds, thousands of them, but maybe hundreds of them

and they need to exchange information. So some form of log chatter should appear where 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 the level where they need to chatter, which we will soon see. This happens when you create memes on the train, usually they're very bad memes, this is apparently gossip girl, I've never seen it,

but if you Google gossip and meme, so who now runs the log? Who are the entities which 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 currently are 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 promised that these three open for all logs are separated geographically and administratively, so they are run by different entities, but again, they all have the same boss and some way it would be better if there would be more open logs,

so to say. Symantec has one, Wosign, CNN IC, every time 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. Also, Google has tens of millions of certificates in them, they really have an open for all log, so everyone can push certificates in there. Digit, Symantec is kind of big, but all the other nodes which are listed on the websites,

they have 100,000-ish certificates, which is not that much compared to 50 million or 60 million. Right now, Google already mandates certification transparency for extended validity certificate,

so if you not only see the green text up in the left corner of your browser, but also some fancy name and the big, big green whatever, this is an EV cert, and Google mandates for EV certs to have two SETs. 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 it issued 23 test certificates, but the logs are public, anybody can query them, and within seconds, you can see that Symantec issued also another 164 certificates for other domains, and also 2,500 certificates for non-existing domains,

just regarding this one issue. So, I need to hurry, time is running out. Some of the downsides of certification transparency are, of course, privacy. People can learn your internal hosts, so if you have a 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 LED encrypt certificate, but since not only the certificate is published, but also it's logged, people can see in the public log files

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 want to 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 its signature using this URL. Most interestingly, it gives you also the number of certificates

and the timestamp. It looks then like this JSON, so 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 ACT. If you are the log operator, you would then include this. Any website right now which is not using ACT,

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 ACT, is received. It is valid and compliance is checked. So, this was for google.com and everything worked out. Last but not least, just to mention it, Komodo operates a large search engine, crt.sh.

There you can query the public logs. And 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. So, they 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 also can send PGP encrypted mails

and nothing leaks to anyone. This screenshot was borrowed from Scott Helmer. So, what's next? Just 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 certification transparency. I would expect to have more logs and more certificates included in the logs.

Yeah, in the far future, basically, the idea of transparency in this Merkle tree is open for anything. You could put key management software releases, anything in there. The team at Google, they also built a prototype for that

called Trillion and described in the paper verifiable data structure. Before we come to the end and questions, 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, anything. When I talked to the colleague on the train here, he said, yeah, of course, you could just push the log into the blockchain, but yeah, not the same thing. Thank you.

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. A reminder that a question has a question mark at the end. Also, if you are exiting, please do so silently and from the front door, please. Exiting from the front door, thank you. I think we have a question over there.

Do you can recommend some lips or software where I can download and 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? Not by heart. I mean, if it's part of the TLS certificate, anything will go open SSL, whatever. It's just a field. Same is 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. Thank you. A question from this microphone. Hello, thank you very much for the nice talk.

I wonder, do you know how much space is needed to store all the logs currently? I have the same question, but unfortunately not, no. I can, no. But what they store is the tree and they store the entire chain excluding the root certificates.

So, probably like two, three, four certificates per entry, which is like, I think you can buy the regular electronic markets, a hard drive which is able to fit a lot of those entries. Next question from that microphone.

Yeah, thank you for the talk. Why do you need two SCTs for extended validation? Because a single entity might cheat. So, it's like, even though you can detect it, it's still a time frame left. And if you have two SCTs which are operated independently,

the idea is that it's not that likely that they too will collaborate to make a certificate disappear. Thanks. That microphone, yes. 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 OCSE tapeling. So, that makes it even bigger. And this is like a SHA-256. So, we're talking 256 bits there, plus another one you said that one is not enough. Actually, I've never seen any that has more than one SCT. Have you?

No. No. Not yet. I've looked around, but nothing. Yeah, yeah. So, yeah, it's actually increasing the size. And I'm just wondering, you know, where is this going? Like, are we just going to eat the cost of having all these SCTs and OCSE tapeling? Or are we prepared to eat that cost?

If you, I think the cost is small compared to the gain you get by HTTP2. So, if you pipe anything to one single connection, I think it's not that of a cost anymore. But, of course, this is a policy thing to require a certain amount of SCTs to prevent fraudulent CAs.

Yes. 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'm going to assume yes. And then also, like, how does this work for people who can't have their certs be public for people who are like issuing things for internal networks?

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. So, you have to operate your own CA. You can incorporate it in the trust stores. But, of course, this is costly.

You have to sign the certificate and everything. But if, like, in October 2017, when Chrome rejects all certs that don't have signed time stamps, like, what do I do? Use Edge.

I'm sure you can disable it somehow, but it's raw. Just a question. What about the decentralized SCT with DHT or other system? Not blockchain, of course. It's possible to do that without central authorities?

Sorry, say again. English is very bad, I'm sorry. I say it is possible to do that without central authority like Google or other SCT, but with distributed edge table like DHT technologies?

Yes, yes, of course. And there is an existing implementation? 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 am sure you can think of a browser extension

which uses the DHT to obtain the SCTs. But right now it's just purely centralized, but the source is open. Okay, thank you. Hey, so 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? Good question. So the goal of CT is not about revocation. So whether the 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, which has been revoked is not part of the specification. This is not the use case.

It's just logging the certificates which have been issued. But if you audit all the logs and you want to know if something is going on, it shouldn't be going on, wouldn't you want to know whether the certificate has been revoked at some point? 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 is stapling with the CA, but that's a different channel. So this is not for certificate transparency. Thank you. Okay, that's all the time we have for Q&A. Big round of applause again for Martin for his talk.