Mastering SSL/TLS: From CIAA Security Model to OpenSSL CA Setup

This comprehensive guide explains the CIAA security model for network transmission, details confidentiality, integrity, authentication, and availability, and walks through building a private CA with OpenSSL, configuring TLS 1.2/1.3, HTTPS authentication modes, SNI/ESNI extensions, and upgrading curl for HTTP/2 support.

AI Cyberspace
AI Cyberspace
AI Cyberspace
Mastering SSL/TLS: From CIAA Security Model to OpenSSL CA Setup

Network Transmission CIAA Security Model

The CIAA security model defines four core principles for secure network communication:

Confidentiality : Only authorized users can view data during transmission, typically achieved with encryption.

Integrity : Data must not be altered in transit; hash‑based verification ensures the received data matches the sender’s hash.

Authentication : Verifies the identity of the communicating parties, often using usernames/passwords or digital certificates.

Availability : Services must remain accessible, commonly ensured with load balancing and redundancy.

Authentication and availability protect resource access, while confidentiality and integrity protect business data.

Confidentiality

SSL/TLS employs three encryption types:

Symmetric Encryption

Both parties share a single secret key (e.g., AES, DES). It is fast but vulnerable if the key is leaked.

Asymmetric Encryption

Uses a key pair: a public key (distributed to clients) and a private key (kept on the server). RSA is a common algorithm. The public key encrypts data; only the matching private key can decrypt it, mitigating key‑leakage risks.

Hybrid Encryption

Combines asymmetric encryption to securely exchange a symmetric session key, then uses symmetric encryption for the bulk data. This approach is used in SSL/TLS, IPSec, Signal, WireGuard, etc.

Integrity

Different layers provide checksum or CRC checks:

L2 Data Link Layer : Ethernet frames include a 4‑byte CRC (strong check) for intra‑LAN integrity.

L3 Network Layer : IP headers use a weak checksum to verify header integrity.

L4 Transport Layer : Transport checksums are optional and may be omitted.

Security Layer : SSL/TLS can use MD5 (16 bytes), SHA‑1 (20 bytes), or SHA‑512 (64 bytes) checksums for stronger validation.

Authentication

Man‑in‑the‑middle attacks can compromise public key distribution. PKI (Public Key Infrastructure) solves this by issuing trusted digital certificates.

PKI Components

CA (Certificate Authority) : Issues digital certificates and authenticates identities.

Digital Signature Certificate : A public key signed by a CA, allowing clients to verify the server’s identity.

Certificate Structure (X.509 v3)

Version, Serial Number, Signature Algorithm

Issuer (CA details)

Validity period

Subject (certificate holder)

Subject Public Key Info

Extensions (e.g., Basic Constraints, Key Identifiers)

Issuer's Signature (signed hash of the above fields)

CA Certificate Issuance Process

Create a private key and public key for the website.

Submit CSR with domain and organization info to the CA.

CA validates the information.

CA signs the certificate, producing a digital signature.

The client validates the certificate by checking the trust chain, revocation status, expiry, and domain match.

Using OpenSSL to Build a Private CA and Issue Certificates

Step 1 – Create CA Directory and Config

# CA directory structure
-- CA/
    |-- index.txt
    |-- newcerts/
    |-- private/
    |-- serial

CERT_DIR=/root/CA
mkdir -p $CERT_DIR
cd $CERT_DIR
mkdir newcerts private
chmod 700 private

touch index.txt
echo 01 > serial

Step 2 – Generate CA Private Key

openssl genrsa -des3 -passout pass:foobar -out $CERT_DIR/private/cakey.pem 2048

Step 3 – Generate CA Public Certificate (Root)

openssl req -x509 -passin pass:foobar -new -nodes -key $CERT_DIR/private/cakey.pem -days 365 -subj "/C=US/ST=Denial/L=Springfield/O=Dis/CN=web.apigw.com" -out $CERT_DIR/ca_01.pem

Step 4 – Generate Server Key and CSR

mkdir $CERT_DIR/web.apigw.com
openssl req -newkey rsa:2048 -nodes -keyout $CERT_DIR/web.apigw.com/server.key -subj "/C=US/ST=Denial/L=Springfield/O=Dis/CN=web.apigw.com" -out $CERT_DIR/web.apigw.com/server.csr

Step 5 – Sign Server Certificate with CA

openssl ca -passin pass:foobar -config $CERT_DIR/openssl.cnf -in $CERT_DIR/web.apigw.com/server.csr -out $CERT_DIR/newcerts/server.pem -batch

SSL/TLS Overview

SSL (Secure Sockets Layer) was created by Netscape in 1994; IETF later standardized it as TLS (Transport Layer Security). TLS 1.2 is widely used, while TLS 1.3 (RFC 8446, 2018) offers stronger security and lower latency.

TLS 1.2

TLS consists of two parts:

TLS Record Layer : Splits application data into TLS records.

TLS Handshake Protocol : Authenticates parties and negotiates security parameters.

Handshake Steps

ClientHello : Client sends supported TLS version, cipher suites, compression methods, extensions, random, and optional Session ID.

ServerHello + Certificate + ServerHelloDone : Server selects version, cipher suite, compression, random, optional Session ID, and returns its certificate.

Certificate Authentication : Client validates the server certificate (trust chain, revocation, expiry, domain).

ClientKeyExchange + ChangeCipherSpec + EncryptedHandshake : Client encrypts a Pre‑Master secret with the server’s public key and sends it.

Server processes the Pre‑Master secret, derives the Master Secret, and sends its own ChangeCipherSpec and Finished messages.

After the handshake, both sides use the Master Secret for symmetric encryption of application data.

TLS 1.3

Improvements:

Stronger security: full handshake encryption, removal of insecure algorithms (RSA key transport, CBC, RC4, SHA‑1, weak DH groups).

Faster performance: reduces round‑trips to 1‑RTT for new connections and supports 0‑RTT data.

Key changes include mandatory forward‑secret Diffie‑Hellman key exchange and encrypted handshake messages.

Upgrading OpenSSL to 1.1.1 for TLS 1.3

# Verify TLS 1.3 support
openssl s_client --help | grep tls1_3

# Build OpenSSL 1.1.1
cd /opt
wget https://github.com/openssl/openssl/archive/OpenSSL_1_1_1-stable.zip
unzip OpenSSL_1_1_1-stable.zip
cd openssl-OpenSSL_1_1_1-stable
./config enable-tls1_3 --prefix=/usr/local/openssl
make && make install

HTTPS

HTTPS = HTTP over SSL/TLS. Two authentication modes are common:

One‑Way Authentication

Client sends TLS version, cipher suites, random.

Server returns its certificate.

Client validates the certificate (expiry, CA trust, signature, domain).

Client and server negotiate a symmetric cipher, exchange Pre‑Master secret, derive Master Secret, and encrypt subsequent traffic.

Two‑Way Authentication

Same as one‑way, but the server also requests a client certificate, and the client presents its own certificate for verification.

TLS SNI Extension

SNI (Server Name Indication) allows the client to indicate the hostname during the TLS handshake, enabling virtual hosting with multiple certificates on a single IP.

ESNI (Encrypted SNI)

ESNI encrypts the hostname inside ClientHello to protect privacy. The server’s DNS record must publish an ESNI public key, which the client uses to encrypt the SNI.

Upgrading curl for HTTP/2 and TLS 1.3

Compile Installation

# Install build tools
yum -y groupinstall "Development Tools"
yum -y install libev libev-devel zlib zlib-devel openssl openssl-devel git

# Build OpenSSL 1.0.2 (example)
mkdir /var/tmp && cd /var/tmp
wget https://openssl.org/source/openssl-1.0.2.tar.gz
tar -zxf openssl-1.0.2.tar.gz
cd openssl-1.0.2
./config --prefix=/opt/openssl
make && make install

# Build nghttp2
git clone https://github.com/tatsuhiro-t/nghttp2.git
cd nghttp2
autoreconf -i && ./configure && make && make install

# Build curl with OpenSSL and nghttp2
cd /var/tmp
git clone https://github.com/bagder/curl.git
cd curl
./buildconf
./configure --with-ssl=/opt/openssl --with-nghttp2=/usr/local --disable-shared --disable-file
make

YUM Upgrade

rpm -ivh http://mirror.city-fan.org/ftp/contrib/yum-repo/city-fan.org-release-1-13.rhel6.noarch.rpm
yum upgrade libcurl
rpm -e city-fan.org-release

Common curl Options

-A/--user-agent <string>: Set User‑Agent header.

-e/--referer <URL>: Set Referer header.

--cacert <file>: Specify CA certificate.

-k/--insecure: Skip certificate verification.

--compressed: Request compressed response.

-H/--header <line>: Add custom header.

-i: Show response headers.

-I/--head: Show only headers.

-D/--dump-header <file>: Save headers to file.

--basic: Use HTTP Basic authentication.

-u/--user <user[:password]>: Set server credentials.

-L: Follow redirects.

-O: Save file with remote name.

-o <file>: Save output to specified file.

--limit-rate <rate>: Limit transfer speed.

-0/--http1.0: Use HTTP 1.0.

-v/--verbose: Verbose output.

-C: Enable resume.

-c/--cookie-jar <file>: Store cookies.

-x/--proxy <host[:port]>: Use proxy.

-X/--request <command>: Specify request method.

-U/--proxy-user <user:password>: Proxy authentication.

-T: Upload file to FTP.

--data/-d: Send POST data.

-b name=data: Send cookie data.

curl with SNI

curl \
  --cacert /root/CA/nginx1.com/cacert.pem \
  -X GET "https://webserver.com:8443/" \
  -H "Content-type: application/json" \
  -H "Accept: application/json" \
  -H "host: nginx1.com"

curl with --resolve (no DNS)

curl \
  --cacert /root/CA/nginx1.com/cacert.pem \
  --resolve webserver.com:8443:127.0.0.1 \
  -X GET "https://webserver.com:8443/" \
  -H "Content-type: application/json" \
  -H "Accept: application/json" \
  -H "host: nginx1.com"
SSL/TLS diagram
SSL/TLS diagram
TLS 1.2 handshake
TLS 1.2 handshake
TLS 1.3 handshake
TLS 1.3 handshake
network securityOpenSSLTLScertificateSSLPKI
AI Cyberspace
Written by

AI Cyberspace

AI, big data, cloud computing, and networking.

0 followers
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.