While reading MS SDL (Microsoft Security Development Lifecycle) presentations I found a recommendation to replace UDP with TCP in applications because TCP is more secure than UDP. But both of them are only transport layers, nothing more.
So why is TCP more secure than UDP?
To send data to an application using TCP, you first have to establish a connection. Until the connection is established, packets only get to the OS layer, not the application. Establishing a connection requires that you receive packets back to the initiating end. If you wanted to forge an IP address not on your own network and establish a TCP connection, you'd need to be able to intercept the packets the other side sent out. (you need to be "in between" the endpoint, and where the packets to the forged IP address would normally go, or do some other clever routing tricks.)
UDP has no connection, so you can forge a packet with an arbitrary IP address and it should get to the application. You still won't get packets back unless you're in the right "place" of course. Whether this matters or not depends on the security you put in the application. If you were to trust certain IP addresses more than others inside the application, this may be a problem.
So in that sense, TCP is more "secure" than UDP. Depending on the application, this may or may not be relevant to security. In and of itself it's not a good reason to replace UDP with TCP since there's other tradeoffs involved between the two protocols.
Plain UDP does not keep state, have handshakes etc. This mean an attacker could easily send a spoofed packet unless there are protections at other layers.
On the other hand, sending a spoofed TCP packet requires the attacker to guess the sequence number and client's port of an established connection.
TCP isn’t more secure than UDP, it is more “reliable” as it is stateful and requires acknowledgment of each segment. UDP is stateless and just sends segments without knowing of the client gets them or not.
Neither have any bespoke security features that other doesn’t, differences are mealy down to the different requirements of each protocol, any perceived security benefits are mealy by-products of the protocols functionally rather than a deliberate security feature.
EDIT: UDP and TCP have specific uses, none of these uses relates to security.
Both protocols rely on other protocols to provide security. So although TCP may have a slightly smaller attack surface, this is really inconsequential as to secure either you require a security orientated protocol. Protocol such as DTLS or googles QUIC.
Choosing to implement TCP for a use case that is better suited for UDP, rather than securing UDP correctly (TCP would also require securing in most use cases), would be like using a 9 iron for putting because you think that a 9 iron would be a better weapon to defend yourself with in a fight...when you have a gun in your pocket.
Yes, but we have to be very clear about what we are talking about when we are talking about "security" and not generalize this statement to upper layer protocols.
Currently, security is often associated to the CIA triad:
The version 4 of the IP protocol, which is still the most commonly used now, is a very old beast which was developed during the 70's and 80's.
At that time, confidentiality was not really a subject and what was really targeted was to achieve integrity and availability (the Arpanet network, the ancestor of the Internet which gave birth to the IP protocol, was designed to ensure a continuity of service even in the event of a nuclear war, not to protect in-transit data).
In this optic, two transport protocols were developed over the IP layer: TCP and UDP.
TCP was the one designed to ensure both the integrity and availability properties. It includes what was at that times advanced techniques such as a three-way handshake, parameters negotiation, various connection state handling, transparent packet reordering, acknowledgement windows and retry mechanisms. This brings good guaranties to the sender that the data it sent has been received in a complete an uncorrupted form (ie. no missing, altered or unordered parts).
Remind though that what this protocol was targeting was a technical disaster, not a malicious tampering of the data in transit. Such issue was completely out-of-scope at that time.
UDP on the contrary was designed to be a fast protocol. It has none of the above mentioned feature, and therefore none of their overhead too. In particular, when the sender sends some data using UDP, the data received may be incomplete, unordered or not received at all: the UDP protocol by itself does not provide any mechanism to prevent or detect this neither on the sender or receiver sides.
In this way, when focusing on the data integrity and availability properties of security, TCP is indeed more secure than UDP.
Certainly not.
This only means that people developing an application protocol relying on UDP will have more work since they may have to implement in their application protocol workarounds for the features missing in the UDP protocol. They will have to take into account that data sent may not be necessarily received, that data received may not be in the right order, etc. These are all well-known problems.
OpenVPN for instance, while it supports TCP mostly for compatibility with restrictive firewalls, runs by default and runs best over UDP. Switching it to TCP is possible but will not increase its security in any way as the difference between the two transport layer protocol UDP and TCP is fully handled by OpenVPN itself. Switching it to TCP will only add the TCP overhead to the OpenVPN protocol, thus reducing its performance.
No, this is entirely an application protocol design choice.
UDP is a more raw protocol. When used correctly and carefully it may achieve better performances than TCP at the price of a more difficult development and maintenance of the application protocol.
Most protocols are not time sensitive and therefore TCP is most widely used protocol. Indeed, when you load a web page or receive an email, there is no difference if you receive it 10 milliseconds sooner or later.
Two classical examples of protocols using UDP, in addition to the OpenVPN previously cited, are media streaming and DNS.
With media streaming, you don't really care if one video frame or a few milliseconds of video or audio is missing, as long as the video or audio is playing smoothly and synchronously. In such case, you don't want to induce repetitive pauses because TCP detected a missing packet and asked the sender to resend the content of the last acknowledgement window.
With DNS, requests and answers are usually very short and you want the name resolution process to be as fast as possible (note that longer and less time-sensitive answers such as DNS zone transfers usually still occur on TCP). It is faster to resend the name resolution request to the DNS server on the very few times the request or its answer gets lost than processing a full-fledged three-way handshake for every request.
All we cared about until now was, in the spirit of this old IPv4, the balance between transmission speed and data integrity + availability. Now, if we want to add confidentiality on top of this, we can do this but it will have to be done at the application layer as, as stated before, IPv4 is not concerned by confidentiality issues.
A modern, full-fledged implementation of security can be implemented at the application layer and rely on either TCP or UDP (or both) protocols without any impact on the application protocol security itself (see the example of OpenVPN above).
However, as stated in the beginning, IPv4 really comes from a another computing age. It got a successor by the name if IPv6, which natively supports IPSec at the IP layer, thus providing more modern security services below transport protocols such as UDP and TCP.
This allows to delegate in-transit data encryption from the application to the network layer, and allows both UDP and TCP to provide exactly the same security guaranties. However, in most scenarios UDP performance gain will be counterbalanced by IPSec overhead, so I'm not sure there would be any advantage in using UDP instead TCP as long as IPv6 IPSec is being used.
Not really.
Neither protocol has any built-in features which are meant to provide confidentiality. Any security is supposed to be provided by the protocol layers above (or below).
TCP is a more complex protocol than UDP which makes it a tad bit harder to spoof, but these complications are rarely a serious obstacle.
When people say that TCP is "more reliable" than UDP, they don't refer to security. TCP is more reliable because it ensures that all segments are received in order and any lost segments are retransmitted. UDP does not guarantee this. When the connection is bad, UDP segments can get lost without a trace or arrive in the wrong order. How to deal with this problem is up to the application.
TCP is "Connection-Based" which means it has reliability built in, in the form of sequence numbers. So, for example, I send you an image over TCP but, 1/4 of the packets get dropped. Since we have a connection based protocol with sequence numbers, your computer will know that you are missing that data and therefore request that data from me in order to have data integrity. This is slower but, much more secure. Also, in order to spoof TCP/IP packets, you have to catch that sequence number and send a malicious packet. Without a man in the middle, that is almost impossible!
UDP is a "Connetionless" protocol, meaning it just sends the data and forgets. There is no data reliability or integrity, but it's faster and more efficient for some applications.
In practice, TCP is easier to police in a firewalled network: Traffic pertaining to externally vs internally established connections, and thus client vs server roles, can be clearly distinguished and handled by separate policy. For example, you can trivially ensure hosts on a protected network can access an external web server but will not be able to act as a web server to outside clients. For UDP services (for example DNS), enforcing such policies requires far more intelligence and guesswork, since you have to take information above and below the transport layer into account.
TCP is not "more secure" than UDP:
UDP is just a thin layer on top of the IP packets, whereas TCP has complex - and standard - additional mechanisms, which are part of the Operating Systems.
Worth taking a look at the QUIC project, to find out more about TCP/UDP differences, and why Google did create its own secured HTTP/2 transport layer over UDP instead of TCP.
Let's quote https://www.chromium.org/quic :
Key advantages of QUIC over TCP+TLS+HTTP2 include:
- Connection establishment latency
- Improved congestion control
- Multiplexing without head-of-line blocking
- Forward error correction
- Connection migration
Let's set some pros/cons from security prospective for each and see:
UDP
TCP
Currently, TCP is not more secure than UDP. TCP is more reliable than UDP because TCP can detect and retransmit error packets.
If one wishes to have secure data transmission, then you are looking at using some format encryption such as TLS or IPSec.
TCP has a concept of a connection, UDP doesn’t. However the connection concept is both a strength and weakness from a security standpoint. The main security strength of the connection is that it is standardized, the application developer, networking gear and firewalls can all rely on a fixed method for, establishing the connection, handling packet fragmentation, retransmission and so on. Additionally the connection concept makes it easier to build additional layers of security on top, for example SSL.
However a TCP connection doesn’t provide much protection from an attack that directly targets the transport layer, for example a SYN flood attack. With UDP you could theoretically authenticate every single packet to mitigate some of these risks.
Therefore I would argue that UDP is “theoretically” more secure than TCP, however we live in a world where security is not perfect, so theoretical strength is somewhat meaningless. In the real world it is possible to find examples both ways - where one protocol has failed in a way that the other would not have been vulnerable to.
In summary, I don’t think there is an answer to which protocol is more “secure” you need to qualify your question with what threats you are concerned about and how much and how long you are willing to spend to mitigate them. If it’s all threats and you have an infinite about of time and money, then my theoretical answer holds.
