A blog post is forthcoming exists about Apple's bug in the SecureTransport library that can allow an attacker in a network privileged position to take control of an apparently secure SSL/TLS session.
This is the thread for that discussion.
Looking forward to it, however for me what surprised me is not the bug. I for sure am surprised at Apples failure to test and capture such things. However I am nearly more surprised at security vendors etc, SSL is known to be SUCH a weak spot with comprised CA etc and rogue certs. I really would have thought many security firms would have a rake of such failure conditions that they would auto run on the released software. Banks IT departments when developing internal app scan and rescan for such bad code from vendors, why the move to Apps from them did not get the same treatment etc. overall just surprised it was not spotted the day or week after ios 6.0 dropped.
I'm also very surprised that no pen testing firm discovered this.
I completely concur that what we most need an explanation of is why this wasn't caught by testing. Given Apple's tradition of non-comment about what goes on internally, I do not think we will not get the needed answer.
@jpgoldberg do you know if it affects iOS 4?
The last I looked into it, it was still uncertain how far back this bug goes. I've seen some discussion about when it was first introduced, but it was inconclusive at the time I looked.
Damn. My gf's iPhone has iOS 4. Would be good to know. I take it Apple have only fixed iOS 6 and 7.
Yes. Apple have so far released updates only for iOS 6 & 7 and for Apple TV 6. Again, we don't know how far back this bug goes, but we do know that it is present in OS X 10.9, which has not yet been updated.
Jeffrey Grossman, on Twitter:
I have confirmed that the SSL vulnerability was introduced in iOS 6.0. It is not present in 5.1.1 and is in 6.0.
Excellent. Thanks @blackandyellow and @jpgoldberg
I'm hoping that my use of DNSCRYPT on my mac means that this ssl issue is a non-issue for me
Issue dealt with in 10.9.2, now available
@charlie98 SSL and DNS are separate technologies. Usage of DNSCrypt would not in my knowledge fix the gotfoail bug.
I haven't read up on DNSCrypt, so it is hard to comment specifically.
But if it
then it will make it harder launch certain types of attacks based on gotofail. Typically when running a Man In The Middle attack, one of the early steps is to hijack DNS resolution. But although that is one typical way of placing yourself "in the middle", it is hardly the only way. If you control a switch/router along the genuine route, you don't have to mess with DNS at all to perform these sorts of attacks.
DNSCrypt or DNSsec can't prevent SSL MITM attack. These could only eliminate certain types of attacks that involve DNS poisoning. Obviously if the potential hacker sits on the route between you and the server (like using a rogue access point) he doesn't have to fake DNS requests to be able to exploit the SSL goto bug.