Comment by nullc | Hacker News Reader

Comment by nullc | Hacker News Reader

Parent Full thread

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).

> 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.

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).

Except when the user sees the author's public key for the first time and downloads it from the same site. Key distribution sucks ....

Exactly. Even the famed homakov's company delivers keys via HTTP: http://sakurity.com/contact this BS about HTTPS providing the illusion of security is nonsense. It's much harder to even do a protocol downgrade attack (and we have HSTS lists for those!) than it is to replace a single endpoint or key of a HTTP connection.

That was my point. How do you know the pub key is not tampered with? Come to think of it, is meeting in person the only reliable way to reliably exchange keys?

Perhaps, but it depends on your needs.

When using PGP, you have to decide how much you trust each key. All that PGP does is enforce your trust preferences.

For example http://www.cypherpunks.ru/pygost/Download.html page contains instructions how to receive the key. You can get it using either maillist, website, DNS, keyservers. And you can use various DNS servers and transport routes via Tor. There is plenty of options. And this key is signed with another one containing many signatures. Of course there is no full guarantees, but at least you have to do it just once and then conveniently do tarballs verifying. With TLS you have to do it everytime, all the time you visit and connect to the server.

Moreover how can you "transfer" the trust to other people? If you proxy/give tarball to someone else, then how can you prove that you did not tamper it? Again, with detached signatures people knowing public key can authenticate it, without connecting to Internet. With TLS there is only single distribution point (TLS website) that can not transfer trust to someone else.

What CA should be used for certificate issuing? Paid one? Not an option if you do not want to support PKI business model (it is business, not security). CAcert.org? Modern browsers and operating systems does not include its certificate too. So anyway you have to get its public key too somehow.

So, TLS has the same problem of getting the public key and is less convenient in use, requiring TLS-aware webserver (instead of cheap providers with static pages hosting), without ability to transfer trust (send signature separately) to someone else. OpenPGP keys (for www.cypherpunks.ru websites), comparing to CA ones, can be received with several (!) keyservers (many of them replicates between themselves), several (!) DNS servers (listed as NS record), through various transports (VPN, proxy, Tor) to one of webservers (listed as A/AAAA record).

That was informative. Thank you.

Reply on news.ycombinator.com