You can't use a https connection without a SSL certificate, can you? You probably mean using a self-signed certificate
–
Pekka 웃Oct 5 '10 at 15:15

2

No information or connection is ever safe. If the internet is a series of tubes, those tubes are translucent and anyone can see through them and into your application.
–
MosesOct 5 '10 at 15:15

6

@Moses Modern encryption ensures a reasonable level of safety for any data the average person is likely to encounter - SSNs, credit card, etc. I imagine the government wouldn't trust it for information on captured aliens.
–
ceejayozOct 5 '10 at 15:17

5 Answers
5

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
xa, where a is a large prime number known only to Alice, and sends that to Bob. Bob calculates xb and
sends it to Alice. Alice calculates (xb)a,
and Bob calculates (xa)b. Since
(xa)b = (xb)a = xab, Alice and Bob now both know the number xab 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
xa, 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.

Note: I think you forgot to mention that all calculations are performed module N where N is another large number agreed upon by Alice and Bob. Note also that neither X nor N need be random numbers -- they can even be constants hardwired into the algorithm; only a and b are variables and secrets.
–
Edward FalkMay 7 '13 at 19:32

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).

Basically what you're saying is using SSL without a certificate is pointless, against experienced hackers
–
boboboboApr 7 '13 at 7:01

@bobobobo: SSL without a certificate protects against some threats but not others. Whether or not such protection is useful depends upon the type of protection that's needed. If each party had a certificate which confirmed via some outside channel to have been protected by the other, there would be no need for certificates issued by some outside CA. For example, even without certificate authorities it would be possible for banks to post on billboards a thumbprint of their self-issued certificate, specify in all their ads and mailings the locations where such...
–
supercatApr 8 '13 at 15:12

...billboards might be found, and have people watch such billboards to ensure they are not tampered with. Their customers could then confirm when they connect to the bank the first time that the certificate they receive has a correct thumbprint. In practice, this would be so much hassle that few customers would want to bother with it; having SSL automatically use certificates from a small number of trusted authorities simplifies things enormously.
–
supercatApr 8 '13 at 15:14

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.

the browser ask you if you trust in the connection, if i accept this connection the transfered information is not encrypted anyway?
–
user466981Oct 5 '10 at 15:17

3

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.
–
ceejayozOct 5 '10 at 15:19

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.edmondsonOct 5 '10 at 15:20

The server is NOT going to refuse the connection. The browesr will warn you that there is no certificate (or that it is expired) then it is your sole responsibility to drop or continue the session. As long as you are using the SSL protocol, the connection will be encrypted.
–
Jean-FrançoisJan 19 '13 at 20:53

@Jean-François - without a certificate where does the browser get the encryption key from?
–
m.edmondsonJan 20 '13 at 22:50

It's possible to establish an encrypted connection, yes, but it would still be possible that you're communicating with a cracked cpmputer instead of the real server. Like that, the cracked computer tells the server that he would be the client, decrypt all the data, store it and send the encrypted data to the client (and tell him he would be the server). So it's just a safe connection if there's no vulnerable point between the server and the client, which no one can guarantee.