Linux security

>>58895966
>So every package update gets downloaded via unsecured network?
Depends on your distro. All the competent ones at least sign updates so that you can be sure they haven't been tampered with. I believe most have a way to force TLS downloads too, at least for some mirrors.

so in other words, you're full of crap.

>>58895966
I know it's a trol but
>what is apt-transport-https
>what are digitally signed packages

>>58896021
Is Ubuntu competent?

>>58896032
FYI, for non-autists those things are unfamiliar.

File: 1486506712226.jpg (43KB, 480x451px) Image search: [Google]

43KB, 480x451px

> Ubuntu general

So should one download new packages through a shitty compromised network?

Are these secure means you're referring to enabled by default on popular distros?

>>58896151
Yes. It has signed packages and https mirrors.

>>58896287
Pretty much all of them.

>>58896302
I checked my /etc/apt/sources.list and everything is just simple http without s.

Hell, even security.ubuntu.com doesn't support https!

>>58896381
Change your mirror.

>>58896390
You are supposed to use http://security.ubuntu.com/ubuntu for urgent security updates, no? It clearly doesn't support https.

Does Debian's security update server support https?

>>58896413
Same deal. The default one doesn't, but you can change it to one that does.

>>58895966
checksum

>>58896381
>>58896390
>>58896413
>>58896470
HTTP mirrors are totally fine for signed packages, you know. It doesn't matter what the transport is, signed packages ensure that you can only get updates from your distro maintainters.

>>58895966
Actually, OP, I remember when people made fun of Arch Linux on /g/ because it didn't provide signed packages. Updates over HTTP with unsigned packages are a pretty solid indication of a amateur distro.

>>58896573
>signed packages ensure that you can only get updates from your distro maintainters.
How does that work if you connect to everything via simple http?

>>58896573
>>HTTP mirrors are totally fine for signed packages, you know. It doesn't matter what the transport is, signed packages ensure that you can only get updates from your distro maintainters.
Well integrity isn't the only goal here. We also want to make it more difficult for three-letter agencies to see what we're doing.

If you search for instructions on enabling TLS for package updates you'll see a bunch of people saying "Ah, it doesn't matter, they can tell what you're downloading anyway by looking at filesizes and crap". Which misses the point, doing updates over TLS turns something that's easy to eavesdrop on reliably into something that you might be able to eavesdrop on, if you go to the effort to keep track of what package updates are coming out, how big they are, and such. And there's still an element of unreliability to that. You've made life that much harder for the spooks.

You're also engaging in good internet hygiene. We want encrypted traffic to be the norm on the web, even for things that don't strictly "need" it. If everyone does it, the applications that really do need it don't stand out and are better protected.

>>58896579
It's basic public-key cryptography. The package maintainer signs the package with their private key so that anyone can use their public key to verify that the package is from them and that it hasn't been tampered with. It doesn't matter how you received the package or if the medium you received it over is untrustworthy, public-key cryptography proves the package's authenticity. If you use a distro that has package signing, your package manager will maintain a list of public keys that it trusts, and it will refuse to update a package if it hasn't been signed by a trusted key.

>>58896620
Agreed 100%, though the OP just seemed concerned with malicious package updates. It's important to clarify that regardless of whether HTTP or HTTPS is used, for distros with package signing, the integrity and authenticity of the packages is not a concern.

how the fuck are ubuntu and debian not encrypted by default?:(

it's 2017 ffs

>>58895966

They're signed and cannot be modified without breaking it.

>>58896151

apt uses signed packages.

>>58896381

HTTPS is not needed to protect you with key signing.

>>58896620
>Well integrity isn't the only goal here. We also want to make it more difficult for three-letter agencies to see what we're doing.

Then SSL isn't going to help you. You can't trust the various CAs to not hand over their root key. The three-letter agencies can easily perform a MITM on you if they have the CA's root keys.

SSL IS supported, but it's unlikely to actually protect you from the NSA.

>>58896679
>>Then SSL isn't going to help you. You can't trust the various CAs to not hand over their root key. The three-letter agencies can easily perform a MITM on you if they have the CA's root keys.
That's another "its not perfect, so its worthless" fallacy. Can the NSA go lean on a CA to issue bogus certs? Yes, they can. That's why we have things like the HTTPS Everywhere observatory, HPKP, and the certificate transparency initiative. We can't make it impossible for someone at No Such Agency to compromise a CA, but we can dramatically raise the cost for them to do so. Once upon a time, even with TLS, they could issue a bogus cert and collect traffic pretty much as easily as they could when the web was unencrypted. Now their bogus cert stands a good chance of not only not working, but of being noticed by the security community. Spooks very much do not want senpai to notice them when they do things like that. Their compromised CA might well be good for only one attack before its noticed, certificates get revoked, browsers and OSes issue updates to remove the CA, etc. To say nothing of the target knowing he was targeted.

We don't have to make surveillance impossible, we just have to make it infeasible.

>>58896749

Yes, I get what you're saying, so go ahead and enable HTTPS on your apt sources. It's not hard.

Regardless though, they'll just see you downloading 500+ libraries and not much of interest.

>>58896749
This. The reason why government agencies perform passive surveillance on everyone instead of just targeted surveillance on people who they have warrants for is because it's just so cheap and easy to do the former. Widespread HTTPS deployment might not prevent them from doing their jobs completely, but it can help to make it prohibitively difficult for them to perform passive surveillance.

>>58896783
There are a lot of government agencies (maybe not in the US yet) who would be very interested in people downloading certain packages like aircrack-ng or tor.

Arch has both HTTP and HTTPS mirrors, so if you really care just make sure only HTTPS ones are uncommented. You can also use Tor if desired.

>>58896579
Cryptography confirms integrity of the package

>>58896834
>There are a lot of government agencies (maybe not in the US yet) who would be very interested in people downloading certain packages like aircrack-ng or tor.

And those who are paranoid about that would've enabled HTTPS already. Aircrack-ng is also not a very suspicious package.

script to find some mirrors on debian which support https

https://gist.github.com/eighthave/7285154

didn't test yet

>>58896783
>so go ahead and enable HTTPS on your apt sources. It's not hard.
But you can't, the most important repo doesn't support it!

Just try https://security.ubuntu.com/ubuntu

Found this explanation of public-key. The original one probably comes with the install ISO, right?

https://help.ubuntu.com/community/SecureApt

>>58895966
Fedora master race.

Some other things to consider.

What about browser plugin installs and updates?

What about various software package managers like pip?

There's probably more.

>>58899323
bump

File: 1477231695620.jpg (165KB, 500x500px) Image search: [Google]

165KB, 500x500px

>>58895966
I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX.

Many computer users run a modified version of the GNU system every day, without realizing it. Through a peculiar turn of events, the version of GNU which is widely used today is often called "Linux", and many of its users are not aware that it is basically the GNU system, developed by the GNU Project.

There really is a Linux, and these people are using it, but it is just a part of the system they use. Linux is the kernel: the program in the system that allocates the machine's resources to the other programs that you run. The kernel is an essential part of an operating system, but useless by itself; it can only function in the context of a complete operating system. Linux is normally used in combination with the GNU operating system: the whole system is basically GNU with Linux added, or GNU/Linux. All the so-called "Linux" distributions are really distributions of GNU/Linux.

>>58895966
PGP signatures, moron.

>>58895966
Linux botnets are pretty common.

https://arstechnica.com/security/2015/09/botnet-preying-on-linux-computers-delivers-potent-ddos-attacks/

>>58895966
>what is gpg

>>58896470
could someone provide a link please?

>>58901820
https://gist.github.com/eighthave/7285154

>>58901889
thank you!

this is very useful against man in the middle attacks

>>58900308
RMS GTFO

>>58895966

You couldn't be arsed to spend 10 minutes researching this before making this threat? Hang yourself

>>58902257
>arsed
innit m8?

>>58896641
>If you use a distro that has package signing, your package manager will maintain a list of public keys that it trusts
Suppose you download a distro over http that was compromised. Its keylist contains untrustworthy keys. The key used to sign the real image was replaced too. What then?