Any chance of getting this a version compiled for TLS included? I ask first because, IMO making a feature request should be after a discussion if it is even feasible.
Looking at the project page, it doesn’t seem like it would be a big deal. The distro uses openssl already, does it not? The required package is libssl and should reside in openssl-devel which is in the sng-updates repo.
I believe I asked about this possibility, and was told that the distro uses upstream packages as much as possible so getting native tls support was not likely. A former colleague, @mattschadt shared these install steps with me some time ago. None of the following is necessarily recommended, but on the very few occasions when I’ve done it, it worked for me:
# Install from source to enable openssl support
yum -y remove sngrep
yum install autoconf automake gcc git libpcap-devel make ncurses-devel openssl-devel pcre-devel
cd /usr/src/
wget https://github.com/irontec/sngrep/archive/master.zip
unzip master.zip
cd sngrep-master/
./bootstrap.sh
# configure flag - Feature
# ------------------ - ------------------------------------------------------------------
# '--with-openssl' - Adds OpenSSL support to parse TLS captured messages (req. libssl)
# '--with-gnutls' - Adds GnuTLS support to parse TLS captured messages (req. gnutls)
# '--with-pcre' - Adds Perl Compatible regular expressions support in regexp fields
# '--enable-unicode' - Adds Ncurses UTF-8/Unicode support (req. libncursesw5)
# '--enable-ipv6' - Enable IPv6 packet capture support.
# '--enable-eep' - Enable EEP packet send/receive support.
./configure --with-openssl
make
make install
sngrep -k /etc/asterisk/keys/default.key
I definitely support this. Because the less that is different, the faster things can stay up to date with upstream security updates.
I wonder if this would be a worthy exception because of the prevalence of audits starting to be forced on everyone with blanket requirements.
I recently dealt with a client that was failing an automated external PCI scan from their bank because they had port 5060 on UDP instead of TLS.
In that case I showed they network guy how to not whitelist the PCI scanner for 100% of the inbound everything. I also recommended (again) they upgrade their PBX. We shall see how that goes.
But the point is with external forces pushing requirements, people will start turning these features on more and more. I use sngrep all the time when doing basic troubleshooting and it would certainly be way more convenient if it was natively supported.
I realize that’s an old ticket but newer tickets about TLS decryption “not working” are referring back to that one.
As I understand it, this won’t let you capture TLS 1.2. I tested it out in my home lab. Configuring FreePBX to allow TLS 1.0 and up, only my ancient Obi 110 set for TLS shows up in the capture.
If they’re using modern forms of TLS in order to meet requirements, sngrep will probably not be useful in decryption mode. Other ideas might be to use Asterisk’s pjsip logger / sip debug, or have Asterisk do EEP mirroring (Examples: Asterisk · sipcapture/homer Wiki · GitHub) which you can then pick up with sngrep.
I’m hoping that perhaps within the next year we’ll have the ability to just output pcap files via an option in the PJSIP packet logger, before decryption and encryption occurs, to make it easier to look at things. I don’t know if it’ll happen though but I’d like to see it.
