131–140 of 246 posts
ocspd /usr/sbin/ocspd Total: 196 B sent, 45.8 MB received Outgoing to devimages.apple.com (92.122.207.101), Port http (80), Protocol TCP (6), 196 B sent, 45.8 MB received
This should really have been a separate fix & installed without user interaction. Instead this is 450 Megs & requires a restart. It'll take days for it to get out to those at risk.
> This should really have been a separate fix & installed without user interaction Considering it needs to update the TLS support on the rescue partition too, doing it outside of single-user mode is probably not a good idea. You're nitpicking, it seems.
This bug was pretty serious. I'd better be extra careful and install and verify this myself. Oh, good: there's a standalone installer available ( http://support.apple.com/kb/DL1726 ). But the download is served over HTTP. Maybe I can just try the same URL with HTTPS: $ curl --head https://support.apple.com/downloads/DL1726/en_US/OSXUpdCombo10.9.2.dmg HTTP/1.1 302 Moved Temporarily Server: Apache/2.2.24 (Unix) Locatio…
1. Use linux/fbsd/obsd/win box to download update.
2. Verify authenticity of cert/sha1
3. scp dmg / copy to USB drive
4. Apply update and move on.Earlier quoted context omitted.
It's even more unacceptable that it took them FOUR DAYS to fix it, just so they could add a couple of features to FaceTime while they were at it.
While this is too long IMO, Similarly critical bugs in windows have been left unfixed for years.
Earlier quoted context omitted.
It's getting attention because: - It's an easy to spot bug, - in the most critical part of the code, - of a fundamental security library, - and it's been there for a long time, nobody knows how many systems have already been compromised due to it. With this bug, Apple's library isn't actually a SSL implementation. It does not perform the most essential part of a SSL implementation - verifying that the peer possesses…
It's even more unacceptable that it took them FOUR DAYS to fix it, just so they could add a couple of features to FaceTime while they were at it.
Earlier quoted context omitted.
Unless your box has already been pwnd and the update installer has been modified to not install that update in the way it was meant to be.
Yes, if we assume you're already fucked, then we can conclude that there is nothing you can do to verify anything and that you are fucked, because we have assumed our conclusion. SHA1s and MD5s are equally pointless in this case because you've already assumed you're fucked, so it should all be assumed to be lying to you. If, however, we don't engage in circular reasoning and we assume your box isn't currently in the…
Earlier quoted context omitted.
Without this bug, they wouldn't be able to use BofA's own certificate to do it.
Why does this matter? The browser isn't even at bankofamerica.com, it is at bankofamericaa.com: it "adds insult to injury", but it doesn't affect the attack. No browser would notice, even with the fanciest watchdog services and certificate pinning, that the certificate of an unrelated website is "authentic" or not. The only way you are going to notice the name being wrong is if the user opens the certificate details…
Earlier quoted context omitted.
It's getting attention because: - It's an easy to spot bug, - in the most critical part of the code, - of a fundamental security library, - and it's been there for a long time, nobody knows how many systems have already been compromised due to it. With this bug, Apple's library isn't actually a SSL implementation. It does not perform the most essential part of a SSL implementation - verifying that the peer possesses…
How many malicious exploits have occurred in the last 5 days? I'm genuinely curious if anyone has a guess. Wouldn't you need to have control of the router Starbucks is using to set up the MITM attack?
This isn't true of home networks using PSK, where the AP and the client need an identical PSK in order to authenticate each other. Yes, each other - if you successfully connect to an AP using a PSK, you can be pretty sure that AP knows the same key, and probably isn't someone impersonating it (note however that anyone with the PSK can impersonate the access point).
Remember kids, when you connect to a network without a PSK or more elaborate authentication where you verify the identity of the AP, you generally have no idea who is operating that network.
I hope for a iOS 7.1 beta soon with this fix.
Earlier quoted context omitted.
How many malicious exploits have occurred in the last 5 days? I'm genuinely curious if anyone has a guess. Wouldn't you need to have control of the router Starbucks is using to set up the MITM attack?
Anyone can hide his access point in a backpack and claim to be Starbucks. Or anything else - most people don't care, they'll hook themselves to just about anything. This isn't true of home networks using PSK, where the AP and the client need an identical PSK in order to authenticate each other. Yes, each other - if you successfully connect to an AP using a PSK, you can be pretty sure that AP knows the same key, and p…