Hi,
after implementing H.235 media encryption in the GNU Gatekeeper and H323Plus I am surprised by the false sense of security people have about their commercial endpoints.
I have collected my thoughts here along with a suggestion for a partial fix.
http://www.gnugk.org/h323-encryption.html
http://www.gnugk.org/gnugk-tls-tunnel.html
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 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. So this danger is quite real.
What should you do ?
- Don't stop using AES encryption, make more use of it! At least against passive listening, its a good protection.
- Check if your endpoint supports TLS encryption. For example use Wireshark, filter by "h225" and if you can see Setup, Alerting and Connect messages for your call, its not encrypted.
- Ask your vendor why he doesn't support encryption for the signaling channel!
- Spread the word and help avoiding a false sense of security using current encryption implementations!
- You can use GnuGk's TLS encryption to at least encrypt H.323 signaling over internet connections that are especially prone to eavesdropping. See this TLS tunnel example: http://www.gnugk.org/gnugk-tls-tunnel.html
- If you do come across endpoints that support TLS encryption, please contact me. I'd love to run some interoperability tests.
- I'm still looking for sponsors to improve the TLS encryption in GnuGk and implement similar in H323Plus. Please contact me.