4 ms·

Stupid question: A lot of HTTPS's value comes from authentication, not encryption. Has anyone investigated using something like the TLS_RSA_WITH_NULL_SHA ciphe

by scarmig 11y ago

Stupid question: 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.

deleted 11y ago
[deleted]
- realityking 11y ago
  Asymetric message authentication without encryption is certainly a thing. The most common example is probably code signing as required by Windows and OS X for certain software.
jkire 11y ago
A similar idea is to allow pages to download static content over HTTP if they include the hashes of the content. Things like CSS and javascript need authentication so you know they haven't been tampered with, but don't necessarily require encryption. (The authentication here is from the fact you would download the page containing the hashes via HTTPS). Using this to download the global static content for a site doesn't even leak which individual page you were looking at. 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.
- theandrewbailey 11y ago
  If you're concerned about things getting tampered with, encryption guarantees that it won't. With your suggestion of hashes + HTTP, if it is tampered with, the page silently won't work as intended. With hashes + HTTPS, loud errors happen when things are tampered with. And because it's static content, deliver over HTTPS once and cache the hell out of it.
  - jkire 11y ago
    > If you're concerned about things getting tampered with, encryption guarantees that it won't 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.
hannob 11y ago
The performance benefit would be hardly measurable. First of all the performance impact of HTTPS in general is almost irrelevant. Second, even if you care about that irrelevant performance impact, unless you transmit really large files the biggest hit is from the asymmetric part. You'd still have that with a NULL cipher. 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.
- chetanahuja 11y ago
  "First of all the performance impact of HTTPS in general is almost irrelevant." 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.
pjc50 11y ago
I keep proposing "<a href="..." hash="sha256:abcdefg..."> as the quick, easy 80% solution to this. Works across sites and lets you authenticate resources you don't own.
- ldjb 11y ago
  This is the first I've heard of this. Is this currently in the HTML specification or in actual use, or are you proposing such functionality be added to the spec?
  - theandrewbailey 11y ago
    It's called Subresource Integrity. I just implemented it on my blog yesterday. It only works on CSS and JS, but image support is supposedly coming. I highly doubt that it would be a good idea for hyperlinks. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
    - majewsky 11y ago
      I would argue it's a bad idea for images already. Images give away a lot about the type of content that you're viewing, which is possibly sensitive information. 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.
      - theandrewbailey 11y ago
        I'm not saying that it's a replacement for HTTPS. Nothing stops you from using SRI hashes for HTTPS content. If you're concerned over censorship, you should be using HTTPS, period. SRI is more concerned about bad CDN content. Your CDN can use HTTPS, but your server's page says what the hash should be, so if your CDN goes rouge, things will start breaking.
    - geofft 11y ago
theandrewbailey 11y ago
These days, the significant performance hit of HTTPS is in the handshake and round trip times, not the symmetric encryption. Any modern CPU does AES much faster than the internet connection most people have. With CPU/hardware support, the cost is literally negligible. TLS_RSA_WITH_NULL_SHA likely would not provide any significant performance benefit, due to the handshake. The only user agent SSL Labs reports as supporting null ciphers is Safari 6/iOS6. https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=6&platform=iOS%206.0.1 https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&...
- drewg123 11y ago
  "Any modern CPU does AES much faster than the internet connection most people have" 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 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.

by scarmig 11y ago

deleted 11y ago

[deleted]

realityking 11y ago
Asymetric message authentication without encryption is certainly a thing. The most common example is probably code signing as required by Windows and OS X for certain software.

jkire 11y ago

A similar idea is to allow pages to download static content over HTTP if they include the hashes of the content. Things like CSS and javascript need authentication so you know they haven't been tampered with, but don't necessarily require encryption. (The authentication here is from the fact you would download the page containing the hashes via HTTPS). Using this to download the global static content for a site doesn't even leak which individual page you were looking at. 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.

theandrewbailey 11y ago
If you're concerned about things getting tampered with, encryption guarantees that it won't. With your suggestion of hashes + HTTP, if it is tampered with, the page silently won't work as intended. With hashes + HTTPS, loud errors happen when things are tampered with. And because it's static content, deliver over HTTPS once and cache the hell out of it.
- jkire 11y ago
  > If you're concerned about things getting tampered with, encryption guarantees that it won't 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.

hannob 11y ago

The performance benefit would be hardly measurable. First of all the performance impact of HTTPS in general is almost irrelevant. Second, even if you care about that irrelevant performance impact, unless you transmit really large files the biggest hit is from the asymmetric part. You'd still have that with a NULL cipher. 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.

chetanahuja 11y ago
"First of all the performance impact of HTTPS in general is almost irrelevant." 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.

pjc50 11y ago

I keep proposing "<a href="..." hash="sha256:abcdefg..."> as the quick, easy 80% solution to this. Works across sites and lets you authenticate resources you don't own.

ldjb 11y ago
This is the first I've heard of this. Is this currently in the HTML specification or in actual use, or are you proposing such functionality be added to the spec?
- theandrewbailey 11y ago
  It's called Subresource Integrity. I just implemented it on my blog yesterday. It only works on CSS and JS, but image support is supposedly coming. I highly doubt that it would be a good idea for hyperlinks. https://developer.mozilla.org/en-US/docs/Web/Security/Subresource_Integrity https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
  - majewsky 11y ago
    I would argue it's a bad idea for images already. Images give away a lot about the type of content that you're viewing, which is possibly sensitive information. 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.
    - theandrewbailey 11y ago
      I'm not saying that it's a replacement for HTTPS. Nothing stops you from using SRI hashes for HTTPS content. If you're concerned over censorship, you should be using HTTPS, period. SRI is more concerned about bad CDN content. Your CDN can use HTTPS, but your server's page says what the hash should be, so if your CDN goes rouge, things will start breaking.
  - geofft 11y ago

theandrewbailey 11y ago

These days, the significant performance hit of HTTPS is in the handshake and round trip times, not the symmetric encryption. Any modern CPU does AES much faster than the internet connection most people have. With CPU/hardware support, the cost is literally negligible. TLS_RSA_WITH_NULL_SHA likely would not provide any significant performance benefit, due to the handshake. The only user agent SSL Labs reports as supporting null ciphers is Safari 6/iOS6. https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&version=6&platform=iOS%206.0.1 https://www.ssllabs.com/ssltest/viewClient.html?name=Safari&...

drewg123 11y ago
"Any modern CPU does AES much faster than the internet connection most people have" 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 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.