On Fri, 5 Jul 2002, Jerome Houston wrote: > if the browser is making a request, and it sees an https:// at the beginning > of the request URL, it will : > 1. get the domain's public key from a public key server > 2. encrypt the whole request with the domain's public key > 3. submit it to the web server.
We have public key servers? Around these parts the client and server use a self-contained process to handle the key exchange. The server's key has been signed by a certificate authority (Verisign, etc.) whose public key is already stored in the browser... or not, in which case the client alerts the user and generally continues nevertheless. > If the web server sees that this is an encrypted request, it will : > 1. decrypt the request with it's private key > 2. process it and generate a response (usually in the form of html) > 3. encrypt the response with it's private key > 4. send it back to the browser Sort of. The server's key is used to encrypt the exchange of a new key which lasts only for the lifetime of the transaction. This ephemeral key is what's used to encrypt the actual data. But this nuance is probably not very important to understanding the practical issues of working with PHP and HTTPs. > Now, one of the things that many people are confused about is that they > think there must be a lock icon at the bottom of the browser when they > are entering sensitive info (like credit card numbers). Nope. The only > important thing is that the form which takes the sensitive data SUBMITS > to an https:// URL. Because (as above) it will encrypt the request > (which includes the sensitive data) BEFORE it submits it over the > internet. But most people don't know how to check that a form submits > to an to an https:// URL. Yup. You'd think that the browser developers would come up with a way to indicate this (mouse pointer turning to a lock when hovering over a submit button, etc.). miguel -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
