[Interest] TLS/SSL XML encryption security

Sat Oct 5 19:26:01 CEST 2019

Il 05/10/19 02:17, Roland Hughes ha scritto:
> 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?

Of course! Everyone in charge of security at Google, Amazon, Apple, 
Facebook, Microsoft is a complete moron and didn't think of this 
already, as they're happily sending plain XML and JSON from their servers!

Or maybe it has to do with the fact that modern encryption algorithms 
are designed to be resilient against these attacks, so there is no point 
at obfuscating the data you're sending? I'm really not sure. I'll go 
with "everyone else is a complete moron".

>> 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."

Sure; there are (at most) ~10^80 =~ 2^266 atoms in the observable 
universe. So you need roughly ALL THE MATTER IN THE UNIVERSE to store 
every possible combination of 256 bit keys+algorithms into a fingerprint 
database.

>>> 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?

It's not. It's security by obscurity. I'll grant it may be a legitimate 
use of obfuscation, which of course doesn't work ALONE -- it works when 
the rest of your stack is also secure. And in the case of TLS/SSL, the 
rest of the stack is secure WITHOUT using security by obscurity.

> Well, first we have to shred some marketing fraud which has been in
> existence for a very long time.
> 
> https://en.wikipedia.org/wiki/Security_through_obscurity
> 
> "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.
> 
> https://www.youtube.com/watch?v=493jZunIooI
> 
> _ALL_ electronic encryption is security by obscurity.
> 
> Take a moment and let that sink in because it is fact.

"Let that sink in" is the official "I've just told you a very very 
appealing lie/logical fallacy/... and I don't want to get caught".

> 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.

*JUST THE KEY*. Every other part of the system (SSL version, key 
derivation algorithms, encryption algorithms, etc.) can be known, and 
the system still be secure. The secret key is an input of the system, 
and NOT part of its design (which is standardized) or the implementation 
(which can be open source and thus examinable), which therefore doesn't 
make it (according to your own quote) security by obscurity.

> 
> "It would take a super computer N years running flat out to break this
> encryption."
> 
> I first heard that uttered when the Commodore SuperPET was on the market.
> 
> https://en.wikipedia.org/wiki/Commodore_PET
> 
> 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.

Back of envelope calculation:

* a botnet of 50 millions hosts
* each of which can do 10000 G tries per second (completely unrealistic; 
a GeForce 1080 is ~8500 GFLOPS, and of course a try costs more than 1 FLOP)
* the verification of a possible result costs 0
* they need to explore a 2^128 key space

The result is 21565795049 years

> 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. 

And remember to drink Coca-Cola® Zero Sugar™. This mailing list endorses 
only products from The Coca-Cola Company. Only losers drink Pepsi Max®.

> 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.

There are no known attacks of this sort which are viable against modern 
encryption algorithms.

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

Bullshit.

> 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.

They can happily use XML, JSON, CBOR and any other standardized solution 
to avoid inventing yet another format and rely on 3rd party libs solving 
the (de)serialization for them.

-- 
Giuseppe D'Angelo | giuseppe.dangelo at kdab.com | Senior Software Engineer
KDAB (France) S.A.S., a KDAB Group company
Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com
KDAB - The Qt, C++ and OpenGL Experts

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4329 bytes
Desc: Firma crittografica S/MIME
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20191005/6c7fa080/attachment.bin>