Circumventing Netflow's visibility on SSL traffic

Question

In a SSL handshake, the hostname is visible most of the time as it is needed to validate the certificate over HTTP. Netflow is thus able to pick up the common name from the certificate exchange, revealing the hostname.

Would a C&C server be better off using a self-signed certificate using IP as common name (since legitimate providers do not allow that) with a static IP and no domain name, so that when Netflow queries, it only sees the IP address? Since C&C IPs change frequently, it would be hard for any investigations to make out any meta data out of this. Also, SSL certs and domain names leave traces on whois, and might be breadcrumbs for investigation. The certificate is between servers without user interaction, and security is not key, so self-signed is acceptable.

Answer 1

While a C&C client would hide its real target by not using SNI it would be suspicious especially because it does not use SNI with HTTPS while everybody else does. It might be better then to claim that it connects to some innocent target by setting the SNI extension accordingly but in reality connecting to the C&C server. This only needs some fiddling in the TLS stack and is not much harder for an experienced attacker to do.

But since the certificate of the server is sent by the server in clear with a full TLS handshake one can still check if the certificate returned by the server matches the name given in SNI and is also issued by a trusted CA. To bypass this the C&C client might try to simulate a resumed connection everytime. To do this way more fiddling with the TLS stack is needed so it might be simpler to use a protocol which looks enough like TLS to fool the detection but is not real TLS. I think this is what Skype has at least done in the past to bypass firewalls and maybe it still does this today.

Another approach would be to use domain fronting, i.e. (mis)use a system which is serving multiple domains on the same IP address, serves the certificate based on the SNI extension in the TLS handshake but serves the actual content based on the Host header which is encrypted within TLS and thus not accessible when doing passive inspection. In this case it looks like the client connects to some innocent site while in reality it connects to its C&C master.

If the attacker controls relevant parts of the server (for example because it was hijacked) it could also (continue to) serve a mostly innocent site and then use only specific path on it for the C&C communication. Since the path of the URL is not visible when doing passive inspection of HTTPS it probably looks like the client is just accessing innocent data on this site.

Still, SNI is not the only thing which can detected with passive analysis. The handshake of the client also shows which kind of ciphers it supports and the preference and a variety of TLS extensions and their order. Also significant pattern of the traffic like size of request and response or timing are still visible even if the traffic is encrypted. This can also often be used to fingerprint the client and thus distinguish typical browser from other clients and maybe known C&C clients. Cisco has done interesting research in this area.