[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
On 06/03/14 22:38, Martijn Grooten wrote: > > They are different issues. It's just a big coincidence that they both > revolved around incorrect 'goto' statements in the C source code and > that they both meant that SSL/TLS certificates weren't verified. Not sure it is simply a coincidence. The task is complex, they both implement in the same language, which lacks key features for exception handling, so the exceptions are all handled by goto (or something logically equivalent, return code with lots of extra "if" blocks and we all know how good humans are at that logic stuff). There are also reasons these bits of code are being checked at this time. The gnutls code sample given doesn't appear to be a goto bug if the code diff is to be believed, it is simply a problem setting return codes. Other languages offer exception handling, making the goto the machines problem, which would have avoided Apple's issue (along with a lot of other checks). > Apart from the fact that apparently people didn't read the source code > as much as they should (or as wel assume they do), what I find slightly > worrying is that no one had drawn conclusions from not getting > certificate errors. If the code diff is correct, then it looks like issuer errors are the key area, may well be that there are few "natural" cases where it would fail to issue an error. Malicious certificates are fairly thin on the ground, not least for all its faults hitting the crypto side of a TLS connection is often harder than other attacks. Thus the "natural" errors people see are "not trusted"/"broken chain", "expired", "wrong name" (really how many of your TLS errors fall outside this, I've been doing a lot of this lately and I see some new warnings for the first time, but they mostly boil down to these cases). How many times have you seen a revoked certificate warning in the wild for example? (Okay maybe Martijn will have seen more than most given his job). So you really need to test these cases because whilst they are important, you can't rely on them occurring in the wild at a level for users to debug your code. I suspect another case where enabling all the compiler warnings and fixing them might have helped, without building before and after hard to be sure (but don't mention Debian OpenSSL in the same breathe). I suspect we need simpler crypto standards. These code bases handle a load of obsolete protocols and cipher suites, like SSLv2 and SSLv3. The author of Varnish explains why Varnish doesn't do TLS. https://www.varnish-cache.org/docs/trunk/phk/ssl.html There are smaller TLS libraries uses in embedded devices, but by and large they are trying to solve a problem of comparable complexity (keep supporting all the legacy protocols because someone somewhere is still using it, whilst supporting all the new ones). Bigger than the Apple bug - I'm skeptical. Apple had all their consumer devices default browsers affected. Including a LOT of phones, tablets, TVs and music players. We have Linux boxes without GNUtls installed. Mostly it is in boxes for diagnostic tools, text browser, and a lot of minority applications. Sure if you use a text mode browser or a text mail client, there is a good chance you are affected. A lot more machine to machine cryptography affected possibly. A lot harder to fix because more than one organisation involved, sure. But anywhere near the scale of the SSL traffic affected by the Apple bug - well we can ask someone with a probe on a big network if someone wants to argue the case - but I'll happily take a bet that there is a shed load more Apple SSL traffic, than GNUtls, on any UK ISP backbone. Oh and I'll take a bet that key DNSSEC implementations have similar issues despite it being simpler protocol (says Simon knowing he has a bug to investigate and report if appropriate). -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq