Page 1 of 2 12 Last
  • Jump to page:
    #1
  1. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14

    SSL for secure form submission


    To submit an HTML form securely with SSL, does the initial page that the user comes to (the one with the form) need to be accessed via a secure connection, or just the script / template (whatever) that processes the form as specified in the action attribute of the form tag?
  2. #2
  3. No Profile Picture
    Apprentice Deity
    Devshed Loyal (3000 - 3499 posts)

    Join Date
    Jul 1999
    Location
    Niagara Falls (On the wrong side of the gorge)
    Posts
    3,237
    Rep Power
    19
  4. #3
  5. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14
    When I sign into my hotmail account only the URL in the action attribute of the form tag is accessed via SSL, what's up with that?
  6. #4
  7. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2001
    Posts
    4
    Rep Power
    0
    Because the user+pass is considered to be sensitive info. Once logged in, the session and cookie are taking over to identify your account.
  8. #5
  9. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14

    Non-sequitur


    freebsd,

    Ok, did you even read the previous posts? Because your post makes no sense, it's doing nothing to straighten this out. If you want to try this over again and post something that makes sense, I'd love to know what you know about this, if anything.

    Just for the sake of unequivocal clarity, I will rephrase my previous post.

    When I sign into my hotmail account, the page with the form that I enter my username and password in is accessed via a regular HTTP connection. The URL specified in the action attrbiute of the form tag is over an HTTPS connection. Thus, when I submit the form in which I have entered my username and password, I am sent to an HTTPS connection. See my original post for the relevance of this observation.
  10. #6
  11. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2001
    Posts
    4
    Rep Power
    0
    >> Ok, did you even read the previous posts?

    Sure.

    >> Because your post makes no sense

    Because your brain was thinking something else, perhaps girls or so...
    Anyhow, let me explain a little bit in details.

    1) When you type in http://www.hotmail.com, it immediately redirects you to a load-balancing login page, http://something.passport.com/cgi-bin/login
    Up to this point, SSL connection is still unnecessary.

    2) Once you entered your user+pass, but before clicking on sign in button, SSL connection is still unnecessary because only the people looking over the shoulder can see your user+pass.

    3) Once you clicked on sign in button, the transmission finally takes place. So setting the form action to https://something.passport.com/cgi-bin/dologin is to ensure your user+pass transmission is encrypted over SSL.

    4) Once logged in, the duty of passport.com is done. Therefore it redirects you to a non-https site.

    I said Because the user+pass is considered to be sensitive info because hotmail only care about user+pass and considered that to be sensitive info, so https connection is necessary in that matter.

    True, hotmail doesn't wanna encrypt your entire login session over SSL, because they think your inbox messages and whatever message you send to others are not sensitive, they don't care about that.

    5) While you are reading your inbox messages, hotmail already recognized your user+pass from cookie and its previous redirected session, they just think using SSL throughout your entire login session is unnecessary and is a waste of resource. Keep in mind, implementing OpenSSL takes more system resources.

    What you were saying sounds like step (2) and think that password sniffer can sniff your password before you click on the sign in button and while entering the user+pass into the form fields. That isn't true. Only someone who is looking over your shoulder can grab your password up to that point.

    All this stuff is just a common sense to a computer newbie. You should have posted your message to Beginners forum in the first place.
    Last edited by freebsd; July 12th, 2001 at 10:04 PM.
  12. #7
  13. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14

    reading the not-so-fine print


    freebsd,

    That's cute. Look, I know it must be hard for you to get along in the world being such an ignoramus, but I haven't given up on you yet, I'm going to try to explain this in terms even you can understand...

    1) I post a legitimate question.

    2) rod k posts a reply.

    3) I post a reply to rod k questioning his answer by citing an example that seems to contradict him.

    4) You post a reply, not to my original question, but to my later post, taken completely out of context. Due to your taking my post completely out of context, presumably because of not reading or understanding the rest of the thread, your reply makes no sense.

    5) I post a reply pointing out that your post made no sense, and re-phrasing my original question to make it easier to understand.

    6) You post a reply that takes a childish poke at me personally, and continues on to make what would have been a sensible, if not authoritative, response to my original question, before continuing on to babble about stuff that, yet again, had nothing to do with my question.

    Like I said, I haven't given up on you yet freebsd. I really think this annotated chronology should help you pin the problem down.

    Meanwhile, I would greatly appreciate it if anyone else wants to weigh in on this issue by answering my original question, which can be found in my original post or re-phrased in a later post.

    Still waiting to hear back from you rod k.
  14. #8
  15. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2001
    Posts
    4
    Rep Power
    0
    >> You post a reply, not to my original question, but to my later post

    Exactly. I was replying to your 2nd post in this thread in purpose to explain a little bit in details but unfortunately you still didn't get it.

    Okay, here's a reply to your orginal question: just the script.

    To support my answer:
    1) Say passport.com is using a self-signed cert (just to make you understand better), you would then get a prompt whether to accept or deny the cert. If you accept it, then the SSL connection is taking place and your form is being submitted over SSL.
    2) Say you have a static html page in your hard drive (file:///C:/form.html) with the form action set to whatever https script, before you submit it, obviously this initial page doesn't need SSL connection at all. When you submit it, then the SSL connection is initializing.

    Once again, the answer to your original question is: just the form action
  16. #9
  17. No Profile Picture
    Apprentice Deity
    Devshed Loyal (3000 - 3499 posts)

    Join Date
    Jul 1999
    Location
    Niagara Falls (On the wrong side of the gorge)
    Posts
    3,237
    Rep Power
    19
    JMM,

    My mistake. You don't need HTTPS on the form page, only on the action.

    BTW, I don't believe I will be responding to any more questions from you. Your attitude and personal attacks indicate that you are not someone who appreciates FREE help.
  18. #10
  19. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14
    freebsd, thank you. rod k, thank you.

    rod k,

    Do you think wrong information is helpful (hint: no)?

    What is my attitude?

    I never made a personal attack until I was the subject of an unprovoked personal attack from someone else.

    I greatly appreciate it when people on thus forum help me, and I try to help other people too.

    >> I don't believe I will be responding to any more questions from you

    Do whatever you want to do
  20. #11
  21. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2001
    Location
    Tauranga, NZ
    Posts
    349
    Rep Power
    14
    If the login page is unsecure you need to use POST method
    in your form

    if you use GET
    eg http://secure.com/login?user=bumeprbox&password=secret

    the url will be stored in the log files on every server it goes through
  22. #12
  23. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14
    Thanks for the heads up – yeah I'm using POST. So I take it you concur that the submission IS secure if only the action URL is a secure connection, and not the page with the form?
  24. #13
  25. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Apr 2001
    Location
    Tauranga, NZ
    Posts
    349
    Rep Power
    14
    unsecure page -> secure post action = secure transmission
    secure page -> secure post action = secure transmission
  26. #14
  27. No Profile Picture
    Contributing User
    Devshed Newbie (0 - 499 posts)

    Join Date
    Jan 2001
    Posts
    4
    Rep Power
    0
    >> If the login page is unsecure you need to use POST method in your form

    Incorrect. In the encrypted session perspecitive, that's secure, POST or GET doesn't make any difference.

    Once again, imagine the server is using a self-signed cert. If your form uses GET/POST, before the server accepting your form data (in other words, the SSL session initialization), you are required to Grant the cert, (a window will popup), then your https://secure.com/login?user=bumeprbox&password=secret is being transmitted securely from your browser to the server.

    >> the url will be stored in the log files on every server it goes through

    The transmission is still encrypted. Yes, it's visible when it gets to your server and that's why you should not use GET for the said reason and not the transmission.

    >> So I take it you concur that the submission IS secure if only the action URL is a secure connection, and not the page with the form?

    I thought you already figured out the answer previously. Why do you need to reconfirm it?

    Let me explain once again just so you don't ask this question repeatedly.

    #1:
    If you are at a form page http://domain.com/form.html with a form tag like so: <form action="/cgi-bin/login.cgi" method="get">, that's equivalent to requesting http://domain.com/cgi-bin/login.cgi?value1=blah&value2=blahblah directly. I don't use full URL in this example so you can see the difference, because your unsecure HTTP session is kept, if KeepAlive hasn't expired. If you waited to long, you would have to reinitialize the unsecure HTTP session with the server to your request /cgi-bin/login.cgi.

    #2:
    At: http://domain.com/form.html
    Form tag: <form action=https://domain.com/cgi-bin/login.cgi method="get">
    Say this is your 1st visit, once the form button is pressed, your form data is not yet submitted, because another session (secure) needs to be initialized. A few moment later, you will then be asked whether you want to accept this cert, say you press Grant, okay, the SSL session has finally begun and you are sending value1=blah&value2=blahblah to the server with the data being encrypted DURING the transmission. That said, the session is encrypted and what sniffer sees is some garbage (not plain text).
    When the data gets to the destinated server, that is no longer secure if the sysadmin didn't configure a tight permission to the log files and its directory.
    In the SSL perspective, it's still secure.

    #3:
    At https://domain.com/form.html
    Form tag: <form action=/cgi-bin/login.cgi method="get">
    This is equivalent to the form action of <form action="https://domain.com/form.html>. That said, you don't need to use FULL URL because you have already GRANTED the cert once before getting to https://domain.com/form.html, so the window doesn't pop again.
    There is an SSL directive -> SSLSessionCacheTimeout. This directive configures when the server should reinitialize the SSL session.

    Say you did press GRANT but for the current session only as opposed to Accept this cert permanently until its expiration, and the server has configured SSLSessionCacheTimeout to be 60 (1 minute).
    And it takes you 3 minutes to complete the form, once you press submit, that darn window will popup again because your SSL session has expired and the server needs to reinitialize it with you, the browser.

    #4:
    At https://domain.com/form.html
    Form tag: <form action="http://domain.com/cgi-bin/login.cgi method="get">
    In this case, your SSL session may continue, but you really are requesting a brand new and unsecure HTTP session.

    To summarize all this up:

    #1 - unsecure all the way
    #2 - secure for transmission of your form data to the server but unsecure if everyone has access to the server log (not SSL issue any longer)
    #3 - secure all the way to the desitination
    #4 - unsecure all the way because you are reinitialize a new session to the HTTP, not HTTPS.

    And finally, if you use POST, that secures the transmission as well as the logging mechanism, if applicable.
  28. #15
  29. No Profile Picture
    Contributing User
    Devshed Novice (500 - 999 posts)

    Join Date
    Feb 2001
    Location
    USA
    Posts
    830
    Rep Power
    14
    freebsd,

    Let me explain once just so you don't feel the need to open your mouth ever again.

    #1:
    You are an ignoramus

    #2:
    I don't believe you know anything about anything

    #3:
    "destinated" ? Nice. That must be one of your own invention. Now, I'm generally in favor of word invention, but that one is just stupid

    In summary:

    For you, silence is golden

    Or to put it another way, since you're such an expert on all things computer and our English form of communication is seemingly too crude for you to understand:
    Code:
    if ( freebsd ) {
    
      silence = 'golden';
    
    }
Page 1 of 2 12 Last
  • Jump to page:

IMN logo majestic logo threadwatch logo seochat tools logo