It's a "128 bits private key", what means it's assymetric. I fully expect it to be an RSA key, but even for ECC that's at least half the size of something that could be considered secure.
TLS uses several algorithms, almost always both asymmetric and symmetric algorithms, in every session. For example, my current connection to HN is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. And that does mean that our underlying session key is 128 bits, independent of the size of HN's public key (which turns out to be 2048 bits).
There is a possible argument that a 128-bit AES key and a 2048-bit RSA key are mismatched, but a 1024-bit RSA key is clearly known to be dangerous now, while the same is not at all true for a 128-bit AES key.
Symmetric encryption does not have the concept of a "private key". A 128 bits private key in TLS can only vary from almost useless (if it's some ECC algorithm) to completely useless (in case it's RSA).
Too bad (but understandable) that the article does not give any detail. About a decade ago, 128 bits RSA keys were widely used (but not recommended anymore), I wouldn't be surprised to discover a bank didn't change their security procedures since then.
> Symmetric encryption does not have the concept of a "private key".
In the early days of public key cryptography, the NSA referred to it as "non-private key cryptography".
Even today, people often refer to symmetric vs asymmetric and private vs public interchangeably. (Yes, it can cause confusion and you will probably never see professional cryptographers like Bernstein, Green, Lange, Schwabe, Schneier, or Wilcox-O'hearn refer to it that way.)
There is a possible argument that a 128-bit AES key and a 2048-bit RSA key are mismatched, but a 1024-bit RSA key is clearly known to be dangerous now, while the same is not at all true for a 128-bit AES key.