A Look at H.323 Encryption or Why your AES encryption might be worth nothing
How does encryption work for H.323 calls ?Most endpoints today have a setting for "AES encryption" and will show some indicator (usually a closed lock) when the current call is being encrypted. Most users take this as a sign that their conversation can not be snooped on. Unfortunately thats not true for many implementations.
Why so ? AES itself is a very secure algorithm, unless you know the key used for the encryption...
Virtually all endpoints, use the standard H.235.6 encryption. H.235.6 specifies that a master key is negotiated when the call is established using a Diffie-Hellman exchange. From this master key, the H.245 master in the call creates separate media keys for each logical channel (thats a very good design, so we don't use the master key too often).
Unfortunately the Diffie-Hellman exchange is easily attacked by a man-in-the-middle and must be protected by separate security measures to be safe. H.323 and H.235 mention TLS or IPSec encryption to secure the signaling channel, but so far I haven't seen any commercial endpoint that actually implements this!
What does this all mean ?Unless you currently encrypt your whole network up to the destination endpoint using IPSec, your AES encryption is only reasonably safe against attackers that use passive listening, but is easily(!) subverted with a man-in-the-middle attack.
It doesn't take expensive equipment to mount a man-in-the-middle attack, two GNU Gatekeepers working as encryption proxies are enough. I don't want to give a detailed explanation, but its really simple. The slightly harder part is to divert H.323 calls through a listening device, but tampering with BGP routes happens quite often and some attackers might even have direct access to your internet lines. Other options include DNS spoofing or ARP spoofing. So this danger is quite real.
What should you do ?
What else is wrong with encryption in H.323 ?As long as your encryption keys aren't properly protected, you probably don't have to worry about other things, but for completeness sake:
ReferencesH.235.6 ITU Spec
Last updated: 18. Dez 2013
Page maintained by Jan Willamowius