Cloud 101CircleEventsBlog
Call for Presentations: Share your expertise at 2024! Submit your proposals by June 28th.

Web Protocol - Uses Finite State Machine

Web Protocol - Uses Finite State Machine

Blog Article Published: 07/15/2022

Written by Gregory Machler, Cybersecurity Engineer, Daikin Applied.

In an attempt to improve the cybersecurity of the communications between a browser and web server, I’ve been mulling over session protocols. In prior thoughts last year, I commented on the use of TLS 1.3 to encrypt traffic between the browser and the web server.

The deployment of TLS 1.3 will be a great improvement in security of https traffic. Its strengths over prior TLS versions are significant because it is not backward compatible. So, protection of sessions via TLS 1.3 is excellent.

How does one improve upon superior encryption? One can implement a finite state machine at the application layer between the browser and the web server. This will allow applications to be run in defined states, which improves cybersecurity. I recommend using a different port. We’ll call it port httpf (finite state machine). It implements an application layer finite state machine embedded within an encrypted TLS 1.3 session.

So, this new traffic won’t use ports 80 (http traffic) or port 443 (TLS 1.3 protecting standard http traffic). The new finite state machine will improve application states, and thereby remove the dependence on cookies for maintaining the static session state which has security vulnerabilities. The finite state machine states can be modeled after a subset of the TCP finite state machine and operate in the application layer. This will lead to a more secure session, such as addressing Denial of Service attacks more effectively.

The globally used TCP finite state machine has the following states[1]: Listen, Syn Sent, Syn Recvd, Established (session), Wait, Closing, Close Wait, and Closed. There are a few more non-critical states.

Here are most of the TCP state transitions:

  1. Closed to Listen or Syn Sent
  2. Listen to Syn Recvd or Syn Sent
  3. Syn Recvd to Listen, Established, or Wait
  4. Syn Sent to Closed, Syn Recvd or Established
  5. Established to Fin Wait and Close Wait

Having the session Established is what is most important because that is when normal traffic is flowing. But the Syn Recvd or Syn Sent states are important because they are the transitions that help get to the Established state. The Listen state is important in that it exists to receive the initial traffic on the httpf session protocol.

This TCP state machine might be simplified as an application layer state machine. One wonders if only a subset of the TCP finite state machine is needed. The implementation will need a significant amount of testing within customized browsers and servers because it can impact global traffic. The browser and server must support use of the newly proposed finite state machine.

Operating applications within a finite state machine protects applications from different types of attack. The attacker doesn’t know which state an application session is in. Guessing could lead to packet rejection. Applications that use the new httpf protocol can take advantage of its cybersecurity strengths immediately. Transitioning applications to use httpf throughout the internet can be done gradually over time.

Some applications that execute within http or https sessions could be rewritten or converted to httpf. An upgrade analysis of an application can be created to identify portions of software that deal with static sessions and cookies; it then makes recommendations on how to convert the application to use httpf. Session logic will need to be reviewed and altered. Converting current applications properly may not be easy.

Cybersecurity doesn’t really ever go away, but we can make it harder for criminals to go about their business. They have significant money and time on their side. We need secure architectures to foil their plans.

[1] Internetworking with TCP/IP Volume II, Design, Implementation, and Internals, pg. 174.

About the Author

Greg Machler is a cybersecurity engineer with Daikin Applied. He has spent much of the past 10 year focused on security architectures, contracts and vendor analysis, and application security. He also has developed network protocols and other complex software applications. He can be reached at [email protected].

Share this content on your favorite social network today!