4 ms·
The problem I see is not the computational power required for implementing the DPI, but the storage capacity and bandwidth required to implement retention for u
by datenwolf 10y ago
The problem I see is not the computational power required for implementing the DPI, but the storage capacity and bandwidth required to implement retention for upo to a year. Lets assume that ISPs were applying a data cap of, let's say 200GiB/month. MTU for Ethernet is 1500 octets, with PPPoE it's 1480. IP Headers are at least 17 octets, so around 1% overhead for a optimally utilized connection. In that situation this gives about 2GiB/month of IP header data. Even if you strip that down to just the source/destination address that would still leave you with 800MiB/(customer·month) of data. That's the bottom baseline you have to provision for.
Of course your typical TCP stream is highly redundant and even simple RLE compression will cut that. But ISPs have to provision for the worst case. Currently there are about 60M internet users in the UK.
That would amount to about 536PiB/year of retention data to be provisioned for (worst case). And even if due to redundancies you can compress that down in practice that's still a lot of harddisks to keep around just to store the bare minimum (who with whom, but without context) of a whole country's internet traffic metadata (about 100k HDDs).
That's a significant investment that's expected from ISPs to be implemented in a very short timespan.
- mfukar 10y agoDisclaimer: I won't claim to have read the law or even caring about what happens in the UK. From reading related articles, I get the idea its requirements can be implemented in terms of a browsing history, which could point to a date in the internet archive for all the legislator cares. Hint: that's how you compress browsing habits for > quadrillions of requests. I don't see why one would need complete packet traces of the whole thing.
- datenwolf 10y ago> From reading related articles, I get the idea its requirements can be implemented in terms of a browsing history, which could point to a date in the internet archive for all the legislator cares. Good luck doing that with a TLS secured connection. All you see is the TCP stream between the two peers. And thanks to PFS enforced on the server side you can't even go around and force people to escrow their keys. > I don't see why one would need complete packet traces of the whole thing. Because that's the only thing an ISP is able to see of a properly encrypted connection.
- viraptor 10y agoBut it's useless to save the encrypted bytes so nobody will do it. It doesn't matter the connection is encrypted - you still get the following information: Source IP, mapped to customer. Timestamp. Target domain (from SNI or the certificate). Passive system identification (os, browser). The only thing they're additionally interested in is the link and that's the only thing that encryption hides. I'm not sure they even care about cookies and headers in ICR
- anonymousab 10y agoThey'll get around to government mandated certs, backdoors or other such stuff eventually.
- datenwolf 10y agoCertificate pinning anyone? Also a few years ago DJB proposed to make a systems hostname the nonce of a key/signature and use secured DNS (DNSSEC or DNSCurve) as a means for establishing a web of trust; a CNAME would be used to for translating www.example.com into ${NONCE}.example.com. Since DNSSEC (and DNSCurve) allow for signature verfication against a small number of root keys (ATM a single digit number) it'd be trivial to ensure an unbroken chain of trust for name resolution, which essentially completely mitigates a state level MitM attack on DNS. So by combination of securing DNS and nonceing the hostname into TLS certificates you can throw quite a log into state level crypto circumvention. Of course the critical problem is rolling out all the necessary protocol changes and implementation. And of course DNSSEC is used only homeopathically ATM (and yes, I'm guilty of not having implemented for my stuff as well).
- mfukar 10y agoSo ISPs can now be coerced, by law, to allow for MITM in TLS connections. Another reasonable expectation from buyers of DPI products. Like I said, nothing technically absurd about this law. It is its profound disregard for privacy that we should be discussing, instead of spending our time on technical issues which are solved.
- dorfsmay 10y agoWhat about SSL? If they don't terminate SSL a la NSA/google, then all they know is that you're talking to a lot CDNs and cloud provider. I guess they can try to cross-match that with your DNS queries, but that still is fairly generic.
- viraptor 10y agoWhen you make an ssl connection you're sending the domain name in the clear. They don't need to match on dns.
- movedx 10y agoHTTP over SSL/TLS? No, the domain is not visible. The domain (hostname) you request is inside the encrypted communications between you and the remote server. Only the TCP information is visible (IP, source port, destination IP, and destination port.) It's the DNS request which reveals the domain you requested.
- viraptor 10y agoHave a look at https communication in Wireshark for example. What you wrote is incorrect. Https reveals the domain at least one time these days. First, ssl extension SNI (https://en.m.wikipedia.org/wiki/Server_Name_Indication https://en.m.wikipedia.org/wiki/Server_Name_Indication) is sent, which reveals the domain you're requesting. This happens before the keys are exchanged. Then, the matching certificate is sent (again in plaintext) from the server so that you can verify it and extract the keys. It will contain the domain again, although it may be a partial one like *.example.com So no, the domain is public. The full URL path is encrypted though.
- movedx 10y agoThanks for the info! I hadn't considered some of those aspects of the connection process.
- EvilTerran 10y ago
- chinathrow 10y agoThey don't need to implement that - GCHQ has that already. One month buffer, at least. Scale to 6, done.