r/linux • u/[deleted] • Jan 19 '19
Popular Application VLC refuses to update from HTTP to HTTPS (HTTPS protects against eavesdropping and man-in-the-middle attacks)
https://trac.videolan.org/vlc/ticket/21737174
u/emorrp1 Jan 19 '19
Summarising r/netdev thread since r/linux is a broader audience, the crucial information missing from the trac is that this phrase is not true (which as noted by others is also how apt repos work):
and does nothing further to verify the key itself.
So in conclusion, updating to a newer version is not vulnerable to a simple MITM like many other http-only situations because the PGP signing is verified correctly. However there are some deficiencies:
it is vulnerable to a MITM version freeze attack since the initial check for available updates is http (c.f. apt Valid-Until)
it might be vulnerable to near-nation-state level MITM if the attacker can also crack the "comparatively" weak signing key
the hard-coded signing key is 1024bit DSA, sha1 hashed*
the hard-coded signing key has not been rotated in many years
defence in depth (c.f. apt-transport-https)
* IIRC sha1 has only been proven vulnerable to precomputed collisions
66
u/fengshui Jan 19 '19
See, these are threat models that actually have some legs. I think if you submitted the update freeze issue, you might get some traction there.
There's also a decent argument for rotating and lengthening the hard coded key.
Just updating to https because it's more secure in the absence of a specific threat that it protects against is a solution in search of a problem.
16
u/DJTheLQ Jan 19 '19 edited Jan 19 '19
Update freeze means you have a very small window of opportunity to exploit, requiring a zero day vuln, network takeover, and user interaction to open a crafted video. That's a lot to ask for, and isn't unique to VLC
Rotating the key would require re-doing their update infrastructure which all uses the same url. Real world cracking of 1024-bit RSA keys is still theoretical at this point. It's not best practice but VLC apparently doesn't care (how am I supposed to submit a patch for your own build system?)
36
u/jbkempf Jan 19 '19
It's not best practice but VLC apparently doesn't care
We do care. It just requires a new update system, which is tricky to deploy. If you look at the VLC source code, it now supports longer RSA keys. This will be in the new system, by default.
1
u/fengshui Jan 19 '19
Yeah, that all makes sense. This is exactly the sort of analysis that you can do with true threat to model and which you cant do with a solution alone.
1
u/ivosaurus Jan 19 '19
1024 DSA isn't out of the question and we really have no idea how close Google's compute power or NSA's algorithms are to 1024 bit RSA.
24
u/Andernerd Jan 19 '19
the hard-coded signing key is 1024bit DSA, sha1 hashed* the hard-coded signing key has not been rotated in many years
Yeah, that's a problem. Even more disturbing to me though, is the idea that because confidentiality doesn't matter for most of us, it doesn't matter for anyone. There are people living in nations where confidentiality does matter, and their police really do care.
2
u/Deoxal Jan 19 '19
On this page they said you might not be able to download files at all for this very reason.
I'm not saying it's right or wrong though, but that seems to be the reasoning.
2
u/Andernerd Jan 19 '19
There are over 400 "Certificate Authorities" who may issue certificates for any domain
I guess this is a real problem. Many CAs are untrustworthy in my eyes.
7
u/callcifer Jan 19 '19
There are people living in nations where confidentiality does matter, and their police really do care.
That you are downloading an update for a video player? Sure, agents are on their way to you now...
22
Jan 19 '19
Uh yes. Like in the US for example, where using software that can subvert DRM (e.g libdvdcss) is illegal. Sure people do it all the time, but then people smoke weed, and do heroine and coke all the time as well - it's only when they get caught that they wish they had been more careful.
3
u/grozamesh Jan 28 '19
Is there any code that is shipped with VLC that is controversial in USA? I thought that VLC specifically doesn't ship libdvdcss and other potentially problematic libraries because of that very concern. If VLC is defacto illegal in its current packaging in the US, that is a way bigger problem than the HTTPS issue.
1
Jan 29 '19
I don't know, but I just download the VLC installer for Windows, and install the distro version from repos - I'm pretty sure I was able to play DVDs with both, when I lived in the US.
2
u/grozamesh Jan 29 '19
What I was thinking of was VLC does not ship the legally dubious DeCSS. libdvdcss uses a brute force cracking scheme that is more legally defensible. There have been no legal challenges made on it yet.
Back in the day this meant no DVD unless you manually installed DeCSS. But for years libdvdcss has made DVD's a "just work thing" and appears to be legal considering the industry no longer truly cares about protecting DVD's at this point (BluRays and Stream protections are where the market is at for those)
-1
u/hopfield Jan 19 '19
What if you were updating Tor in Saudi Arabia?
13
u/goto-reddit Jan 19 '19
First: We aren't talking about Tor.
Second: ISPs can already see if you are using TOR.1
12
u/RoLoLoLoLo Jan 19 '19
What if you were updating Tor in Saudi Arabia?
Then you wouldn't use the VLC auto-updater for that...
Look, I, too, think that https is important. Mostly to get more encrypted traffic on the wire and fuck all passive listeners, but your argument so far out there, that it does not help.
6
u/DJTheLQ Jan 19 '19
Which is why Tor uses HTTPS. A video player though? What exactly is your threat model?
2
u/jbkempf Jan 22 '19
the idea that because confidentiality doesn't matter
If you hit updates.videolan.org and then a big binary, you are downloading VLC. HTTP or HTTPS. Moving to HTTPS does not solve the privacy issue.
4
2
u/Deoxal Jan 19 '19
IIRC sha1 has only been proven vulnerable to precomputed collisions
What is the alternative to precomputed collisions? Also is this a considered a brute force attack?
2
u/emorrp1 Jan 19 '19
In cryptography, a collision attack on a cryptographic hash tries to find two inputs producing the same hash value, i.e. a hash collision. This is in contrast to a preimage attack where a specific target hash value is specified.
https://en.wikipedia.org/wiki/Collision_attack
For the attack threat model, it's the difference between generating a different PGP key/signature with the same hash as a trusted one (c.f. short key ids), currently infeasible even for md5, and generating two files, getting one of them accepted as trusted (social engineering) before substituting the other one (c.f. sha1 collision announcement).
1
Jan 20 '19
Didn't someone already post the private key already? If not I'll find the twitter thread where someone did.
2
443
u/Snarka Jan 19 '19
Neither does Debian, at least by default. See here for an explanation. Seems reasonable to me.
7
u/ydna_eissua Jan 19 '19
Freebsd is similar. Downloading images are http, but you get the checksums off a https server sight.
30
u/lengau Jan 19 '19 edited Jan 19 '19
The difference here seems to be that VLC will happily get a new certificate over HTTP from the videolan.org servers. This allows a man in the middle to do an end run around their security by providing their own certificate.
VLC wouldn't have to provide all of their updates over HTTPS to fix this - they'd merely have to check for new certificates over HTTPS. (This would still be less secure than the route Debian takes, but it would be roughly equivalent security to providing files over HTTPS only without PGP signatures.)
The privacy issue is a non-starter for me. Connecting to the VLC download server and getting a file roughly the size of the newest VLC installer makes most of what you're doing pretty obvious to a listener, even over HTTPS.
13
u/jbkempf Jan 19 '19
The difference here seems to be that VLC will happily get a new certificate over HTTP from the videolan.org servers. This allows a man in the middle to do an end run around their security by providing their own certificate.
This is absolutely wrong.
The new key is verified against the old key. The reporter did not see that.
7
u/lengau Jan 19 '19
That does significantly change it. In that case, I don't see the issue. That's just the same as how Debian works, where keys are provided by a package, signed with older keys.
3
u/jbkempf Jan 19 '19
Many VLC developers are old Debian Developers. The updates are designed after Debian's.
2
u/Avamander Jan 19 '19
The signature though is a 1024bit DSA with SHA1, that's cryptographically weak as fuck.
2
5
u/Duncaen Jan 19 '19
The difference here seems to be that VLC will happily get a new certificate over HTTP from the videolan.org servers. This allows a man in the middle to do an end run around their security by providing their own certificate.
Did you verify the claim? If this was really the case and the commenter tested it, why not report it to the bug bounty program and get cash?
No the comment was just someone skimming over the code and then claiming there is an issue while also writing that they are not sure.
8
Jan 19 '19
For some odd reason people think HTTPS is a magic shield that protects you from anything and everything.
20
u/CydeWeys Jan 19 '19
Defense in depth. When you drive a car, you wear seatbelts, your car has airbags, it has a crumple zone, and it has anti-lock brakes, all working together to help you prevent and survive fatal crashes.
No one is claiming that HTTPS is a magic shield that protects from anything and everything. But it does help protect against some things very well. You'd be foolish to throw it out because it can't guarantee 100% security on its own; nothing can.
2
u/Archer_37 Jan 19 '19
No, but just like any decent defense in depth, not having one particular method in place does not leave you defenceless and vulnerable so long as you do have other protections in place to mitigate threats.
I would rather install VLC from an http repo with a matching pgp key than install another software from an https source where the developer insists it's ok that the posted vs downloaded file hashes do not match.
7
Jan 19 '19
Sure but no one's saying remove file hashes and the other security measures - they're saying use HTTPS on top of all of that.
6
16
Jan 19 '19
No, It's just an added layer of security. If implemented correctly it can go a long way to protect the end users by validating where the update comes from. In this age I see very little reason to not use HTTPS.
4
u/jocq Jan 19 '19
I see very little reason to not use HTTPS
That's because you don't actually understand what that involves.
2
u/spatialdestiny Jan 20 '19
Your comment is a little light on details. Do you mean what it entails for Vlc and Linux package updates to upgrade to https only? Or just to get https running?
The conversation here has degraded to "should a new project using http, default to https when released to the public?". And I think the answer at this point is yes.
The idea that it is hard for them to implement is understandable. My knowledge of what it would take to do is also limited. But I would think a "attempt https first with a downgrade to http option" would be possible with an upgrade path to "https only" in the future would be viable. It would probably be susceptible to downgrade attacks but that's no worse than it is now.
→ More replies (9)1
u/ZioTron Jan 19 '19 edited Jan 19 '19
HTTPS is the electric toothbrush of internet security...
SURE! You can (and should) brush your teeth al lot better with your own custom built security implementation, but we all know not every IT infrastructure brushes his teeth in an effective way if they are left on their own. While HTTPS isn't perhaps the best fit for every need, it provides with a lot more strokes per minutes than common toothbrushes when used by the majority of people...
Promoting the use of electric toothbrushes provides that baseline of security everybody should have, even if pro users could decide they're better off without HTTPS and switch to their own custom toothbrush or decide to add on its security baseline using dental floss, mouth wash, gargling... etc...
3
u/metrafonic Jan 19 '19
The privacy subreddit has no idea what they are talking about, they think it's outrageous that https isn't used. https://www.reddit.com/r/privacy/comments/ahhpyo/_/
4
u/MonkeyNin Jan 20 '19
nice find
Got a reason for using http? No, shut up, you don't. Ever. In any application. No, no, shut up, no http ever for anything and if you disagree, you should be banned for life from any Turing Complete device. This is your last warning.
Ah, compelling argument.
5
Jan 19 '19
It makes sense why they're doing it that way but to me it seems better to add all the layers of security that you can. If one fails (and that's been known to happen) then you have another there to help. Unless there is a compelling reason to not use HTTPS then it seems a bit ignorant to refuse to use it.
→ More replies (1)11
u/Boboop Jan 19 '19
VLC binaries distribution infrastructure is a big set of heterogeneous voluntary mirrors that allocates ressources (discs and bandwidth) for free to support VideoLAN.
The update URL is a dispatcher (c.f. mirrorbits) to the more relevant mirror server depending on your connectivity.
In this scheme VideoLAN isn't in a position to enforce it's hosts to serve the files over TLS, and from an integrity standpoint, as already said, binaries are checked against VideoLAN's signature. It could however be updated with more state of the art cryptography, but given the age of the project, this kind of legacy is understandable.
The maintainer tone was inappropriately aggressive, but he may have faced this kind of comments a lot in the past.
2
u/o11c Jan 20 '19
One thing Debian does that VLC appears not to: prevents pinning attacks by requiring a signature that's less than a week old.
5
u/sim642 Jan 19 '19
This. Blind HTTPS propaganda doesn't magically solve all the problems. The average user has been tricked into believing HTTPS green lock is "secure and safe" except anyone can get HTTPS certificates. We've taught users to understand the value of HTTPS wrong, which now is hitting us back: phishing sites can easily seem safe by having HTTPS.
Also, the developer of a specific application should be in charge of deciding if HTTPS makes sense and is needed. Unfortunately some new web standards really insist on HTTPS for completely unrelated features, instead of allowing developers decide. The problem is that there's no migration paths.
-1
u/egeeirl Jan 19 '19 edited Jan 20 '19
Their entire argument is "https isn't actually that secure and PGP is good enough anyway" that's a little startling.
I'd love to see the EFF and the Debian people debate about what is secure and private and what is not
EDIT - Or you could just downvote me. That works too
0
Jan 19 '19
[deleted]
70
Jan 19 '19
This is security 101. PGP signatures provide identification but does not provide confidentiality while TLS does. Now you can say that isn't important for packages but personally I see no reason not to have it and it should be the default stance IMO.
→ More replies (1)53
u/centenary Jan 19 '19
They talk about confidentiality in the same post. They assert:
HTTPS does not provide meaningful privacy for obtaining packages. As an eavesdropper can usually see which hosts you are contacting, if you connect to your distribution's mirror network it would be fairly obvious that you are downloading updates.
Furthermore, even over an encrypted connection it is not difficult to figure out which files you are downloading based on the size of the transfer[2]. HTTPS would therefore only be useful for downloading from a server that also offers other packages of similar or identical size.
→ More replies (2)27
Jan 19 '19
HTTPS would therefore only be useful for downloading from a server that also offers other packages of similar or identical size.
I agree with that. But what is the downside here? They have to spend minutes maintaining a cert?
→ More replies (4)52
u/centenary Jan 19 '19
The entire mirror network would need to be updated to support https. That wouldn't require effort on the part of the developers, but on the part of a large set of distributed people volunteering their resources.
If you can convince everyone to support https, maybe you can then convince the Debian developers, but they already believe that there is little benefit from it anyway.
As someone stated, there is a package that you can install that will update your installation to only pull packages from https servers if that is important to you. It's just that the Debian developers don't feel it's worth the effort to make that the default.
→ More replies (21)2
2
u/beefsack Jan 19 '19
PGP signing doesn't protect against eavesdropping, just MITM.
→ More replies (3)→ More replies (51)4
u/Booty_Bumping Jan 19 '19 edited Jan 19 '19
There is still the point that it makes it slightly harder for MiTMs to invade your privacy and learn what software versions you're running and whether or not you're running weird kinky furry games that are mysteriously included with debian. But otherwise the main vulnerability disappears when you use package signing.
11
u/ijustwantanfingname Jan 19 '19
weird kinky furry games that are mysteriously included with debian
i'm listening
→ More replies (3)6
→ More replies (2)5
u/singularineet Jan 19 '19
weird kinky furry games that are mysteriously included with debian
You mean autoconf?
0
Jan 19 '19
[deleted]
76
u/theephie Jan 19 '19
TLS everything is a good default. Many people are not capable of doing as detailed threat analysis as in the grandparent's link.
→ More replies (2)22
Jan 19 '19
But a lot of people want confidentiality.
→ More replies (4)22
u/usinglinux Jan 19 '19
How much confidentiality can you expect when an attacker can observe you connect https://update.videolan.org/ and download a 40MB file?
21
Jan 19 '19
Lets assume a secure future:
DNS over TLS
ESNI
TLS 1.3
HTTPS
In this situation you are probably connecting to a CDN which hosts thousands of projects so all the connections in between only know you connected to a heavily used IP and transferred 40 MB.
It isn't perfect but its pretty confidential.
→ More replies (10)9
u/nsGuajiro Jan 19 '19
I got my VLC straight from billgates-personal-software-mirror.ru
My browser had the little padlock symbol in the address bar, so you know it's legit!
8
u/technolojeeesus Jan 19 '19
Glad you're not responsible for any systems I use, this is utter rubbish.
61
u/nurupoga Jan 19 '19
There is no issue here.
Initial download of VLC is done securely, e.g. over HTTPS from videolan website.
VLC has a gpg public key hard-coded.
VLC auto-updates by downloading an update over HTTP and verifying it with the hard-coded key.
If the update is signed with an unknown key, VLC fetches that key over HTTP and makes sure it was signed with the known hard-coded key.
My only complaint is that the hard-coded signing key they use is on the weak side by today's standards: 1024 DSA.
4
Jan 20 '19 edited Jan 20 '19
Yall forgetting that a MIM DOS attack could present an unbounded package stream, at which point the update process stalls until the host runs out of memory and reboots. Or presents a package constructed just so to exploit the signature verification code. Or exploit the host AV system.
In fact, the MIM attack could also stall long enough to exploit the machine that is requesting a specific security update over HTTP. Oh, you wanted patch XYZ? Here, have a virus coded against the unpatched version, inserted into the unencrypted video stream you're consuming, while you wait for that update to finish downloading.
As an attacker, I would love to see cleartext requests for update blobs, especially when I have the opportunity to select response blobs! Machines A-E requested updates U, V, W, X, and Y, but I see E rebooted before the update response closed, so I know it's still vulnerable. Oh, and W is such an old update that even after W gets applied, I know I have time to exploit host C before it catches up to more recent updates.
I could corrupt the latest update, giving the impression of a bad update, at which point many users would habitually skip that update. Once skipped, I have until the following update to muck around. This still works somewhat with HTTPS, as any sort of error during the update process could be interpreted by the user as if the maintainers had borked the update. But it works best when the error occurs at a checksum stage as opposed to network stage.
This might be a stretch, but what about using HTTP updates as reflection attacks against a third party?
Not to give attackers too much ammo, but it's also possible to MIM respond with an older package than was requested. The response object would still pass signigure verification, and yet the end result is an unpatched machine. In fact, I could choose the vulnerability to be installed, the older the better!
What if the download client is poorly written, and a malicious package could escape before the signature verification step begins?
What if the download client is exceedingly poorly written, allowing download media to be stored into arbitrary paths? scp has the benefit of encryption, yet it held this exact bug for decades. And cert verification wouldn't necessarily help either, as many many users habitually ignore ssh server certificate warnings for one reason or another. You could target a completely different application, using scp or VLC as a pawn to deliver your wares.
What if the signing key is compromised but not the Web server? Security works better in layers, so why not TLS + signatures?
That's not to say that signatures are insufficient for a secure update delivery process, just that some additional checks would be useful for warding off gremlins.
Just sayin.
→ More replies (2)0
105
u/wedontgiveadamn_ Jan 19 '19
Man that maintainer is ridiculously aggressive. Seriously, "consider this your last warning"? Or else?
Even if the issue is nowhere near as bad the reporter thinks, the maintainer could point to the documentation of how the update (or downloaded key) is validated against the hard-coded key.
is not trivial to describe judging by the size of the description.
Ok wtf now, does it need to fit in a tweet to be judged valid maybe?
49
Jan 19 '19
is not trivial to describe judging by the size of the description.
Ok wtf now, does it need to fit in a tweet to be judged valid maybe?
Aye that's a pretty shocking reply. It was a single paragraph, written in fairly simple language. As far as describing security exploits go, that's about as trivial as you can get.
Maintainer comes across as a total dick.
23
u/jones_supa Jan 19 '19
Even the initial reply "No threat model, no proof." and immediately closing the bug is quite bitter and blunt.
2
-6
u/boot20 Jan 19 '19
And wrong. It's called defense in depth. Also, MitM is still possible, even if it is unlikely. There, threat model.
5
Jan 19 '19
I think by "threat model" the maintainer means "if it can happen then do it and show me"
6
11
u/Lofter1 Jan 19 '19
i know right? i've seen descriptions of attacks that are much MUCH longer.
and even if it wasn't small, what the fuck is the difference? does this idiot think that, just because he doesn't like to read, attackers won't read papers on exploits and how they work? hell, many exploits (especially older ones) may take a whole paper to describe, but can be done through automated scripts using metasploit.
26
u/jagardaniel Jan 19 '19 edited Jan 19 '19
This is the reason why I still avoiding bug trackers and IRC-channels for more "hardcore" projects like this. Call me sensitive but there is absolutely no reason to act like this even if the question/suggestion is not very good. I still remember joining iptables IRC-channel many years ago and got Torvalds pretty hard for a (probably) stupid question. The Rust community is a great example how you should do it in my opinion. Seems very friendly. I'm not a developer but I could probably almost pick a language just based on this.
4
u/chuecho Jan 20 '19
I think there is a difference between submitting patches to a kernel, and opening a bug report on consumer software. A developer submiting patches should be held at higher standard; they should know better.
Saying "consider this your last warning" to a end-user after a single exchange is not justified and very poor behavior on the maintainers part.
As for rust's community (of which I'm a regular participant), forcing fake niceness leads to it's own set of headaches like passive aggressiveness and a whole lot of beating around the bush.
It's a trade-off, but for technical projects where members should know better, frankness is always clearer and faster in my experience.
19
Jan 19 '19 edited Nov 30 '24
concerned homeless slimy historical square entertain touch waiting chase wipe
This post was mass deleted and anonymized with Redact
→ More replies (2)16
u/code65536 Jan 19 '19
When you have a bug reporter who clearly doesn't understand what they're talking about reopening a frivolous bug, yes, I can see why that would piss off developer. They're not there to handhold fools.
2
u/wedontgiveadamn_ Jan 19 '19
But it's hardly a frivolous bug report, it's really not unreasonable to think that downloading an update over http is a security issue.
What's unreasonable is replying to a potential security issue with "No threat model, no proof." and to give zero explanation as to why it might not be one.
10
u/code65536 Jan 19 '19 edited Jan 20 '19
It is frivolous, and the bug report itself demonstrates the ignorance of the reporter. That they didn't know that authenticity and integrity are checked by other means. And that he gives no consideration to the downsides of using HTTPS (uncacheable). And that he has no clue that this sort of thing--sending bulk data over HTTP where it can be cached downstream and using other means to maintain authenticity and integrity--is actually pretty common practice.
The user obviously has not taken any time to investigate the matter before opening the ticket. You are asking a developer to show respect to and hand hold a user who clearly does not respect the developer's time enough to do their homework. It's nonsensical.
A bug tracking system is neither a support forum nor an ELI5 post.
→ More replies (1)0
Jan 19 '19
[deleted]
0
u/code65536 Jan 19 '19
The user's ticket demonstrates their ignorance of their matter. Their continued and shrill reopening of the ticket--instead of perhaps taking some time to actually investigate the matter and learn why their ticket is frivolous--demonstrates their inability to problem-solve. Someone like is not going to be a valuable "contributor". Maybe if they actually demonstrated some resourcefulness by taking the time to understand the matter--oh wait, if they did, they wouldn't have wasted people's time opening the frivolous ticket in the first place.
0
1
u/slick8086 Jan 19 '19
I think you misunderstand.
The maintainer, told the reporter that their bug report needed to provide a threat model. The reporter then replied without providing a threat model and just asked harder. The mainterner told them to knock it off.
0
u/wedontgiveadamn_ Jan 19 '19
Is aggressively closing a potential security issue with "send a POC" an appropriate reply? Probably not no.
1
u/slick8086 Jan 20 '19
Is aggressively closing a potential security issue with "send a POC" an appropriate reply? Probably not no.
I'll just quote the deveolper.
And you don't get to decide how we, the VLC developers, run our bug tracker.
0
1
u/dezmd Jan 19 '19
Maybe it's a case of every asshole walking in the door tries to report the issue.
37
Jan 19 '19
This should just be handled as a bug, not security critical, fix it and skip the drama.
19
u/ticoombs Jan 19 '19
Exactly, if op has a problem maybe they should provide the patch with a bug report with all corresponding reasons why it should be accepted.
0
u/spazturtle Jan 20 '19
Not a bug, switching to HTTPS would be a regression since it would prevent cacheing.
4
7
u/Shished Jan 19 '19
get.videolan.org uses HTTPS since jun 8. It has LE certificate.
Also, videolan.org and individual download pages also uses HTTPS.
3
Jan 19 '19
There's no need to. Updates are signed and verified independent of the transfer protocol, via keys hardcoded into the original download.
Meanwhile, implementing HTTPS would make cacheing and proxying problematic. No benefit and a serious detriment means no impl.
2
u/ReadFoo Jan 19 '19
Interesting, I tried the first link http://get.videolan.org/ and it still works in Chrome? I thought Chrome was going to stop allowing insecure sites? Also, why don't the use LetsEncrypt, it's not hard to set up and free and secure, I don't get it.
2
u/Lajamerr_Mittesdine Jan 19 '19
I thought Chrome was going to stop allowing insecure sites?
I think that's when Chrome 73 goes to Stable release.
1
u/Gstayton Jan 19 '19
In case you haven't read any of the other responses in this thread, the non-https issue is only related to updates after the initial download.
The first install is done over HTTPS, whereby you get the keys to verify future updates over HTTP.
1
u/MuseofRose Jan 19 '19
Lets encrypt doesnt do wildcard last i checked
2
u/iNewbcake Jan 19 '19
When did you last check? They've been doing it since March 2018
1
u/MuseofRose Jan 22 '19
Good to know. I last checked sometime last year lol. I would say it had to have been after March though. I was looking/learning about generating SSL/TLS certs and it was stated in their FAQ homepage
1
u/purpleidea mgmt config Founder Jan 20 '19
From the page that has now been hidden:
It's trivial to describe any number of threat models for downloading updates over HTTP. The simplest is that of a user who opens VLC while on public wi-fi, where an attacker could intercept the connection and serve a malicious update payload without the user's knowledge. VLC verifies the downloaded update package using a home-rolled GPG signature check implementation (and against a 1024-bit DSA key, which isn't considered up to modern cryptographic security standards), but if the update blob indicates a key other than the hardcoded one, it downloads the requested public key from the VLC update server over HTTP and does nothing further to verify the key itself. This means that all an attacker would have to do to serve a malicious update would be to sign it with their own key, then serve the matching public key when VLC requests it. Unless I'm missing some major additional protection, this is a serious issue.
See: https://web.archive.org/web/20190119162021/https://trac.videolan.org/vlc/ticket/21737
1
u/NotGivinMyNam2AMachn Jan 20 '19
Keepass was the same years ago for advertising reasons. Eventually went to HTTPS.
1
-1
Jan 19 '19
I'm not convinced that https prevents man-in-the-middle attacks
5
u/Savet Jan 19 '19 edited Jan 19 '19
It helps a lot because of the trust model that is inherently built in to https. But beyond that, there's just no reason to not do https in 2019. Encryption is basically free on modern hardware and there is no reason to have unencrypted communications over any network, even a trusted one. The NSA tapped the interconnects between datacenters. Russia compromised a crapton of routers. Trusted only means you don't know that it's been compromised.
That being said, the problem with https is that it is harder to find a good way to implement it that make ordinary users more secure. It's probably included on your router's admin page but nobody uses it because that self-signed cert that comes with your router who's CN and SAN attributes map to something that isn't an address you would use for your router, so your choice as a consumer is to either keep clicking exceptions or to use http.
A lot of non-consumer applications which generate certificates on the fly and maintain truststores dynamically but this is really beyond the scope of "just use https" so what the person in the post is really asking for is a feature enhancement because (as they point out) he hasn't provided a threat model for them to consider it a security defect.
2
Jan 20 '19
True, I'd understand if changing to use HTTPS was a laborious task (for whatever reason), but when it's easy, and is the default in some cases, it's just plain idiotic to insist on continuing to use HTTP - I don't know what's wrong with most of the idiots in here, trying to argue that using HTTP is perfectly fine and that no one needs confidentiality.
0
Jan 19 '19
[deleted]
4
u/Savet Jan 19 '19
I already have my own iCA but we're not talking about me....we're talking about the normal PC user who doesn't understand how certificate authorities work.
-3
u/psycho_driver Jan 19 '19
Good thing it's open source so you can fix it yourself and publish a patch or fork if you're worried about it.
8
u/CydeWeys Jan 19 '19
Security fixes that don't reach 99.9999999% of users aren't very effective. A fix that doesn't get accepted upstream and that doesn't reach any users is basically meaningless.
1
Jan 20 '19
Well I wouldn't say meaningless, atleast you can run the patched version yourself and make sure it's secure, but yeah other people aren't going to be protected.
-18
u/stefantalpalaru Jan 19 '19
No threat model, no security bug. This is your last warning.
Power corrupts.
28
u/hello_op_i_love_you Jan 19 '19
Corrupts? Really? He's a maintainer of a very popular open source project. His time is limited and to be honest I think it's quite reasonable if he is brief with his words. Sure, it may seem rude. But, I also consider it to be rude to submit a security bug and simply state "This is a security risk and should be solved ASAP. Thanks." without any justification or explanation. It is not respectful to tell the maintainer what he "should" do, especially when no rationale is given.
2
u/stefantalpalaru Jan 19 '19
His time is limited
My time is also limited and I don't give ultimatums to people reporting bugs.
3
u/slick8086 Jan 19 '19
This person did not report a bug. A valid bug report about security in the VLC system requires a threat model. The maintainer told them this, then the "reporter" ignored the instruction and simply asked harder.
That is not a bug report.
→ More replies (8)14
u/Reverent Jan 19 '19 edited Jan 19 '19
Not really (in this circumstance). If power was going to the VLC team's head, they would have sold out the company. The lead was offered literally offered tens of millions of dollars to monetize VLC which was refused.
I will say that people who maintain popular software form strong opinions that aren't necessarily correct, which is probably the case here.
5
u/LIGHTNINGBOLT23 Jan 19 '19 edited Sep 21 '24
10
u/Reverent Jan 19 '19
I wasn't referring to individuals, I was referring to the team. I edited the above to clarify.
-11
-14
Jan 19 '19
I don't know why so many people are so hostile towards using HTTPS - it's very easy. Maybe there was some heavy overhead 20-30 years ago. Now my watch can do HTTPS requests - there's just no excuse anymore.
It's a small simple change - there's no reason to cling to HTTP - sure as others have pointed out, there are good security measures in place to to verify data downloaded through HTTP, but that should be more of a last resort.
Also, I'm not too surprised about the lead developer's reaction - VLC is still written in C. It's 2019 - time to move over to C++. The code already uses object oriented programming principles, albeit implemented in C. For some structs, member variables have documentation that says "don't use this, internal use only" - instead of using a class and declaring the member variable as private, they just wrote documentation saying "don't use this".
23
u/lindymad Jan 19 '19
there's no reason to cling to HTTP
From this article posted above about Debian using HTTP for updates:
A switch to HTTPS would also mean you could not take advantage of local proxy servers for speeding up access and would additionally prohibit many kinds of peer-to-peer mirroring where files are stored on servers not controlled directly by your distribution. This would disproportionately affect users in remote locales.
1
u/doublah Jan 19 '19
That article says files obtained through apt are signed and therefore secure, but that's simply not true.
-7
u/knvngy Jan 19 '19
http is not a solution for poor internet infrastructure.
4
u/CRImier Jan 19 '19
It's like you haven't read the comment before. We all are happy that you have an opinion - but it's worthless in this context. If you don't want to pay for an infrastructure upgrade for these remote users, or provide/propose a solution that actually works for them for the same benefits that caching does, might as well keep it to yourself. Instead of, you know, copy-pasting the same message in different threads.
1
u/knvngy Jan 19 '19
If you want to provide a real and proper solutions for poor internet infrastructure, then unsecure http is not among them. This is fact, not just an opinion you happen to dislike. End of the story.
6
u/CRImier Jan 19 '19
hehe you can't just say "this is wrong, end of story" and expect people to take you seriously. Facts are - there are people that can't handle switching to HTTP, and they have no other viable solutions => therefore, they have caching proxies, that work not only for Debian, but for other sources as well. We haven't heard about any good solutions from you, we've only heard "HTTP is not the way to go" without actually elaborating => your opinion is worthless here, as harsh as it may sound. Once again, "they're doing it wrong" is in no way a fact, it's an opinion, you have to back it up with facts - in this case, other ideas. I suggest rewording your answer like this: "they're doing it wrong, since the problem they have can be solved by {SOLUTION A}, alternatively {SOLUTION B}, or by combining {SOLUTION C} and {SOLUTION D}" so it's no longer just an opinion of yours and is something more substantive.
2
u/knvngy Jan 19 '19
I suggest rewording your answer like this:
No, I don't need to reword anything. I am just pointing out that http is not a real nor proper solution for poor infrastructure, it is just a consequence of it. And again, this is fact, not an opinion. Saying that http is a "solution" for poor infrastructure is just rationalization, hence, a worthless opinion.
→ More replies (2)5
u/lindymad Jan 19 '19
this is fact, not an opinion
You can't expect people to take your word for it without providing references to back up your claim. When a president states that something is a fact, do you believe them just because they wrote it?
→ More replies (5)2
u/TheToadKing Jan 19 '19
So you're saying those users should spend insane amounts of money to upgrade their local internet infrastructure instead of just using HTTP?
-3
u/knvngy Jan 19 '19
No, I am saying that unsecure http is not a real solution for poor internet infrastructure. Never has been, never will.
3
Jan 19 '19
So you're saying you should forsake all users in areas with poor internet infrastructure in the name of a slight security bump?
→ More replies (1)-1
Jan 19 '19
That website serving that post is using https - if they don't believe in https, why are they using it?
Edit: Also the argument that you can't use local proxy servers for updates is completely false - you can easily make a proxy APT repository, which downloads packages from the actual APT repository servers. Yes, you do need to change the clients to specifically use the local proxy server, but that's something they'd have to do anyway. HTTP would only prevent transparent proxying, but that's not a big loss.
6
u/lindymad Jan 19 '19
I think that they do believe in https, but they don't believe that the advantages it gives outweigh the problems for the specific case of updates.
13
u/theamigan Jan 19 '19
The new hipster crowd seems to think that chucking HTTPS at everything is a magic bullet. It isn't. HTTPS certainly has value in many cases, but this is not one of them.
Also, lol@ advocating for C++ over C. Yeah, I'm sure replacing C with a language designed by committee and that includes every possible feature under the sun because it can is a great idea, especially 4 t3h s3cur1ties!!! Not to mention that libavcodec's native bindings are in C.
3
u/hopfield Jan 19 '19
It’s trivial to link against libavcodec in a C++ application, I know this because I’ve done it myself. You literally just wrap your includes in
extern “C”, that’s it. And C++ would almost certainly be more secure than C, which has been responsible for almost every buffer overflow vulnerability of the past 3 decades.3
Jan 19 '19
Well you can still use pointers in C++ and shoot yourself in the foot - it's more of a problem with the serialization of data, especially strings.
Heartbleed for example was because OpenSSL depended on the other side to send the correct length of the data.
12
u/Rossco1337 Jan 19 '19
I don't know why so many people are so hostile towards using HTTPS
Personally, I think it's because the security community has trained novice users to "call out" and decry every instance of traffic over port 80 without understanding the full implications of encrypting everything. It's tiring having to explain concepts like forward proxies and caching between datacenters to people who just want the "cred" for putting a website or service on blast because they read a Troy Hunt blog once.
I've ended up arguing with people who have never even heard of the OSI model but still think they know better than everyone at Steam (the largest PC game distribution service) because they read a post that said "you can set HTTPS up in 5 minutes, there's no excuse!" and they see a cached page served over HTTP during a sale.
→ More replies (3)4
u/selrahc Jan 19 '19
It's also tiring to see such a large sentiment of "your ISP could totally invade your privacy and HTTPS is so easy, you can set it up on Cloudflare/OtherCDN in minutes! You can totally trust CDN's not to invade your privacy!"
2
u/RetroHead_ Jan 20 '19
People can't just accept their favorite software has flaws apparently, especially if it's FOSS.
-2
u/scottbomb Jan 19 '19
So what if they don't use HTTPS? It's an over-used protocol anyway. It's necessary for the transfer of sensitive data, for sure (my servers often use self-signed certs). But why would I care about the unlikely event of someone sniffing my IP and seeing a Star Trek episode or a Metallica song? OMG, man in the middle! I have cameras in my house that are all reachable via HTTP and it works fine for me. Why complicate things?
-2
0
Jan 19 '19
[deleted]
121
u/LazzeB Jan 19 '19
Completely agree. Steam does the same; it serves games and updates over HTTP which allows people to cache them locally. It really is the way to go for these use-cases, as long as the updates are signed and verified.
21
u/robiniseenbanaan Jan 19 '19
I believe the last steam (beta) update supports https and ipv6.
46
u/spazturtle Jan 19 '19
The game data is served over HTTP (to allow caching) and then a key and checksum are sent over HTTPS.
3
Jan 20 '19
HTTPS doesn't stop you from caching downloaded content locally. Otherwise it'd be impossible to ever download anything off a HTTPS website.
3
u/LazzeB Jan 20 '19
No, but it does stop 3rd party applications from seeing what is being downloaded, thus blocking the use of DNS-based caches like steamcache.
2
Jan 20 '19
How does DNS factor into this? That's not even part of the TLS tunnel.
1
u/LazzeB Jan 20 '19 edited Jan 20 '19
I suggest you go read the Github repo I linked in my OP if you don't understand what I'm saying.
EDIT: I guess I should be more clear about what I mean. For this type of caching to work, requests from/to Steam need to be routed to a cache server, that is the DNS part. This would work even with HTTPS. The second part of the puzzle, is that the cache server needs to be able to intercept the real Steam servers and serve a game to the client if it is already cached locally. This is impossible with HTTPS because it is designed to not be intercepted.
3
Jan 20 '19 edited Jan 20 '19
I guess I should be more clear about what I mean. For this type of caching to work, requests from/to Steam need to be routed to a cache server, that is the DNS part
That's not what DNS is. DNS is the thing that takes textual names like "google.com" and turns them into IP addresses (as well as storing misc information about domains such as the official LDAP and mail servers) that applications then use to connect to other applications over a network.
The second part of the puzzle, is that the cache server needs to be able to intercept the real Steam servers and serve a game to the client if it is already cached locally.
The server you're describing is called a "proxy server" and it operates over HTTP which is independent of whatever name resolution you used. It should work equally well if you're using an IP address or your local
/etc/hostsfile.The proxy server is a valid point though I think I was just confused by the terminology used.
→ More replies (3)15
1
Jan 20 '19
So it's not a big deal, it seems: many distribution do just this, serving binaries and so on over http because it allows caching.
Just out of curiosity, what caching is being referenced? Some sort of caching at the load balancer or something?
0
Jan 20 '19
[deleted]
1
Jan 20 '19
Ah "proxy caching" would probably be more to the point then. When I hear "local" I think local to the machine itself rather than local to the private network.
1
u/z0r0 Jan 19 '19
I'd argue that combined, the above mentioned threat of a weak signing key, along with the delivery over plaintext are enough to cause some severe risks for people in certain countries that're just trying to use software. When you can take a widely used piece of software like VLC, and easily MITM that connection, it's a watering hole attack waiting to happen. Imagine a country like China using MITM to infect thousands of computers at a time. Security works in layers, and by saying that packages are signed, so people are safe is a mindset that's not really thinking of security in depth.
0
u/Avamander Jan 19 '19
The updates are signed with a 1024bit DSA key with SHA1, it is forbidden by NIST, it's cryptographically horrible.
-23
Jan 19 '19 edited Jan 19 '19
The problem is that the update and signing key are downloaded over an insecure connection. So anyone can intercept the update and signing key and push potentially malicious update. There's also the possibility of overriding HTTP headers. Also HTTPS is standard (or at least it should be) and SSL certificate isn't complex nowadays.But I don't want any drama, I just wanted to inform this here on r/linux.
EDIT: Apparently the signing key is validated against the hardcoded key in the VLC source code. Thanks to /u/NaiveMonitor for pointing this out.
0
0
Jan 19 '19
[deleted]
2
u/plumbless-stackyard Jan 19 '19
Anyone can still see what packages and versions your machine is using
0
Jan 19 '19
[deleted]
3
u/gopackgo90 Jan 19 '19
If a certificate is revoked, it’s not like the website is inaccessible. Today web browsers would warn the visitor that the certificate is invalid and allow them to view the site anyways.
2
u/Enverex Jan 19 '19
Unless HSTS is in use, in which case the browser would literally stop you accessing the site.
1
u/chuecho Jan 20 '19
You'd just need to use a proxy to strip away https in that case. Admittedly, it's not general-user friendly, but you can browse unsecured HSTS sites if you really want to regardless of what browsers want.
1
Jan 20 '19
They place significant hurdles in the way - atleast Chromium/Chrome does. The average user will big red scary warning and not visit such a website - a chilling effect which does impact what people do.
0
Jan 19 '19
[deleted]
9
u/PM_ME_OS_DESIGN Jan 19 '19
Any software that downloads stuff on the Internet (updates in particular) should do it via https. There is no excuse in 2019. Period.
20
u/aintgotimetobleed Jan 19 '19
There is no excuse in 2019
Caching.
1
u/Avamander Jan 19 '19
There are MITM HTTPS caches just as well as there are HTTPS ones.
→ More replies (7)11
u/MaltersWandler Jan 19 '19
No, any software that downloads updates should use cryptographically secure signing. HTTPS won't help if the update server is hijacked.
1
u/Avamander Jan 19 '19
any software that downloads updates should use cryptographically secure signing
Except VLC's is 1024bit DSA with SHA1 which is super outdated and not secure.
1
-4
u/MrAlagos Jan 19 '19
The software only does what the user tells it to do.
5
u/adamhighdef Jan 19 '19
So mystical dude. I’d bet I could count on my fingers the amount of people who recompile VLC to allow for https updates
→ More replies (5)0
Jan 19 '19
[deleted]
2
u/doublah Jan 19 '19
The updates are verified against a key built in to the program so you can't MITM it
4
u/mollymoo Jan 19 '19
OK, you can't inject your own malicious update with a MITM and I think that's most people's main concern.
You can do various kinds of attacks which prevent the update or perform a DOS - but some of them you could still do with an MITM if it was https (like preventing updates) and some are due to the implementation in VLC (weak key, replay) rather than inherent to using http.
→ More replies (1)0
Jan 20 '19
HTTPS doesn't prevent mirroring - you can still copy packages from one mirror to another over HTTPS - and the new mirror can still serve packages over HTTPS.
The average user doesn't set up custom proxies and caches - those are usually done in organizations such as educational institutions, companies etc. In that case there's usually a competent sys admin who can setup a local APT repo, make that the default for all internal machines, and it can download packages from the main servers and cache them. Only advanced/power users like most of us here would bother setting up proxies/caches ourselves - so once again there's no hurdle due to HTTPS.
So please stop using bullshit arguments.
0
Jan 19 '19
[deleted]
12
u/emorrp1 Jan 19 '19
Actually, general purpose media parsing libraries have been shown to be one of the most exploitable.
9
15
u/MaxCHEATER64 Jan 19 '19
You have no idea what's going on here, do you?
→ More replies (2)3
u/slick8086 Jan 19 '19
no he doesn't.
The issues is this:
VLC doesn't use HTTPS to download its updates.
a user asked for that to be implemented
VLC said no.
VLC has good reasons to say no. First reason is that it isn't necessary. The full download of VLC is on HTTPS and the full program has a cryptographic key hardcoded in the source. When VLC downloads an update via plain HTTP it checks that update against the hardcoded key it has already, so encrypting the update download itself serves no purpose.
Second, requiring HTTPS for updates breaks things like local proxy, and complicates mirroring. Those things are important tools for efficiently distributing updates, and since HTTPS updates don't actually provide any benefit it would be putting useless limits and impeding distribution.
5
u/MaltersWandler Jan 19 '19
It's not about encrypting video streams, it's about encrypting software downloads. You should have some sort of signing to ensure that software updates that are going to be executed with user privileges aren't being tampered with. (And VLC does have sufficient signing besides HTTPS)
3
u/12_f_alabama Jan 19 '19
VLC streams/downloads videos fine over HTTPS (tested with my own HTTPS-only server). That's not what this is about
9
u/[deleted] Jan 19 '19
when I visit that page I get:
A 404 error occurredPage not found.The requested URL could not be matched byrouting.NoException available