Friday, May 29, 2015

The importance of strong and fast cryptography [feedly]

The importance of strong and fast cryptography
// pfSense Digest

People occasionally ask me about a malicious fork of pfSense.  It's not that I don't appreciate a good looking webGUI.  I do, as evidenced by the amount of work we're expending on the "bootstrap pfSense" project (   We're currently 38 pull-requests ahead of the repository, and we welcome any and all help from the community.

But while pretty is nice, I have far more important things to cogitate.

In addition to running a business, with all the associated challenges, I find that I am drawn to find ways to counter the attacks on networks and applications by the world's state security agencies.  Bruce Schneier recently posted "The Further Democratization of QUANTUM" explaining one of the more serious of these.

QUANTUMINSERT is a HTML Redirection attack that works by injecting malicious content into a specific TCP session. A session is selected for injection based on 'selectors', such as a persistent tracking cookie that identifies a user for a longer period of time.

The injection is done by observing HTTP requests by means of eavesdropping on network traffic. When an interesting target is observed, another device, the shooter, is signaled to send a spoofed TCP packet. In order to craft and spoof this packet into the existing session, information about this session has to be known by the shooter.

All the information required by the shooter is available in the TCP packet containing the HTTP request:

  • Source & Destination IP address
  • Source & Destination port
  • Sequence & Acknowledge numbers

For the attack to succeed the packet injected by the shooter has to arrive at the target before the 'real' response of the webserver. By exploiting this speed difference or race condition, one can impersonate the webserver.

I've included links to more information about QUANTUM at the end of this post.

Nicholas Weaver wrote wrote (and Schneier agrees):

"The only self defense from all of the above is universal encryption. Universal encryption is difficult and expensive, but unfortunately necessary."

If the encryption used to secure a network or application is weak, it provides a false sense of safety.  If it is too slow, then it causes inconvenience for the users of that network or application.  Encryption must be both strong and fast in order to become ubiquitous and universal.

We've been working to make encryption in pfSense (and FreeBSD as our upstream) both fast and secure.  We, along with the FreeBSD Foundation, brought AES-NI acceleration for the AES-GCM algorithm to FreeBSD last year.  We also added support for an RFC compliant implementation of IPsec to pfSense.

While that work completed last year, and we have a working IPsec with AES-GCM in pfSense 2.2, we only recently began the work of upstreaming the patches to pfSense back into FreeBSD.  The first of these was accepted into FreeBSD about a month ago.

While we anticipate that not all of our patches will be accepted upstream (frankly, some of them are ugly hacks that we should have shed years ago), we do anticipate that many of the patches will be accepted, potentially with some work on our end to rewrite them to FreeBSD coding standards.

In particular, the work of bringing AES-GCM support for IPsec to FreeBSD has finally begun.

Somewhat in parallel, we've been working to bring support for Intel's QuickAssist Technology to FreeBSD (and pfSense).  A version of QAT is included in the C2000 SoC, and most of the appliances for sale on the pfSense store include a C2000 SoC.  Intel rates the QuickAssist unit in the C2758 (and C2758) at 7Gbps when used with IPsec.  Other C2000-series SoCs are slower, commensurate with their clock rate.

We also have proof of concept code that uses a QuickAssist unit to greatly speed up OpenSSL, and patches to nginx to take advantage of this code.

The usage of HTTPS in combination with HSTS can reduce the effectiveness of QUANTUMINSERT. Also using a CDN that offers low latency can make it very difficult for the QUANTUM packet to win the race with the real server, but this only makes the attack position-dependent.

Even before these become available, detection of QUANTUM attacks is possible by looking for duplicate TCP packets which have different payload as well as other anomalies in TCP streams.

Among the leaked NSA documents was a slide from the Communications Security Establishment Canada describing how to detect QUANTUMINSERT attacks.  See slide 16 in:

QUANTUM is used to attack a number of protocols and applications.  See this link for details:

A video was posted online by The Intercept that shows the inner workings of QUANTUMHAND, which uses QUANTUMINSERT against targets visiting Facebook:

As it turns out, Suricata is able to detect these kind of attacks.  Suricata has an event called 'stream-event:reassembly_overlap_different_data' that can be alerted on when triggered using a default signature. An additional signature that detects HTTP 302 responses in possible QI payloads is available.

You can use the Suricata package for pfSense to detect QUANTUMINSERT.  By rebuilding the Snort package with the patches included in the same repo, it too may be used to detect QI.  We'll be working to incorporate these into the pre-built packages for pfSense, as well as to push them into upstream ports.

In order to test these, tools that can be used to simulate and perform QUANTIUMINSERT are available:


More information on QUANTUM:

Chinese government use of packet injection:

Hacking Team sells packet injection:

Packet injection tool:

China's Great Cannon:

Packet injection homework assignment:

Nicholas Weaver:

The democratization of cyberattack:



Shared via my feedly reader

Sent from my iPhone

No comments:

Post a Comment