4 ms·

This seems to make two wrong assumptions: 1. HTTPS does not only guarantee that data is secret, it also guarantees that data is not manipulated. And in this se

by hannob 12y ago

This seems to make two wrong assumptions: 1. HTTPS does not only guarantee that data is secret, it also guarantees that data is not manipulated. And in this sense scientific data is very sensitive - it matters that you know your data is the correct data. 2. As so many do, it vastly exaggerates the performance costs of HTTPS. They are really minimal. If you really care I suggest you benchmark before you make any claims regarding your servers can't handle it.

dijit 12y ago
Your second point is valid only for x86 machines (and modern ones). AES instruction sets implemented in hardware are the main factor in making HTTPS viable. But my toaster (which speaks HTTP), or my ARM based router, or even my high end server iDRAC/iLO does not have a dedicated x86 or AES hardware instruction. so the point stands, even if it's not relevant to modern laptop users.
- icebraining 12y ago
  ARMv8 comes with the AES instruction set as well, and Linux supports it. The newer Android phones like the Nexus 9 are already using it.
- xenophonf 12y ago
  Of all the things that should be using strong encryption by default, router and server management interfaces are at the top of that list. Those interfaces _do not_ have the kinds of high-performance transfer requirements like that of bulk data transfers or streaming video services. As for bulk data transfers for government-funded scientific research, data integrity for anything having to do with clinical trials or personally-identifiable information is among my highest concerns. And unless we're pumping that data across private fiber, the latency and bandwidth limits of the global Internet far outweigh the overhead caused by encryption/authentication algorithms. (I would add that I think bulk data transfers ought to be encrypted over private/internal networks as well, but that's an argument for when I'm not on mobile.)
- thoughtpolice 12y ago
  This point is important, because there is a lot more non-AESNI hardware than the converse. But luckily, it's possible (and likely, I hope) that TLS 1.3 will include the ChaCha20-Poly1305 AEAD ciphersuite, which should improve this matter quite a bit for most users who need software implementations - it's _much_ simpler to implement, and even in software, a heavily optimized can get within the ballpark of AESNI. Google is already using ChaCha20-Poly1305 inside Chrome to talk to Google servers, if your hardware doesn't support AESNI. It's been doing this since early last year, and Adam reported at that time nearly 40% of all traffic to Google was going through it (including mobile devices IIRC): https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto...
  - qrmn 12y ago
    It won't just include it, at this stage it seems set to become mandatory-to-implement (not necessarily mandatory to deploy). We'll see.
- Dylan16807 12y ago
  > AES instruction sets implemented in hardware are the main factor in making HTTPS viable. Not true. It's something like 30-40 cycles per byte to do AES without specialized instructions. That makes saturating 100mbit trivial, and saturating gigabit one of the easier problems. How much traffic can your toaster and router possibly be terminating?
  - thoughtpolice 12y ago
    Power usage is very important for low-end devices, especially smartphones which will be talking to lots of HTTPS resources. This is the complaint on the other side of the pond, away from the people who need ASIC accelerators for whatever reason to keep up with bandwidth/latency/cpu concerns. Just as an example of the difference - I wrote a naive implementation of ChaCha20 in C with zero optimization effort and it does 5cpb out of the gate (Sandy Bridge). Just using vector-types and letting GCC/Clang vectorize brings that down to ~3cpb on Sandy Bridge - no effort. The Krovetz implementation of ChaCha20 is closer to 1.2cpb on my machine, with AES-256 doing 1.0cpb using AESNI (again, my own naive implementation). All software. Even the most hand optimized, secure AES software implementations are still in the realm of ~15-20cpb (IIRC), three-to-four times worse than the unoptimized competitor. As linked elsewhere in this thread by me, non-scientific tests show it 3x faster in software on some mobile phones. That's a lot of extra cycles-per-byte for your battery to chew through using AES-256, and I'd guess I easily churn through a low number of gigs of HTTPS data every month..
    - Dylan16807 12y ago
      I'm not sure about phones. Active cellular data demolishes my battery; I don't think the extra CPU use would matter terribly much. And let's say you use 6-8GB of HTTPS data. 3 minutes of full use of a single 1GHz core per month is not a lot of battery.
daphreak 12y ago
Could you not solve 1 by having an HTTPS index page with content hashes?
- meric 12y ago
  If they can modify the content on a website, they can modify the content hashes on the index page. I suppose you could put the content hashes on an https page...
  - fluidcruft 12y ago
    >> Could you not solve 1 by having an HTTPS index page with content hashes? > I suppose you could put the content hashes on an https page... Aren't these the same thing?
    - meric 12y ago
      Yes, I meant using https for a subsection instead of the entire page as a solution, my comment reluctantly recognising the parents solution as valid.
  - deleted 12y ago
    [deleted]
  - mcguire 12y ago
    If they can modify the content on a web site, they can modify the data hosted on the site, in place.

by hannob 12y ago

dijit 12y ago

Your second point is valid only for x86 machines (and modern ones). AES instruction sets implemented in hardware are the main factor in making HTTPS viable. But my toaster (which speaks HTTP), or my ARM based router, or even my high end server iDRAC/iLO does not have a dedicated x86 or AES hardware instruction. so the point stands, even if it's not relevant to modern laptop users.

icebraining 12y ago
ARMv8 comes with the AES instruction set as well, and Linux supports it. The newer Android phones like the Nexus 9 are already using it.
xenophonf 12y ago
Of all the things that should be using strong encryption by default, router and server management interfaces are at the top of that list. Those interfaces _do not_ have the kinds of high-performance transfer requirements like that of bulk data transfers or streaming video services. As for bulk data transfers for government-funded scientific research, data integrity for anything having to do with clinical trials or personally-identifiable information is among my highest concerns. And unless we're pumping that data across private fiber, the latency and bandwidth limits of the global Internet far outweigh the overhead caused by encryption/authentication algorithms. (I would add that I think bulk data transfers ought to be encrypted over private/internal networks as well, but that's an argument for when I'm not on mobile.)
thoughtpolice 12y ago
This point is important, because there is a lot more non-AESNI hardware than the converse. But luckily, it's possible (and likely, I hope) that TLS 1.3 will include the ChaCha20-Poly1305 AEAD ciphersuite, which should improve this matter quite a bit for most users who need software implementations - it's _much_ simpler to implement, and even in software, a heavily optimized can get within the ballpark of AESNI. Google is already using ChaCha20-Poly1305 inside Chrome to talk to Google servers, if your hardware doesn't support AESNI. It's been doing this since early last year, and Adam reported at that time nearly 40% of all traffic to Google was going through it (including mobile devices IIRC): https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto...
- qrmn 12y ago
  It won't just include it, at this stage it seems set to become mandatory-to-implement (not necessarily mandatory to deploy). We'll see.
Dylan16807 12y ago
> AES instruction sets implemented in hardware are the main factor in making HTTPS viable. Not true. It's something like 30-40 cycles per byte to do AES without specialized instructions. That makes saturating 100mbit trivial, and saturating gigabit one of the easier problems. How much traffic can your toaster and router possibly be terminating?
- thoughtpolice 12y ago
  Power usage is very important for low-end devices, especially smartphones which will be talking to lots of HTTPS resources. This is the complaint on the other side of the pond, away from the people who need ASIC accelerators for whatever reason to keep up with bandwidth/latency/cpu concerns. Just as an example of the difference - I wrote a naive implementation of ChaCha20 in C with zero optimization effort and it does 5cpb out of the gate (Sandy Bridge). Just using vector-types and letting GCC/Clang vectorize brings that down to ~3cpb on Sandy Bridge - no effort. The Krovetz implementation of ChaCha20 is closer to 1.2cpb on my machine, with AES-256 doing 1.0cpb using AESNI (again, my own naive implementation). All software. Even the most hand optimized, secure AES software implementations are still in the realm of ~15-20cpb (IIRC), three-to-four times worse than the unoptimized competitor. As linked elsewhere in this thread by me, non-scientific tests show it 3x faster in software on some mobile phones. That's a lot of extra cycles-per-byte for your battery to chew through using AES-256, and I'd guess I easily churn through a low number of gigs of HTTPS data every month..
  - Dylan16807 12y ago
    I'm not sure about phones. Active cellular data demolishes my battery; I don't think the extra CPU use would matter terribly much. And let's say you use 6-8GB of HTTPS data. 3 minutes of full use of a single 1GHz core per month is not a lot of battery.

daphreak 12y ago

Could you not solve 1 by having an HTTPS index page with content hashes?

meric 12y ago
If they can modify the content on a website, they can modify the content hashes on the index page. I suppose you could put the content hashes on an https page...
- fluidcruft 12y ago
  >> Could you not solve 1 by having an HTTPS index page with content hashes? > I suppose you could put the content hashes on an https page... Aren't these the same thing?
  - meric 12y ago
    Yes, I meant using https for a subsection instead of the entire page as a solution, my comment reluctantly recognising the parents solution as valid.
- deleted 12y ago
  [deleted]
- mcguire 12y ago
  If they can modify the content on a web site, they can modify the data hosted on the site, in place.