[Interest] Interest Digest, Vol 97, Issue 4

Roland Hughes roland at logikalsolutions.com
Sat Oct 5 23:38:17 CEST 2019

On 10/5/19 5:00 AM, interest-request at qt-project.org wrote:
> 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.

Here's a really good 2016 article about birthday attacks and other 
security breaching methods.


It is fine if your eyes glaze over reading it. Man I _never_ wanted to 
step back into this world!

Before passing out reading it one should jump to the "Responsible 
disclosure" part near the end.

"Mozilla is implementing data limits for all ciphersuites. This has been 
integrated into NSS 3.27, which should be used in Firefox 51."

Okay, I'm at 69.0.1 on my machine, but the version isn't the interesting 
part of that quote. "data limits for all cyphersuites" is the 
interesting part. If you managed to wade through the entire article you 
will see they were able to force some "birthday" attacks within 64MiB of 
packet exchanges.

This "data limits for all ciphersuites" is what pushes the creation of 
"fingerprint" databases. Lord knows there are more than enough 
compromised machines out there to create thousands of such databases. 
With a fingerprint database you need ONE magic packet. For JSON, that is 
any packet in the stream because you are looking for

" : "


" :"

": "

as an encrypted fingerprint with many instances in the packet. If the 
encryption algorithm used consistently encrypts the same character 
string the exact same way within a packet a human just glancing at the 
sniff could see the repetition. For xml you just need to find

<?xml version=

or the first 8 bytes of it (for the 64-bit block ciphers) and you are 
golden. But to find that you have to sniff the first packet of the document.

Another interesting quote from that same section has to do with OpenVPN

"It will also implement a default renegotiation limit of 64MB when used 
in TLS mode in a future version."

They are slowly migrating towards what all communication has to use, a 
book code. Use of a book code removes the renegotiation. If you allow 
more than one packet to use one key+algorithm pair, at some point one 
side or the other sends the "next code" command then both sides move to 
the next code. The correct way to do it is change with every packet 
though. I call it "reading the book." The only negotiation is about 
which book and what page at the beginning. The books all have numbers 
and are routinely rotated out. No client has more than 3 and no server 
has more than 5. Fall too far behind and you need a new executable from 
the head librarian.

*nix did it wrong.

None of this transport layer stuff should ever happen at the application 
developer level. The "system manager" should configure the available 
connections along with their dynamic security and they should simply 
appear as files or streams of known names. In the case of 
Google/Apple/etc. idiot phones the "system manager" is Google/Apple/etc. 
When they push an update they push a new configuration with new books. 
One still shouldn't use XML or JSON because of the fingerprint repetitions.

Note: With XML I focused on the opening string because it is a 
thumbprint. One could choose to search for the fingerprints of both < 
and > repeating many times within any given packet having stuff between 

Roland Hughes, President
Logikal Solutions


More information about the Interest mailing list