- h323implementers - lists.packetizer.com

NSA H.323 surveilance
by Jan Willamowius 14 Mar '14

14 Mar '14

Hi, The Intercept just published a few very interesting slides how the NSA intercepts H.323 (and SIP and Skype) VoIP traffic: https://firstlook.org/theintercept/document/2014/03/12/vpn-voip-exploitatio… Notice how the HAMMERSTEIN component on page 4 "processes" the call signaling as man-in-the-middle. This would pretty much match the attack I have been warning about previously when I wrote "Why your AES encryption might be worth nothing". http://www.gnugk.org/h323-encryption.html Another interesting fact seems to be that they targeted H.323 and SIP before taking on Skype (bottom of page 2). Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan(a)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

2 2

GNU Gatekeeper 3.5 released
by Jan Willamowius 02 Jan '14

02 Jan '14

Dear community, I'm happy to announce the release of GNU Gatekeeper version 3.5. The new version brings a number of new features as well as a number of important bug fixes and a few changes in configuration options. As usual, you can download the source code and executable for Linux, Windows, FreeBSD, OpenBSD, NetBSD and Solaris from http://www.gnugk.org/h323download.html Regards, Jan New features: - implement H.460.22 to negotiate the use of TLS - language based routing (using the upcoming H.323v8) - new command line switch -mlock to prevent GnuGk from being swapped out - new section [ModeVendorSelection] to set proxy mode based on endpoint vendor support for challenge/response authentication using DES-ECB, eg. from Avaya endpoints - new switch [RoutedMode] FilterEmptyFacility= (Avaya interop) - new switch [RoutedMode] ProxyHandlerHighPrio=0 to avoid setting the proxy handler to high priority; needed to run GnuGk on certain virtualization platforms - print number of proxied calls and peak number of calls in statistics on status port - new switch [RoutedMode] H46023ForceNat - new switch [RewriteSourceAddress] TreatNumberURIDialedDigits - more detailed codec descriptions in %{codec} and Radius attribute - process multiple terminal-alias VSA from Radius - extend [GkStatus::Message] for URQ Configuration changes: - changed default call signaling port from 1721 to 1720 - replace H235HalfCallMediaStrength= switch with H235HalfCallMaxTokenLength= - disable use of SHA1 for TLS by default, the new switch [TLS] CipherList= can be used to customize the cipher selection And a number of bug fixes (see changes.txt for all the details). -- Jan Willamowius, Founder of the GNU Gatekeeper Project 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

1 0

H323 call in a bash script
by Michael A Hawkins 07 Nov '13

07 Nov '13

I am new to H323+ so please forgive me if this has been asked before. I would like to be able to make dial a number to an H323 gateway in order to turn message waiting indicator on and off for some SCCP phones. Does H323+ provide a mechanism whereby I can initiate a H323 call from inside of a bash script? Michael A Hawkins 203-550-5502 This email and any attached files are confidential and are intended solely for the use of the intended recipient(s). If you received this email in error, please notify the sender and delete the email and attachments.

2 1

Re: [h323implementers] [Openh323gk-users] [Openh323gk-developer] Thoughts on H.323 encryption or Why your AES encryption might be worth nothing
by Jan Willamowius 23 Sep '13

23 Sep '13

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... Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan(a)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

2 2

Re: [h323implementers] [Openh323gk-users] [Openh323gk-developer] Thoughts on H.323 encryption or Why your AES encryption might be worth nothing
by Jan Willamowius 23 Sep '13

23 Sep '13

Simon Perreault wrote: > Le 2013-09-23 13:25, Hani Mustafa a écrit : > > Most vendors (including aforementioned vendors) have mostly just hoped > > that the entire industry is going to move to SIP and also placed their > > bets there, hoping that all the security problems with H.323 > > authentication would go away. > > [...] > > As long as nobody verifies TLS certificates, I don't see how the > situation can change for either SIP or H.323. Exactly my point: Lets use TLS and check the certificates as closely as we can. 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. Everybody is invited to check the source code if I do it right and is encouraged to implement similar checks in other endpoints, gateways or gatekeepers! See Toolkit::MatchHostCert() in Toolkt.cxx http://openh323gk.cvs.sourceforge.net/viewvc/openh323gk/openh323gk/Toolkit.… Regards, Jan -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan(a)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

1 0

Thoughts on H.323 encryption or Why your AES encryption might be worth nothing
by Jan Willamowius 23 Sep '13

23 Sep '13

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. -- Jan Willamowius, Founder of the GNU Gatekeeper Project EMail : jan(a)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

1 0