Take the 2-minute tour ×
Super User is a question and answer site for computer enthusiasts and power users. It's 100% free, no registration required.

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?
share|improve this question
    
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 '10 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? –  Kevin Fegan Apr 19 '13 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 '13 at 14:34
add comment

3 Answers 3

up vote 3 down vote accepted
  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.

share|improve this answer
    
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 '10 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 '10 at 19:50
add comment

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.

share|improve this answer
    
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? –  Kevin Fegan Apr 19 '13 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 '13 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). --> –  Kevin Fegan Apr 21 '13 at 16:23
    
I don't have either site (dikidiki.net or iana.org) in my trusted sites list. –  Kevin Fegan Apr 21 '13 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. –  Kevin Fegan Apr 21 '13 at 16:26
show 2 more comments

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

share|improve this answer
    
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 '10 at 19:04
    
this is true... –  hbdgaf Nov 23 '10 at 19:06
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.