This page is "secure" which means that it was sent to you using HTTPS, which, in turn, means that it was encrypted in-flight between my web server and your computer. Fine. But what does that say about the data someone enters on this page?

Nothing.

The fact that a web page was downloaded to you securely (HTTPS) implies nothing about how data entered on that page is uploaded. Don't believe me? I don't blame you. But, it's true. And yes, this means you have been lied to for years about secure web pages/sites. Many many years. The forms below illustrate my point.

The HTTPS Submit button below works as expected, whatever data you type is uploaded using HTTPS and you end up at a secure web page on this site. Boring.

However, the HTTP submit button below uploads the data you enter to a non-existing page on my JavaTester.org website. You get a 404 error because the web page does not exist. That is irrelevant to the issue at hand. YOU SHOULD GET AN ERROR (or warning) THAT DATA IS BEING SUBMITTED INSECURELY VIA HTTP. Most browsers (test results are below) fail to warn the user. (I would have sent the data to a valid HTTP web page, but I don't have one. All my websites use nothing but HTTPS.)

Here is the underlying HTML for these two forms. In the first one, the FORM ACTION specifies HTTPS, in the second one it uses HTTP.

I find this quite ironic. When it comes to data being sent from a web server computer to you, the browsers are quite strict, but in the other direction, the direction where passwords travel ... not so much.

To illustrate the strict security of incoming/downloaded data, realize that although a web page may appear to be a single thing, under the covers it is composed of many individual components. The most obvious components are the images. Each image is fetched individually. For a web page to be considered "secure" by a web browser, all the images need to have been retrieved using HTTPS. If one of them was, instead, included using HTTP, then the page is considered Mixed Mode (or mixed content) and many browsers will issue a warning.

I created a sample web page that does exactly this (see mixedmode.php) so you can see the warnings, if any, from your web browser. There are warnings about insecurely retrieving images, but none about insecurely transmitting a password. Go figure.

Good Web Browsers

Windows 10: Firefox version 73 (current as of Feb. 2020) warns: "The information you have entered on this page will be sent over an insecure connection and could be read by a third party. Are you sure you want to send this information?"

Firefox 73 on Windows 10

Android 10: Firefox (version 68.5.0) and Firefox Focus (version 8.0.26) warn with the same text, but different colors. The warning is exactly the same as Firefox on Windows.

Firefox and Firefox Focus on Android 10

iOS 13.3.1: Safari warns "This form is not secure. Are you sure you want to submit it?" This was tested in February 2020 with the then-current version, but I could not figure out, specifically, which version of Safari it was.

Safari on iOS 13

I am told by a trustworthy source that Safari on macOS does warn about this. I don't have exact details on versions of Safari or macOS.

Bad Web Browsers

If the insecure submission is allowed, you will see this error

The following web browsers fail to warn about the insecure data transmission and instead go directly to the non-existing page. They result in the Page Not Found error shown above.

1. Windows 10: Chrome version 80 (tested Feb. 2020) through 87 (tested Dec. 2020)
2. Windows 10: Brave version 1.3.118 (current as of Feb. 2020)
3. Windows 10: Edge version 42.17134.1098.0 (the legacy version of the browser)
4. Windows 10: Edge version 80.0.361.57 (new version based on Chromium)
5. iOS 13.3: Firefox version 22.0 (current as of Feb 2020)
6. iOS 13.3: Brave version 1.14.3 (current as of Feb 2020)
7. iOS 13.3: DuckDuckGo version 7.38.0 (current as of Feb 2020)
8. ChromeOS: Chrome version 79.0.3945.119 (current as of Feb 2020)
9. Android 10: Chrome version 80.0.3987 (current as of Feb 2020)
10. Android 10: Brave version 1.5.6 (current as of Feb 2020)
11. Android 10: DuckDuckGo version 5.43.0 (current as of Feb 2020)

Google has struggled like heck to close this security flaw on desktop OSs.

• In this August 2020 blog posting, Protecting Google Chrome users from insecure forms, Google said that Chrome would start warning users about insecurely submitting data on an HTTPS page in Chrome version 85. They refer to this issue as "mixed forms". Quoting: "... Chrome will warn users when they try to complete forms on secure (HTTPS) pages that are submitted insecurely. These 'mixed forms' (forms on HTTPS sites that do not submit on HTTPS) are a risk to users' security and privacy. Information submitted on these forms can be visible to eavesdroppers, allowing malicious parties to read or change sensitive form data. "
• At some point, this was pushed back to Chrome version 86.
• In early October 2020, this was pushed back to Chrome version 87.
• November 17, 2020: Chrome Enterprise release notes for Chrome 87. This also says the fix will be in Chrome 87. It was not. Quoting: "Web forms that load using HTTPS but submit their content using HTTP (unsecured) pose potential risk to user privacy. Chrome 85 shows a warning on such forms, letting the user know that the form is insecure. Chrome 87 shows an interstitial warning when the form is submitted, which stops any data transmission ... "
• December 29, 2020: On his Security Now podcast, Steve Gibson discussed how this was just added to Chrome, but immediately, Google ran into a design flaw in their implementation.
• December 30, 2020: I tested this with Chrome version 87.0.4280.88 on Windows 10 and it still submitted the insecure HTTP data without warning.
• Here is a screen shot from Google of the warning they are planning on adding to Chrome.

Address Bar to the rescue?

To be fair, some web browsers are not ALL bad. Take, for example, Chrome 80 on Windows. While it does not issue an obvious in-your-face warning, it does detect the possible insecure data transmission and it makes a small change to the address bar. Below we see three different indicators Chrome uses.

On the top, it is displaying the fully secure page, my blog about hovering the mouse over a link. Don't you miss green for indicating a good state? On the bottom it is viewing my Mixed Mode tester page which it detects as obviously not secure. This page is in the middle and I am pretty sure that no one will have any clue what the "i" in a circle means. If you click it, Chrome says "Your connection to this site is not fully secure." Useless words that convey no information.

Chrome 80 address bar flags on Windows

On Android 9, however, Chrome is not so indicating. As the screen shots below indicate, both the Mixed Mode page and this page display exactly the same in the address bar.

Chrome address bars in Android 9

And, anyone who uses multiple browsers and/or multiple operating systems will never be able to track the meaning of the assorted icons used by different browsers.

History

I first wrote about this back in January 2006 How Secure Is That Web Page In The Window?. Back then, Firefox version 3 had an option about this, you could be warned, or not, about submitting information that was not encrypted. Firefox version 4 made it harder to control this. Interestingly, the warning from Firefox back then is exactly the same warning that it issues today.

That blog was prompted by an episode of the Security Now podcast with Steve Gibson from late in 2005. Interestingly, even after that podcast, Gibson's own personal website (grc.com) suffered from this problem. The site was all HTTPS but, on at least one page, it used HTTP to submit data.

Leo Notenboom also wrote about this, back in July of 2008: How Can an Https Website Still Not Be Secure?. He revised the article on March 18, 2020.

Internet Explorer, now part of history, gets mixed reviews. In February 2020, I tested IE 11 running on Windows 7.

The good news is that IE issues a warning (shown below) when HTTP is used to send data from an HTTPS page.

IE 11 warns about sending insecure data

Bad news awaits however. If you click the More Info button, you end up with the following Question and Answer which is full of lies.

IE 11 lies, lies and lies again

Updated Oct 14, 2020. The insecure data submission now goes to my old JavaTester.org site. In early 2020, I gave up my FlashTester.org site which was used originally. Also added that Chrome version 87 is supposed to finally warn about this.