5 ms·

So your argument is that bugs in OpenSSL (a necessarily very complex piece of software) mean that using SSL to increase network security is a bad thing?

geofft 8y ago
No, their argument is that bugs in OpenSSL mean that using SSL when it does not actually increase network security is a bad thing. Reduce your attack surface. Use the things you need to use; don't use things you don't need to use. Whether apt using OpenSSL would in fact increase network security is a separate and debatable question, but the argument as stated assumes it would not, and is sound.
- zaarn 8y ago
  Defense in depth is a thing. SSL provides some security guarantees. Using signed package databases also provide some security guarantees. Both may overlap in what security they provide. BUT! If one fails, the other can continue to provide a subset of the previously available guarantees.
  - moviuro 8y ago
    Not in the case of OpenSSL, no. (Some) OpenSSL issues, just as (some) apt issues, end with RCE. Game over. Priv-sep, correctly handling untrusted files (e.g. 1. check signature, then 2. execute whatever; not the other way round), memory-safe languages, etc. would be more welcome additions.
    - tracker1 8y ago
      And overcoming both is much harder than overcoming either on their own.
      - moviuro 8y ago
        In the worst case, you only need to overcome one. And you ~double your attack surface.
        tracker1 8y ago
        Which one? If you gain control of a server, you'd still have to overcome signing... and you only control that single server, not all replicas (for a bug like in TFA). Could you describe a way to have double the attack surface that would effect the majority of peer servers?
    - blattimwind 8y ago
      > Priv-sep Apt even has the had part already implemented by separating the network I/O in other processes. Only problem is that those currently write directly to system directories, but that can be fixed.
moviuro 8y ago
No. My argument is that both arguments do exist and security is all about middle-ground. Do we add (yet another) layer of (bug-riddled) software to defeat one possible sort of exploits, or not? How much does it cost? (Time, money, etc.) Other options include: not handle http directly in the package manager but use a known-good library (curl?); do priv-sep; not having the package manager execute code from a file before it checked its authenticity... My personal opinion on the topic is that authenticating servers is a good thing to do (https does this; encryption is an added benefit), but time has shown that https is broken: libs are full of holes; the CA model is broken by design. Maybe share updates using ssh?
- deleted 8y ago
  [deleted]
- jmvoodoo 8y ago
  I think the point is that adding https over http for the current system would always improve security. At it's most broken, https is at least as secure as http and therefore wouldn't reduce the security of the overall system. It adds one more hurdle for an attacker to clear. Similarly, the apt team ignoring a bug like this "because it's protected by https anyway." Is an invalid argument.
  - moviuro 8y ago
    > adding https over http for the current system would always improve security No. If an attacker can inject packets that break your SSL lib, but wouldn't have broken your package manager, you added a vuln. Example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0545 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0545
    - jmvoodoo 8y ago
      Fair. There are specific library attacks that could result in RCE. However that is also true against curl, ssh, and for that matter could be introduced into your http library at some point. The question then becomes what library do you trust most? OpenSSL is attacked and tested constantly. Things have been found (in your example in 2003!). They have been fixed. Apt can choose to stand on it's shoulders, or go through the entire process themselves by putting together a patchwork of their own solutions that will no doubt get less testing by whitehats and be a juicy target for blackhats.

geofft 8y ago

No, their argument is that bugs in OpenSSL mean that using SSL when it does not actually increase network security is a bad thing. Reduce your attack surface. Use the things you need to use; don't use things you don't need to use. Whether apt using OpenSSL would in fact increase network security is a separate and debatable question, but the argument as stated assumes it would not, and is sound.

zaarn 8y ago
Defense in depth is a thing. SSL provides some security guarantees. Using signed package databases also provide some security guarantees. Both may overlap in what security they provide. BUT! If one fails, the other can continue to provide a subset of the previously available guarantees.
- moviuro 8y ago
  Not in the case of OpenSSL, no. (Some) OpenSSL issues, just as (some) apt issues, end with RCE. Game over. Priv-sep, correctly handling untrusted files (e.g. 1. check signature, then 2. execute whatever; not the other way round), memory-safe languages, etc. would be more welcome additions.
  - tracker1 8y ago
    And overcoming both is much harder than overcoming either on their own.
    - moviuro 8y ago
      In the worst case, you only need to overcome one. And you ~double your attack surface.
      - tracker1 8y ago
        Which one? If you gain control of a server, you'd still have to overcome signing... and you only control that single server, not all replicas (for a bug like in TFA). Could you describe a way to have double the attack surface that would effect the majority of peer servers?
  - blattimwind 8y ago
    > Priv-sep Apt even has the had part already implemented by separating the network I/O in other processes. Only problem is that those currently write directly to system directories, but that can be fixed.

moviuro 8y ago

No. My argument is that both arguments do exist and security is all about middle-ground. Do we add (yet another) layer of (bug-riddled) software to defeat one possible sort of exploits, or not? How much does it cost? (Time, money, etc.) Other options include: not handle http directly in the package manager but use a known-good library (curl?); do priv-sep; not having the package manager execute code from a file before it checked its authenticity... My personal opinion on the topic is that authenticating servers is a good thing to do (https does this; encryption is an added benefit), but time has shown that https is broken: libs are full of holes; the CA model is broken by design. Maybe share updates using ssh?

deleted 8y ago
[deleted]
jmvoodoo 8y ago
I think the point is that adding https over http for the current system would always improve security. At it's most broken, https is at least as secure as http and therefore wouldn't reduce the security of the overall system. It adds one more hurdle for an attacker to clear. Similarly, the apt team ignoring a bug like this "because it's protected by https anyway." Is an invalid argument.
- moviuro 8y ago
  > adding https over http for the current system would always improve security No. If an attacker can inject packets that break your SSL lib, but wouldn't have broken your package manager, you added a vuln. Example: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0545 https://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2003-0545
  - jmvoodoo 8y ago
    Fair. There are specific library attacks that could result in RCE. However that is also true against curl, ssh, and for that matter could be introduced into your http library at some point. The question then becomes what library do you trust most? OpenSSL is attacked and tested constantly. Things have been found (in your example in 2003!). They have been fixed. Apt can choose to stand on it's shoulders, or go through the entire process themselves by putting together a patchwork of their own solutions that will no doubt get less testing by whitehats and be a juicy target for blackhats.