New Report: Most common errors when implementing HPKP, HSTS and preload conditions

Tuesday, January 17, 2017

We have collected and visited two different sources of domains and webpages, Alexa top million domains, and Shodan. These results come from November 2016 searches. From those domains, we have restricted the search to be able to determine which ones use HSTS or HPKP over HTTP or HTTPS, and even which of them uses different configurations for the headers. We have tried to determine not only the quantity but the "quality" of the implementation. Just 0,02% of most popular domains are implementing HPKP in the best possible way, and just 0,74% are doing so with HSTS. Even or have some errors.

We show now some excerpts from the report you cand find here.

Number of pins

When implementing HPKP it is important to respect the number of pins required. Despite the recommended values are using between 3 and 4 pins, some domains use from just one pin (violating the RFC) up to 17, which seems to be an irregularity that reduces the efficiency. Regarding Alexa top million domains, 282 out of 450 domains use 2 or 3 pins, which is correct. 89 (19,8%) use zero or just one, which is useless from the browser standpoint since it will ignore it.

Number of pins offered by top 1 million Alexa domains using HPKP.

Which certificate to pin

When using HPKP, choosing the right certificate to pin may be an important decision. Administrators may use whatever pin in the chain (root, intermediate or leaf) but this decision may impact directly in their usability and security from the administrator standpoint and user security. There is a tradeoff between security and maintenance.
  • Pinning the root offers less security, but an easier way for the administrator to deal with HPKP. This means that, as long as the administrator does not change its CA provider, no additional changes should be done, so less maintenance is required. But, on the other hand, if an attacker gets a fake certificate from the same CA, the browser would not detect the difference, since the root remains the same.
  • Pinning the intermediate certificate is the best choice, maybe. The attacker should get a certificate from the same subCA to make the "perfect" attack. The administrator, on the other hand, may change its leaf certificate as long as it comes from the same subCA with no extra cost of changing pins.
  • Pinning the leaf is the most secure way, but the most "dangerous" as well. If the certificate expires or for whatever reason the certificate changes (more specifically, the public key), even if issued by the same CA or subCA, the administrator has to modify its pins or use the backup one. On the other hand, an attacker may not be able to create a valid certificate (unless the private key is stolen) to create a man in the middle "perfect" scenario.
So we have checked what certificate does administrators pin, and this is what we have found. Most of them (73,65%) use the intermediate certificate to pin.

Pinned certificates in the trust chain for the top million Alexa domains using HPKP.

Pins reuse

Reusing pins among different domains is not an invalid practice at all. Considering that most of the pins used in HPKP are "intermediate" pins mostly from subCAs, it is even absolutely normal to share some pins between domains. But this procedure brings a little risk. Thus, from an attacker standpoint, knowing which subCAs or even CAs are pinned may allow to plan a specific APT for that domain. For example, if a domain issues its intermediate certificates with a specific subCA and pins this intermediate certificate, an attacker that gets a rogue leaf certificate for that domain issued from the same subCA will still have a perfect MiTM situation, since the browser will not show any warning message. Therefore, from the attackers standpoint, if they are able to determine if a domain pins its intermediate certificate, and furthermore, which one is the pinned subCA, it allows him to know better who to target. Additionally, if the attacker wants to maximize its scope, he would try to get a rogue certificate signed by this "popular" subCA.

The following map represents which certificates (and its pins) are pinned with more domains. These are the top 25 most pinned certificates. Since the protocol allows to know just the pin and not the certificate itself, it is necessary to "unhash" the certificate. We have collected several millions of certificates and hashed them to compare it with the pins associated to the domains. The results show how an intermediate certificate from Comodo is the most pinned certificate (klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY=). It pins 40 different domains from Alexa and Shodan.

Pins reuse map. Click to enlarge.


To avoid "Trust on first use" issue, "preload" mechanism was introduced. This preload works as a root CA embedded in the browser. It is basically a list of domains that are willing to be accessed with HSTS securely from the first time. This list is maintained by Google and some conditions have to be satisfied to belong to this list.
  • Have a valid certificate chain and redirect from HTTP to HTTPS in the same host (of course)
  • Serve all subdomains under HTTPS. WWW is mandatory if it exists in DNS server.
  • Serve HSTS header via HTTPS with this properties:
    • max-age is at least 18 weeks (10886400 seconds).
    • includeSubDomains directive must be included.
    • preload directive must be included.
    • If serving an additional redirect from the HTTPS site, it must still use the HSTS header (rather than the page it redirects to).
If all these conditions are satisfied, the domain owner may apply to the list in here: and the domain will be eventually included in the list. This webpage allows as well to check if a domain satisfies or not all these conditions. There are a total of 18197 domains preloaded in Chromium list (shared with Firefox). As of December 2016, only 2056 domains from the top 1 million from Alexa are in that list.

Preloading status in Alexa's top million domains

In the background, uses a public API providing the reasons why a specific domain may be preloaded or not. We have checked all the top million Alexa domains against this API, to know if preloaded domains do really validate all this conditions to be preloaded. When a domain is checked against this API or preload list, the domain is visited in real time and errors checked. It is interesting to prove that, from those 2056 preloaded domains in top Alexa list, 662 contain some errors, thus, strictly speaking, they should not be preloaded. We have even detected that, 67 out of those 2056 preloaded domains in the list, do not contain the preload directive in the header, which as well violates the condition. and are domains that do not keep the mandatory conditions to be preloaded, but they actually are.


Although HSTS and HPKP protocols are intended to provide an additional layer of security to HTTPS communications, their implementation is not widespread. At server level, many of the most relevant Internet domains do not even implement them. Moreover, among the minority of domains that do use them, there exist a significant number of implementation errors, even a disregard of the recommendations of their respective RFCs. This situation shows both low level adoption and, somehow, some misunderstanding about how to take full advantage of these protocols. Some of the most interesting figures are:

  • From Alexa, we have collected 632648 HTTPS domains, and 901958 HTTP domains. We retrieved 30886979 HTTPS (port 443) domains and 45330802 HTTP (port 80) domains (a total of 76217781) from Shodan.
  • Only 1,9% of domains in Shodan use HSTS correctly over HTTPS, while just a 5,35% from the Alexa top million do so.
  • 4717 (roughly a 0.74%) of the top million domains in Alexa using HTTPS (632648) are implementing HSTS in the best possible way.
  • 175 of the top million domains in Alexa (a roughly 0,02%) using HTTPS (632648) are implementing HPKP the best possible way.
  • 20% of top Alexa domains using HPKP over HTTPS use zero or just one pin, which is useless from the browser standpoint since it will ignore it. Most of them (a 73,65%) use the intermediate certificate to pin.
  • 17% of domains in Alexa implementing HPKP are using a wrong or ignored max-age value.
  • The most used pin (a certificate from Comodo) pins 40 different domains from Alexa and Shodan.
  • There are a total of 18197 domains preloaded in Chromium list (shared with Firefox). As of December 2016, only 2056 domains from the top 1 million from Alexa are in that list.
  • From those 2056 preloaded domains in top Alexa list, 662 contain some errors if checked against the official preloading API, so, strictly speaking, they should not be preloaded. Whatsapp and Facebook are among those domains that do not keep the mandatory conditions to be preloaded, but they actually are.
Here is the whole report.

See You at the RSA Conference 2017

Monday, January 16, 2017

The U.S. city of San Francisco is to host once again, as it does every year, one of the most important events worldwide in the field of security, RSA Conference. From 13 to 17 February, the most relevant players within the industry worldwide will gather, and ElevenPaths, Telefónica's cyber security unit, will be there among them of course.

We offer you a pass to the exhibition area absolutely free of charge. To get your ticket you only need to register here using the code: XE7TELFNCA. Deadline for registration February 10th.

We look forward to seeing you at stand #410 in the South Hall of the Moscone Center, where you will discover: 
  • Enjoy a one-on-one ElevenPaths' senior executives and cyber experts.*
  • Join our Cyber Security lovers’ day party on Tuesday 14 February at 3:00 p.m.

Remember! We look forward to seeing you from 13 to 17 February at the RSA Conference in San Francisco, at the Moscone Center, South Hall, stand #410.

*In order to book your one-on-one with our experts you should complete the mail with your name, surname, title, availability schedule, company, meeting purpose. Deadline for booking February 9th.

Browser Extension Usage by the Islamic State Propaganda

Friday, January 13, 2017

One of the tools that the Islamic State has been using to spread its propaganda is the use of social networks. In the past they have shown how capable they are of expanding their capabilities to cover smartphones and mobile devices, but recently they have also opted for the development of browser add-ons in order to further facilitate access to their content.

Although Firefox extensions are mainly distributed by means of the official market run by Mozilla, the Amaq News Agency, identified as part of the Islamic State’s propaganda apparatus, is also distributing .xpi files in related websites. These files are compressed in .zip and renamed to a .xpi that contains the Javascript, CSS and HTML code that defines the behaviour of the extension.

About this extension, we have identified at least two different versions, 1.0.1 and 1.0.2, whose folder structure contains the same series of source and data files.
├── bootstrap.js
├── data
   ├── safe-16.png
   ├── safe-32.png
   ├── safe-48.png
   ├── safe-64.png
   ├── safe.png
   ├── unsafe-16.png
   ├── unsafe-32.png
   ├── unsafe-48.png
   ├── unsafe-64.png
   └── unsafe.png
├── icon.png
├── install.rdf
├── lib
   └── main.js
   ├── mozilla.rsa
   └── mozilla.sf
└── package.json

The most interesting files are three: package.json, install.rdf and the Javascript source file found at lib/main.js:
  • package.json contains metadata and information about the extension like the name, the author, the licenses or the permissions required.
    "name": "amaq",
    "title": "Amaq AR",
    "id": "jid1-5Fs7iTLaaUaZBgwdar@amaq",
    "description": "Amaq AR.",
    "author": "Amaq AR",
    "license": "MPL 2.0",
    "version": "1.0.2",
    "icon": "icon.png",
    "permissions": {
        "private-browsing": true
    "engines": {
        "firefox": ">=38.0a1",
        "fennec": ">=38.0a1"
    "main": "lib/main.js",
    "devDependencies": {
        "gulp": "^3.8.11",
        "gulp-image-resize": "^0.6.0",
        "gulp-rename": "^1.2.2"
  • install.rdf defines in the field em:targetApplication that the extension is thought to be installed in certain versions. In this case, it explicitly shows that it is valid for different versions of Firefox Browsers, including Firefox for Android (this is defined by the tag <em:id>{aa3c5121-dab2-40e2-81ca-7ea25febc110}</em:id> tagasda).


  • lib/main.js defines the code of the extension itself. In this case, it opens a new tab pointing to a given URL as shown in lines 107 and 108. The only difference between versions is the IP address shown in line 108.

var tabs=require("sdk/tabs");"");

Using the extension as a bookmark

In the case of the first release of the add-on 1.0.1, the URL opened was hosted at IP address (a non-accessible address linked to an internet services provider settled in Sweden) while in the most recent version this IP address is This address, still accessible at the moment of writing this article, is linked to an anonymous hosting provider settled in Panama that runs a nginx 1.6.2. However, this resource seems not to be hosting the contents itself because if we access to this URL it responds a 302 Moved Temporarily code and redirects us to, the agency website.  There, this Firefox extension can also be downloaded as amaq_news_agency_ar-1.0.2.xpi together with a hash of the file that would ultimately allow users to verify the legitimacy of the extension.

$ curl -I
HTTP/1.1 302 Moved Temporarily
Server: nginx/1.6.2
Date: Tue, 10 Jan 2017 11:02:55 GMT
Content-Type: text/html
Content-Length: 160
Connection: keep-alive

The referred website is hosting news in Arabic about Amaq and the Islamic State and is protected by Cloudflare making it impossible to know the real location of the systems used to serve the contents.  By using this approach, banning the access to would not be enough to stop their propagation mechanisms considering that the application developer would only need to modify the Location field to redirect to the new domain in which the content would be hosted.

Identifying other affiliated websites

The structure of the URL found in the extension suggested the possibility of the existence of other domains. The tests conducted have returned new 302 responses that pointed to at least 6 other domains also protected by Cloudflare and whose content is also tied to the Islamic State. The details of the certificates used indicate recent validity periods as can be seen in the following table.

Redirected domain
Certificate valid since

Apart from this extension, there is no evidence of the existence of others with a similar behavior that point to the rest of domains. However, the recent creation of the certificates suggests that newer similar add-ons could be created easily by modifying only the URL of the original file to point to one of the URL shown before.

Registrant information and other metadata

Regarding the registry of identified domains, those that do not present special privacy protection measures have been registered email accounts using the encrypted email provider taking into account that the,, and (used to register a domain linked to the organization which is no longer used like are different domains that make use of this service.


On the other hand, the rest of files identified in the extensions do not show too many details apart from some EXIF data found in the agency logos and icons. These files seem to have been edited with various Adobe products for Windows according to its metadata.


The Islamic State has shown in the past that it has used the means at its disposal to massively spread its content in both, social networks and mobile applications. In this case, the use of a browser plug-in is another example of how the individuals linked to this organization are capable of adapting themselves to ensure the dissemination of content using not only a technological assets located in different countries, but tools and systems such as Cloudflare and various servers and methods to ensure the effectiveness of the difussion of their message. 

Félix Brezo
Intelligence Analyst at ElevenPaths

Yaiza Rubio
Intelligence Analyst at ElevenPaths