The posts will go via SSL, however, I don't like interfaces setup
this way to supply any sensitive information. One dot-com I was
considering buying from did this and I was entering my credit card
information and looked at the current page and saw that it was not
secure so (rather than doing a view-source and reading the HTML) I
used the telephone to order. Checking later I realized I would
have been OK.
Note, some pathological programmer could do just the opposite, but
that is why I have my browser set to warn me about secure-to-non-secure
transitions.
"Brian D. Kohl" wrote:
>
> Was not sure where else to turn for this question, so here goes:
>
> We are trying to get consensus on whether the following scenario will be
> fully encrypted when data is passed to the server (ie: we can't allow
> username and password data to go in the clear - obviously).
>
> We have a non secure http page that has two POST fields; one for username
> and another for the password. This is on example page
> http://nonsecure.html. The user types in the information and hits the
> submit button. The action URL that is tagged in the POST command in this
> html file posts to https://secure.html, which will validate a users login,
> etc. Now SSL is a session based protocol, and it seems quite unlikely that
> ANY information could be passed from the clients browser to the server
> until AFTER the SSL session was created; thereby sending it encrypted
> only. I am 95% sure that the data is encrypted, but wanted to run it by
> you all to let me know if I'm in the ballpark here. My apache and NES logs
> don't show conclusively whether the connection was established, then the
> login data was sent (securely), or whether both the POST URL (an SSL URL)
> and the data was all sent at once (ie: login in the clear) and the server
> just handled them both in the right order, but received them both in the
> clear from the beginning (I doubt it).
>
> I am snooping on some packets, but wanted to know if the RFC states it thus
> and whether anyone has seen different in regards to apache+mod_ssl and NES
> SSL (which we also use and would want to use this mechanism with as well -
> though not mod_ssl obviously).
>
> Thanks very much,
> Brian
>
> ----------------------------------------------------------------------------
> -----------------------
> Brian D. Kohl
> Lead Systems Administrator
> ChemConnect, Inc.
> [EMAIL PROTECTED]
> Direct: 415.364.3328
> Cell: 415.518.9052
> Fax: 415.646.0010
> ----------------------------------------------------------------------------
> -----------------------
> ______________________________________________________________________
> Apache Interface to OpenSSL (mod_ssl) www.modssl.org
> User Support Mailing List [EMAIL PROTECTED]
> Automated List Manager [EMAIL PROTECTED]
--
Gary Algier, WB2FWZ [EMAIL PROTECTED] +1 856 787 2758
Ulticom Inc., 1020 Briggs Rd, Mt. Laurel, NJ 08054 Fax:+1 856 866 2033
This space intentionally left blank by the censors.
______________________________________________________________________
Apache Interface to OpenSSL (mod_ssl) www.modssl.org
User Support Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
