The only user agent SSL Labs reports as supporting null ciphers is Safari 6/iOS6. https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&...
But the server side, which is serving thousands or tens of thousands of these 10Mb/s connections, is a bit more challenging.
For high-bandwidth CDN applications (like Netflix, Youtube, etc), the drawback to SSL encryption is indeed due to the bulk data encryption. The penalty is twofold. First, the need to encrypt the data requires that the CPU have access to it. Even discounting the costs of computation, the need to touch the data removes a lot of benefits of sendfile / splice / etc. There is an interesting Netflix paper about this: https://people.freebsd.org/~rrs/asiabsd_2015_tls.pdf
Due to the nature of SSL, applying hardware offload solutions is problematic. The most efficient hardware offload would be a PCIe card that does encryption AND TCP offload. But then you're dealing with TCP offload, which is seldom a good idea. If you use an encyption-only hardware solution like the Intel QuickAssist cards, then you wind up in danger of running out of PCIe lanes. Eg, to serve at 100Gb/s per CPU socket, you need 16 PCIe Gen3 lanes for network, 16 PCIe Gen3 lanes for storage, and 16 PCIe Gen3 lanes for Quick Assist. So you're up to 48 lanes, but a Xeon e5-xxx v3 CPU has a max of 40 lanes.
You would also introduce a significant risk. How would you communicate your "authenticated, but not encrypted" connection? Looks like HTTPS? Like HTTP? Something new? Confusion for the user (who doesn't know the finer details between authenticity and secrecy) is guaranteed.
In the end you'd introduce a less secure variant of HTTPS without any significant advantage. And you add complexity and the risk that it gets used in situations where secrecy matters, but the people responsible didn't properly think about it. Doesn't sound like a good idea to me.
Wonder why you through in the "in general" caveat in there? Is it because HTTPS 4 way handshake (2 full roundtrips) is actually an enormous hit on performance on high latency networks. And what are these high latency networks? Mobile networks of course.> Works across sites and lets you authenticate resources you don't own.
https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
It's useful for increasing the status quo on HTTP pages, or for defense-in-depth on HTTPS pages, but it doesn't actually enable you to do anything you couldn't before.
Consider, for example, a Chinese computer connecting to Wikipedia over HTTPS, which then downloads an image over HTTP without S that is clearly related to the Tiananmen massacre.
On the other hand, it complicates things a lot without really giving much advantages. The only time I can think of where it might be useful is for using CDNs from a HTTPS site, without having to set up HTTPS with your CDN.
Sure, HTTPS protects against tampering, but its not the only way. The parent comment seemed interested in ways of solving the same problem without the CPU overhead of encryption (whether this is a valid concern or not is a separate question).
In fact, hashes offer superior protection when loading resources via a CDN since you don't need to trust that the CDN won't tamper with things.
> With your suggestion of hashes + HTTP, if it is tampered with, the page silently won't work as intended.
Why? This would require browser support and it could whine about mismatched hashes as much as it wants.
---
I'm not seriously proposing that we should do this, but I find it interesting to think about the different ways that things can be done.
A lot of HTTPS's value comes from authentication, not encryption. Has anyone investigated using something like the TLS_RSA_WITH_NULL_SHA cipher suite for HTTPS, to provide auth and integrity without the computational cost of symmetric encryption? Would that even provide a meaningful performance benefit?
I'm guessing that it's disabled by default in most browsers, and figuring out a sane user experience to allow users to differentiate between encrypted and non-encrypted secure traffic seems like a very hard problem.