TLS interception considered harmful
CC Attribution 3.0 Germany:
You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal purpose as long as the work is attributed to the author in the manner specified by the author or licensor.
Böck, Hanno
With the more widespread use of encrypted HTTPS connections many software vendors intercept these connections by installing a certificate into the user's browser. This is widely done by Antivirus applications, parental filter software or ad injection software. This can go horribly wrong, as the examples of Superfish and Privdog have shown. But even if implemented properly these solutions almost always decrease the security of HTTPS.
 Now, this is Hanno Berg. I think a lot of you probably already know him because he's a well-known journalist and most of you probably have read something in a lot of magazines where he is writing something and he will speak about TLS interception considered harmful. So this is about HTTPS and this is not only encryption, it's also about identities and whom we trust and who decides whom we trust and how this can be attacked. Well, have fun. Hello. So TLS interception. This is a problem that came up earlier this year when there was software called SuperFish that got detected and that had a very severe security vulnerability. But this also highlighted kind of an issue that a lot of software pieces are doing this and it's a questionable way of doing things and I wanted to provide an overview about this issue and get a bit deeper into it. Quickly about myself, as she already said, I'm a journalist mainly writing for the German IT news magazine Golem. But right now I'm also doing some IT security work for the core infrastructure initiative from the Linux Foundation and mainly I do fuzzing there. So I'm trying to improve the software that you're running on your computers. So I want to go a step back and talk a bit in general about TLS and the kind of discussions we had in the past five years where we had a lot of vulnerabilities. You probably heard about some of them. We had HeartLate which had most attention but also we had things like Beast, Crime, Sparky13, Poodle. So we got a lot of attention about the security of TLS and CryptoConnections and there are also some things to learn from that. One example was the so-called Beast vulnerability. When the Beast vulnerability was presented it was already a known issue that older versions of TLS had some issue with the CBC mode which is the encryption mode for the symmetric encryption. So there was already a fix available but back then most people still used the old TLS 1.0 version and still today a lot of web pages only support TLS 1.0 and yeah. So the fix is one possible fix is to use a newer TLS version that doesn't have this issue and there's also a workaround where you can, if you do a certain kind of splitting of your data packets then this vulnerability doesn't happen. Then there was an issue called Crime which was that due to compression in TLS that would leak information about the data inside and the relatively trivial solution is don't use TLS compression. It gets a bit tricky because HTTP also has compression and it has similar issues and it's a bit harder to fix it there. So what's also interesting here is again we have an issue that's part of the protocol so it's not that there's a bug in the software but it's the TLS protocol itself that had a security issue. And then we had Lucky 13 which was an issue with the way that TLS combines the MAC and the padding and the encryption and in which order it does it. So generally today we consider it the only safe way to combine the different things is to first encrypt and then do a MAC. So the MAC is there to guarantee that the package has not been manipulated. And there was a timing side channel so by checking whether what kind of error occurred on a connection an attacker could find out something about the key. And so the workaround about is do everything timing safe but this is very hard. And the solution would be not to use these encryption modes anymore that have this weakness. And there's currently only one encryption algorithm in TLS specified that doesn't have this weakness which is AES in the GCM mode. And there's also RC4 but that has other weaknesses so we don't want to use that as well. And then there was Poodle which was a vulnerability in the very old SSL version 3 which kind of was okay it shouldn't be a problem because it's so old nobody should be using it but a lot of people were still using it and there was also a downgrade attack you could do. But then there was something interesting that there were some devices that actually had the same vulnerability in also in TLS because the issue was that in the old SSL version 3 there was a padding and it was not defined what's inside this padding. So you could have arbitrary values in that and that somehow could be used for an attack. So TLS defined that this padding must be a specific value but some implementations didn't check that so they managed kind of to port the vulnerability from the old protocol by doing a bad implementation to the new protocol. So and then we had some debate about something called forward secrecy that's a feature of encryption technologies where you generate a key for each connection. And the idea there is that you destroy that key after the connection and then if your private key later gets stolen it doesn't have such a high impact because the connections from the past still cannot be decrypted. And now there are modes in TLS that have forward secrecies and others don't but there's really no good reason not to use forward secrecy and it's now also agreed upon that the future version TLS 1.3 will only have forward secrecy modes and the modes without forward secrecy will be removed. So that's kind of the debate we had on TLS in the past years. There were some more vulnerabilities but some of the lessons to learn here is that we have security bugs in the protocol which means that even if you implement the protocol as it's written in the standard you may have security vulnerabilities. So you need to know about all these workarounds and what to disable to have a safe version of TLS today. And only the very latest TLS 1.2 with the GCM mode and with forward secrecy is really considered up to date crypto and considered safe these days. But you still need to support more or less TLS 1.0 because there are still so many servers in the internet that if you would disable that you couldn't serve a lot of web pages. But that's kind of tricky because you have these timing issues and these record splitting issues so if you want to do that safe it's quite complicated. And then we have this problem with certificate authorities. So as you probably know if you want to have an HGPS web page you need to get a certificate and there are hundreds of these certificate authorities and all these certificate authorities can have sub certificate authorities so we don't even really know how many there are. And the old system was that basically every CA could issue a certificate for every domain. So this has the impact that the whole system is only as secure as the worst of all CA's. So if one gets breached everyone has a problem. And this also has the impact that it doesn't really matter which CA you choose. So if you say I go to a CA that's especially trustworthy for whatever reason that doesn't really make any sense. And yeah so and this also had practical implications. We had a lot of cases in the past years where certificate authorities issued certificates like for Googlecom but not to Google but to someone else. There was many issues with Komodo. There was Turk trust. There was CNNIC the Chinese government controlled CA with India CCA. There was Digi Notar which later went bankrupt. ANSI which is a French government controlled CA. So for quite different reasons so some of them were hacked. Some of them like there was an issue where this Chinese CA sold a sub certificate to an Egyptian company that then used it to intercept traffic in their own network. But all of them so we had a lot of issues where these CA's didn't follow the rules and issued certificates to people who shouldn't get those certificates. And over the years there have been many debates about how we could fix this. And so there was an idea called sovereign keys which was interesting but quite complicated. There was a talk on the Congress a few years ago. There was TAC which was a kind of key pinning proposal. There was convergence which the idea was to check a certificate from different points in the network. And Dain which is based on DNSSEC but all of these solutions have in common that none of them ever got really deployed widely. But recently there's now a standard called HTTP public key pinning which I like a lot and the idea there is that a web page can say okay this is the key of my certificate and here's a backup key and the browser should store this key and the backup key and in the future only these keys are accepted for this web page. So we have kind of additionally to the certificate authorities we have a trust on first use system that not every CA can issue a certificate for this web page that can later be used for a text. And also the browsers these days contain some pre-pinned certificates so for example if you create a bad certificate for Google com it will not really work at least in Chrome and Firefox because the browser already knows that Google only gets certificates from Google's own certificate authority so you cannot use a random certificate authority to issue a certificate for Google. The problem with that is a bit that it's not widely used. So there was recently a statistics in the about the Alexa top one million web pages and only one of them was using this key pinning header and at some point there were four pages and now it got down to one so it's really not widely deployed which is unfortunate because this is really a very big improvement of the security of the TLS system. And then there's a concept that's mostly developed by Google which is called certificate transparency and the idea here is that we have a public log that's append only so it works a bit like Bitcoin that can be verified by anyone who wants to and that has all certificates in it and the idea is to have several of these certificate transparency logs. So that's a very promising idea so it doesn't prevent attacks with wrong certificates but it pretty much makes sure that you cannot hide these attacks. So there's a very high likelihood that if you have certificate transparency in place that all attacks will be detected at some point. And it's not really widely deployed but Chrome has some preliminary support and Google plans to require it from at least for the so-called extended validation certificates and later for all certificates. So there are some things happening in this space to mitigate these problems with certificate authorities. So finally after many, many years where we had this problem we have now some mitigations that are coming but also the conclusion there is that if you want to verify TLS certificates you need to know about these things and your implementation needs to know about it and you have to stay on top of the development what's going on in TLS security. And some late development is that a lot of people are pushing now for HTTP as everywhere. Google did a lot in this case and also Mozilla now plans to mark HTTP pages as insecure generally then certificates are no longer expensive things so there are no certificate authorities that give you a certificate for free. There are two now and let's encrypt will start pretty soon which we will have a talk later today also. And I think this is generally a very good thing and I also think this is a good thing even if you don't have any secret data on a web page because what many people tend to forget is HTTP. HTTPS guarantees that your data is transmitted encrypted but also that it has integrity so that means that the page the user sees is really the page that came from the server and it was not manipulated on the way. So even if your data is not secret you always want your data to be correct. But there are also people who think that this is a very dangerous development like here's a picture I made on the Black Hat conference recently where a company called Blue Code you may have heard of them they have some questionable approach to security researchers that they say TLS traffic is pervasive and introduces risk especially it can also be used for advanced persistent threats so if anything is APT that's really dangerous. And obviously they sell your solution for that so they have a way to inspect your TLS traffic. And many other companies do as well this is from F5 and this is I don't know which company this is I'll sell you some products that allow you to kind of inspect your encrypted traffic. So there are a lot of products that are doing this like we have these enterprise security solutions like what Blue Code and F5 is selling we have now antivirus software that's doing this we have parental control or youth protection we have some ad blockers or a lot of ad injection software which is usually the stuff that you don't want but may have installed anyway on your computer. So how do they do this? So the idea here is that so you cannot inspect or manipulate the traffic if there's HTTPS because it's the idea of HTTPS to prevent that. So the solution these products have is that they install their own certificate authority root certificate into the browser and then basically what they do is a man in the middle attack on your browsing. And then earlier this year there was a software called Superfish that some people found on their Lenovo laptops it came pre-installed on Lenovo laptops. What this software did was that when you were surfing the internet it analyzed the images and tried to find objects on these images and then it would present you some ads that were related to these images. So I don't know you could surf a web page about camping and then it would give you an ad about where you can buy a tent. So what this also highlights is that there's now this kind of very strange market that there are companies who are producing software that nobody really wants but they are paying companies like Lenovo that they install it on their laptops. And what also happens is this software bundling where someone you install some software and then the installer asks you with some very tricky UI thing that do you also want this toolbar or this whatever and then if you click the wrong button you have something installed that you never wanted. But the problem with this Superfish software was that it used such a man in the middle proxy and it had the same certificate on all installations. And so also it had the same private key on all installations and the key is naturally part of the software. So you could just extract this key and two days later someone did this so the key was public and with this key you could basically attack everyone who is using a laptop that had this Superfish software installed. So yeah. It was a big PR disaster for Lenovo. They later said okay we're sorry they provided a removal tool. They then said okay we've learned from it we will be more careful in the future. A few days ago if you've seen this Lenovo is now using BIOS root kits to install some crap on your Windows system I don't know if they have really learned anything. But then it became even more interesting than people found out okay the Superfish was using a software module from a company called Komodia and this was used in many different applications and all had the same problem all had this shared key problem and people were extracting keys from many different products. So there was a product called StuffCop and Custodio which was some parental control thing and some VPN software and then at Adware it's an anti-Adware tool and there was also a lot of Adware like this stuff that gets installed on your system you don't really want whatever. So it turned out this problem was much bigger than the Superfish issue that there was a lot of software that all had the same vulnerability. And then Philippo Valzada who is a Cloudflare engineer he found out that there was a trick how you could create certificates that all of these Komodia products would accept. So first we thought okay you have a key for every of these products but then there was kind of this trick because what happened was if the software would connect to a web page with an invalid certificate it would replace it with a certificate that was signed by this man in the middle proxy but that had an invalid host name. But what this software didn't consider was that certificates also have this field subject alternative name where you can add additional host names for a certificate and these were kept intact so you could create a certificate that was signed by any CA or by your own self signed CA and then add the host name for the web page you want to attack in this subject alternative name field and then every software that had this Komodia module would accept this certificate. And then I found this kind of ridiculous then Lavasoft which is producing this ad adware software they said on their Facebook page Lavasoft's most recent release of ad adware web companion does not include this capability so this Komodia SSL interception but we are not yet able to confirm with certainty that the compromised component of the Komodia SSL digester has been removed. So there you have a company that's producing a security product and they say okay we had a severe security vulnerability and we don't know if we have really fixed it and that's kind of a bit ridiculous and it took me like 15 minutes to verify okay they were still vulnerable I commented it on their Facebook blog post maybe it helped them I don't know. And then a few days later there was some ISE channel where people who were interested in this issue were chatting and then someone posted a link that okay there was someone asking he has a software called Priftock on his system and he wanted to know if this is something like Superfish and it turned out this was a software that was developed by a company founded by the CEO of Komodo and what this software would do was it would identify ads that it considers as dangerous it wasn't really clear why what criteria or that would impact your privacy it would replace them with its own ads so thereby they make money because they replace some ads with their own. And then I looked at it and found out okay it does not use a Shirt certificate so it's not like Superfish but what it did is it just accepted on the other end every web page certificate so you could have a random invalid certificate and the software would connect to it and replace it with its own certificate that was valid for the browser because it had its root certificate installed and then also I looked at the traffic of the software and it was sending every URL you were surfing to in clear text to some server from this company and then yeah I wrote a blog post about this it was pretty late in the evening and then I went to sleep and the next day BBC called me so this really generated a lot of interest in the media because the issue here was really Komodo because Komodo is a company that's selling TLS certificates that's the biggest certificate authority these days and so the same company that's selling you the certificates for HTTPS security is related to a product that's breaking the security so it was not a Komodo product but they had some close ties so Komodo was advertising this product and also Komodo had a browser that was bundled with this PrifTalk but this version in the Komodo browser was not affected by this vulnerability because that worked as a browser plugin and not as a man in the middle proxy but yeah so yeah we had another issue where this TLS interception proxy caused a severe security vulnerability and then I looked at some other products that would intercept TLS traffic and there are some antivirus applications and I looked especially at Avira, Kaspersky and Asset because these were the ones that were freely available and I could easily test and none of them had a severe vulnerability like SuperFish or PrifTalk but all of them had something that made the TLS connection worse so the biggest issue was that Kaspersky was then still vulnerable to the freak vulnerability so freak was a vulnerability where you could downgrade connections to some export mode from the back in the 90s when it was forbidden to have strong crypto and it was found that somehow you can trick open SSL into doing these old connections and very shortly some days after this freak vulnerability was published someone posted in Kaspersky's forum that okay you have this problem with the freak vulnerability and it was ignored for more than a month so I re-found this issue in Kaspersky and then I earlier told you about this key pinning standard we have now so you might think okay if we have this key pinning then this whole TLS interception proxy shouldn't really work because if the browser has a Google certificate pinned and then it gets replaced from some TLS interception that shouldn't really work but the problem there is that the browsers had to do some kind of compromise because there is already so much software that does this TLS interception that they couldn't break all of it so what they did is they said okay if there is a manually installed root certificate in the browser then it would ignore that key pinning header so it's not really nice but you can kind of understand why the browsers did this. Now what should happen if you do it right then these products should test this header themselves on the back end side but none of the software that I looked at did this and I have not until today seen any software doing this so take away there is like if you're doing this if you're doing a TLS interception proxy then you are responsible for the security of this connection and then it matters like how good is the implementation of the TLS and how good is the implementation of the certificate validation and the question you have to ask here is are these companies who are producing this product qualified for that and my answer to that is probably not because browsers have large security teams and they are very involved in the debate about TLS in general and so they follow up what kind of state of the art and encryption and a company that's producing some strange super efficient software probably is not. And then under this blog post about the antivirus application someone asked me the TS software called Edgard that also installed some certificate and if I can look at it so I did that and then I found out okay it created a new certificate on every installation but it always used the same key so that was a bit strange but and then later I found out okay so I then contacted them and got a reply from some of the developers what they did was that they choose one out of eight keys that based on your CPU so the idea was if you reinstall it on the same system you get the same key doesn't really make any sense and so you can just extract these keys from a file that was shipped with this software and there were eight different keys and I have published them so yeah there's a GitHub repo where I've published all these keys I will post the link later. Now this Edgard depended on a software called Netfilter SDK and there was specifically a file called protocolfilters.dll where the keys were in so it was quite easy I just created a Python script that would look if something starts with the byte for which is the byte that a private key in TS starts with and then I would pass that to OpenSSL and see if it could decode it and if that was the case I could dump the key. And then this reminded me of something because this protocolfilters also bundled a very old version of NSS and I saw that before because I saw that in PrifDoc and then I found out okay PrifDoc also had this shared key issue so it was basically not only broken that it didn't validate the certificates on the other side but it also had this shared key which is also like adds an additional risk because even people who have uninstalled PrifDoc at some point may still have the certificate in the browser with the shared key. So and then I learned is there anything else that's using this protocolfilters module and I found a lot of web pages reporting about software using this most of it was what's called potentially unwanted software or crap where the stuff you have on your PC you don't really know why it came there, you don't want it how to remove it but unfortunately I didn't find any of these pieces of software for download. So the issue with that is these are usually companies who are only in business for a short time and then they stop so I found a lot of information about these software pieces but I didn't find anything for download. So if anyone has access to these things I would be very interested. Then this so recently there are also people trying to do the same thing for other protocols so this is a semantic solution that's for email encryption basically that's the thing that was PGP in the past that's now sold as semantic desktop email encryption so it tells you basically to disable TLS in your email application this is Thunderbird so if I try to if I have this installed and try to set up my email at Thunderbird it tells me to disable TLS encryption and then it will intercept that email encrypted and do a connection to my email server. Thunderbird then shows this very scary warning which is completely the right thing to do I mean you're trying to fetch your emails without encryption so it should warn the user about that. So yeah. And then I started up a sniffer and looked like how does this TLS connection look like and it only does TLS 1.0 without forward secrecy so you have a product that's trying to sell your email encryption and it uses a very outdated version of TLS and a very outdated cypher. So what kind of left as a question is that we have these enterprise appliances which I had earlier this picture from Bluecode and F5 because I don't have access to these things so I don't know how good or how bad they are but I would assume that they probably have similar issues but there's maybe some evidence so in enterprise TLS applications there were a lot of very weird bugs in the past years so probably one of the strangest things that happened in TLS is that F5 had a device that if you connected to it with a TLS handshake that was larger than 256 but smaller than 512 bytes it would not do a connection. This was a big problem when people tried to introduce new features into TLS and then the handshake got bigger and these F5 appliances wouldn't allow connections. So what happened then that now there's an extension to pad the handshake so this is I think the first time that there's an explicit TLS extension only for one bug and a certain product from a certain vendor. So then I also mentioned earlier this Poodle TLS issue so people were able basically to port a bug from an older version of the SSL version 3 bug to the newer protocol TLS and that was found in a whole range of devices like F5, A10, Cisco, Checkpoint, Unipot and these are very often these are the companies that are producing these enterprise interception devices also. And something that came up very recently is a bug called Maze where devices would not check the MAC so they wouldn't verify if the connection was, if the data was correct at all. So I would not trust these companies to intercept my TLS traffic. And then you may ask what's the alternative and I think first of all this may be the wrong question because a lot of these products I would doubt if they should exist at all. And this is quite obvious for something like Superfish. I mean it's a software that gets installed on your laptop without your consent and that's showing you some ads. I don't think there's anyone or is anyone in the audience who thinks they need more ads in the internet? I don't think so. But also for things like if you have these firewalls or antivirus applications, I want to ask the question is it a good idea to inspect the traffic with antiviruses basically don't really work anymore? I don't know if they ever worked in a reasonable way. So for many of these products I would just question is this a reasonable way to do IT security? And if you're breaking encryption then you're introducing a big risk and if you're doing that for security seems very questionable. But there are of course legit reasons why you want to modify traffic in some way but if you do that then please do it after the encryption. So what you can do of course is a browser extension. There are a lot of things that do that like HTTPS everywhere or like privacy badger or things like that. But especially this should happen with the user's consent so and then this is fine. So my takeaways are kind of I think this issue with these potentially unwanted applications or Crabware or Loadware however you want to call them is a big security threat and it's not really it's underestimated I think. So the idea that you're paying a laptop vendor to install some software on the device that nobody wants that's not a viable that's not a legitimate business model and also the idea that you're bundling a software with something else and then tricking the user into clicking OK and then you can say OK the user consented to it but these these are often made in a way that it's very easy to click on the wrong button. You may have heard that that source for now had kind of taken over a lot of free software projects and is now providing installers that are shipping some other software with it. There was recently GIMP found out that there were GIMP installers on source for that were bundling something and they didn't know about that. So this is really not something that's absolutely not acceptable. So if you want to install a software on another person's computer you need their consent I think and that yeah. And this whole TLS interception issue I think it is generally dangerous. I have not seen any software that gets it right and even a lot of security products don't get it right. So I think it's completely a misguided approach. The encryption is there for a reason it's there to protect your information and to guarantee that information gets transmitted and modified and that shouldn't be messed with. So yes as I mentioned earlier the GitHub repository where I collected all the certificates and now I assume we were faster than I expected. So we have a lot of time for discussion. Yeah thank you for this talk. I think we learned a lot and there are already at least three questions we start at the left. Hello Hi do you think it would be a good idea for all browser windows to offer an Ithon extension or an API for software windows which works that they submit all the traffic in addition to somewhere else. So like a span port on the router. So then you have a common API. Yeah so basically you want something like a browser extension but that's across all browsers. Yes because it seems to be the case that windows want to have such a functionality. That might be an idea. I haven't thought about it but might be a viable idea. Next one also from that side because there's nobody lining up. Okay thanks a lot for the great talk. What I was wondering was really related to the last question. So I think we all agree and superficial etc. But blue code I think there's like legitimate compliance need and there are companies who want that kind of SSL interception. So saying just don't do it at all I think it would be nice but don't work. So maybe we should like say like go away from it. Maybe you should have like this explicit standard to like share the TLS secrets with a trusted party. So if I have in Chrome a special field in my address bar which says hey this is monitored by your blue code appliance from your company you're working at. I think that will be better or more interesting than the approach we are going for or what you pushed for saying well that's evil practice don't do it at all. So what what you kind of want from me that I make proposals how to fix something I don't like. And I mean I think it's generally wrong. You want to have a better solution for something which I find illiterate in the first place. Yeah no I mean your your point is that you don't like it you want to get it away right. So I won't make proposals to do something better that I want to get away with. From a practical point of view it's not going to go away because there are companies who have a need. So I'm asking why don't you go for and say we should have a better standard a better way to do it rather than just ignore it at all. Because let's say you try to like ignore the issue that there's a need for it. So you can try that but I won't do that. I won't propose anything that I think shouldn't happen in the first place. Fine. Now a question from the right. Hi I'm really curious about what kind of need you have to break the LS. It's not a question for the speaker but for the guy who just went away. Yeah you come back if you like. Thank you. So I'm involved with SSL Interception a bit but doing open source work only I have no commercial interest in that. But my point of view is that the issue is if you do SSL Interception in the traditional way like doing two kinds of connections and have like explicit SSL certificate management on the proxy instance then you get these issues which we have for superfish etc. If you have a legitimate site channel where you would leak like your TLS master secret then you would get at least a very explicit way and you would still have a connection end to end but with a third party that could listen in. I think protocol wise that would be more interesting. For HTTP2 there was actually a RFC on SSL Interception Proxying which had a lot of debate. But that was only for opportunistic encryption so that was not for explicit HTTPS connections. Yeah sure. I mean blue code etc. I have a business case for that and it's not going to go away. They're still going to do it so I think you can't just push it away and that's basically the issue. What we have, that's the point. Go please go to the microphone if you want to say something. Just for the record I don't like it myself. I would be happy if it goes away but for companies there's a compliance use case why they're doing it and if you ask those compliance guys they will say well we will continue doing it and getting this away is way harder than going over to a better protocol. So you're not going to make it go away by inventing technical solutions that make it better when it stays. So the way to make it go away is to make the technology go away. You don't have the trusted side channel. You don't put that legitimate access law enforcement kind of thing into the protocol. You make a secure protocol and you implement it and people will live with it. People will deal with it. If you implement that you'll just get more intercepted connections, not fewer. I think we could one or give a five to answer this as well. And so I also want to say like my hope is that if we do more analysis on these things I expect we will find more vulnerabilities so we can have more like get these devices avers reputation. That would be my approach to it. Maybe I can again say something to this because I see the point and if we start and have a super protocol which does not allow such a thing then people or Windows will start to do as you said build a browser extension which is doing the same thing. And I think that's especially what he wants to have a common way of accessing everything. That's just the thing. Okay, we are moving forwards but either we can say hey Windows think of another way because we disabled your old way or we say hey this is a better way maybe you use this one either be constructive or not. Was this a question or? So I mean the first question I always want to ask is this product doing something legitimate at all because for a lot of these products I think the answer is no. Yes, but people pay a lot of money for this product so. Yeah. Obviously there is a market for this and they will not stop paying money for it. Now the person in red who is waiting a long time now. Yeah, it seems like I'm going to be on the side of poor interception in a way because I just like to remind people that not everyone has 40 gigabytes per second anywhere. What I work for we have really expensive boundaries with a huge latency and the current web really works badly overall. And each time we add encryption or more generally TLS and we'd like to have proxy for the users which they would opt in but in an easy way and currently with more TLS we have more problem doing it. I'd like to have a really clean solution with other than a hackish interception but so far it seems like there are people who are constable in the living room with really good internet access and they are just thinking about adding encryption but not thinking about others. I don't want to do many in the middle at all but it's a bit easy when you have a good connection to forget about others. Yeah, that's it. Yeah, I think there was no question. No question, just a command because I think we're a bit privileged here and we should think that proxies can help sometimes. So your issue is that proxies can cache things and there could be one user. So the issue with caching is that you can cache less and less anyway because content is getting more dynamic and caches have very few uses these days. So I think the increased security from TLS and also if you do things like HTTP2 where you have performance improvements through TLS are much bigger than what you can gain with caching. I'm not completely, I don't completely agree. I see a point and yeah, definitely with Web 2.0 we have less and less caching but then we have some fairly large media which could benefit a lot from caching. Okay, the next question from the right. Okay, I just wanted to add some points. How I came across this mental attacks from Antivirus software I think with VAST because they break client certificates. I think that's something that wasn't mentioned. Okay, now I didn't notice that. Thanks for this note. I looked at VAST but I didn't notice that they break client sets. Because the client certificate is obviously in the browser and the Antivirus software doesn't have or doesn't check for that. Yeah. And do you have any ideas how to prevent any interference from local processes in the TLS session given ideas? Because I also think that this is a bad practice and shouldn't be done and then common interface would just be misused by ad injection software. So I mean this only can happen if you have some access on the client. So this software must install something into your browser. So the solution is basically be careful what you install on your computer. If you install bad software on your computer then it can do bad things. I understand. But if we have a corporate environment where such an SSL injection is common and the user probably doesn't have any meaningful way to influence what is installed on the computer, that way we can do something on the browser side so it doesn't even, it's not very easy to do such things. So there's basically no way if you control, if you have a software on the client that wants to mess with your browser, there's no way to stop that. I mean that's basically the malware problem. If you have something on your client then it is in control. Yeah, good point. Thanks. Yeah, there seem to be no other question. Oh, there's one. Hi. When it comes to TLS security, why can't I pin a key to a site and why can't I look up the key fingerprint? You can pin a key to a site. So if you're the site or a P and not a certificate. So the way this key pinning standard works is that it is pinning the key to a site. And you're wearing a Firefox t-shirt. Firefox doesn't support this. Firefox supports this since two or three versions. Okay, I'll come back to you when you will. So there's this HTTP public key pinning standard. It's an RFC now. And the idea is... By the server. Yeah. Yeah, no, I'm a user. I'm either usable to pin a key to a site and I want to see it so I can check it manually. And this is not possible and I don't know why especially because I can see the fingerprint of the certificate. The problem with these, so you think about things like certificate patrol and similar plugins, right? I don't... Yeah. I think this one uses a notary service. I'm not talking about notary service. There are some usability issues with that because if the certificate changes, what do you do? You don't know if it's a ledger change or a malicious change. I have a chance to check it and I have a chance to check with my bank. I am very skeptical about any solution that requires the user to know what a certificate is because that's not widely usable. But we can discuss that later. Okay. Okay. That seems to be the last question. Yes. So, please again, a big applause for Hanno. Thank you.
 Now, this is Hanno Berg.  I think a lot of you probably already know him because he's a well-known journalist and  most of you probably have read something in a lot of magazines where he is writing something  and he will speak about TLS interception considered harmful.  So this is about HTTPS and this is not only encryption, it's also about identities and  whom we trust and who decides whom we trust and how this can be attacked.  Well, have fun.  Hello.  So TLS interception.  This is a problem that came up earlier this year when there was software called SuperFish  that got detected and that had a very severe security vulnerability.  But this also highlighted kind of an issue that a lot of software pieces are doing this  and it's a questionable way of doing things and I wanted to provide an overview about  this issue and get a bit deeper into it.  Quickly about myself, as she already said, I'm a journalist mainly writing for the German  IT news magazine Golem.  But right now I'm also doing some IT security work for the core infrastructure initiative  from the Linux Foundation and mainly I do fuzzing there.  So I'm trying to improve the software that you're running on your computers.  So I want to go a step back and talk a bit in general about TLS and the kind of discussions  we had in the past five years where we had a lot of vulnerabilities.  You probably heard about some of them.  We had HeartLate which had most attention but also we had things like Beast, Crime,  Sparky13, Poodle.  So we got a lot of attention about the security of TLS and CryptoConnections and there are  also some things to learn from that.  One example was the so-called Beast vulnerability.  When the Beast vulnerability was presented it was already a known issue that older versions  of TLS had some issue with the CBC mode which is the encryption mode for the symmetric encryption.  So there was already a fix available but back then most people still used the old TLS 1.0  version and still today a lot of web pages only support TLS 1.0 and yeah.  So the fix is one possible fix is to use a newer TLS version that doesn't have this issue  and there's also a workaround where you can, if you do a certain kind of splitting of your  data packets then this vulnerability doesn't happen.  Then there was an issue called Crime which was that due to compression in TLS that would  leak information about the data inside and the relatively trivial solution is don't use  TLS compression.  It gets a bit tricky because HTTP also has compression and it has similar issues and  it's a bit harder to fix it there.  So what's also interesting here is again we have an issue that's part of the protocol  so it's not that there's a bug in the software but it's the TLS protocol itself that had  a security issue.  And then we had Lucky 13 which was an issue with the way that TLS combines the MAC and  the padding and the encryption and in which order it does it.  So generally today we consider it the only safe way to combine the different things is  to first encrypt and then do a MAC.  So the MAC is there to guarantee that the package has not been manipulated.  And there was a timing side channel so by checking whether what kind of error occurred  on a connection an attacker could find out something about the key.  And so the workaround about is do everything timing safe but this is very hard.  And the solution would be not to use these encryption modes anymore that have this weakness.  And there's currently only one encryption algorithm in TLS specified that doesn't have  this weakness which is AES in the GCM mode.  And there's also RC4 but that has other weaknesses so we don't want to use that as well.  And then there was Poodle which was a vulnerability in the very old SSL version 3 which kind of  was okay it shouldn't be a problem because it's so old nobody should be using it but  a lot of people were still using it and there was also a downgrade attack you could do.  But then there was something interesting that there were some devices that actually had  the same vulnerability in also in TLS because the issue was that in the old SSL version  3 there was a padding and it was not defined what's inside this padding.  So you could have arbitrary values in that and that somehow could be used for an attack.  So TLS defined that this padding must be a specific value but some implementations didn't  check that so they managed kind of to port the vulnerability from the old protocol by  doing a bad implementation to the new protocol.  So and then we had some debate about something called forward secrecy that's a feature of  encryption technologies where you generate a key for each connection.  And the idea there is that you destroy that key after the connection and then if your  private key later gets stolen it doesn't have such a high impact because the connections  from the past still cannot be decrypted.  And now there are modes in TLS that have forward secrecies and others don't but there's really  no good reason not to use forward secrecy and it's now also agreed upon that the future  version TLS 1.3 will only have forward secrecy modes and the modes without forward secrecy  will be removed.  So that's kind of the debate we had on TLS in the past years.  There were some more vulnerabilities but some of the lessons to learn here is that we have  security bugs in the protocol which means that even if you implement the protocol as  it's written in the standard you may have security vulnerabilities.  So you need to know about all these workarounds and what to disable to have a safe version  of TLS today.  And only the very latest TLS 1.2 with the GCM mode and with forward secrecy is really  considered up to date crypto and considered safe these days.  But you still need to support more or less TLS 1.0 because there are still so many servers  in the internet that if you would disable that you couldn't serve a lot of web pages.  But that's kind of tricky because you have these timing issues and these record splitting  issues so if you want to do that safe it's quite complicated.  And then we have this problem with certificate authorities.  So as you probably know if you want to have an HGPS web page you need to get a certificate  and there are hundreds of these certificate authorities and all these certificate authorities  can have sub certificate authorities so we don't even really know how many there are.  And the old system was that basically every CA could issue a certificate for every domain.  So this has the impact that the whole system is only as secure as the worst of all CA's.  So if one gets breached everyone has a problem.  And this also has the impact that it doesn't really matter which CA you choose.  So if you say I go to a CA that's especially trustworthy for whatever reason that doesn't  really make any sense.  And yeah so and this also had practical implications.  We had a lot of cases in the past years where certificate authorities issued certificates  like for Googlecom but not to Google but to someone else.  There was many issues with Komodo.  There was Turk trust.  There was CNNIC the Chinese government controlled CA with India CCA.  There was Digi Notar which later went bankrupt.  ANSI which is a French government controlled CA.  So for quite different reasons so some of them were hacked.  Some of them like there was an issue where this Chinese CA sold a sub certificate to  an Egyptian company that then used it to intercept traffic in their own network.  But all of them so we had a lot of issues where these CA's didn't follow the rules and  issued certificates to people who shouldn't get those certificates.  And over the years there have been many debates about how we could fix this.  And so there was an idea called sovereign keys which was interesting but quite complicated.  There was a talk on the Congress a few years ago.  There was TAC which was a kind of key pinning proposal.  There was convergence which the idea was to check a certificate from different points  in the network.  And Dain which is based on DNSSEC but all of these solutions have in common that none  of them ever got really deployed widely.  But recently there's now a standard called HTTP public key pinning which I like a lot  and the idea there is that a web page can say okay this is the key of my certificate  and here's a backup key and the browser should store this key and the backup key and in the  future only these keys are accepted for this web page.  So we have kind of additionally to the certificate authorities we have a trust on first use system  that not every CA can issue a certificate for this web page that can later be used for  a text.  And also the browsers these days contain some pre-pinned certificates so for example if  you create a bad certificate for Google com it will not really work at least in Chrome  and Firefox because the browser already knows that Google only gets certificates from Google's  own certificate authority so you cannot use a random certificate authority to issue a  certificate for Google.  The problem with that is a bit that it's not widely used.  So there was recently a statistics in the about the Alexa top one million web pages  and only one of them was using this key pinning header and at some point there were four pages  and now it got down to one so it's really not widely deployed which is unfortunate because  this is really a very big improvement of the security of the TLS system.  And then there's a concept that's mostly developed by Google which is called certificate transparency  and the idea here is that we have a public log that's append only so it works a bit like  Bitcoin that can be verified by anyone who wants to and that has all certificates in  it and the idea is to have several of these certificate transparency logs.  So that's a very promising idea so it doesn't prevent attacks with wrong certificates but  it pretty much makes sure that you cannot hide these attacks.  So there's a very high likelihood that if you have certificate transparency in place  that all attacks will be detected at some point.  And it's not really widely deployed but Chrome has some preliminary support and Google plans  to require it from at least for the so-called extended validation certificates and later  for all certificates.  So there are some things happening in this space to mitigate these problems with certificate  authorities.  So finally after many, many years where we had this problem we have now some mitigations  that are coming but also the conclusion there is that if you want to verify TLS certificates  you need to know about these things and your implementation needs to know about it and  you have to stay on top of the development what's going on in TLS security.  And some late development is that a lot of people are pushing now for HTTP as everywhere.  Google did a lot in this case and also Mozilla now plans to mark HTTP pages as insecure generally  then certificates are no longer expensive things so there are no certificate authorities  that give you a certificate for free.  There are two now and let's encrypt will start pretty soon which we will have a talk later  today also.  And I think this is generally a very good thing and I also think this is a good thing  even if you don't have any secret data on a web page because what many people tend to  forget is HTTP.  HTTPS guarantees that your data is transmitted encrypted but also that it has integrity so  that means that the page the user sees is really the page that came from the server  and it was not manipulated on the way.  So even if your data is not secret you always want your data to be correct.  But there are also people who think that this is a very dangerous development like here's  a picture I made on the Black Hat conference recently where a company called Blue Code  you may have heard of them they have some questionable approach to security researchers  that they say TLS traffic is pervasive and introduces risk especially it can also be  used for advanced persistent threats so if anything is APT that's really dangerous.  And obviously they sell your solution for that so they have a way to inspect your TLS  traffic.  And many other companies do as well this is from F5 and this is I don't know which company  this is I'll sell you some products that allow you to kind of inspect your encrypted traffic.  So there are a lot of products that are doing this like we have these enterprise security  solutions like what Blue Code and F5 is selling we have now antivirus software that's doing  this we have parental control or youth protection we have some ad blockers or a lot of ad  injection software which is usually the stuff that you don't want but may have installed  anyway on your computer.  So how do they do this?  So the idea here is that so you cannot inspect or manipulate the traffic if there's HTTPS  because it's the idea of HTTPS to prevent that.  So the solution these products have is that they install their own certificate authority  root certificate into the browser and then basically what they do is a man in the middle  attack on your browsing.  And then earlier this year there was a software called Superfish that some people found on  their Lenovo laptops it came pre-installed on Lenovo laptops.  What this software did was that when you were surfing the internet it analyzed the images  and tried to find objects on these images and then it would present you some ads that  were related to these images.  So I don't know you could surf a web page about camping and then it would give you an  ad about where you can buy a tent.  So what this also highlights is that there's now this kind of very strange market that  there are companies who are producing software that nobody really wants but they are paying  companies like Lenovo that they install it on their laptops.  And what also happens is this software bundling where someone you install some software and  then the installer asks you with some very tricky UI thing that do you also want this  toolbar or this whatever and then if you click the wrong button you have something installed  that you never wanted.  But the problem with this Superfish software was that it used such a man in the middle  proxy and it had the same certificate on all installations.  And so also it had the same private key on all installations and the key is naturally  part of the software.  So you could just extract this key and two days later someone did this so the key was  public and with this key you could basically attack everyone who is using a laptop that  had this Superfish software installed.  So yeah.  It was a big PR disaster for Lenovo.  They later said okay we're sorry they provided a removal tool.  They then said okay we've learned from it we will be more careful in the future.  A few days ago if you've seen this Lenovo is now using BIOS root kits to install some  crap on your Windows system I don't know if they have really learned anything.  But then it became even more interesting than people found out okay the Superfish was using  a software module from a company called Komodia and this was used in many different applications  and all had the same problem all had this shared key problem and people were extracting  keys from many different products.  So there was a product called StuffCop and Custodio which was some parental control thing  and some VPN software and then at Adware it's an anti-Adware tool and there was also a lot  of Adware like this stuff that gets installed on your system you don't really want whatever.  So it turned out this problem was much bigger than the Superfish issue that there was a  lot of software that all had the same vulnerability.  And then Philippo Valzada who is a Cloudflare engineer he found out that there was a trick  how you could create certificates that all of these Komodia products would accept.  So first we thought okay you have a key for every of these products but then there was  kind of this trick because what happened was if the software would connect to a web page  with an invalid certificate it would replace it with a certificate that was signed by this  man in the middle proxy but that had an invalid host name.  But what this software didn't consider was that certificates also have this field subject  alternative name where you can add additional host names for a certificate and these were  kept intact so you could create a certificate that was signed by any CA or by your own self  signed CA and then add the host name for the web page you want to attack in this subject  alternative name field and then every software that had this Komodia module would accept  this certificate.  And then I found this kind of ridiculous then Lavasoft which is producing this ad adware  software they said on their Facebook page Lavasoft's most recent release of ad adware  web companion does not include this capability so this Komodia SSL interception but we are  not yet able to confirm with certainty that the compromised component of the Komodia SSL  digester has been removed.  So there you have a company that's producing a security product and they say okay we had  a severe security vulnerability and we don't know if we have really fixed it and that's  kind of a bit ridiculous and it took me like 15 minutes to verify okay they were still vulnerable  I commented it on their Facebook blog post maybe it helped them I don't know.  And then a few days later there was some ISE channel where people who were interested  in this issue were chatting and then someone posted a link that okay there was someone  asking he has a software called Priftock on his system and he wanted to know if this is  something like Superfish and it turned out this was a software that was developed by  a company founded by the CEO of Komodo and what this software would do was it would identify  ads that it considers as dangerous it wasn't really clear why what criteria or that would  impact your privacy it would replace them with its own ads so thereby they make money  because they replace some ads with their own.  And then I looked at it and found out okay it does not use a Shirt certificate so it's  not like Superfish but what it did is it just accepted on the other end every web page certificate  so you could have a random invalid certificate and the software would connect to it and replace  it with its own certificate that was valid for the browser because it had its root certificate  installed and then also I looked at the traffic of the software and it was sending every URL  you were surfing to in clear text to some server from this company and then yeah I wrote a  blog post about this it was pretty late in the evening and then I went to sleep and the  next day BBC called me so this really generated a lot of interest in the media because the  issue here was really Komodo because Komodo is a company that's selling TLS certificates  that's the biggest certificate authority these days and so the same company that's selling  you the certificates for HTTPS security is related to a product that's breaking the security  so it was not a Komodo product but they had some close ties so Komodo was advertising  this product and also Komodo had a browser that was bundled with this PrifTalk but this  version in the Komodo browser was not affected by this vulnerability because that worked  as a browser plugin and not as a man in the middle proxy but yeah so yeah we had another  issue where this TLS interception proxy caused a severe security vulnerability and then I  looked at some other products that would intercept TLS traffic and there are some antivirus applications  and I looked especially at Avira, Kaspersky and Asset because these were the ones that  were freely available and I could easily test and none of them had a severe vulnerability  like SuperFish or PrifTalk but all of them had something that made the TLS connection  worse so the biggest issue was that Kaspersky was then still vulnerable to the freak vulnerability  so freak was a vulnerability where you could downgrade connections to some export mode  from the back in the 90s when it was forbidden to have strong crypto and it was found that  somehow you can trick open SSL into doing these old connections and very shortly some  days after this freak vulnerability was published someone posted in Kaspersky's forum that  okay you have this problem with the freak vulnerability and it was ignored for more  than a month so I re-found this issue in Kaspersky and then I earlier told you about  this key pinning standard we have now so you might think okay if we have this key pinning  then this whole TLS interception proxy shouldn't really work because if the browser has a Google  certificate pinned and then it gets replaced from some TLS interception that shouldn't  really work but the problem there is that the browsers had to do some kind of compromise  because there is already so much software that does this TLS interception that they  couldn't break all of it so what they did is they said okay if there is a manually installed  root certificate in the browser then it would ignore that key pinning header so it's not  really nice but you can kind of understand why the browsers did this.  Now what should happen if you do it right then these products should test this header  themselves on the back end side but none of the software that I looked at did this and  I have not until today seen any software doing this so take away there is like if you're  doing this if you're doing a TLS interception proxy then you are responsible for the security  of this connection and then it matters like how good is the implementation of the TLS  and how good is the implementation of the certificate validation and the question you  have to ask here is are these companies who are producing this product qualified for that  and my answer to that is probably not because browsers have large security teams and they  are very involved in the debate about TLS in general and so they follow up what kind  of state of the art and encryption and a company that's producing some strange super  efficient software probably is not.  And then under this blog post about the antivirus application someone asked me the TS software  called Edgard that also installed some certificate and if I can look at it so I did that and  then I found out okay it created a new certificate on every installation but it always used the  same key so that was a bit strange but and then later I found out okay so I then contacted  them and got a reply from some of the developers what they did was that they choose one out  of eight keys that based on your CPU so the idea was if you reinstall it on the same system  you get the same key doesn't really make any sense and so you can just extract these keys  from a file that was shipped with this software and there were eight different keys and I have  published them so yeah there's a GitHub repo where I've published all these keys I will  post the link later.  Now this Edgard depended on a software called Netfilter SDK and there was specifically a  file called protocolfilters.dll where the keys were in so it was quite easy I just created  a Python script that would look if something starts with the byte for which is the byte  that a private key in TS starts with and then I would pass that to OpenSSL and see if it  could decode it and if that was the case I could dump the key.  And then this reminded me of something because this protocolfilters also bundled a very old  version of NSS and I saw that before because I saw that in PrifDoc and then I found out  okay PrifDoc also had this shared key issue so it was basically not only broken that it  didn't validate the certificates on the other side but it also had this shared key which  is also like adds an additional risk because even people who have uninstalled PrifDoc at  some point may still have the certificate in the browser with the shared key.  So and then I learned is there anything else that's using this protocolfilters module and  I found a lot of web pages reporting about software using this most of it was what's  called potentially unwanted software or crap where the stuff you have on your PC you don't  really know why it came there, you don't want it how to remove it but unfortunately I didn't  find any of these pieces of software for download.  So the issue with that is these are usually companies who are only in business for a short  time and then they stop so I found a lot of information about these software pieces but  I didn't find anything for download.  So if anyone has access to these things I would be very interested.  Then this so recently there are also people trying to do the same thing for other protocols  so this is a semantic solution that's for email encryption basically that's the thing  that was PGP in the past that's now sold as semantic desktop email encryption so it tells  you basically to disable TLS in your email application this is Thunderbird so if I try  to if I have this installed and try to set up my email at Thunderbird it tells me to  disable TLS encryption and then it will intercept that email encrypted and do a connection to  my email server.  Thunderbird then shows this very scary warning which is completely the right thing to do  I mean you're trying to fetch your emails without encryption so it should warn the user  about that.  So yeah.  And then I started up a sniffer and looked like how does this TLS connection look like  and it only does TLS 1.0 without forward secrecy so you have a product that's trying to sell  your email encryption and it uses a very outdated version of TLS and a very outdated  cypher.  So what kind of left as a question is that we have these enterprise appliances which  I had earlier this picture from Bluecode and F5 because I don't have access to these things  so I don't know how good or how bad they are but I would assume that they probably have  similar issues but there's maybe some evidence so in enterprise TLS applications there were  a lot of very weird bugs in the past years so probably one of the strangest things that  happened in TLS is that F5 had a device that if you connected to it with a TLS handshake  that was larger than 256 but smaller than 512 bytes it would not do a connection.  This was a big problem when people tried to introduce new features into TLS and then the  handshake got bigger and these F5 appliances wouldn't allow connections.  So what happened then that now there's an extension to pad the handshake so this is  I think the first time that there's an explicit TLS extension only for one bug and a certain  product from a certain vendor.  So then I also mentioned earlier this Poodle TLS issue so people were able basically to  port a bug from an older version of the SSL version 3 bug to the newer protocol TLS and  that was found in a whole range of devices like F5, A10, Cisco, Checkpoint, Unipot and  these are very often these are the companies that are producing these enterprise interception  devices also.  And something that came up very recently is a bug called Maze where devices would not  check the MAC so they wouldn't verify if the connection was, if the data was correct at  all.  So I would not trust these companies to intercept my TLS traffic.  And then you may ask what's the alternative and I think first of all this may be the wrong  question because a lot of these products I would doubt if they should exist at all.  And this is quite obvious for something like Superfish.  I mean it's a software that gets installed on your laptop without your consent and that's  showing you some ads.  I don't think there's anyone or is anyone in the audience who thinks they need more  ads in the internet?  I don't think so.  But also for things like if you have these firewalls or antivirus applications, I want  to ask the question is it a good idea to inspect the traffic with antiviruses basically don't  really work anymore?  I don't know if they ever worked in a reasonable way.  So for many of these products I would just question is this a reasonable way to do IT  security?  And if you're breaking encryption then you're introducing a big risk and if you're doing  that for security seems very questionable.  But there are of course legit reasons why you want to modify traffic in some way but  if you do that then please do it after the encryption.  So what you can do of course is a browser extension.  There are a lot of things that do that like HTTPS everywhere or like privacy badger or  things like that.  But especially this should happen with the user's consent so and then this is fine.  So my takeaways are kind of I think this issue with these potentially unwanted applications  or Crabware or Loadware however you want to call them is a big security threat and it's  not really it's underestimated I think.  So the idea that you're paying a laptop vendor to install some software on the device that  nobody wants that's not a viable that's not a legitimate business model and also the idea  that you're bundling a software with something else and then tricking the user into clicking  OK and then you can say OK the user consented to it but these these are often made in a  way that it's very easy to click on the wrong button.  You may have heard that that source for now had kind of taken over a lot of free software  projects and is now providing installers that are shipping some other software with it.  There was recently GIMP found out that there were GIMP installers on source for that were  bundling something and they didn't know about that.  So this is really not something that's absolutely not acceptable.  So if you want to install a software on another person's computer you need their consent I  think and that yeah.  And this whole TLS interception issue I think it is generally dangerous.  I have not seen any software that gets it right and even a lot of security products don't  get it right.  So I think it's completely a misguided approach.  The encryption is there for a reason it's there to protect your information and to guarantee  that information gets transmitted and modified and that shouldn't be messed with.  So yes as I mentioned earlier the GitHub repository where I collected all the certificates  and now I assume we were faster than I expected.  So we have a lot of time for discussion.  Yeah thank you for this talk.  I think we learned a lot and there are already at least three questions we start at the left.  Hello Hi do you think it would be a good idea for all browser  windows to offer an Ithon extension or an API for software windows which works that  they submit all the traffic in addition to somewhere else.  So like a span port on the router.  So then you have a common API.  Yeah so basically you want something like a browser extension but that's across all  browsers.  Yes because it seems to be the case that windows want to have such a functionality.  That might be an idea.  I haven't thought about it but might be a viable idea.  Next one also from that side because there's nobody lining up.  Okay thanks a lot for the great talk.  What I was wondering was really related to the last question.  So I think we all agree and superficial etc.  But blue code I think there's like legitimate compliance need and there are companies who  want that kind of SSL interception.  So saying just don't do it at all I think it would be nice but don't work.  So maybe we should like say like go away from it.  Maybe you should have like this explicit standard to like share the TLS secrets with  a trusted party.  So if I have in Chrome a special field in my address bar which says hey this is monitored  by your blue code appliance from your company you're working at.  I think that will be better or more interesting than the approach we are going for or what  you pushed for saying well that's evil practice don't do it at all.  So what what you kind of want from me that I make proposals how to fix something I don't  like.  And I mean I think it's generally wrong.  You want to have a better solution for something which I find illiterate in the first place.  Yeah no I mean your your point is that you don't like it you want to get it away right.  So I won't make proposals to do something better that I want to get away with.  From a practical point of view it's not going to go away because there are companies who  have a need.  So I'm asking why don't you go for and say we should have a better standard a better  way to do it rather than just ignore it at all.  Because let's say you try to like ignore the issue that there's a need for it.  So you can try that but I won't do that.  I won't propose anything that I think shouldn't happen in the first place.  Fine.  Now a question from the right.  Hi I'm really curious about what kind of need you have to break the LS.  It's not a question for the speaker but for the guy who just went away.  Yeah you come back if you like.  Thank you.  So I'm involved with SSL Interception a bit but doing open source work only I have no  commercial interest in that.  But my point of view is that the issue is if you do SSL Interception in the traditional  way like doing two kinds of connections and have like explicit SSL certificate management  on the proxy instance then you get these issues which we have for superfish etc.  If you have a legitimate site channel where you would leak like your TLS master secret  then you would get at least a very explicit way and you would still have a connection  end to end but with a third party that could listen in.  I think protocol wise that would be more interesting.  For HTTP2 there was actually a RFC on SSL Interception Proxying which had a lot of debate.  But that was only for opportunistic encryption so that was not for explicit HTTPS connections.  Yeah sure.  I mean blue code etc.  I have a business case for that and it's not going to go away.  They're still going to do it so I think you can't just push it away and that's basically  the issue.  What we have, that's the point.  Go please go to the microphone if you want to say something.  Just for the record I don't like it myself.  I would be happy if it goes away but for companies there's a compliance use case why they're  doing it and if you ask those compliance guys they will say well we will continue doing  it and getting this away is way harder than going over to a better protocol.  So you're not going to make it go away by inventing technical solutions that make it  better when it stays.  So the way to make it go away is to make the technology go away.  You don't have the trusted side channel.  You don't put that legitimate access law enforcement kind of thing into the protocol.  You make a secure protocol and you implement it and people will live with it.  People will deal with it.  If you implement that you'll just get more intercepted connections, not fewer.  I think we could one or give a five to answer this as well.  And so I also want to say like my hope is that if we do more analysis on these things  I expect we will find more vulnerabilities so we can have more like get these devices  avers reputation.  That would be my approach to it.  Maybe I can again say something to this because I see the point and if we start and have a  super protocol which does not allow such a thing then people or Windows will start to  do as you said build a browser extension which is doing the same thing.  And I think that's especially what he wants to have a common way of accessing everything.  That's just the thing.  Okay, we are moving forwards but either we can say hey Windows think of another way because  we disabled your old way or we say hey this is a better way maybe you use this one either  be constructive or not.  Was this a question or?  So I mean the first question I always want to ask is this product doing something legitimate  at all because for a lot of these products I think the answer is no.  Yes, but people pay a lot of money for this product so.  Yeah.  Obviously there is a market for this and they will not stop paying money for it.  Now the person in red who is waiting a long time now.  Yeah, it seems like I'm going to be on the side of poor interception in a way because  I just like to remind people that not everyone has 40 gigabytes per second anywhere.  What I work for we have really expensive boundaries with a huge latency and the current web really  works badly overall.  And each time we add encryption or more generally TLS and we'd like to have proxy for the users  which they would opt in but in an easy way and currently with more TLS we have more  problem doing it.  I'd like to have a really clean solution with other than a hackish interception but so far  it seems like there are people who are constable in the living room with really good internet  access and they are just thinking about adding encryption but not thinking about others.  I don't want to do many in the middle at all but it's a bit easy when you have a good  connection to forget about others.  Yeah, that's it.  Yeah, I think there was no question.  No question, just a command because I think we're a bit privileged here and we should  think that proxies can help sometimes.  So your issue is that proxies can cache things and there could be one user.  So the issue with caching is that you can cache less and less anyway because content  is getting more dynamic and caches have very few uses these days.  So I think the increased security from TLS and also if you do things like HTTP2 where  you have performance improvements through TLS are much bigger than what you can gain  with caching.  I'm not completely, I don't completely agree.  I see a point and yeah, definitely with Web 2.0 we have less and less caching but then  we have some fairly large media which could benefit a lot from caching.  Okay, the next question from the right.  Okay, I just wanted to add some points.  How I came across this mental attacks from Antivirus software I think with VAST because  they break client certificates.  I think that's something that wasn't mentioned.  Okay, now I didn't notice that.  Thanks for this note.  I looked at VAST but I didn't notice that they break client sets.  Because the client certificate is obviously in the browser and the Antivirus software  doesn't have or doesn't check for that.  Yeah.  And do you have any ideas how to prevent any interference from local processes in the TLS  session given ideas?  Because I also think that this is a bad practice and shouldn't be done and then common interface  would just be misused by ad injection software.  So I mean this only can happen if you have some access on the client.  So this software must install something into your browser.  So the solution is basically be careful what you install on your computer.  If you install bad software on your computer then it can do bad things.  I understand.  But if we have a corporate environment where such an SSL injection is common and the user  probably doesn't have any meaningful way to influence what is installed on the computer,  that way we can do something on the browser side so it doesn't even, it's not very easy  to do such things.  So there's basically no way if you control, if you have a software on the client that  wants to mess with your browser, there's no way to stop that.  I mean that's basically the malware problem.  If you have something on your client then it is in control.  Yeah, good point.  Thanks.  Yeah, there seem to be no other question.  Oh, there's one.  Hi.  When it comes to TLS security, why can't I pin a key to a site and why can't I look  up the key fingerprint?  You can pin a key to a site.  So if you're the site or a P and not a certificate.  So the way this key pinning standard works is that it is pinning the key to a site.  And you're wearing a Firefox t-shirt.  Firefox doesn't support this.  Firefox supports this since two or three versions.  Okay, I'll come back to you when you will.  So there's this HTTP public key pinning standard.  It's an RFC now.  And the idea is...  By the server.  Yeah.  Yeah, no, I'm a user.  I'm either usable to pin a key to a site and I want to see it so I can check it manually.  And this is not possible and I don't know why especially because I can see the fingerprint  of the certificate.  The problem with these, so you think about things like certificate patrol and similar  plugins, right?  I don't...  Yeah.  I think this one uses a notary service.  I'm not talking about notary service.  There are some usability issues with that because if the certificate changes, what do  you do?  You don't know if it's a ledger change or a malicious change.  I have a chance to check it and I have a chance to check with my bank.  I am very skeptical about any solution that requires the user to know what a certificate  is because that's not widely usable.  But we can discuss that later.  Okay.  Okay.  That seems to be the last question.  Yes.  So, please again, a big applause for Hanno.  Thank you.
hanno__TLS_interception_considered_harmful_2VV50g1w-TU_0_47.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_48_347.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_348_611.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_612_695.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_696_1211.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_1212_1367.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_1368_1439.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_1440_1871.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_1872_2255.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_2256_4691.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_4692_5147.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_5148_5507.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_5508_6011.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_6012_6059.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_6060_9047.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_9048_9839.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_9840_9947.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_9948_10583.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_10584_13355.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_13356_14543.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_14544_16727.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_16728_17267.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_17268_18047.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_18048_19667.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_19668_21791.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_21792_22511.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_22512_22595.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_22596_22703.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_22704_22751.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_22752_23087.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_23088_23135.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_23136_23375.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_23376_24143.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_24144_24719.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_24720_24935.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_24936_28367.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_28368_30575.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_30576_31475.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_31476_32867.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_32868_36563.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_36564_41243.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_41244_44003.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_44004_44195.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_44196_44291.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_44292_44735.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_44736_46919.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_46920_55283.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_55284_56519.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_56520_56711.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_56712_57035.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_57036_57671.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_57672_58319.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_58320_58547.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_58548_61103.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_61104_61295.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_61296_63971.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_63972_64283.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_64284_65471.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_65472_65771.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_65772_71591.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_71592_71891.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_71892_72251.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_72252_73331.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_73332_74543.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_74544_74615.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_74616_74915.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_74916_75851.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_75852_76475.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_76476_76523.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_76524_77543.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_77544_77867.png hanno__TLS_interception_considered_harmful_2VV50g1w-TU_77868_78213.png