What TLS actually gives you

Three properties, and they come apart

When someone says a connection is secure they usually mean one thing. TLS supplies three, and the three are separable — you can hold any one of them without the others. The failures that matter in practice are precisely the ones where a program bought two out of three and nobody noticed.

Confidentiality means nobody on the path can read the bytes. Authentication means the party at the far end really is who it claims to be. Integrity means nothing was altered in flight, whether by an attacker or by a flaky link. Keep the three names apart in your head for the rest of the module: every switch on SSLSocket and SSLServerSocket is a decision about which of them you are buying.

Symmetric encryption, and the key you cannot send

Almost every practical cipher is built on a key — a bit pattern, not a password, combined with the plain text by some algorithm to produce cipher text. Longer keys make brute-force guessing exponentially harder, which is why key length is the number people quote.

In symmetric (secret-key) encryption the same key both encrypts and decrypts, so both ends have to know it before the conversation starts. Over a public network that is a genuine chicken-and-egg problem. To agree on the key you have to send it, and you have to send it unencrypted, because encryption is exactly what you do not have yet. Anyone listening at that moment now holds the key and can read everything that follows. The cipher is not broken; the distribution of the key is.

Public keys: two keys with opposite jobs

Asymmetric (public-key) encryption breaks the deadlock by using a pair of mathematically related keys. What one encrypts, only the other can decrypt. You publish one half — the public key — to anybody who asks, on any channel, and you keep the private key and never transmit it at all.

Now the flow works. To send you something only you can read, I fetch your public key and encrypt with it. An eavesdropper who captured that public key in transit gains nothing: decryption needs the private half, which never left your machine.

Signing is the same operation, run backwards

Run the pair the other way and something more interesting falls out. If I encrypt with my private key, then anybody with my public key can decrypt it. As secrecy that is useless — everyone has the public key. As proof it is decisive: only the holder of the private key could have produced a blob that decrypts cleanly under the matching public key. That is authentication. And because any tampering en route would wreck the decryption, the same operation also detects modification. That is integrity. One mechanism, two of the three properties.

Why TLS uses both kinds

Public-key operations are far more CPU-expensive than symmetric ones — orders of magnitude, not percentages. So TLS is a hybrid. It uses public-key cryptography exactly once per connection, to agree on a fresh symmetric session key, and then runs the entire conversation on the fast symmetric cipher. The expensive maths happens during the handshake; the bulk data does not pay for it.

The man in the middle, and what a certificate is for

There is one attack left, and it is not on the cipher. Suppose an attacker sits on the path and swaps the server's public key for her own as it crosses to you. You encrypt under her key, believing it to be the server's. She decrypts, reads, re-encrypts under the server's real key, and forwards. Both ends see a working, correctly encrypted connection. Note carefully what this attack does not need: it does not break any algorithm and it does not care how long the keys are. Doubling the key length changes nothing.

The fix is to stop learning the public key from the very channel you are trying to secure. A certificate is a public key bound to an identity and signed by a certificate authority whose own public key already ships inside your JDK's trust store. Verifying the signature tells you that some CA was willing to vouch that this key belongs to this name. That is all it tells you. A certificate is a statement about identity, never about honesty, competence or solvency — a criminal can hold a perfectly valid certificate for their own domain.

Worked example — one HTTPS connection, property by property

Walk a browser connecting to books.example.com and mark where each property is bought.

1. Client hello. The client offers the protocol versions and cipher suites it supports. Nothing is secret yet and nothing is proved.
2. Certificate. The server sends its certificate chain: its own certificate, signed by an intermediate CA, signed by a root already in the trust store.
3. Verify the chain. The client checks each signature up to that root, checks the validity dates, and checks that the name inside the certificate matches the host it actually asked for. Authentication is bought here, and only here.
4. Key exchange. Both sides derive one fresh session key for this connection.
5. Application data. GET /catalogue HTTP/1.1 goes out encrypted under the session key, with an authentication code on every record. Confidentiality and integrity are bought here.

Now delete step 3 — which is exactly what an anonymous cipher suite does, since it carries no certificate to verify. Steps 4 and 5 still work perfectly. You get a flawlessly encrypted, tamper-evident channel to whoever happened to answer.