How does DPI basically identify SSL data traffic? Just by the number “443” in port section or the SSL traffic has some other particular properties other than “443”?

Thanks in advance,


SSL/TLS has a very specific on-the-wire format for data: data is sent as records. Moreover, at the start of every connection:

  • The client talks first.
  • The client sends a "handshake" record containing a handshake message of type ClientHello.

So the very first byte from the client will be 0x16. It is then followed by the protocol version, which will be two bytes: 0x03, then a byte of (normally) value 0x00 (for SSL 3.0) to 0x03 (for TLS 1.2). Then the record length as two bytes. Within the record payload is found the handshake message header: a byte of value 0x01 (type for a ClientHello) followed by a three-octet length.

At some point, I had used a multiplexer for SSL and RDP on the same port: since the RDP connection begins with a byte of value 0x03 from the client, while the first byte of SSL is 0x16, so I could write a simple program which forwarded the data to either the Web server or the RDP server, depending on that first byte.

Not all DPI systems are sophisticated, and some can be fooled by applying variants of the protocol. For instance, the client can split the ClientHello message into several records, and possibly begin with a long stream of empty records. Some server implementations will actually tolerate an initial sequence of a thousand alert messages (of type "warning") which may evade the DPI system scrutiny in several ways:

  • The DPI system may expect a first byte of value 0x16, and deem it non-SSL if any other byte is sent (e.g. a 0x15 for an "alert" record).
  • The DPI system may expect the ClientHello to be contained within a single record, without fragmentation, and thus not recognize the SSL handshake.
  • The DPI system may expect the ClientHello within the first packet of the TCP connection, and all the extra empty records or alert record may push the ClientHello arbitrarily far into the TCP connection.

The trick here is to find variants which are accepted by SSL server implementations (who themselves have some more-or-less arbitrary limitations) but are not covered by whatever DPI system you are trying to hide from.

(If unsure, try to implement a custom SSL library -- for learning, not for production use, of course. This will teach you a lot of things on the details of the protocol.)

| improve this answer | |

In order to establish TLS/SSL, the parties must first handshake (which is conducted in the clear, at layer 5 of the OSI model). An eavesdropper can readily recognise this process and record that the connection is using TLS/SSL.

Thereafter, the communication between the parties is encrypted (at layer 6) and an eavesdropper cannot intercept the application data (at layer 7).

However, as you have noted, lower levels can still be observed: in particular, one may be able to infer the application protocol from the TCP port number (at layer 4). Port 443 is reserved by IANA for HTTPS, so HTTP would be a good guess (one might even perform an active attack and attempt to communicate with the server in order to see whether it responds to an HTTP request over TLS on that port).

Also, don't forget that traffic analysis can prove extremely informative. With SMTP one would expect a short two-way handshake followed by a bulk of data being sent by the client, followed by a short two-way farewell; this would contrast with HTTP where one would expect a short request being sent by the client followed by a larger response from the server. Indeed, using traffic analysis alone researchers have been able to quite accurately guess exactly which HTTP resources have been requested by clients over TLS.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.