You are not logged in.
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.
Offline
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.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
Couldn't a man in the middle attack replace the packages and their signature?
Offline
Not without the private keys that belong to the Arch developers.
Last edited by Slithery (2017-10-06 21:17:14)
Offline
Got it. Thank you.
Offline
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.
Offline
Thank you. I wasn't sure how pacman checks the packages.
Offline
Offline
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)
Offline
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)
Offline
Yeah but intercepting http request is much easier than compromising server especially on public untrusted networks.
Offline
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)
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
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)
Offline
No, they couldn't serve outdated packages. They could prevent new ones, but not send old ones.
That's exactly what I mean.
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)
Offline
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.
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.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
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.
Offline
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.
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)
Offline
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)
Offline
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.
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.
"UNIX is simple and coherent..." - Dennis Ritchie, "GNU's Not UNIX" - Richard Stallman
Offline
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.
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.
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)
Offline
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.
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
@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:
pacman over HTTP isn't any less secure than pacman over HTTPS.
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.
Offline
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)
Managing AUR repos The Right Way -- aurpublish (now a standalone tool)
Offline
Ok. Nevermind.
Offline
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 is more than just GNU/Linux -- it's an adventure
pkill -9 systemd
Offline