pacman over http insecure?

ecataranciuc · 2017-10-06 20:19:25

Hello.
Isn't pacman over HTTP insecure? Of course we can always choose only HTTPS mirrors but shouldn't security be a default setup?
Thank you.

Trilby · 2017-10-06 20:28:56

Define insecure?

There is a very real risk that someone could 'listen in' on the transaction, but what would they get out of that? They'd be able to steal freely available software! I suppose they would also get to see a sampling of the software you had on your computer. If you consider the packages you have installed to be some sort of secret, then yes, you could be worried. But other than that, what do you think the risk is?

Packages are signed, so if a MITM gives you different versions of the packages, pacman will not install them.

ecataranciuc · 2017-10-06 21:14:46

Couldn't a man in the middle attack replace the packages and their signature?

Slithery · 2017-10-06 21:16:26

Not without the private keys that belong to the Arch developers.

Last edited by Slithery (2017-10-06 21:17:14)

ecataranciuc · 2017-10-06 21:18:14

Got it. Thank you.

loqs · 2017-10-06 21:49:04

Yes both the packages and their signatures could be replaced but if signing key used to generate the signature is different then the signature should be different.
They could be replaced anyway even if your connection to the mirror is secure how can you verify that the mirror itself is secure or that it received the files securely?
Pacman by default will refuse to install none local packages whose signatures are generated by keys that are not trusted.

ecataranciuc · 2017-10-06 21:50:37

Thank you. I wasn't sure how pacman checks the packages.

loqs · 2017-10-06 22:01:41

http://allanmcrae.com/2011/12/pacman-pa … rch-linux/

Uriel_Bernhard48 · 2017-10-07 12:24:42

HTTPS is for secure transport between you and the server. Without https attacker can serve you outdated packages infinitely so you won't get security fixes like recent dnsmasq one which makes you vulnerable.

Last edited by Uriel_Bernhard48 (2017-10-07 12:26:11)

Slithery · 2017-10-07 12:32:44

Good point, but that is also a viable attack vector over https if the attacker can compromise the mirror.

Last edited by Slithery (2017-10-07 12:33:18)

Uriel_Bernhard48 · 2017-10-07 12:50:33

Yeah but intercepting http request is much easier than compromising server especially on public untrusted networks.

Trilby · 2017-10-07 13:29:52

No, they couldn't serve outdated packages. They could prevent new ones, but not send old ones.

So there would be the risk of just not getting any updates. But if an arch user notices that their primary mirror is drastically behind the rest of the arch world, they will pick a new mirror. In fact checking mirror status should be a regular part of system maintenance.

The only way to serve "old" packages would be to repackage old code with a new version number. But then this could not be signed and pacman would not install it.

At this point, intercepting http transmissions on the wire and interfering with their transmission and/or sending back fake responses - despite being quite possible - would be astronomically more difficult that simply cutting the line which would have the same end result.

Last edited by Trilby (2017-10-07 13:31:06)

Slithery · 2017-10-07 13:33:51

Once again, Trilby pipes up with the correct answer

If a day or two went by without any updates, I'd definitely be checking my mirrors.

Last edited by Slithery (2017-10-07 13:34:22)

Uriel_Bernhard48 · 2017-10-07 16:31:48

Trilby wrote:

No, they couldn't serve outdated packages. They could prevent new ones, but not send old ones.

That's exactly what I mean.

Trilby wrote:

So there would be the risk of just not getting any updates. But if an arch user notices that their primary mirror is drastically behind the rest of the arch world, they will pick a new mirror. In fact checking mirror status should be a regular part of system maintenance.

Package databases aren't signed so attacker can choose only specific packages. Anyway there is no excuse for using plain http in 2017.

Last edited by Uriel_Bernhard48 (2017-10-07 16:41:20)

Trilby · 2017-10-07 17:16:39

Uriel_Bernhard48 wrote:

Package databases aren't signed so attacker can choose only specific packages.

Not really. Unless only packages without dependencies and without other packages depending on them were targetted. There may be some of these, but they are far less likely to be of any potential security risk. So now the attack surface is vanishingly small and ridiculously complicated to target. But again, https will not prevent this form of attack as a DDOS on the mirror, or just blocking transmission in some other way would be sufficient to gain the same effect. One can interfere with https transmissions just as easily as http, they just can't decipher what it is they are interfering with.

Uriel_Bernhard48 wrote:

Anyway there is no excuse for using plain http in 2017.

This may be a true statement, but it is completely irrelevant to the discussion at hand. This thread is about whether http mirrors pose a security risk. Saying every server out there should just use https regardless may be a good point, but it is most definitely not evidence that an http connection would be a security risk.

adesh · 2017-10-07 17:21:45

Uriel_Bernhard48 wrote:

Anyway there is no excuse for using plain http in 2017.

Well, two come to mind - caching and compression.

HTTPS is not a magic bullet. And security is so overrated today that people buy sh** for it.
The best security software is installed in your head. Use it.

Uriel_Bernhard48 · 2017-10-07 17:44:36

Trilby wrote:

Not really. Unless only packages without dependencies and without other packages depending on them were targetted. There may be some of these, but they are far less likely to be of any potential security risk.

Why? What stops you from holding package like dnsmasq? It doesn't need rebuilding libraries.

Trilby wrote:

This may be a true statement, but it is completely irrelevant to the discussion at hand. This thread is about whether http mirrors pose a security risk. Saying every server out there should just use https regardless may be a good point, but it is most definitely not evidence that an http connection would be a security risk.

Security is not a binary state so simple yes/no isn't a valid answer. HTTPS is more secure than HTTP. That's all.

Last edited by Uriel_Bernhard48 (2017-10-07 17:56:41)

Slithery · 2017-10-07 17:55:54

adesh wrote:

Well, two come to mind - caching and compression.

If you're using ssl then there's no reason to not also be using HTTP/2 which has in-built compression and automatic content pushing.

Last edited by Slithery (2017-10-07 18:16:43)

Trilby · 2017-10-07 17:57:55

Uriel_Bernhard48 wrote:

Why? What stops you from holding package like dnsmasq? It doesn't need rebuilding libraries.

Yes it does. I don't really know how to respond to this, this is not a subjective or controversial point, it's merely a point of fact that dnsmasq links to various libraries and if the same versions of those libraries are not present on the system dnsmasq would simply not function at all.

Uriel_Bernhard48 wrote:

Security is not a binary state so simple risk/no risk isn't a valid answer. HTTPS is more secure than HTTP. That's all.

If you don't see the irony in the juxtaposition of your own two claims there, then there isn't possibly anything else I could say that would sink in.

By all means, boycot every http mirror if you like, it will not bother me in the slightest. In any case I think the OP got the answer they were seeking.

Uriel_Bernhard48 · 2017-10-07 18:49:22

Trilby wrote:

Yes it does. I don't really know how to respond to this, this is not a subjective or controversial point, it's merely a point of fact that dnsmasq links to various libraries and if the same versions of those libraries are not present on the system dnsmasq would simply not function at all.

Yes but this matters when major versions of libraries are updated which is not that often, i.e https://www.archlinux.org/todo/. not when dnsmasq is updated. I can succesfully run dnsmasq 2.72 from 2015 (https://git.archlinux.org/svntogit/pack … b67e530658) on otherwise fully updated system. I hope this is enough objective and uncontroversial point for you. BTW linux kernel is one of packages which are mostly independent of others.

Trilby wrote:

If you don't see the irony in the juxtaposition of your own two claims there, then there isn't possibly anything else I could say that would sink in.

Security is not a binary state
HTTPS is more secure than HTTP
Show me and all readers where did you see irony or contradiction here, please.

Trilby wrote:

In any case I think the OP got the answer they were seeking.

Maybe, but I think my point wasn't invalidated. Let readers decide. Thank you for discussion.

Last edited by Uriel_Bernhard48 (2017-10-07 19:08:08)

eschwartz · 2017-10-09 17:25:43

pacman over HTTP isn't any less secure than pacman over HTTPS. However, your pacman security policy may be insecure in general.

See the section in pacman.conf(5) for "PACKAGE AND DATABASE SIGNATURE CHECKING".

Note that by default, Arch Linux official repositories use the signing policy:

SigLevel    = Required DatabaseOptional
LocalFileSigLevel = Optional

Which means that if you want to protect Arch Linux from the specific case of a malicious mirror or MITM'ed HTTP mirror modifying the database to hold back updates to some package which does not need a soname rebuild but does have an important security update, while simultaneously offering most updates to avoid sending up obvious red flags, then you have two options which need not be mutually exclusive.

1) Subscribe to arch-security

2) Try to discuss with the dbscripts/devtools maintainers the possibility of signing the official repo databases. IIRC this is currently not implemented because the people in charge do not consider automated signing by a non-password-protected key which is simply left on the dbscripts server does not offer meaningful security, and at the time this was last discussed no one could think of a good way to sign the database with the key of the last maintainer to add/update/remove a package.

The issue is that syncing down to the developer's machine and then syncing the signatures back to the server is problematic when some other developer adds a package partway through this process and they clobber each other. Normally dbscripts can queue the packages to be added on its own.

Uriel_Bernhard48 · 2017-10-09 17:47:32

@Eschwartz Thanks for your input. I'm not proposing or complaining about anything, just stating the facts. I'm aware of pacman config and everything I wrote is consistent with yours, except:

Eschwartz wrote:

pacman over HTTP isn't any less secure than pacman over HTTPS.

Eschwartz wrote:

Which means that if you want to protect Arch Linux from the specific case of a malicious mirror or MITM'ed HTTP mirror modifying the database to hold back updates to some package which does not need a soname rebuild but does have an important security update, while simultaneously offering most updates to avoid sending up obvious red flags

As HTTPS isn't vulnerable to the above I think we can agree that pacman over HTTP is less secure. Above quotes are mutually exclusive so it's matter of logic. I hope my point is crystal clear now and we can end this topic unless someone explains case when plain http isn't vulnerable to scenario which you described.

eschwartz · 2017-10-09 18:02:32

I merely meant to imply that it isn't pacman itself which is at fault here. pacman offers many options and HTTP is frankly not even a "default" mirror setup; the problem lies solely and completely in the repository management end of things.
A signed database would be just as secure over HTTP, and encrypting the transport is at best a halfhearted solution.

Also I never accused you of complaining, in fact I regard this as a legitimate concern (albeit one with a specific limited attack surface) which I wish would be fixed.
(However, I have enough on my plate at the moment that I have never gotten around to looking at what might be necessary to fix this.)

EDIT EDIT EDIT: Attack of the edit wars.

Last edited by eschwartz (2017-10-09 18:08:28)

Uriel_Bernhard48 · 2017-10-09 18:05:08

Ok. Nevermind.

Leonid.I · 2017-10-10 16:00:48

slithery wrote:

adesh wrote:
Well, two come to mind - caching and compression.
If you're using ssl then there's no reason to not also be using HTTP/2 which has in-built compression and automatic content pushing.

Sigh... I wish people ditch HTTPS as much as possible. Just because you have an 16 core monster in your CPU socket doesn't mean that you should waste it on pointless encryption just to feed users placebo.

The security of pacman transactions relies on public-key cryptography, not on p2p encryption. Besides, why do you trust CAs who warrant S in HTTPS?

Arch Linux

#1 2017-10-06 20:19:25

pacman over http insecure?

#2 2017-10-06 20:28:56

Re: pacman over http insecure?

#3 2017-10-06 21:14:46

Re: pacman over http insecure?

#4 2017-10-06 21:16:26

Re: pacman over http insecure?

#5 2017-10-06 21:18:14

Re: pacman over http insecure?

#6 2017-10-06 21:49:04

Re: pacman over http insecure?

#7 2017-10-06 21:50:37

Re: pacman over http insecure?

#8 2017-10-06 22:01:41

Re: pacman over http insecure?

#9 2017-10-07 12:24:42

Re: pacman over http insecure?

#10 2017-10-07 12:32:44

Re: pacman over http insecure?

#11 2017-10-07 12:50:33

Re: pacman over http insecure?

#12 2017-10-07 13:29:52

Re: pacman over http insecure?

#13 2017-10-07 13:33:51

Re: pacman over http insecure?

#14 2017-10-07 16:31:48

Re: pacman over http insecure?

#15 2017-10-07 17:16:39

Re: pacman over http insecure?

#16 2017-10-07 17:21:45

Re: pacman over http insecure?

#17 2017-10-07 17:44:36

Re: pacman over http insecure?

#18 2017-10-07 17:55:54

Re: pacman over http insecure?

#19 2017-10-07 17:57:55

Re: pacman over http insecure?

#20 2017-10-07 18:49:22

Re: pacman over http insecure?

#21 2017-10-09 17:25:43

Re: pacman over http insecure?

#22 2017-10-09 17:47:32

Re: pacman over http insecure?

#23 2017-10-09 18:02:32

Re: pacman over http insecure?

#24 2017-10-09 18:05:08

Re: pacman over http insecure?

#25 2017-10-10 16:00:48

Re: pacman over http insecure?

Board footer