There are many VoIP services that provide ID-spoofing functionality
Jumblo: Create an account and add some credit to it (10 Euros minimum excluding VAT), then install their Android app, login, the go to Settings and choose "Add Caller ID" then add the number. (Requires SMS verification) *
Skype: You can create an online number (15 Euros minimum) ...
Browsing through the source on GitHub, one learns that it uses ZRTP.
From What are the vulnerabilities of VOIP-specific security protocols? :
Prateek Gupta, Vitaly Shmatikov (2006) Security Analysis of Voice-over-IP Protocols
We also demonstrate a man-in-the-middle attack on ZRTP which disables authentication and allows the attacker to impersonate a ZRTP ...
Mumble's home page states it uses public-key cryptography. This is done by using the TLS protocol, which is mentioned in the FAQ.
With public-key cryptography, the private key is always known by the server. Thus, a Mumble server administrator indeed has access to the private key - usually in the form of a X.509 certificate - which can be used to decrypt the ...
I'll have disagree with AJ's answer. When making a RedPhone call you're first authenticated by one the authentication servers and then a relay server handles connecting you to the call recipient. All of these communications are encrypted.
Since the caller isn't directly connected to the recipient (most you need NAT traversal on mobile data networks) , your ...
When the call is coming from an external PBX, then the Caller ID you receive is what the caller's service provider sends to your service provider. This could by anything the caller's service provider wants. Many service providers choose to respect that and send the real Caller ID to your service provider (and eventually, to you).
Many SIP / VOIP service ...
The STIR IETF charter group is working on this problem now. (Literally right now, join the Jabber or listen) Namely this article highlights the need for CallerID due to
Former solutions include:
RFC 4474 defines SIP "Identity", however this isn't compatible with existing deployments so it hasn't been used. RFC447bis ...
Caller ID is always insecure, VOIP Caller ID is no more insecure than any other. If you want to know for sure who the caller is, you have to do a trace rather than trust the included information. Caller ID is kind of like politely asking someone for their name, they don't have to tell you the truth.
Payload encryption means they can't know what the communication content is, but in some cases they can still know what protocol you're using (In this case Skype). This is how countries block Tor, for example.
Methods to detect the protocol being used even if it's encrypted:
IP-based: TCP is not encrypted even if the payload is encrypted (So that computers ...
Redphone is not designed to prevent meta-information capture. It still is possible for someone monitoring to figure out who you are talking to and how long you talked since no onion routing or similar system is implemented by it. However, it should protect the security of the contents of your communication since the encryption keys are unknown by anyone ...
There is something between the scanner and the target that is responding on behalf of the target, spoofing its source address so as to appear to be the target itself. When you ran the Nmap scan as root with --reason -v, it showed the IP Time-to-Live (TTL) values of the response packets for each port:
PORT STATE SERVICE REASON
21/tcp open ftp ...
Putting findings in an answer instead of comments seems to be the best approach.
As usual, turns out this has been discussed before. A quick search on CiteSeerX gave 50 papers, however not quite up-to-date:
Angelos D. Keromytis (2009) Voice over IP: Risks, Threats and Vulnerabilities
Prateek Gupta, Vitaly Shmatikov (2006) Security Analysis of Voice-over-IP ...
The simple answer is that this is not considered a vulnerability - the protocol stack is not designed to authenticate the caller.
From @schroeder's Wikipedia link on Caller ID:
Additionally, nothing ensures that the number sent by a switch is the actual number where the call originated; the telephone switch initiating the call may send any digit string ...
Considering every VOIP phone is different, it's kind of hard to standardize depending on where the storage module is located.
There are companies who are specialized in hardware destruction, opting for performing destruction yourself can be very very tricky. Should you be able to locate the storage module you could use the Guidelines for Media Sanitization ...
A TeamSpeak identity is simply an ECC key pair for the NIST curve ECC-256 as generated by the libtomcrypt library, together with a counter value that is a 64-bit unsigned integer.
The security level makes use of a classical Proof-of-work system.
Let PUBLICKEY be the base64-encoded string of the identity's ASN.1 DER encoded public key. Further, let COUNTER ...
Skype apparently had some known vulnerabilities, but most are old:
You might also be interested in reading Skype's security page
Without going ...
Whatsapp uses specific ports including: 5223, 5228, 4244, 5242, 5222. By monitoring packets to these ports, it is very easy for a packet filter to figure out which clients are trying to conduct a Whatsapp session. The problem is made easier because Whatsapp uses TCP, a sequential protocol. Using this protocol makes it even easier to target and interrupt.
The method that is used is based on hashcash. http://en.wikipedia.org/wiki/Hashcash
Hashcash is a proof-of-work system designed to limit email spam and denial-of-service attacks.
Ethereal was renamed Wireshark back in 2006 due to trademark issues.
Ethereal/Wireshark is just a packet capture tool with a GUI front end, there are many packet capture tools available. As to intercepting particular traffic, that would depend on particular network architecture and/or various attack methods that end up being a man in the middle.
I think there are many factors that could make it a legitimate request:
other people in the home who might need network segregation
old equipment (getting a newer modem)
I, myself, have made the same request to a certain remote employee to ensure separation of use within that employee's home. Sometimes it's simply to ...
I wonder whether using a relay server in the middle doesn't actually add a layer of privacy since it would be less obvious where the packets are being sent - all packets would go to the server instead of being sent straight to the other device.
It adds different kinds of privacy. You have (mainly) two kinds of privacy here:
Privacy from provider
A secured phone line would indicate that there is encryption in place. This would be similar to how we do encryption in networks using TLS, etc. The line on it's own would not typically be encrypted, but the data flowing over the line would be encrypted. Typically, there is encoding software/hardware built into the phone units or you could encrypt the data ...
This option basically allows registered hosts to call without re-authenticating. According to this article:
Never include the parameter “insecure=invite” or “insecure=very” when
defining a dynamic SIP user account. If you do, it will disable
password checking for that account. Where possible, restrict the range
of IP addresses from which the user ...
I think both posters are correct. Skype will or will not make a direct connection. For example, if you are sitting next to each other with a friend, go online in Skype and transmit a file between both of you. You should notice amazingly fast transmission speed, as Skype detects that you are located on the same network and therefore it makes a P2P connection.
I can't tell for sure. But if you are looking for a similar feature I would implement it as following:
An ID contains a private and a public part (That's what Teamspeak does). So I guess it's some asnyc encryption key you can generate yourself.
Now just generate a sequence of numbers e.g. s = [1..n] and hash them.
As soon as the first M bits of the ...
NIST has created SP 800-164, "Guidelines on Hardware-Rooted Security in Mobile Devices".
It is a document that discusses not only the destruction of the device, but other security features that you should be considering, including remote wipe, certificate management, device integrity, using isolation to address various threats, key storage, BYOD, etc.
To block VoIP, you don't need to know what the content is. VoIP packets do have certain characteristics/behaviour (length, frequency) that are identifiable with or without encryption, also known as Heuristic Classification. This pro-DPI article touches the surface: http://www.telecoms.com/39718/encryption-will-it-be-the-death-of-dpi/
Adding to Stevens correct answer:
chat is indeed TLS encrypted and voip via OCB-AES but both channels are only server-client as opposed to end-to-end, i.e. the server (operator) has in principle access to all clear text and voice running through the server.
Hence I run my own server (setup is really ...
You are right in the fact that securing SIP communication is not sufficient.
RTP has got SRTP as his secured counterpart, so you may use
SIP over TLS to secure the control channel communication,
SRTP to encrypt the data channel communication (SRTP will need to rely on another protocol, like ZRTP, to securely exchange the keys/ More information can be found ...