1

As a user, how do I know my user name and password sent to a server is encrypted with HTTPS? Let me preempt the answer of "look for the little lock" or "look for https in the URL" with the following two examples:

First, let's say I browse to bank.com's website. When I get to the login page, the URL in the address bar says "https://www.bank.com/login.php". I type in the my user name and password, and hit submit.

However, the form for the authentication says this:

<form action="http://www.bank.com/login.php"> ... </form>

Obviously, my credentials are not being sent through HTTPS. The second example is just the opposite, as you might imagine. I browse to bank.com and am presented with the "http://www.bank.com/login.php" page. However, the form this time uses HTTPS:

<form action="https://www.bank.com/login.php"> ... </form>

From this, it's clear we can't trust the lock symbol in the browser nor the "https" in the address bar.

I think I really have two questions which straddle SO and SU:

  1. SU: How can a normal (not HTML/programming savvy) user perform such a check effectively?
  2. SO: How can websites (or browsers) provide help to users to perform this check?
3
  • I believe that most browsers will throw up a "sending unencrypted data from an encrypted website" warning in the first case, but don't currently have any evidence to hand to back that up.
    – DMA57361
    Nov 23, 2010 at 18:34
  • @DMA57361 - If the site (like bank.example.com) has previously been added to your list of "Trusted Sites", will you still get the warning in all (modern) browsers? Apr 19, 2013 at 3:50
  • (Jeremy, apparently Chrome and IE do not warn at all; see my updated answer. That surprised me a lot... CC: @DMA57361)
    – Arjan
    Apr 20, 2013 at 14:34

3 Answers 3

3
  1. For non-tech savvy users, there is not a lot you can do. Enabling warnings in your browser for posting over HTTP from HTTPS, is your best option. If available this is likely enabled by default. However, it it common that the form will not specify the site or protocol, and will submit back to the server which sent the form using the site and protocol that the form was supplied on. In this case, if the form was served over HTTPS, then the submission will be also.
  2. Websites should run certification tests which ensure the login form requires HTTPS. This is relatively easy to do in most web servers. If they deal with credit cards, there are requirements that they do certify there site and infrastructure. They should also ensure the login form is only served using HTTPS.

HTTPS does not necessarily indicate that your data is well encrypted. There are relatively low security protocols which can be enabled. The server, and browser negotiate the encryption level. Where permitted (some countries have limits) you can disable lower security protocols in your browser. (The screen to do this is not always easy to find.) It is usually easier to check the security on the particular connection.

2
  • Even more: Apache had a major flaw some years ago, by allowing zero-bit encryption... Shared public computers that had their browser settings changed to allow for that non-encrypted "SSL" too, could then fool the server into accepting that.
    – Arjan
    Nov 23, 2010 at 19:01
  • I didn't mention it but one available protocol is none (0 bit encryption). Normally it needs to be enabled.
    – BillThor
    Nov 23, 2010 at 19:50
2

it's clear we can't trust the lock symbol in the browser nor the "https" in the address bar

I expected a sane browser to warn you when a form on a HTTPS site submits to a non-HTTPS URL (your first example). But some more testing reveals that such is only partly true . April 2013:

  • Safari 6.0.4, Mobile Safari and Firefox 20 (on OS X 10.8 and Windows 7) indeed show a warning (both when submitting to the same URL, and when submitting to some other domain).

  • Chrome 26 (on OS X 10.8, Android 4.1 and Windows 7) and Internet Explorer 9 and 10 (on Windows 7) do not warn at all.

So, for the best user experience on browsers that do show a warning, the login page itself should indeed be served by HTTPS as well. Any bank will do that. On sites that don't, users indeed need to do the validation themselves, or install a plugin or use some Greasemonkey script to decorate safe forms, or show some warning. For Chrome a third-party extension is available as well, but I never used that.

__________
Thinking about it, maybe I like the change: it might make more people enable HTTPS on their site, not having to worry about warnings when interacting with third-party sites that do not use HTTPS yet.

7
  • If the site (like bank.example.com) has previously been added to your list of "Trusted Sites", will you still get the warning in all (sane) browsers? Apr 19, 2013 at 3:52
  • @kevin, I don't know, as I don't use browsers that use the concept of trusted sites. But: you can easily test in this example. However, it seems the current Chrome on a Mac (no longer) warns about submitting to a non-secure URL. Firefox and Safari do well though.
    – Arjan
    Apr 20, 2013 at 10:51
  • I tried your example page on Windows 7 x64 using IE9 x32 and x64. For each version of IE9, I opened the example page and clicked each button. After clicking each button, I went back to the original page and clicked the next button. When clicking the HTTP buttons, the page background changed from green to red, but in all HTTP and HTTPS cases, I got no browser warnings. My IE9 on this machine is heavily customized, so that might explain why no warnings. I also tried this in FireFox 14.0.1 and indeed I do get a warning from the browser as suggested (when the target is HTTP). --> Apr 21, 2013 at 16:23
  • I don't have either site (dikidiki.net or iana.org) in my trusted sites list. Apr 21, 2013 at 16:23
  • I don't have Chrome (or Safari) installed on any machine so I can't test on Chrome at this time. I can try this in the future, but perhaps someone else will try this on Chrome and report here. Apr 21, 2013 at 16:26
1

Force-TLS requires you to specifiy sites you want to require https communications. An article on usage and why is here: http://techcrunch.com/2010/10/25/firesheep/ I think this might answer both questions

2
  • Indeed, SSL is NOT only required while sending the credentials. (To ensure that, apart from using the correct URLs, a sane web application should also send the cookies with the secure flag.)
    – Arjan
    Nov 23, 2010 at 19:04
  • this is true... Nov 23, 2010 at 19:06

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .