Re: How to download over https
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 <debian-cd@lists.debian.org>), 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|
Reply to: