6 ms·

What they mean is: a Man in the middle attack is very unlikely and not easy to setup. They will not spend time on this issue untill the OP has a valid threat mo

What they mean is: a Man in the middle attack is very unlikely and not easy to setup. They will not spend time on this issue untill the OP has a valid threat model. Which the OP has not given. They already cryptographically sign and validate the updates, which is why it is ignored. It's another solution for the same problem ( reducing change of a malicious update) PS. > This is a security risk and should be solved ASAP. Thanks This has a unfriendly tone of the OP. I would have done the exact same thing in the same situation as the VLC developers ( since there is already a solution implemented).

eponeponepon 8y ago
Yeah, this doesn't really hold water when your software is as widely installed as VLC - I've lost count of the number of deeply nontechnical people I've installed it for, for what that's worth. Checking file sizes is serious half-assing IMO - it's not beyond the wit of teenagers running a botnet to deal with that, never mind determined criminals.
- NicoJuicy 8y ago
  NASA could also be hacked by determined criminals, VLC hasn't got unlimited resources to spend. The HTTPS change could be easy, but you don't know what other things can be affected at first glance ( eg. update mechanism on older versions with no https support). If the attackers can do a MITM, they probably also have other stuff at their disposal :) But more important, issue the bug with a valid threat model and it could be fixed. As long as there is no threat model and perhaps an active discussion ( this is how open source works), the ticket stays closed. The OP had 2,5 days to respond.
  - DoctorOetker 8y ago
    so suddenly the onus of developing the threat model is on the user? I believe both devs and users should have the liberty to discuss and propose threat models, but if there already is "some level of precaution" the real question is where was the previous threat model that dictates signing? or is this security theater?
    - NicoJuicy 8y ago
      If the developers think there is no threat. Then yes, it is for the user to prove this.
      - DoctorOetker 8y ago
        you can't prove a threat model. a threat model is part of what is in or out of scope. the first thing that should happen is for VLC dev to set up a threat model, if the user base disagrees with the narrow scope of the VLC threat model they should fork. the second thing that can then happen is that given a threat model, a user could file a bug report to complain how a certain hypothetical attack (within scope of the threat model) violates the security. think about it this way: for all non-security bugs, would you ask users to "prove that resolving a certain bug is within scope of the project"? how can a user prove what is within the developers' scope?
        theamk 8y ago
        I think you are making a wrong analogy here. A "threat model" in security is like a "user operation" for the feature. So in the non-security bug world, the exchange would look like: Bug report: the program is missing blue circle in the top right corner. Please add is ASAP. Developer response: what would possibly be the use of this feature? Please tell me of I will close the bug.
        NicoJuicy 8y ago
        Here is a decent developer response: https://www.beauzee.fr/2017/07/04/videolan-and-https/ https://www.beauzee.fr/2017/07/04/videolan-and-https/
  - lowry 8y ago
    > HTTPS change could be easy Yes, but it adds load on download servers and increases the cost of serving VLC to users.
- jjeaff 8y ago
  They don't cryptographically sign the updates as the op mentioned?
  - dcbadacd 8y ago
    They do, with 1024bit DSA with SHA1. Cryptographically weak and forbidden by the NIST.
    - jjeaff 8y ago
      While yes, it is considered weak, that doesn't mean it is useless. Git uses Sha1 and a lot of other services do as well. Using it to validate and sign an update is probably still pretty much safe as I have only ever seen or heard of a single SHA1 collision ever. And that was in 2017. It took them 6500 years of CPU computation time and 110 years of GPU computation time to find it. I think we can consider SHA1 good enough to sign VLC updates for now. https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html https://security.googleblog.com/2017/02/announcing-first-sha...
toomuchtodo 8y ago
I brought the same issue up with Tesla about their firmware updates not being encrypted in transit, and their argument was the updates are cryptographically signed. Good enough I suppose.
gamma-male 8y ago
Coincidentally, there was a post yesterday on HN about how to communicate to developers. Sounds like they didn't read it. https://www.cryptologie.net/article/466/developers-are-not-idiots/ https://www.cryptologie.net/article/466/developers-are-not-i...
- NicoJuicy 8y ago
  Yeah, i was trying to edit my comment with variations of: 1) PS ...{text} and would loathe the open source model for a second. 2) PS2. Some sign of respect to developers would be nice (y) 3) ... But haven't found a good one. Your comment is better :)
cjbprime 8y ago
It looks like their crypto validation is busted, according to a commenter.
- NicoJuicy 8y ago
  Then this issue should still be closed and the validation should be fixed. End result for this issue is the same. Also, a comment is not the same as posting a bug.
  - fhrow4484 8y ago
    You might be interested in the concept of "Defense in depth": https://en.m.wikipedia.org/wiki/Defense_in_depth_(computing) https://en.m.wikipedia.org/wiki/Defense_in_depth_(computing). If the effort is minimal to migrate from HTTP to HTTPS, there's no reason to not do it and to fix the validation. In fact, if the HTTPS change is faster, this should be prioritized, given that the other issue might take a lot of time to fix: the old validation mechanism will have to be supported for a long time to keep older clients backwards compatible... I'd take that the VLC guy had a bad day, otherwise that'd be a terrible reaction from someone involved in computer security.
    - NicoJuicy 8y ago
      We just read what is posted in the bug report. We have no knowledge of "technical debt" or technical issues migrating from http to https. Videolan has 5 applications, perhaps all of them use the same update mechanism, which would broathen the scope of the fix. What seems trivial (i agree), isn't always that in the software world. We need business knowledge of the VLC source or architecture for having a clear decision. For what it's worth. I'll give the VLC developers the benefit of the doubt.
      - BTeam 8y ago
        They have a network of voluntary mirrors using very different stacks that give them storage and bandwidth for free. Similar to Debian's APT [0]. VideoLAN isn't in a position to enforce it's hosts to serve the files over TLS. However the cryptography of the signature check will be updated in the future. [0] https://whydoesaptnotusehttps.com/ https://whydoesaptnotusehttps.com/
userbinator 8y ago
I remember when Microsoft released Win7 the ISOs were downloadable through HTTP direct links, and MS published the hashes on an HTTPS page. Similar idea, different implementation... and if cryptographic signing is good enough for a company like Microsoft, it should be good enough for VLC.
- dcbadacd 8y ago
  I really do not agree with any arguments that are just saying "they're doing it, so may I".
  - NicoJuicy 8y ago
    Perhaps he's saying: Microsoft didn't find a threat model. The VLC developers had the same conclusion. So the issue should still be closed according to the supplied information in the bug post submission.
deleted 8y ago
[deleted]
DoctorOetker 8y ago
what you claim is in contradiction with what eps claims at https://news.ycombinator.com/item?id=18948449 https://news.ycombinator.com/item?id=18948449 I don't know who is right, but you claim the update needs to be signed, but eps says that it also allows the update to be signed by a key retrieved over insecure HTTP which of course can be MitM'ed. I guess the threat model includes malicious ISP's / governments, so as a user you want a clear delineation of responsibility, and have VLC either 1) use a backup master key to sign the signing key, so if the signing keys is compromised a new key can be issued from an airgapped system or 2) insist VLC retrieve the second key over HTTPS. I would prefer 1) though...
- theamk 8y ago
  > I don't know who is right hm.. we have one of the software authors and a random by-stander arguing about the code? I know who I would bet on. (Note that if it were a political question, then yes, opinions of any random bystander are potentially as valuable as software authors'. But it is not. I need to see a specific evidence before trusting random strangers)
guenthert 8y ago
>> This is a security risk and should be solved ASAP. Thanks > This has a unfriendly tone of the OP. Having lived on both sides of the pond, I'm aware of differences, but in which culture is that considered rude? You're addressing computer geeks, not the King of Thailand.
- NicoJuicy 8y ago
  He is commanding them to fix it ASAP The thanks afterwards is meant for after they have done it and makes it worse. What he actually says is: The bug is posted, I offered the solution. Fix it and I won't follow up on this. Which would be something what a boss would say.
  - guenthert 8y ago
    I read ASAP as "as soon as possible", which arguably applies to all security bugs. > The thanks afterwards is meant for after they have done it and makes it worse. That used to trigger me in the past as well, but it is deeply ingrained in corporate communication (at least of West Coast USA). Just ignore it, you can't fight it. > Which would be something what a boss would say. I thought so in the past as well, but now everybody uses it. Thanks for clarifying :)
    - NicoJuicy 8y ago
      You're welcome :)
  - deleted 8y ago
    [deleted]
  - j0hnny_r3db34rd 8y ago
    No, he isn't.
userbinator 8y ago
I've noticed that anything "security" related tends to attract lots of loud-mouthed authoritarian cargo-culting do-gooders, and for this reason I prefer to distance myself from them as much as possible. Perhaps it's a prerequisite for this type of work (in the real world, think of police, TSA border guards, etc...)

eponeponepon 8y ago

Yeah, this doesn't really hold water when your software is as widely installed as VLC - I've lost count of the number of deeply nontechnical people I've installed it for, for what that's worth. Checking file sizes is serious half-assing IMO - it's not beyond the wit of teenagers running a botnet to deal with that, never mind determined criminals.

NicoJuicy 8y ago
NASA could also be hacked by determined criminals, VLC hasn't got unlimited resources to spend. The HTTPS change could be easy, but you don't know what other things can be affected at first glance ( eg. update mechanism on older versions with no https support). If the attackers can do a MITM, they probably also have other stuff at their disposal :) But more important, issue the bug with a valid threat model and it could be fixed. As long as there is no threat model and perhaps an active discussion ( this is how open source works), the ticket stays closed. The OP had 2,5 days to respond.
- DoctorOetker 8y ago
  so suddenly the onus of developing the threat model is on the user? I believe both devs and users should have the liberty to discuss and propose threat models, but if there already is "some level of precaution" the real question is where was the previous threat model that dictates signing? or is this security theater?
  - NicoJuicy 8y ago
    If the developers think there is no threat. Then yes, it is for the user to prove this.
    - DoctorOetker 8y ago
      you can't prove a threat model. a threat model is part of what is in or out of scope. the first thing that should happen is for VLC dev to set up a threat model, if the user base disagrees with the narrow scope of the VLC threat model they should fork. the second thing that can then happen is that given a threat model, a user could file a bug report to complain how a certain hypothetical attack (within scope of the threat model) violates the security. think about it this way: for all non-security bugs, would you ask users to "prove that resolving a certain bug is within scope of the project"? how can a user prove what is within the developers' scope?
      - theamk 8y ago
        I think you are making a wrong analogy here. A "threat model" in security is like a "user operation" for the feature. So in the non-security bug world, the exchange would look like: Bug report: the program is missing blue circle in the top right corner. Please add is ASAP. Developer response: what would possibly be the use of this feature? Please tell me of I will close the bug.
        NicoJuicy 8y ago
        Here is a decent developer response: https://www.beauzee.fr/2017/07/04/videolan-and-https/ https://www.beauzee.fr/2017/07/04/videolan-and-https/
- lowry 8y ago
  > HTTPS change could be easy Yes, but it adds load on download servers and increases the cost of serving VLC to users.
jjeaff 8y ago
They don't cryptographically sign the updates as the op mentioned?
- dcbadacd 8y ago
  They do, with 1024bit DSA with SHA1. Cryptographically weak and forbidden by the NIST.
  - jjeaff 8y ago
    While yes, it is considered weak, that doesn't mean it is useless. Git uses Sha1 and a lot of other services do as well. Using it to validate and sign an update is probably still pretty much safe as I have only ever seen or heard of a single SHA1 collision ever. And that was in 2017. It took them 6500 years of CPU computation time and 110 years of GPU computation time to find it. I think we can consider SHA1 good enough to sign VLC updates for now. https://security.googleblog.com/2017/02/announcing-first-sha1-collision.html https://security.googleblog.com/2017/02/announcing-first-sha...

toomuchtodo 8y ago

I brought the same issue up with Tesla about their firmware updates not being encrypted in transit, and their argument was the updates are cryptographically signed. Good enough I suppose.

gamma-male 8y ago

Coincidentally, there was a post yesterday on HN about how to communicate to developers. Sounds like they didn't read it. https://www.cryptologie.net/article/466/developers-are-not-idiots/ https://www.cryptologie.net/article/466/developers-are-not-i...

NicoJuicy 8y ago
Yeah, i was trying to edit my comment with variations of: 1) PS ...{text} and would loathe the open source model for a second. 2) PS2. Some sign of respect to developers would be nice (y) 3) ... But haven't found a good one. Your comment is better :)

cjbprime 8y ago

It looks like their crypto validation is busted, according to a commenter.

NicoJuicy 8y ago
Then this issue should still be closed and the validation should be fixed. End result for this issue is the same. Also, a comment is not the same as posting a bug.
- fhrow4484 8y ago
  You might be interested in the concept of "Defense in depth": https://en.m.wikipedia.org/wiki/Defense_in_depth_(computing) https://en.m.wikipedia.org/wiki/Defense_in_depth_(computing). If the effort is minimal to migrate from HTTP to HTTPS, there's no reason to not do it and to fix the validation. In fact, if the HTTPS change is faster, this should be prioritized, given that the other issue might take a lot of time to fix: the old validation mechanism will have to be supported for a long time to keep older clients backwards compatible... I'd take that the VLC guy had a bad day, otherwise that'd be a terrible reaction from someone involved in computer security.
  - NicoJuicy 8y ago
    We just read what is posted in the bug report. We have no knowledge of "technical debt" or technical issues migrating from http to https. Videolan has 5 applications, perhaps all of them use the same update mechanism, which would broathen the scope of the fix. What seems trivial (i agree), isn't always that in the software world. We need business knowledge of the VLC source or architecture for having a clear decision. For what it's worth. I'll give the VLC developers the benefit of the doubt.
    - BTeam 8y ago
      They have a network of voluntary mirrors using very different stacks that give them storage and bandwidth for free. Similar to Debian's APT [0]. VideoLAN isn't in a position to enforce it's hosts to serve the files over TLS. However the cryptography of the signature check will be updated in the future. [0] https://whydoesaptnotusehttps.com/ https://whydoesaptnotusehttps.com/

userbinator 8y ago

I remember when Microsoft released Win7 the ISOs were downloadable through HTTP direct links, and MS published the hashes on an HTTPS page. Similar idea, different implementation... and if cryptographic signing is good enough for a company like Microsoft, it should be good enough for VLC.

dcbadacd 8y ago
I really do not agree with any arguments that are just saying "they're doing it, so may I".
- NicoJuicy 8y ago
  Perhaps he's saying: Microsoft didn't find a threat model. The VLC developers had the same conclusion. So the issue should still be closed according to the supplied information in the bug post submission.

deleted 8y ago

[deleted]

DoctorOetker 8y ago

what you claim is in contradiction with what eps claims at https://news.ycombinator.com/item?id=18948449 https://news.ycombinator.com/item?id=18948449 I don't know who is right, but you claim the update needs to be signed, but eps says that it also allows the update to be signed by a key retrieved over insecure HTTP which of course can be MitM'ed. I guess the threat model includes malicious ISP's / governments, so as a user you want a clear delineation of responsibility, and have VLC either 1) use a backup master key to sign the signing key, so if the signing keys is compromised a new key can be issued from an airgapped system or 2) insist VLC retrieve the second key over HTTPS. I would prefer 1) though...

theamk 8y ago
> I don't know who is right hm.. we have one of the software authors and a random by-stander arguing about the code? I know who I would bet on. (Note that if it were a political question, then yes, opinions of any random bystander are potentially as valuable as software authors'. But it is not. I need to see a specific evidence before trusting random strangers)

guenthert 8y ago

>> This is a security risk and should be solved ASAP. Thanks > This has a unfriendly tone of the OP. Having lived on both sides of the pond, I'm aware of differences, but in which culture is that considered rude? You're addressing computer geeks, not the King of Thailand.

NicoJuicy 8y ago
He is commanding them to fix it ASAP The thanks afterwards is meant for after they have done it and makes it worse. What he actually says is: The bug is posted, I offered the solution. Fix it and I won't follow up on this. Which would be something what a boss would say.
- guenthert 8y ago
  I read ASAP as "as soon as possible", which arguably applies to all security bugs. > The thanks afterwards is meant for after they have done it and makes it worse. That used to trigger me in the past as well, but it is deeply ingrained in corporate communication (at least of West Coast USA). Just ignore it, you can't fight it. > Which would be something what a boss would say. I thought so in the past as well, but now everybody uses it. Thanks for clarifying :)
  - NicoJuicy 8y ago
    You're welcome :)
- deleted 8y ago
  [deleted]
- j0hnny_r3db34rd 8y ago
  No, he isn't.

userbinator 8y ago

I've noticed that anything "security" related tends to attract lots of loud-mouthed authoritarian cargo-culting do-gooders, and for this reason I prefer to distance myself from them as much as possible. Perhaps it's a prerequisite for this type of work (in the real world, think of police, TSA border guards, etc...)