Jörg-Volker Peetz:
> Jörg-Volker Peetz wrote on 06/16/16 15:12:
>> Did you take a look here: https://www.debian.org/CD/verify , "Verifying
>> authenticity of Debian CDs"?
>>
>> The https protocol would add quite some overhead to the download of the
>> iso-files which are already big by them self.
>>
> This statement has to be corrected: the overhead of https is hardly perceptible
> on "modern" hardware. (See, e.g.,
> https://www.keycdn.com/blog/https-performance-overhead/ ,
> https://www.imperialviolet.org/2010/06/25/overclocking-ssl.html )
It really depends on what you are looking at. Clients have no reason to
care about that but if you are running a busy site that's a whole
different issue.
The first link of yours doesn't really discuss the server-side
implications. The second one is from 2010 and talks about how Google
prefers RC4 for its speed but RC4 is almost completely dead today (see
RfC 7465). Incidentally, Google switched off RC4 for Gmail just
yesterday:
http://news.softpedia.com/news/google-drops-sslv3-and-rc4-support-in-gmail-504176.shtml
Admittedly, one of the main issues with HTTPS is the number of
handshakes your hardware can do per second. That probably isn't a
problem for the CD image download server that we are discussing here.
But for (non-distributed) sites that serve a huge number of requests
(think tens of thousands of requests per second) and (unlike Google) use
off-the-shelf hardware and software that's a different issue. I am
working on such a site and our customer has to spend big bucks for our
load balancers (F5 BIG IP) which terminate SSL connections in our
environment.
J.
--
In this bunker there are women and children. There are no weapons.
[Agree] [Disagree]
<http://archive.slowlydownward.com/NODATA/data_enter2.html>
Attachment:
signature.asc
Description: Digital signature