 Thank you Right, so this is also part of the work that happened for the privacy goal And yeah, we are going to look at how to talk to network services in a secure fashion And the subtitle was kind of spoiled by by Ivan already. We'll see it's not All that easy unfortunately Why we are doing this, I think this is pretty clear, right? most of you in the in the last one or two days have been connected to an open Wi-Fi somehow and That usually means everybody else can just listen in on what you are communicating unless of course the connection is encrypted and I guess many of you also got in in contact with captive portals For example in the hotel So that's something where the server or the captive portal pretends to be Whoever you actually want to talk to and if your application doesn't verify that it's actually talking to the server It wants to talk to it might just happily send out authentication details passwords Session tokens, whatever to that captive portal So this isn't some esoteric corner case if you are a public enemy Punted down by the NSA. This is really something that happens Pretty much at any hotel airport public Wi-Fi Whatever you get in in contact with The usual technology to do that is TLS and transport layer security Formerly SSL, so it's more or less the same thing just Yeah, there's some some issues fixed most often you get in touch with that in HTTP URLs or HTTPS URLs, so the S makes the difference and it Connects in an encrypted and authenticated fashion And as Ingle rightfully mentioned this isn't limited to HTTP even HTTP is the most common one several other protocols like the whole email set They basically use the same technology just on On the socket level So most of what we are going to see here also applies to that So Yeah, in theory that should be it right You use an HTTPS URL and you're fine and you enable it TLS on your socket for non-http and you should be fine well Now the even stuff kicks in right unfortunately, it's not that easy The first and probably A bit surprising thing is we tend to forget to actually do this Maybe not on like the primary feature of your application So if you're writing a chat client or an email client You tend to pay attention that that communication is is probably encrypted or secured rate But that is usually not the only thing that can communicate with some network service in your application There are simple things like links to websites license informations or Further information in your documentation If you put an HTTP URL there you click on it right Connection is is not encrypted Might not be as severe as leaking your emails, but It's also those small things that count we also found that in Download URLs for external content chain new stuff and Some some block content in aggregator for example in the default installation Where this is already a bit more severe And we found it in in places for For content sharing so we're actually leaking out data So this is stuff like paste bin integration or image bin integration for sharing data as part of For example in email application Now how do we address this? It's unfortunately much harder as search and replace for HTTP and replace that with HTTPS Because XML files tend to use HTTP URIs as identifiers Rather than as addresses that get resolved So you find that for example SVG files if we do a do a global search and replace right We break all those files by trying to fix the network addresses. So it's not that easy During the privacy sprint Sundra and I worked on a script that does this properly And as a still pending review on fabricator that tries to inject that as a global unit test for all ECM users That's a bit of a hack, but that seemed to be the The best way we found to make this as widely rolled out as as possible And even if you don't do that, there's these scripts that you can run over your code base That checks for for URLs and optionally also replaces them On top of that there is So this is basically the static approach static code analysis and on top of that there is Various tools that allow you to look at your runtime traffic But with that it's usually much harder to capture the rare secondary use cases, right? So this works nicely for the primary communication of your application Capturing a click on a specific link in your documentation in a wire shark That doesn't really work so but yeah, let's Let's assume we are talking to a good server that actually redirects us to To an HTTPS URL Many servers nowadays do that But is that enough? So first of all, are we actually following that redirect? We will see later on when we look at the the tools we actually have to To do this or the libraries That is not necessarily the case and then there's the case do we follow redirects in the wrong direction, so if Somebody tricks this trick or injects a redirect from a secure site to an insecure site That's usually not something we would want to follow and we'll see in a few cases we follow that as well, so That's something to take care of and then there is an extension strict transport security for HTTP that allows the The server basically to tell us For the next half year you can expect me to offer an encrypted site And if you get an unencrypted link always upgrade to encrypt it So that requires to keep some some state locally and it's it's an again another building block that prevents these Either downgrade the tax or the capture portals Confusing this To see if we are actually doing this or to what extent we are doing this Let's have a look at the two major libraries or components we have to to actually do HTTP communication and that's Q network access manager Coming from Q network and KL So network access manager We directs are off by default. That's Ben's favorite feature in there And you explicitly need to enable that and you have several policies you can pick from and the only one that actually Does what you would expect it? or to Add a redirect behavior that is kind of what one would expect is the no less safe redirection policy So you explicitly need to set out on that like access manager and then you have The redirect problem fixed Strict transport security is supported but it's off by default so you need to switch this on and Persistency of the of the results you get from the server is also off by default. So you need a third call on network access manager to switch this on and then you have something that That does most things correctly When we look at how to move forward there's some Only vaguely related things coming in like cookie and cash handling So I won't go in detail in this one here, but cookie persistence is also not Not done in network access manager from a privacy point of view. That's actually a sensible default Cookie persistence is something that usually only browsers should do if at all in application code. You usually don't want that So how does KIO perform against that? So here redirects work by default But they actually work a bit too well. So KIO Happily follows a redirect to an To an insecure site as well And there is no knobs to turn this off. So You have to live with that Then strict transport security is not supported at all That's due to KIO being fairly old predating that that standard And that's part of the problem in KIO right The HTTP implementation there isn't really as actively maintained as it would probably or as it probably should be Especially as there's also newer HTTP standards coming out And in KIO we have persistence of cookies by default which as I said for applications might not be desirable Then we have another subject to look at and that is What happens if we encounter TLS errors so Some outdated or wrong Crypto format or encryption algorithm Some untrusted unknown or self-signed certificate Or like something like the capture portal messing all of this up First maybe the question how should those errors be handled And There's there's basically two approaches The one we know from the browser where the user is asked and given the opportunity to overwrite that temporarily or possibly persistently and then the other option is to just treat it as an error and I think the the recommendation would be If we are dealing with an address that the user has entered So like in the browser or like in an email application or in a chat application where I configure the server Then we need to give the user the ability to actually overwrite that because it might be my own server with a self-signed certificate. I mean that's less relevant in the days of let's encrypt but There's at least valid scenarios where the overwrite might be necessary and then there is basically internal API calls to hard-coded endpoints For those I think we should treat it as an as an hard error so because Otherwise you're behind a capture portal and your weather applet is asking you if you want to trust that other certificate You didn't even trigger a network operation like so. How am I supposed to decide this? How can we do that or how is that our handling done? You probably know that message box you get from KAO is we have an error show me the details and Ignore or ignore persistently That is infrastructure provided by KAO But it also can be used in combination with QSSL sockets or the the non-http version from Qt and Starting with the next frameworks with ease. It will also be possible for To use that together with network access manager Before that network access manager will always basically hard fail on an TLS error But with the the next release that will at least be on feature parity How can you test if your application behaves correctly in the face of such errors and That's where bad SSL.com comes in That is a large collection of Server set up this specific errors So you can have weak encryption or self-sign certificates and all that stuff which is usually very annoying to to set up manually or to intentionally trigger so it's it's actually Very helpful to run your application against that and see if it behaves correctly and I mean this is focused on HTTP Communication because I think it's done by the chromium team But you can also use that for non-http applications They will of course once they manage to set up the encryption they will fail because the protocol doesn't match But if you get to that point then you are at least sure that Your SSL error handling is correct And to show you how that looks like I want a little demo application that uses the four different Methods we have to To talk to a network endpoint By default they are basically this is running With their vanilla configuration right no option changed. How many of those think they Or how many of those Options you think will work out of the box with this very suspicious website set up there Any idea right it's it's certainly not all of them. So That's Why this network access manager That seems to work at first but actually it fails on the redirect of that website So with network manager out of the box We can't get to this suspicious website and if I try TCP socket That fails as well and I'll get to to that in a bit the default in TCP socket is SSL version 3 which is a protocol so old that open SSL Says I'm not going to touch this and The other two actually work And I can also show you how this works for the let's say the self self-signed Test so KKO will Actually give us that well-known dialogue right And network access manager by default will just fail but if I use the the same UI for that or that used to work This is for the different versions. I might have the the old framework one. So let me show it for this one So that queue KO feature is now available for for all the cute options The redirect stuff, I think we have a test for that as well So this is an HTTPS URL redirecting to HTTP and if I put this on the Correct policy we should get an error here right and KO Will Happily execute that and give us all kinds of information So None of them really is ideal and the defaults Well, you need to actually set the defaults correctly for for this to to work But with this you can at least play with the various options and and see how how they behave and what And if that's what you what you would expect Right then we have briefly Seen that in the demo if you don't have HTTP. There is QSSL socket That's the good option and we have KTCP socket Which is also I think this is from the time before there was QSSL socket. So it's a fairly legacy thing and as we saw it it defaults to an And communication protocol that even open SSL considers outdated So you explicitly need to set that to use a secure Protocol it's actually that's how the the API is called and then it it kind of works like the SSL socket And both of them you can connect to the SSL UI So you can have the manual the manual override for TLS errors if you if you need them So this is basically just what at that point so far mostly complaining about stuff not working. So how do we get it? Or how do we move forward from this and Based on the discussions We had on this with David for example One suggestion is that we add a K network access manager, which is Basically a Q network access manager with sensible defaults So ideally that thing only has three lines of codes in its constructor Because with the with the introduction of the strict transport security feature We saw that We will need to adapt to changes in network access manager And we can't rely on the defaults there Being like we want them, right? and If we are now already at three lines of Setup code for network access measure that we would need to do correctly in each application That seems to error prone and to how to maintain so on the other hand having another framework for a three line class is also not ideal, right, but At least that gives us a central point to configure this and likely there would be more in there if we look at default cache handling and an optional cookie persistence and that kind of stuff so Right or Well, do we want to wait until Qt 6? Are we assuming that within Qt 6 network access manager will aid change its defaults and will not Get to the point again where we need to change the defaults because I mean there's reasons why they didn't change the defaults, right? It changes behavior For the redirects quite drastically actually possibly with security implications, right, so I Can see the point while they Why there is the behavior in network access manager the way it is Yeah, it's of course that is I mean this is not this is not a statement on what we are going to do right this is Proposal based on discussion for options. We might want to look into So that is one of the ideas then Yeah, I vote the slides before some of the things already got fixed. So the error handling for a network access manager that is I Think it's it's integrated right so it should be in the in the next release Right and then there is the question what do we do with the legacy HTTP implementations we have and that is mainly the HTTP IO slave and the The web dev support which is also in in Kaldaf Katafin in PIM I Think it would be a good idea to rebase that on top of network access manager So we don't maintain our own HTTP implementation anymore especially in the light of HTTP as a standard actually Moving again with the innovations coming from from Google I Do network access manager is behind the the browsers there, but we are way behind in KL So I'm not sure if it's worth to to maintain that anymore, especially if it's nobody actively working on it Well, and finally It looks like there is no good reason to keep KTCP socket and that could be Basically phased out in favor of QSSL socket QSSL socket seems to have sensible defaults So that's the only one where you actually where you saw in the demo There is not a single checkbox for it apart from the I actually want the overwrite which is a sensible option to have So I think that is a transition We probably want to look into this actually only like six places or so in in LXR that use TCP socket but swapping it out for SSL socket is a Delicate task because you're touching very security relevant code That will at least be kind of my proposal on how to move forward on this and that's Hopefully something we can discuss further during the week Yeah, so I Think it's we have seen that We basically have all the building blocks But it is quite tricky to assemble them in a way that you get the optimal Behavior and It's quite easy to assemble them in a way that things either don't work or have Some problematic security wise problematic behavior I Also think there is still a lot of room in improving the tools that support us in verifying that we are doing this correctly And in a way that and the tools that allow us to find places where we are not doing this correctly And doing this correctly is of course very important confirming also what Ivan said in the morning Yeah, that's it. There is an cave six both on Monday where Changes to carry all might be on on topics. So that might be a place where we can further discuss this Thank you for our other questions That can I'm a thing shouldn't that be somehow put into Qt so that everyone could use Qt saying default network access manager That then actually could move its defaults to those who opts into saying behavior by default Yeah, I mean the The closer this is to a network access manager and therefore closer to Qt network I think the better the more people benefit from this I Think that that probably requires talking to the Qt people if we can have Like a same default option or same default rapper Somewhere in Qt and if we agree on what is saying, right? integration with the Ever handling that is you are on our side. So that certainly needs to be somewhat external But yeah, that's that's certainly an option to consider as well So I just checked Lex are for how many cases of ktcp sockets are they're not that many as you said But one of them is tcp slave base, right? So basically our all our slaves when they call socket they get a ktcp socket So that that's a bit of a multiplier, right? That just codes as one, but I guess there's various slaves on top of that one that yeah Yeah, I look like expected to be at ktcp socket. I don't know what's the actual difference between tcp socket and this is the socket nowadays, but I mean it's TCP socket uses an SSL socket but wraps most of the API including all the SSL relevant API And messes with the defaults some of this bad some of this might be useful It's It's not even documented. So it doesn't even show up on any APA KDE org site. So it's a and it's a fairly extensive class, so it's very hard to assess how What subtle things will break in the board and yes, TCP slave base is one of the interesting things And I think there's the IMAP and SMTP handling they look Easy on first site, but this is like multi-threaded code with the error handling for TLS happening in a different thread and so touching all of that is It's not a simple search and replace The remaining user is conversation right But I would guess that is similar complexity as for IMAP and SMTP and so on so But this this is something that we can I think step-by-step Migrate, right? It's it's not something where we need new API in any of the the platforms At least avoid using that in new code Anything else? Okay, thank you