SSL/TLS: key concepts and protocols in development

What is SSL/TLS?

SSL (Secure Sockets Layer) and TLS (Transport Layer Security) — cryptographic protocols that ensure secure data transmission over a network. SSL, developed by Netscape in the 1990s, is considered outdated after version 3.0 due to POODLE and BEAST vulnerabilities. TLS, its successor, has gone through versions 1.0, 1.1, 1.2, and 1.3 — only TLS 1.2 and TLS 1.3 are considered current. All modern mobile platforms require TLS for network connections, and App Store and Google Play verify this during review.

Why TLS for Mobile Applications

Without TLS, traffic between the application and the server is transmitted as plaintext — anyone on the same Wi-Fi network can intercept logins, passwords, tokens, and users’ personal data using Wireshark or tcpdump. TLS encrypts all transmitted data (transport-layer encryption) and verifies the server’s authenticity through a chain of X.509 certificates. According to IETF (2018), TLS 1.3 uses only modern AEAD ciphers (AES-GCM, ChaCha20-Poly1305), excluding outdated algorithms like RC4 and 3DES.

HTTPS and TLS

HTTPS (HTTP Secure) — is HTTP over TLS. When a mobile application makes a request via https://, it first establishes a TLS connection with the server, then transmits HTTP headers and the request body through the encrypted channel. Without HTTPS, no serious API should operate — it is basic security hygiene. According to OWASP (2026), unsecured connections are among the top 3 mobile application vulnerabilities.

How TLS Handshake Works

TLS Handshake — the process of establishing a secure connection between a client and a server. The parties negotiate the protocol version, select a cipher suite, exchange keys through asymmetric cryptography, and verify certificates. In TLS 1.2, the handshake requires 2 Round Trip Time (2 RTT): client → server with ClientHello, server → client with ServerHello and Certificate, then final Finished messages. TLS 1.3 reduces this process to 1 RTT.

Detailed TLS 1.2 Handshake Stages

First stage: ClientHello — the client sends supported TLS versions, a list of cipher suites, and a random number. The server responds with ServerHello, selecting a version and cipher suite, sends its X.509 certificate (Certificate) and ServerHelloDone message. The client verifies the certificate through a chain of trusted Certificate Authorities (CA), generates a pre-master secret, encrypts it with the public key from the certificate, and sends it to the server in ClientKeyExchange. After this, both parties generate session keys and exchange ChangeCipherSpec and Finished messages. From this point onward, all data is encrypted symmetrically.

import Security

let url = URL(string: "https://api.example.com")!
let session = URLSession(configuration: .default,
                           delegate: self,
                           delegateQueue: nil)

func urlSession(
    _ session: URLSession,
    didReceive challenge: URLAuthenticationChallenge,
    completionHandler: @escaping (URLSession.AuthChallengeDisposition,
                                    URLCredential?) -> Void
) {
    let trust = challenge.protectionSpace.serverTrust
    guard let trust else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    completionHandler(.useCredential, URLCredential(trust: trust))
}

Example of handling URLAuthenticationChallenge on iOS via URLSessionDelegate. This method is called during each TLS Handshake, allowing the application to perform custom server certificate verification. For production use, add certificate verification via SecTrustEvaluateWithError and compare against a pre-saved fingerprint — only then call useCredential.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446, 2018) — the first major protocol update in 10 years. Key improvements: handshake reduced to 1 RTT (0 RTT for repeated connections), deprecated cipher suites removed (RSA key exchange, CBC-mode), mandatory Perfect Forward Secrecy (PFS), and protection against downgrade attacks via signed transcript. According to Qualys SSL Labs (2026), TLS 1.3 provides protection even when the long-term server key is compromised thanks to PFS.

0-RTT (Zero Round Trip Time) — a TLS 1.3 feature that allows the client to send data immediately along with ClientHello during a repeated connection via PSK (Pre-Shared Key). This speeds up loading of subsequent screens in mobile applications, especially with frequent requests to the same server. However, 0-RTT data is not protected against replay attacks — it can be intercepted and resent. Use 0-RTT only for idempotent requests (GET, PUT) with no side effects.

TLS on iOS: App Transport Security

App Transport Security (ATS) — Apple’s mechanism requiring HTTPS connections with TLS 1.2 or higher, enabled by default since iOS 9. ATS blocks all HTTP connections and HTTPS with TLS below 1.2. Developers can configure exceptions in Info.plist via NSAppTransportSecurity for specific domains, but Apple recommends minimizing exceptions and using HTTPS everywhere. Violating ATS requirements is grounds for app rejection during App Store review.

<!-- Info.plist — App Transport Security -->
<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <false/>
    <key>NSExceptionDomains</key>
    <dict>
        <key>cdn.example.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <false/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
        </dict>
    </dict>
    <key>NSAllowsLocalNetworking</key>
    <true/>
</dict>

ATS configuration in Info.plist. NSAllowsArbitraryLoads is set to false — all connections must use HTTPS. For the domain cdn.example.com, a minimum TLS version of 1.2 is specified, NSAllowsLocalNetworking=true allows HTTP for local networks (useful for dev servers). Apple strongly recommends not enabling NSAllowsArbitraryLoads without NSExceptionDomains — this should be an exception, not a general rule.

TLS on Android: Network Security Config

Network Security Config — Android’s mechanism for configuring HTTPS and TLS without changing Java/Kotlin code. Configuration is specified in the network_security_config.xml file and connected in AndroidManifest via the android:networkSecurityConfig attribute. Supports configuration of trusted certificates (user and system CA), Certificate Pinning, disabling cleartext HTTP, debug overrides, and traffic redirection.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-01-01">
            <pin digest="SHA-256">
                47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
            </pin>
        </pin-set>
    </domain-config>
</network-security-config>

Network Security Config for Android. Base-config blocks cleartext traffic and trusts only system CA certificates (no user certificates — protection against MitM certificate installation by users). Domain-config for api.example.com contains a pin-set with a SHA-256 certificate fingerprint. If the server certificate changes before the specified expiration date, the connection will be rejected — this is a strict form of Certificate Pinning.

Certificate Pinning and Security

Certificate Pinning — a technique of fixing a certificate or public key of the server in the application code. During each TLS Handshake, the client compares the server certificate against a pre-saved fingerprint (SHA-256 hash). Even if an attacker obtains a trusted CA certificate or compromises the certificate authority, they cannot perform a MitM attack — the application checks the specific fingerprint, not the CA chain. This is especially important for financial applications and apps handling sensitive data.

Risks and Alternatives to Pinning

Certificate Pinning requires caution: when the server certificate changes, all older versions of the application will stop connecting. It is recommended to store multiple backup fingerprints (primary + backup), specify a pin-set expiration date, and implement a fallback mechanism through standard CA verification. An alternative is Trust On First Use (TOFU), where the application remembers the certificate on first connection and warns the user when it changes. According to OWASP (2026), the absence of Certificate Pinning ranks among the top 3 mobile application vulnerabilities (M3: Insecure Communication).

Implementing Pinning in Alamofire

In Alamofire 5+, Certificate Pinning is configured via ServerTrustManager with PinnedCertificatesTrustEvaluator (full certificate check) or PublicKeysTrustEvaluator (public key only). The public key is preferable — it does not change when the certificate is renewed with the same CA. Create a ServerTrustManager with a [host: evaluator] dictionary, pass it to Session, and use it for all requests to secured APIs.