iOS 10 Will Support Upgrade-Insecure-Requests
The feature makes it easier for existing sites to transition to HTTPS.
One of the main obstacles in an HTTPS transition is removing any and all mixed content issues. In order for a browser to display the green padlock, which indicates you have a secure connection, every single resource on the page needs to be loaded over HTTPS. This means every image, every script, every object.[1] If just a single resource, even one out of hundreds, is fetched insecurely over HTTP, you have a mixed content issue and will not see a green padlock.
Mixed content issues can vary page to page, so fixing them is quite a headache. Some developers take the time to painstakingly comb through their sites, updating resources from HTTP to HTTPS. Others automatically rewrite every instance, hoping that it does not cause any errors. But there is a better solution.
Upgrade-insecure-requests is an HTTP header[2] specifically designed to fix this problem. When a browser (or other client) encounters this header, it tells them that they should automatically fetch all the resources on that site securely over HTTPS.
One of the key features of Upgrade-insecure-requests is that it does not require changing the source code of individual pages, making it very easy to implement. This can help a site eliminate their mixed content issues with a single change.
Browsers defer to what a website explicitly tells them to do. Because HTTP was widely used until very recently, many sites explicitly included “http://” in their source code, so browsers continue to load content insecurely even if the site uses HTTPS. The more legacy content a site has, the more valuable this feature can be for them because legacy content often contains hardcoded HTTP URLs.
Mike West, an engineer at Google, designed upgrade-insecure-requests. He wanted to make HTTPS migrations easier. West wrote “we should remove this burden from site authors by allowing them to assert to a user agent that they intend a site to load only secure resources.”
However, Upgrade-insecure-requests only works if a user’s browser supports the feature. Therefore, it’s only a useful tool if it’s widely deployed in client side software. Otherwise a significant number of people will continue to experience insecure mixed content connections.
For the most part, most major browsers support Upgrade-insecure-requests, including Firefox and Chrome. Overall, 60% of global users support Upgrade-insecure-requests.
There are a few household-name browsers that do not yet support it, the most popular among those being Safari and iOS browsers. That’s because, until recently, Upgrade-insecure-requests was not supported by Webkit, the browser engine that powers those browsers.
CanIUse.com, a website that tracks support for web technologies across popular web browsers, estimates that 8.16% of global traffic comes from iOS. It’s significantly more popular in the US, where iOS accounts for 18.96% of the browser market. Safari for Mac OS contributes a few more percentage points on top of that (1.6% globally, and 3.77% in the USA).
Webkit added support for upgrade-insecure-requests in June. It then became a part of Safari Technology Preview, a beta version of the browser, in an update later that month.
Now, it’s finally going to reach consumers’ devices. When iOS 10 releases tomorrow, on the 13th, everyone who upgrades will receive a new version of Webkit that will give the power of Upgrade-insecure-requests to every browser.
Safari 10, shipping with Mac OS 10.12 Sierra, will also include support for upgrade-insecure-requests which will release on September 20th.
Microsoft’s browsers, Edge and Internet Explorer, do not have support for upgrade-insecure-requests. It is very unlikely that Internet Explorer will receive support. Edge’s developer website says support is “under consideration,” which means it will hopefully receive support but that may not be anytime soon.
Zack Tollman, Wired.com’s application architect, broke this news last week. He confirmed to us that the iOS 10 beta does indeed support Upgrade-insecure-requests.
[1] But not HTML Anchors (i.e. <a> or <a href>)! Links to other pages do not count as resources because they are not being loaded/fetched on the current page.
[2] More specifically, it’s a Content Security Policy directive
5 Ways to Determine if a Website is Fake, Fraudulent, or a Scam – 2018
in Hashing Out Cyber SecurityHow to Fix ‘ERR_SSL_PROTOCOL_ERROR’ on Google Chrome
in Everything EncryptionRe-Hashed: How to Fix SSL Connection Errors on Android Phones
in Everything EncryptionCloud Security: 5 Serious Emerging Cloud Computing Threats to Avoid
in ssl certificatesThis is what happens when your SSL certificate expires
in Everything EncryptionRe-Hashed: Troubleshoot Firefox’s “Performing TLS Handshake” Message
in Hashing Out Cyber SecurityReport it Right: AMCA got hacked – Not Quest and LabCorp
in Hashing Out Cyber SecurityRe-Hashed: How to clear HSTS settings in Chrome and Firefox
in Everything EncryptionRe-Hashed: The Difference Between SHA-1, SHA-2 and SHA-256 Hash Algorithms
in Everything EncryptionThe Difference Between Root Certificates and Intermediate Certificates
in Everything EncryptionThe difference between Encryption, Hashing and Salting
in Everything EncryptionRe-Hashed: How To Disable Firefox Insecure Password Warnings
in Hashing Out Cyber SecurityCipher Suites: Ciphers, Algorithms and Negotiating Security Settings
in Everything EncryptionThe Ultimate Hacker Movies List for December 2020
in Hashing Out Cyber Security Monthly DigestAnatomy of a Scam: Work from home for Amazon
in Hashing Out Cyber SecurityThe Top 9 Cyber Security Threats That Will Ruin Your Day
in Hashing Out Cyber SecurityHow strong is 256-bit Encryption?
in Everything EncryptionRe-Hashed: How to Trust Manually Installed Root Certificates in iOS 10.3
in Everything EncryptionHow to View SSL Certificate Details in Chrome 56
in Industry LowdownPayPal Phishing Certificates Far More Prevalent Than Previously Thought
in Industry Lowdown