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?

Both.

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?

Because the user+pass is considered to be sensitive info. Once logged in, the session and cookie are taking over to identify your account.

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.

>> 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.

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.

>> 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

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.

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

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

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?

unsecure page -> secure post action = secure transmission
secure page -> secure post action = secure transmission

>> 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.

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: