WEBVTT 00:00.000 --> 00:09.960 So today I'm going to explain to you how you can hijack a web application before it's even installed and use certificate transparency for that. 00:10.260 --> 00:29.220 So to get started, so you all know that we're using much more HTTPS these days, so there's a lot of effort to move the web to encrypted connections, like Google gives you a higher search ranking if your site is using HTTPS, and there have been initiatives like Let's Encrypt to make it easier. 00:29.820 --> 00:34.880 So yeah, so HTTPS is a very important piece of modern web security. 00:36.480 --> 00:39.420 And part of that is certificate authorities. 00:39.420 --> 00:47.160 So if you want to run a web page with HTTPS, you need a certificate and that needs to be signed by one of these certificate authorities. 00:47.480 --> 00:54.020 And here are some of the bigger ones, like Komodo, Symantec, and Let's Encrypt, which is like a new and free one. 00:55.700 --> 01:00.740 And one question that comes up quite often is, do we trust certificate authorities? 01:01.300 --> 01:06.280 And for many people, the answer to that question is just, no, we cannot trust them. 01:06.440 --> 01:18.520 Because like there have been a lot of incidents in the past where certificate authorities have issued certificates for domains where they haven't been asked for, or even for rogue purposes for attacking people. 01:19.220 --> 01:23.340 So many people don't trust the system very much. 01:24.800 --> 01:30.940 And something I hear very often is that people say, yeah, this whole system is broken. 01:30.940 --> 01:32.200 We need to get rid of it. 01:32.200 --> 01:35.220 We need to completely replace that with something else. 01:36.100 --> 01:40.840 That's something I hear very often, especially in the IT security community. 01:41.620 --> 01:52.900 The problem, however, with that is in reality, I think nobody really has a plan with what to replace certificate authorities, or at least not any plan that is realistically feasible. 01:54.680 --> 02:00.820 And so what has been happening a lot in the past couple of years that people have thought, how can we improve this system? 02:00.820 --> 02:03.760 How can we make the existing system more secure? 02:04.780 --> 02:08.300 One thing that has happened is the so-called baseline requirements. 02:08.300 --> 02:15.160 So that's just a document that is writing down the rules under which these certificate authorities operate. 02:16.280 --> 02:23.460 So how they should issue certificates, how they should check that a domain really belongs to the domain owner. 02:23.460 --> 02:37.580 And that's already improving a lot, because if something strange is going on and the certificate authority is doing things that it probably shouldn't do, then there's probably something in the baseline requirements where you can say, hey, here's a rule that's not allowed. 02:39.360 --> 02:53.460 Then there's a technology called HTTP public key pinning, which is a very strong protection, but it's also kind of dangerous, because you could pin your site to a key and then lose the key. 02:53.520 --> 03:02.080 So this is a very strong technology, but you probably shouldn't use it unless you know exactly what you're doing. 03:03.100 --> 03:08.880 One other thing is called CAA, certificate authority authorization. 03:08.880 --> 03:18.820 What's happening there is that you can define a DNS record which is saying, I only want certificates from this specific certificate authority and not from any other. 03:20.560 --> 03:26.500 And then there's this thing called certificate transparency, which will be the main topic of my talk. 03:28.760 --> 03:34.420 And the idea here is that we have public logs of certificates. 03:34.680 --> 03:41.940 So all the certificates, we put them in a log that is also verifiable in some cryptographic sense. 03:41.960 --> 03:47.840 So there's more transparency in that system so that people can watch what's going on. 03:49.860 --> 03:53.800 So I'm not going to talk about the details of how that works. 03:53.800 --> 03:56.240 So there's a lot of fancy crypto. 03:56.240 --> 04:04.040 There are a lot of acronyms like signed certificate timestamps, etc. 04:05.240 --> 04:11.060 The basic idea is all of that is to prevent cheating in that system. 04:11.060 --> 04:23.860 So the idea is to make it really hard for any actor in the system, whether it's a certificate authority or log operator, to make something appear like it isn't really. 04:24.080 --> 04:35.680 So these logs have some cryptographic integrity and it is very hard to log something and then remove it again from the log without that being noted. 04:40.680 --> 04:49.640 So right now this is not fully implemented, but starting next year, at least according to the current plan, this has been changed. 04:49.760 --> 04:59.940 But according to the current plan, next year in April, there will be a requirement for all new certificates that they need to be submitted to at least two of these public logs. 05:02.840 --> 05:09.460 But in practice today, a lot of certificates are already logged and there are a number of reasons for that. 05:09.760 --> 05:15.040 So there are some certificate authorities that already submit their certificates to logs. 05:15.180 --> 05:22.280 One of them is Symantec and they do it because Google said they have to do it because there were a lot of issues with Symantec in the past. 05:23.300 --> 05:27.500 Let's Encrypt is doing it voluntarily because they say they want to support this. 05:27.500 --> 05:29.320 They think this is a good system. 05:29.840 --> 05:37.720 Also Cloudflare is doing it, so if you register a Cloudflare site, you automatically get HTTPS and they submit the certificates to logs. 05:37.760 --> 05:49.080 And also the Google search engine crawler, so if the crawler from the Google search engine surfs to your site and you have HTTPS, then they will download the certificate and submit it to their logs. 05:49.800 --> 06:00.340 So in practice, that means already today, a lot of certificates are in these logs and get submitted pretty quickly to these logs. 06:02.000 --> 06:07.140 So you can think of certificate transparency a bit like a CA watchdog. 06:07.140 --> 06:13.240 So everyone can look into these logs and see if there's anything that looks in any way suspicious. 06:13.580 --> 06:22.360 So the most obvious thing is to look into these logs if there are certificates for your own domains that you haven't ordered yourself. 06:22.700 --> 06:27.400 So if there's a certificate for my domain and I don't know about it, then something is wrong. 06:27.720 --> 06:29.080 That's obvious. 06:29.080 --> 06:39.020 But there's also things like if you look at this certificate, what's a bit suspicious here is that it's only valid for one day and it's for Google com. 06:40.820 --> 06:44.020 That was an internal test at Symantec. 06:44.140 --> 06:48.980 Apparently they have submitted the certificate from the internal test to the public log. 06:48.980 --> 06:50.780 So Google found out about it. 06:50.780 --> 06:54.960 So it's a certificate for Google com, but it's not from Google. 06:55.240 --> 06:59.120 So that started the whole Symantec controversy. 07:02.420 --> 07:04.560 This is also interesting. 07:04.700 --> 07:08.420 So does anyone see what's wrong here? 07:08.420 --> 07:17.610 So if you look at the location, it says it's in Rotterdam in California in the Netherlands. 07:19.010 --> 07:27.350 So I don't know about your geography skills, but California is, as far as I know, not part of the Netherlands. 07:29.870 --> 07:32.790 Maybe there are some similarities, but yeah. 07:34.010 --> 07:35.930 This one is also interesting. 07:35.950 --> 07:41.370 So here you can see in one of the lower lines, there's a domain name with two dots in it. 07:41.650 --> 07:45.470 So it says dot dot this, and that's not a valid host name. 07:45.650 --> 07:54.930 So we can be sure that there's no way anyone has really checked that this host name belongs to anyone because it's an invalid host name. 07:54.930 --> 07:56.490 It cannot belong to anyone. 07:57.830 --> 08:04.450 So here you can see that this system really works. 08:04.450 --> 08:12.750 People are looking at these logs and are seeing, okay, here's something strange, here's something fishy, and we should report that, and yeah. 08:13.510 --> 08:16.850 And hopefully then the CA will not do it again in the future. 08:18.390 --> 08:27.690 If you want to check this out a bit, there's a search engine for certificates and certificate transparency under your LCRTSH. 08:27.690 --> 08:28.650 That's very nice. 08:28.650 --> 08:30.550 That's operated by Komodo. 08:31.790 --> 08:38.370 So for example, the very easiest thing you could do right now is search if there are certificates for your domain that you don't know. 08:40.810 --> 08:46.090 But on the other hand, certificate transparency is also a kind of data source. 08:46.570 --> 08:54.430 Because we have all these certificates, okay, for example, they contain, as we have seen sometimes, the location and also they contain host names. 08:54.870 --> 09:04.830 So for example, if you operate a search engine, this could be interesting because you could know, okay, here are all these hosts that have web pages, so maybe I look at them. 09:07.810 --> 09:14.890 So in a certain sense, certificate transparency gives you a kind of feed for new host names. 09:14.990 --> 09:27.830 So if you're permanently observing these logs as they are public, like there's an API, you can just simply request the new certificates from them, and then you can look into these certificates and see host names. 09:27.950 --> 09:37.010 And when someone creates a new web host with HTTPS and gets a certificate, then it will end up in logs, so you kind of have a feed of new web host names. 09:38.530 --> 09:49.470 So now I want to switch the topic a bit to something which may appear like something completely unrelated at first, and that's web applications. 09:49.470 --> 09:54.930 And when I talk about web applications here, I mean things like self-hosted web applications. 09:54.950 --> 09:59.770 So things like WordPress, Joomla, or things like Nextcloud. 09:59.890 --> 10:10.110 These are usually written in PHP, usually use MySQL, you probably all know one of these like typical content management systems and similar things. 10:10.830 --> 10:30.050 When you install one of those, what usually happens, so you upload the files from the software to some web hosting company or on your own server, and then usually you just call the web page and get an installer and click through a few things. 10:30.050 --> 10:39.550 It asks you for your database credentials, then it asks you to create an initial administration account, and then you have installed your application. 10:41.070 --> 10:44.410 What's notable is there's no authentication whatsoever. 10:44.650 --> 10:52.390 So these installers have no protection, so everyone who, like if someone else calls this installer, he can install it just as well. 10:55.970 --> 11:08.810 And this has been known for a while, like people have been using Google to search for uninstalled WordPresses that have been abandoned, like maybe someone has uploaded them and then a problem happened and they just forgot about this installation. 11:09.530 --> 11:12.930 And if you find them with Google, then you can take them over. 11:16.230 --> 11:27.190 But the new idea here is there's a small time window between when a webmaster uploads this application and when he finishes the installation. 11:27.730 --> 11:38.070 And if we can hit that time window, we have an attack, because then we can do the installation and then we are in control of this application. 11:40.210 --> 11:43.570 And you might see where this is getting at. 11:43.610 --> 11:47.750 You may remember from earlier, we have this feed of new host names. 11:48.070 --> 11:52.710 So if we combine these things, we have our attack. 11:53.770 --> 12:05.050 So we can monitor the certificate transparency logs all the time, probably with some kind of con job, automated, and extract all the host names. 12:07.490 --> 12:20.750 And then we check these hosts, like we do a curl or a wget on them, and compare what they are currently serving as a web page to common application installers from WordPress, from Joomla, from whatever. 12:22.890 --> 12:27.570 So , and if you find one of them, we install this application ourselves. 12:27.570 --> 12:31.510 And if we're a real attacker, we would probably do this automated. 12:31.510 --> 12:33.590 Of course, it's faster. 12:35.290 --> 12:46.210 Now then, when we have done this installation, we can upload a plugin, because all these applications usually have some kind of extension mechanism where you can upload a plugin, and basically that gives you code execution. 12:48.250 --> 12:56.070 And ideally, we upload something that gives us further code execution, so we can just then execute arbitrary code. 12:57.410 --> 13:10.970 And what we do then is that we revert the installation, because how these installs work is usually just when they finish, they write down a config file, and if we delete that config file, then the installation is undone. 13:13.980 --> 13:34.400 So one thing we need for the whole thing are database credentials, but that's not a problem, because you can just define an external MySQL host, and there's, for example, a service called freemysqlhosting.net, which offers free MySQL hosting, which is very convenient for what we're trying to do. 13:36.920 --> 13:40.080 Yeah, so we have a little demo. 13:43.840 --> 13:57.560 So what I'm doing here, this is the search engine I mentioned earlier, and what I'm now doing is I put in a percent, which is a wildcard character, and then I put in .tlsfun.de. 13:57.560 --> 14:00.360 That is one of my own domains. 14:02.660 --> 14:05.320 And I'll make this a bit bigger. 14:05.420 --> 14:11.820 You see, the very latest entry here is for blog.tlsfun.de. 14:12.240 --> 14:16.800 And let's just copy that URL and see what we can find there. 14:20.180 --> 14:22.880 Oh, this is a WordPress installation. 14:23.440 --> 14:24.520 That is nice. 14:24.520 --> 14:29.080 So we click on continue, and click another button. 14:29.080 --> 14:31.440 Okay, now we need these database credentials. 14:32.160 --> 14:40.660 And as I'm prepared for this, I already have database credentials here, as I said, from free MySQL hosting. 14:43.420 --> 14:49.600 And password, and this host. 14:54.520 --> 14:57.660 Okay, run the install. 14:58.600 --> 15:11.180 So now I need a site title, I just use test, username admin, want some password for me, and an email. 15:11.180 --> 15:13.960 There, I just use something like trash mail. 15:16.720 --> 15:18.880 And installation. 15:19.420 --> 15:20.620 Now it takes a bit... 15:24.770 --> 15:28.170 Okay, so it says WordPress has been installed. 15:28.170 --> 15:29.290 Thank you and enjoy. 15:30.210 --> 15:31.330 Login. 15:31.690 --> 15:37.490 So now I'm logging in with the admin account I just created with the password I just typed in. 15:43.280 --> 15:53.140 Okay, and now I go in plugins, and click on add new. 15:56.700 --> 16:03.680 And so here I can just install plugins from WordPress itself, but I can also click on upload plugin. 16:03.680 --> 16:13.380 So I can upload my own plugin, which I have prepared before, which is called hijack, and we'll install it. 16:18.560 --> 16:32.160 Okay, so now in this plugin, I have a file called shell.php, and it doesn't show me anything, because it wants a secret. 16:32.160 --> 16:34.740 Secret is DEF CON 2017. 16:35.220 --> 16:37.560 It's not very exciting, but okay. 16:37.560 --> 16:40.440 Okay, and this is a very simple PHP shell. 16:40.440 --> 16:44.280 So we can make ls, and we can also... 16:46.400 --> 16:48.200 Okay, now the screen is cut off. 16:48.200 --> 16:49.280 That's not very good. 16:49.280 --> 16:54.880 But I can show you, for example, if I type in uname, then I get output of uname. 16:54.880 --> 16:56.620 So I basically have a shell now. 16:59.460 --> 17:04.820 And the interesting thing is I also here have a button which says remove installation traces. 17:05.840 --> 17:08.940 I'll just try to let you see that. 17:09.220 --> 17:10.580 Yeah, that's better. 17:12.980 --> 17:21.220 And now if I go on this again, then you see the installer's back. 17:21.580 --> 17:31.920 And that is important, because the person who is the owner of this WordPress, which in this case is me, but in the real case is someone else, will never notice what happened. 17:32.420 --> 17:33.860 So I have a backdoor now. 17:33.860 --> 17:41.040 I can execute arbitrary code on that server, but the owner of that WordPress installation will never notice it. 17:41.580 --> 17:43.300 At least that's what we hope. 17:45.200 --> 17:46.480 Yeah. 17:56.660 --> 18:03.040 So one challenge here that we have is that the certificates are not immediately public. 18:03.200 --> 18:13.440 There's a time lag, which so it is a maximum two hours, but I have kind of measured it, and it's usually about 30 minutes. 18:13.500 --> 18:17.780 So from certificate issuance until the certificate ends up in the lock. 18:19.480 --> 18:29.700 But it doesn't really matter, because there are still like enough people who will just create that host and then upload that WordPress and then go for a coffee and finish the installation later. 18:29.700 --> 18:33.760 So we'll just hit enough vulnerable hosts in that time frame. 18:35.960 --> 18:51.500 And this could also be further optimized, like you could say, I'm not only checking a site once, but when I see a new host in the certificate transparency locks, I just check it every five minutes again and again for maybe a couple of hours. 18:54.800 --> 19:07.080 So I ran a test script where I was searching for these installs this certificate transparency locks over three months, and I could have taken over 5,000 WordPress installations in that time. 19:07.280 --> 19:18.640 So that's quite a nice spot net if you have 5,000 ways to execute PHP code, use that to send spam or host phishing sites or whatever. 19:18.940 --> 19:24.200 Also around 500 Joomla installations, 120 next cloud and 70 on cloud. 19:24.200 --> 19:29.560 The others were all quite low, so the others I would say probably doesn't deserve the effort. 19:30.760 --> 19:39.040 One thing is Drupal doesn't show up because their installer page is so slow that the time out of my script hit. 19:41.460 --> 19:45.640 But yeah, that's just kind of a technicality. 19:47.520 --> 19:50.700 So how can you protect against this? 19:50.700 --> 19:54.780 So in very general, I think these installers need to be authenticated. 19:54.840 --> 20:04.540 I think it's just not a good design to say I upload an installer and then it's just without any protection out there in the internet and we just hope nobody finds it. 20:07.620 --> 20:14.760 The challenge is, of course, the developers of these applications, they want to make the installation as easy as possible. 20:14.760 --> 20:19.420 And if you add any kind of authentication, that creates extra effort. 20:19.440 --> 20:26.180 So I can kind of understand that they are reluctant, but still this somehow needs to be fixed. 20:28.060 --> 20:43.520 So one thing you could imagine is that the installation process creates a secret token, writes that into a file, and then the user has to download that file and paste that token into a web form and only then he can install the application. 20:43.960 --> 20:47.020 That's one option, but of course there are other options as well. 20:48.700 --> 20:56.600 So I reported this to a couple of vendors, primarily the big content management systems because they are the most interesting here. 20:57.020 --> 21:01.680 So from Drupal, Typo3, and OnCloud, I got no reaction at all. 21:01.680 --> 21:03.640 They just ignored my messages. 21:05.460 --> 21:17.360 Then from WordPress, NextCloud, and Serendipity, there came some answers like we would like to discuss this with other vendors and can we have a cross-vendor discussion. 21:17.360 --> 21:19.500 And I said, okay, I'll set up a mailing list. 21:20.340 --> 21:22.900 But then there was not a whole lot of discussion. 21:28.880 --> 21:30.420 This is interesting. 21:30.520 --> 21:36.460 MediaWiki is not vulnerable to it and was not even before I did this research. 21:36.460 --> 21:38.960 And the reason is their installer works a bit different. 21:38.960 --> 21:45.320 So when you finish the installer, they don't just write the config file, but they provide the config file for download. 21:45.400 --> 21:48.960 And you have to download it and then upload it again to your web host. 21:49.200 --> 21:51.840 Otherwise, the installation doesn't get finished. 21:53.380 --> 21:57.460 Although, MediaWiki allows you to use SQLite. 21:57.460 --> 21:59.420 And SQLite is file-based. 21:59.420 --> 22:04.160 So the installer still kind of allows you to create a file on the server. 22:04.180 --> 22:07.200 But you don't have a whole lot of control over it. 22:07.810 --> 22:12.360 I don't think this can be exploited, but it's a nice challenge. 22:12.360 --> 22:17.660 So if anyone of you has an idea how to exploit that, I would be very interested to hear about that. 22:20.520 --> 22:21.320 And then Joomla. 22:21.320 --> 22:27.940 Joomla was the only content management system that implemented a fix after I reported it to them. 22:27.940 --> 22:30.160 They released it a couple of days ago. 22:30.860 --> 22:36.800 And what they're doing is that it was basically my idea. 22:36.800 --> 22:41.680 The problem is I don't... I later decided that I don't like the idea anymore. 22:43.620 --> 22:49.180 So what they're doing is they're whitelisting localhost as a MySQL server. 22:49.180 --> 22:55.200 So if you have a local database server, the installation is just like it was before. 22:55.200 --> 23:01.140 And if you have an external MySQL server, then they have an extra authentication step. 23:01.880 --> 23:13.040 And the extra authentication step is that it has created a directory with a random file name, and you're supposed to remove that directory, and then you can continue the installation. 23:15.000 --> 23:16.660 So why don't I like it? 23:16.660 --> 23:28.760 So the problem here is if you have a large web hosting company that may have thousands of customers on a single server, then it may just be that the attacker already has credentials for that server. 23:29.840 --> 23:34.400 Like he can just register a couple of accounts at major web hosting companies. 23:34.580 --> 23:36.520 Or you could even think one step further. 23:36.520 --> 23:43.160 The attacker is, of course, attacking multiple applications at once, and WordPress is still vulnerable. 23:43.320 --> 23:53.840 So chances are high he may have already hijacked one WordPress on that server when he finds that Joomla, and then he can use the database credentials from that WordPress to hijack that Joomla. 23:54.200 --> 24:01.240 So I don't think it's an ideal fix, but at least I have to give Joomla credit that they were the only ones that did a fix at all. 24:01.380 --> 24:03.520 Like the others just didn't do anything. 24:07.470 --> 24:09.690 So what can you do as a user? 24:09.690 --> 24:12.730 If you think now, okay, that's a problem. 24:12.730 --> 24:17.190 I don't want my WordPress to get hijacked before I even use it. 24:17.190 --> 24:19.670 How can I protect myself? 24:21.870 --> 24:23.590 You could say, okay. 24:24.210 --> 24:37.530 As I said, these logs are not updated instantly, so you have like 30 minutes, but it's kind of a bit risky because like there's no guarantee how fast these logs are. 24:37.530 --> 24:47.310 And it could just be that next month Google decides they make a super fast log because they have optimized their software and it's running much faster and then this doesn't work anymore. 24:47.310 --> 24:52.530 So I don't think it's a very good solution, but yeah, you can think about that. 24:54.730 --> 24:58.310 Then there's the thing called certificate reduction. 24:58.410 --> 25:10.410 So with this certificate transparency, some certificate authorities were worried that, oh, that means all these host names are now public and our customers might not like it. 25:10.890 --> 25:14.210 Particularly Symantec now already offers that. 25:14.210 --> 25:20.150 So there is a part of certificate transparency where you can have redacted domain labels. 25:20.150 --> 25:27.670 So you could say this certificate in the log is for redactedlabel.something.com. 25:30.070 --> 25:33.210 But I don't think that's very practical either. 25:33.270 --> 25:38.630 So for one, as soon as the Google crawler sees your real certificate, you're still again in the log. 25:39.330 --> 25:43.930 And the other thing is not all certificate authorities offer this. 25:43.930 --> 25:46.570 And this has been quite controversial. 25:46.570 --> 25:50.590 So I'm not entirely sure if it's going to stick around. 25:50.690 --> 25:57.590 And particularly if you had some web host that automatically issues certificates for you, they are likely not going to use this. 25:57.910 --> 26:00.650 So it's also not a very good solution. 26:00.850 --> 26:05.670 You can use a htaccess file to just password protect your installation. 26:06.230 --> 26:08.830 That works. 26:08.830 --> 26:14.610 A problem is that some of these applications use htaccess themselves to configure things. 26:15.530 --> 26:18.450 And you need to make sure that that doesn't interfere. 26:18.450 --> 26:22.670 For example, if you finish a WordPress installation, it creates an htaccess file. 26:22.830 --> 26:30.290 And what you can however do is that you put your password protection htaccess file in the upper directory. 26:30.810 --> 26:39.330 Because like Apache server goes recursively through all the directories to scan for htaccess files. 26:39.950 --> 26:45.890 That doesn't work at all web hosting environments because sometimes you only have write access in your web root. 26:46.010 --> 26:49.510 But if you have write access in the upper directory, then you can do that. 26:49.690 --> 26:55.750 And that's kind of the best you can do right now as long as these applications don't protect you. 26:58.110 --> 26:59.730 So, yeah. 26:59.730 --> 27:02.050 Defending as a user is hard here. 27:02.050 --> 27:04.570 And we really need fixes from vendors here. 27:08.050 --> 27:11.730 Then I was wondering, do attackers already use this? 27:11.730 --> 27:14.170 Does anyone know about this attack? 27:14.170 --> 27:15.810 Has anyone had the same idea? 27:15.810 --> 27:17.430 And do they already exploit it? 27:17.430 --> 27:25.930 So, I sent a couple of posts with just random subdomains from my domains and checked if anyone would access them. 27:26.010 --> 27:29.310 And okay, my own test script would access them. 27:29.430 --> 27:30.450 That's obvious. 27:32.110 --> 27:38.970 And I also saw this in the log file which says Netcraft survey agent. 27:38.970 --> 27:40.790 So, Netcraft is a company. 27:40.790 --> 27:43.430 I think they mainly do statistics around the web. 27:43.430 --> 27:46.430 So, I think this is non-malicious. 27:46.430 --> 27:56.850 And it's also a good example that this data, of course, it can be used for attacks, but it can also be used for legitimate proposals like doing statistics, looking for new websites. 27:56.850 --> 27:59.660 That, I think, is legitimate use of that data. 28:01.010 --> 28:06.090 So, I think nobody is exploiting this yet, but that may change. 28:06.930 --> 28:07.550 Yeah. 28:08.070 --> 28:14.830 So, major takeaway, I think, is unauthenticated installs are a security risk. 28:14.830 --> 28:20.770 And I really think these web applications need to do something about that and should fix this. 28:23.710 --> 28:32.590 Then one thing, and I think that message many people haven't gotten yet, there are no more secret host names, at least if you use HTTPS. 28:32.590 --> 28:47.070 So, if you ever had the idea in my company I could have internal secret something something dot company name dot com and there's an internal backend interface that nobody ever will find, forget about that. 28:47.190 --> 29:00.290 That has been a bad idea in the past anyway, because host names are not encrypted, even if you use HTTPS, the host name is always visible on the traffic, both through DNS and through server name indication. 29:01.710 --> 29:04.410 But now it's a really broken assumption. 29:04.410 --> 29:09.390 So, if you have HTTPS for your web pages, you must assume that the host names are public. 29:09.430 --> 29:16.950 And it's also interesting if you're maybe a pen tester or looking at a bug bounty program, this is a good way to search for host names from companies. 29:19.110 --> 29:28.470 And, yeah, final takeaway, certificate transparency is a valuable data source, both for attackers and defenders. 29:29.750 --> 29:33.150 And I'd like to say something that I find important. 29:33.150 --> 29:40.330 So, when I submitted this talk, I feared a bit that people might use this as an argument against certificate transparency. 29:40.710 --> 29:43.850 And therefore I want to make very clear that I don't think it is. 29:43.850 --> 29:46.890 I think certificate transparency is an amazing system. 29:46.890 --> 29:52.430 It's probably the best security improvement the TLS ecosystem has seen in a while. 29:53.510 --> 29:56.090 And I think the problem really lies elsewhere. 29:56.090 --> 30:02.510 Certificate transparency is just kind of amplifying the problem of unauthenticated installers here. 30:03.070 --> 30:04.350 So, yeah. 30:06.510 --> 30:13.050 Yeah, I think it was pretty fast, so we should have time for some questions. 30:13.050 --> 30:13.730 Thank you.