[Interest] TLS/SSL XML encryption security

[Henry Skoglund]

Yes, I also know about the lizardmen from Phobos who can crack SSL/TLS 
keys instantly.
If you can show some code all this would be much more credible. After 
all, this is a Qt mailing list, not a science fiction one.

Rgrds Henry


On 2019-10-07 16:06, Roland Hughes wrote:
>
> On 10/7/19 5:00 AM, Thiago Macieira wrote:
>> You do realise that's not how modern encryption works, right? You do 
>> realise
>> 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
>> while.
> yeah.
>> 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 
> fingerprint database.
>
> 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 did:
>
> https://www.mcall.com/news/watchdog/mc-counterfeit-credit-cards-identity-theft-watchdog-20160625-column.html 
>
>
> 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 
> information?
>
> 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 
> that much
>
>> 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.
>
> https://venturebeat.com/2014/07/13/hackers-only-need-to-get-it-right-once-we-need-to-get-it-right-every-time/ 
>
>
>
>