Is a HTTPS connection secure without a valid SSL certificate?

I use a HTTPS connection without a valid SSL certificate. Is the connection safe? Is the information encrypted?

The connection is encrypted even if the SSL certificate isn't valid (expired, snake-oil, untrusted CA, etc.). The SSL certificate validation just makes sure you're connecting to the folks you think you're connecting to. Encryption doesn't do you any good if the folks decrypting your data are crackers instead of PayPal.

Actually it is possible to establish an encrypted connection between complete strangers without a certificate, using Diffie-Hellman or similar key exchange algorithms.

Alice and Bob agree on a random number x. Alice calculates x^a, where a is a large prime number known only to Alice, and sends that to Bob. Bob calculates x^b and sends it to Alice. Alice calculates (x^b)^a, and Bob calculates (x^a)^b. Since (x^a)^b = (x^b)^a = x^ab, Alice and Bob now both know the number x^ab and can use it as an encryption key. The beauty of this is that Bob doesn't know a, Alice doesn't know b, and any eavesdroppers don't know either number (because calculating a from x^a, in the case of large numbers, would take years).

As supercat points out, this by itself is still susceptible to a man-in-the-middle attack, and that's why at least one end of the transaction needs to authenticate using a certificate. To be accurate, though, it is not the server that checks this, it's the browser, and most browsers will let the user continue if the certificate is invalid (or possibly even garbage). In that event, the connection will still be considerably more secure than a regular connection. To listen in, you'd need to be able to manipulate IP routing or DNS lookups, and you'd have to set it up before the connection was first made, which is not easy to do.

BTW the keypairs in certificates are not what's used to encrypt actual traffic; they are used to establish a new single-use key for a much faster symmetric cipher (such as DES) which then does the rest of the work.

If there were no verification of SSL certificates, then someone who intercepted a communications channel could capture a request to connect to https://www.acmebank.com, send its own request to www.acmebank.com, and negotiate keys with both acmebank.com and the user. After that, it could receive each morsel of data from the user, decrypt with the user's key, and encrypt with acmebank's key, and do likewise with data from acmebank.com. The net effect would be that neither the user nor acmebank would see anything wrong, but the interceptor would be able to decrypt all of the data between the user and acmebank. The user and the bank will be using different keys to handle their communication, but neither entity will know this. Adding any standard aspect to the protocol to inquire what key is in use wouldn't help, since the interceptor could detect such queries and change the responses appropriately.

SSL prevents a man-in-the-middle attack by requiring the host to send the recipient a copy of the key the host is using, encrypted in a form that an intruder won't be able to fake (unless the intruder can fake CA credentials, at least). If one does not use a CA-issued certificate, there will be little protection against a man-in-the-middle attack, though the encrypted layer would prevent passive or retrospective decryption of session contents (BTW, I wish there were standards for something between unencrypted communication and SSL, for situations where passive or retrospective decryption are the primary threat, but I don't know of any).