Therefore, we look for HTTP and HTTPS connections from the same client over a short time period and pair cipher suites and User-Agents from such connections. We assume that clients mostly communicate on both protocols. The novel network-based method is based on simultaneous monitoring of HTTP and HTTPS connections. The host-based approach is based on advanced logging on the server side. We use two approaches to obtain pairs of cipher suite lists and corresponding User-Agents. However, it is not possible to get the User-Agent from the HTTPS request without decryption. We suppose that the list of supported cipher suites (declared by the client in the ClientHello message) can be used as an identifier similarly to a User-Agent in a HTTP header. Second, we shall correlate selected parts of SSL/TLS handshakes and HTTP headers. Recent discoveries of severe vulnerabilities, such as POODLE, might have significantly changed the proportion of protocol versions in use. Apart from the usable information for identifying the client, we are particularly interested in the share of old and vulnerable protocol versions. We focus on analyzing information provided during the handshake by the client, i.e., the ClientHello message containing the protocol version, list of supported cipher suites, and other data. We shall deploy network traffic monitoring, filter HTTPS connections, and create a list of the SSL/TLS handshakes and their fingerprints. How much information, i.e., number of known SSL/TLS parameters and pairings to HTTP headers, do we need to analyze a significant portion of network traffic?Ĭan we utilize the SSL/TLS fingerprinting in network security monitoring and intrusion detection?įirst, we aim to observe real network traffic to gain insight into contemporary SSL/TLS handshakes. Which parameters of a SSL/TLS handshake can be used for client identification?Ĭan we pair selected SSL/TLS handshake parameters and HTTP header fields? To sum up our goals, the research questions are: The fourth question addresses applicability of results. We set up an experiment, which will answer three research questions. Therefore, we approach the problem of identifying the SSL/TLS client and classifying HTTPS traffic by building up a dictionary of SSL/TLS handshake fingerprints and their corresponding User-Agents. However, only the SSL/TLS handshake can be observed in a HTTPS connection without decrypting the payload. The similar client identifier is a User-Agent value in a HTTP header, which is commonly used for identifying the client and classifying traffic. This information varies among different clients and their versions. Therefore, the initial packets contain unencrypted messages with information about the client and server. In a communication encrypted by SSL/TLS, the hosts have to first agree on encryption methods and their parameters. In this paper, we shall discuss HTTPS-HTTP over SSL/TLS, the most common encrypted network traffic protocols. Furthermore, malicious network behavior can be hidden in encrypted connections, where it is invisible to detection mechanisms. The more secure the connection is, from the point of view of communicating partners, the harder it is to understand the network traffic and identify anomalous and malicious activity. Nowadays, we are able to monitor, identify, and classify plain-text network traffic, such as HTTP, but it is hard to analyze encrypted communication. On the other hand, it complicates the legitimate monitoring of network traffic, including traffic classification and host identification. On the one hand, it provides secure data transmission, protects against eavesdropping, and improves the trustworthiness of communicating hosts. The rising popularity of encrypted network traffic is a double-edged sword.
0 kommentar(er)
