Following on from Russell's talk, to further enlighten you, here is a useful description of the hearts bleeding: http://abclocal.go.com/wls/story?section=news%2Fiteam&id=9526738 'Heartbleed. The term comes from the communication between two so-called "hearts" on a server which verify your security as you shop, check e-mails and bank statements. There is now a backdoor break-in between those hearts, and it's bleeding.' -- Tim Connors
Hi, 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. On 6/05/2014 11:16 PM, Tim Connors wrote:
Following on from Russell's talk, to further enlighten you, here is a useful description of the hearts bleeding:
http://abclocal.go.com/wls/story?section=news%2Fiteam&id=9526738
'Heartbleed. The term comes from the communication between two so-called "hearts" on a server which verify your security as you shop, check e-mails and bank statements. There is now a backdoor break-in between those hearts, and it's bleeding.'
This is about a "heartbeat" vulnerability, hearts is a funny way of saying it here. Of the odd 66% of the Internet that /may/ have been vulnerable, slightly less than 20% were actually running the bad code and that was at the worst point -- during those two years, there would have be a scaling up of websites, but not beyond 20%. Sure that is a lot of websites. The most critical, as in used massively, like Google and Facebook have worked on fixes behind the scenes way before most of the world found out about the issue. 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. The heartbleed issue meant that servers AND clients could have been making memory requests continually, getting 64KB at a time of random memory on either the client or the server -- remember, BOTH were vulnerable if they used the effected versions of OpenSSL. Losing the certificates themselves is not so much a problem, it is losing the keys to those certs -- the certs alone are provided with every SSL [or more correctly TLS] connection setup. And of course the raw memory dumps could easily have contained usernames and passwords, code or all sorts of things that could have been quite interesting. If you ran a server (or client) with the effected versions of OpenSSL, then there is no way to tell if you have or have not been exploited. It's time to change the keys, get new certs, change passwords, etc.... oh and the article was right about not changing passwords early -- you need to know the site has been fixed first. 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. 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] This reference is more useful in relation to heartbleed itself and helps people work out which services to reset passwords: http://mashable.com/2014/04/09/heartbleed-bug-websites-affected/ Cheers A.
Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> writes:
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.
I think Tim's *point* was the article's hilariously poor explanation. Cf. Think of a monad as a spacesuit full of nuclear waste in the ocean next to a container of apples. Now, you can't put oranges in the spacesuit or the nucelar waste falls in the ocean, *but* the apples are carried around anyway, and you just take what you need. -- dons
Andrew McGlashan <andrew.mcglashan@affinityvision.com.au> writes:
This is a huge issue some have likened it to Y2K...
PS: [Heartbleed] was just another in a serious of annual catastrophic OpenSSL bugs. -- http://www.tedunangst.com/flak/post/origins-of-libressl The *only* reason heartbleed is getting mainstream media attention, is because the researchers invested more effort into registering a catchy domain name and designing a cute logo, than on responsible disclosure.
On 07/05/14 12:31, Trent W. Buck wrote:
The *only* reason heartbleed is getting mainstream media attention, is because the researchers invested more effort into registering a catchy domain name and designing a cute logo, than on responsible disclosure.
Given they're my coworkers I take umbrage to that. The Finnish team who (apparently) rediscovered this after it was already disclosed to the OpenSSL team by researchers at Google did do some of the publicity, but by that point the patch was already ready, the openssl team were simply taking time on the release to try and coordinate it. I've seen nothing showing anything but responsible disclosure from all sides on this issue (others, even others involving Google researchers sure).
On 7/05/2014 9:27 PM, Julien Goodwin wrote:
On 07/05/14 12:31, Trent W. Buck wrote:
The *only* reason heartbleed is getting mainstream media attention, is because the researchers invested more effort into registering a catchy domain name and designing a cute logo, than on responsible disclosure.
Given they're my coworkers I take umbrage to that. The Finnish team who (apparently) rediscovered this after it was already disclosed to the OpenSSL team by researchers at Google did do some of the publicity, but by that point the patch was already ready, the openssl team were simply taking time on the release to try and coordinate it.
I've seen nothing showing anything but responsible disclosure from all sides on this issue (others, even others involving Google researchers sure).
I have no problem with how the disclosure was handled. In fact I think it was handled very, very well. There have been reports and denials about the NSA using the bug.... guess we'll never know the answer to that. But I did hear about one server/service that somehow manages to keep every single data packet to/from them -- they analyzed those packets and found evidence of the exploit in play. Wish I had the reference, but that makes it more interesting and scary. Ordinarily no such traffic capture is available and the logs themselves don't give any hint of an exploit having been attempted (success or failure). Cheers A.
Julien Goodwin wrote:
On 07/05/14 12:31, Trent W. Buck wrote:
The *only* reason heartbleed is getting mainstream media attention, is because the researchers invested more effort into registering a catchy domain name and designing a cute logo, than on responsible disclosure.
Given they're my coworkers I take umbrage to that. The Finnish team who (apparently) rediscovered this after it was already disclosed to the OpenSSL team by researchers at Google did do some of the publicity, but by that point the patch was already ready, the openssl team were simply taking time on the release to try and coordinate it.
I've seen nothing showing anything but responsible disclosure from all sides on this issue (others, even others involving Google researchers sure).
Shrug. If I'm poorly informed, I apologize. Certainly I'm not happy with the OpenSSL people, either :-)
On 07.05.14 00:34, Andrew McGlashan wrote:
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.
Is there any evidence for any of those assertions? That bank cared enough about security to _insist_ on sending a security dongle when a substantial netbank account was opened - they did not wish to accept liability for loss of that amount of funds without the extra security provision. Given the one-time access provided by each long-cycle pseudorandom code produced by the dongle, a strong password on the account becomes mere back-up protection. AIUI anyone can ask for a dongle. It's worth knowing that even if account ID and password were intercepted, they would avail a crim nothing at all. Erik -- A computer is like an air conditioner, it works poorly when you open Windows.
On 7/05/2014 7:38 PM, Erik Christiansen wrote:
On 07.05.14 00:34, Andrew McGlashan wrote:
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.
Is there any evidence for any of those assertions?
That bank cared enough about security to _insist_ on sending a security dongle when a substantial netbank account was opened - they did not wish to accept liability for loss of that amount of funds without the extra security provision.
Given the one-time access provided by each long-cycle pseudorandom code produced by the dongle, a strong password on the account becomes mere back-up protection.
AIUI anyone can ask for a dongle. It's worth knowing that even if account ID and password were intercepted, they would avail a crim nothing at all.
They've had other methods too, certs on a USB stick for one, multi-person auth too. Still, from what I've seen and what I understand, I still don't trust them as much as I would like -- heck my NetBank with a dongle doesn't even work properly with Firefox [NetBank, not the login auth], I have to use Chrome and that's something I would otherwise like to avoid too. What's the best banking alternative? I'm not sure any are going to satisfy me, just knowing what can go wrong and how they manage security risk based on a dollar value, rather than on it's own merit. It's a commercial world we live in, same problem when fuel tanks were exploding on Ford cars in the US way back.... they assessed the cost of /fixing/ the rare occurrence with the cost of doing a proper recall .. the cost of people's lives was less, so they didn't do a recall. [1] http://auto.howstuffworks.com/1971-1980-ford-pinto12.htm Cheers A.
On 07.05.14 20:28, Andrew McGlashan wrote:
Still, from what I've seen and what I understand, I still don't trust them as much as I would like -- heck my NetBank with a dongle doesn't even work properly with Firefox [NetBank, not the login auth], I have to use Chrome and that's something I would otherwise like to avoid too.
For good or bad, I'm still in the "nuffin's visibly gone wrong so far" cohort. Without the dongle, even with the account ID and password, any stolen information would be useless, AIUI. (That said, known slack security of any kind has to be fixed ASAP.) Incidentally, Firefox and NetBank have worked fine for me for six years now. Admittedly, the "about firefox" menu item suggests a version number of "17.0". I haven't updated in some time. Erik -- The universe contains any amount of horrible ways to be woken up, such as the noise of the mob breaking down the front door, the scream of fire engines, or the realization that today is the Monday which on Friday night was a comfortably long way off. - Terry Pratchett, _Moving Pictures_
On 7/05/2014 9:32 PM, Erik Christiansen wrote:
On 07.05.14 20:28, Andrew McGlashan wrote:
Still, from what I've seen and what I understand, I still don't trust them as much as I would like -- heck my NetBank with a dongle doesn't even work properly with Firefox [NetBank, not the login auth], I have to use Chrome and that's something I would otherwise like to avoid too.
For good or bad, I'm still in the "nuffin's visibly gone wrong so far" cohort. Without the dongle, even with the account ID and password, any stolen information would be useless, AIUI. (That said, known slack security of any kind has to be fixed ASAP.)
Incidentally, Firefox and NetBank have worked fine for me for six years now. Admittedly, the "about firefox" menu item suggests a version number of "17.0". I haven't updated in some time.
I keep Firefox up to date, but I was getting warning about using "back" in the browser, when I had not done that, transactions wouldn't process; if I didn't do any transactions it was okay. Now I use Chrome because gives me no errors; it works, but I have to use Chrome to get a reliable experience with NetBank. Cheers A.
Erik Christiansen <dvalin@internode.on.net> writes:
On 07.05.14 20:28, Andrew McGlashan wrote:
Still, from what I've seen and what I understand, I still don't trust them as much as I would like -- heck my NetBank with a dongle doesn't even work properly with Firefox [NetBank, not the login auth], I have to use Chrome and that's something I would otherwise like to avoid too.
For good or bad, I'm still in the "nuffin's visibly gone wrong so far" cohort. Without the dongle, even with the account ID and password, any stolen information would be useless, AIUI. (That said, known slack security of any kind has to be fixed ASAP.)
Are you talking about these tokens? https://en.wikipedia.org/wiki/SecurID#March_2011_system_compromise Re liability dumping, some choice quotes from an excellent book: Although U.S. banks faced a much fiercer liability regime, they actually spent less on security that UK banks did, and UK banks suffered more fraud. [...] But the main change was to shift liability so that the merchant bore the full risk of disputes. If you challenge an online credit card transaction (or in fact any transaction made under MOTO rules) then the full amount is immediately debited back to the merchant, together with a significant handling fee. [...] The ability of banks to blame their customers for fraud has also led to many sloppy practices. -- http://www.cl.cam.ac.uk/~rja14/Papers/SEv2-c10.pdf UK law provides that a forged handwritten signature is completely null and void [...] it’s not possible for a bank to use its standard terms and conditions to dump the risk on the customer. -- http://www.cl.cam.ac.uk/~rja14/Papers/SEv2-c14.pdf In the UK in particular, smartcards have been more a liability engineering technology than a protective one; complaints are answered with a standard refrain of ‘your chip and PIN card was used, so it’s your fault.’ [...] The law moved the liability for forged [digital] signatures from the relying party to the party whose key was apparently used. By accepting such a device, you were in effect saying, ‘I agree to be bound by any signature that appears to have been made by this device, regardless of whether or not I actually made it’. -- http://www.cl.cam.ac.uk/~rja14/Papers/SEv2-c16.pdf On whom does the burden of proof lie under Australian law, for the respective banking technologies (e.g. signatures, mag strip, EMV, RSA tokens, two-factor SMS confirmation)?
On 8/05/2014 11:53 AM, Trent W. Buck wrote:
On whom does the burden of proof lie under Australian law, for the respective banking technologies (e.g. signatures, mag strip, EMV, RSA tokens, two-factor SMS confirmation)?
That, and your other info, is exactly the point. The bank doesn't care about security if it can put the risk on merchants or customers. I will not use a chip and pin card for anything more than is absolutely necessary [a pre-paid credit card is as close as I'll get]. I may give up accepting credit cards too, MOTO is looking to be too much of a risk with the way things are going. Cheers A.
On 07.05.14 20:28, Andrew McGlashan wrote:
Still, from what I've seen and what I understand, I still don't trust them as much as I would like -- heck my NetBank with a dongle doesn't even work properly with Firefox [NetBank, not the login auth], I have to use Chrome and that's something I would otherwise like to avoid too.
Andrew, after logging off netbank, I've just seen a "NetBank optimisation check" on the log-off splash. Clicking it I get: » Web browser: Firefox 17.0 Optimised = Yes Your browser is compatible with NetBank. If you're experiencing difficulties viewing NetBank, please refer to our technical FAQs « If the check grumbles about your Firefox, or the FAQs have anything, then you're onto something, but if not, then they won't be any help, because for Linux they also report: » Operating system: Unknown Optimised = Unknown We have not tested this operating system. Your experience may vary. « Have you disabled cookies? Erik -- The only way to do anything about man made global climate change is to reduce the population. The way to do that is to do nothing about climate change and let nature do it for us. - eko000 http://www.abc.net.au/news/2014-05-12/scientists-have-new-explanation-for-dr...
On 13/05/2014 9:13 PM, Erik Christiansen wrote:
On 07.05.14 20:28, Andrew McGlashan wrote:
Still, from what I've seen and what I understand, I still don't trust them as much as I would like -- heck my NetBank with a dongle doesn't even work properly with Firefox [NetBank, not the login auth], I have to use Chrome and that's something I would otherwise like to avoid too.
Andrew, after logging off netbank, I've just seen a "NetBank optimisation check" on the log-off splash. Clicking it I get:
» Web browser: Firefox 17.0 Optimised = Yes Your browser is compatible with NetBank. If you're experiencing difficulties viewing NetBank, please refer to our technical FAQs «
If the check grumbles about your Firefox, or the FAQs have anything, then you're onto something, but if not, then they won't be any help, because for Linux they also report:
» Operating system: Unknown Optimised = Unknown We have not tested this operating system. Your experience may vary. «
Have you disabled cookies?
I use NoScript, ad block edge, change referrer (normally RED), RequestPolicy, toogle cookies (3rd party usually off, but /normal/ cookies on). Perhaps any of those could be the problem. NetBank sort of works, but it gets painful when doing some things, coming up with errors -- no errors at all with Chrome. I just did a quick login and logoff, didn't see any optimization check links of any kind. Thanks and Cheers A.
Hi, On Wed, May 7, 2014 at 7:38 PM, Erik Christiansen <dvalin@internode.on.net>wrote:
On 07.05.14 00:34, Andrew McGlashan wrote:
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.
Is there any evidence for any of those assertions?
That bank cared enough about security to _insist_ on sending a security dongle when a substantial netbank account was opened - they did not wish to accept liability for loss of that amount of funds without the extra security provision.
Thats where it got/gets tricky.
The dongle was / could have been "keyed" off the private cert of the domain...perhaps? The bank will not...ever publish the detail...but CloudFlare threw out a challenge the first weekend after "Nosebleed" was made public knowledge. It was "Can you gain access to a private key via the flaw?" http://blog.cloudflare.com/the-results-of-the-cloudflare-challenge ans=yes and it only took a couple of hours. So...if a private key was able to be gained...then the smart assumption would have to be that everything else that relied on it had already/or could be compromised if it was/si not replaced. Best most succinct description of the flaw I have seen is here: http://xkcd.com/1354/ The CF challenge proved that a private key was vulnerable via this flaw. To date, cert revocations have been very slow...big players quick...lesser players still dragging their heels: http://news.netcraft.com/archives/2014/04/08/half-a-million-widely-trusted-w... (and if you follow the links on that you will find that they are tracking revocation rates,,,which have been abysmally slow) This issue is not over by any means... kudos2 to RC for the highlite! This issue is and should still be BIG News! BW
Should have added that via the Netcraft link above that this link, which provides up2date info: http://toolbar.netcraft.com/site_report?url=https://www.commbank.com.au Has this: Heartbleed revocation The certificate offered on www.commbank.com.au before the Heartbleed announcement has *not yet been revoked*. SerialCommon Name(s)Normally ExpiresCRL revocation statusCRLSet revocation status0x5e9f33e7cfb02a58043266c2be468feewww.commbank.com.au2014-06-05not revokednot revoked Revocation information last updated 2014-05-06 18:00 GMT. BIG and very IMPORTANT FAIL! BW On Wed, May 7, 2014 at 8:34 PM, Brent Wallis <brent.wallis@gmail.com> wrote:
Hi,
On Wed, May 7, 2014 at 7:38 PM, Erik Christiansen <dvalin@internode.on.net
wrote:
On 07.05.14 00:34, Andrew McGlashan wrote:
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.
Is there any evidence for any of those assertions?
That bank cared enough about security to _insist_ on sending a security dongle when a substantial netbank account was opened - they did not wish to accept liability for loss of that amount of funds without the extra security provision.
Thats where it got/gets tricky.
The dongle was / could have been "keyed" off the private cert of the domain...perhaps? The bank will not...ever publish the detail...but CloudFlare threw out a challenge the first weekend after "Nosebleed" was made public knowledge. It was "Can you gain access to a private key via the flaw?"
http://blog.cloudflare.com/the-results-of-the-cloudflare-challenge
ans=yes and it only took a couple of hours.
So...if a private key was able to be gained...then the smart assumption would have to be that everything else that relied on it had already/or could be compromised if it was/si not replaced.
Best most succinct description of the flaw I have seen is here:
The CF challenge proved that a private key was vulnerable via this flaw.
To date, cert revocations have been very slow...big players quick...lesser players still dragging their heels:
http://news.netcraft.com/archives/2014/04/08/half-a-million-widely-trusted-w... (and if you follow the links on that you will find that they are tracking revocation rates,,,which have been abysmally slow)
This issue is not over by any means... kudos2 to RC for the highlite! This issue is and should still be BIG News!
BW
On 7/05/2014 8:45 PM, Brent Wallis wrote:
Should have added that via the Netcraft link above that this link, which provides up2date info: http://toolbar.netcraft.com/site_report?url=https://www.commbank.com.au
Security rating 0/10 Same for the NetBank login page too!!!!!! http://toolbar.netcraft.com/site_report?url=https://www.my.commbank.com.au Very scary indeed, simply not good enough. A.
On 7/05/2014 9:09 PM, Andrew McGlashan wrote:
On 7/05/2014 8:45 PM, Brent Wallis wrote:
Should have added that via the Netcraft link above that this link, which provides up2date info: http://toolbar.netcraft.com/site_report?url=https://www.commbank.com.au
Security rating 0/10
My bad, it is "Netcraft *Risk* Rating" ... so that is good! I'm still not going to concede that they meet the level of trust they should, based on other experience and knowledge. ;-) A.
On 07.05.14 20:34, Brent Wallis wrote:
On Wed, May 7, 2014 at 7:38 PM, Erik Christiansen
That bank cared enough about security to _insist_ on sending a security dongle when a substantial netbank account was opened - they did not wish to accept liability for loss of that amount of funds without the extra security provision.
..
The dongle was / could have been "keyed" off the private cert of the domain...perhaps?
Such dongles merely generate one-time passwords, changing every few seconds. They are driven by a pseudo-random sequence generator, I figure. It is trivial to build one into a CMOS chip which runs for years on the tiny sealed-in battery, yet does not repeat in 100 human lifetimes. The one weakness, in the event of the account ID and password both being acquired, is that a lucky crim might randomly guess the token value for that instant, since that's only 1 in a million. Erik -- Pessimist: The glass is half empty. Optimist: The glass is half full. Engineer: The glass is twice as big as it needs to be. - Read on avr-chat ML Pragmatist: Who cares, so long as there's more in the bottle.
Hi, On Wed, May 7, 2014 at 9:54 PM, Erik Christiansen <dvalin@internode.on.net>wrote:
On 07.05.14 20:34, Brent Wallis wrote:
On Wed, May 7, 2014 at 7:38 PM, Erik Christiansen
That bank cared enough about security to _insist_ on sending a security dongle when a substantial netbank account was opened - they did not wish to accept liability for loss of that amount of funds without the extra security provision.
..
The dongle was / could have been "keyed" off the private cert of the domain...perhaps?
Such dongles merely generate one-time passwords, changing every few seconds. They are driven by a pseudo-random sequence generator, I figure. It is trivial to build one into a CMOS chip which runs for years on the tiny sealed-in battery, yet does not repeat in 100 human lifetimes.
The one weakness, in the event of the account ID and password both being acquired, is that a lucky crim might randomly guess the token value for that instant, since that's only 1 in a million.
I agree in part... but remember... 1 in a million is a a simple and solvable challenge for a smart person with an x86 CPU... :-) IMHO we are yet to see or hear of a serious "Nosebleed" event...perhaps, its already happened and the the worst part in all of this is that will only know after the fact...remember, one of the most insidious issues around this is that there are no detectable fingerprints left by a compromise.
The bug existed for over 12 months prior to revelation. Any sane admin responsible for TLS/SSL has to assume that it had already been exploited! I need a hanky:-) BW
On 07.05.14 22:19, Brent Wallis wrote:
On Wed, May 7, 2014 at 9:54 PM, Erik Christiansen
Such dongles merely generate one-time passwords, changing every few seconds. They are driven by a pseudo-random sequence generator, I figure. It is trivial to build one into a CMOS chip which runs for years on the tiny sealed-in battery, yet does not repeat in 100 human lifetimes.
The one weakness, in the event of the account ID and password both being acquired, is that a lucky crim might randomly guess the token value for that instant, since that's only 1 in a million.
I agree in part... but remember... 1 in a million is a a simple and solvable challenge for a smart person with an x86 CPU... :-)
Please re-read. If the PRSG "does not repeat in 100 human lifetimes", then that the output token is only 6 digit does not help with sequence length, polynomial, or current position computability, even where it just comes from 20 bits of the much longer internal current value. Furthermore, nothing useful can be computed even if the attacker had the account ID, password, _and_ one 20 bit value from even a 64 bit current sequence value. It's rather hard to decode from a single point. ;-) Erik -- We cannot do everything at once, but we can do something at once. - Calvin Coolidge
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/
On 8/05/2014 1:13 AM, Russell Coker wrote:
https://www.imperialviolet.org/2014/04/19/revchecking.html
The above URL has an article describing the problems with revocation checks.
Not a bad article, but if servers can setup OCSP checks much more quickly than 3 days. If the certs had a MUST STAPLE flag and the server itself checks OCSP much more frequently, then the stapled reference could be good for an hour or two -- it doesn't have to be 3 days. The trouble is, I believe, today there is no option in certs to make stapling compulsory. Cheers A.
participants (8)
-
Andrew McGlashan -
Brent Wallis -
Erik Christiansen -
Julien Goodwin -
Russell Coker -
Tim Connors -
Trent W. Buck -
trentbuck＠gmail.com