Port 1433: Microsoft SQL Server — The Enterprise Data Channel

Port 1433 is the default listening port for Microsoft SQL Server. When an application connects to a SQL Server database, when a report pulls sales figures, when a transaction commits to the ledger, port 1433 carries that conversation. It speaks a protocol called TDS, the Tabular Data Stream, and understanding that protocol means understanding how enterprise data has moved across networks for four decades.

What Runs on Port 1433

Port 1433 carries the Tabular Data Stream (TDS) protocol, an application-layer protocol designed for one purpose: moving data between a database server and its clients.¹ When you execute a SQL query in SQL Server Management Studio, your query travels to port 1433. When the server responds with rows of data, those rows stream back through the same port, formatted as TDS packets.

The protocol handles everything a database client needs:

• Authentication: Verifying who you are before you touch the data
• Encryption negotiation: Deciding whether the conversation should be encrypted
• SQL batch execution: Sending your queries to the server
• Stored procedure calls: Invoking precompiled database logic
• Result streaming: Returning data in self-describing packets that tell the client what columns exist and what types they contain

The elegance of TDS is that returned data is self-describing. The server sends column metadata, essentially a schema, before sending the actual rows. The client does not need to know the table structure in advance. The stream itself carries the blueprint for understanding what it contains.²

How TDS Actually Works

A TDS connection follows a precise choreography:

1. Pre-Login Handshake

Before any authentication happens, client and server exchange capabilities. The client announces its TDS version, whether it wants encryption, and whether it supports features like Multiple Active Result Sets (MARS). The server responds with its own capabilities. If they cannot agree, the connection terminates before any credentials are exchanged.³

2. TLS Handshake (Optional in TDS 7.x, Mandatory in TDS 8.0)

In older TDS versions, encryption was optional and negotiated at the TDS layer. With TDS 8.0 (introduced with SQL Server 2022), encryption happens first, before any TDS communication begins. The entire conversation, including pre-login, is encrypted from the start.⁴

3. LOGIN7 Authentication

The LOGIN7 packet is where authentication rules are defined. The client sends credentials (username and password, or Windows authentication tokens), along with metadata like the client application name, hostname, and the database to connect to. The server validates the credentials and either accepts or rejects the connection.

4. Query Execution

Once authenticated, the client sends SQL batches or stored procedure calls. The server executes them and returns results. Data comes back as COLMETADATA packets (describing the columns) followed by ROW packets (containing the actual data). A completion token signals when the result set is finished.

The History

Berkeley, 1984

The story begins not in Redmond but in Berkeley, California. In 1984, Mark Hoffman, Bob Epstein, Jane Doughty, and Tom Haggin founded Sybase in Epstein's home.⁵ Epstein had helped create Ingres, one of the earliest relational database systems, during his PhD work at UC Berkeley. He knew databases. What he also knew was that databases had a problem.

The problem: there was no commonly accepted application-level protocol to transfer data between a database server and its client.⁶

Every database vendor had their own way of moving data. If you wanted to talk to a database, you used that vendor's proprietary libraries, their proprietary wire format, their proprietary everything. Sybase decided to change this, at least for their own product.

They created TDS, the Tabular Data Stream. They built two libraries: db-lib provided an API for client applications, and netlib handled the network communication. The actual bytes that flowed between client and server, that was TDS.⁷

The Microsoft Partnership

In 1990, Sybase entered a technology-sharing agreement with Microsoft. Bill Gates had called Sybase "the best SQL database engine" and convinced Ashton-Tate to use it instead of their own.⁸ Microsoft wanted to bring SQL Server to OS/2, and later to Windows NT.

The result was Microsoft SQL Server, built on Sybase's codebase and speaking Sybase's TDS protocol. For several years, Sybase SQL Server and Microsoft SQL Server were essentially the same product for different platforms.

In 1995, Microsoft released SQL Server 6.0, marking the end of the Sybase collaboration.⁹ From that point forward, the two products diverged. Sybase continued developing what became Adaptive Server Enterprise. Microsoft continued developing SQL Server. Both kept using TDS, but their versions began to drift apart.

The Protocol Versions

TDS version numbers tell the story of that divergence:

For 24 years, TDS was proprietary. Sybase documented TDS 5.0 for their own users, but Microsoft kept their versions secret. Developers who wanted to connect to SQL Server from non-Windows platforms had to use Microsoft's libraries or reverse-engineer the protocol.

Then, in 2008, Microsoft published the full TDS specification as part of their Open Specification Promise.¹⁰ The FreeTDS project, which had spent years reverse-engineering the protocol, suddenly had official documentation. The protocol was no longer a secret.

Security

The Password Problem

The early security of TDS was, frankly, embarrassing. Microsoft SQL Server authentication did not encrypt passwords. Instead, it applied a simple XOR transformation with a constant value. Passwords were sent in Unicode, XORed, and transmitted. Anyone sniffing the network could trivially recover them.¹¹

This was not encryption. It was obfuscation, and weak obfuscation at that.

The Buffer Overflows

In 2002, security researcher David Litchfield discovered a buffer overflow vulnerability in SQL Server's handling of TDS packets on UDP port 1434 (the SQL Server Resolution Protocol port, used by the SQL Browser service). He presented the vulnerability at Black Hat Briefings and Microsoft released a patch (MS02-039).¹²

Six months later, many organizations had not applied the patch.

On January 25, 2003, the SQL Slammer worm exploited that vulnerability. The worm was 376 bytes of assembly code. It did not write to disk. It existed only in memory and in network packets. It spread by sending malformed UDP packets to port 1434 on random IP addresses.¹³

SQL Slammer became the fastest-spreading worm in Internet history. It doubled in size every 8.5 seconds. Within 10 minutes, it had infected 75,000 servers.¹⁴ It crashed routers worldwide, disrupted ATMs, and brought credit card point-of-sale systems to a halt.

The worm targeted port 1434 (UDP), not port 1433 (TCP). But SQL Slammer changed Microsoft's approach to security fundamentally. It was a wake-up call that reverberates through every subsequent SQL Server release.

Port 1433 Attacks Today

Modern attacks on port 1433 tend to follow a pattern:

1. Scanning: Attackers scan for open port 1433 across IP ranges
2. Brute forcing: They attempt to guess the sa (system administrator) password
3. Exploitation: Once in, they use SQL Server features like xp_cmdshell to execute operating system commands
4. Persistence: They create scheduled jobs in SQL Server Agent to maintain access even if their entry point is closed¹⁵

The security guidance is consistent and unambiguous: never expose port 1433 to the public Internet.¹⁶ If remote access is required, use a VPN. Use strong authentication. Disable xp_cmdshell. Monitor for brute-force attempts. Encrypt connections.

TDS 8.0, introduced with SQL Server 2022, makes encryption mandatory rather than optional. The entire conversation is encrypted from the first byte. This addresses the historical weakness where pre-login packets were sent in cleartext.

Port 1433 and Port 1434

SQL Server uses two ports:

• Port 1433 (TCP): The default port for database connections
• Port 1434 (UDP): The SQL Server Browser service

Why two ports? Because SQL Server supports multiple instances on a single machine. The default instance listens on port 1433. Named instances listen on dynamic ports that can change when the server restarts.

The SQL Server Browser service solves the discovery problem. A client connects to UDP port 1434, asks "what port is the instance named SALES using?", and the Browser responds with the current port number. The client then connects to that port via TCP.¹⁷

If you are running only the default instance and have configured a static port, you do not need port 1434. If you are running named instances with dynamic ports, the Browser service becomes the routing layer that makes connections possible.

Current Usage

Microsoft SQL Server remains one of the dominant enterprise database platforms. Over 200,000 companies worldwide use SQL Server.¹⁸ It holds approximately 14% of the database management system market, competing with Oracle, MySQL, and the rapidly growing PostgreSQL.¹⁹

In North America, over 70% of enterprise customers use SQL Server for database management.²⁰ It powers everything from small business applications to Fortune 500 data warehouses. Every query, every transaction, every report flows through port 1433.

SQL Server 2025, announced in late 2024, adds native vector data types and AI capabilities, signaling that the database, and port 1433 with it, will continue to carry increasingly sophisticated workloads.²¹

Related Ports