On Wed, 7 May 2014, Andrew McGlashan <[email protected]> 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/ _______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
