How it works

SeaCat is designed to securely transport data packets regardless Application protocol.

SeaCat and TCP Model

TCP Model

SeaCat operates on application, transport, and internet layer. On application layer, SeaCat transports HTTP/HTTPS or MQTT protocol. Other protocols are transported on transport layer by using network sockets or on internet layer.

Transport on Application Layer

Common HTTP protocol communication flow between Application and Application Backend look as on the diagram:

High Level View

For successful establishment of Client Connection for HTTP Requests, the following SeaCat components are utilized:

Steps-by-step process:

  1. Application generates a URL request
  2. Application generates an HTTP request
  3. SeaCat SDK intercepts the HTTP request
  4. Based on HTTP request, URI SeaCat SDK asked Discover Service for target SRV entry and associated IP address of the SeaCat Gateway for particular Application
  5. SeaCat Gateway verifies Client Certificate
  6. SeaCat SDK verifies SeaCat Gateway Certificate (mutual authentication is done, Client Connection is established)
  7. SeaCat SDK passes the HTTP request to SeaCat Gateway via Client Connection
  8. SeaCat Gateway takes the HTTP request and passes it to Application Backend
  9. Reply from Application Backend is similar but in reverse order
  10. Client Connection is established until Client inactivity time out

HTTP headers

If it is configured, SeaCat Gateway append HTTP headers (e.g. X-Forwarded-For, X-Forwarded-Host) to every HTTP request to provide additional details about Client to Application Backend for further processing.

For more Host configuration options, go to SeaCat Host Configuration Reference.

Transport on Transport Layer by using Network Sockets

Transport via transport layer uses network sockets. For successful establishment of Client Connection, the following SeaCat components are utilized:

Steps-by-step process:

  1. SeaCat Agent receives TCP request from the operating system
  2. Based on TCP request destination, SeaCat Agent asked Discover Service for target SRV entry and associated IP address of the SeaCat Gateway for particular destination
  3. SeaCat Gateway verifies Client Certificate
  4. SeaCat Agent verifies SeaCat Gateway Certificate (mutual authentication is done, Client Connection is established)
  5. SeaCat Agent passes the TCP request to SeaCat Gateway via Client Connection
  6. SeaCat Gateway takes the TCP request and passes it to the destination
  7. Reply from the destination is similar but in reverse order
  8. Client Connection is established until Client inactivity time out

Client addressing

By using persistent Client Connection it is possible to reach Client from the Application Backend side when Client is connected and the Client Connection is established. SeaCat Gateway offers SOCKS proxy to connect to Client (e.g. for customer service helpdesk remote access) via SeaCat Gateway service. SOCKS proxy is not limited in protocol or by an used application.

Applications with native SOCKS proxy support use SeaCat Gateway IP address and SOCK proxy port together with Client ID specification for remote access to Client. All other applications without native SOCKS proxy support need to use SOCKS proxy enabler (for example socat command).

Example of SSH Remote Access

Secure shell program (SSH) is a common administration tool to enable remote access to the Linux server. It does not contain SOCKS proxy ability. For using SSH remote access to Client via SeaCat, the following configuration is necessary:

  1. Edit .ssh/config by the following code, where 1.2.3.4 is SeaCat Gateway IP address and 12367 is a SOCKS proxy port.:

    Host *.seacat
        ProxyCommand socat stdio SOCKS4A:1.2.3.4:%h:%p,socksport=12367
    
  2. Run a SSH command. c36519d7479610d562725d78649108d20bfeb0e341b6aa63aa4979441e623e7584fbfbfbc529ca51aebc67ad9e4a789f is Client ID of the remote Client.

    ssh root@c36519d7479610d562725d78649108d20bfeb0e341b6aa63aa4979441e623e7584fbfbfbc529ca51aebc67ad9e4a789f.seacat

Mutual Authentication

For ensuring the security of every Client Connection, mutual SSL authentication is used.

High Level View

The basis of mutual SSL authentication is a certificate verification on both sides of the Client Connection. This approach ensures confidentiality, integrity, authenticity and non-repudiation of data sent via Client Connection. This approach also uniquely identifies every Client, which effectively protects against Man-In-the-Middle attacks. No other Client except the whitelisted one is authorized to establish Client Connection.

For more cryptographic details, go to Cryptographic details chapter.

Found a mistake? Please contact us.