Chris Travers wrote: > On Sat, Mar 13, 2010 at 5:21 PM, Luke<account...@lists.tacticus.com> wrote: >> I am assuming SSL. Correct me if I am wrong, but my recollection is that >> the query string (I.E. get) is in the clear with SSL, whereas post data is >> not. >> Do I have a fundimental misunderstanding or massive brain fart here? > > The SSL negotiation occurs as part of the socket establishment (hence > the name). This is why you can't supply different certificates based > on, say, the HOST header. SSL protects the whole socket, not just the > payload.
Translation: yes, you have a fundamental misunderstanding. The second most common one, in my experience, so I won't accuse you of a "massive brain fart", as amusing as that might be :-). Since understanding of how SSL works is still quite rare in practice, and *many* people arrive at erroneous conclusions based on incorrect or incomplete knowledge, I'd like to expand a bit on Chris' statements: Normal HTTP[1] usage is to make one request per TCP connection[2]. This follows the usual model of one-shot TCP connections, where the client uses a hostname to look up the IP address, connects a socket[3] to the remote IP address, sends the command (GET, POST, etc.) and reads the response. HTTP-over-SSL starts the same way (IP address lookup, socket connection), but instead of proceeding directly to the command/response portion, it immediately negotiates a secure connection before doing anything else. Part of this negotiation involves the web server[4] sending its certififcate[5] to the client, whereupon the client checks that the certificate is valid and also verifies that the host name contained *in the certificate* matches the host name used at the beginning of the whole process to do the IP address lookup. The server has no way of knowing in advance what hostname was used by the client, so each IP address may only be configured with a single certificate and, by implication, a single host name. Once the client and server have finished the SSL negotitation (see [5] for more info) the client finishes off in exactly the same way as it would have without SSL: by sending a command to the server and reading back the response (except now the entire communications channel is encrypted). [1] I'm only discussing HTTP 1.0, for simplicity's sake. [2] I'll also ignore HTTP over non-TCP connections, for the same reason. Those are extremely rare, anyway. [3] See http://en.wikipedia.org/wiki/Internet_socket and/or http://en.wikipedia.org/wiki/Berkeley_sockets for details. [4] Actually, any SSL-enabled peer; it doesn't have to be "web" or "server". And the SSL protocol is almost perfectly symmetric; the client can also start by pushing its certificate, if so configured. [5] Identity information that has been verified and attested, and subjected to a one-way mathematical transformation that the client can recompute and verify. See http://www.rsa.com/rsalabs/node.asp?id=2152 for an introduction. -- -Adam Thompson <athom...@athompso.net> (204) 291-7950 ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
