Diffie-Hellman and its TLS/SSL usage
Diffie-Hellman is used in SSL/TLS, as "ephemeral Diffie-Hellman" (the cipher suites with "DHE" in their name; see the standard). What is very rarely encountered is "static Diffie-Hellman" (cipher suites with "DH" in their name, but neither "DHE" or "DH_anon"): these cipher suites require that the server owns a certificate with a DH public key in it, which is rarely supported for a variety of historical and economical reasons, among which the main one is the availability of a free standard for RSA (PKCS#1) while the corresponding standard for Diffie-Hellman (x9.42) costs a hundred bucks, which is not much, but sufficient to deter most amateur developers.
Diffie-Hellman is a key agreement protocol, meaning that if two parties (say, the SSL client and the SSL server) run this protocol, they end up with a shared secret K. However, neither client or server gets to choose the value of K; from their points of view, K looks randomly generated. It is secret (only them know K; eavesdroppers on the line do not) and shared (they both get the same value K), but not chosen. This is not encryption. A shared secret K is good enough, though, to process terabytes of data with a symmetric encryption algorithm (same K to encrypt on one side and decrypt on the other), and that is what happens in SSL.
There is a well-known asymmetric encryption algorithm called RSA, though. With RSA, the sender can encrypt a message M with the recipient's public key, and the recipient can decrypt it and recover M using his private key. This time, the sender can choose the contents of M.
So your question might be: in an RSA world, why do we bother with AES at all? The answer lies in the following points:
There are constraints on M. If the recipient's public key has size n (in bytes, e.g. n = 256 for a 2048-bit RSA key), then the maximum size of M is n-11 bytes. In order to encrypt a longer message, we would have to split it into sufficiently small blocks, and include some reassembly mechanism. Nobody really knows how to do that securely. We have good reasons to believe that RSA on a single message is safe, but subtle weaknesses can lurk in any split-and-reassemble system and we are not comfortable with that. It is already bad enough with symmetric ciphers, where the mathematical situation is simpler,
Even if we could handle the splitting-and-reassembly, there would be a size expansion. With a 2048-bit RSA key, an internal message chunk has the size of at most 245 bytes, but when encrypted, it yields to be a 256-byte sequence. This wastes our life energy, i.e. the network bandwidth. Symmetric encryption incurs only a bounded overhead (well, SSL adds a slight overhead proportional to the data size, but it is much smaller than what would occur with a RSA-only protocol),
Compared to AES, RSA is slow as hell,
We really like to have the option of using key agreement protocols like DH instead of RSA. In older times (before 2001), RSA was patented but DH was not, so the US government was recommending DH. Nowadays, we want to be able to switch algorithms in case one becomes broken. In order to support key agreement protocols, we need some symmetric encryption, so we may just as well use it with RSA. It simplifies implementation and protocol analysis.
See this answer for a detailed description of how SSL works.
I think Security Now ep. 412 "SSL & Perfect Forward Secrecy" has what you want.
Maybe you should just search read their transcript for 'Diffie', because these podcasts have a lot of news/misc stuff before they get to the point.
Quoting:
But many browsers today, and many servers today, support what's called Diffie-Hellman Ephemeral, DHE. Ephemeral specifically means "just for the moment." So this is DHE, Diffie-Hellman Ephemeral, is a technology that is decoupled - and this is the key, "decoupled" - from the server's authentication. And as I just said with Diffie-Hellman, a third-party observing the interchange gets no knowledge. That is exactly the protection we want in our SSL connections from long-term archiving. Long-term archiving and subsequent revelation of the server's private key doesn't give anybody any help in cracking Diffie-Hellman Ephemeral protection.`
They specifically address why it is not yet in full use:
But Microsoft does not offer any Diffie-Hellman Ephemeral [...] that also has RC4, which is the cipher [...]. Unfortunately they're all CBC, Cipher Block Chaining. And that's the encryption protocol which is vulnerable to the BEAST attack.`
Here they refer to the SSLLabs tests they described in ep. 395 (and 396).