[sf-lug] https - "improves"(?) security?

[Michael Paoli]

> From: "Rick Moen" <rick at linuxmafia.com>
> Subject: Re: [sf-lug] Linux Mint iso files hacked.
> Date: Mon, 22 Feb 2016 00:12:51 -0800

> Quoting Michael Paoli (Michael.Paoli at cal.berkeley.edu):
>
>> And ... https?  Yes, wouldn't have done anything for *this* particular
>> issue, but does generally thwart *other* problems.
>
> Out of curiosity, what specific use-case (applies to this particular
> example)?
>
> On many Web sites, encrypted transport buys little for lack of need for
> confidentiality, and authentication is either relatively unimportant or
> is better achieved in other ways for relevant content (e.g., gpg-signed
> checksums for ISOs).

Use of https just raises the bar, at least somewhat, on security.  And
yes, various degrees of mishandling by various CAs, and their
relatively limited thoroughness in checking, and their own security,
etc. - https in general, yes, far from perfect.  But it does add at
least an additional (partial) layer of protection.

E.g. it makes man-in-the-middle attacks more difficult.  This could
also have side benefits of making it less probable that, e.g. mirrors,
would pick up and display invalid (e.g. "hacked") data/information
and/or that users would get or download "hacked" or tampered with data.
With lack of signed data, and lack of https, there's no assurances
that recipient gets data that's not been tampered with.  Adding https,
well, there's at least some modest bit of improvement on reducing the
probability that the data was altered between site and recipient - but
of course, and certainly by itself, it's no panacea.

Also, these days, pretty easy - and *free*! - to do https.  Really not
much reason to not do - or at least also include use of - https.  E.g.
letsencrypt.org makes free certs available to all (and yes, I'm using
such on most or all the SF-LUG stuff - at least make it available, and
a fair bit of the BALUG stuff too - alas, can't add it to DreamHost.com
hosted stuff for free - even if one has obtained relevant cert).

Though, in many cases, https adds little to nothing.  E.g. if I have
signature data for an ISO, and have only options to download of https
or http, I might go with http, as https only adds a bit more overhead
to client and server in downloading, and I'd be checking against
signature data anyway.  On the other hand, if the site puts up hashes
of ISOs on their website, but doesn't bother to sign the ISOs, I'm not
going to particularly trust those hashes if they're only offered via
http, whereas if they're offered via https ... well, a modicum of trust
above http only.