Tracking users with core Internet protocols
Mueller, Tobias
TLS 1.3, QUIC, and TCP belong to the most important and most often used protocols on the Internet. We will point out how these protocols can be used to track user beyond what is commonly known to be possible. We also present modifications to the protocols for preserving the user's privacy. To further reduce the page load times on the Web, we point out how the layering between DNS, TCP, and TLS is affecting the speed of connection establishment between client-server pairs. Finally, we present modifications to some of those protocols to get us a faster and more privacy-friendly Internet. The download of an average Web site causes around one hundred small transactions from several hosts. Nowadays, the available bandwidth does not present an effective limitation of the page load time anymore. Thus, the design of a faster connection establishment is a promising direction to further improve the convenience of web browsing. To this end, TLS 1.3, QUIC and TCP Fast Open reduce the delay of the connection establishment by requiring the client to store data across several connections. These mechanisms, however, can be abused to stealthily track user's independent of traditional tracking approaches like HTTP Cookies, IP addresses, and browser fingerprinting. In particular, like TLS Session Resumption, QUIC's source-address Token, QUIC's server config, and TCP Fast Open cookies expose tokens which may be used to invade the users' privacy. To investigate the real-world feasibility of these tracking mechanisms, we analysed the configuration of popular Web browsers. Our worrying results indicate that especially via QUIC and TCP Fast Open tracking periods of multiple days are practical. While these protocols lead to faster connection setups, an initial connection establishment requires still at least three round-trip times (1 DNS, 1 TCP, 1 TLS 1.3). The idea of strict layering between those protocols prevents us from achieving further performance gains. In our talk, we will present cross-layer solutions which allow to substantially reduce the number of required round-trip times to establish initial connections on the Web without affecting the core components of each protocol, respectively. To substantiate the feasibility of our presented solutions, we implemented our approach and investigated its performance properties. Please note, that this talk assumes the audience to be familiar with the basic concepts of DNS, TCP, and TLS.
 Let me say hello. I'm Toby. I'm a researcher at the University of Hamburg in the northern part of Germany. My other hat that I'm wearing is a gnome hat. So I am also active in the gnome project. And within the gnome project, I'm trying to, well, increase the privacy and security aspects of your computing. And today, I'm here, or in this slot, I'm here to present research that we've conducted in our lab in Hamburg. So good to have experts here. That's amazing. Brilliant stuff. So what was the fix? Just push the button? Or? Good. Perfect. Right, right. Probably with the right tension on the button. This is the computer stuff. Actually, I tried to push this new line of research with this, which is theological computer science, because in computing, everything is non-deterministic, and you need to sacrifice childs and have demons and everything. But that's for another talk. So as I said, I have a few hats. One is this research hat from my university. The other is my gnome hat. And today, or in this very slot, I want to talk about some research we've done in what we call core internet protocols regarding, well, tracking users' privacy aspects in these protocols. And I have to name my colleagues. I will refer to a few papers that we've written and published, so if you want to know more about several graphs or several strategies that I will present, I will have the pointers in the slides. So tracking in internet protocols in order to understand what the issue is, what the scenario is, let me ask you to briefly think about what happens if you type some address in your browser and hit Enter. And then the next few milliseconds or seconds, what happens? And now we could do that interactively as a quiz and so on, but we don't have so much time, so I'll tell you what happens. We have many round trips back and forth, and it starts with the DNS, and then eventually you have the IP address, then you open a TCP connection, and then you send your TLS request because we want to push encrypted communication forward. And eventually, here down below, you have your payload. This is what you actually want to send to the other party. The stuff before is the overhead involved in well, connecting to that web server in this case. Arguably bandwidth is not so much of an issue these days. I mean, of course, well, you could always want more, and you're never satisfied with the amount of bandwidth you have, but arguably latency is much more important these days than bandwidth. And let's just make that an assumption, right? If an academic doesn't have anything, any data to back things up, we just assume that it's the case. And we just assume that latency is an issue. So people want to reduce the number of round trips here, the number of times back and forth. And well, thinking that this, well, makes the application more snappy and uses more happy when they have snappy websites. And in fact, there was a, I think it was the motivation, like the paper that introduced them quick, when Google introduced quick, I think they conducted research on their YouTube platform. And I remember something like Google claiming having, and now I make a number of, 30% more revenue when they have clients connecting via quick, because then people are less likely to just prematurely abort the connection and not watch the video and the advertisement. So maybe it's not 30%, maybe it's 13. But even then, saving one or two round trips does have an impact on, well, people like Google or entities like Google when they terminate loads of connections, and well, saving a few round trips is good. Anyway, so this is the standard connection establishment as of today. And what do people do to reduce the number of round trips? People do things like this. So there's a few mechanisms. One is TCP fast open. There's a TLS session resumption, which you may be more familiar with. And then there's quick, which will be the new, or will be the base for the HTTP 3 protocol. So these are mechanisms to reduce the round trips. And we had a look at the privacy properties in these protocols, because maybe, sure Google is interested in making your connection faster, giving you a more pleasant experience while browsing the videos. But maybe, just maybe, it's a hidden tracking mechanism that nobody thought of, and it's the grand evil plan, and now everything comes together, and then they know everything. So we had a look. But before discussing these in more detail, let's have a look at those. This is quick. And we don't really need to understand each and every line item there. What we will see is that there's a connection establishment made by the client. And then at the end of the day, we get some token from the server, which we can then, in our subsequent request, use here. So this is the initial connection establishment. This is the resumption when you come back later. Then you save one round trip, and you do that, because you share states with the server. You have established this state, which is encoded in this cookie or token, whatever you want to call it. And eventually, you send it back so that the server will know who you were or who you are and can then link your state. So this is some, and it's a very brief overview of a quick, right? It's of course, there's many more aspects to this, but this is the core aspect that we were interested in. TCP fast open works similarly. It's in TCP. You know there's this screen by handshake, right? We send our SYN, and then we get the response back, and then we again send the ACK. And modern like systems, they only push the payload with this third packet there with the ACK. There's, interestingly enough, there's nothing in the, there's nothing preventing you from already sending your payload in the initial SYN. But turns out in real life, people are bad, and on the internet, people are especially bad. So the, the servers don't, they don't hold state for your initial SYN. In fact, you know, servers are so afraid of keeping state that they don't even want to, to hold the state of your connection ID or TCP ID and instead tend to use something like SYN cookies, which you know, is a mitigation for a, for a DOS attack so that the server does not need, does not need to maintain even these few bytes of TCP session ID. They would be even more afraid of, of keeping 1500 bytes of payload in your, from your initial TCP SYN. Having said that, Facebook thought it'd be clever if we, if we still found a mechanism to send payload in our very, in our initial packet. So how does that work? Facebook thought it'd be reasonable that if you established a connection once, this is, this is regular TCP, this is fast open. If you established a connection once, then you're deemed good enough to come back a second time with the payload already in the first packet. Assuming that if you're a botnet or whatever, then you can possibly not establish a full connection and then, you know, it's, it's a trade-off they made. They say if you came once and you've had established a connection once, then we trust you that you're good enough that you can come back a second time and we're happy to then accept your payload in the first packet. So how does that work? You may see here is an addition compared to, this is regular TCP, you see the SYN and the ACK and you see here is the cookie. And the cookie is an opaque blob. It's a few bytes, I think something between 8 and 16 bytes that the server sends you and then you can see here in the, in the fast open case, we not only send our SYN flag, we also send these few bytes back to the server. And the server then, well, checks that the cookie matches its expectations and then accepts your, your data that you fear, that you've pushed here. Here's the payload that we want to send. And well, there's a few technical details such that this cookie, of course, does not have to make the server maintain state because that's what we were afraid of, right? So what does this mechanism do, that's probably the arguably the clever part of it, they, it's a Mac over the metadata. And in the case of Linux, it's the Mac over the source IP address and the target IP address. Maybe reports, I forgot. And then the server, when you come back, the server just needs to, to recompute the Mac of the metadata and see whether it matches the cookie and in that case, well, you're good enough. All right, so this is fast open and the, the attentive reader may already see some problems with these schemes regarding, well, tracking and so on. But we come back to that later. Let's first talk about session resumption. The idea is very similar. You establish a connection once and then you ought to be good enough to come back. In the case of TLS, it's a bit more complicated because we have negotiated encryption keys, right? And there's a few mechanisms. Well, actually two main ones with NTLS 1.2 and then there's a pre-share keys in TLS 1.3. That allow you to tell the server that you've been here before. You've had a connection before. I am the client. I've had a connection with you before. Here's my state. Please, server, let's reuse that state. Is that okay with you? That's roughly how session tickets work. Here's some, these two mechanisms, session tickets is, let's start with the session ID one. Everybody remembers the TCP-FAST OpenCookie I've had before that was only like a few bytes, right? Only sort of, and if you want to find an abstraction, it's only your ID, your number of, you know, your ID, your running number of connection that you've established. And then the server could look it up in a database. This is what session IDs are. So you get 16 bytes or so that identify you and then the server has to pull the state from somewhere, like from a database or something, and then reuse that state. Turned out, servers are lazy. They don't want to maintain the state. So they serialize all the state of the TLS connection in a relatively large, what they call, ticket. And then the server, the client, sends this ticket back each and every time it wants to connect, well, trying to coerce the server into deserializing the state and then, well, taking it from there and resuming the connection. That works well. And with the TLS 1.3, everybody ought to use it. These tickets are even encrypted. That was not the case before. So that's good. How does that work? This is TLS 1.2. We have our client hello. We have the server hello. And then, eventually, the server, well, we indicate that we have support for a session ticket that we want one. And then we eventually get this session ticket. And when we reestablish the connection, we send this session ticket back in our client hello. So we tell the server, here's my ticket that you've given me before. Would you please reuse that state? And then we can save the relatively expensive negotiation of a shared key. So that's great. That's a good mechanism. And if you've, well, listened carefully and if you have the ethical mindset, then you notice the problems which are that, well, you get the state from the server and the server needs to somehow, well, reuse the state from before. So there's nothing preventing the server from linking these requests, right? There's the server. By definition, the server needs to know who you were before in order to reuse this key material that you've established before. And in the case of, well, TLS, it's the session ticket, obviously. It could be the session ID2, but it's not that prevalent. And the TCP fast open case, we have this cookie. You remember we had this eight bytes that we get from the server and turns out that if you send it back to the server, then, well, surprise, surprise, the server learns who you were. Even worse, the network-based attacker, a passive attacker, like me now when I'm snooping all your wireless connections, I can see what token you receive from the server and then I can see you later when you send this token back. At least in the TCP case and in the TLS1.2 case because these tokens are sent in as plain text and similar with this quick token that I've mentioned before. So that's a problem, right? Because now we have, you know, especially in the TLS case because we wanted to use TLS in first place to protect our privacy. And now what happened? Now we're leaking not only to the server like who we were, which may be fair enough, right? If you're connecting to Facebook, it's, you know, maybe you're not so much concerned that Facebook learns who you were. But even worse, your network-based attacker can now re-identify you based on this privacy-preserving protocol that you're trying to use, which is TLS. And it's a complicated problem because we have this inherent conflict of what we're trying to achieve in terms of performance with what we're trying to achieve in terms of privacy. You could say now, well, you know, I don't use any of these mechanisms and then I'm good. And you're right. You could do that. You could simply nod your TLS resumption. In fairness, though, you'd have to configure all your libraries to not do that because they tend to give you the advantage of, like, more a quicker connection establishment. But you could do that. You could opt out. And what we ought to try, though, is to make it harder, to make these simplest attacks harder, to these tracking attacks, if you want to call them that, right? That the passive network attacker is not able to link your requests, that would be already a good step, right? Then, well, we would save some of our privacy when we send these cookies or tokens back to the server. So how prevalent is that? How much of a problem is that, really, this resumption case? This is the Alexa top million, I think. Yeah, one million. It's this proprietary top list of website made by Amazon. And what we can see here is that only 4% of the internet, let's call it the internet, is not using any form of session resumption. Conversely, the rest does. We can say that the internet uses TLS session resumption, well, not only to make your experience better, but also to save some CPU cycles and round trips as we've learned before. So potentially, these are all tracking you through the mechanism we've seen before. And what does that even mean to track? How big of an issue is this tracking problem, say? We've measured how long service advertised that they can track you. This is my negative interpretation. Their interpretation is for how long this key is valid now. And we have also measured how long clients actually reuse this token, like this tracking cookie if you want to call it that. So it turns out that self-advertised tracking time is roughly 24 hours. There's a few exceptions. I think Google and Facebook were like they had long tracking periods. And there is, well, when you reconnect, then you get a cut off here at about 1,000 minutes or so when clients tend to not send it back for whatever reason. By investigating the clients more closely, we see this behavior, which is that, well, clients keep the session ID, which is this relatively short token for this long, and the session ticket, which is this rather large state for that long. And we see things like anything from 30 minutes to a day or a day is the longest. And then the question is, can we extend this period? We have clients, because clients are not necessarily dumb. They know it's a problem that you can be tracked. So clients try to prevent you from being tracked. So what do they do? Well, they let this token time out. And in this case, they let the token time out in 30 minutes or here in one day. And then the question is, could we, as a smart attacker, somehow prolong this period? Could we somehow track users for longer than that? And yes, it's possible. If we think of an attacker like this, like a third party, your Google AdSense or whatever, and you have a website A and a website B, and A being, let's say, Facebook, and B being, let's say, eBay, and both include content from the third party, say Google AdWords or whatever it is. And then because you're browsing website A, you're establishing a connection to Google. Google gives you their session ticket. This is TLS 1.3 now, by the way. I thought I'd throw some more modern stuff in. This is a TLS 1.3 handshake. And then when you connect to website B to eBay, you also establish a connection to Google. And because you're reusing your session ticket or in TLS 1.3, it's the key share, then Google can link your two requests together. And again, your browser might extend the period on which this token is valid. And this is a measurement of how long you can actually track users using this method. It's based on data. We have acquired a real browsing behavior. And we see that this is the reconnection time of when users reconnect to a website for whatever reason, not necessarily directly, but also indirectly. And we've measured that you can track users for very long times. You find details in this paper there. It's quite interesting research. So what do we do to prevent this? Well, how about we do not send plain text tokens in first place? Wouldn't that be nice? Yeah, it would be so good to have more encryption on the link layer. Yeah, everybody should be in favor of that. And yeah, how about we encrypt these tokens using, well, some mechanism that we don't have yet? In fact, this quick token is not yet encrypted. How about we just encrypt that? The fast open cookie is not encrypted yet. How about we encrypt that? And in TLS, it's easy, though, because TLS 1.3 encrypts our session ticket. That's good. So let's not focus on this one, because we've talked a bit about quick. Let's talk about the fast open case. In fast open, we have the problem that we are on the TCP layer. And TCP has no encryption yet. And we, at the same time, require to not incur state on the server side, because it ought to be cheap for the server. So our options here are limited. What we came up with is to combine these two layers. That is the TLS layer and the TCP layer to send the token over the encrypted channel. That's the idea. And it then looks like this. You have your TCP connection establishment. You send your TLS clientel all. And you get this cookie, this TCP fast open cookie, back in this encrypted channel. And then you have the problem of feeding it back to Linux, because, well, somehow Linux needs to know about this cookie. So we introduced two new socket options. These are socket options we needed to introduce to make this happen. It's, well, some socket to get and set the cookie on a socket. And on the server side, we need to actually generate this cookie in order for the client to connect back. And this is the patch. It's like 200 lines, more or less. So it's easy enough to get into Linux. It's not terribly complicated to bring more privacy to these protocols. On the TLS side, we've used Wolf SSL. They have a booth here also, I think, in H. Good guys. I can highly recommend talking to those people. They're very nice. And Wolf SSL, we've patched such that the cookie comes over TLS. And then we have this patch of also roughly 200 lines. And that's minimal overhead. We have some more ideas how to, well, further increase performance and privacy of these protocols by combining these layers, and the core ideas are to somehow pre-fetch data and send them over an encrypted link. And there is some more applications we could, well, or some more protocols we could treat that way. My time is up, I was told. If you have any comments, questions, whatever, you're very welcome to contact me, the email or personally. And I don't know whether we have time for questions. I'm fearing not. But I will stick around. Thank you very much. Thank you.
 Let me say hello.  I'm Toby.  I'm a researcher at the University of Hamburg in the northern part of Germany.  My other hat that I'm wearing is a gnome hat.  So I am also active in the gnome project.  And within the gnome project, I'm trying to, well, increase the privacy and security aspects  of your computing.  And today, I'm here, or in this slot, I'm here to present research that we've conducted  in our lab in Hamburg.  So good to have experts here.  That's amazing.  Brilliant stuff.  So what was the fix?  Just push the button?  Or?  Good.  Perfect.  Right, right.  Probably with the right tension on the button.  This is the computer stuff.  Actually, I tried to push this new line of research with this, which is theological computer  science, because in computing, everything is non-deterministic, and you need to sacrifice  childs and have demons and everything.  But that's for another talk.  So as I said, I have a few hats.  One is this research hat from my university.  The other is my gnome hat.  And today, or in this very slot, I want to talk about some research we've done in what  we call core internet protocols regarding, well, tracking users' privacy aspects in  these protocols.  And I have to name my colleagues.  I will refer to a few papers that we've written and published, so if you want to know more  about several graphs or several strategies that I will present, I will have the pointers  in the slides.  So tracking in internet protocols in order to understand what the issue is, what the  scenario is, let me ask you to briefly think about what happens if you type some address  in your browser and hit Enter.  And then the next few milliseconds or seconds, what happens?  And now we could do that interactively as a quiz and so on, but we don't have so much  time, so I'll tell you what happens.  We have many round trips back and forth, and it starts with the DNS, and then eventually  you have the IP address, then you open a TCP connection, and then you send your TLS request  because we want to push encrypted communication forward.  And eventually, here down below, you have your payload.  This is what you actually want to send to the other party.  The stuff before is the overhead involved in well, connecting to that web server in this  case.  Arguably bandwidth is not so much of an issue these days.  I mean, of course, well, you could always want more, and you're never satisfied with  the amount of bandwidth you have, but arguably latency is much more important these days  than bandwidth.  And let's just make that an assumption, right?  If an academic doesn't have anything, any data to back things up, we just assume that  it's the case.  And we just assume that latency is an issue.  So people want to reduce the number of round trips here, the number of times back and forth.  And well, thinking that this, well, makes the application more snappy and uses more  happy when they have snappy websites.  And in fact, there was a, I think it was the motivation, like the paper that introduced  them quick, when Google introduced quick, I think they conducted research on their YouTube  platform.  And I remember something like Google claiming having, and now I make a number of, 30% more  revenue when they have clients connecting via quick, because then people are less likely  to just prematurely abort the connection and not watch the video and the advertisement.  So maybe it's not 30%, maybe it's 13.  But even then, saving one or two round trips does have an impact on, well, people like  Google or entities like Google when they terminate loads of connections, and well, saving a few  round trips is good.  Anyway, so this is the standard connection establishment as of today.  And what do people do to reduce the number of round trips?  People do things like this.  So there's a few mechanisms.  One is TCP fast open.  There's a TLS session resumption, which you may be more familiar with.  And then there's quick, which will be the new, or will be the base for the HTTP 3 protocol.  So these are mechanisms to reduce the round trips.  And we had a look at the privacy properties in these protocols, because maybe, sure Google  is interested in making your connection faster, giving you a more pleasant experience while  browsing the videos.  But maybe, just maybe, it's a hidden tracking mechanism that nobody thought of, and it's  the grand evil plan, and now everything comes together, and then they know everything.  So we had a look.  But before discussing these in more detail, let's have a look at those.  This is quick.  And we don't really need to understand each and every line item there.  What we will see is that there's a connection establishment made by the client.  And then at the end of the day, we get some token from the server, which we can then,  in our subsequent request, use here.  So this is the initial connection establishment.  This is the resumption when you come back later.  Then you save one round trip, and you do that, because you share states with the server.  You have established this state, which is encoded in this cookie or token, whatever  you want to call it.  And eventually, you send it back so that the server will know who you were or who you are  and can then link your state.  So this is some, and it's a very brief overview of a quick, right?  It's of course, there's many more aspects to this, but this is the core aspect that  we were interested in.  TCP fast open works similarly.  It's in TCP.  You know there's this screen by handshake, right?  We send our SYN, and then we get the response back, and then we again send the ACK.  And modern like systems, they only push the payload with this third packet there with  the ACK.  There's, interestingly enough, there's nothing in the, there's nothing preventing you from  already sending your payload in the initial SYN.  But turns out in real life, people are bad, and on the internet, people are especially  bad.  So the, the servers don't, they don't hold state for your initial SYN.  In fact, you know, servers are so afraid of keeping state that they don't even want  to, to hold the state of your connection ID or TCP ID and instead tend to use something  like SYN cookies, which you know, is a mitigation for a, for a DOS attack so that the server  does not need, does not need to maintain even these few bytes of TCP session ID.  They would be even more afraid of, of keeping 1500 bytes of payload in your, from your initial  TCP SYN.  Having said that, Facebook thought it'd be clever if we, if we still found a mechanism  to send payload in our very, in our initial packet.  So how does that work?  Facebook thought it'd be reasonable that if you established a connection once, this is,  this is regular TCP, this is fast open.  If you established a connection once, then you're deemed good enough to come back a second  time with the payload already in the first packet.  Assuming that if you're a botnet or whatever, then you can possibly not establish a full  connection and then, you know, it's, it's a trade-off they made.  They say if you came once and you've had established a connection once, then we trust  you that you're good enough that you can come back a second time and we're happy to then  accept your payload in the first packet.  So how does that work?  You may see here is an addition compared to, this is regular TCP, you see the SYN and the  ACK and you see here is the cookie.  And the cookie is an opaque blob.  It's a few bytes, I think something between 8 and 16 bytes that the server sends you and  then you can see here in the, in the fast open case, we not only send our SYN flag,  we also send these few bytes back to the server.  And the server then, well, checks that the cookie matches its expectations and then accepts  your, your data that you fear, that you've pushed here.  Here's the payload that we want to send.  And well, there's a few technical details such that this cookie, of course, does not  have to make the server maintain state because that's what we were afraid of, right?  So what does this mechanism do, that's probably the arguably the clever part of it, they,  it's a Mac over the metadata.  And in the case of Linux, it's the Mac over the source IP address and the target IP address.  Maybe reports, I forgot.  And then the server, when you come back, the server just needs to, to recompute the Mac  of the metadata and see whether it matches the cookie and in that case, well, you're  good enough.  All right, so this is fast open and the, the attentive reader may already see some problems  with these schemes regarding, well, tracking and so on.  But we come back to that later.  Let's first talk about session resumption.  The idea is very similar.  You establish a connection once and then you ought to be good enough to come back.  In the case of TLS, it's a bit more complicated because we have negotiated encryption keys,  right?  And there's a few mechanisms.  Well, actually two main ones with NTLS 1.2 and then there's a pre-share keys in TLS  1.3.  That allow you to tell the server that you've been here before.  You've had a connection before.  I am the client.  I've had a connection with you before.  Here's my state.  Please, server, let's reuse that state.  Is that okay with you?  That's roughly how session tickets work.  Here's some, these two mechanisms, session tickets is, let's start with the session ID  one.  Everybody remembers the TCP-FAST OpenCookie I've had before that was only like a few bytes,  right?  Only sort of, and if you want to find an abstraction, it's only your ID, your number of, you know,  your ID, your running number of connection that you've established.  And then the server could look it up in a database.  This is what session IDs are.  So you get 16 bytes or so that identify you and then the server has to pull the state  from somewhere, like from a database or something, and then reuse that state.  Turned out, servers are lazy.  They don't want to maintain the state.  So they serialize all the state of the TLS connection in a relatively large, what they  call, ticket.  And then the server, the client, sends this ticket back each and every time it wants to  connect, well, trying to coerce the server into deserializing the state and then, well,  taking it from there and resuming the connection.  That works well.  And with the TLS 1.3, everybody ought to use it.  These tickets are even encrypted.  That was not the case before.  So that's good.  How does that work?  This is TLS 1.2.  We have our client hello.  We have the server hello.  And then, eventually, the server, well, we indicate that we have support for a session  ticket that we want one.  And then we eventually get this session ticket.  And when we reestablish the connection, we send this session ticket back in our client  hello.  So we tell the server, here's my ticket that you've given me before.  Would you please reuse that state?  And then we can save the relatively expensive negotiation of a shared key.  So that's great.  That's a good mechanism.  And if you've, well, listened carefully and if you have the ethical mindset, then you  notice the problems which are that, well, you get the state from the server and the  server needs to somehow, well, reuse the state from before.  So there's nothing preventing the server from linking these requests, right?  There's the server.  By definition, the server needs to know who you were before in order to reuse this key  material that you've established before.  And in the case of, well, TLS, it's the session ticket, obviously.  It could be the session ID2, but it's not that prevalent.  And the TCP fast open case, we have this cookie.  You remember we had this eight bytes that we get from the server and turns out that if  you send it back to the server, then, well, surprise, surprise, the server learns who  you were.  Even worse, the network-based attacker, a passive attacker, like me now when I'm snooping all  your wireless connections, I can see what token you receive from the server and then  I can see you later when you send this token back.  At least in the TCP case and in the TLS1.2 case because these tokens are sent in as plain  text and similar with this quick token that I've mentioned before.  So that's a problem, right?  Because now we have, you know, especially in the TLS case because we wanted to use TLS  in first place to protect our privacy.  And now what happened?  Now we're leaking not only to the server like who we were, which may be fair enough, right?  If you're connecting to Facebook, it's, you know, maybe you're not so much concerned that  Facebook learns who you were.  But even worse, your network-based attacker can now re-identify you based on this privacy-preserving  protocol that you're trying to use, which is TLS.  And it's a complicated problem because we have this inherent conflict of what we're  trying to achieve in terms of performance with what we're trying to achieve in terms  of privacy.  You could say now, well, you know, I don't use any of these mechanisms and then I'm good.  And you're right.  You could do that.  You could simply nod your TLS resumption.  In fairness, though, you'd have to configure all your libraries to not do that because  they tend to give you the advantage of, like, more a quicker connection establishment.  But you could do that.  You could opt out.  And what we ought to try, though, is to make it harder, to make these simplest attacks  harder, to these tracking attacks, if you want to call them that, right?  That the passive network attacker is not able to link your requests, that would be already  a good step, right?  Then, well, we would save some of our privacy when we send these cookies or tokens back  to the server.  So how prevalent is that?  How much of a problem is that, really, this resumption case?  This is the Alexa top million, I think.  Yeah, one million.  It's this proprietary top list of website made by Amazon.  And what we can see here is that only 4% of the internet, let's call it the internet,  is not using any form of session resumption.  Conversely, the rest does.  We can say that the internet uses TLS session resumption, well, not only to make your experience  better, but also to save some CPU cycles and round trips as we've learned before.  So potentially, these are all tracking you through the mechanism we've seen before.  And what does that even mean to track?  How big of an issue is this tracking problem, say?  We've measured how long service advertised that they can track you.  This is my negative interpretation.  Their interpretation is for how long this key is valid now.  And we have also measured how long clients actually reuse this token, like this tracking  cookie if you want to call it that.  So it turns out that self-advertised tracking time is roughly 24 hours.  There's a few exceptions.  I think Google and Facebook were like they had long tracking periods.  And there is, well, when you reconnect, then you get a cut off here at about 1,000 minutes  or so when clients tend to not send it back for whatever reason.  By investigating the clients more closely, we see this behavior, which is that, well,  clients keep the session ID, which is this relatively short token for this long, and  the session ticket, which is this rather large state for that long.  And we see things like anything from 30 minutes to a day or a day is the longest.  And then the question is, can we extend this period?  We have clients, because clients are not necessarily dumb.  They know it's a problem that you can be tracked.  So clients try to prevent you from being tracked.  So what do they do?  Well, they let this token time out.  And in this case, they let the token time out in 30 minutes or here in one day.  And then the question is, could we, as a smart attacker, somehow prolong this period?  Could we somehow track users for longer than that?  And yes, it's possible.  If we think of an attacker like this, like a third party, your Google AdSense or whatever,  and you have a website A and a website B, and A being, let's say, Facebook, and B being,  let's say, eBay, and both include content from the third party, say Google AdWords or  whatever it is.  And then because you're browsing website A, you're establishing a connection to Google.  Google gives you their session ticket.  This is TLS 1.3 now, by the way.  I thought I'd throw some more modern stuff in.  This is a TLS 1.3 handshake.  And then when you connect to website B to eBay, you also establish a connection to Google.  And because you're reusing your session ticket or in TLS 1.3, it's the key share, then Google  can link your two requests together.  And again, your browser might extend the period on which this token is valid.  And this is a measurement of how long you can actually track users using this method.  It's based on data.  We have acquired a real browsing behavior.  And we see that this is the reconnection time of when users reconnect to a website for whatever  reason, not necessarily directly, but also indirectly.  And we've measured that you can track users for very long times.  You find details in this paper there.  It's quite interesting research.  So what do we do to prevent this?  Well, how about we do not send plain text tokens in first place?  Wouldn't that be nice?  Yeah, it would be so good to have more encryption on the link layer.  Yeah, everybody should be in favor of that.  And yeah, how about we encrypt these tokens using, well, some mechanism that we don't  have yet?  In fact, this quick token is not yet encrypted.  How about we just encrypt that?  The fast open cookie is not encrypted yet.  How about we encrypt that?  And in TLS, it's easy, though, because TLS 1.3 encrypts our session ticket.  That's good.  So let's not focus on this one, because we've talked a bit about quick.  Let's talk about the fast open case.  In fast open, we have the problem that we are on the TCP layer.  And TCP has no encryption yet.  And we, at the same time, require to not incur state on the server side, because it ought  to be cheap for the server.  So our options here are limited.  What we came up with is to combine these two layers.  That is the TLS layer and the TCP layer to send the token over the encrypted channel.  That's the idea.  And it then looks like this.  You have your TCP connection establishment.  You send your TLS clientel all.  And you get this cookie, this TCP fast open cookie, back in this encrypted channel.  And then you have the problem of feeding it back to Linux, because, well, somehow Linux  needs to know about this cookie.  So we introduced two new socket options.  These are socket options we needed to introduce to make this happen.  It's, well, some socket to get and set the cookie on a socket.  And on the server side, we need to actually generate this cookie in order for the client  to connect back.  And this is the patch.  It's like 200 lines, more or less.  So it's easy enough to get into Linux.  It's not terribly complicated to bring more privacy to these protocols.  On the TLS side, we've used Wolf SSL.  They have a booth here also, I think, in H. Good guys.  I can highly recommend talking to those people.  They're very nice.  And Wolf SSL, we've patched such that the cookie comes over TLS.  And then we have this patch of also roughly 200 lines.  And that's minimal overhead.  We have some more ideas how to, well, further increase performance and privacy of these  protocols by combining these layers, and the core ideas are to somehow pre-fetch data  and send them over an encrypted link.  And there is some more applications we could, well, or some more protocols we could treat  that way.  My time is up, I was told.  If you have any comments, questions, whatever, you're very welcome to contact me, the email  or personally.  And I don't know whether we have time for questions.  I'm fearing not.  But I will stick around.  Thank you very much.  Thank you.
Tracking_users_with_core_Internet_protocols_Enhancing_privacy_0_47.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_48_107.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_108_515.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_516_959.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_960_1043.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_1044_2015.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_2016_3047.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_3048_3599.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_3600_6707.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_6708_7871.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_7872_9383.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_9384_14687.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_14688_17651.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_17652_18791.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_18792_21335.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_21336_22919.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_22920_24059.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_24060_25463.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_25464_26807.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_26808_28271.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_28272_29087.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_29088_30131.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_30132_30899.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_30900_31403.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_31404_31823.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_31824_32147.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_32148_32495.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_32496_32591.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_32592_32651.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_32652_33131.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_33132_33623.png Tracking_users_with_core_Internet_protocols_Enhancing_privacy_33624_33743.png
Let me say hello. I'm Toby. I'm a researcher at the University of Hamburg in the northern part of Germany. My other hat that I'm wearing is a gnome hat. So I am also active in the gnome project. And within the gnome project, I'm trying to, well, increase the privacy and security aspects of your computing. And today, I'm here, or in this slot, I'm here to present research that we've conducted in our lab in Hamburg. So good to have experts here. That's amazing. Brilliant stuff. So what was the fix? Just push the button? Or? Good. Perfect. Right, right. Probably with the right tension on the button. This is the computer stuff. Actually, I tried to push this new line of research with this, which is theological computer science, because in computing, everything is non-deterministic, and you need to sacrifice childs and have demons and everything. But that's for another talk. So as I said, I have a few hats. One is this research hat from my university. The other is my gnome hat. And today, or in this very slot, I want to talk about some research we've done in what we call core internet protocols regarding, well, tracking users' privacy aspects in these protocols. And I have to name my colleagues. I will refer to a few papers that we've written and published, so if you want to know more about several graphs or several strategies that I will present, I will have the pointers in the slides. So tracking in internet protocols in order to understand what the issue is, what the scenario is, let me ask you to briefly think about what happens if you type some address in your browser and hit Enter. And then the next few milliseconds or seconds, what happens? And now we could do that interactively as a quiz and so on, but we don't have so much time, so I'll tell you what happens. We have many round trips back and forth, and it starts with the DNS, and then eventually you have the IP address, then you open a TCP connection, and then you send your TLS request because we want to push encrypted communication forward. And eventually, here down below, you have your payload. This is what you actually want to send to the other party. The stuff before is the overhead involved in well, connecting to that web server in this case. Arguably bandwidth is not so much of an issue these days. I mean, of course, well, you could always want more, and you're never satisfied with the amount of bandwidth you have, but arguably latency is much more important these days than bandwidth. And let's just make that an assumption, right? If an academic doesn't have anything, any data to back things up, we just assume that it's the case. And we just assume that latency is an issue. So people want to reduce the number of round trips here, the number of times back and forth. And well, thinking that this, well, makes the application more snappy and uses more happy when they have snappy websites. And in fact, there was a, I think it was the motivation, like the paper that introduced them quick, when Google introduced quick, I think they conducted research on their YouTube platform. And I remember something like Google claiming having, and now I make a number of, 30% more revenue when they have clients connecting via quick, because then people are less likely to just prematurely abort the connection and not watch the video and the advertisement. So maybe it's not 30%, maybe it's 13. But even then, saving one or two round trips does have an impact on, well, people like Google or entities like Google when they terminate loads of connections, and well, saving a few round trips is good. Anyway, so this is the standard connection establishment as of today. And what do people do to reduce the number of round trips? People do things like this. So there's a few mechanisms. One is TCP fast open. There's a TLS session resumption, which you may be more familiar with. And then there's quick, which will be the new, or will be the base for the HTTP 3 protocol. So these are mechanisms to reduce the round trips. And we had a look at the privacy properties in these protocols, because maybe, sure Google is interested in making your connection faster, giving you a more pleasant experience while browsing the videos. But maybe, just maybe, it's a hidden tracking mechanism that nobody thought of, and it's the grand evil plan, and now everything comes together, and then they know everything. So we had a look. But before discussing these in more detail, let's have a look at those. This is quick. And we don't really need to understand each and every line item there. What we will see is that there's a connection establishment made by the client. And then at the end of the day, we get some token from the server, which we can then, in our subsequent request, use here. So this is the initial connection establishment. This is the resumption when you come back later. Then you save one round trip, and you do that, because you share states with the server. You have established this state, which is encoded in this cookie or token, whatever you want to call it. And eventually, you send it back so that the server will know who you were or who you are and can then link your state. So this is some, and it's a very brief overview of a quick, right? It's of course, there's many more aspects to this, but this is the core aspect that we were interested in. TCP fast open works similarly. It's in TCP. You know there's this screen by handshake, right? We send our SYN, and then we get the response back, and then we again send the ACK. And modern like systems, they only push the payload with this third packet there with the ACK. There's, interestingly enough, there's nothing in the, there's nothing preventing you from already sending your payload in the initial SYN. But turns out in real life, people are bad, and on the internet, people are especially bad. So the, the servers don't, they don't hold state for your initial SYN. In fact, you know, servers are so afraid of keeping state that they don't even want to, to hold the state of your connection ID or TCP ID and instead tend to use something like SYN cookies, which you know, is a mitigation for a, for a DOS attack so that the server does not need, does not need to maintain even these few bytes of TCP session ID. They would be even more afraid of, of keeping 1500 bytes of payload in your, from your initial TCP SYN. Having said that, Facebook thought it'd be clever if we, if we still found a mechanism to send payload in our very, in our initial packet. So how does that work? Facebook thought it'd be reasonable that if you established a connection once, this is, this is regular TCP, this is fast open. If you established a connection once, then you're deemed good enough to come back a second time with the payload already in the first packet. Assuming that if you're a botnet or whatever, then you can possibly not establish a full connection and then, you know, it's, it's a trade-off they made. They say if you came once and you've had established a connection once, then we trust you that you're good enough that you can come back a second time and we're happy to then accept your payload in the first packet. So how does that work? You may see here is an addition compared to, this is regular TCP, you see the SYN and the ACK and you see here is the cookie. And the cookie is an opaque blob. It's a few bytes, I think something between 8 and 16 bytes that the server sends you and then you can see here in the, in the fast open case, we not only send our SYN flag, we also send these few bytes back to the server. And the server then, well, checks that the cookie matches its expectations and then accepts your, your data that you fear, that you've pushed here. Here's the payload that we want to send. And well, there's a few technical details such that this cookie, of course, does not have to make the server maintain state because that's what we were afraid of, right? So what does this mechanism do, that's probably the arguably the clever part of it, they, it's a Mac over the metadata. And in the case of Linux, it's the Mac over the source IP address and the target IP address. Maybe reports, I forgot. And then the server, when you come back, the server just needs to, to recompute the Mac of the metadata and see whether it matches the cookie and in that case, well, you're good enough. All right, so this is fast open and the, the attentive reader may already see some problems with these schemes regarding, well, tracking and so on. But we come back to that later. Let's first talk about session resumption. The idea is very similar. You establish a connection once and then you ought to be good enough to come back. In the case of TLS, it's a bit more complicated because we have negotiated encryption keys, right? And there's a few mechanisms. Well, actually two main ones with NTLS 1.2 and then there's a pre-share keys in TLS 1.3. That allow you to tell the server that you've been here before. You've had a connection before. I am the client. I've had a connection with you before. Here's my state. Please, server, let's reuse that state. Is that okay with you? That's roughly how session tickets work. Here's some, these two mechanisms, session tickets is, let's start with the session ID one. Everybody remembers the TCP-FAST OpenCookie I've had before that was only like a few bytes, right? Only sort of, and if you want to find an abstraction, it's only your ID, your number of, you know, your ID, your running number of connection that you've established. And then the server could look it up in a database. This is what session IDs are. So you get 16 bytes or so that identify you and then the server has to pull the state from somewhere, like from a database or something, and then reuse that state. Turned out, servers are lazy. They don't want to maintain the state. So they serialize all the state of the TLS connection in a relatively large, what they call, ticket. And then the server, the client, sends this ticket back each and every time it wants to connect, well, trying to coerce the server into deserializing the state and then, well, taking it from there and resuming the connection. That works well. And with the TLS 1.3, everybody ought to use it. These tickets are even encrypted. That was not the case before. So that's good. How does that work? This is TLS 1.2. We have our client hello. We have the server hello. And then, eventually, the server, well, we indicate that we have support for a session ticket that we want one. And then we eventually get this session ticket. And when we reestablish the connection, we send this session ticket back in our client hello. So we tell the server, here's my ticket that you've given me before. Would you please reuse that state? And then we can save the relatively expensive negotiation of a shared key. So that's great. That's a good mechanism. And if you've, well, listened carefully and if you have the ethical mindset, then you notice the problems which are that, well, you get the state from the server and the server needs to somehow, well, reuse the state from before. So there's nothing preventing the server from linking these requests, right? There's the server. By definition, the server needs to know who you were before in order to reuse this key material that you've established before. And in the case of, well, TLS, it's the session ticket, obviously. It could be the session ID2, but it's not that prevalent. And the TCP fast open case, we have this cookie. You remember we had this eight bytes that we get from the server and turns out that if you send it back to the server, then, well, surprise, surprise, the server learns who you were. Even worse, the network-based attacker, a passive attacker, like me now when I'm snooping all your wireless connections, I can see what token you receive from the server and then I can see you later when you send this token back. At least in the TCP case and in the TLS1.2 case because these tokens are sent in as plain text and similar with this quick token that I've mentioned before. So that's a problem, right? Because now we have, you know, especially in the TLS case because we wanted to use TLS in first place to protect our privacy. And now what happened? Now we're leaking not only to the server like who we were, which may be fair enough, right? If you're connecting to Facebook, it's, you know, maybe you're not so much concerned that Facebook learns who you were. But even worse, your network-based attacker can now re-identify you based on this privacy-preserving protocol that you're trying to use, which is TLS. And it's a complicated problem because we have this inherent conflict of what we're trying to achieve in terms of performance with what we're trying to achieve in terms of privacy. You could say now, well, you know, I don't use any of these mechanisms and then I'm good. And you're right. You could do that. You could simply nod your TLS resumption. In fairness, though, you'd have to configure all your libraries to not do that because they tend to give you the advantage of, like, more a quicker connection establishment. But you could do that. You could opt out. And what we ought to try, though, is to make it harder, to make these simplest attacks harder, to these tracking attacks, if you want to call them that, right? That the passive network attacker is not able to link your requests, that would be already a good step, right? Then, well, we would save some of our privacy when we send these cookies or tokens back to the server. So how prevalent is that? How much of a problem is that, really, this resumption case? This is the Alexa top million, I think. Yeah, one million. It's this proprietary top list of website made by Amazon. And what we can see here is that only 4% of the internet, let's call it the internet, is not using any form of session resumption. Conversely, the rest does. We can say that the internet uses TLS session resumption, well, not only to make your experience better, but also to save some CPU cycles and round trips as we've learned before. So potentially, these are all tracking you through the mechanism we've seen before. And what does that even mean to track? How big of an issue is this tracking problem, say? We've measured how long service advertised that they can track you. This is my negative interpretation. Their interpretation is for how long this key is valid now. And we have also measured how long clients actually reuse this token, like this tracking cookie if you want to call it that. So it turns out that self-advertised tracking time is roughly 24 hours. There's a few exceptions. I think Google and Facebook were like they had long tracking periods. And there is, well, when you reconnect, then you get a cut off here at about 1,000 minutes or so when clients tend to not send it back for whatever reason. By investigating the clients more closely, we see this behavior, which is that, well, clients keep the session ID, which is this relatively short token for this long, and the session ticket, which is this rather large state for that long. And we see things like anything from 30 minutes to a day or a day is the longest. And then the question is, can we extend this period? We have clients, because clients are not necessarily dumb. They know it's a problem that you can be tracked. So clients try to prevent you from being tracked. So what do they do? Well, they let this token time out. And in this case, they let the token time out in 30 minutes or here in one day. And then the question is, could we, as a smart attacker, somehow prolong this period? Could we somehow track users for longer than that? And yes, it's possible. If we think of an attacker like this, like a third party, your Google AdSense or whatever, and you have a website A and a website B, and A being, let's say, Facebook, and B being, let's say, eBay, and both include content from the third party, say Google AdWords or whatever it is. And then because you're browsing website A, you're establishing a connection to Google. Google gives you their session ticket. This is TLS 1.3 now, by the way. I thought I'd throw some more modern stuff in. This is a TLS 1.3 handshake. And then when you connect to website B to eBay, you also establish a connection to Google. And because you're reusing your session ticket or in TLS 1.3, it's the key share, then Google can link your two requests together. And again, your browser might extend the period on which this token is valid. And this is a measurement of how long you can actually track users using this method. It's based on data. We have acquired a real browsing behavior. And we see that this is the reconnection time of when users reconnect to a website for whatever reason, not necessarily directly, but also indirectly. And we've measured that you can track users for very long times. You find details in this paper there. It's quite interesting research. So what do we do to prevent this? Well, how about we do not send plain text tokens in first place? Wouldn't that be nice? Yeah, it would be so good to have more encryption on the link layer. Yeah, everybody should be in favor of that. And yeah, how about we encrypt these tokens using, well, some mechanism that we don't have yet? In fact, this quick token is not yet encrypted. How about we just encrypt that? The fast open cookie is not encrypted yet. How about we encrypt that? And in TLS, it's easy, though, because TLS 1.3 encrypts our session ticket. That's good. So let's not focus on this one, because we've talked a bit about quick. Let's talk about the fast open case. In fast open, we have the problem that we are on the TCP layer. And TCP has no encryption yet. And we, at the same time, require to not incur state on the server side, because it ought to be cheap for the server. So our options here are limited. What we came up with is to combine these two layers. That is the TLS layer and the TCP layer to send the token over the encrypted channel. That's the idea. And it then looks like this. You have your TCP connection establishment. You send your TLS clientel all. And you get this cookie, this TCP fast open cookie, back in this encrypted channel. And then you have the problem of feeding it back to Linux, because, well, somehow Linux needs to know about this cookie. So we introduced two new socket options. These are socket options we needed to introduce to make this happen. It's, well, some socket to get and set the cookie on a socket. And on the server side, we need to actually generate this cookie in order for the client to connect back. And this is the patch. It's like 200 lines, more or less. So it's easy enough to get into Linux. It's not terribly complicated to bring more privacy to these protocols. On the TLS side, we've used Wolf SSL. They have a booth here also, I think, in H. Good guys. I can highly recommend talking to those people. They're very nice. And Wolf SSL, we've patched such that the cookie comes over TLS. And then we have this patch of also roughly 200 lines. And that's minimal overhead. We have some more ideas how to, well, further increase performance and privacy of these protocols by combining these layers, and the core ideas are to somehow pre-fetch data and send them over an encrypted link. And there is some more applications we could, well, or some more protocols we could treat that way. My time is up, I was told. If you have any comments, questions, whatever, you're very welcome to contact me, the email or personally. And I don't know whether we have time for questions. I'm fearing not. But I will stick around. Thank you very much. Thank you.
users' privacy aspects in these protocols. And I several strategies that I will present, I will starts with the DNS, and then eventually you have the IP address, then you open a TCP connection, overhead involved in well, connecting to that web these days than bandwidth. And let's just make connecting via quick, because then people are familiar with. And then there's quick, which will protocol. So these are mechanisms to reduce the properties in these protocols, because maybe, connection faster, giving you a more pleasant there. What we will see is that there's a connection establishment made by the client. And then at the end of the day, we get some token initial connection establishment. This is the this, but this is the core aspect that we were and on the internet, people are especially bad. server does not need, does not need to maintain bytes of payload in your, from your initial TCP The idea is very similar. You establish a enough to come back. In the case of TLS, it's a 1.3. That allow you to tell the server that your running number of connection that you've from there and resuming the connection. That works well. And with the TLS 1.3, everybody ought eventually, the server, well, we indicate that we one. And then we eventually get this session all your wireless connections, I can see what least in the TCP case and in the TLS1.2 case server like who we were, which may be fair save some of our privacy when we send these cookies or tokens back to the server. So how How big of an issue is this tracking problem, periods. And there is, well, when you reconnect, this case, they let the token time out in 30 And this is a measurement of how long you can based on data. We have acquired a real browsing behavior. And we see that this is the that you can track users for very long times. You socket options. These are socket options we client to connect back. And this is the patch. then we have this patch of also roughly 200 more ideas how to, well, further increase performance and privacy of these protocols by