3 ms·

whats the use-case for an encryption layer?

by 0x006A 7y ago

ggg2 7y ago
hiding packages you have installed from your ISP/NSA/etc. this discussion comes up time and time again (in rpm, apt et al). the consensus is: if you need that extra feature, manually download sensitive packages via ssl or something. everyone else (with nothing to hide, heh) keeps benefiting from a global cache of unencrypted transport of (mostly) open source data.
- pwnna 7y ago
  Does that help? I thought the package size is quite revealing.
  - isostatic 7y ago
    In some cases (although the server could presumably send some random length data headers if that's a concern), but if you download multiple packages on a single connection can it still be tracked?
    - vetinari 7y ago
      The sizes of all packages are a known information. So if someone is dedicated enough to track your downloaded packages, figuring out which ones were transferred with a single connection is relatively simple integer programming task. If you want to really hide what you are installing, make a local mirror of the entire repo and then pick and choose from that.
      - scheveningen 7y ago
        I thought _pmf_ was describing packages that he authored, and certainly if the contents of them are confidential, they would be in a private repository. I don't think that the RPMs that I have created in my internal repository and deploy to my field systems are a 'known information' to anyone outside of my organization. If they are, I'm in serious trouble. I think a more realistic use case for package-level encryption is deploying RPMs that have secrets in them (either keys/creds in configuration or trade secrets in application logic). Ideally of course we should encapsulate these such that they aren't deployed to field/embedded devices but in embedded there certainly may be some use-cases and requirements that those of us used to working in data center and cloud computing aren't immediately thinking of.
        deleted 7y ago
        [deleted]
- BuildTheRobots 7y ago
  Transport security & confidentiality makes sense (though at first I was trying to work out how an encrypted yum package would work). Yum with CentOS 6 and above does support SSL for mirror sites and a handful of global mirrors also support it (HEG being one). I suppose there's a slight race condition (eg how do I update the CA-Certificates bundle when I need the new CA-Certificates bundle to connect to the mirror site to download the update), however I tend to agree there should be some privacy as default.
- ses1984 7y ago
  You can cache things that are encrypted too, or do you think drm protected Netflix videos are all streamed from the origin? Yeah it's a bit more complicated...
  - forgottenpass 7y ago
    If by "origin" you mean "box Netflix has root on"... yes, I do think that?
  - rhinoceraptor 7y ago
    Netflix runs a fleet of their own CDN boxes, that they put in ISP data centers.
- solatic 7y ago
  As pwnna pointed out, package size gives you away. The real way to protect against this, if it's genuinely part of your threat model, is to maintain a complete local mirror: you can't tell what is installed and at what versions if you simply download everything. And if it's actually part of your threat model, then you likely have a large enough install base that you need a local mirror for performance/non-security reasons anyway. So it's really a non-issue.
- eeZah7Ux 7y ago
  The combination of IP addresses and package sizes is way too revealing. That's why APT supports Tor as a transport protocol.
scheveningen 7y ago
Personally I don't feel like the "hiding from the listener" use case discussed in the other response is very critical. What I think _pmf_ is getting at is an "only authorized devices may install my software, or view the RPMs". You could accomplish this having a keypair on your field/embedded devices, and then having the RPM distribution system pull each devices public key from the keyserver, build the RPM with encryption specifically for this device, and then push it out. Or maybe you choose to have a generic keypair for a class of devices. This could be used in cases where you have internal secrets in the RPMs you are building, or in the case of things like proprietary software and software licensing. I don't see how this applies to open source OS updates which is what I think the other sub-thread seems to be fixated on for some reason. Whether this belongs in the RPM system itself or in a wrapper format, I'm not so sure of.
_pmf_ 7y ago
This is for embedded Linux devices with a set of proprietary applications (small volume commercial/industrial control, no consumer device). Mostly non networked, so we have to distribute application updates via USB (in the networked case, we a use VPNs separated by customer groups to deliver updates, so this layer provides the encryption without requiring the update archive to be encrypted).

whats the use-case for an encryption layer?

by 0x006A 7y ago

whats the use-case for an encryption layer?

ggg2 7y ago

hiding packages you have installed from your ISP/NSA/etc. this discussion comes up time and time again (in rpm, apt et al). the consensus is: if you need that extra feature, manually download sensitive packages via ssl or something. everyone else (with nothing to hide, heh) keeps benefiting from a global cache of unencrypted transport of (mostly) open source data.

pwnna 7y ago
Does that help? I thought the package size is quite revealing.
- isostatic 7y ago
  In some cases (although the server could presumably send some random length data headers if that's a concern), but if you download multiple packages on a single connection can it still be tracked?
  - vetinari 7y ago
    The sizes of all packages are a known information. So if someone is dedicated enough to track your downloaded packages, figuring out which ones were transferred with a single connection is relatively simple integer programming task. If you want to really hide what you are installing, make a local mirror of the entire repo and then pick and choose from that.
    - scheveningen 7y ago
      I thought _pmf_ was describing packages that he authored, and certainly if the contents of them are confidential, they would be in a private repository. I don't think that the RPMs that I have created in my internal repository and deploy to my field systems are a 'known information' to anyone outside of my organization. If they are, I'm in serious trouble. I think a more realistic use case for package-level encryption is deploying RPMs that have secrets in them (either keys/creds in configuration or trade secrets in application logic). Ideally of course we should encapsulate these such that they aren't deployed to field/embedded devices but in embedded there certainly may be some use-cases and requirements that those of us used to working in data center and cloud computing aren't immediately thinking of.
      - deleted 7y ago
        [deleted]
BuildTheRobots 7y ago
Transport security & confidentiality makes sense (though at first I was trying to work out how an encrypted yum package would work). Yum with CentOS 6 and above does support SSL for mirror sites and a handful of global mirrors also support it (HEG being one). I suppose there's a slight race condition (eg how do I update the CA-Certificates bundle when I need the new CA-Certificates bundle to connect to the mirror site to download the update), however I tend to agree there should be some privacy as default.
ses1984 7y ago
You can cache things that are encrypted too, or do you think drm protected Netflix videos are all streamed from the origin? Yeah it's a bit more complicated...
- forgottenpass 7y ago
  If by "origin" you mean "box Netflix has root on"... yes, I do think that?
- rhinoceraptor 7y ago
  Netflix runs a fleet of their own CDN boxes, that they put in ISP data centers.
solatic 7y ago
As pwnna pointed out, package size gives you away. The real way to protect against this, if it's genuinely part of your threat model, is to maintain a complete local mirror: you can't tell what is installed and at what versions if you simply download everything. And if it's actually part of your threat model, then you likely have a large enough install base that you need a local mirror for performance/non-security reasons anyway. So it's really a non-issue.
eeZah7Ux 7y ago
The combination of IP addresses and package sizes is way too revealing. That's why APT supports Tor as a transport protocol.

scheveningen 7y ago

Personally I don't feel like the "hiding from the listener" use case discussed in the other response is very critical. What I think _pmf_ is getting at is an "only authorized devices may install my software, or view the RPMs". You could accomplish this having a keypair on your field/embedded devices, and then having the RPM distribution system pull each devices public key from the keyserver, build the RPM with encryption specifically for this device, and then push it out. Or maybe you choose to have a generic keypair for a class of devices. This could be used in cases where you have internal secrets in the RPMs you are building, or in the case of things like proprietary software and software licensing. I don't see how this applies to open source OS updates which is what I think the other sub-thread seems to be fixated on for some reason. Whether this belongs in the RPM system itself or in a wrapper format, I'm not so sure of.

_pmf_ 7y ago

This is for embedded Linux devices with a set of proprietary applications (small volume commercial/industrial control, no consumer device). Mostly non networked, so we have to distribute application updates via USB (in the networked case, we a use VPNs separated by customer groups to deliver updates, so this layer provides the encryption without requiring the update archive to be encrypted).