[Interest] TLS/SSL XML encryption security

Roland Hughes roland at logikalsolutions.com
Sat Oct 5 02:17:26 CEST 2019

Sorry, I need to invert the quoted message so answers make sense.

On 10/3/19 5:00 AM, Matthew Woehlke wrote:
> On 01/10/2019 20.47, Roland Hughes wrote:
>> If they targeted something which uses XML documents to communicate, they
>> don't need to brute force attempt everything, just the first 120 or so
>> bytes of each packet until they find the one which returns
>> <?xml version=
>> and they are done.
> That seems like a flaw in the encryption algorithm. It seems like 
> there ought to be a way to make it so that you can't decrypt only part 
> of a message. Even an initial, reversible step such as XOR-permuting 
> the message with some well-known image of itself (e.g. "reversed") 
> might suffice?
> Not a flaw in the algorithm, just seems to be a flaw in the 
> communications. This isn't partially decrypting a packet. It is 
> encrypting every possible combination of key+algo supported by TLS/SSL 
> into a fingerprint database. You then use a sliding window of the 
> fingerprint size performing keyed hits against the fingerprint 
> database. You "dust for prints."
>> To really secure transmitted data, you cannot use an open standard which
>> has readily identifiable fields. Companies needing great security are
>> moving to proprietary record layouts containing binary data. Not a
>> "classic" record layout with contiguous fields, but a scattered layout
>> placing single field bytes all over the place. For the "free text"
>> portions like name and address not only in reverse byte order, but
>> performing a translate under mask first. Object Oriented languages have
>> a bit of trouble operating in this world but older 3GLs where one can
>> have multiple record types/structures mapped to a single buffer (think a
>> union of packed structures in C) can process this data rather quickly.
> How is this not just "security through obscurity"? That's almost 
> universally regarded as equivalent to "no security at all". If you're 
> going to claim that this is suddenly not the case, you'd best have 
> some *really* impressive evidence to back it up. Put differently, how 
> is this different from just throwing another layer of 
> encry^Wenciphering on your data and calling it a day? 

Well, first we have to shred some marketing fraud which has been in 
existence for a very long time.


"Security through obscurity (or security by obscurity) is the reliance 
in security engineering on design or implementation secrecy as the main 
method of providing security to a system or component."

I wonder if Gartner was paid to market this fraud. They've certainly 
marketed some whoppers in their day. Back in the 90s declaring Microsoft 
Windows an "open" platform when it was one of the most proprietary 
systems on the market. Can't believe nobody went to prison over that.

At any rate the peddlers of encryption have been spewing this line. In 
fact this line is much truer than the peddlers of encryption wish to 
admit. When you press them on it they are forced to perform a "Look at 
the Grouse" routine.


_ALL_ electronic encryption is security by obscurity.

Take a moment and let that sink in because it is fact.

Your "secrecy" is the key+algorithm combination. When that secret is 
learned you are no longer secure. People lull themselves into a false 
sense of security regurgitating another Urban Legend.

"It would take a super computer N years running flat out to break this 

I first heard that uttered when the Commodore SuperPET was on the market.


I believe they were talking about 64-bit encryption then. Perhaps it was 
128-bit? Doesn't matter. IF someone wants to do a brute force attack and 
they have 6-30 million infected computers in their botnet, they can 
crush however many bits you have much sooner than encryption fans are 
willing to believe.

They can easily build fingerprint databases with that much horsepower 
assuming they buy enough high quality storage. You really need Western 
Digital Black for that if you are single or paired driving it. I haven't 
seen anyone use a SAN for high speed high volume data collection so I 
don't know how well those hold up. During my time at CTS one of the guys 
was running high speed data collection tests with a rack of pressure and 
leak testers running automated tests as fast as they could. Black would 
make it roughly a year. Blue around 6 months. Red was just practicing 
how to replace a drive.

One of the very nice things about today's dark world is that most are 
script-kiddies. If they firmly believe they have correctly decrypted 
your TLS/SSL packet yet still see garbage, they assume another layer of 
encryption. They haven't been in IT long enough to know anything about 
data striping or ICM (Insert Character under Mask).

>> If you are using XML, JSON or any of the other trendy text based
>> open standards for data exchange, you've made it easy for the hackers.
>> They don't have to put any human noodling into determining if they
>> cracked your transmission or not. It can be fully automated. As soon as
>> one of the attempts returns something like this
>> <firstName>John</firstName>
>> or this
>> "firstName" : "John"
>> a tiny bit of code which runs through the result looking for an opening
>> tag with a matching closing tag or colon delimited quoted strings can
>> tell a brute force method to stop and notify the hacker of success.
> Isn't the fix for this just to encrypt your data twice (using different
> keys, or maybe better, different algorithms)? Offhand, it seems like
> this should exponentially increase the difficulty of decryption for each
> layer added.

Be extremely careful with that knee-jerk response. Most people using it 
won't have the patience to really test it.

Back in 2012 I was working on the IPGhoster project. We were initially 
doing 3-layers of encryption well, because who was supposedly buying 
(and funding) it wanted at least that. We had some great stuff too. Not 
just OpenSource but libraries which supposedly cost 6 figures as well. 
Every packet had to have a unique set of key+algorithm. No two packets 
used the same set for the duration of the session. (Yeah, there was some 
serious threading going on to make real-time feel like real-time.)

I'm good when it comes to architecting solutions. Some clients even call 
me brilliant but that may have more with trying to reduce my rate than 
honesty. I'm not stating this to brag. I'm giving you a frame of 
reference so you understand when I say calling Mr. Keith, the guy came 
up with our edge cases for testing, a genius is a severe understatement. 
He came up with a set of test cases and sure enough, this system which 
worked fine with simple XML, JSON, email and text files started 
producing corrupted data at the far end with the edge cases.

Moral of the story: You can never be certain 2 or more encryption 
solutions will play well together.

There were no "software bugs" in the libraries. Those got pounded on. 
His edge cases found the flaws in the algorithms. Flaws which wouldn't 
show up until they were compounded by flaws in other algorithms. No, I 
don't still have the test cases nor do I remember what they were. I was 
a hired gun on that project and they owned everything. What they did 
and/or who they told is up to them.

Maybe all of those things have since been fixed, but I would not make 
such an assumption.

Even if all of that stuff has been fixed, you have to be absolutely 
certain the encryption method you choose doesn't leave its own tell-tale 
fingerprint. Some used to have visible oddities in the output when they 
encrypted groups of contiguous spaces, nulls, etc. Plus, there are quite 
a few places like these showing up on-line. (Admittedly this one is hash 
but I didn't feel like doing much of the kind of searches which could 
land me on the FBI "follow them" list.)


discussions like this


Ah, here's one which could be put to nefarious use.


Personally, I vote for data striping and ICM primarily because the 
script kiddies can't really be bothered with anything that isn't already 
a "free" OpenSource tool _and_, as far as I know, it doesn't trigger any 
of those multi-level nested encryption data not coming out right on the 
other end problems.

At any rate, I've started writing some of this up in a blog series. 
(Well, one post right now, but more.) I did order a 6TB WD Black from 
NewEgg today. If time allows before I head off for next contract I'll 
spend a few days coding up the fingerprint generator mostly to see if it 
fits on a 6TB drive and how long it takes to create using limited 
resources. I might use 2-3 machines or may just leave it on this desktop.

If you take nothing else away from this discussion, take these points:

1) You don't have to crack encryption if you can find a fingerprint and 
that scan isn't a lot of work.

2) Given the size of botnets which have already been discovered, 
fingerprint databases can be generated quickly.

3) Phone App and Web developers should never use XML, JSON or any "free 
text" standard nor should they write systems which expect to get it off 
the IP stack in that format. If they do, then they are the security 
breach. If the exact same key+algorithm is used for an entire session, a 
hacker only needs to identify a single fingerprint to decrypt ever packet.

Roland Hughes, President
Logikal Solutions


More information about the Interest mailing list