Popular news websites, hotels, pharmacies, gaming sites, and many online banking sites are among millions of websites that are now explicitly flagged as "not secure" by some of the most commonly used browsers.
Current stable versions of Google Chrome and Mozilla Firefox now display a "not secure" warning in the URL bar if a webpage served over an unencrypted HTTP connection requests a user's password – even if the password is usually submitted to a secure (HTTPS) site. This is because an attacker could modify the non-secure HTTP form and cause the user's credentials to be sent elsewhere.
This security feature was first introduced in Firefox 51, which was released on 24 January, and then in Chrome 56, which was rolled out in the weeks following 25 January. Chrome also displays the warning on pages that contain fields for entering credit card numbers.
Banks failing to protect their customers
Surprisingly many banks have failed to react to the new browser behaviour. For example, Santander's Chilean website at http://www.santander.cl can be accessed over an unencrypted HTTP connection, but it displays an online banking login form regardless.
The contents of the login form are submitted to a secure URL on https://www.santander.cl/, which uses an SSL certificate issued by GeoTrust. This secure connection is therefore protected against man-in-the-middle attacks, but crucially, this security is undermined by www.santander.cl serving its login form over an unencrypted HTTP connection — a man-in-the-middle attacker can simply siphon the customer's credentials from this page before they are even submitted to the secure site.
A few other examples of banking websites that are now marked as "not secure" (and this is not an exhaustive list by any means) include Eagle Bank, Community Bank of Fitzgerald, Diamond Bank, Flora Bank & Trust and Bank of Hamilton.
Ironically, some of these examples display padlock icons on their online banking login forms, despite serving them over unencrypted HTTP connections. This gives a misleading impression of security, although the risks are now made apparent to any user of Firefox 52.
Pharmacy logins exposed
CVS pharmacy — the largest pharmacy chain in the United States, with a parent company that is #7 in the Fortune 500 — also displays its login form over an insecure connection. Interacting with this form in Firefox 52 will cause the "not secure" warning to be displayed much more prominently, beneath whichever field has focus. This is much harder to miss than just the crossed padlock icon in the address bar of Firefox 51.
A customer who signs in to CVS can manage their family's prescriptions online, so any security weakness that potentially exposes their login credentials could raise some regulatory eyebrows. To maintain the privacy and security of Electronic Protected Health Information (EPHI), the HIPAA Security Rule lays out a set of administrative, physical and technical safeguards. The latter is intended to protect communications being intercepted by anyone other than the intended recipient.
Why are browser vendors doing this?
Such attacks are entirely plausible, especially with the prevalence of mobile computing. The attacker does not need to infiltrate an ISP or be part of a spy agency in order to view a victim's network traffic – he can simply turn up to a coffee shop and use his phone or laptop to offer a free Wi-Fi network that other customers are likely to use. This would allow him to view and alter the contents of any HTTP form without detection.
The warning feature was previously made available in development releases of both browsers. When it was added to Firefox 46 Developer Edition in January 2016, Mozilla stated that there were no plans to add it to general releases, since developers were ultimately the ones who need to make logins more secure on the sites they build.
While the warnings are now displayed to all users of Firefox and Chrome, they are still intended to encourage web designers to update their sites to ensure that sensitive information is always requested over HTTPS. Although the warnings are only shown in a limited set of circumstances, Chrome's warnings represent a step towards Google's long-term plan to flag all HTTP sites as "not secure".
The new browser behaviour could encourage faster migration to HTTPS by naming and shaming offending websites to their own users. The warnings shown in Firefox 51 and Chrome 56 are rather subtle and could easily be overlooked or not understood by regular users, but the inline warnings now shown in Firefox 52 are easier to interpret and much harder to miss. Chrome 57 is expected to have a similar feature when it is released on March 14. Many websites are therefore expected to react to their "not secure" status in the coming days and weeks.
How many sites are now "not secure"?
Netcraft's Active Sites dataset contains millions of examples where websites serve password fields over unencrypted HTTP connections. All of these sites will be flagged as "not secure" in the latest stable versions of Firefox and Chrome.
Prior to the release of Firefox 51 and Chrome 56, the affected sites would not have caused any warnings to be shown in the URL bar, giving the impression that there were no problems. In contrast, an HTTPS website that uses an expired SSL certificate would display prominent, unmissable warnings, regardless of whether it serves any password fields – even though the connection would arguably be more secure than an unencrypted HTTP connection.
A wide variety of sites are affected by the new behaviour of Chrome and Firefox, including some of the most popular news websites. This is arguably a good thing, as being affected will encourage them to adopt better security measures.
Fox News visitors (foxnews.com) currently receive the warning when logging in. Although Fox News credentials are ordinarily submitted to a secure server at https://signin.foxnews.com, the login form itself is served over an unencrypted HTTP connection, and so there is an opportunity for a man-in-the-middle attacker to steal any credentials entered on this page:
Some of the news websites that make use of Gigya for customer identity management are also flagged as not secure. This includes the Irish Examiner, the Independent, and the Express. Again, although Gigya's service only accepts credentials via a secure login URL similar to https://accounts.us1.gigya.com/accounts.login, the pages that send these credentials are not secure.
Chinese search engine Baidu is one of the most frequently visited HTTP sites that is now marked as "not secure" by Chrome and Firefox. Unlike Google, its homepage does not use HTTPS by default, and so a significant number of users are likely to see http://www.baidu.com/ flagged as being "not secure" when they try to log in.
Not all Baidu users will be vulnerable, however, as any visit to its HTTPS site at https://www.baidu.com/ will cause Baidu's HTTP Strict Transport Security policy to kick in. This will force the user's browser to use HTTPS for all subsequent visits for at least the next two days, thus ensuring that the login form will be served over a secure connection.
Unfortunately, Baidu's 2-day HSTS policy can only take effect after the user has visited the HTTPS site, rendering all new and infrequent users vulnerable to MITM attacks. This weakness could be resolved by adding baidu.com to Chromium's HSTS preloaded list, which would cause most modern browsers to always use HTTPS, even if the site has never been visited before.
Other high-profile sites that are currently "not secure"
The FIFA website at http://www.fifa.com is instantly flagged as being insecure, even before the login form is made visible to the user. Although this login form submits to a secure URL at https://secure.fifa.com/theclub/login.htmx, the form itself is of course vulnerable to man-in-the-middle attackers who could divert the user's credentials elsewhere.
Tagged and hi5 are popular social networking sites that are flagged as insecure despite having login forms that are served over secure HTTPS connections. This is because each secure login form is displayed inside an iframe that is displayed by an HTTP site. If the HTTP site were to be man-in-the-middled, the attacker could instead cause this frame to show a spoof login form instead of the intended secure content.
A few other high profile sites also flagged as "not secure" include those operated by the global lodging company Marriott, Scandinavia's largest airliner SAS, parcel delivery companies Parcelforce and DPD, online gaming sites Miniclip and Bigpoint, and some sites that use Salesforce (e.g. avid.force.com).
What do the affected websites need to do?
Chrome and Firefox will only display the new warnings when they encounter password fields that are served over unencrypted HTTP connections, so the fix is quite straightforward: Make sure these pages are served over HTTPS (using a valid SSL certificate, of course).
While this course of action will make the warning messages disappear, it will not on its own eliminate all types of man-in-the-middle attacks. For instance, most HTTPS sites are vulnerable to trivial connection hijacking attacks that can be exploited whenever a user inadvertently tries to access the secure site over HTTP. This "SSL stripping" vulnerability can easily be resolved by implementing an appropriate HTTP Strict Transport Security (HSTS) policy, yet only a small percentage of HTTPS sites actually do this.
Further protection can be sought by using HSTS preloading, which ensures that a site's HSTS policy is distributed to supported browsers before the user's first visit. Going a step further, HTTP Public Key Pinning can prevent fraudsters using mis-issued SSL certificates to carry out man-in-the-middle attacks, but incredibly few sites have dared to use this feature – partly because it can backfire spectacularly if website administrators get it wrong.
Users of Chrome 56 and Firefox 51 also might not notice the subtle "not secure" warnings displayed by these versions, and so an attacker who has man-in-the-middled a login form may still be able to carry out a viable attack as long as the login form continues to be served over HTTP.
However, Firefox 52 (and soon Chrome 57) will make the warnings much easier to notice, and this is likely to drive the security of the web in the right direction. Directly naming and shaming insecure websites to their own users is potentially one of most powerful ways of encouraging companies to make better use of HTTPS, which will ultimately make it harder for hackers to carry out man-in-the-middle attacks.
Fraudsters are still exploiting eBay's persistent cross-site scripting vulnerabilities to steal account credentials, years after a series of similar attacks took place. Worse still, many of the listings that exploited these vulnerabilities remained on eBay's website for more than a month before they were eventually removed.
As can be seen below, the cybercriminals even used listings of dental tools to extract credentials from their victims, bypassing eBay's toothless listing policies in a similar way to the attacks that took place a few years ago.
But the malicious code in this listing executes as soon as the page has loaded, which causes it to be displayed for only a split second. In the blink of an eye — and without any further interaction — the victim is redirected to a spoofed login form:
The externally-hosted script redirected victims to a data URI, which is another trick sometimes used by cybercriminals: The Base64-encoded address makes it difficult for victims to report such attacks, as by this point, the page is ostensibly not hosted anywhere.
When the victim submits his username and password, the credentials are transmitted to a script at daviddouglas.co.uk/session.php?/ws/eBayISAPI.dll?co_partnerId=2&siteid=3&UsingSSL=1 (which has also since been taken down). This PHP script receives the victim's credentials and then immediately redirects the victim to a page on the genuine eBay website, giving the impression that the listing that the victim originally attempted to visit is no longer available:
The victim may not realise it — as his browser never showed the address of any externally hosted websites — but at this point, his credentials will have already been stolen by the fraudster's PHP script.
These latest listings were reported to Netcraft by "Jaco Bustero". Although this pseudonym is very similar to "Buster Jack" — who discovered a series of related scams in 2014 — they are, in fact, different people in the UK. Both hide behind pseudonyms because of valid concerns about their own safety – for instance, Buster Jack's efforts to combat vehicle fraud have earned him several death threats from the perpetrators of these crimes.
In some cases, it could be that eBay is simply unaware of the fraud it is facilitating. When one customer phoned eBay Trust & Safety to report these redirect attacks, the eBay handler was unable to see the redirection due to security settings on their internal systems. Consequently, reporting such vulnerabilities to eBay can prove frustrating, as well as fruitless: When Jaco posted a similar warning to the eBay Motors community forum, he claims his message was quickly deleted.
Netcraft is in the news today after the Chancellor of the Exchequer announced plans to work with us to develop better automatic defences to reduce the impact of cyber attacks affecting the UK.
There is coverage in the Independent which says "Mr Hammond will set out plans to work in partnership with firms such as internet security company Netcraft to develop better automatic defences", ARS Technica notes "Number 11 said it would work closely with industry partners such as Bath-based Netcraft" while TechCrunch observes "One company the government is highlighting here is Netcraft for “automated defence techniques to reduce the impact of cyber-attacks.”"
Her Majesty's Government's own announcement outlines Netcraft's role in the cyber security strategy:
The strategy sets out how government will strengthen its own defences as well as making sure industry takes the right steps to protect Critical National Infrastructure in sectors like energy and transport. We will do this through working in partnership with industry - including companies such as the innovative SME Netcraft - to use automated defence techniques to reduce the impact of cyber-attacks [...]. Previously a website serving web-inject malware would stay active for over a month- now it is less than two days. UK-based phishing sites would remain active for a day- now it is less than an hour. And phishing sites impersonating government’s own departments would have stayed active for two days - now it is less than 5 hours.
Posted in Security
Bangladesh is one of the world's largest producers of fish; but lately, its government has also become an inadvertent exporter of phish.
Over the past week, several phishing sites have popped up on Bangladeshi government websites, under the .gov.bd second-level domain. These fraudulent sites have been used in phishing attacks against customers of Wells Fargo bank, Google, AOL, and other email providers.
Domain name registrations under .gov.bd are restricted to government-related entities in Bangladesh, although it is unlikely that the government is directly responsible for these attacks. As with most phishing sites, the fraudulent content has probably been placed on these government sites by remote hackers; nonetheless, this would make the Bangladesh government at least responsible for poor security.
The vast majority of websites under .gov.bd are hosted within Bangladesh, but the apparently-compromised server involved in these attacks is one of a few that are hosted in the United Kingdom, on a static IP address used by the hosting company Nibs Solutions. No Bangladeshi servers are currently serving phishing sites from .gov.bd domains.
After more than a week since this spate of phishing attacks started appearing on UK-hosted .gov.bd sites, none of the fraudulent content has been removed. The presence of multiple live phishing sites on the affected server, and the fact that the previous compromises have not yet been cleaned up, suggests that whatever security vulnerabilities might have affected the server are yet to be resolved.
Bangladesh has a relatively small presence on the web, with just over 30,000 websites making use of the entire .bd country code top-level domain. However, the ratio of phishing incidents to sites is quite high at roughly 1 in 100.
Users of the Netcraft anti-phishing extension are already protected from these attacks, including the examples shown above, even though the fraudulent content has not yet been removed by the sites' administrators.
Fraudsters are abusing Facebook's app platform to carry out some remarkably convincing phishing attacks against Facebook users.
Masquerading as a Facebook Page Verification form, this phishing attack leverages Facebook's own trusted TLS certificate that is valid for all facebook.com subdomains. This makes the page appear legitimate, even to many seasoned internet users; however, the verification form is actually served via an iframe from an external site hosted by HostGator. The external website also uses HTTPS to serve the fraudulent content, so no warnings are displayed by the browser.
This phishing attack works regardless of whether the victim is already logged in, so there is little chance of a victim being suspicious of being asked to log in twice in immediate succession.
To win over anyone who remains slightly suspicious, the phishing site always pretends that the first set of submitted credentials were incorrect. A suspicious user might deliberately submit an incorrect username and password in order to test whether the form is legitimate, and the following error message could make them believe that the credentials really are being checked by Facebook.
Those who were slightly suspicious might then believe it is safe to enter their real username and password. Anyone else who had already entered the correct credentials would probably just think they had made a mistake and try again. After the second attempt, the phishing site will act as if the correct credentials had been submitted:
The final response indicates that the victim will have to wait up to 24 hours for their submission to be approved. Without instant access to the content they were trying to view, the victim will probably carry on doing something else until they receive the promised email notification.
But of course, this email will never arrive. By this point, the fraudster already has the victim's credentials and is just using this tactic to buy himself some time. He can either use the stolen Facebook credentials himself, or sell them to others who might monetize them by posting spam or trying to trick victims' friends into helping them out of trouble by transferring money. If more victims are required, then the compromised accounts could also be used to propagate the attack to thousands of other Facebook users.
However, Facebook does provide some features that could make these attacks harder to pull off. For example, if login alerts are enabled, the victim will be notified that their account has been logged into from a different location – this might at least make the victim aware that something untoward is going on. Although not enabled by default, users can completely thwart this particular attack by activating Facebook's login approvals feature, which requires a security code to be entered when logging in from unknown browsers. Only the victim will know this code, and so the fraudster will not be able to log in.
HTTP Public Key Pinning (HPKP) is a security feature that can prevent fraudulently issued TLS certificates from being used to impersonate existing secure websites.
Our previous article detailed how this technology works, and looked at some of the sites that have dared to use this powerful but risky feature. Notably, very few sites are making use of HPKP: Only 0.09% of the certificates in Netcraft's March 2016 SSL Survey are served with HPKP headers, which equates to fewer than 4,100 certificates in total.
But more surprisingly, around a third of these sites are using the HPKP header incorrectly, which effectively disables HPKP. Consequently, the total number of certificates that are actually using HPKP is effectively less than 3,000.
HPKP is the best way of protecting a site from being impersonated by mis-issued certificates, but it is easy for this protection to backfire with severe consequences. Fortunately, most misconfigurations simply mean that a site's HPKP policy will be ignored by browsers. The site's administrators might not realise it, but this situation is essentially the same as not using HPKP at all.
How can it go wrong?
Our previous article demonstrated a few high-profile websites that were using HPKP to varying degrees. However, plenty of other sites have bungled HPKP to the extent that it simply does not work.
Every HPKP policy must specify a
max-age directive, which suggests how long
a browser should regard the website as a "Known Pinned Host". The most commonly used
max-age value is 5184000 seconds (60 days).
Nearly 1,200 servers use this value, while around 900 use 2592000 seconds (30 days).
But around 70 sites feature pointlessly short
max-age values, such as 5 or 10 seconds. These durations are far too short to be effective, as a victim's browser would rapidly forget about these known pinned hosts.
Additionally, a few sites explicitly specify a
max-age of zero along with their public key pins. These sites are therefore not protected by HPKP, and are in some cases needlessly sending this header to every client request. It is possible that they are desperately trying to remove a previously set HPKP policy, but this approach obviously cannot be relied upon to remove cached pins from browsers that do not visit the site in the meantime. These sites would therefore have to continue using a certificate chain that conforms to their previous HPKP policy, or run the risk of locking out a few stragglers.
One of the sites that sets a zero
max-age is https://vodsmarket.com. Even if this
max-age were to be increased, HPKP would still not be enabled because there is only one pinned public key:
Public-Key-Pins: pin-sha256="sbKjNAOqGTDfcyW1mBsy9IOtS2XS4AE+RJsm+LcR+mU="; max-age=0;
Another example can be seen on https://wondershift.biz, which pins two certificates' public keys. Again, even if the
max-age were to be increased, this policy would still not take effect because there are no backup pins specified (both of the pinned keys appear in the site's certificate chain):
Public-Key-Pins: pin-sha256="L7mpy8M0VvQcWm7Yyx1LFK/+Ao280UZkz5U38Qk5G5g="; pin-sha256="EohwrK1N7rr3bRQphPj4j2cel+B2d0NNbM9PWHNDXpM="; includeSubDomains; max-age=0; report-uri="https://yahvehyireh.com/incoming/hpkp/index.php"
Wrong pin directives
Each pinned public key must be specified via a separate
pin-sha256 directive, and each value must be a SHA256 hash;
but more than 1% of servers that try to use HPKP fail to specify these pins correctly.
For example, the Department of Technology at Aichi University of Education exhibits the following header on https://www.auetech.aichi-edu.ac.jp:
Public-Key-Pins: YEnyhAxjrMAeVokI+23XQv1lzV3IBb3zs+BA2EUeLFI="; max-age=5184000; includeSubDomains
This header appears to include a single public key hash, but it omits the pin-sha256 directive entirely. No browser will make any sense of this attempted policy.
In another example, the Fast Forward Imaging Customer Interface at https://endor.ffwimaging.com does something very peculiar. It uses a pin-sha512 directive, which is not supported by the RFC – but in any case, the value it is set to is clearly not a SHA512 hash:
Public-Key-Pins: pin-sha512="base64+info1="; max-age=31536000; includeSubDomains
Some sites try to use SHA1 public key hashes, which are also unsupported:
Public-Key-Pins: pin-sha1='ewWxG0o6PsfOgu9uOCmZ0znd8h4='; max-age=2592000; includeSubdomains
This one uses pin-sha instead of pin-sha256:
Public-Key-Pins: pin-sha="xZ4wUjthUJ0YMBsdGg/bXHUjpEec5s+tHDNnNtdkwq8="; max-age=5184000; includeSubDomains
And this one refers to the algorithm "SHA245", which does not exist:
Public-Key-Pins: pin-sha245="pyCA+ftfVu/P+92tEhZWnVJ4BGO78XWwNhyynshV9C4="; max-age=31536000; includeSubDomains
The above example was most likely a typo, as is the following example, which specifies a ping-sha256 value:
Public-Key-Pins: ping-sha256="5C8kvU039KouVrl52D0eZSGf4Onjo4Khs8tmyTlV3nU="; max-age=2592000; includeSubDomains
These are careless mistakes, but it is notable that these types of mistake alone account for more than 1% of all certificates that set the Public-Key-Pins header. The net effect of these mistakes is that HPKP is not enabled on these sites.
Only one pinned public key
As we emphasised in our previous article, it is essential that a secure site should specify at least two public key pins when deploying HPKP. At least one of these should be a backup pin, so that the website can recover from losing control of its deployed certificate. If the website owner still possesses the private key for one of the backup certificates, the site can revert to using one of the other pinned public keys without any browsers refusing to connect.
But 25% of servers that use HPKP specify only one public key pin. This means that HPKP will not be enabled on the sites that use these certificates.
To prevent sites from inadvertently locking out all of their visitors, and to force the use of backup pins, browsers should only cache a site's pinned public keys if the Public-Key-Pins header contains two or more hashes. At least one of these must correspond to a certificate that is in the site's certificate chain, and at least one must be a backup pin (if a hash cannot be found in the certificate chain, then the browser will assume it is a backup pin without verifying its existence).
https://xcloud.zone is an example of a site that only sets one public key pin:
Public-Key-Pins: pin-sha256="DKvbzsurIZ5t5PvMaiEGfGF8dD2MA7aTUH9dbVtTN28="; max-age=2592000; includeSubDomains
This single pin corresponds to the subscriber certificate issued to xcloud.zone. Despite the 30-day max-age value, this lonely public key hash will never be cached by a browser. Consequently, HPKP is not enabled on this site, and the header might as well be missing entirely.
No pins at all
As well as the 1,000+ servers that only have one pinned public key, some HPKP headers neglect to specify any pins at all, and a few try to set values that are not actually hashes (which has the same effect as not setting any pins at all). For example, the Hide My Ass! forum at https://forum.hidemyass.com sets the following:
Public-Key-Pins: pin-sha256="<Subject Public Key Information (SPKI)>"; max-age=2592000; includeSubDomains
The ProPublica SecureDrop site at https://securedrop.propublica.org also made a subtle mistake last month by forgetting to enclose its pinned public key hashes in double-quotes:
Public-Key-Pins: max-age=86400; pin-sha256=rhdxr9/utGWqudj8bNbG3sEcyMYn5wspiI5mZWkHE8A= pin-sha256=lT09gPUeQfbYrlxRtpsHrjDblj9Rpz+u7ajfCrg4qDM=
The HPKP RFC mandates that the Base64-encoded public key hashes must be quoted strings, so the above policy would not have worked. ProPublica has since fixed this problem, as well as adding a third pin to the header.
If companies that specialise in online privacy and secure anonymous filesharing are making these kinds of mistake on their own websites, it's not surprising that so many other websites are also getting it wrong.
At least two pins, but no backup pins
A valid HPKP policy must specify at least two pins, and at least one of these must be a backup pin. A browser will assume that a pin corresponds to a backup certificate if none of the certificates in the site's certificate chain correspond to that pin.
The Samba mailing lists site at https://lists.samba.org specifies two pinned public key hashes, but both of these appear in its certificate chain. Consequently, a browser will not apply this policy because there is no evidence of a backup pin. HPKP is effectively disabled on this site.
Incidentally, the Let's Encrypt Authority X1 cross-signed intermediate certificate has the most commonly pinned public key in our survey. More than 9% feature this in their set of pins, although it should never be pinned exclusively because Let's Encrypt is not guaranteed to always use their X1 certificate. Topically, just a few days ago, Let's Encrypt started to issue all certificates via its new Let's Encrypt Authority X3 intermediate certificate in order to be compatible with older Windows XP clients; but fortunately, the new X3 certificate uses the same keys as the X1 certificate, and so any site that had pinned the public key of the X1 certificate will continue to be accessible when it renews its subscriber certificate, without having to change its current HPKP policy.
The next most common pin belongs to the COMODO RSA Domain Validation Secure Server CA certificate. This pin is used by more than 6% of servers in our survey, all of which – despite the use of HPKP – could be vulnerable to man-in-the-middle attacks if Comodo were to be hacked again.
Pinning only the public keys of subscriber certificates would offer the best security against these kinds of attack, but it is fairly common to also pin the keys of root and intermediate certificates to reduce the risk of "bricking" a website in the event of a key loss. This approach is very common among Let's Encrypt customers, as the default
letsencrypt client software generates a new key pair each time a certificate is renewed. If the public key of the subscriber certificate were to be pinned, the pinning would no longer be valid when it is renewed.
Setting HPKP policies over HTTP
Some sites set HPKP headers over unencrypted HTTP connections, which is also ineffectual. For example, the Internet Storm Center website at www.dshield.org sets the following header on its HTTP site:
Public-Key-Pins: pin-sha256="oBPvhtvElQwtqQAFCzmHX7iaOgvmPfYDRPEMP5zVMBQ="; pin-sha256="Ofki57ad70COg0ke3x80cbJ62Tt3c/f3skTimJdpnTw="; max-age=2592000; report-uri="https://isc.sans.org/badkey.html"
The Public Key Pinning Extension for HTTP RFC states that browsers must ignore HPKP headers that are received over non-secure transport, and so the above header has no effect other than to consume additional bandwidth.
2.2.2. HTTP Request Type Pinned Hosts SHOULD NOT include the PKP header field in HTTP responses conveyed over non-secure transport. UAs MUST ignore any PKP header received in an HTTP response conveyed over non-secure transport.
One very good reason for ignoring HPKP policies that are set over unencrypted connections is to prevent "hostile pinning" by man-in-the-middle attackers. If an attacker were to inject a set of pins that the site owner does not control—and if the browser were to blindly cache these values—he would be able to create a junk policy on behalf of that website. This would prevent clients from accessing the site for a long period, without the attacker having to maintain his position as a man-in-the-middle.
If a visitor instead browses to https://www.dshield.org (using HTTPS), an HSTS policy is applied which forces future requests to use HTTPS. The HTTPS site also sets an HPKP header which is then accepted and cached by compatible browsers. However, as the HTTP site does not automatically redirect to the HTTPS site, it is likely that many visitors will never benefit from these HSTS or HPKP polices, even though they are correctly implemented on the HTTPS site.
In another bizarre example, HPKP headers are set by the HTTP site at http://www.msvmgroup.com, even though there is no corresponding HTTPS website (it does accept connections on port 443, but does not present a subscriber certificate that is valid for this hostname).
Not quite got round to it yet...
A few sites that use the Public-Key-Pins header have not quite got around to implementing it yet, such as https://justamagic.ru, which sets the following value:
Using HPKP headers to broadcast skepticism
One security company's website – https://websec-test.com – uses the Public-Key-Pins header to express its own skepticisms over the usefulness of HPKP:
Public-Key-Pins: This is like the most useless header I have ever seen. Preventing MITM, c'mon, whoever can't trust his own network shouldn't enter sensitive data anywhere.
Violation reports that will never be received
The Public-Key-Pins header supports an optional
report-uri directive. In the event of a pin validation failure, the user's browser should send a report to this address, in addition to blocking access to the site.
These reports are obviously valuable, as they will usually be the first
indication that something is wrong.
However, if the
report-uri address uses HTTPS, and is also known pinned host, the browser must also carry out pinning checks on this address when the report is sent. This makes it foolish to specify a
report-uri that uses the same hostname as the site that is using HPKP.
An example of this configuration blunder can be seen on https://yahvehyireh.com, which sets the following Public-Key-Pins header:
Public-Key-Pins: pin-sha256="y+PfuAS+Dx0OspfM9POCW/HRIqMqsa83jeXaOECu1Ns="; pin-sha256="klO23nT2ehFDXCfx3eHTDRESMz3asj1muO+4aIdjiuY="; pin-sha256="EohwrK1N7rr3bRQphPj4j2cel+B2d0NNbM9PWHNDXpM="; includeSubDomains; max-age=0; report-uri="https://yahvehyireh.com/incoming/hpkp/index.php"
This header instructs the browser to send pinning validation failure reports to https://yahvehyireh.com/incoming/hpkp/index.php. However, if there were to be a pinning validation failure on yahvehyireh.com, then the browser would be unable to send any reports because the
report-uri itself would also fail the pinning checks
by virtue of using the same hostname.
Incidentally, Chrome 46 introduced support for a newer header,
Public-Key-Pins-Report-Only, which instructs the browser to perform identical
pinning checks to those specified by the
Public-Key-Pins header, but it will
never block a request when no pinned keys are encountered; instead, the
browser will send a report to a URL specified by a
report-uri parameter, and the user will be allowed to continue browsing the site. This mechanism would make it safe for site administrators to test the deployment of HPKP on their sites, without inadvertently introducing a denial of service.
The proportion of secure servers that use HPKP headers is woefully low at only 0.09%, but to make matters worse, many of these few HPKP policies have been implemented incorrectly and do not work as intended.
Without delving into developer settings, browsers offer no visible indications that a site has an invalid HPKP policy, and so it is likely that many website administrators have no idea that their attempts at implementing HPKP have failed. Around a third of the sites that attempt to set an HPKP policy have got it wrong, and consequently behave as if there was no HPKP policy at all. Every response from these servers will include the unnecessary overhead of a header containing a policy that will ultimately be ignored by all browsers.
But there is still hope for the masses: A more viable alternative to HPKP might arise from an Internet-Draft entitled TLS Server Identity Pinning with Tickets. It proposes to extend TLS with opaque tickets, similar to those being used for TLS session resumption, as a way to pin a server's identity. This feature would allow a client to ensure that it is connecting to the right server, even in the presence of a fraudulently issued certificate, but has a significant advantage over HPKP in that no manual management actions would be required. If this draft comes to fruition, and is subsequently implemented by browsers and servers, this ticket-based approach to pinning could potentially see a greater uptake than HPKP has.
Netcraft offers a range of services that can be used to detect and defeat large-scale pharming attacks, and security testing services that identify man-in-the-middle vulnerabilities in web application and mobile apps. Contact firstname.lastname@example.org for more information.
Your link here? Advertising on the Netcraft Blog