171–180 of 355 posts
Earlier quoted context omitted.
Or, simply assume that there really are no “good guys”.
Especially where money is involved.
Earlier quoted context omitted.
It's worth noting that on ios you can never block anything - just have to put up with it.
You can still block access by host by using an HTTP proxy like Fiddler or Charles. Settings > WIFI > Proxy
Earlier quoted context omitted.
5 minutes is an absurdly short cache time…
If you catch malware in the wild you don’t want to wait half a day for the cache to expire. Negative responses are typically cached for short periods of time. Can you imagine if people cached NXDOMAIN for half a day and someone creating a record had to wait 12 hours for it to go live because someone queried it?
But if you have a cached OCSP response for the cert of a malware author, then you've already launched their app, so it's probably too late.
Now just waiting for the trolls to write some software that makes the response always cause it to be invalid. With a wee bit of ARP magic, you could make a bunch of mac users very unhappy at the cafe's.
Earlier quoted context omitted.
> I never asked them to do that in the first place, so I'll be blocking it from now on. Apple's working on making sure you can't block it. They already keep you from blocking their own traffic with Little Snitch and similar tools: https://news.ycombinator.com/item?id=24838816
if they keep doing like this I will block their entire ASN .
Earlier quoted context omitted.
first compressed and then encrypted. A good encryption is indistinguishable from random data.
That's why it's compressed before encryption?
Reality is a little different of course, and compression can cause problems for encryption because compressed data tends to be highly predictable (especially things like compression headers and compression dictionaries). This allows for potential “known/chosen plaintext” attacks on the encryption.
Some classic examples of this type of attack are breaking Enigma (known plaintext, no compression) by assuming the content of some messages[0] and the more recent CRIME[1] attacks against TLS using compression to help produce a chosen plaintext.
The simple solution in these scenarios is to avoid using compression completely.
[0] https://www.quora.com/Did-the-inclusion-of-Heil-Hitler-at-th... [1] https://en.m.wikipedia.org/wiki/CRIME
Now just waiting for the trolls to write some software that makes the response always cause it to be invalid. With a wee bit of ARP magic, you could make a bunch of mac users very unhappy at the cafe's.
Earlier quoted context omitted.
Which is still sufficient information to narrow down to the set of applications developed by a single entity. And because this is being done over HTTP, anyone along the network chain has visibility as well.
Agreed, this should be sent encrypted, obviously. My point was that the intent here might not be to "snoop" on users, as even the author points out by comparing his analysis with what Jeffrey Paul's article reported ("[...] that’s quite an important difference on a privacy perspective") but likely to efficiently handle certificate revocation. Hopefully they will find a better way.
http://ocsp.apple.com/ocsp-devid01 is Developer ID, but http://ocsp.apple.com/ocsp03-apevsrsa2g101 is something else, which if blocked can prevent the Mac App Store from loading.