Home
· Download
· Support
· Success Stories
· Blog
· Imprint

Documentation
· English Manual
· French Manual
· Spanish Manual
· Persian Manual
· Portuguese Manual
· Chinese Manual
· FAQ
· Interoperability
· Intro to H.323
· Usage Examples
· Configuration Notes
· GnuGk and SIP

Tools & Addons
· Java GUI
· ISDN Gateway
· CTI / ACD
· GnuGk Addons
· Endpoints
· Gateways
· MCUs
· IVRs
· Billing
· Commercial Addons

Development
· Compiling
· Development
· NAT Traversal
· Tools
· Authors

Misc
· Events
· Logos
· Recommended Books
· Site Map

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 ?

  • 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.
  • If you do come across endpoints that support TLS encryption, please contact me. I'd love to run some interoperability tests.

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:
  • H.235.6 specifies the use of Diffie-Hellman token up to 4 KB, but the underlying transport structure only allows tokens up to 2 KB, so its impossible to use anything larger than 2 KB. The ITU is working on a fix and H323Plus and thus GnuGk already support the proposed fix. It is telling that this fact only shows up so many years after the spec was passed...
  • H.235.6 specifies the update of media keys after 2^64 crypto operations or whenever one party feels the need. Crypto text books suggest a key change after 2^32 operations (roughly 64 GB = 9 hr of 2 mbps video), but it seems most endpoints don't support a key update at all.

References

H.235.6 ITU Spec



Last updated: 18. Dez 2013
Page maintained by Jan Willamowius