• 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 ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

How dows 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 ( at least to me ). 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!
Ranch Hand
Posts: 205
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I'm no SSL expert but I think the SSL handshake happens before any information is sent. So in your scenario...it happens like this:

Press submit button to submit a form to https://whatever/login.jsp
Browser sees that the form action is for a site using SSL so BEFORE sending the form parameters connects to the site and completes the SSL handshake (checking certificates, creating session key, encrypting it with server's certificate etc). This initial connection for the SSL handshake may or may not be over SSL, I don't know. But it doesn't really matter since you're not sending any confidential information.
Once the SSL handshake is completed the connection is now over https and the browser will safely send the username/password.

The handshake and the sending of the form parameters will seem like one connection to the user since they press the "submit" button and all they see is the browser redirect to either a success or failure page. But in reality there is more than just one connection happening.
    Bookmark Topic Watch Topic
  • New Topic