Interesting Part |
Bad News |
Internet Explorer | Opera | Steve Gibson
This page is in transition. It originated with Firefox version 1 and IE version 6 and I need to update it to reflect Firefox 3 and IE7 and Opera. June 24, 2008.
This page addresses the question: What does it really, actually, truly and technically mean that a web page is secure?
You request web pages using a bunch of rules that computer nerds called HTTP. The "P" at the end stands for Protocol, another term for a bunch of rules. No doubt, you have seen many references to "HTTP" such as in the web page address for Yahoo: http://www.yahoo.com. You may forget that it exists, because it is the default set of rules for web pages and can thus be omitted when requesting web pages. That is, typing just "www.yahoo.com" into a web browser (Internet Explorer, Firefox, etc.) is good enough, because the HTTP is assumed (the colon and two slashes are simply separators). Not that it matters, but the HTT part is short for Hypertext Transfer.
In the original design of the World Wide Web, web pages came to you. Period. All web pages were read-only. That is, you could not enter anything into a web page and send it back to a web site. The only thing you could send out from your computer were requests for new web pages.
Of course, this was later expanded upon so that you can enter data into web pages. Technically speaking, you enter data into "forms" in web pages, a term that you don't normally need to know, but it will come up later in this discussion.
As web pages travel to you from web sites they bounce around the Internet and it's possible for someone to intercept it and read it along the way. You would have no clue that this happened, but then again, you wouldn't care as there was nothing sensitive (i.e. credit card numbers) in web pages. But now, of course, there can be. If your bank sends you a web page with information about your accounts, you certainly don't want anyone who might intercept that web page along the way to be able to read it. Consider this issue number one.
Secure information also travels in the other direction, from your computer to a web site. If, in the process of buying a book from Amazon.com, you enter your credit card number into an Amazon web page, you only want Amazon to see it. Consider this issue number two.
A secure version of the HTTP protocol was eventually introduced that added encryption. The new protocol is HTTPS; the "S" at the end is for "Secure". HTTPS encrypts data before sending it out over the Internet. If the encrypted web page/data is intercepted while in transit, no big deal.
Below is a sample secure web page from Google's Gmail displayed by Firefox. The HTTPS is what makes it secure (Gmail is simply used as an example, there is no security problem with Gmail). To insure that you know it's a secure web page, Firefox turns the address bar yellow (Internet Explorer does not do this) and adds a lock at the end of the web site address (IE does not do this either). Both IE and Firefox display yellow locks in the bottom right corner of the screen to indicate the web page is secure.
Many people already know the above introductory material. The interesting issue is:
What does it really, actually, truly and technically mean that a web page, such as the Gmail one above, is secure?
The standard answer is that the Gmail userid and password are secured by encryption as they travel out of your computer, bounce around the Internet and eventually end up at Google's web site (issue number two).
This is wrong.
What it really, actually, truly and technically means is that the web page was secure/encrypted as it traveled from Google to you (issue number one).
In the case of the initial Gmail web page, the one where you enter the Gmail userid and password, this is mostly irrelevant as it contains no sensitive information on its way from Google to you. It's only relevant when the web page has sensitive information in it, such as a page with bank account details traveling from your bank's web site to you.
Why did Google encrypt the initial Gmail web page as as it traveled from them to me over the Internet if it had nothing sensitive in it?
For the most part, to make you feel warm and fuzzy (more later).
Again, not to pick on Google, many web sites do this; in fact, it's probably the rule rather than the exception. The web page where you sign in to eBay, for example, is also secure (that is, it was sent to you using HTTPS rather than HTTP).
The important issue is whether your Google or eBay userid and password are secure/encrypted when they leave your computer and travel over the Internet back to Google or eBay. And whether the web page that asks for the userid and password is secure or not has nothing to do with this. Nada. Zilch. Zippo. Zero. Totally irrelevant. Let me repeat,
Just because a web page you are viewing is secure (that is, using HTTPS), DOES NOT mean that the data you enter into it, will be secure (encrypted) when it leaves your computer and makes it way around the Internet.
If you are looking at a secure web page in Firefox, then do Tools -> Page Info. The resulting display, says it all:
It goes without saying that Chase Bank and Amazon.com care about security. When you enter a userid/password on these web sites it is surely encrypted before being sent out from your computer. Yet, the web page asking for your userid/password on these sites is not secure. That is, it's an ordinary HTTP page, not an HTTPS page.
|An example of the reverse is the MediaMax feature at Streamload.com. Entering my userid/password on that page, resulted in this warning from Firefox.|
Yahoo's web based email used to give you a choice of logging in using "Standard Mode" or "Secure mode". Sometime in January 2006, Yahoo removed the choice. All logins to their webmail system are now encrypted, an improvement that they make note of on the login page (the encryption is done using a standard called SSL, which is fine).
To be perfectly accurate, the "warm and fuzzy" remark earlier is not completely true. Although the initial Gmail web page does not have your userid/password in it, it does have one piece of important information that you do want secured: the address (URL) of the web page that will accept, validate and process the userid/password that you enter. Theoretically, if the web page into which you enter a userid/password was sent to you via HTTP, it could have been intercepted and modified along the way. A bad guy could have changed the URL that validates the userid/password to one of his own making.
For example, the Gmail web page that validates your userid/password is "ServiceLoginAuth". If a bad guy intercepted the initial login page, this could be changed to something like http://www.badguy.com/stealuserid.html.
If you are using a public WiFi hotspot, then this is doubly important. You shouldn't
necessarily trust an HTTPS web page with an important userid/password.
So how you can tell whether your data will be encrypted and secure when it leaves your computer?
When looking at a web page, there is no visual clue offered by either IE or Firefox.
To be 100% sure, you have to look at the HTML code that underlies a web page to see which web page is going to process the userid and password you are about to enter and, most importantly, whether the connection to that web page is HTTPS or HTTP.
Not to be too nerdy, below is an excerpt from the Yahoo Mail web page where you enter your Yahoo userid and password. Technically, it is the form definition (there's that word again).
<input type="text" id="username" size="17" >
<input type="password" id="passwd" size="17" >
<input type="submit" value="Sign In">
The important part, the "action" parameter, is shown as bold above. This is what defines the web page that will accept and validate the userid and password and how the data will be sent to this web page. In this case, Yahoo sends your userid/password using HTTPS. Good.
Back when Yahoo Mail offered a choice of signing in using Secure Mode or Standard Mode, both "modes" use the exact same "action" parameter and both send the data out from your computer to Yahoo using the secure HTTPS protocol.
What to do?
The good news: Firefox can be configured to warn you just before submitting unencrypted information.
The bad news: The warnings can get annoying if you often enter non-sensitive information on web pages. For example, you'll be nagged for every Google search. The price of security is always inconvenience. :-(
|From the menu bar, click on Tools -> Options -> Security tab.
This brings up the window shown at the right.
Then click on the "Settings..." button in the "Warning Messages" section. This pops up the window shown below. Turn on the checkbox to be warned when "I submit information that's not encrypted".
From the menu bar, click on Tools -> Options -> Security tab. Then click on the "Settings..." button in the "Warning Messages" section. This pops up the window shown at the right. Turn on the checkbox to be warned when "I submit information that's not encrypted". It's configured the same way in version 2 as in version 3.
(This screen shot was from Firefox 220.127.116.11 but it has not changed as of version 18.104.22.168)
Start Firefox and enter "about:config" into the address bar (without the quotes). Scroll down to "security.warn_submit_insecure". Double click on it to change the value to True.
Update: August 18, 2006: A reader of this page (thanks Bruce) wrote to tell me about a Firefox extension called Formfox that displays the form action in a pop-up, and when you hover over a submit button it turns yellow if the data is submitted securely (with SSL encryption).I haven't tried it.
The warnings issued by Firefox vary based on whether you are viewing a secure HTTPS page or a normal HTTP page.
Below is the warning issued by Firefox 3 when you submit data into a normal HTTP page such as google.com. The text has not changed from version 2.
Below is the warning issued by Firefox 3 when you submit insecure data while viewing a secure HTTPS page.
You can see this warning at grc.com. Select "Shields Up!" from the Services menu, then click on the "Proceed" button. You can also see it at citibank.com. Select to sign on to "Bank Accounts" and then click on "Find Citi Locations" at the top of the page. Enter a zip code (or any 5 digits) and click on the "Find" button.
Internet Explorer 6 also has a warning message (shown at right) about sending un-encrypted data. As with Firefox, the warning is displayed the first time this happens and it has a check box that lets you disable the warning in the future.
If you have checked the box and disabled this warning in IE, then it can be re-enabled with:
Tools -> Internet Options -> Security Tab -> Internet Zone -> Custom Level button -> set "Submit non-encrypted form data" to Prompt.
I haven't yet seen a copy of IE with this option turned on.
Opera 9.5 doesn't seem to have a configuration option regarding a warning about submitting insecure data. However, it doesn't need one as it works well by default. Insecure data submitted into HTTP pages generates no warning, but, insecure data submitted into HTTPS pages generates the warning shown here. This was tested on Windows XP.
Security Now is a Podcast by Steve Gibson and Leo Laporte. On the December 29, 2005 show, they answered some questions from listeners and one of the questions prompted me to create this web page. I felt this was an important point and deserved a longer explanation than the Podcast allowed for.
The listener question was why, at some web sites, do you enter sensitive data into non-secure web pages? To insure that data was submitted securely the listener always put in a bad password just to get a secure page with the error message about the password being bad. Then he submitted the real password into this secure page. Now we know, that the security of the page where you enter a userid and password (or any sensitive information) is irrelevant.
Steve Gibson also mentioned that a secure page lets the user view the digital certificate used to validate the page. Again, this relates to the current page being viewed and has nothing at all to do with transmission of data entered into the page.
I recommend the Security Now Podcast, by the way.
|@defensivecomput||TOP||Home => Submitting Secure Data|
|michael at michaelhorowitz.com||Created: January 2006||Last Updated: July 26, 2008|