SoylentNews is people
SoylentNews
from the when-does-a-video-stream-become-a-river? dept.
Ars Technica reports that Netflix is about to encrypt all its video streams with HTTPS. The feature will be rolled out in the coming year. This comes after one failed attempt six months ago.
Netflix's entry into the HTTPS party comes as privacy and security advocates are calling on all websites to encrypt all their traffic. The rationale behind the request is that continuous and complete HTTPS protection thwarts state-sponsored attacks that countries like the US and China launch from the Internet backbone. Web encryption is also useful against man-in-the-middle attacks that hijack huge chunks of Internet traffic. In both cases, HTTPS prevents the attacker from surreptitiously injecting malicious packets into the targeted data stream.
According to El Reg, this change will increase costs considerably for Netflix:
Netflix has battled with the overheads HTTPS incurs; Watson estimated a capacity hit between 30 to 53 percent thanks to encryption computational overheads and a lack of optimisations to avoid data copies to and from user space.
Such a hit would cost Netflix potentially hundreds of millions of dollars a year.
Tweaks could cut that overhead by a third while speculative advancements in the next several years could crush it by up to 80 percent.
Do we really need encrypted video streams?
(Score: 4, Informative) by VortexCortex on Sunday April 19 2015, @08:05PM
A video (and most other content) can be identified even while encrypted by the traffic signature it generates, the size of the download alone is enough to identify most videos when cross referenced with the availability / popularity matrix. As is common knowledge round these parts, the PKI Certificate Authority system is completely broken. Any CA can be compelled to generate a false cert for use by state actors, and furthermore, the security of the OSs that generate the certs are laughably insecure. Yes even GNU+Linux or BSD boxen have exploits that any skiddie with ~US$3k can purchase on the exploit market and they come pre-configured to deploy via popular exploit toolkits. This is how the NSA gets its exploits too. [theatlantic.com] Furthermore, today's SSL means that 3rd party collocation servers must be trusted to provide the "secure" handshake because encryption must be applied atop content at the point of delivery from the cache -- It's not like Netflix will be hosting all the content in house and applying the TLS on their systems prior to transit -- Current Crypto doesn't work that way, but a custom cipher could pre-authenticate a signed stream of data and allow caches to transmit that, but that's not "SSL" or "HTTPS".
What is needed is authentication to ensure no one has injected malicious exploits into the video stream that target the video app or codex. The problem is that SSL doesn't work well with caching; Thus, invoking ye ol' Mixed Content warning (secured page/app/metadata requesting unsecured assets/content). One solution is to digitally sign the content. I have long proposed a modification to HTML to allow secured pages to provide an attribute for Hashed Message Authentication Codes. The secured page would have something like:
<img src="..." key="YW9ldXN0bmgK" hmac="SHA-512;Base64=OGEwYTY1MDliOTYyNDM2N2EwMjU1ODViZTc1MTc1NmMyMDk1YWYzYgo=">
The browser user agent / application can then pull in the secured (uncatchable) page and then verify additional unsecured content has not been tampered with by testing: Hash[type].HMAC( key, src_data ) == hmac;
However current methods of signing require the entire video/content stream to be fed to the hashing system. Authenticated Encryption is the new hotness in cryptography which crypto folk are competing for standardization of. Authenticated encryption systems provide tamper proof encryption; Traditional stream ciphers are weak against tampering of blocks such that when the modified stream is decrypted you get "gibberish" in the modified bytes and they are then treated as valid bytes. This is a problem due to Chosen plaintext attacks and other forms of cryptanalysis. Say we know there's an exploit where a frame byte-length is a signed value but not expected to become negative. We only need to flip one bit of the length value to generate a negative value. This often allows one to overwrite memory structures with the payload data. If we know what the video is, then we can select the frames that happens to have the bytes that match some opcode we want positioned in memory and flip the bits of the TLS stream required to perform exploit. Authenticated Encryption prevents such attack by ensuring that the data sent was the data received.
However, most authenticated encryption schemes still have the property that the entire encrypted content must be fed through prior to authentication. A work around is to break the data into smaller chunks which are then authenticated individually. Rekeying the cipher of most authenticated encryption suites is a significant performance penalty. Long before mainstream crypto academics were aware of or working to solve this problem I came up with a simple solution: Use a hashing algorithm as the cipher. A random initialization vector precedes the cipher stream (possibly signed, or transmitted via public key crypto). This I.V. is HMAC'd with a key and key stretched to generate the passphrase. The first block of data is enciphered using HMAC( key, IV ) as the passphrase. The plaintext of Block0 is fed into a clone of the hashing function that was created prior to finalizing the hash. Then the next HMAC is computed, HMAC(key, IV + Block0), where "+" indicates concatenation, and this output is used to encipher Block1. Block2 is enciphered with HMAC( key, IV + Block0 + Block1 ), and so on.
This is a form of cipher block chaining which requires all prior blocks to be unmodified or the result is complete gibberish. Although each block is HMAC'd with all prior blocks, the cloning of the hash data structure avoids having to re-hash every prior block each time, so it runs in O(1) constant time. When decrypting, each prior decrypted block's plaintext must remain unaltered or the invalid HMAC will not work. This alone doesn't create the authenticated encryption. One more modification does: Each N blocks of data (prearranged via protocol) include a hash of the HMAC that is expected for the next block in the series (auth_bits). The decrypting end can then verify that the entire series of blocks up to that point matches HASH( HMAC( key, IV + Block0 ... BlockN ) ) == auth_bits, and the auth_bits are not included in the decrypted data stream (they're ignored as auth overhead). This allows the stream to be authenticated every n blockbytes with very little overhead (one extra hash finalization round).
I built a flexible cypher system that utilizes only the HMAC (and stretching of it via hashing it again) to XOR, roll and mix bits as block-cipher. This turns a single "one-way" hash into a two way authenticated cipher and can be upgraded by dropping in any hashing algorithm. My first version used MD4, but I have dropped in all the hashes up to the current SHA3 family to "upgrade" the cipher over the years. The new authenticated encryption systems are still trying to solve the problem without including overhead (or with as little as possible), but the per-authenticated segment overhead is fundamentally unavoidable if strong authentication is desired. 8 to 16 bytes overhead per ~8k seems more than acceptable overhead to me, even when ciphering file system data blocks. My crypto system can also be used with a no-op cipher to provide authenticated and non-encrypted blocks, such that the per-connection HMAC stream can be transmitted in parallel to play well with caching systems while allowing the stream to be authenticated in chunks (prior to sending them into a most likely vulnerable codec).
Modern encryption suites are not well suited to todays demands for authenticated data streams. The "common wisdom" of "don't roll your own cipher" merely creates a single point of failure in adoption of standardized crypto suites. Don't roll your own if you're not a cryptographer, otherwise constructing ciphers for your applications from tested crypto primitives is the way to go, especially if you don't want to have to trust the horribly broken CA system. I deploy secure pages with JS on them which can perform authentication of external resources (fetched by XMLHTTPRequest so I can get at them before the browser's image/audio/video codecs do). That means I can deploy my systems right now without waiting on design-by-committee bureaucracy of a "Standard Committee" (an oxymoron). Also, be sure to notify the authorities (NSA and BIS if you're a USA-ian) of the source code prior to publishing your open source crypto systems such that they can be accessed internationally; In the US, You may be exempted from notification and source publication if the ciphers are only used for user authentication and/or content protection as long as your product does not permit "general purpose" encryption. Running afoul of export restrictions is enough to scare most projects into not creating new crypto, thus making the single points of failure that much more valuable. Consider the manpower to analyze and design a custom crack for your custom encryption a great boon to your security, even if it's weaker cryptographically than industry standards. The more ciphers we create, the less popular each is and thus less likely they'll have a crack for the one you're using -- besides, it keeps some spooks employed trying to keep up with us.
The mixed content / caching issue can be solved if the presentation layer (HTML on the web) is not forced to remain ignorant of the security layer. Already the HTTP layer is aware of the security layer, see also the "secure" cookie parameter that only transmits a cookie if HTTPS is present. The HTML key/salt + HMAC properties could likewise exist in the HTTP layer, but this would mean slower adoption since servers upgrade slower than web site code and browser features.
TL;DR: The primary TLS bottleneck is in the public key crypto "authenticated" key exchange. Encryption of video and images isn't very valuable, what we need is authenticated data; And we can get that a number of ways via simple modification to clients (include a stream of HMACs). The future will be authenticated encryption, but I can assure you it will be implemented in a broken and retarding manner, just like all web security to date (see: multiple SSL protocol (re)negotiation hacks where a MITM simply tells one end to use a weaker/broken cipher). If your new stream cipher doesn't have built in cheap in-stream rekeying, then you're doing it wrong.
(Score: 0) by Anonymous Coward on Sunday April 19 2015, @11:48PM
> A video (and most other content) can be identified even while encrypted by the traffic signature it generates
One pause/rewind/fastforward and that's out.
> Any CA can be compelled to generate a false cert for use by state actors,
State actors aren't the threat in this scenario. It is your ISP and anyone operating the intermediary hops.
(Score: 2) by Yog-Yogguth on Tuesday April 21 2015, @03:39AM
Have a listen to the great audio an AC posted [soylentnews.org]. They're not mixing objects. Lots of detail in the audio (and more to come in a year: papers) that would interest you (too much work to transcribe and the questions are intelligible to me).
Bite harder Ouroboros, bite! tails.boum.org/ linux USB CD secure desktop IRC *crypt tor (not endorsements (XKeyScore))