Articles / Mitigating that Nagging Inbound TCP SYN Packet Weakness

on 03 Apr 2017

We lost a pioneer last year when Chuck Flink, inventor of Unix System V/MLS, passed in May. Chuck’s idea was to steal bits from the Unix group identifier, known as the GUID, to create multi-level security labels for the familiar lattice model of clearance and need-to-know. Such labeling enabled Unix for sensitive applications requiring mandatory access control. It was a precursor to SE-Linux and SE-Android.

Stealing bits from the GUID was a great idea, because the largely unused structure was there in the operating system, and re-using it for security labels seemed a win-win for everyone involved. Some Unix purists saw the approach as messy, but I always thought it was opportunistic genius and that cyber security experts should have studied Chuck’s work more carefully. We are going to miss him.

During a recent technical review with John Hayes, CTO of BlackRidge, I found my mind wandering back to Chuck’s work, because I felt chilling (and exhilarating) parallels between their work and Chuck's Unix GUID design. BlackRidge is embedding identity credential information into the existing TCP handshake, thus improving the sacred Alice-and-Bob dance that’s been with us since Cerf and Kahn first conceived the protocol. I had to ask John to repeat his explanation a couple of times, because it seemed inconceivable that after decades with this protocol, a team might find a new means for enhancing security. But BlackRidge seems to have done just that.

Anyone familiar with TCP knows that application-level authentication cannot occur until a session is established. Policy teams realize this when they order up inbound firewall rules for outsourced call centers. They see that the three-step TCP handshake occurs first, and only then can any authentication commence. If the authentication fails, then that inbound connection that should not have been allowed in the first place. This scenario has always struck me as a hole in connection policy enforcement, and has led to weak safeguards such as source IP-based blocking, which can be easily spoofed.

The BlackRidge solution uses a technique known as Transport Access Control (TAC)and more specifically as First Packet Authentication. On a per-session basis, cryptographic identity tokens are inserted into the sequence field of the TCP header for that first SYN packet – the one that helps firewall engineers put their kids through college. A TAC gateway from BlackRidge sees the first SYN, extracts the crypto token, and then uses it to establish the identity that has been bound to that token. Depending on the policy associated with that identity, the TCP session would be allowed or denied. This functionality allows network security engineers to create trusted domains, thus allowing for an inbound packet security check point from the call center.

One of the great advantages of TAC over similar protocols such as IPSec involves the common headaches that come with network address translation (NAT). As any network security engineer will explain (complain), NAT includes modification of IP addresses and TCP port numbers, which causes numerous operational problems with the IPSec Authenticating Header protocol. In contrast, TAC executes in a transparent manner across networks that employ NAT. It also easily supports man-in-the-middle network or security solutions that would otherwise have trouble dealing with IPSec tunnel mode encryption.

Another advantage of TAC is that its use of the sequence field in the TCP header results in no operational impact to existing network or security infrastructure. The TAC approach interoperates with standards-compliant TCP/IP stacks, and does not require changes to endpoints. It also encourages the use of multiple administrative domains. But more than anything else, it closes a logical security weakness that has nagged enterprise security teams for years – namely, the allowance of inbound TCP sessions blindly.

Like those who criticized Chuck Flink’s GUID design two decades ago, there will be those who complain that TAC adjusts a standard protocol in a way that is consistent with TCP's original purpose. I asked John Hayes about this and he acknowledged that this purist view might complicate turning TAC into a fully-accepted standard or RFC. My advice to the purists is to get over it: Everyone knows that TCP/IP has been ill-suited to cyber security, so protection enhancements should be welcomed.

Much of the above discussion might sound like technical mumbo-jumbo to the less well-informed on network protocols and OSI stack technologies. Perhaps the following non-technical analogy might help: If you want to check the credentials of strangers on the street who would like to enter your kitchen, you could set up a check-in table in your living room, thus allowing entry to your home (i.e., current TCP technology). Or you could take the more sensible route of setting up the table outside your home to check credentials before anyone enters your home. This is what TAC does on your network.

I think I know which of these two methods I would choose. I don’t like strangers in my living room. And I'll bet Chuck Flink would have agreed.

Let me know what you think.