• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Tim Cooke
  • paul wheaton
  • Jeanne Boyarsky
  • Ron McLeod
Sheriffs:
  • Paul Clapham
  • Liutauras Vilda
  • Devaka Cooray
Saloon Keepers:
  • Tim Holloway
  • Roland Mueller
Bartenders:

How does https really work?

 
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi everyone, I have a question on a particular way to use https that, at first look, seems incorrect. I noticed that some sites ( Paypal.com, americanExpress.com ) do not use the same pattern that everybody else does. That pattern is as follows:

As soon as I am redirected on the page of the site that contains the login form, the browser displays allready an https url. Therefore, when I hit the submit button on the login form, my user name and password is encrypted because both the page I'm on and the page that is being called ( or servlet, whatever ) resides on an https protocol. I always thought that this was the only way to go.

Now, as I said earlier, I noticed that some sites use a different way that mechanism... There way is the same way that I just described except that the page that contains the login form, does not display the https protocol...

In fact, if you type www.paypal.com, you will get the login page but the browser will not display https as the protocol being used. If you look at the source code however, the action of the form is an https page.

So, when I first noticed how Paypal works, I thought that the username and password were not protected while they were sent to the https page. But I installed a sniffer on my pc to see if I would be able to pick up the http package that contains the user name and password and to my surprise, I was not able to snif anything. In fact, when I hit the submit button, I did not pick up any http package at all. I thought that I would at least pick up the http package that contains the username and password who is being sent from an http page to an https page.

So my question is, how does this work? The user information seems protected but I dont undersdtand why because I thought that the page who contains the login form had to be in https.

I hope I was clear enough,
Thanks in advance!

Alexandre Folgueras
 
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
HTTP or HTTPS is used for the entire request-process-result loop from client to server back to client. If the submit action is an HTTPS URL, the request to the server is encrypted.

It may seem backwards, but don't think of the request to login as part of the page with the form for entering login information. As an analogy, consider tax forms. You go to the post office or library and obtain the the correct tax forms in clear text. Anyone watching you can see the forms you pick up. This is the HTTP request to get the login form.

You then go home and fill out the information in the clear. Again, anyone watching over your shoulder can see how much money you make. This is like you entering your login credentials in your browser (though the password entry box shows ***** instead of your password, just as if you covered up the "gross income" box with your other hand while you filled it in.

Finally, you put your tax forms in an envelope and mail it to the IRS. Someone would have to "break into" your envelope in order to see your information. This is the HTTPS request sending your login/password to the server which would have to be decrypted to be useful.

Browsers are not supposed to cache pages that are the result of an HTTPS request, but I don't know if encrypting the request for the login page itself gives you any added security. Who cares if the login page is cached so long as the data you entered isn't.
 
Alexandre Folgueras
Ranch Hand
Posts: 38
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Thank you for your response, it helps a lot. So there is no advantage nor disadvantage of making the login page secure? Then why do most of the commercial sites secure there login page? Maybe because they want customers to see right away that he is on a secure page and therefore he wont ask the question I asked in my first post?

Thank you for your help!
 
David Harkness
Ranch Hand
Posts: 1646
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Originally posted by Alexandre Folgueras:
So there is no advantage nor disadvantage of making the login page secure?

I think that's correct, but I wouldn't bet anything valuable on it. It could be that if it's not encrypted, a browser could cache it, and said browser might also store the values entered for autocomplete the next time it's displayed. That would be bad, and the browsers I've used have all separated autocomplete from storing logins and passwords.

Then why do most of the commercial sites secure there login page? Maybe because they want customers to see right away that he is on a secure page and therefore he wont ask the question I asked in my first post?

That would be my guess as well.
 
WARNING! Do not activate jet boots indoors or you will see a tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
reply
    Bookmark Topic Watch Topic
  • New Topic