Comment by hn_throwaway_99
2 years ago
> HTTPS doesn't mean anything.
That's not accurate at all. HTTPS should mean "we've validated that the content you're receiving comes from the registered domain that you've hit". Yes, it's possible that the domain host itself was compromised, or that the domain owner himself is malicious, but at the end of the day you have to trust the entity you're getting the content from. HTTPS says, importantly, "You're getting the content from whom you think you're getting it from."
Yes but we abandoned that idea a while ago. There are no more green locks in browsers. Nobody buys those expensive certificates that proof ownership. When you curl something it doesn't show anything unless it is an actual invalid certificate.
You are correct that it _should mean_ but reality today is that it doesn't mean anything.
No, it still means that you've connected to the domain that you wanted to connect to and the connection is reasonably resistant to MITM attacks. It doesn't say anything about who controls the domain, but what it provides still isn't nothing.
It is not about the domain.
"It is not a good indicator of trustworthiness of the actual thing you download."
I just downloaded something with malware from github.com. I indeed wanted to connect to github.com and I trust that it is Github.com. But again ... it did not say _anything_ about the trustworthyness of the _actual_ thing I did, which was to download an asset from that domain.
That is my point. In the context of this discussion about downloading dependencies.
But by using GPG to check the authenticity of the actual files that are downloaded, we can remove the web site -- whether https is sufficienctly secure or not -- from the trust chain all together. The shorter the trust chain, the better.
> HTTPS says, importantly, "You're getting the content from whom you think you're getting it from."
You need certificate pinning to know this for sure, due to the existence of MITM HTTPS spoofing in things like corporate firewalls. HTTPS alone isn't enough; you have to confirm the certificate is the one you expected. (You can pin the CA cert rather than the leaf certificate if you want, if you trust the CA; that still prevents MITM spoofing.)
I’m not aware of any HTTPS MITM that can function properly without adding its own certificate to the trusted roots on your system (or dismissing a big red warning for every site), so I don’t think certificate pinning is necessary in such an environment (if the concern is MITM by a corporate firewall).
An attacker would still need to either have attacked the domain in question, or be able to forge arbitrary trusted certificates.
If an attack requires compromising my operating system certificate store, I'm reasonably comfortable excluding it from most of my threat models.
Obviously you choose your own relevant threat models, but it's common to do in iOS apps--many apps are including it in their threat models. Pinning the CA cert is what Apple recommends to app developers. It's not an unreasonable thing to do.
https://developer.apple.com/news/?id=g9ejcf8y
1 reply →