Secure Java Chat Application with SSL/TLS

Java client/server chat application with TCP sockets, SSL/TLS, certificate validation, MySQL message storage, Swing UI, and Wireshark-based security tests.

Date2024-12-20

CategoryAcademic

RoleApplication implementation, SSL/TLS configuration, test reporting, and technical documentation

StackJava • TCP sockets • SSLServerSocket / SSLSocket • Swing • MySQL • JDBC • keytool • Wireshark

JavaSSL/TLSMySQLWiresharkCybersecurityClient/server

Key highlights

Implemented a concrete client/server security project instead of staying at theory level.
Validated the effect of SSL/TLS by comparing readable traffic without encryption and unreadable payloads when encryption was enabled.
Connected Java networking, certificate handling, database storage, GUI interaction, and test reporting in one project.

ContextBUT R&T S3 secure development project

Core featureMulti-user chat with accounts, message history, and GUI client

Security proofWireshark comparison with SSL disabled/enabled and invalid-certificate rejection

Evidence availableTechnical documentation, user guide, test report, source code, and generated Javadoc

What I handled

Built and documented the Java client/server architecture with multithreading, TCP communication, and a Swing-based client interface.

Configured SSL/TLS using Java secure sockets, keystores, truststores, and certificate validation behavior.

Integrated MySQL storage for users and timestamped messages, including a /history command to retrieve previous exchanges.

Produced technical documentation, a user guide, and a test report covering clear-text communication, invalid certificate handling, encryption validation, and message storage.

Results & evidence

TransportTCP + SSL/TLSThe project uses Java secure socket classes to protect client/server exchanges.

Certificate testInvalid certificate refusedThe test report documents SSLHandshakeException behavior for untrusted or missing certificate scenarios.

Traffic proofWireshark comparisonCaptured packets were used to show the difference between clear text and encrypted communication.

PersistenceMySQL + /historyMessages are stored with timestamps and can be retrieved from the chat interface.

Secure chat architecture

Architecture diagram showing Java Swing clients, SSL/TLS sockets, chat server, MySQL storage, certificate validation, and Wireshark tests. — The project combines a Java client/server design with a security validation workflow.

Timeline

Step 1

Build the chat architecture

Create the Java client/server base with TCP communication, multithreading, user handling, and a Swing interface.

Step 2

Add security and storage

Enable SSL/TLS, configure keystores/truststores, validate certificates, and persist messages in MySQL.

Step 3

Test and document

Compare clear and encrypted captures with Wireshark, test invalid certificates, validate message history, and produce final documentation.

Overview

This project is a secure Java chat application built as a client/server system. It combines networking, security, database storage, and graphical interaction in one practical project.

The goal was to build a real messaging application and then prove that the security controls were doing something observable. That is why the project includes not only code, but also a technical documentation file, a user guide, and a test report.

Context

The project was developed in a BUT R&T S3 environment around secure application development. The application allows users to exchange messages through a server, while SSL/TLS protects the communication path and MySQL stores user and message data.

The important point is that the security part was tested, not only described.

What I built

The project includes:

a Java chat server
Java clients using a Swing graphical interface
TCP client/server communication
multithreaded client handling
SSL/TLS secure sockets
keystore and truststore configuration
MySQL storage for users and messages
message history retrieval through /history
Wireshark validation with SSL disabled and enabled

Architecture / approach

The architecture is simple but useful:

the client opens a connection to the server
the server handles multiple clients with dedicated threads
SSL/TLS secures the client/server exchange
certificates are validated through the truststore logic
MySQL stores users and timestamped messages
the client interface lets users chat and retrieve history
Wireshark is used to check what appears on the network

This is exactly the kind of project that shows the difference between “I know the word encryption” and “I tested what encryption changes in a real capture”.

Security tests

The test report covers several useful scenarios:

Clear-text baseline

SSL/TLS was disabled to observe the baseline behavior. This made it possible to see that messages could be readable in traffic captures when communication is not protected.

Invalid certificate rejection

The client/server connection was tested with an invalid or missing certificate scenario. The expected and observed behavior was connection refusal, with an SSL handshake error.

Encrypted traffic validation

With SSL/TLS enabled, Wireshark captures no longer showed readable message content. This confirmed the practical effect of the secure transport layer.

Message storage and history

MySQL storage was tested by sending messages, validating database persistence, and retrieving previous exchanges through the /history command.

Proof available

The uploaded project material includes:

source code
generated Java documentation
technical documentation
user guide
test report

Before publishing the source publicly, configuration files should be reviewed and sanitized so no local paths, passwords, keystores, truststores, or environment-specific values are exposed.

Results

This project demonstrates a useful mix of skills:

Java client/server development
secure socket programming
certificate validation logic
database persistence
GUI development
Wireshark-based verification
structured test documentation

Limits and improvements

The application is a learning project, not a production messaging platform. The main improvements would be:

stronger password handling
cleaner configuration management
better error handling in the UI
sanitized public repository structure
stronger certificate lifecycle management
automated tests around authentication and message storage

What this project demonstrates

This project is valuable because it connects security theory with proof. It shows that I can implement a feature, test it, observe it with tools, and explain what the result means technically.