On Wed, 7 May 2014, Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> wrote:
In short, I don't know what Russell covered, which links he pointed to or how good his coverage was with the talk, but the linked article below is pretty poor.
https://twitter.com/etbe After my talk I tweeted the relevant URLs, see the above.
This is a huge issue some have likened it to Y2K ... the major difference is that Y2K was known about and properly handled for almost all critical systems -- it was a very significant amount of work. It's actually not close to the same issue, Y2K is completely different.
I did some Y2K testing. Most of the work that I did was in testing standard Unix programs such as NTP. The programs that should have been tested were the in-house apps and I was banned from testing them at one client site and not asked to test them at another. My experience of Y2K testing was that it was a lot of wasted money with little good that came of it. The only good that came of the Y2K testing was when I started labelling well known bugs in code as "things that will break in the year 2000" without mentioning that they were broken in 1999 and earlier - that got some things fixed. Some years later I discovered that a program I had written in 1995 had a Y2K bug but the client worked around that without telling me until years later.
Lots of certs were re-generated quickly after public disclosure, but with old dates, so it is hard to tell if a site is fixed, you certainly can't tell by the cert date(s). Apparently the Commonwealth Bank was effected, but they claim that only the main website was vulnerable, not Netbank -- can you trust them? I think NOT! Banks do NOT care about security as much as they need to; why do you think tap-and-pay systems are so good for them ... it's because the RETAILER takes ALL the risk whilst the bank takes NO RISK at all.
Banks tend not to upgrade software quickly. If they were using Debian/Squeeze (which is still supported) or any other distribution of that age then they would be fine.
A much bigger problem related to the certs is how browsers handle certification revocation, or rather handle it very poorly. The revocation lists in a browser would only cover the /normal/ number of revocations in a single day. Browsers can use OCSP which can also have soft fail errors that are accepted, much like SPF allowing soft fail. If OCSP fails to get a result (testing for cert revocation), then it might just go ahead and act as if it did get a confirmation result that the cert was okay.
If you use Firefox, set the following to true (about:config entry) security.OCSP.require [the default is false]
https://www.imperialviolet.org/2014/04/19/revchecking.html The above URL has an article describing the problems with revocation checks. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/