If I use a https connection without a SSL certificate, is the connection safe? the information is encrypted?
I'm a little bit confused about this =/
thanks!
+2
A:
Nope. What you're doing when using HTTPS is telling the browser to connect via a different port (443) whereas normally you connect via (80). Without a certificate, the server would refuse the connection. HTTPS is simply not possible without a certificate. Look here and you'll see a certificate is needed for it to work.
m.edmondson
2010-10-05 15:14:50
the browser ask you if you trust in the connection, if i accept this connection the transfered information is not encrypted anyway?
2010-10-05 15:17:36
If your browser asks you to trust an invalid cert, the information is encrypted. You just can't verify that the person receiving it is legit.
ceejayoz
2010-10-05 15:19:20
This means that the certificate is likely self signed or expired (thats why its asking if you're sure). The question was whether a certificate was required - which it is.
m.edmondson
2010-10-05 15:20:05
+3
A:
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.
ceejayoz
2010-10-05 15:15:31
But thats the point, a certificate is still required (whether valid or not)
m.edmondson
2010-10-05 15:17:11
Yes, but you can generate a self-signed one in seconds. I took the question as asking whether you need a valid cert.
ceejayoz
2010-10-05 15:18:15
In that case you're correct, however the question was whether a certificate was required - which it is or nothing will be encrypted.
m.edmondson
2010-10-05 15:21:49
The question says he's using a HTTPS connection, though. If you take the question 100% literally it's an impossible one.
ceejayoz
2010-10-05 15:23:16
+1
A:
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).
supercat
2010-10-05 15:40:40