On 10/5/19 5:00 AM, interest-requ...@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.
https://sweet32.info/
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
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
them.
--
Roland Hughes, President
Logikal Solutions
(630)-205-1593
http://www.theminimumyouneedtoknow.com
http://www.infiniteexposure.net
http://www.johnsmith-book.com
http://www.logikalblog.com
http://www.interestingauthors.com/blog
___
Interest mailing list
Interest@qt-project.org
https://lists.qt-project.org/listinfo/interest
