Did you read the warning? It pretty much answers your question:
"This may mean that the server has generated its own security credentials, which Google Chrome cannot rely on for identity information, or an attacker may be trying to intercept your communications."
I just want to ensure the user that information passed to/from the server is encrypted.
Self-signed certificate doesn't guarantee the encrypted communication to/from your server. An attacker can intercept your handshake request and provide their own self-signed certificate.
You can create your own CA, sign a server certificate with it, and then ask users to install your CA certificate into their browsers.
Or you can get a free certificate from StartSSL.
Alternatively, you can contribute to some replacement for TLS.
ok, so are you also saying that it is impossible for an attacker to intercept data from a standard HTTP request?
My next point being that if standard HTTP is also vulnerable to such attacks, why doesn't the browser display a warning on EVERY page, telling us that it can not verify the website identify? Thus, all things being equal, I would assume that unverified, but encrypted is still better for the user than unverified AND unencrypted.
...but I've probably misunderstood something fundamental here (as is often the case!)
Comments
Did you read the warning? It pretty much answers your question:
"This may mean that the server has generated its own security credentials, which Google Chrome cannot rely on for identity information, or an attacker may be trying to intercept your communications."
I just want to ensure the user that information passed to/from the server is encrypted.
Self-signed certificate doesn't guarantee the encrypted communication to/from your server. An attacker can intercept your handshake request and provide their own self-signed certificate.
You can create your own CA, sign a server certificate with it, and then ask users to install your CA certificate into their browsers.
Or you can get a free certificate from StartSSL.
Alternatively, you can contribute to some replacement for TLS.
ok, so are you also saying that it is impossible for an attacker to intercept data from a standard HTTP request?
My next point being that if standard HTTP is also vulnerable to such attacks, why doesn't the browser display a warning on EVERY page, telling us that it can not verify the website identify? Thus, all things being equal, I would assume that unverified, but encrypted is still better for the user than unverified AND unencrypted.
...but I've probably misunderstood something fundamental here (as is often the case!)
HTTPS claims to secure the connection, so it is necessary to make clear when these claims aren't justified.
HTTP makes no security claims, no there's no "unexpected lack of security" to disclose.
Imagine that you're trying to connect to https://mail.google.com. Your browser receives a self-signed certificate. What should it do?
http://www.startssl.com/ - fantastic, thanks!