Timing attacks against RSA, DH and AES I have been reading about “Timing Attacks on RSA: Revealing Your Secrets through the Fourth Dimension” by Wing H. Wong. I was wondering if this attack is feasible while signing with RSA and, if yes, how?  

Also, how this kind of attack is applied with DH? 

Talking about timing attacks in general, in which way AES is affected and how to solve it? (I mean, with RSA the "problem" is at multiplication level, while for AES where is the problem that makes the cipher implementation key or data dependent?)
The seminal paper on timing attacks is Paul C. Kocher, ‘Timing Attacks on Implementations of Diffie–Hellman, RSA, DSS, and Other Systems’, CRYPTO 1996, Springer LNCS 1109, 1996 (alternate link in case you hit a paywall).  This is also the standard reference, and it's quite approachable—I recommend reading it.  Here's a coarse high-level overview.

The basic idea for RSA and DH is to measure how long modular exponentiation takes as a function of a secret exponent.

How do you do this with RSA encryption?  Find an automated system that decrypts and sends an answer back to you, and send it a long sequence of messages, and measure how long it takes to decrypt each one.  Any timing variation in the crypto computation itself—once you've isolated noise from the network and other sources—is likely to be dominated by the timing variation in modular exponentiation to compute $m = c^d \pmod n$ for secret $d$, in naive RSA implementations.  (Here $n$ is the public key, $c$ is the ciphertext representative, and $m$ is the padded plaintext representative for (say) RSAES-OAEP, or secret key seed for RSA-KEM.)

How do you do this with RSA signature?  Find an automated system that signs and sends a signature back to you—not a signature on any document you want, only a signature on documents that the legitimate signer wants to sign.  For example, an HTTPS certification authority like Let's Encrypt will do this.  Send it a long sequence of requests to sign, and measure how long it takes to sign them.  Again, the timing variation is likely to be dominated by timing variation in modular exponentiation to compute $s = h^d \pmod n$ for secret $d$, in naive RSA implementations.  (Here $h$ is the message hash, and $s$ is the signature.)

How do you do this with Diffie–Hellman?  Find an automated system that performs DH key agreement with a static key, and ask it to do a long sequence of key agreements with public keys of your choice.  Once again, the timing variation is likely to be dominated by timing variation in modular exponentiation to compute $k = B^a \pmod p$ where $a$ is the static secret and $B$ is the attacker's ephemeral public key.

How do you do this with AES?  It's a little different, and the Kocher paper doesn't go into much detail beyond a casual mention.  The standard reference here is Daniel J. Bernstein, ‘Cache-timing attacks on AES’, Document ID: cd9faae9bd5308c440df50fc26a517b4, 2005-04-14.  It is also fairly approachable.  The coarse high-level overview is that the time it takes the CPU to load an element of an array depends on whether that position in memory is already cached.  By studying which elements of the S-box are typically not cached at some point in the computation yielding $S[k_i \oplus p_i]$, and studying which plaintext bytes $p_i$ cause the computation to take the most time, we can deduce the key byte $k_i$, and repeat for all the others.

There are also side channel attacks on other parts of RSA-based cryptosystems than modular exponentiation, such as Bleichenbacher's attack on PKCS#1 v1.5, which exploits side channels for the bytes that make up valid padding of a secret message representative to enable an adversary to decrypt or sign messages without the private key.  This side channel may manifest as a different error message, or as variation in the time it takes to respond, which extended the idea to RSAES-OAEP (paywall-free preprint), the successor to PKCS#1 v1.5 encryption.  Attacks in this class of side channels, padding oracle attacks, apply in other contexts as well, such as the Lucky Thirteen attack on CBC modes of block ciphers in TLS.

And there are, of course, other variations on the theme of timing attacks: e.g. exploiting cache-sharing in hyperthreading to recover keys from one hyperthread in another on Intel CPUs via the L2 cache, flush+reload attacks to recover keys via the L3 cache, cache-timing attacks that thwart naive RSA timing countermeasures, acoustic cryptanalysis using a microphone to hear variations in the spectrum of sound produced by secret-dependent timing in crypto algorithms, and so on.