EA Origin Chat Sent Messages in Plaintext
EA's Origin desktop client — the launcher and social platform for Battlefield, FIFA, The Sims, and other EA titles — transmitted user chat messages as unencrypted XMPP traffic, readable by anyone positioned to observe the network path between the client and EA's servers. This investigation documents what was observed through packet capture, explains the XMPP protocol mechanics behind the plaintext transmission, assesses the real-world risk to users, and draws practical lessons about messaging security that remain relevant well beyond a single gaming platform. The methodology involved direct traffic analysis using Wireshark on a standard home network, capturing and examining the TCP streams generated during Origin chat sessions. The work connects to broader themes covered in the security section and the privacy and security topic hub.
What was observed
Origin's chat system used XMPP (Extensible Messaging and Presence Protocol) for its instant messaging functionality. The XMPP connection between the Origin client and EA's chat servers was established without TLS encryption. Message content, sender and recipient identifiers, presence status changes, and friend list information were transmitted in plaintext XML over a standard TCP connection. Any network observer — a shared Wi-Fi access point, an ISP performing deep packet inspection, a compromised router — could read the full content of Origin chat conversations.
The capture process
The observation was straightforward. Running Wireshark on the same network as the Origin client and filtering for XMPP traffic (or more broadly, for TCP traffic to EA's known chat server hostnames) revealed readable XML stanzas containing:
- Full message text in
<body>elements within<message>stanzas - User identifiers (EA account names and JIDs) in
fromandtoattributes - Presence updates showing online/offline/away status
- Friend list roster queries and responses
This was not an exploit. It was not a vulnerability in the traditional sense of bypassing a security mechanism. There was no security mechanism to bypass. The connection simply was not encrypted.
When a user sent a chat message through Origin, the client transmitted an XMPP <message> stanza in cleartext XML over TCP. The message body was directly readable in the packet payload without any decoding, decryption, or reconstruction. A single packet often contained the complete message text, sender, and recipient — making passive interception trivial for anyone with network visibility.
Understanding the XMPP protocol context
XMPP is a mature, well-documented protocol for real-time messaging. It was originally developed as Jabber in 1999, standardised by the IETF as RFC 3920/3921 (later updated to RFC 6120/6121), and has been used in production messaging systems for over two decades. Google Talk, Facebook Messenger (initially), WhatsApp (internally), and numerous enterprise systems have used XMPP.
The protocol itself fully supports encryption. XMPP defines a STARTTLS upgrade mechanism that moves the connection from plaintext to TLS after the initial TCP handshake. Servers can require TLS before allowing authentication. End-to-end encryption is available through extensions like OMEMO and OTR. The infrastructure for secure XMPP messaging existed and was well-understood at the time EA was running Origin chat in plaintext.
The issue was not that XMPP cannot be encrypted. It was that EA's implementation did not use the encryption capabilities the protocol provided. The server accepted plaintext connections. The client did not initiate STARTTLS. The result was a messaging system built on a protocol designed to support encryption, operating without any encryption at all.
Why this matters more than it sounds
The instinct is to dismiss this as low-stakes. It is a gaming chat system. People are coordinating Battlefield squads, not exchanging state secrets. That framing misses several important points:
Users did not know. There was no indication in the Origin interface that messages were unencrypted. Users sending messages through what looked like a private chat feature had a reasonable expectation that the platform provided basic transport security — especially in an era when web browsers were moving aggressively toward HTTPS-everywhere.
The content was not always trivial. Gaming chat frequently includes personal information — real names, locations, ages, account credentials shared informally between friends, links to personal social media profiles, and sometimes financial discussions about in-game purchases or account trades.
Shared networks amplified the risk. Gaming laptops on university Wi-Fi, shared household internet connections, gaming cafés, conference networks — the environments where people play games are disproportionately likely to be shared networks where passive interception is easiest.
The scale was enormous. Origin had tens of millions of registered users. Even if each individual conversation was low-sensitivity, the aggregate data flowing unencrypted across networks worldwide was substantial.
What was actually dangerous
To be precise about the threat model: the risk was passive interception by anyone on the network path between the user's machine and EA's XMPP servers.
Scenarios where this was exploitable
- Public Wi-Fi without client isolation: A user on the same café or hotel Wi-Fi could capture Origin chat traffic from any other Origin user on that network with standard packet capture tools.
- Compromised routers: Home routers with known vulnerabilities (and the consumer router ecosystem has a poor track record) could be used to capture all XMPP traffic passing through them.
- ISP-level observation: Internet service providers, or government agencies with ISP cooperation, could read Origin chat traffic as part of broader surveillance without needing any additional access beyond what the network path already provided.
- Man-in-the-middle at any hop: Without TLS, there was no certificate validation, no integrity protection, and no authentication of the server. An active attacker could not only read but modify messages in transit.
What this was not
This was not a remote code execution vulnerability. It did not allow account takeover directly (authentication was handled separately from chat). It did not expose passwords (Origin's login used HTTPS for credential exchange). The finding was specifically about the chat message transport — but within that scope, the exposure was complete.
The broader pattern: selective encryption
EA's Origin was not unique in encrypting authentication while leaving other communication channels in plaintext. This was a common pattern in the early 2010s across desktop applications, and it reveals a particular mindset about security: protect the credentials, do not worry about the content.
In the early 2010s, many desktop applications encrypted login credentials but left application-layer communication — chat, telemetry, updates, file transfers — on unencrypted channels. The assumption was that transport encryption was expensive, complicated, and unnecessary for "non-sensitive" data. TLS certificate management was genuinely more painful before automated issuance (Let's Encrypt launched in 2015), and CPU overhead for TLS was a real consideration on older hardware.
Modern applications encrypt everything by default. TLS 1.3 is fast and lightweight. Certificate issuance is automated. The computational overhead argument has evaporated. Platform vendors enforce encrypted transport — Apple's App Transport Security and Google's Play Store policies both require TLS by default. A new application shipping with unencrypted messaging would be flagged in security review before it reached users.
The lesson is not that EA was uniquely negligent. It is that the industry's baseline expectation for transport security shifted dramatically over a short period, and applications that were built during the permissive era carried their insecure defaults forward until someone looked closely enough to document them.
Origin's eventual trajectory
EA eventually addressed encrypted transport across Origin's communication channels as part of broader platform updates. The specific timeline of when TLS was added to the XMPP connection is not publicly documented with precision — EA did not issue a security advisory about it.
EA replaced Origin entirely with the EA App, which launched as a full replacement in 2022. The EA App was built on a modern architecture where encrypted transport was the default for all communication channels. Origin was officially retired, and users were migrated to the EA App. The unencrypted XMPP chat finding became historical — the vulnerable platform no longer exists — but the investigation methodology and the lessons about transport security remain directly applicable.
Practical lessons for identifying unencrypted traffic
The methodology used to identify Origin's plaintext chat applies to any desktop application where you want to verify transport security:
1. Capture traffic during normal use. Run Wireshark or tcpdump while using the application's communication features. Filter for the application's known server addresses or for common protocol ports.
2. Examine TCP stream content. If you can read message content, identifiers, or structured data (XML, JSON, plaintext) directly in the packet payload, the connection is not encrypted. TLS-encrypted traffic appears as opaque byte streams after the initial handshake.
3. Look for STARTTLS negotiation. In protocols that support optional encryption (XMPP, SMTP, IMAP), the initial connection may start in plaintext and upgrade. If you see a STARTTLS command followed by a TLS handshake, the connection was upgraded. If the conversation proceeds without it, encryption was never established.
4. Check certificate validation behaviour. Even if TLS is present, test whether the application validates server certificates properly. A proxy like mitmproxy can present a self-signed certificate to test this. An application that accepts the proxy's certificate without warning has a TLS implementation that provides limited security against active attackers.
Seeing HTTPS in a login flow does not mean the entire application uses encrypted transport. Many applications use HTTPS for authentication but switch to unencrypted protocols for other functionality. Verify each communication channel independently. Chat, voice, file transfer, telemetry, and update mechanisms may each use different protocols with different security properties.
Why this investigation still matters
The EA Origin chat finding is historical — the platform is retired — but it remains instructive for several reasons.
It demonstrates that large, well-funded software companies can ship products with basic transport security omissions. EA was not a small developer without security resources. Origin was a flagship platform competing with Steam. The plaintext chat was not a temporary oversight; it persisted across multiple Origin versions over a multi-year period.
It illustrates the value of independent traffic analysis. The finding was not reported by EA. It was not discovered through a bug bounty programme. It was found by users who ran packet captures and looked at what their software was actually sending. That kind of verification — do not trust the application, verify the wire — remains the most reliable way to assess whether a piece of software is protecting your communications.
And it provides a clear case study for understanding transport security concepts. The difference between "the login is encrypted" and "the communications are encrypted" is easier to explain with a concrete example than with abstract threat models. Origin's chat is that concrete example.
The fail2ban and IPv6 investigation covers a different but related theme — security tooling that appears to protect you but has gaps in coverage that only surface under specific conditions. Both are cases where the assumption of security did not match the observed reality.