Helping people with computers... one answer at a time.

Surprisingly, it's possible for aspects of an https site to still be nonsecure, if the site is improperly designed. And it's very difficult to tell.

I have heard that going to an "https" web site isn't a guarantee of security, and that some data I enter might still be unencrypted. How can that be? I thought https was encrypted and could not be sniffed?

You're right: https is encrypted, and cannot be sniffed.

However, everything can be foiled by bad web site design. In fact, I'd go so far as to even say easily foiled by bad website design and by the fact that we all tend to turn off one very annoying -but important - error message.

To really understand what can happen we have to understand just a little bit more about how the web works and what happens when you visit a web page.

Requests and Responses

The entire web experience is based on a very simple model: through your web browser you make a "request", and the web site you're visiting returns a "response". Everything is built on this very simple concept.

For example, when you visit a web site like, the following sequence occurs:

  • Your browser looks up the IP address for

  • Your browser then sends a request to port 80 on that IP address for the page "" (empty, or the default page) on "".

  • The web server responds with the HTML text that makes up the page.

"The entire web experience is based on a very simple model: through your web browser you make a "request", and the web site you're visiting returns a "response"."

It's worth noting that this one transaction is only for the base HTML for the page. If that page then references images, additional and separate transactions just like the sequence above are repeated for each such reference as the browser parses and displays the page.

But fundamentally, it's simply that request / response model we talked about.

A secure or https transaction is similar. Let's use this time:

  • Your browser looks up the IP address for

  • Your browser establishes a secure encrypted connection with port 443 on that IP for the site ""

  • Your browser then sends through that encrypted connection a request for the page "" (empty, or the default page)

  • The web server responds through that encrypted connection with the HTML text that makes up the page.

When you enter data on a form, such as your login information, the sequence is still considered a request for a page. The difference is that along with the name of the page you might be asking for additional information will be included with the request; something along the lines of "please give me the page "login.php" for user "leo" and password "password". In a secure connection that would look like this

  • Your browser looks up the IP address for

  • Your browser establishes a secure encrypted connection with port 443 on that IP for the site ""

  • Your browser then sends through that encrypted connection for the page "login.php" and includes the additional information "user:leo" and "password:password".

  • The web server does whatever it needs to do with that additional information and responds through that encrypted connection with the HTML text that makes up the page it wants to show you after logging in.

All seems well and good, and you can see that your login information, as well as the results of your login are transmitted only in encrypted form. Someone sniffing your traffic would see only that you had gone to, but nothing else.

Web Forms

Next, we need to understand a little bit more about how web forms work.

Forms are the common and typical way that web sites ask you for information. For example, this is a form:

Enter some text:

Push this button:

What you can't see in that form is that it includes a reference to a URL: When you click on Submit on that form the following happens:

  • Your browser looks up the IP address for

  • Your browser establishes a connection with port 80 on that IP for the site ""

  • Your browser then sends a request for the page "formdemo.php" along with the additional information "text_field: " followed by whatever you entered, and "submit_button: Submit".

  • The web server builds a web page that simply displays that information and returns the HTML for that page as the response.

Note that that's not a secure transaction. Had I specified in the form that a secure URL like was to be accessed when you hit submit, then the sequence would be more like this:

  • Your browser looks up the IP address for

  • Your browser establishes a secure encrypted connection with port 443 on that IP for the site ""

  • Your browser then sends a request on the encrypted connection for the page "formdemo.php" along with the additional information "text_field: " followed by whatever you entered, and "submit_button: Submit".

  • The web server builds a web page that simply displays that information and returns on the encrypted connection the HTML for that page as the response.

As you can see, it's very similar. It's simply replacing the open unencrypted connection on port 80 with an encrypted secure connection on port 443.

In the unencrypted connection, someone could sniff both the data that you sent my server, and my response. In an encrypted connection, neither would be visible.

The Problem: Bad Web Design

The problem boils down to this: when you hit the submit button above you really don't know whether I've written this web page to use a secure connection or not.

And on top of that there's really no easy way for you to tell.

So, all the explanations above are so that we can understand this example:

  • You visit your bank. You take great care to make sure that the URL you go to begins with "https" so as to ensure an encrypted connection. Let's say you visit "".

  • The request for "" is made securely, and the response comes back securely. That response? The page on which you enter your username and password. Note: so far nothing important has been encrypted. All you got was a login page with no sensitive information. There was a secure request, followed by a secure response. And it has absolutely no bearing on what happens next.

  • You enter your (sensitive) login information and password, and press "Submit".

  • The browser then gets the URL specified in the form - the URL that you can't see - connects to it, sends your login information as the request, and gets the next web page to show you as the response.

Here's the million dollar question: how do you know before you hit Submit that that the request you're about to make is to a secure (https) web page?

The fact that you're on a secure web page means nothing. It's the page that you're about to go to, the page that you're about to request on hitting Submit, that's the page that needs to be secure.

And you might not be able to tell.

The Solution? Caution and Software

You're hopefully already familiar with the fact the most browser will display the URL represented by a link in the status bar if you hover the mouse over the link. For example, if you hover over this link you should see something like this in your browser's status bar:

Browser Status Bar hovering over the link above

"Submit" buttons on web forms are really just another type of "link", if you will. Only until recently, you couldn't easily see where they are about to take you.

Internet Explorer 7 will display the target for most forms if you hover the mouse over the corresponding Submit button. Thus, if you've just entered sensitive information and are about to press "Login", or "Submit" or whatever they choose to call the button, in Internet Explorer 7 you can hover over that button first and make sure that the link it's about to take you to is an https connection.

I know of no similar solution for versions of Internet Explorer prior to version 7.

Firefox users can install the FormFox extension which displays a small tool tip with the destination URL of a form's Submit button.

Sadly, neither of those is really enough.

It gets worse: AJAX and other technologies

So fa,r I've discussed only Forms which are a common, but very specific type of approach to getting information from a user, like you, to a server, like your bank's, when you want to do things like login.

Forms are based on that "request / response" approach I described at the beginning. You make a request, and the response is a new page.

AJAX is an example of a technology that allows requests and responses to happen "behind the scenes" in such a way that you're not actually getting a new page each time. Google mail is a good example: many operations such as archiving your mail or tagging messages may not involve a new page at all - and yet information is being sent back and forth to Google's servers.

Even if you're on a secure page, there's no guarantee that this background request / response transfer is actually happening over a secure connection. It all depends on how the page was authored.

And there really is no way for you to know, unless you're a geek willing to look at and understand the HTML and Javascript that implements those pages.

The Ultimate Answer

The ultimate answer is to enable a warning that I'm almost positive you've already turned off:

IE's Secure Transition Warning

You've probably already checked the "Don't show this again" checkbox, and with good reason. This warning appears every time you switch between secure and nonsecure modes. Even if it's obvious and you know what's about to happen, you get this warning.

The only way to know when it's not obvious and you might not know that it's about to happen is to re-enable it. And then also live with it all the rest of the time.

In IE you can re-enable it by clicking on Tools, Internet Options, Advanced, scroll down in the Setting box and make sure that Warn if changing between secure and nonsecure modes is checked.

In FireFox click Tools, Options, Security and then the Settings button in the Warning Messages section. Make sure that "Show a warning dialog when:" I leave an encrypted page for one that isn't encrypted, and I submit information that's not encrypted are both checked.

A Perhaps More Practical Solution

It really all boils down to websites being properly created. If you are on an https page it's reasonable to expect that the form button you click on to take you to more of your personal information will also be through and to a secure page. And most of the time, it is. Most sites get it right.

But some don't.

Since I hate that annoying warning over and over and over again as much as anyone, here's what I'd be tempted to do: enable the warning for "a while" and see which of the sites I regularly visit have a problem, if any.

And then turn it off.

I'd perhaps remember to turn it back on again before visiting a new site - say when opening or accessing an account with a new bank or other sensitive information site. And perhaps turning it back on when using an open WiFi hotspot, or always using an encrypted VPN if I were very concerned.

These are not the best of solutions, but maybe a little less annoying than others.

Article C3461 - July 30, 2008 « »

Leo Leo A. Notenboom has been playing with computers since he was required to take a programming class in 1976. An 18 year career as a programmer at Microsoft soon followed. After "retiring" in 2001, Leo started Ask Leo! in 2003 as a place for answers to common computer and technical questions. More about Leo.

Not what you needed?

Ken B
July 30, 2008 9:10 AM

I read several months ago, in an article on some of the "worst" spyware out there, that it's possible for spyware to read https information, by installing itself in the browser between the browser and the SSL layer. (Unfortunately, I didn't save a link to the online version.)

Basically, the browser communicates internally with the SSL layer unencrypted. By wedging itself in that layer, the spyware can see everything unencrypted.

Have you heard anything of this?

Spyware and viruses can to ANYTHING - that's why they're to be avoided at all costs.


July 30, 2008 2:35 PM

yes leo, as you kind of alluded to, you can "view" "source" and read the html for where the link is pointed to but you just about have to have atleast some knowledge of html, like us

That's why I mention AJAX, since that is often incomprehensible to even those of us who could read it.


July 30, 2008 5:41 PM

Great explanation! I never fully realized that it was the target page that really mattered, not the current page.

July 30, 2008 8:09 PM

Hi Leo, I am a high school student. I am familiar with html but I was wondering is there a way of creating an online database that can be accessed by anyone using HTLM only. If so what are the necessary steps in doing so. And if not is there a way of creating and online database using other methods eg PHP, XHTML etc. And what would be the necessary steps.

July 31, 2008 3:37 AM

Great article Leo ,you explained http/https method in details with extra information and solutions , really great article for beginners and professionals....thanks Leo.

August 5, 2008 8:43 AM

You've done it again! Not only made the subject clear and understandable, but gave easy to follow instructions that even a senior citizen can follow.
Thanks - I feel safer now - for a while.

August 5, 2008 9:15 AM

Thanks Leo. That was enlightening (as always).
Thanks a lot.

Bob Rutske
August 5, 2008 7:37 PM

Agaian, a great topic, well explained.
Thank you

August 5, 2008 8:24 PM

Since hovering over the 'Login' didn't work, I tried entering a fake username and password. Clicking 'Login' gave me an unknown user/password message but the URL started 'https' - could this be an easy way to verify the URL of the target page?

Unfortunately no. It's very possible that the URL you went to first was some other URL that, for example, captured your information and then automatically and transparently sent you on to the https URL.


David Sorge
August 10, 2008 7:27 PM

I don't know of a better way to get info to you and it may be important. In your News letter just below the link to this article I found this: MailScanner has detected a possible fraud attempt from "" claiming to be "MailScanner has detected a possible fraud attempt from "" claiming to be" was in RED. I think I have MailScanner on my computer so I think this may be bad. I won't click on it unless you can say nothing to worry about. More information would be appreciated.

"Aweber" is the company that processes my mailing list, and they modify links so that I can see which links people are clicking on. So the link is safe.


David Sorge
August 10, 2008 7:40 PM

Speaking of bad web design. I went to read "Why didn't you answer my question?" and a grayed out screen with modal box asking me if I wanted to receive your news letter in the middle of it came up. Ironically I was trying to read the article Because of the news letter. I had no scroll bar and so I was not able to scroll down to close it. I used the back button.and here I am. I'm going to try again. This time it worked.

FWIW: that popup does have a close button (x in the upper right corner, like most windows), and as long as cookies are enabled should only appear once ever 180 days.

More here: Why do I keep getting a newsletter subscribe pop-up on your site?


Jimmy Boyd
September 21, 2008 4:38 AM

Hi Leo,

Excellent article! You mentioned 'always using an encrypted VPN' in your article. How is a VPN more secure than a single https web site implementation? Wouldn't I need using your browser settings trick within a VPN? Thanks a lot.

A VPN will encrypt all data between yourself and the VPN provider, whether it's https or not. After the VPN provider it travels encrypted, or not, dependong on whether it's https, or not.

An https connection is encrypted all the way between you and the web site you're accessing.

Most sniffing attacks happen at your end, so making sure that the data is encrypted as it leaves your computer - https or VPN - is what's important, IMO.

- Leo
August 2, 2011 8:54 AM

Can anyone help with the settings for Firefox? It looks like the article was written in 2008 and those settings (Tools, Options, Security, Settings) was available in Firefox 3.5. In the newer version of Firefox (I'm on v5), there's no "Settings" button, and I can't find a similar one anywhere in Options. Please advise if you find a solution!

Unfortunately that's been moved to a set of hidden preferences in about:config. I found this on that:

August 2, 2011 2:05 PM

JayFlight - I searched Firefox help and found this for Ver 4. It also appears to apply to ver 5.

The only way I know to do this in Firefox 4 is to change hidden preferences.

Type about:config into the location bar and press enter
Accept the warning message that appears, you will be taken to a list of preferences
In the filter box type security.warn this will show a few preferences, you can double-click on them to change their values, the settings are:
security.warn_viewing_mixed -I'm about to view an encrypted page that contains some unencrypted information
security.warn_submit_insecure - I submit information that's not encrypted
security.warn_leaving_secure - I leave an encrypted page for one that isn't encrypted
security.warn_entering_weak - I am about to view a page that uses low-grade encryption
security.warn_entering_secure - I am about to view an encrypted page

August 2, 2011 2:31 PM

The Google Chrome browser version 13.0.782.107 beta-m, and perhaps earlier versions are smart enough to show https in green when it's safe, and in red when it's not. The Walmart prescription renewal url is one example that demonstrates this.

Again, that's the page that you're on, and it does not reflect the security of the page that you're going to when you press "Submit", "Login" or whatever after filling in your account details.

Comments on this entry are closed.

If you have a question, start by using the search box up at the top of the page - there's a very good chance that your question has already been answered on Ask Leo!.

If you don't find your answer, head out to to ask your question.