4 ms·

I don't get these crypto types that use plain http for the download page [1] and then make a show with "You have to verify downloaded tarballs integrity and aut

• fulafel 10y ago
  End-to-send security is much better than the in-flight protection TLS gets you, and even that only as far as you trust the half-assed pki. I imagine most crypto experts don't put much faith in the integrity of their hosting providers and are not in the business of opsec themselves. Of course end-to-end only helps if people actually perform the check... TL;DR They probably think TLS in software distribution = false sense of security.
• stargrave 10y ago
  PKI is a business model. That download page suggests you to verify downloaded tarballs with OpenPGP key, or visit Git repository to look for signed (OpenPGP again) tags there. Of course you have to setup some kind of trust for verifying keys. If your browser shows you such kind of errors, then seems that you do not trust CAcert.org used for certificate creation. You may retrieve OpenPGP keys and find signature you may trust. PKI (HTTPS) is single point of trust, OpenPGP provides much more ones.
  • deleted 10y ago
    [deleted]
• nullc 10y ago
  If your primary threat model is an active attacker in proximity to the server, rather than the client, SSL provides _NO_ security: The attacker can intercept the plaintext communication to your domain used to show control over the domain and trivially obtain a certificate. If your threat model is adversarial nation states that control a CA or ten and are willing to create some bad issuance drama... again no security added by browser SSL. If your threat model is an attacker who will compromise your webserver because no one can keep up with the flood of new vulnerabilities, and the only way you can keep a private key private is to keep it offline-- which can't be used with SSL then again, no joy. Some people believe the use of HTTPS in these cases creates a false sense of security and reduces the likelyhood that people will check using other mechanisms. I am pretty confident() that they are wrong and that they've not actually measured the effect. But it's not a crazy position to take. (Especially when you mix in how easy it is for https snafus to result in giving users scary warnings that make them blind to scary warnings) (: confidence due to religiously verifying packages and keys, and finding _frequently_ that they are unverifiable even on major high profile targets like major linux distros or crypto libraries... e.g. signed with a key that is signed by no one else and exists only in the same directory as the binary; if people were actually checking I wouldn't find so many messed up cases; Also confident by watching the number of .sig downloads on my own software-- no one checks).
  • eternalban 10y ago
    That was informative. Thank you.
  • 3pt14159 10y ago
    > The attacker can intercept the plaintext communication to your domain used to show control over the domain and trivially obtain a certificate. Could you explain? Are you talking about DNS spoofing / hijacking or protocol downgrade attacks? There are answers to those, so I'm not following. > If your threat model is an attacker who will compromise your webserver because no one can keep up with the flood of new vulnerabilities, and the only way you can keep a private key private is to keep it offline-- which can't be used with SSL then again, no joy. If you are important enough to worry about 0days, then you need to invest heavily in monitoring and tools like Appcanary that can autoupdate your packages. If you detect that your key is compromised then issue a new one and move on with your life. HTTPS does not create a false sense of security, MD5 sums for packages delivered over non-TLS do. HTTPS isn't perfect but not using it because it won't stop some very well funded actors is silly. I'm worried about hacked wifi routers at my cafe, not about state level actors stealing HTTPS certificates.
    • stargrave 10y ago
      But OpenPGP detached signatures, that are isolated and does not depend no transport protocols (TLS), defend you from all that kind of MitM attacks, because they are point-to-point (directly from developer to end-user), without depending on any third-party (like CA issuing TLS certificates, DNSSEC provides, intermediate DNS proxies that must not strip DNSSEC off, and so on).
      • deleted 10y ago
        [deleted]
      • Quiark 10y ago
        Except when the user sees the author's public key for the first time and downloads it from the same site. Key distribution sucks ....
• userbinator 10y ago
  sec_error_cert_signature_algorithm_disabled They are using a SHA-512 signature in the certificate, which seems to be quite uncommon, but maybe that's why they did it...