6 ms·
>If you can mitm the dns or ip you can still do this even with https. Strictly speaking you'd need a compromised DNS and a compromised CA (possibly with a wild
by phkn1 12y ago
>If you can mitm the dns or ip you can still do this even with https.
Strictly speaking you'd need a compromised DNS and a compromised CA (possibly with a wildcard certificate). Certificates provide assurance of identity as well as encryption (that's why public key encryption works). No matter where the connection comes from. (EDIT: If I compromise DNS for an SSL secured site I only get half an attack.)
> does the app allow "upgrading" to a lower version number automatically?
I'm not as familiar with the app update mechanisms in respect to enforcing monotonic version numbers. I don't have proof it enforces this, however.
> the app enforces signed updates, no?
The author says it best here:
http://httpshaming.tumblr.com/post/95160721901/but-its-signed http://httpshaming.tumblr.com/post/95160721901/but-its-signe...
- hjlklhj 12y ago>>> But this is still a risk, as the link to the app that does the syncing could be blocked to maintain a vulnerability >>If you can mitm the dns or ip you can still do this even with https. >Strictly speaking you'd need a compromised DNS and a compromised CA (possibly with a wildcard certificate). Certificates provide assurance of identity as well as encryption (that's why public key encryption works). No matter where the connection comes from. (EDIT: If I compromise DNS for an SSL secured site I only get half an attack.) My comment here was for the "the link to the app that does the syncing could be blocked to maintain a vulnerability" argument. That you don't need a CA for. Just throw a NXDOMAIN from the dns. edit: please note that I very much agree that update checks should be over https. It's just that I think that it's not a panacea and should be accompanied by e.g. code signing, enforcing updating version, etc.
- phkn1 12y agoAgreed. Defense in depth is key.