HAMAWhat TLS is and why you need it
TLS 1.3 (Transport Layer Security) is a protocol that encrypts data as it travels across a network between two parties, typically between a client application and a server. When you see the padlock in your browser's address bar or use a secure app, TLS is almost always working under the hood. Its job is to make sure that no one sitting between you and the server — your ISP, the operator of a Wi-Fi hotspot, the owner of intermediate equipment — can read or silently tamper with the data being sent.
TLS solves three problems at once: confidentiality (the traffic is encrypted), integrity (any change to the data in transit is detected) and authentication (you can be sure you are connecting to the genuine server, not an impostor). Authentication is built on certificates and public-key infrastructure.
What TLS 1.3 improved over TLS 1.2
TLS 1.2 was published in 2008 and accumulated a lot of historical baggage over a decade and a half: many optional features, outdated algorithms and compromises made for compatibility. TLS 1.3 (RFC 8446, 2018) is a rethink of the protocol with a focus on security by default and on speed.
Fewer round trips
Setting up a secure connection requires a "handshake" — an exchange of messages in which the parties agree on keys. In TLS 1.2 this took two round trips (2-RTT). TLS 1.3 fits it into one (1-RTT), and when reconnecting to an already-known server, into zero (0-RTT). In practice this noticeably speeds up opening connections, especially over high-latency networks.
Weak and outdated algorithms removed
- RSA key exchange and static Diffie-Hellman were dropped — only ephemeral variants (ECDHE) remain, which provide forward secrecy.
- The RC4 stream cipher, CBC modes with known weaknesses, and MD5 and SHA-1 in signatures were removed.
- Only proven AEAD ciphers (such as AES-GCM and ChaCha20-Poly1305) are supported, which encrypt and verify integrity in a single step.
- The dangerous ability to "downgrade" to older algorithms — exploited by several attacks — was eliminated.
Forward secrecy became mandatory
Where forward secrecy was optional in TLS 1.2, it is built into the foundation of TLS 1.3: a separate temporary key is created for every session.
What forward secrecy is and why it is critical
Imagine an attacker recording encrypted traffic for years, hoping that someday they will obtain the server's key. Without forward secrecy, a single long-term key would be enough to decrypt the entire accumulated archive after the fact.
Forward secrecy breaks this scheme: each session is protected by its own ephemeral key, which is not derived from the server's long-term key and is deleted once the session ends. A future leak of the server's key does not reveal past traffic. This matters especially for organizations whose data retains value for years.
TLS (transport) vs E2E (end-to-end) — different layers
A common misconception: "we use TLS, so our messages are fully protected." That is not the case — these are two different layers of protection.
- TLS protects data in transit. The channel between the client and the server is encrypted, but on the server itself the data is decrypted in order to be processed or stored. A server administrator can in principle access it.
- E2E protects data from sender to recipient. A message is encrypted on the sender's device and decrypted only on the recipient's device. The server merely relays the encrypted "package" and never sees the plaintext.
These layers don't compete — they complement each other. TLS protects the channel itself and the transport metadata, verifies the server's authenticity and prevents connection hijacking. E2E additionally guarantees that even a compromised or curious server cannot read the content. A robust system uses both layers.
How HAMA handles this
In HAMA all transport runs over TLS 1.3 only — older versions are not used. This means the connection between the desktop client and the server is protected by modern encryption, mandatory forward secrecy and a fast handshake.
But HAMA does not stop at transport. On top of TLS, message content is protected by end-to-end encryption using the Signal protocol (X3DH + Double Ratchet), with AES-256-GCM used for groups. This means even the server has no access to the plaintext of messages. The local database on the device is encrypted with SQLCipher, and keys are kept in the operating system's secure store.
In addition, the server itself is hosted on a secure facility in Uzbekistan or on-premise within the organization's infrastructure, and HAMA is preparing for compliance with O'z DSt ISO/IEC 27001:2023 and the PP-167 requirements for critical information infrastructure. TLS 1.3 here is the foundation of the transport layer, not the entire defense on its own.