Pascal Hambourg wrote: > Le 16/06/2016 18:18, Dan Purgert a écrit : > 1) >> So, the fact that HTTPS doesn't ~actually~ provide you with any security >> when a "malicious party" has root accesss to the webserver, > > >> AND that it >> adds overhead to the transmission > > Does it really add network overhead of just CPU overhead on the server ?
CPU on both ends, as well as making the overall amount of data transmitted somewhat larger. This is because encrypted blocks have specific size requirements (if you're familiar with base-64 encoding, that's why the data usually ends with '==' -- it's an indicator that the encoding process ran out of data before the block was full, and is padding it out). Remeber that a single packet can only carry 1460 bytes, before accounting for services that specify MTUs <1500 . If you're using something like 64-byte blocks for the encryption scheme (which is fairly common, so I'm going with that from here on out), you're limited to only sending 1408 bytes / packet of actual data, assuming zero overhead. For the 660 602 880 bytes of "cd1" from the debian installer suite, this means you're transmitting 469,178 fully loaded packets, plus 1 partial (approx 315 bytes) ... or a total transmission of 689 691 975 bytes. For plain HTTP with 1460-byte payloads, it's only 452,467 full packets, plus 1 partial (approx 1100 bytes) ... or a total transmission of 678 701 600 bytes. Sure, a savings 10 MB is only 1.6% of the original image size - but then you need to look at how many copies of the CD are downloaded (I don't know that). Works out to every 63rd download creates enough overhead that you've effectively transmitted another full image in overhead alone. > > 2) >> Given that "debian" is the "well-trusted" party in this instance, their >> providing of both >> >> - their public signing key, AND >> - the *.iso MD5 and/or SHA checksum(s) >> >> on a HTTPS-secured webpage will suffice the conditions of "creating >> trust" for most people. > > 1) and 2) sound contradictory to me. I apologize, as a phone call distracted me, and I inadvertantly missed this during editing. It should read as follows: ===================== Given that "Debian" is a well-trusted party (insofar as distributing 'debian installation cds'), the fact that they provide both: - their public signing key (signed by 33 other individuals), AND - various signed checksum lists (MD5 / SHA1 / SHA2 / etc.) out-of-band to the CD images themselves (i.e. it's not a tarball containing all three pieces of information) creates conditions that suffice as "trustworthy" for the case of ensuring the CD image you get isn the one you were intended to get by the Debian team. ===================== Remember too, that the TLS certificate is ONLY providing verification the server is who it says it is (e.g. "www.example.com"), and encrypting the session. It does nothing to prove that the data contained on a mirror is the data that the upstream party intended you to get. So if a mirror was providing a broken CD image (either due to a technical error, or operator malice), even having it provide that image over HTTPS would not 'protect' you from burning that invalid image to a CD, and then having a bad night when it fails install 98% of the way through. And that's not even considering an error at your end. So, that's where the checksums come in. You WILL NOT get the same checksum if your newly downloaded image was corrupted in transit (or was no good at the remote end in the first place). Now, since people have expressed concerns over ensuring the validity of the checksums themselves, they get signed with the Debian CD signing key (Debian CD signing key <[email protected]>), of which the public key is signed by no fewer than 30 people. And, because the only way to get a valid signature from that private key is to have access to that private key (and its passphrase), someone downloading the files can then verify the checksum file is signed by the right party (i.e. "Debian"), and then they can compare the checksum of the downloaded CD image against the now known-good checksums. If the iso checksum matches the checksum in the list, the iso image is now known-good (and one can proceed to using it for installation). -- |_|O|_| Registered Linux user #585947 |_|_|O| Github: https://github.com/dpurgert |O|O|O|
