HTTPS/SSL question



  • I thought I knew the answer to this, but after a conversation today, I'm not so sure.

    Say there is a standard web 'submit' form with a username and password.   If the form is on an unsecure/http page, but it is submitting to a secure/https page, is the form data sent encrypted or cleartext?

    It comes down to whether or not the encryption information is exchanged before the post data is submitted...and I didn't think it was...but in retrospect I guess I am not sure.  A wonderful WTF could result, since the page I'm seeing this on is a bank...

    -cw



  • @CodeWhisperer said:

    I thought I knew the answer to this, but after a conversation today, I'm not so sure.

    Say there is a standard web 'submit' form with a username and password.   If the form is on an unsecure/http page, but it is submitting to a secure/https page, is the form data sent encrypted or cleartext?

    It comes down to whether or not the encryption information is exchanged before the post data is submitted...and I didn't think it was...but in retrospect I guess I am not sure.  A wonderful WTF could result, since the page I'm seeing this on is a bank...

    -cw

     It is sent encrypted.  It doesn't matter where the page with the form came from, but where it's going to that matters.



  • If I was in your shoes, I'd fire up Ethereal aka Wireshark and check the captured packets. I'm not entirely sure, but somewhere in the back of my mind there is this "http form->https = bad idea" memory fragment.

    Edit:  I think the main problem with an form transmitted by HTTP is that the authenticity of the server cannot be verified, so if some bad guy manages to do a man-in-the-middle-attack, you cannot check the certificate before you send the confidential information.



  • @ammoQ said:

    If I was in your shoes, I'd fire up Ethereal aka Wireshark and check the captured packets. I'm not entirely sure, but somewhere in the back of my mind there is this "http form->https = bad idea" memory fragment.

    Edit:  I think the main problem with an form transmitted by HTTP is that the authenticity of the server cannot be verified, so if some bad guy manages to do a man-in-the-middle-attack, you cannot check the certificate before you send the confidential information.

    Close. The problem is that the unsecured page contains the URL of the server to which you are going to send the confidential information, and you haven't validated that this URL is the correct one. An attacker would intercept your request for the unsecured page and deliver you an identical copy, which had the form action URL replaced with one that pointed to her own server.



  • >g<  I guess the real WTF in this case is that this login page has a small link underneath it that asks "Why is this secure?" :)

    It takes you to another page (which doesn't really explain why it would be secure, incidently), and then a link to a log in page which is https.  At least you can get to one...

    Thanks for the sanity check guys.

    -cw



  • @asuffield said:

    Close. The problem is that the unsecured page contains the URL of the server to which you are going to send the confidential information, and you haven't validated that this URL is the correct one. An attacker would intercept your request for the unsecured page and deliver you an identical copy, which had the form action URL replaced with one that pointed to her own server.

    I wonder if it is possible for a Web server to answer an HTTPS request with a redirect (e.g. to another https url), without having a valid certificate for the first URL...


Log in to reply