[h323implementers] [Openh323gk-users] [Openh323gk-developer] Thoughts on H.323 encryption or Why your AES encryption might be worth nothing

Simon Horne s.horne at packetizer.com
Mon Sep 23 11:43:17 EDT 2013

I am not a fan of TLS as it has the inherent issue of being hop-by-hop.
Unless you can verify the entire signaling path is secure then it is
useless. Certainly you can verify from you endpoint to the gatekeeper is
secure but what about beyond that. Certainly for small closed deployments it
can be useful but for large adhoc network it can be problematic.

I have a contribution to the next meeting proposing that the ITU discuss the
security issues with regards to H.235.6 and MiTM attackes and propose the
group makes a decision on whether there is merit in developing a new H.235
standard. The really good thing with H.235 it supports end to end which
there is no equivalent in SIP.

Many years ago I developed an idea which I called eaRTP encryption and
authentication with RTP. The idea was to use PKI and the keys where
provisioned by the gatekeeper when registering. Most likely via a URI fields
in the RCF . The actual key generation is done separately when the account
is created.

When a call is placed the certificate is signed embedded and the first half
of the Diffie Hellman is sent in the clear.  The remote authenticates the
certificate and encrypts the reply Diffie Hellman with the certificate
supplied from the remote so only the caller can decrypt it. It would also
sign it's own certificate. This way each party is authenticated and only
half of the Diffie Hellman is exposed. If DH key sizes of 2048 bits or
greater are used (rather than the current 1024) it makes it very difficult
to derive the key to unlock the media streams. Moving to AES256 (rather than
current AES128) would assist greatly. BTW each media stream has its own
unique key so as long as that diffie hellman is large and is protected it
makes it very difficult to crack those keys. The other advantage is that
there is some backwards compatiblity and would work across any existing
H.323 network. TLS is not implemented other than with GnuGk.

I hope to have to have a lively discussion on the topic in Geneva next


-----Original Message-----
From: h323implementers-bounces at lists.packetizer.com
[mailto:h323implementers-bounces at lists.packetizer.com] On Behalf Of Jan
Sent: 23 September 2013 23:39
To: openh323gk-users at lists.sourceforge.net
Cc: h323implementers at lists.packetizer.com
Subject: Re: [h323implementers] [Openh323gk-users] [Openh323gk-developer]
Thoughts on H.323 encryption or Why your AES encryption might be worth

Simon Perreault wrote:
> Le 2013-09-23 15:09, Jan Willamowius a écrit :
> > GnuGk currently checks the certificates signature (either against 
> > your own CA or the public CAs you configure) and can also check if 
> > the IP the call comes from matches the certificate.
> The weak point here is, and has always been, the necessary PKI 
> infrastructure. Way too complex to set up and maintain.
> A way to untie this knot could be to use DANE, a protocol for 
> verifying TLS certificates using self-published DNSSEC records. No need
for a CA.
> There is this proposal for SIP, but one could easily imagine an H.323
> equivalent:
> https://tools.ietf.org/html/draft-johansson-dane-sip-00

I'd be happy to support DANE in GnuGk, but the current lack of PKI
infrastructure should not serve as an excuse not to implement TLS at all.

There are a lot of H.323 installations with a rather closed user group that
can happily live with their own private CA, except you can't get any
endpoints doing TLS at all...


Jan Willamowius, Founder of the GNU Gatekeeper Project EMail  :
jan at willamowius.de
Website: http://www.gnugk.org
Support: http://www.willamowius.com/gnugk-support.html

Relaxed Communications GmbH
Frahmredder 91
22393 Hamburg
Geschäftsführer: Jan Willamowius
HRB 125261 (Amtsgericht Hamburg)
USt-IdNr: DE286003584

More information about the h323implementers mailing list