On Tue, 10 Oct 2017, Carlos Carvalho wrote:
Marcus Meissner (meissner@suse.de) wrote on Tue, Oct 10, 2017 at 09:19:08AM -03:
With the availability of letsencrypt this can even be done without any additional costs.
There's a higher overhead on the machine, so "no additional costs" is an illusion... Further, there's no security bennefit because clients are able to check for hash mismatches using the distribution keys. There's also no privacy protection because if a man-in-the-middle watches your traffic they'll discover what you pulled from the IPs and sizes of the transfers. That's why we (opensuse.c3sl.ufpr.br) are against https for mirrors.
Our experience is that for mirrors (ie, file-serving) performance is only an issue if you have very good connectivity and/or very old CPUs. As a case in point, ftp.acc.umu.se HP DL180G6 hosts had to be upgraded to 2xE5606 CPU:s (3 EUR each on ebay) in order to get first-generation TLS acceleration. With this upgrade, 10 Gbps https (AES-128-GCM) per host is achieved with lots of spare CPU cycles. Yes, we need 3-4 streams to fill up 10 Gbps but since most users are on GigE or slower in Sweden that's not a big issue... openssl speed -evp aes-128-gcm is the command you want to use to check your TLS CPU performance. Note that you really want to use the gcm cryptos, since that's where the CPU accelleration is really good. I get around 3-4 GiB/s per core on modern CPUs...
However some recent developments are reducing the https burden, notably TLS in the kernel. It's not yet finished but since not all of the distribuitions will change immediately, we can already offer https for some now. This means we can offer https for opensuse (starting next week) if you officially decide that this is your policy and request it from mirrors.
We see this as promising to solve the single-stream/core problem, in order to achieve 100 Gbps single-stream https. For multiple stream workloads there is a benefit in avoiding unnecessary memory copying (think https enabled sendfile()), but it's not really solving any hard bottlenecks for the open source mirror usecase (assuming 10 Gbps connectivity)... The situation is likely different for hosts seeing lots of connections and small transfers, but since we're not in that problem space I don't have any insights there. /Nikke -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Niklas Edmundsson, Admin @ {acc,hpc2n}.umu.se | nikke@acc.umu.se --------------------------------------------------------------------------- Water + Malt + Hops + Yeast = Satisfaction =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= -- To unsubscribe, e-mail: mirror+unsubscribe@opensuse.org To contact the owner, email: mirror+owner@opensuse.org