tinycorelinux.net does not support SSL, Chrome blocks downloads

[ovacikar]

Hello

Google Chrome is blocking downloads from tinycorelinux.net web site, for being insecure.If it was due to high cost of SSL Certificates in the past, letsenctypt offers free SSL certificates to my knowledge.

[patrikg]

You can bypass that using key Keep.

[curaga]

This is ridiculous. SSL does not any way mean a download is secure...

[Rich]

Hi curaga
Sounds like poor wording. It's probably objecting because
the link on the Downloads page points to the repo which
needs to be http.

[andyj]

This is ridiculous. SSL does not any way mean a download is secure...

Just another part of security theater.

[CentralWare]

"Secure" has numerous definitions based on who you ask.

SSL simply encrypts data between two (or more) points - there have been US presidential candidates (no names need be mentioned ) who somehow thought just because something says SSL is SECURE doesn't mean the press isn't going to have a field day with your emails!

Encrypting publicly available downloads --- it's a pure WASTE of BANDWIDTH as SSL just adds fat to the download since the file itself is public domain.  It's not a "secret!"
Encrypting downloads that contain personal content (ie: zip files or scanned images of your identification, banking records, etc.) WOULD be something you'd want to encrypt.

G00GLE wants to make everything online SSL-IDENTITY based when in fact, it's because of places like Let's Encrypt (free) that every crook on the planet can afford an SSL cert of their own, so what's the point of Chrome pretending there's "safe" anything   Don't get me wrong, Let's Encrypt is awesome...  but trying to force the planet into submission?  Sounds an awful lot like the Shockwave/Flash demise to me!

@Curaga: If we HAD to comply...  why not utilize mirror links which DO have SSL implemented?  (https://distro.ibiblio.org/tinycorelinux/14.x/x86_64/release/CorePure64-14.0.iso)

[gadget42]

@CentralWare, thanks for taking the time to post that since there are many who don't understand the particulars.

[Dies Irae]

While we're on this subject of secure..

What are the thoughts about adding signify, noting that there are various flavours (predominantly due to adding fields), for which we perhaps could choose OpenWRT usign (which cost them a mere 11K when installed).

Recall that the computational overhead here would be minimal, the idea is that we can cryptographically verify a small file that is basically an hash+info of the extension. Once we know the hash is good, we assume that the file matching that hash is also good. OpenBSD (whom sanely rejected the idea that https solves everything in life) proved the idea is sound and inclusive to all, OpenWRT's implementation isn't new (had eyeballs) and is invested in being small and lightweight.

The entire dance is probably even cheaper than a https handshake/exchange (and alleviates everyone from fears such as as today, while even pre-preemptively swiping pro-https arguments off some potential table). Potential match made in heaven?

[curaga]

TC is a small, volunteer-based distro. While signing extensions would help detect a rogue mirror, it would imply many other kinds of security that would only be available in larger, corporate distros.

[Dies Irae]

TC is a small, volunteer-based distro. While signing extensions would help detect a rogue mirror, it would imply many other kinds of security that would only be available in larger, corporate distros.

After giving this response considerable thought, I can't, for the life of me, come up with any other implied benefits, other than of course the purpose: that a man in the middle (like the public internet wifi access in a super market of cafe or numerous other places OR some Iranian govt (and similar)) can not trivially infect a tinycore instance, by *simply* passing it the wrong md5 and infected matching tcz extension.
For equivalent example, I also don't see any other implied security of openwrt (for example) using signify, while I assume one wouldn't run openwrt on their laptop in a cafe, like one would use your cloud-os tinycore.

What other implied security features did I not think of?

[curaga]

A signed extension implies the extension itself can be trusted. It would be trivial for a Jia Tan (see the recent xz news) to contribute a compromised extension, which would then be signed.

[Dies Irae]

Thanks for your clarification. With the utmost respect (really), I'd personally only 'trust' the signify to show that I obtained the binary that is in the repository. After all, with the same xz example, that could still have been in our repo (if someone in good faith had compiled and submitted it).
A more 'glaring' bad extension would hopefully have more eyeballs (Not only the person that somewhat skimmed what was submitted, but also the other users (by usage) of the extension).
It would only guarantee that whatever is currently in the repo, is what I got, be it good, or bad.

Who knows, a fair poll could shed some light on what 'the masses' think about the subject. You may be very right that they would mis-perceive it's purpose (what it does, and doesn't add/do).

[mrodrigues]

SSL certs are about more than just encrypting traffic. They help establish that the web server is run by the same organization who manages the DNS record. This lets you be reasonably assured your connection is not being man-in-the-middled.

This is particularly helpful when downloading an operating system, as with no HTTPS, it would be trivial to MitM and spoof the TC download site with a malicious installer.

IMO, it's pretty ridiculous that a site serving OS downloads isn't using HTTPS in the letsencrypt era.

[curaga]

Many of our mirrors offer https. If you worry about MITM, please download from those.

[nick65go]

http vs. https is just the peek of the iceberg (MITM corruption).

Looking over the process to grab a package for Alpine Linux:
Here below in the context, package/application is equivalent of Tinycore TCZ.

1. For each CPU Architecture (ex: x86_64) they have an list (index) of the programs (like TCZ) that they offer. This list/index is SHA1 signed, it means that no alien contributions/packages (similar with TCZ) could arrive on the server (with different file size, time stamp, etc). Only from verified contributors.

2. Each TCZ/package is also SHA1 signed, to check if the package was modified during download.

3. In the package, each FILE is SHA1 signed (has PAX header in TAR segments), so even if the package was correctly downloaded, it can not be inside tampered (back doors).

FYI: Other advantages:
4. There is only one version of a library. Ex: if an application depends on some *.so (ex: ABC.so.10) when ABC is updated (to ABC.so.20) then ALL appls that depends on it will be also updated/recompiled. So the will be no case that a dependency of a dependency to drag both/multiple versions of ABC.so in a dependency tree. [or to load both like in tinycore when using FlaxPdf and Xpdf].

Minimalism/simplicity is not equivalent with security, but it helps a little by reducing attack surface and the possible bugs/back-doors.