10 replies to this topic

[David85]

Looks like downloads on https://openpli.org/download/ as well as downloads performed by opkg are done via HTTP (without SSL/TLS).

 

Are the opkg packages signed and is signature verification enforced?

 

Are there any plans for release (flashable) downloads over HTTPS and/or putting hashes/signatures of the releases available via HTTPS?

[WanWizard]

Yes, implementing SSL for downloading files is a waste of resources. And no, there are no plans to implement it, it means (with our download volume) quite a substantial hardware investment.

 

What is it that you want to achieve, i.e. what are you afraid of ?

 

afaik opkg doesn't support any signing, so that isn't going to happen anyway.

[Erik Slagter]

If TS is worried that much, he should build it's own PLi based image...

[David85]

AFAIK opkg supports GPG based signing:

https://stackoverflow.com/a/39972015

http://wiki.openmoko.org/wiki/Opkg

https://groups.googl...Zsk4/discussion

 

The goal of HTTPS or signatures is malware prevention. It is extremely easy to "reroute" traffic in metro ethernet networks (so in larger networks there usually are "naughty" neighbors who hijack traffic, steal HTTP passwords/cookies and infect HTTP downloads, though usually Windows executables are the files getting infected).
Also it might be feasible for some botnet operators to infect OpenPLi distribution network (either by compromising download servers, or by some DNS hijack etc.). Of course HTTPS wouldn't help much in this case, but GPG signatures could/would (assuming signing buildservers aren't compromised). Also GPG signatures for flashable builds could help in this case.

[WanWizard]

There is nothing to steal, so in-transit protection isn't required. And if our distribution network is compromised, that means the secure datacenter of our hosting company is compromised (we use a corporate hosting environment, not direct internet attached servers or VPSses), in which case not having TLS in transit is the least of our worries.

 

If GPG signing is enabled, you immediately block all other people of buidling an image from our source, and you immediately block creation of packages by third parties, as obviously we would keep our private key secret. So while that is a possibility, it is complex and has a lot of downsides, it is not something one would implement on a whim...

[littlesat]

Never heard about the man in the middle attack...?

Edited by littlesat, 30 October 2018 - 00:26.

[Pr2]

Never heard about the man in the middle attack...?

 

It is a technique that instead of having a true direct client - real server connection, by for exemple cheating the client DNS the traffic is redirected to an hacker server that can inject or intercept traffic between client and server because the connection became:   client - hacker - real server (the hacker is the man in the middle).

[technic]

Certain ISP like to intercept http connections. I would prefer to have more privacy. Also if router is compromised, and you know how insecure they are, https will protect stb from getting mailware packages.

Sent from my MI 4LTE using Tapatalk

[Erik Slagter]

Certain ISP like to intercept http connections. I would prefer to have more privacy. Also if router is compromised, and you know how insecure they are, https will protect stb from getting mailware packages.

ROFL!!!! Indeed, always make sure your ISP doesn't know what enigma plugins you're downloading!!!

Edited by Erik Slagter, 30 October 2018 - 19:09.

[technic]

How about second part of my message.


Sent from my MI 4LTE using Tapatalk

[Erik Slagter]

The chance of your STB getting malware using this route is nihil compared to the chance getting malware because it's reachable over the internet, from outside. As a volunteers based society we don't have the resources to add TLS to the feed downloads, given the amount of traffic the feeds generate.