Hi Lance, I am by no means an authority on SSL. But my customer and I did conduct our own 'secure logon' testing with a packet sniffer and could easily 'see' what encrypted and un-encrypted data was being sent and under our own controlled conditions. I am merely offering some advice and information based on my experience.
Regardless of what anybody recommends to you (including me), I urge you to conduct your own security tests for your own peice of mind. The following is a copy-and-paste from the VeriSign SSL Guide book: http://www.verisign.com/resources/gd/buildEcommerce/index.html (Signup required). ================= How SSL Server Certificates Work ------------------------- SSL Certificates take advantage of SSL to work seamlessly between Web sites and visitors' Web browsers. The SSL protocol uses a combination of asymmetric public key encryption and faster symmetric encryption. The process begins by establishing an SSL "handshake" - allowing the server to authenticate itself to the browser user, and then permitting the server and browser to cooperate in the creation of the symmetric keys used for encryption, decryption, and tamper detection: 1.) - A customer contacts a site and accesses a secured URL: a page secured by a SSL Certificate (indicated by a URL that begins with "https:" instead of just "http:" or by a message from the browser). This might typically be an online order form collecting private information from the customer, such as address, phone number, and credit card number or other payment information. 2.) - The customer's browser automatically sends the server the browser's SSL version number, cipher settings, randomly generated data, and other information the server needs to communicate with the client using SSL. 3.) - The server responds, automatically sending the customer's browser the site's digital certificate, along with the server's SSL version number, cipher settings, etc. 4.) - The customer's browser examines the information contained in the server's certificate, and verifies that: a. -- The server certificate is valid and has a valid date b. -- The CA that issued the server been signed by a trusted CA whose certificate is built into the browser c. -- The issuing CA's public key, built into the browser, validates the issuer's digital signature d. -- The domain name specified by the server certificate matches the server's actual domain name If the server cannot be authenticated, the user is warned that an encrypted, authenticated connection cannot be established. 5.) - If the server can be successfully authenticated, the customer's Web browser generates a unique "session key" to encrypt all communications with the site using asymmetric encryption. 6.) - The user's browser encrypts the session key itself with the site's public key so that only the site can read the session key, and sends it to the server. 7.) - The server decrypts the session key using its own private key. 8.) - The browser sends a message to the server informing it that future messages from the client will be encrypted with the session key. 9.) - The server then sends a message to the client informing it that future messages from the server will be encrypted with the session key. 10.) - An SSL-secured session is now established. SSL then uses symmetric encryption, (which is much faster than asymmetric PKI encryption) to encrypt and decrypt messages within the SSL-secured "pipeline." 11.) - Once the session is complete, the session key is eliminated. It all takes only seconds and requires no action by the user. ==================== Note steps 1.) and 10.) -- My para-phrased summary note on step 1.) - "A customer accesses a secured URL" "This might typically be an online order form" -- My para-phrased summary note on step 10.) which 9 steps after step 1.) - "An SSL-secured session is now established" Good luck. Cheers... Scott Cadillac http://xml-extra.net [EMAIL PROTECTED] http://witango.org [EMAIL PROTECTED] VP, Research and Development Plus International Corp. 604-460-1843 [EMAIL PROTECTED] http://www.plusinternational.com Vancouver, BC, Canada Does your company have an Enterprise Information Portal? Check out Salsa at www.plusinternational.com/flash/salsa.htm ----- Original Message ----- From: "Lance" <[EMAIL PROTECTED]> To: "Multiple recipients of list witango-talk" <[EMAIL PROTECTED]> Sent: Tuesday, July 02, 2002 10:23 AM Subject: Re: Witango-Talk: does a form submit from a http page to a https ensure secure data? > in fact... this is getting confusing, cos i get 2 different response > from different people. so far, i have 3 person telling me that the data > will be encrypted and 1 person (you know who ;) telling me otherwise. > > <@snip1> > > I beleive the answer to your question is yes, the data from the form would > be encrypted > > </@snip1> > > <@snip2> > Yes it will be encrypted...when the browser sends to HTTPS it must (by > definition) use SSL to communicate and will there for be encrypted...you > traffic will look like: > > C = Client > S = Server > > C -> S Form Request > S -> C Form > C -> S SSL Connect > S -> C SSL Certificate > C -> S SSL Form Submit > S -> C Form Result page > </@snip2> > > <@snip3> > > Your form action parameter has an absolute url specifying an https > protocol. When the browser submits the form, it uses the url you specify > which is https. So the request is going to be encrypted. You might > consider serving the form page from https as well to kind of tighten > things up a little, but the data will be posted under https which is an > encrypted connection. > > </@snip3> > > > for once, how i wish you would have said "yes, it does encrypt". ;) > > Scott Cadillac wrote: > > >Hi Lance, > > > >I think I follow what you are trying to do and no it won't work. :-] > > > >If you open an HTTPS page on Domain1 - your browser has negotiated > >encryption keys exclusively for just that site (based on the domain name). > >So, if you Post your form to an HTTPS page on Domain2 (a different domain > >name), then your browser won't have 'keys' for Domain2 and so the form data > >is sent un-encrypted. > > > >Remember, encryption keys for a particular domain can't be obtained until > >the first time you open an HTTPS page for that domain - only after being on > >an HTTPS page can you then send encrypted data back to that domain. > > > >Hope this helps a little. Cheers... > > > >Scott Cadillac > >http://xml-extra.net > > > > > > > ________________________________________________________________________ > TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] > with unsubscribe witango-talk in the message body > ________________________________________________________________________ TO UNSUBSCRIBE: send a plain text/US ASCII email to [EMAIL PROTECTED] with unsubscribe witango-talk in the message body
