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.
Related
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?
I'm working on a project involving Socket.IO that I'd like to add encryption to. It seems kinda wrong, but being able to add a standard way to tunnel a TLS socket through my protocol would be really helpful since mine is transport agnostic, and TLS is great for negotiating and creating secure sessions (a wheel I really don't want to have to reinvent).
Ultimately, you would have BCP inside TLS inside BCP (BCP is the name of my protocol). As ugly as that is, it would guarantee that any transport medium could easily upgrade to an encrypted connection within BCP, which is great considering I don't know ahead of time which transport Socket.IO will pick (also, futureproofing and providing options for other people using BCP, etc). I understand if this is a bad idea, or impossible from TLS being too low-level, but if it can be done or you have better alternatives I'd be happy to hear your thoughts.
In general, SSL/TLS doesn't care about transport and can work even on pigeon mail (if you have enough pigeons in the cage ;). Consequently you can run it over some transport other than TCP, and you can run anything over SSL/TLS.
If I got your problem right, look at how Explicit SSL mode is done in FTPS and in SMTP. Initially non-secured session is established, then STARTTLS command is sent, then SSL handshake takes place and finally the rest of communication goes on top of SSL. And all of this happens within single socket connection.
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.
I'm looking for options for securing UDP traffic (mainly real-time video) on a wireless network (802.11). Any suggestions apart from Datagram Transport Layer Security (DTLS)?
Thanks.
You must be more clear about the attacks you are trying to defend against. For instance if your only concern is spoofing then you can use a Diffie–Hellman key exchange to transfer a secret between 2 parties. Then this secret can be used to generate an Message Authentication Code for each packet.
If you need any more protection I strongly recommend using DTLS. It should be noted that all TLS/SSL connections can be resumed so you can cut down on the number of handshakes. Also, certificates are free.
Are you trying to wrap an existing application or writing your own? What client server setup do you have? Do you want to prevent snooping or tampering?
I am assuming here that you
are developing an application
are trying to prevent snooping
have access to client and server.
The simple approach is to use any off the self strong encryption. To prevent tampering use any signing algorithm with a private/public key scheme. You can use the same key pair for encryption and authentication.
The drawback of this approach is that it is on layer 7 and you have to do most of the work on your own. On the other hand, DTLS is a viable option...
Have you considered IPSEC? This article provides some good guidance on when and when not to use it.
You can look into ssh with port forwarding. That comes at the cost of maintaining a TCP connection over which the UDP traffic can be secured.
I heard that if you use port 443 (the port usually used for https) for ssh, the encrypted packets look the same to your isp.
Could this be a way to avoid traffic shaping/throttling?
I'm not sure it's true that any given ssh packet "looks" the same as any given https packet.
However, over their lifetime they don't behave the same way. The session set up and tear down don't look alike (SSH offer a plain text banner during initial connect, for one thing). Also, typically wouldn't an https session be short lived? Connect, get your data, disconnect, whereas ssh would connect and persist for long periods of time? I think perhaps using 443 instead of 22 might get past naive filters, but I don't think it would fool someone specifically looking for active attempts to bypass their filters.
Is throttling ssh a common occurrence? I've experienced people blocking it, but I don't think I've experienced throttling. Heck, I usually use ssh tunnels to bypass other blocks since people don't usually care about it.
443, when used for HTTPS, relies on SSL (not SSH) for its encryption. SSH looks different than SSL, so it would depend on what your ISP was actually looking for, but it is entirely possible that they could detect the difference. In my experience, though, you'd be more likely to see some personal firewall software block that sort of behavior since it's nonstandard. Fortunately, it's pretty easy to write an SSL tunnel using a SecureSocket of some type.
In general, they can see how much bandwidth you are using, whether or not the traffic is encrypted. They'll still know the endpoints of the connection, how long it's been open, and how many packets have been sent, so if they base their shaping metrics on this sort of data, there's really nothing you can do to prevent them from throttling your connection.
Your ISP is probably more likely to traffic shape port 443 over 22, seeing as 22 requires more real-time responsiveness.
Not really a programming question though, maybe you'll get a more accurate response somewhere else..