4 ms·
Why is this necessary? Shouldn't all encrypted traffic be compressed to begin with? I'm ignorant of how SSL traffic is actually encrypted, but if you're alread
by drcube 14y ago
Why is this necessary? Shouldn't all encrypted traffic be compressed to begin with?
I'm ignorant of how SSL traffic is actually encrypted, but if you're already crunching the numbers to encrypt something, and a big part of encryption is eliminating redundancy, why isn't the data compressed at the same time?
Seems like you could kill two birds at once and eliminate any reason to decrypt HTTPS data for caching purposes as well. It would cut down on traffic for the rest of us on the internet too.
Or is this like CDN caching, where it's more about limiting latency than bandwidth?
- wikyd 14y agoI'm not sure about Nokia's service specifically, but in general these kinds of services do more than just zipping files. Some things they do: * resize images large images to match the screen resolution * limit the number of HTTP requests the phone itself is making
- tachim 14y agoThe point of most encryption algorithms isn't to compress the data or remove redundancy, at all. In fact, most widely used algorithms are block ciphers that don't change the size of the data.
- jsnell 14y agoIt's not just compression. These kinds of schemes can e.g. eliminate a massive number of extra roundtrips over a high latency mobile link. Or eliminate most uplink traffic completely (basically you'd just need to issue a request for the main page, all the subresources could automatically fetched by the proxy server and pushed to the client without it specifically requesting them). And that can be a huge win on mobile, since uplink tends to be way slower than downlink and often becomes a bottleneck for pages with many small resources.
- DanBC 14y agoThey like to crush images. I'm on a mobile dongle (T Mobile, UK) and I'll happily take some screenshots if anyone has some test gifs anywhere. Mine don't interfere with SSL. But a lot of other stuff is weird or broken.
- A1kmm 14y ago> Why is this necessary? Shouldn't all encrypted traffic be > compressed to begin with? Compressing and then encrypting is dangerous in a partially chosen plaintext environment like HTTPS (and Nokia is probably putting their customers at risk by doing it). The threat is as follows: Threat model: Alice is a user on bob.com. Alice also occasionally visits HTTP websites. Eve wants to obtain Alice's bob.com cookie to gain unauthorised access to bob.com. Eve has full access to the network connection between Alice and Bob.com, and can add, delete, or modify packets as desired. Browser software: HTTPS requests modelled as encrypt(gzip(knownText1 + queryParameters + knownText2 + secretCookie + knownText3)). By injecting a Javascript file controlled by Eve into a normal HTTP transaction, Eve can initiate HTTPS requests to bob.com using XMLHttpRequest where Eve knows the content of knownText* and fully controls the content of queryParameters. If queryParameters contains a substring also found in secretCookie, then the overall length of the ciphertext will be shorter due to the fact that repeated substrings are compressed. When Eve confirms an initial substring of secretCookie by monitoring the length of ciphertext corresponding to a chosen queryParameters, Eve can then expand that substring in queryParameters iteratively to a longer substring until Eve has determined the entire value of secretCookie, completing the attack.
- brazzy 14y agoNo, this is more like a thin client for devices that are too weak to actually run a browser. The device doesn't even render anything, it just receives pre-rendered pages from the server. Should be obvious that it has to decrypt HTTPS to work with it at all.