 I hope it won't make a small demo, I hope it won't disturb you too much. Just a little bit, so I will say a little bit about myself, so if you say the title I want to say a few words about myself, I'm from Aachen, Germany, which is the most western town in Germany near the Dutch and Belgian border, and we are famous for our so-called printing, so if you want to try them, you can get some here after the presentation, and you can take two if you will ask a nice question. And yeah, I'm here because I'm involved in the Fedora project, I started as a second job and patched nearly everywhere, and recently I'm mostly involved with release engineering and patching, and I also have a strong security background because I work as a penetration tester at a company in Aachen, and we are now talking about certificate transparency because we all need certificates for secure internet because we never know who might be behind the computer that we are talking to, and the solution for this is that we get certificates from so-called certificate authorities, and they have to make sure that they know who wants a certificate to prove that he is the one we are talking to, so in the real world we have the government who does this work because they have a strong registry, but certificate authorities don't have these possibilities so they somehow have to bootstrap the security, and this has several problems, for example they can't really securely verify if you own a domain or not, they have some workarounds for this, for example they ask you to put a secret file somewhere on your web server and if you do this then you prove you control this web server and probably you own the domain, and also other possibilities are to do this via email, but then you still have the problem that everyone on the connection between the certificate authority and the domain can manipulate this and get a certificate even though it's not the actual domain owner, for example the hosting provider for your web servers could do it, and also of course since certificate authorities just use software, they have bugs whenever they check for something, so for example recently daddy became aware that they didn't properly check if the secure file does really exist, but they also use the value that was returned on an error page to think that the file was there, so the problem here is that every certificate authority does its own thing and I believe only Let's Encrypt was the first certificate authority that started really defining how they do this process and have a peer review to make sure that they do it right, and of course also the infrastructure of the certificate authority might be compromised, so if they don't do proper updates, they don't care about secure passwords, which all happened in the past, you might be able to get access to an infrastructure of the CA and then create arbitrary certificates, so this problem is that we have a lot of possibilities to get alternate certificates that we don't want to trust, but how do we know whether or not a certificate is the right one or it's an alternate certificate or a fake certificate, actually only the owner of the domain can really know if it's a certificate that he wanted to have that he requested, everyone else only could ask the domain owner, but then there's no secure path to the domain owner to ask him because the certificate is actually the one thing that he would like to use for this, so the idea is to create a possibility to have this communication between domain owners and everyone else to know is the certificate valid, and for this several employees at Google thought about just publishing every certificate that is ever valid and store them in a really secure lock, and this lock has several interesting properties because it has to ensure that everyone who's looking at this lock sees the same thing, so if you could manipulate the communication to the lock and have the certificates appear there, then it might not be secure because you can't be sure that the actual domain owner might have known the certificate, and also you want to make sure that you can't add or remove certificates from this secure lock, and for this they use a really interesting data structure, so-called Merkle hash trees, and what they do is they get all certificates for a certain period and then organize them in a tree, so yeah, for example to certificate because it's a binary tree, you create the hash value of the certificate, and then you again create the hash value of the both hash values of the certificate, and then go on for every new certificate, for example, oh sorry, if you add two new certificates, you get this tree, and then you just add this connection, so this data remains unchanged, and now whenever you want to verify whether or not a certificate is included in there and you have, you only need this value, this value, and this value, and this one you can calculate, you don't need all the other values to make sure that a certificate is within the data structure, and since they're talking about millions of certificates and gigabytes of data, it really reduces the complexity of handing all the certificates, and then it's of course good if you have all these certificates in the good and public infrastructure, that's a little bit annoying, but you also have to do something with it because just by publishing the certificates, you don't gain anything, okay, so I guess I have to try it without slides, so the next thing you have in the certificate transparency system is our so-called monitors, so these are systems that query the log for certificates, and they check it, for example, for suspicious certificates, for example, they can see if they're certificate for a certain domain, maybe you can tweak it a little bit, yeah, it's not a PDF, so I'll just try without it, oh, yes, perfect, thank you, not sure what, okay, so we have this monitor and then they check, so they check, they can check whether or not there are suspicious certificates in the log and then do appropriate actions on this, so how can you run these monitors, for example, you can get this as a service from several service providers, for example, from a CA that might just offer the service for every customer to notify you if a certificate appears at a different certificate authority, and you can also query it by hand, so there's a web search engine, which you can just use, actually I would like to show you live, but I don't dare to touch my system right now, so I will show the domain later, and of course, since certificate authority is a really open system, it's running on free software and you can access all data without any further authentication, you can just run your own software to query the database, so this would be the website where you can just put in any domain name and then see if there's a certificate stored in any trusted log, however, when you're using the log, you still have to make sure that all the data in the log is consistent and everyone is seeing the same thing, so this introduces the next component, the third one, the so-called auditory, the auditory is regularly checking the trusted logs to see if they are cryptographically consistent and they also check if a certain certificate is contained in the log, so I have a question for you, who of you is running Chrome or Chromium? Oh, no one. Two, okay, so you are already running auditors because the browser does this job and they check if there's a certificate in the log and starting in October, Chrome will only trust certificates that are publicly available in the certificate transparency log, so this will make sure that you can't have any targeted attacks and hide a certificate that is valid somewhere without the actual domain owner or other security researchers noticing it and as well you can run these auditing services as your own service and for example also, for example as part of a monitor that this already managed to catch bad CAs who issued certificates that they shouldn't have to, so for example, Symantec was ordered by Google to use certificate transparency because they issued some bad certificates in the past for testing purposes, for example for Google.com and then earlier this happened again, so they just created a certificate for example.com for example and then the security researcher noticed it and then asked the owners of example.com if this was intended and since it wasn't there, he raised this problem at the list for browsers who are managing the trusted root certificate authority. Another component about this to make it really hard for people to circumvent this checks is that all systems can gossip with each other, so whenever a monitor checks a log, it can also communicate with an auditor and they can check if they see the same data, for example they only need to communicate the head hash of the tree and then if they have the same value they know they see the same data or if for example one got newer data than the other, he knows that his previous head tree has to be somewhere in the tree and then they know all this data was the same and the other data was new and whenever someone wants to manipulate this data structure they can easily notice it and take appropriate action. So this sounds everything really good but are there also problems with this approach? So one big problem is that this means that all certificates will be public so you can't hide any domain names if you're using certificate transparency and for example I married last year and I created my own marriage website and then I was thinking whether to use HTTPS or not because then I want to have a cool domain name but I wasn't sure if I wanted to have this cool domain name published on the internet and having everyone being able to access it because I only wanted my guests to access it so this makes it a little bit of a problem and also for example this gossiping can also happen in the browser so the browser can recheck which certificates it saw from a server and if it changes it can report it to the server back to the server maybe to an auditor and then this can also be used as tracking browser so you have to make sure that you don't introduce other tracking than cookies with this gossiping and treat all these information that you use for this the same as you treat cookies so if you disable cookies also the gossiping should be disabled and all these certificate transparency project it's not direct protection in itself because it only makes it possible to protect against it because if there's a bad certificate in the lock and nobody looks at it nothing will happen so it will just work as before so it's important that as many people as possible really use the service to check if there are 40 certificates but the advantage is that not every HTTP client or any TLS client really has to support certificate transparency because on the other end as long as enough people are using this nobody will succeed with using bad certificates and of course whenever a CA creates a certificate that should not have been created it will be public so people can notice it anyways so it's basically the advantage is that you can know faster if there are certain attacks and you can react faster and the other advantage is now you even have this big database and a lot of information about all the TLS certificates you can even start figuring things out that might be problematic or might be specific for certain CAs which was very which was a very hard task to do when you had to scan every server and you didn't get all the certificates and of course with all the certificates you also get for example the public keys and can do a lot of tests there. So what can you use so what do you have to do to use this? Actually it depends on the certificate authority that you're using. So there's one possibility that only the information that is required for certificate transparency is added to a certificate and then you serve it just as before and everything else happens without any interaction from you as a server admin but there are also there might be a possibility that the CA sends you this information separately so via OCSP so you might have might need newer software that supports this properly and of course since it's all the open system you can we are at a developer conference you can also start coding and use the code to implement your own cool services or analysis for the information that is now available. And what's also very interesting is that you can use this framework in general to use it for other things so you don't have it only for TLS certificates but you can also use it for example to publish a public keys for messengers and for example we had this problem with the potential backdoor in WhatsApp recently but it wasn't sure so people said it might be a backdoor if Facebook could just change the encryption key for other people without people noticing it in the app but if you use a system like certificate transparency and all messengers would require that the keys are published in a lock that's cryptographically secure then it would be really hard to do these attacks without people noticing it and then ensuring that Facebook wouldn't dare or probably wouldn't dare to do it or if they did it once you could prove that there happened something that shouldn't happen and also another idea is to use it for example for secure application download so you can make sure that every file that is available for example executables for Windows or troubles for Linux are also published in a lock and then you also have trusted a community trusting repository and can make sure that if you download this tower and want to include it in your distribution it will be the same tower that the other distribution is using as well. So my time is over now. I want to thank you very much for your attendance and if you have any questions just ask and we want to use GPG you will find my details and you can sign my GPG key. So are there any questions? Yes. The operation doesn't work right so we're moving towards and there are proposals to be run in a short-term certificate that applies in three or four days. Do you think this mechanism would sustain this kind of approach that comes from an infrastructure that generates this kind of certificate? So the question was whether the system will even work if we have very short-life certificates and a lot of them and the answer to this is so the idea is you have these structures that are append-only you can't remove anything so they are always growing but the idea is to at a certain point just freeze these logs so you can't add any more certificates and then you only have to wait until the last certificate in this structure is expired and then you can remove this data because nobody needs it anymore for verification of current certificates. So in this case you had to create new logs regularly and then retire them whenever you're done with it. So your suggestion is to separate the tree that is specific to short-term but can you update it with different certificates and other trees that cost certificates with different timescales? So the question was whether or not there would be different trees for different kinds of certificates and yes it was something that I didn't mention there are already different logs so you don't have just one central log you have I think about 20 currently and it would also be good to have more of them because also means more redundancy and more publicity and there are already for example Follett's and Krupp which has a lot of certificates they have a separate log storage for exactly this case because it would be too much information for the other logs. Do you see any drawbacks in the system because nothing is ideal surely there must be something that may not be as ideal as we like. Do you see any drawbacks in the system? Yes so I tried to address it so for example the problem that when everything is public you might have information public that you wouldn't want to have public. So I think I didn't repeat the question today. So the question was what is the biggest drawback of certificate transparency? Yeah so one big problem is that everything will be transparent everything will be public but there are also some ideas to reduce the information that's stored in the certificate so currently you could already use wildcard certificates and then every sub-domain part would still be private because you couldn't reduce it from the certificate and there's an idea to just allow this for the certificates that are stored in the lock stores so you have a placeholder for the parts that are deducted and still have the proper domain published and then the client can still verify whether the certificate matches the one that he sees in this connection but if you only have access to the lock you can't get the information about the actual name. Okay so the question was was there any resistance or objections to the system and exactly about this public part there was one rejection so some certificates really pushed forward to extending the specification to remove these private parts from certificates and I think it's also about some other people mentioning that this might be a bad thing. Okay thank you very much and we're done here. And don't forget to try the printer. It's really delicious. Yeah. I only had one other system but I always assumed it was a bad cable so maybe it's... Yeah I tested it in the hotel room and it worked there with the television but I only... In other rooms they got some of the main things. Maybe because the last day the connector is now... Hi how are you? Nice to see you again. How are you? Good, good. Yes. Too much stress for me to prepare for June 20. Oh yes. Yeah but I live very close to Basel so it's only one hour something drive with a high speed train so that will be okay. So will you be at the social event already? Sure. Yeah so I don't know if I will be at the complete event but I will be at the social event.