ISO Consensus papers present the expert security perspective of the Information Security Office staff at the University of Texas at Austin.
Skype is communications software that allows users to communicate with each other in real time using voiceover IP (VoIP), video chat, or more traditional text chat. It is unique among other instant messaging (IM) applications in that Skype runs over a decentralized peer-to-peer (P2P) network rather than routing all communications packets through a central server or cluster of servers. Skype is designed to work out of the box on modern networks, and has no problems working behind Network Address Translation (NAT) devices or other firewalls. Because of its decentralized architecture, Skype uses strong encryption extensively, making casual eavesdropping or impersonation all but impossible.
Many network and systems administrators take a dim view of Skype because experience with the software has shown that it can be a bandwidth hog. Other administrators fear that Skype's inherent ability to traverse firewalls is a security risk. And some administrators feel the combination of Skype's encryption and its binary-only, closed-source nature make it a black box, or complete unknown that has no place being on a well-maintained network. While these are all valid concerns, they should be considered in the context of local network policies and weighed against the benefits that Skype can provide. In many cases, running Skype in a well-managed environment can mitigate these risks.
The purpose of this paper is to suggest best practices and recommendations when running Skype. Although Skype is available for myriad different hardware platforms, this document will focus on the Mac, Windows, and Linux environments. Unfortunately, many of the management features available to systems administrators are available only for Skype running on Windows.


  • Skype Client—Collective term for the system and the software being used to run the user-facing Skype application.
  • Super Node—A Skype client that has a public IP address and enough spare CPU cycles, RAM, and bandwidth to take on additional duties for the Skype P2P network. Super nodes hold a portion (up to several hundred users) of the distributed Skype directory. Although they accept and reply to directory queries from other Skype users, super nodes do not actually relay communications content (voice, video, chat, etc.) for other users. According to the Skype Guide for Network Administrators (Skype, 2006) super nodes are restricted from using more than 5KBps (kilobytes per second) of bandwidth.
  • Relay Host—A Skype client that has a public IP address and enough spare CPU cycles, RAM, and bandwidth to relay Skype content for other Skype users who are behind restrictive firewalls or are otherwise unable to communicate with each other directly. Although it is theoretically possible for a relay host to relay communications traffic for more than one session at a time, Skype claims that this is not commonly seen in practice. The Skype application places limits on how much bandwidth can be consumed by a relay host (Skype, 2006):

– File Transfer: 3KBps

– Voice Call: 4KBps

– Video Call: 10KBps

  • Skype Login Server—The only centralized piece of the Skype network. This collection of servers handle user authentication and manages the creation of Skype usernames.

Major Points

Skype has the potential to be a bandwidth hog, but high bandwidth consumption while the user is not actively using Skype can be mitigated through changes in configuration or deployment. Provided that mitigating steps are taken, bandwidth consumption while the user is actively using Skype is not unreasonable.
Although the core technologies used in Skype have not had a known security vulnerability in years, Skype still presents an attack vector for spam, phishing, or the transfer of malicious code by way of traditional social engineering. However, these attack vectors already exist on users' systems in e-mail clients, Web browsers, or other IM applications. Skype's functionality makes it no more or less inherently secure than other network communication applications. Skype may, however, be a more attractive target to phishers as some Skype users use paid services such as Skype-Out and Skype-In (the ability to dial out to a land line or to receive calls in from a landline, respectively). In this way, Skype accounts are actually tied to monetary value via PayPal.
Skype has a publicly available API and third parties can write applications to take advantage of Skype's functionality at the user level. Arguably, the most noteworthy examples of these applications are the viruses and worms that occasionally make their rounds on the Skype network. The overwhelming majority of these can be defeated with simple security measures such as user education (don't click the link that comes to you unexpectedly, especially if it's from someone you don't know) and up-to-date anti-virus software. Additionally, users of Skype on Windows can edit a registry key to disable third-party applications from using the Skype API.
Skype's encryption of communications is secure enough to prevent casual eavesdropping and it provides a measure of non-repudiation in that unless a user's credentials (username and password) have been compromised, it is nearly impossible to impersonate another user.
Although the network-based security threats that Skype can present can be mitigated through secure deployment and configuration, it still presents the very real threat of data leakage and information disclosure. In network environments that are subject to strict communication regulations, Skype presents a simple to use, highly encrypted channel for sensitive data exfiltration that can be difficult to detect and hard to block. Administrators who manage systems and networks that are subject to legal and administrative communication regulations may want to prohibit Skype to reduce the risk of unauthorized communications.
In less restrictive network environments, such as higher education networks, Skype is an attractive alternative to using traditional telephone service for costly long-distance calls, particularly when collaborating with colleagues in other countries.
Skype should not be relied on for strong anonymity. Although it uses encryption to protect its network traffic, if this traffic is captured, it is trivial for the certificate owners (Skype and its parent company eBay) to decrypt the traffic. Additionally, Skype takes no measures to hide its presence on the system it's running on. It is easy for a forensic analyst to discover the presence of Skype and to enumerate a user's contact list, among other details. Unless configured to use a proxy (a feature that is native only to the Windows versions of Skype at the time of this writing), the direct peer-to-peer nature of Skype communications traffic indicates the IP address of the sender or receiver; in many cases this could lead to identification of either party.
Skype is designed to easily traverse firewalls and works fine behind a NAT firewall. This feature makes Skype extremely difficult to block with a traditional perimeter firewall. Even in very restrictive network environments, if either HTTP or HTTPS traffic is allowed, Skype will use port 80 or 443 for its traffic.
Although Skype excels at getting around restrictive firewalls, it does not modify the firewalls or their rules themselves in any way. With the exception of a host-based firewall, it does not require specific ports or port ranges to be opened on the perimeter/NAT firewall. Skype does listen for connections using an arbitrarily designated port. This can be specified during installation, or otherwise Skype will select one at random.
On NAT firewalls that prohibit inbound TCP and/or UDP connections, two Skype clients are still able to communicate directly to each other thanks to the coordination of their super nodes. Incoming call information is passed to a Skype client from its super node, causing the client to initiate an outbound UDP "connection" to the other Skype client which does the same thing at the same time. Now each firewall has an outbound "connection" state in its tables and will allow incoming UDP from the outside Skype client. (UDP is a stateless and connectionless protocol, but many stateful firewalls treat outbound UDP packets as if they are part of a session and will allow incoming subsequent UDP packets in, provided that they are from the same source IP and port as the UDP packet that was sent.)
Although Skype's encryption makes it impossible to detect the contents of a user's communications on the network, and its firewall traversal abilities make it extremely difficult to filter at a border firewall, use of Skype can be detected on a network and it can be blocked by an Intrusion Prevention System (IPS) or other reactive Intrusion Detection System (IDS), or an ambitious administrator.
Skype does an excellent job of getting around restrictive firewalls and obfuscating the contents of its communications, but it does not represent a secure computing platform, nor is it a secure storage platform (Skype, 2600). Text-based chat sessions are logged by default, and information such as contact list entries, IP addresses, and Skype cookie information are all kept on the client systems with little, if any, obfuscation. On Windows systems, this data is kept in C:\Documents and Settings\username\Application Data\Skype and on Mac OS X systems, in /Users/username/Library/Application Support/Skype. In Linux, this data is kept in ~user/.Skype/
The Skype application is very much an opaque black box. The code itself is not open source; it is distributed as a binary only, which uses packing and other obfuscation methods to defeat reverse engineering. Skype will detect when certain debuggers are running in the operating system and cease to function in an attempt to protect itself from prying eyes. It can be very difficult to know exactly what Skype is doing on your system, or what data about your system is being transmitted to super nodes and login servers. Users with extreme paranoia to satisfy may want to run Skype on a dedicated system or not at all.


Network Utilization
Skype's P2P network architecture means that where possible, users will be sending data streams directly to and from each other. This is easy to imagine where each host has a publicly facing IP address and communications are unfettered by restrictive firewalls. As noted above, in cases where users are behind a firewall or are otherwise using Network Address Translation (NAT), direct communication is still frequently possible even if inbound UDP packets are restricted to existing "sessions" initiated by the internal host. If both users are behind firewalls that prevent all outgoing UDP traffic, Skype will send its conversations using TCP through a third host that is publicly addressable. Such hosts are known as relay hosts.
The use of relay hosts causes consternation among many network and systems administrators, as this functionality means that Skype is consuming network resources even when the end user is not using the Skype application. Although Skype has self-imposed limits on how much bandwidth it can consume, many administrators feel that this background bandwidth consumption is inappropriate and fear that unchecked use of Skype will lead to inordinate bandwidth use. This behavior can be mitigated (or stopped altogether) during deployment or subsequent configuration of Skype.
Skype's end-user license agreement (EULA) addresses this relay host functionality in the following clause:
"Utilization of Your Computer. Skype Software may utilize the processor and bandwidth of the computer (or other applicable device) you are utilizing, for the limited purpose of facilitating the communication between Skype Software users. Skype Software will use its commercially reasonable efforts to protect the privacy and integrity of the computer resources (or other applicable device) you are utilizing and of your communication, however Skype cannot give any warranties in this respect."
Some institutions prohibit Skype specifically because of this clause. Some administrators and legal counselors will advise prohibiting Skype because this functionality means that a third-party, for-profit company is using university resources for the express purpose of furthering their commercial enterprise.
It is the informal opinion of The University of Texas at Austin's legal counsel that this behavior is not fundamentally different from most other network applications that are developed and supported by commercial interests. For example, consider a user surfing the Web and being subject to advertisements on a Web site, or someone who uses Yahoo Mail and has an advertisement automatically appended to his or her e-mail. Many other IM applications (and indeed many other network applications) are supported by the use of in-line advertisements.
Some protest that when agreeing to the EULA, the end user agrees to let Skype use resources that he or she has absolutely no authority over, and that this alone is reason to prohibit its use. The university's legal counsel informally tells us that this should not be a concern: since the user has no authority over the resource he or she is granting access to, the authorization is not binding or relevant. It would be comparable to this author granting you, the reader, unrestricted access to my transoceanic canal in Panama.
For those wishing to eliminate the possibility of a Skype client becoming a super node or relay host, the simplest solution is to place the host behind a NAT firewall or otherwise restrict its ability to be publicly addressed. If other Skype users cannot see the host directly, the super node and relay host functions will simply not work and the host will remain a regular Skype client with no additional functionality.
For Windows systems, Skype's functionality can be managed at a number of levels. Skype configuration and policy settings are maintained in the following hierarchy:
  1. HKEY_LOCAL_MACHINE Registry Keys
  2. HKEY_LOCAL_USER Registry Keys
  3. XML config files in C:\Documents and Settings\user\Application Data\Skype\
  4. Skype client user preferences and default settings
As of the 3.0 version, Skype can use Group Policies so administrators can make system management changes to sets of enterprise users. The Skype Administrative Template can be found at http://www.skype.com/security/Skype-v1.5.adm.
See the appendix for a complete list of registry entries and configuration parameters that can be employed to help secure the Skype client when run on Windows systems.

Practical Advice and Real World Recommendations

To more securely use Skype requires at the minimum a few configuration changes from the default settings. Unfortunately, many of these settings can only be modified on Windows systems via the registry.
The most basic configuration change that can be made is to limit communications to only those people in a user's contact list. This will stop unsolicited communication and will stop most spam and phishing attempts made over Skype. This configuration change can be made regardless of the platform on which Skype is running. It is highly recommended. Note that this change can be overridden when a user sets his or her presence to "SkypeMe". In this mode, invitations to chat can be accepted from anyone on the Skype network.
  • Disable the Skype API—If third-party applications are not allowed to use Skype, then viruses and worms will be prevented from using it as a transmission and attack vector. This configuration change can be made in the Windows registry.
  • Disable File Transfer—This setting makes sense for most managed deployments and will reduce the risk of data exfiltration. This setting can also be changed in the Windows registry. When file transfer is enabled, Skype users can transmit files of up to 2GB in size directly to and from each other.
  • Disable HTTP Ports—This will stop Skype from listening on TCP ports 80 and 443 and will assist in keeping bandwidth consumption by your Skype client low. Note: when Skype is run by a user without administrative (root) privileges on Mac OS X or Linux, the Skype client will not listen on these ports as non-root users cannot open listening ports below 1024. Not listening on these ports will make it less likely that your Skype client becomes a super node or relay host.
  • Disable Super Node—If it's not possible to put the Skype client behind a NAT firewall, you can still stop Skype from becoming a super node by making this registry change. Super nodes don’t consume as much bandwidth as relay hosts, but they still handle a significant chunk of Skype’s P2P signaling traffic.
  • Disable TCP Listen—This appears to be the relatively undocumented silver bullet that will without a doubt prevent your Skype client from becoming a bandwidth-devouring relay host. If the client is unable to accept incoming TCP sessions (those that are not associated with an outgoing TCP connection), then it will be unable to route other Skype users' traffic at all. It will still make outgoing TCP connections, and will still maintain a TCP session with its designated super node, but it will not route communications content for anyone other than the end user sitting at that system. This is another change that is available only via the Windows registry. Linux and Mac OS X users can use their operating system's firewall to achieve the same results by blocking inbound TCP connections to the listening port designated in Skype's configuration files.
The Skype client is more than just the user-facing GUI application. It is a P2P application that will continue to operate on the P2P network long after the end user has closed the application. In Windows, this is most evident by the Skype icon sitting in the Systray. Users should be educated so they know that unless they fully quit the application, Skype will continue to consume computing and network resources.  


Skype stands alone among VOIP applications due to its peer-to-peer network architecture and its extensive use of strong encryption of not only communications content but signaling traffic as well. The application itself and its network communications are extremely resistant to reverse engineering, making Skype activity difficult to detect and its communications impossible to decipher. For networks that are subject to strict legal or administrative regulations, Skype should be banned to prevent unauthorized communications. For more open networks, Skype can be a boon for end users who want to communicate with colleagues on another side of our rapidly shrinking world. Since Skype is a communication application, users will always be subject to unsolicited messages and end-user education is recommended to ensure that bogus links sent by unknown correspondents don't result in system compromises.

Appendix: Registry Entries and Configuration Settings for Skype Clients on Windows

The following is a list of configurable policies for the Windows Skype Client that can be managed via Group Policy Objects (Skype, 2008)"
DisableFileTransferPolicy—Disables file transfer to prevent the user from sending and receiving files using Skype.
DisableContactImportPolicy—Disables import contacts.
DisablePersonalisePolicy—Disables personalization to prevent the user from changing sounds.
DisableLanguageEditPolicy—Disables language edit to prevent the user from editing language strings.
WebStatusPolicy—When enabled, always publishes the user's status on the Web as Skype buttons. When disabled, prevents the user from publishing status on the Web.
DisableApiPolicy—Disables the Skype Public API to prevent third-party applications from accessing Skype functionality.
DisableVersionCheckPolicy—Disables new version checking by preventing Skype from detecting new versions and updates.
MemoryOnlyPolicy—Runs in memory-only mode so Skype does not store any data on the local disk.
ListePortPolicy—Sets the listening port where Skype listens for incoming connections.
ListenPort—Listening port number.
ListenHTTPPortsPolicy—When enabled, listens on HTTP (port 80) and HTTPS (port 443) ports. When disabled, does not listen on HTTP/HTTPS ports. When not configured, lets the user decide.
DisableTCPListenPolicy—Disables listening for TCP connections to prevent the Skype client from receiving incoming TCP connections.
DisableUDPPolicy—Disables UDP communications to prevent the Skype client from using UDP to communicate with the network.
DisableSupernodePolicy—Prevents the Skype client from becoming a super node or relay host.
ProxyPolicy—Establishes the proxy policy.
ProxyType—Establishes the proxy type.
ProxyAddress—Proxy address (host:port)
The following is a list of configurable registry entries that apply to the Windows Skype Client as taken from the Skype Guide for Network Administrators (HKLM is short for HKEY_LOCAL_MACHINE) (Skype, 2008):
HKLM\Software\Policies\Skype\Phone, DisableApi, REG_DWORD = {0,1}
HKLM\Software\Policies\Skype\Phone, DisableFileTransfer, REG_DWORD = {0,1}
HKLM\Software\Policies\Skype\Phone, MemoryOnly, REG_DWORD = {0,1}
HKLM\Software\Policies\Skype\Phone, DisableContactImport, REG_DWORD = {0,1}
HKLM\Software\Policies\Skype\Phone, DisableVersionCheck, REG_DWORD = {0,1}
HKLM\Software\Policies\Skype\Phone, DisablePersonalise, REG_DWORD = {0,1}
HKLM\Software\Policies\Skype\Phone, DisableLanguageEdit, REG_DWORD = {0,1}
HKLM\Software\Policies\Skype\Phone, ListenPort, REG_DWORD = {0,1}
HKLM\Software\Policies\Skype\Phone, ListenHTTPPorts, REG_DWORD = {0,1}
HKLM\Software\Policies\Skype\Phone, DisableTCPListen, REG_DWORD = {0,1}
HKLM\Software\Policies\Skype\Phone, DisableUDP, REG_DWORD = {0,1}
HKLM\Software\Policies\Skype\Phone, DisableSupernode, REG_DWORD = {0,1}
HKLM\Software\Policies\Skype\Phone, ProxySettings, REG_SZ = {string}
HKLM\Software\Policies\Skype\Phone, ProxyAddress, REG_SZ = {string}
HKLM\Software\Policies\Skype\Phone, ProxyUsername, REG_SZ = {string}
HKLM\Software\Policies\Skype\Phone, ProxyPassword, REG_SZ = {string}
HKLM\Software\Policies\Skype\Phone, WebStatus, REG_DWORD = {0,1}
These same registry settings are available for the current user at HKEY_CURRENT_USER\Software\Policies\Skype\Phone but the HKEY_LOCAL_MACHINE entries take precedence.


Baset, S. A., & Schulzrinne, H. (2008, September 15). An Analysis of the Skype Peer-to-Peer Internet Telephony.
Biondi, P., & Desclaux, F. (2006, March 2). Silver Needle in the Skype.
Saikat, G., Daswani, N., & Jain, R. (06, February). An Experimental Study of the Skype Peer-to-Peer VoIP System.
Schmidt, J. (2006, December 15). The hole trick - How Skype & Co. get round firewalls.
United States Patent Office. (07/12/07). System and method for detection of data traffic on a network (US 2007/0159979). Washington, DC: U.S. Government Printing Office.
Max, H., & Ray, T. (2006). Skype: The definitive guide. Indianapolis: Que Corporation.
Skype Network Administrator's Guide (2006, October 31). Contact the ISO team if you are interested in reading this document.
Network Admin Guide Version 2.2 (2008, February 5). -missing
Berson, T. (2005, October 18). Skype Security Evaluation. -missing