3 ms·

"I said we do not need to encrypt everything" ... as justified by many arguments from ignorance, like "I don't think everyone ...", and "There is no technical

by fche 11y ago

"I said we do not need to encrypt everything" ... as justified by many arguments from ignorance, like "I don't think everyone ...", and "There is no technical reason..." over and over. Even one counterexample for those (some helpfully supplied in comments hereabouts) makes the arguments invalid.

the_mitsuhiko 11y ago
> ... as justified by many arguments from ignorance, like "I don't think everyone ...", and "There is no technical reason..." over and over. Even one counterexample for those (some helpfully supplied in comments hereabouts) makes the arguments invalid. I gave one very practical example of encryption being applied to file transfers without a technical reason why that has to be. The same applies to the majority of resources fetched from CDNs. The only reason we use SSL for that is because there is no other method that browsers currently support for guaranteeing the integrity of the loaded information.
- Nursie 11y ago
  Authentication and Integrity are just as much part of SSL/TLS as secrecy is. For code I'm going to run on my system, I quite like the idea that I can tell where it comes from and if it's correct. When it comes down to it, it's nobody else's business what python code-modules I'm downloading, it might give them enough information to attack my servers, so secrecy isn't a bad thing either.
  - aidos 11y ago
    To be fair, Armin presented the solution to the first argument in the form of checksums. Your 2nd argument is valid though. I also think it's a bit of a shame that we're having to do all this encryption these days. Think of all that wonderful caching capability we're losing. Still, I come down on the side of "necessary evil", given the increasingly malicious attacks on parties that aren't using it.
  - the_mitsuhiko 11y ago
    > When it comes down to it, it's nobody else's business what python code-modules I'm downloading, it might give them enough information to attack my servers, so secrecy isn't a bad thing either. There is much bigger issue there: nobody verifies package signatures. Most packages do not even have ones. So you fundamentally have no way to verify that what you downloaded is what you wanted. Someone could have stolen my PyPI access credentials and uploaded a broken package under one of my releases. Or I'm just a bad person and would ship you bad code. SSL does not solve that problem.
    - Nursie 11y ago
      >> There is much bigger issue there: nobody verifies package signatures. Most packages do not even have ones. This is bad practice, and is not solved by less integrity and authenticity checking! >> Or I'm just a bad person and would ship you bad code. Nobody said it solves everything, but it does help prevent unrelated third parties getting in on the act, actively or passively.
      - the_mitsuhiko 11y ago
        > This is bad practice, and is not solved by less integrity and authenticity checking! No, it's a completely orthogonal issue which was my point. But you were bringing up a potential security issue which is that people might know what packages you are using. I'm bringing up that you are installing completely untrusted packages which is your actual issue there, not that someone might be able to know what you are using. Let alone that with AGPL libraries for instance you are required to disclose that anyways.
        Nursie 11y ago
        >> I'm bringing up that you are installing completely untrusted packages which is your actual issue there, not that someone might be able to know what you are using. There are multiple 'actual' issues here. One, you have identified, is that the content on the server is not very well verified. This is a problem I agree, and solutions are likely non-trivial. TLS will not fix this for you. The second one is making sure that what is on the server is accurately replicated on the client. Authentication (am I talking to the real server?) and integrity checking (did I really get what the server tried to send me?) are important here. TLS can address this. The third is giving away information about modules installed, which may be another risk. TLS will mitigate this. You're right that the AGPL would require you to disclose to any user which modules are in use and give over the source to anyone that uses your service and asks for it, and in general security by obscurity is a bad idea anyway - however I may not have users, I may be setting up a server only for me to access, and I may not want passive traffic sniffers to know that my experimental server is likely to be running an easily-compromised version of a service for the next five minutes until I patch it.

by fche 11y ago

the_mitsuhiko 11y ago

> ... as justified by many arguments from ignorance, like "I don't think everyone ...", and "There is no technical reason..." over and over. Even one counterexample for those (some helpfully supplied in comments hereabouts) makes the arguments invalid. I gave one very practical example of encryption being applied to file transfers without a technical reason why that has to be. The same applies to the majority of resources fetched from CDNs. The only reason we use SSL for that is because there is no other method that browsers currently support for guaranteeing the integrity of the loaded information.

Nursie 11y ago
Authentication and Integrity are just as much part of SSL/TLS as secrecy is. For code I'm going to run on my system, I quite like the idea that I can tell where it comes from and if it's correct. When it comes down to it, it's nobody else's business what python code-modules I'm downloading, it might give them enough information to attack my servers, so secrecy isn't a bad thing either.
- aidos 11y ago
  To be fair, Armin presented the solution to the first argument in the form of checksums. Your 2nd argument is valid though. I also think it's a bit of a shame that we're having to do all this encryption these days. Think of all that wonderful caching capability we're losing. Still, I come down on the side of "necessary evil", given the increasingly malicious attacks on parties that aren't using it.
- the_mitsuhiko 11y ago
  > When it comes down to it, it's nobody else's business what python code-modules I'm downloading, it might give them enough information to attack my servers, so secrecy isn't a bad thing either. There is much bigger issue there: nobody verifies package signatures. Most packages do not even have ones. So you fundamentally have no way to verify that what you downloaded is what you wanted. Someone could have stolen my PyPI access credentials and uploaded a broken package under one of my releases. Or I'm just a bad person and would ship you bad code. SSL does not solve that problem.
  - Nursie 11y ago
    >> There is much bigger issue there: nobody verifies package signatures. Most packages do not even have ones. This is bad practice, and is not solved by less integrity and authenticity checking! >> Or I'm just a bad person and would ship you bad code. Nobody said it solves everything, but it does help prevent unrelated third parties getting in on the act, actively or passively.
    - the_mitsuhiko 11y ago
      > This is bad practice, and is not solved by less integrity and authenticity checking! No, it's a completely orthogonal issue which was my point. But you were bringing up a potential security issue which is that people might know what packages you are using. I'm bringing up that you are installing completely untrusted packages which is your actual issue there, not that someone might be able to know what you are using. Let alone that with AGPL libraries for instance you are required to disclose that anyways.
      - Nursie 11y ago
        >> I'm bringing up that you are installing completely untrusted packages which is your actual issue there, not that someone might be able to know what you are using. There are multiple 'actual' issues here. One, you have identified, is that the content on the server is not very well verified. This is a problem I agree, and solutions are likely non-trivial. TLS will not fix this for you. The second one is making sure that what is on the server is accurately replicated on the client. Authentication (am I talking to the real server?) and integrity checking (did I really get what the server tried to send me?) are important here. TLS can address this. The third is giving away information about modules installed, which may be another risk. TLS will mitigate this. You're right that the AGPL would require you to disclose to any user which modules are in use and give over the source to anyone that uses your service and asks for it, and in general security by obscurity is a bad idea anyway - however I may not have users, I may be setting up a server only for me to access, and I may not want passive traffic sniffers to know that my experimental server is likely to be running an easily-compromised version of a service for the next five minutes until I patch it.