I set up a GNS3 topology with Asterisk and 2 softphones (Blink) and i tried to enable secure calls.(https://wiki.asterisk.org/wiki/display/AST/Secure+Calling+Tutorial)
TLS works, SRTP don't work .
In my Asterisk (last version), SRTP module is enable and running (https://imgur.com/HOlFFlH). Pjsip.endpoint.conf have "media_encryption = sdes" in GUI looks like this https://imgur.com/IAQM1Qt.
The the softphones configuration is this - https://imgur.com/NbjFqFG
[100]
type=endpoint
aors=100
auth=100-auth
tos_audio=ef
tos_video=af41
cos_audio=5
cos_video=4
allow=ulaw,alaw,gsm,g726,g722
context=from-internal
callerid=CEO <100>
dtmf_mode=rfc4733
transport=0.0.0.0-tls
aggregate_mwi=yes
use_avpf=no
rtcp_mux=no
ice_support=no
media_use_received_transport=no
trust_id_inbound=yes
media_encryption=sdes
timers=yes
media_encryption_optimistic=no
send_pai=yes
rtp_symmetric=yes
rewrite_contact=yes
force_rport=yes
language=en
What seems strange to me is that although encryption is SDES mandatory, I can make calls, even if traffic is UDP.
https://imgur.com/8K370Ia It looks as if the settings in the asterisk match the ones on the softphone, but the traffic is not encrypted.
Where am I wrong? What am I missing? Thank you!
SRTP is function of endpoint.
So ALL your endpoints SHOULD support SRTP.
I think i found the answer.
In wireshark I enable RTP over UDP (rtp_udp) and now i see RTP trafic instead of UDP. When i listen the call is only noise, so is encrypted, but why wireshark don't show me SRTP traffic?
Related
I want to use netsed to alter the incoming SIP traffic (UDP port 5060) on a PBX server which is running on a linux system (debian 10 stretch).
In the first step I simply tried to set up the phone to connect to UDP/5061 and started netsed with that command:
./netsed udp 5061 127.0.0.1 5060 s/profile-level-id=4280D/profile-level-id=42800D
The traffic was intercepted, changed and forwarded to port 5060 of the PBX software.
Unfortunately, the SIP protocol "notices" that the port used by the phone does not match the PBX (the pbx is using 5060 and the phone is using 5061 because of the port forwarding). Now the question is how to do this with netsed.
So the question is how to create a transparent proxy on the same system as the pbx.
Or is there a way to listen with netsed already on port 5060, but then pass it on to the pbx software on port 5060?
The deeper background is the Mobotix door phones for outgoing calls that do not correctly encode the profile-level-id field (it should be six base16 characters long but is five characters long). My idea was to simply change the profile-level-id as soon as the SIP-Invite enters the PBX.
Same question at StackExchange.
If I do not misinterpret your idea ; and I thing a quite interesting one ; you are trying to set up an transparent application IP proxy using netsed. From that experiment, the straightforward solution does not fit because SIP protocol "notices" that 'netsed' is altering the data-path.
Some points to be aware of :
By itself, SIP does not work via NAPT as the transferred data
contains IP addresses and port numbers.
Moreover taking aside TLS, SIP is transport protocol agnostic which
mean that a SIP session is authorized to use both UDP and TCP at the
same time.
I suggest you to have a look to SIP proxy, SBC B2BUA and STUN in order to build a correct understanding of all these issues, seem to be a hard path but valuable.
Or you can take inspiration of SIP proxy and implement minimun SIP proxying functionality into netsed. It is interesting but not so easy.
But if you abandon your initial idea of 'basic' proxy then you could use a SIP toolbox like [kamalio][1]. It is a known way of doing SIP related plumbing but obviously very far your initial goal.
Hope this help.
I'm not quite sure how the firewall can tell what transportation is being passed - TCP\UDP?
also - when I have statefull VS stateless FW - I know that there is the difference when using TCP, but what about UDP?
thanks alot! :)
Have a look at https://en.wikipedia.org/wiki/IPv4#Header and see the Protocol field.
The header of the packets are completely different, TCP is much bigger for example. A stateful firewall needs to intercept the TCP headers to map the packets to its state table, but also stateless firewalls sometimes have techniques implemented to recognize valid TCP or UDP headers. Most home routers (broadband/wireless) make use of this when you are using port forwarding to distinguish between both protocol versions.
I'm looking for a transparent SSL/TLS proxy tool to capture (and change?) generic SSL/TLS traffic (man-in-the-middle attack). Basically something that can generate certificates on the fly with its own CA. In a way, I'm looking for something like mitmproxy, but for non-HTTP(S) traffic. Any suggestions?
I found a tool called SSLsplit that I believe does the trick. I did not have the time to test it yet, but the man page looks like it can do plain TCP/SSL sockets.
If anyone finds this post in 2021 like I did. Mitmproxy now supports tcp mode so your application layer traffic need not be http.
I'm developing a SIP mobile softphone, customer needs a complete hiding of SIP messages from softphones to SIP servers as VOIP calls are regionally prohibited, however using TLS connection was not sufficient since the message headers are easily recognized as a SIP message. What are the best common alternative?
what about openvpn, IPSec tunneling?
Transmitting SIP over TLS means the SIP headers will only be viewable if someone is able to compromise your TLS keys, i.e. it's highly unlikely unless some national security agency is on your case.
What you might be encountering is port 5061 being blocked since it's the default and therefore well known SIP TLS port. To get around that simply use a different port for your SIP TLS connection. As far as anyone viewing the traffic goes if it's not suing port 5061 they won't have any idea that SIP is being used in your TLS stream.
Of course you also need to consider the RTP traffic which is what will carry the audio part of the call once SIP has set it up. There are no standardised ports for RTP but some popular VoIP softswitches do use certain ranges by default. For example Asterisk uses UDP 10,000 to 20,000. To work around that you'd really need to use SRTP but that's going to be harder to set up since not that many SIP user agents and servers support it. It will also be easier to detect for someone watching your traffic since even without knowing the contents the profile of RTP packets would be detectable. Still it's likely to need a sophisticated entity monitoring your traffic to detect a VoIP call using SIP over TLS on a non-standard port and SRTP call amongst the general noise of internet traffic.
Here my Problem:
If I am connected to a network (so I know the WPA/WPA2-PSK), I´d like to be able to decrypt the traffic I capture from other devices in the network.
(If WEP is used, tcpdump does this automatically).
As far as I know, WPA uses something like a session key for each client in the WiFi - but I know this is possible - so I´m wondering HOW to do this. (If this is not possibile with tcpdump, how to do this "by hand"?)
Thanks for any help!
I've written a small, open source, application that does exactly this.
If you capture the traffic with tcpdump and can save it to file you should be able to use Wireshark to decrypt it on a PC/Mac. You need to catch the association traffic and the four-way handshake and configure Wireshark with the PSK.
TamoSoft has CommView for WiFi product which does what you need. As far as I know, decrypting WPA is a tricky task, and this is what they charge for.