Applications of ZMap: weak keys and HTTPS ecosystem

ZmapHi there,

in the previous post on ZMap we gave an overview on this new tool for high speed Internet scanning. In this post we will go into detail by showing remarkable findings and results achieved thanks to ZMap.


The first finding we will talk about concerns SSH and HTTPS keys. ZMap’s creators found out that many keys are shared among multiple servers. Although a key can be shared for many legitimate reasons, in some cases (5.6% of TLS hosts and 9.6% of SSH hosts) keys are shared in a vulnerable manner because of entropy problems. Using a vulnerable (predictable) key means that an attacker can easily guess the key through a brute force attack and have access to our servers.


On Linux-based systems, the usual way to generate a random key is to read the /dev/urandom interface. The events that generate entropy are time of boot, disk accesses and mouse/keyboard usage. Unfortunately, many keys are generated by headless or embedded network devices, which do not have enough entropy and thus generate predictable keys.


Also, in typical servers, the minimum entropy is reached only after a certain period, while keys can be generated after a couple of seconds after the boot.
For these reasons, if keys are generated with a low entropy, the security of the server can be at risk. In order to avoid this issue, the Linux 3.x Kernel uses additional information such as interrupts and MAC address.

Furthermore, ZMap’s creators monitored the HTTPS ecosystem and found out some critical weaknesses. For instance, they found out that more than 80% of CAs (certificate authorities) are not commercial certificate authorities but a different kind of organization such as hospitals, religious institutions, etc.


The reason behind this abnormal situation is that root certificate authorities tend to sell intermediates without any constraints. By doing so, they might allow malicious entities to obtain a trusted certificate, therefore they are seriously putting the whole ecosystem at risk. Before selling intermediates, root CAs should make sure that the organization to which they are selling the intermediate is trustworthy.


Moreover, 50% of certificates that are currently used, are signed under a 1024-bit key, which does not guarantee a sufficient level of protection. Surprisingly, some certificates are still signed under MD5 (which is known to be vulnerable)!


Since the total number of servers using HTTPS is constantly growing, these issues become more and more important. CAs should definitively apply constraints more carefully in order to protect the HTTPS ecosystem and prevent malicious entities from obtaining trusted certificates.

So what is the message?

  1. If you are using a key to protect your SSH/HTTPS server, make sure the key has been generated with enough entropy and is non-predictable!
  2. Do not trust certificates issued by non-trustworthy CAs! Carefully check certificate’s information before providing sensitive information to a website! If you are a Mozilla Firefox user, you could find this plugin very useful.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s