Port 684 carries CORBA IIOP SSL traffic—the encrypted variant of the Internet Inter-ORB Protocol that enables secure communication between distributed objects across different systems and programming languages.
What CORBA IIOP SSL Does
CORBA (Common Object Request Broker Architecture) was designed to solve a specific problem: how do you let an object written in Java call a method on an object written in C++ running on a completely different machine, potentially on a different operating system?
The answer was the Object Request Broker (ORB)—middleware that sits between objects and handles all the network communication, data translation, and protocol details. IIOP (Internet Inter-ORB Protocol) is how these ORBs talk to each other over TCP/IP networks.1
Port 684 carries the SSL-encrypted version of this communication. When a client object needs to securely invoke a method on a remote server object, the request flows through port 684, encrypted to protect the method calls, parameters, and return values.2
How It Works
Here's what happens when a CORBA object makes a secure remote method call:
1. The client object calls a method
The client calls a method on what looks like a local object. It's actually a proxy—a stand-in that forwards the call to the ORB.
2. The ORB packages the request
The ORB serializes the method name, parameters, and object reference into a format that can travel over the network. This is called marshalling.
3. IIOP carries it over SSL
The request travels over an SSL/TLS connection on port 684. The encryption protects the method call and any sensitive data in the parameters.
4. The remote ORB receives it
On the server side, another ORB receives the encrypted request, decrypts it, and deserializes the data (unmarshalling).
5. The method executes and returns
The server ORB invokes the actual method on the actual object. The return value gets marshalled, encrypted, and sent back through port 684.
6. The client receives the result
The client ORB decrypts the response, unmarshals the return value, and hands it back to the client object. From the client's perspective, it just called a method and got a result—the network is invisible.3
The CORBA Vision
CORBA was the Object Management Group's answer to distributed computing in the 1990s. The promise was "write once, run anywhere"—before that phrase became associated with Java.
The vision: objects that could communicate across language boundaries, across operating systems, across networks, as easily as calling a local function. A Java object calling a method on a C++ object, which calls a method on a COBOL object, all seamlessly.4
Port 684 was part of this infrastructure—the secure channel for objects that needed encrypted communication. Financial systems. Healthcare applications. Enterprise middleware that handled sensitive data.
Why It Still Exists
CORBA didn't become the universal standard it aimed to be. Web services, REST APIs, and gRPC emerged as simpler, more focused alternatives. But CORBA didn't disappear—it's still running in enterprise systems that were built in the 1990s and early 2000s.
Port 684 is still open on systems where:
- Legacy financial systems use CORBA for secure transaction processing
- Telecommunications infrastructure relies on CORBA ORBs for network management
- Military and government systems built on CORBA for cross-platform integration
- Enterprise application servers from that era (IBM WebSphere, Oracle, BEA) still run IIOP services
These systems work. They're stable. Replacing them would cost millions. So port 684 keeps carrying encrypted method calls between objects that have been talking to each other for decades.
Security Considerations
Port 684 carries SSL/TLS-encrypted traffic, which means the communication is protected from eavesdropping. But "SSL" in this context often means older versions of SSL/TLS that may no longer be considered secure by modern standards.
If you're running CORBA IIOP SSL:
- Verify TLS version — Ensure you're using TLS 1.2 or higher, not SSL 3.0 or earlier
- Update ORB implementations — Old ORBs may have vulnerabilities
- Restrict port access — Port 684 should only be accessible to systems that need it
- Monitor for unusual traffic — CORBA isn't widely used anymore, so unexpected traffic may indicate reconnaissance or exploitation attempts
Related Ports
- Port 683 — CORBA IIOP (unencrypted)
- Port 2809 — IBM WebSphere ORB SSL listener (another common IIOP SSL port)
How to Check What's Listening
On Linux/macOS:
On Windows:
If you see something listening on port 684, it's likely an enterprise application server or legacy middleware using CORBA.
Frequently Asked Questions
آیا این صفحه مفید بود؟