Secure Network Protocols (HTTPS, SFTP, SRTP)

Secure network protocols are communication protocols that incorporate encryption, authentication, and integrity checks to protect data transmitted over a network. The three protocols covered here—HTTPS, SFTP, and SRTP—are each designed for different types of data: web traffic, file transfers, and real-time multimedia streams.

What it is: HTTPS is HTTP over TLS (Transport Layer Security). It protects web browsing by encrypting the entire HTTP request and response, including URLs, headers, and body. HTTPS uses port 443 by default.

How it works: 1. Client (browser) connects to server on port 443. 2. Server presents its TLS certificate (X.509) containing its public key. 3. Client verifies the certificate against a trusted Certificate Authority (CA). 4. Client and server perform a key exchange (e.g., Diffie-Hellman) to derive a symmetric session key. 5. All subsequent HTTP data is encrypted with that session key (e.g., AES-256-GCM). 6. Integrity is ensured via message authentication codes (MACs) like HMAC-SHA256.

Key components: - TLS 1.3 (RFC 8446) is the current standard; TLS 1.2 is still common. - Cipher suites: e.g., TLS_AES_256_GCM_SHA384. - Certificate validation: chain of trust, revocation checks (CRL, OCSP).

Attack vectors: - Man-in-the-middle (MITM) via rogue certificates or CA compromise. - SSL stripping (downgrading HTTPS to HTTP). - POODLE attack (CVE-2014-3566) against SSL 3.0.

Defense: - Use HSTS (HTTP Strict Transport Security) header to enforce HTTPS. - Pin certificates or use Certificate Transparency. - Disable old protocols (SSL, TLS 1.0/1.1).

Real command example:

# Test TLS configuration
openssl s_client -connect example.com:443 -tls1_3

What it is: SFTP is a secure file transfer protocol that runs over SSH (Secure Shell). It is not related to FTP; it is a separate protocol that provides file access, transfer, and management over a secure channel. SFTP uses port 22 by default (same as SSH).

How it works: 1. Client initiates an SSH connection to the server on port 22. 2. Server authenticates via password, public key, or other methods. 3. SSH establishes an encrypted tunnel using key exchange (e.g., Diffie-Hellman) and symmetric encryption (e.g., AES-256-CTR). 4. Within this tunnel, SFTP commands and data are exchanged. 5. SFTP supports resuming transfers, directory listings, and file permissions.

Key components: - SSH-2 protocol (RFC 4251). - Authentication methods: password, public key (RSA, ECDSA, Ed25519), keyboard-interactive. - File integrity via HMAC.

Attack vectors: - Brute-force SSH passwords. - Man-in-the-middle if host key verification is skipped. - Weak cipher suites (e.g., CBC mode).

Defense: - Disable password authentication; use key-based authentication. - Use strong algorithms (e.g., chacha20-poly1305@openssh.com). - Implement fail2ban or rate-limiting.

Real command example:

# Secure file transfer
sftp user@host
# Inside sftp:
get remote_file local_file
put local_file remote_file

What it is: SRTP is a security profile for RTP (Real-time Transport Protocol) used for VoIP, video conferencing, and streaming media. It provides encryption, message authentication, and replay protection. SRTP is defined in RFC 3711.

How it works: 1. RTP packets are generated by the media application. 2. SRTP encrypts the RTP payload (media data) using a symmetric cipher (e.g., AES-128 in counter mode). 3. A message authentication code (e.g., HMAC-SHA1) is appended to each packet for integrity. 4. A sequence number is used to prevent replay attacks. 5. Key management is typically handled by a separate protocol like ZRTP or MIKEY.

Key components: - Encryption: AES-128 or AES-256 in Counter (CTR) or F8 mode. - Authentication: HMAC-SHA1 (80-bit or 32-bit tag). - Master key and session keys derived from a keying protocol.

Attack vectors: - Replay attacks if sequence numbers are not checked. - Key compromise via weak key exchange. - Denial of service via invalid packets.

Defense: - Use strong key management (e.g., ZRTP with Diffie-Hellman). - Always enable authentication (not just encryption). - Monitor for unusual sequence number gaps.

Real tool example:

# Using tshark to filter SRTP traffic
tshark -r capture.pcap -Y "srtp"

Scenario 1: E-commerce Website HTTPS Misconfiguration

A SOC analyst notices that a company's e-commerce site is still using TLS 1.0. Using a tool like openssl s_client, they confirm the vulnerability. The analyst reports this as a critical finding because TLS 1.0 is deprecated and vulnerable to attacks like BEAST (CVE-2011-3389). The correct response is to disable TLS 1.0/1.1 and enable TLS 1.2/1.3 on the web server. A common mistake is to assume that simply having HTTPS is sufficient, ignoring protocol versions. The analyst should also check for HSTS headers and proper certificate chain.

Scenario 2: Secure File Transfer with SFTP

An IT engineer needs to transfer sensitive customer data to a partner. They choose SFTP over FTP. The engineer configures the SFTP server to only accept key-based authentication and disables password logins. They also restrict ciphers to aes256-ctr and hmac-sha2-256. However, they forget to verify the partner's host key, leading to a potential MITM. The correct procedure is to exchange host keys out-of-band and verify fingerprints. A common mistake is using FTP instead of SFTP for simplicity, leaving data in plaintext.

Scenario 3: VoIP Security with SRTP

A company deploys VoIP phones for internal calls. The network team enables SRTP for encryption but forgets to enable authentication (only encryption). An attacker can tamper with the audio stream without detection. The correct configuration is to use SRTP with both encryption and authentication (e.g., AES-128-CM + HMAC-SHA1). Tools like Wireshark can be used to verify that SRTP packets include an authentication tag. A common mistake is assuming encryption alone provides integrity.