[Interest] TLS/SSL XML encryption security
roland at logikalsolutions.com
Mon Oct 7 16:06:07 CEST 2019
On 10/7/19 5:00 AM, Thiago Macieira wrote:
> You do realise that's not how modern encryption works, right? You do
> that SSL/TLS rekeys periodically to avoid even a compromised key from going
> further? That's what the "data limit for all ciphersuits" means: rekey after a
> You're apparently willfully ignoring the fact that the same cleartext will not
> result in the same ciphertext when repeated in the transmission, even between
> two rekey events.
No. We are working from two completely different premises. It appears to
me your premise is they have to be able to decrypt 100% of the packets
100% of the time. That's not the premise here.
The premise here is they don't need it all to work today. They just need
to know that a Merchant account service receives XML/JSON and responds
in kind. The transaction is the same for a phone app, Web site, even
when you are standing at that mom & pop retailer physically using your
card. They (whoever they are) sniff packets to/from the IP addresses of
the service logging them to disk drives.
The dispatch service hands 100-1000 key combinations out at a time to
worker computers generating fingerprints for the database. These
computers could be a botnet, leased from a hosting service or machines
they own. The receiver service stores the key results in the database.
A credit card processing service of sufficient size will go through a
massive number of salts and keys, especially with the approaching
Holiday shopping season. 1280 bytes "should" be more than enough to
contain a credit card authorization request so this scenario is only
interested in fast cracking a single packet. Yes, the CC number and some
other information may well have additional obfuscation but that will
also be a mechanical process.
Periodically a batch job wakes up and runs the sniffed packets against
the database looking for matching fingerprints. When it fast cracks one
it moves it to a different drive/raid array, storage area for the next
step. This process goes in steps until they have full CC information
with a transaction approval, weeding out the declined cards.
When the sniffed packet storage falls below some threshold the sniffer
portion is reactivated to retrieve more packets.
This entire time workers are adding more and more entries to the
These people don't need them all. They are patient. This process is
automated. They might even configure it to send an email when another
100 or 1000 valid CCs so they can either sell them on the Dark Web or
send them through the "buying agent" network.
Yeah, "buying agent" network might need a bit of explanation. Some of
you may have seen those "work from home" scams where they want a
"shipping consolidation" person to receive items and repackage them into
bulk packs for overseas (or wherever) shipping. They want a fall person
to receive the higher end merchandise which they then bulk ship to
someone who will sell it on eBay/Amazon/etc.
The CC companies constantly scan for "unusual activity" and call you
when your card has been compromised. This works when the individuals are
working with limited information. They have the CC information, but they
don't have the "where you shop" information. The ones which have the
information about where you routinely use the card can have a better
informed "buying agent" network and slow bleed the card without tripping
the fraud alert systems. If you routinely use said card at say, Walmart,
2-3 times per week for purchases of $100-$500 they can make one more
purchase per week in that price range until you are maxed out or start
matching up charges with receipts.
The people I get asked to think about are playing a long game. They
aren't looking to send a crew to Chicago to take out $100 cash advances
on a million cards bought on the Dark Web or do something like this crew
Or the guy who just got 8 years for running such a ring in Las Vegas.
That's the most recent one turning up in a quick search.
Maybe they are looking to do just that, but are looking for more
At any rate, the "no-breach" scenario is being seriously looked at. Yes,
the Salt will change with every packet and the key might well change
with every packet but these players are only looking to crack a subset
of packets. Most organizations won't have the infrastructure to utilize
a billion compromised credit cards. They can handle a few hundred to a
few thousand per month.
In short, they don't need _everything_. They just need enough to get
> And don't forget the Initialisation Vector. Even if you could compute the
> fingerprint database, you still need to multiply it by 2^128 to account for
> all possible IVs.
Perhaps. A few of those won't be used, such as low-values and
high-values. That also assumes none of the desalination chatter pans
out. Maybe it does and maybe it doesn't. One thing is certain. We now
have the storage and computing power available to create the database or
2^128 database tables if needed.
The people I get asked to think about are playing a very long game. If
they are using a botnet the machines to generate the database content
cost them nothing. They are only on the hook for a bit of coding and
what is becoming cheaper by the month storage.
Roland Hughes, President
More information about the Interest