4 ms·

I've been trying to convince <Kong>, the owner/(brother of owner) of that desire.de site (btw not the official repo) to implement HTTPS and caching using Let's

I've been trying to convince <Kong>, the owner/(brother of owner) of that desire.de site (btw not the official repo) to implement HTTPS and caching using Let's Encrypt and Cloudflare and not just rely on signed binaries but he's insistent that his method of just signing the binaries is sufficient secure. Maybe if sufficient number of people pester him about it. EDIT: On a related note, I've been trying to get the ddwrt guys to improve their HTTPS setup (ciphers etc.) without much success. To me, testing with testssl.sh and fixing the errors that pop up is easy and not that much work.

lallysingh 10y ago
Why isn't it? I'm sorry, I'm genuinely curious.
- tajen 10y ago
  Over what channel do you retrieve the signature?
  - yoha 10y ago
    A signature is not a hash. As long as you know the right public key (which only needs to be transferred once), you can verify the legitimacy of the signature regardless of how it was transmitted.
  - lallysingh 10y ago
    Isn't the signature part of the executable?
deno 10y ago
Transferring signed packages over TLS only prevents the attacker from observing which particular packages are being updated, and that’s assuming the padding alone is sufficient to obscure identification by size. Otherwise signing packages is actually preferred, because you can do it offline, so that hacking the server is not enough to push malicious code.
- kevinchen 10y ago
  But that assumes hardware vendors' signature verification code is correct -- and crypto is really hard to get right
  - pricechild 10y ago
    You don't need to verify it on the target system though?
    - matthewaveryusa 10y ago
      You sign at the source with a private key, and you verify on the target with the public key. The trick is only someone with the private key can create a signature that the public key can verify.
      - bigiain 10y ago
        The other problem is many people wont have pre-existing copies of the required private key available. If your attacker is in a position to MitM your download of a signed binary, they're probably also in a position to MitM your retrieval of the public key. SSL/TLS certainly helps there (at least the attacker then also needs to be capable of acquiring root CA signed TLS certs for the download site and any readily available PGP key sites. It wont slow the NSA down much - but it will help against the guy with the WiFi Pineapple in your local Starbucks…)
        merijnv 10y ago
        > The other problem is many people wont have pre-existing copies of the required private key available. We're talking about software updates, you embed the key INSIDE the software to avoid this problem.
        bigiain 10y ago
        Ahhh, good catch... Agreed. (Though with my overly-cynical hat on, I now just suspect you've only moved the problem to the previous update's authentication - and recursively back to the initial download. How do you protect against the initial download being MitMed and having an attacker's public key inserted - this is functionally the same as HSTS - if you can MitM the first visit you win...)
AdamN 10y ago
He's not totally wrong. If the package is signed and the public key is trusted (the bigger 'if' actually) and the package signature passes - then it doesn't matter how it was transported. Even email is fine. With that said, security needs to be in layers and defense in depth is critical, especially for this type of core infrastructure. He should upgrade all infrastructure points for better security where feasible. There's also the political reason not to use Cloudflare ... we're quickly moving to a darker Internet where traffic goes into networks like Cloudflare and nobody knows what happens inside the black box. I wonder if that's where the resistance lies.
- breakingcups 10y ago
  The problem with that is that, if you as a malicious third person can MITM the http connection for updates, you can push an older signed package with known vulnerabilities.

lallysingh 10y ago

Why isn't it? I'm sorry, I'm genuinely curious.

tajen 10y ago
Over what channel do you retrieve the signature?
- yoha 10y ago
  A signature is not a hash. As long as you know the right public key (which only needs to be transferred once), you can verify the legitimacy of the signature regardless of how it was transmitted.
- lallysingh 10y ago
  Isn't the signature part of the executable?

deno 10y ago

Transferring signed packages over TLS only prevents the attacker from observing which particular packages are being updated, and that’s assuming the padding alone is sufficient to obscure identification by size. Otherwise signing packages is actually preferred, because you can do it offline, so that hacking the server is not enough to push malicious code.

kevinchen 10y ago
But that assumes hardware vendors' signature verification code is correct -- and crypto is really hard to get right
- pricechild 10y ago
  You don't need to verify it on the target system though?
  - matthewaveryusa 10y ago
    You sign at the source with a private key, and you verify on the target with the public key. The trick is only someone with the private key can create a signature that the public key can verify.
    - bigiain 10y ago
      The other problem is many people wont have pre-existing copies of the required private key available. If your attacker is in a position to MitM your download of a signed binary, they're probably also in a position to MitM your retrieval of the public key. SSL/TLS certainly helps there (at least the attacker then also needs to be capable of acquiring root CA signed TLS certs for the download site and any readily available PGP key sites. It wont slow the NSA down much - but it will help against the guy with the WiFi Pineapple in your local Starbucks…)
      - merijnv 10y ago
        > The other problem is many people wont have pre-existing copies of the required private key available. We're talking about software updates, you embed the key INSIDE the software to avoid this problem.
        bigiain 10y ago
        Ahhh, good catch... Agreed. (Though with my overly-cynical hat on, I now just suspect you've only moved the problem to the previous update's authentication - and recursively back to the initial download. How do you protect against the initial download being MitMed and having an attacker's public key inserted - this is functionally the same as HSTS - if you can MitM the first visit you win...)

AdamN 10y ago

He's not totally wrong. If the package is signed and the public key is trusted (the bigger 'if' actually) and the package signature passes - then it doesn't matter how it was transported. Even email is fine. With that said, security needs to be in layers and defense in depth is critical, especially for this type of core infrastructure. He should upgrade all infrastructure points for better security where feasible. There's also the political reason not to use Cloudflare ... we're quickly moving to a darker Internet where traffic goes into networks like Cloudflare and nobody knows what happens inside the black box. I wonder if that's where the resistance lies.

breakingcups 10y ago
The problem with that is that, if you as a malicious third person can MITM the http connection for updates, you can push an older signed package with known vulnerabilities.