Communication and Network Security practice questions

Use of TKIP for encryption

Why it fails: The use of Temporal Key Integrity Protocol (TKIP) for encryption is explicitly deprecated and not supported in WPA3, as TKIP was designed as a stopgap measure for WPA to address WEP's weaknesses and has known cryptographic vulnerabilities. TKIP's design includes flaws that make it susceptible to various attacks, including key recovery and message injection, rendering it insecure for modern wireless networks. WPA3 exclusively mandates robust encryption algorithms like GCMP-256 (Galois/Counter Mode Protocol with 256-bit keys) to provide strong confidentiality and integrity.

Support for WEP compatibility

Why it fails: WPA3 explicitly drops support for Wired Equivalent Privacy (WEP) compatibility because WEP is an obsolete and fundamentally insecure encryption protocol with severe cryptographic weaknesses. WEP's vulnerabilities, such as its weak initialization vector (IV) usage and static key management, allow for trivial key recovery and data decryption by attackers using readily available tools. Maintaining compatibility would introduce critical security holes into WPA3 networks, thus its removal is essential for ensuring a secure baseline.

Backward compatibility with SSL 3.0

Why it fails: TLS 1.3 intentionally removes backward compatibility with older, insecure protocols like SSL 3.0. This decision was made to eliminate known vulnerabilities, such as the POODLE attack, which exploited weaknesses in SSL 3.0's padding oracle. By dropping support for deprecated versions, TLS 1.3 ensures that connections cannot downgrade to less secure cryptographic standards, thereby enforcing a higher baseline security posture and protecting against known exploits.

Use of RSA key exchange for authentication

Why it fails: TLS 1.3 explicitly removes support for static RSA key exchange mechanisms. This removal is a critical step towards mandating forward secrecy, as static RSA key exchange does not provide this essential property. If a server's long-term private RSA key were compromised, all past communications encrypted with keys derived from that static exchange could be retroactively decrypted, a risk TLS 1.3 mitigates by prioritizing ephemeral key exchanges.

Support for RC4 stream cipher

Why it fails: The RC4 stream cipher is explicitly prohibited and removed from TLS 1.3's suite of supported algorithms. RC4 has known cryptographic weaknesses, including biases in its keystream generation, which can lead to recovery of plaintext data through statistical analysis after a sufficient number of encrypted messages. Its removal is part of TLS 1.3's broader effort to eliminate all known weak or compromised cryptographic primitives, ensuring only robust algorithms are used.

Using SSH protocol version 1

Why it fails: SSH-1 is deprecated and insecure, but the question asks for features to disable/manage; version 1 is not a feature but a protocol version that should not be used at all. The best answers are X11 and port forwarding.

Public-key authentication

Why it fails: Public-key authentication is a highly secure method for authenticating SSH users, relying on cryptographic key pairs rather than passwords. This approach significantly enhances security by eliminating the transmission of sensitive credentials over the network, making it resistant to brute-force attacks and credential stuffing. Far from being a risk to disable, it is a recommended best practice that organizations should actively encourage and implement to strengthen their remote access security posture.

Using SSH protocol version 2

Why it fails: SSH protocol version 2 is the current, secure standard for remote administration, offering robust cryptographic algorithms for encryption, integrity checking, and authentication. It was developed to address numerous security vulnerabilities present in its predecessor, SSH-1, such as weak key exchange and integrity protection. Therefore, using SSHv2 is not a risk to be managed by disabling; rather, it is the fundamental secure protocol that organizations should mandate for all SSH communications.

WPA3 replaces PSK with SAE and uses GCMP-256 encryption.

Why it fails: WPA3 significantly enhances wireless security by replacing the vulnerable Pre-Shared Key (PSK) authentication with Simultaneous Authentication of Equals (SAE) for personal mode. SAE provides robust protection against offline dictionary attacks and ensures forward secrecy through its Dragonfly Key Exchange, meaning compromise of a long-term key does not compromise past session keys. Furthermore, WPA3 mandates the use of GCMP-256, a stronger encryption algorithm, to protect wireless traffic, moving beyond the limitations of WPA2's AES-CCMP.

WPA3 uses TKIP for backward compatibility.

Why it fails: This statement is incorrect because WPA3 explicitly deprecates and removes support for TKIP (Temporal Key Integrity Protocol). TKIP, introduced with WPA and carried over for backward compatibility in WPA2, is known to have significant cryptographic vulnerabilities that make it unsuitable for modern secure networks. WPA3's design prioritizes strong security, requiring only robust AES-based encryption methods like GCMP-256 or AES-CCMP in transition modes, thereby eliminating any reliance on the outdated TKIP.

WPA3 uses AES-CCMP as the mandatory encryption method.

Why it fails: While AES-CCMP (Advanced Encryption Standard in Counter Mode with CBC-MAC Protocol) is the mandatory encryption method for WPA2, it is not the mandatory standard for WPA3. WPA3 elevates the baseline security by mandating GCMP-256 (Galois/Counter Mode Protocol with 256-bit keys) for its most secure operations, particularly in WPA3-Personal. Although AES-CCMP can still be supported in WPA3 transition modes for backward compatibility with WPA2 devices, it is not the primary or mandatory encryption for new WPA3 connections.

WPA3 eliminates the need for 802.1X authentication.

Why it fails: This statement is false; WPA3 does not eliminate the need for 802.1X authentication; rather, it continues to fully support and enhance it for enterprise environments. While WPA3-Personal utilizes SAE for stronger password-based authentication, WPA3-Enterprise relies on 802.1X with EAP (Extensible Authentication Protocol) to provide robust, centralized user and device authentication, often integrating with RADIUS servers. This distinction ensures that large organizations can still leverage their existing identity management infrastructure while benefiting from WPA3's cryptographic improvements.

Segment the network using VLANs, placing web servers and database servers in separate VLANs with no inter-VLAN routing.

Why it fails: Separate VLANs with no inter-VLAN routing would prevent any communication between web servers and database servers, which is not feasible because the web application needs to query the databases. This would break functionality. The goal is to allow necessary traffic while blocking unauthorized access.

Place the database servers in the same DMZ as the web servers but use host-based firewalls on the database servers.

Why it fails: Placing databases in the same DMZ as web servers increases risk because a compromised web server can directly attack the databases without crossing a network boundary. Host-based firewalls add some protection but do not provide the same isolation as network segmentation. This violates the principle of defense in depth.

Use a reverse proxy in the DMZ to handle all client requests, and configure the web servers to only accept connections from the reverse proxy.

Why it fails: A reverse proxy can protect web servers from direct exposure, but it does not prevent a compromised web server from accessing internal databases. The question asks about preventing access to internal databases after web server compromise. This control focuses on protecting the web servers, not the databases.

Layer 3 – Network

Why it fails: The Network layer (Layer 3) is primarily responsible for logical addressing (IP addresses) and routing packets across different networks, enabling communication between distinct subnets. While ARP (Address Resolution Protocol) resolves IP addresses to MAC addresses, it operates at the layer below Layer 3 to facilitate communication *within* a local network segment, not for inter-network routing decisions. ARP spoofing manipulates this L3-to-L2 mapping, but the attack itself targets the Data Link layer protocol responsible for this resolution.

Layer 1 – Physical

Why it fails: The Physical layer (Layer 1) focuses on the raw, unstructured transmission of bits over physical media, defining electrical, mechanical, procedural, and functional specifications for activating, maintaining, and deactivating physical links. Attacks at this layer typically involve physical manipulation of cables, jamming radio signals, or disrupting power supplies. ARP spoofing, however, is a logical attack that manipulates protocol messages and address mappings, not the fundamental physical transmission medium or its characteristics.

Layer 4 – Transport

Why it fails: The Transport layer (Layer 4) is responsible for end-to-end communication between applications, managing connection establishment, data segmentation, flow control, and error recovery using protocols like TCP and UDP. Its primary function is to ensure reliable and ordered delivery of data between processes on source and destination hosts. ARP spoofing does not directly interfere with these end-to-end application-level connections or data streams; instead, it targets the underlying mechanism used to deliver packets to the correct host within a local segment.

L2TP/IPsec

Why it fails: L2TP/IPsec, while capable of providing perfect forward secrecy and utilising elliptic curve cryptography via IKEv2, does not represent the most modern protocol known for an efficient, minimal codebase. L2TP is an older tunnelling protocol, which, when combined with IPsec, typically results in a heavier implementation compared to newer alternatives. This option is tempting because IPsec is a robust, widely adopted security framework offering strong encryption and authentication, making it a common choice for enterprise remote access and site-to-site VPNs where broad interoperability is prioritised.

PPTP

Why it fails: Point-to-Point Tunneling Protocol (PPTP) is an outdated VPN protocol that relies on weak authentication mechanisms like MS-CHAPv2, which is highly vulnerable to offline dictionary and brute-force attacks. It completely lacks Perfect Forward Secrecy (PFS), meaning that if a long-term key is ever compromised, all past session traffic encrypted with that key can be decrypted. Its inherent security flaws and legacy status make it unsuitable for any modern secure communication requirement.

IPsec with IKEv2

Why it fails: While IPsec with IKEv2 is a robust and widely adopted VPN framework capable of providing strong security and Perfect Forward Secrecy (PFS) when properly configured, it is not inherently designed around Elliptic Curve Cryptography (ECC) as its primary cryptographic primitive. Its larger and more complex codebase, compared to WireGuard, can introduce a greater attack surface and often requires more intricate configuration for optimal security and performance. Although powerful, its general-purpose nature means it isn't as streamlined or efficient for simple remote access VPNs as newer, purpose-built protocols.

Stateful inspection firewall

Why it fails: A stateful inspection firewall, also known as a dynamic packet filter, maintains a state table for active connections. It tracks the source and destination IP addresses, port numbers, and sequence numbers for TCP sessions, allowing return traffic to pass without explicit outbound rules. This advanced capability goes beyond the basic IP/port filtering described, which doesn't mention tracking connection states.

Application proxy firewall

Why it fails: An application proxy firewall operates at the application layer (Layer 7 of the OSI model), acting as an intermediary for specific application protocols like HTTP or FTP. It terminates the connection from the client, inspects the application-layer payload for malicious content or policy violations, and then establishes a new connection to the destination server. This level of deep content inspection is far more sophisticated than merely filtering based on IP addresses and port numbers.

Next-generation firewall

Why it fails: A next-generation firewall (NGFW) integrates multiple security capabilities beyond traditional port/protocol inspection, including deep packet inspection, intrusion prevention systems (IPS), application awareness and control, and identity-based policies. While it can perform basic IP/port filtering, its core strength lies in its ability to understand and control applications regardless of port, and detect advanced threats, making it significantly more complex than the simple filtering described.

Layer 7 – Application

Why it fails: Port scanning via SYN packets operates at Layer 4, where TCP headers and port numbers are processed; Layer 7 concerns application protocols such as HTTP. It is tempting because open ports ultimately serve application services, and application-layer firewalls inspect payloads, but the SYN/ACK response itself is a transport-layer artefact.

Layer 3 – Network

Why it fails: Layer 3 routes packets using IP addresses and does not expose TCP port numbers or SYN flags, which belong to Layer 4 (Transport). It is tempting because SYN packets are IP packets, and Layer 3 would be correct for analysing ICMP sweeps, IP fragmentation or routing-based reconnaissance.

Layer 2 – Data Link

Why it fails: TCP SYN scanning reads TCP header flags and port numbers, which are Layer 4 (Transport) constructs; Layer 2 addresses frames via MAC addresses and does not interpret ports. It is tempting because frames carry the encapsulated packets, and Layer 2 would be correct for analysing MAC flooding, ARP spoofing or switch CAM-table attacks.

S/MIME

Why it fails: S/MIME (Secure/Multipurpose Internet Mail Extensions) provides cryptographic security services for electronic messaging, including authentication, integrity, non-repudiation, and confidentiality. It achieves this by using a hierarchical Public Key Infrastructure (PKI) where trusted Certificate Authorities (CAs) issue and manage digital certificates. While S/MIME effectively secures email content, its reliance on a centralized PKI for key validation differs significantly from the decentralized trust model of PGP/GPG.

TLS

Why it fails: Transport Layer Security (TLS) is a cryptographic protocol designed to provide secure communication over a computer network. When applied to email, TLS encrypts the *connection* between a mail client and a server (e.g., SMTP, POP3, IMAP over TLS) or between two mail servers (MTA-to-MTA). However, TLS does not provide end-to-end encryption of the email *message content* itself; the message can be decrypted and re-encrypted at intermediate servers, making it vulnerable at those points.

SSH

Why it fails: Secure Shell (SSH) is a cryptographic network protocol for operating network services securely over an unsecured network. Its primary applications include remote command-line login, remote command execution, and secure file transfer (SFTP/SCP). SSH is fundamentally designed for securing interactive sessions and data transfers between specific endpoints, not for encrypting or signing email messages or securing the underlying email protocols like SMTP, POP3, or IMAP.

MD5 for authentication, no privacy

Why it fails: MD5 is a cryptographically weaker hashing algorithm, making it more susceptible to collision attacks and compromising message integrity. Furthermore, the complete absence of a privacy mechanism means that all monitored data is transmitted in plaintext, leaving it vulnerable to eavesdropping and disclosure by any party with network access, which is unacceptable for secure network management.

SHA for authentication, no privacy

Why it fails: Despite using SHA for stronger authentication compared to MD5, the critical lack of a privacy component means that all SNMP messages, including potentially sensitive network statistics and configuration details, are transmitted unencrypted. This exposes the data to passive wiretapping and unauthorized disclosure, failing to meet fundamental confidentiality requirements for secure network monitoring.

MD5 for authentication, DES for privacy

Why it fails: Both MD5 and DES are considered cryptographically weak algorithms in modern security contexts. MD5 is vulnerable to collision attacks, which can compromise message integrity and authentication, while DES, with its 56-bit key, is easily broken by modern computing power. Relying on these outdated algorithms provides inadequate protection for sensitive network management traffic against determined adversaries, despite offering both authentication and privacy.

WEP

Why it fails: WEP (Wired Equivalent Privacy) does not replace the pre-shared key; instead, it fundamentally relies on a static, shared secret key for both authentication and encryption. Its design flaws, including the use of a weak RC4 stream cipher with a short initialization vector (IV) that is often reused, make it highly susceptible to various attacks, such as IV collision attacks and key recovery. WEP offers no forward secrecy and is considered completely insecure, making it an unsuitable and deprecated protocol for modern wireless security.

WPA2 with TKIP

Why it fails: WPA2 with TKIP (Temporal Key Integrity Protocol) does not replace the pre-shared key; rather, it was introduced as an interim solution to provide some WEP-like compatibility and improve upon WEP's weaknesses without requiring new hardware. While WPA2 itself can use PSK or 802.1X for key management, TKIP is known to have vulnerabilities and is largely deprecated. It still relies on the underlying WPA2 key exchange, which, in the case of WPA2-Personal, is a PSK-based 4-way handshake, not a replacement for it.

WPA2 with CCMP

Why it fails: WPA2 with CCMP (Counter Mode with Cipher Block Chaining Message Authentication Code Protocol) is the robust and preferred security protocol for WPA2, providing strong encryption and integrity using AES. However, it does not replace the pre-shared key mechanism but rather uses it as one of its primary key establishment methods in WPA2-Personal mode. The 4-way handshake in WPA2-Personal, whether using CCMP or TKIP, derives session keys from a pre-shared key, making it susceptible to offline dictionary attacks if the PSK is weak.

Deauthentication attack

Why it fails: A deauthentication attack involves an attacker sending forged deauthentication frames to one or more clients, or to the access point itself, impersonating either the client or the AP. This forces legitimate clients to disconnect from the wireless network, causing a denial of service. While it can be a precursor to other attacks, such as forcing a client to reconnect to a rogue AP, a deauthentication attack itself does not directly capture network credentials but rather disrupts service.

Rogue AP attack

Why it fails: A rogue AP attack involves an unauthorized access point installed on a network, often by an insider, or an attacker setting up an AP to lure unsuspecting users. This AP could be configured with any SSID and might not necessarily mimic an existing legitimate network. While an evil twin is a type of rogue AP, the term "rogue AP attack" is a broader category that doesn't specifically describe the act of impersonating a known, legitimate network's SSID to capture credentials.

Karma attack

Why it fails: A Karma attack operates by responding positively to *any* probe request sent by a client device, regardless of the SSID the client is searching for. This allows the malicious access point to trick clients into connecting to it by pretending to be any network the client has previously connected to. While it aims to lure clients, it differs from an evil twin in that it doesn't necessarily impersonate a *specific* legitimate network's SSID but rather exploits client behavior to connect to *any* known network.

Micro-segmentation

Why it fails: Micro-segmentation controls east-west traffic between workloads inside a data centre using software-defined policies, but it does not create a physically or logically isolated perimeter network for internet-facing servers. The stem requires a DMZ architecture that separates public servers from the internal LAN while permitting controlled inbound traffic. Micro-segmentation is tempting because it enforces granular access controls between application tiers, and it would be correct for limiting lateral movement within a private cloud environment, not for isolating external-facing services from an internal network.

VPN

Why it fails: A Virtual Private Network (VPN) primarily establishes secure, encrypted connections over an untrusted network, like the internet, to provide remote users or branch offices with secure access to internal resources. While VPNs enhance confidentiality and integrity for data in transit, they do not inherently provide network segmentation for public-facing servers or isolate them from an internal network. Their function is secure connectivity, not architectural isolation of public services from the LAN.

VLAN

Why it fails: A Virtual Local Area Network (VLAN) logically segments a single physical network into multiple broadcast domains at Layer 2, improving network performance and security by separating traffic. However, VLANs alone do not provide the robust security architecture required to isolate public-facing servers from an internal network with controlled internet access. While a DMZ might utilize VLANs for internal segmentation within its zone, a VLAN itself does not establish the necessary perimeter defense and firewall-based access controls for internet-exposed services.

Hashing of DNS responses without keys

Why it fails: Hashing alone provides integrity checking, ensuring data has not been tampered with in transit. However, without a cryptographic key or digital signature, hashing does not verify the *origin* of the DNS response. DNSSEC's core function is to authenticate that the DNS data originated from the authoritative source, which simple unkeyed hashing cannot achieve, leaving responses vulnerable to spoofing.

Transport Layer Security for DNS

Why it fails: Transport Layer Security (TLS), often used in DNS over TLS (DoT), secures the communication channel between a DNS client and a recursive resolver. While TLS encrypts and authenticates the *connection*, it does not provide end-to-end data origin authentication for the DNS records themselves, which is DNSSEC's specific role. DNSSEC operates at the DNS data layer, verifying the authenticity of the records within the zone, independent of the transport layer security.

Symmetric encryption of DNS queries

Why it fails: DNSSEC's primary objective is to authenticate the origin and ensure the integrity of DNS data, not to provide confidentiality for DNS queries. Symmetric encryption would encrypt the content of DNS queries, hiding them from eavesdroppers, but this is outside the scope of DNSSEC's design. DNSSEC uses asymmetric cryptography for digital signatures to validate data, rather than symmetric encryption to obscure query traffic, which is a function typically addressed by protocols like DNS over TLS.

Support for RC4 encryption

Why it fails: RC4 is a stream cipher that was widely used in older TLS versions but has been explicitly removed from TLS 1.3. Its removal is due to significant cryptographic weaknesses, including biases in its keystream generation, which made it susceptible to various attacks like the "Bar Mitzvah" attack. TLS 1.3 mandates the use of modern, authenticated encryption with associated data (AEAD) ciphers, rendering RC4 obsolete and insecure for contemporary secure communications.

Support for DES and 3DES

Why it fails: DES (Data Encryption Standard) and its successor, 3DES (Triple DES), are symmetric block ciphers that have been deprecated and removed from TLS 1.3. DES, with its small 56-bit key, is easily breakable, while 3DES, despite its triple encryption, suffers from a small block size (64-bit). This small block size makes 3DES vulnerable to birthday attacks, such as the SWEET32 attack, which can recover plaintext from large volumes of encrypted data, thus compromising confidentiality.

Use of static RSA key exchange

Why it fails: The use of static RSA key exchange has been completely removed in TLS 1.3 due to its critical security flaw: the lack of forward secrecy. With static RSA, the same private key is used to derive session keys for multiple sessions, meaning that if the server's long-term private key is ever compromised, all past communications encrypted using that key could be retroactively decrypted. TLS 1.3 exclusively mandates ephemeral key exchange methods like DHE or ECDHE to ensure that session keys are unique and temporary.

Trust but verify

Why it fails: Zero-trust replaces 'trust but verify' with continuous verification of every request regardless of prior trust. It is tempting because it sounds security-conscious and describes traditional perimeter defence, and would be correct where an established trusted zone is revalidated periodically rather than each access being independently authenticated and authorised.

Trust internal users implicitly

Why it fails: Implicit trust for internal users is exactly what zero-trust removes; BeyondCorp authenticates and authorises every user and device per request. It is tempting because legacy perimeter models assumed insider trust, and would apply where a hardened internal network segment is protected by firewalls and VPN alone.

Trust network location as a primary factor

Why it fails: Zero-trust treats network location as untrusted, so it cannot serve as a primary authentication factor; identity and device posture drive access instead. It is tempting because perimeter security historically relied on being inside the corporate network, and would be correct for a traditional castle-and-moat design.

IKE (Internet Key Exchange)

Why it fails: IKE handles key exchange, not packet protection.

ISAKMP

Why it fails: ISAKMP defines the framework for negotiating security associations and key exchange; it carries no packet encryption itself, so it cannot encrypt the entire IP packet. It is correct for setting up the tunnel, whereas ESP performs the authentication and encryption in tunnel mode.

AH (Authentication Header)

Why it fails: AH provides authentication and integrity only; it does not encrypt payloads, so it cannot satisfy the requirement for encryption of the entire IP packet. It is tempting because AH does authenticate the whole packet including the outer IP header, making it the right choice when integrity protection without confidentiality is required.

Packet filter firewall

Why it fails: A packet filter firewall operates at the network and transport layers (OSI Layers 3 and 4), making decisions based solely on header information such as source/destination IP addresses, port numbers, and protocol types. It examines individual packets in isolation without understanding the context of a connection or the content within the data payload. Consequently, it lacks the ability to inspect application-layer protocols or the actual data being transmitted by applications.

Application proxy firewall

Why it fails: An application proxy firewall, also known as a gateway firewall, functions at the application layer by acting as an intermediary for specific application protocols like HTTP or FTP. It terminates the client connection, inspects the application-level data, and then establishes a new connection to the server. While it effectively inspects application data for predefined protocols, its capabilities are often limited to those specific applications and it typically does not include the broad, integrated security services such as full SSL decryption or advanced intrusion prevention systems that are standard in NGFWs.

Stateful firewall

Why it fails: A stateful firewall maintains a state table to track the status of active network connections, allowing it to permit legitimate return traffic for established sessions based on source/destination IP addresses and port numbers. While it provides enhanced security over packet filters by understanding connection context, its inspection capabilities are primarily confined to Layer 3 and Layer 4 headers. It does not analyze the actual content within the data payload or understand application-layer protocols, thus it cannot inspect application data.

The public key is used to decrypt the session

Why it fails: The public key's role in SSH authentication is to encrypt a challenge issued by the server, which can only be decrypted by the corresponding private key held by the client. Session decryption, however, is handled by symmetric encryption algorithms using a shared session key established during the initial key exchange. The public key is not directly involved in decrypting the ongoing data stream of the SSH session itself. Its function is specifically for proving identity during the authentication phase.

Public-key authentication does not require a passphrase

Why it fails: While the SSH protocol does not technically mandate a passphrase for a private key to function, employing one is a critical security best practice. A passphrase encrypts the private key file itself, providing an additional layer of protection against unauthorized use should the key file be stolen or accessed by an attacker. Without a passphrase, a compromised private key can be immediately used to authenticate, whereas a passphrase requires an attacker to also crack that secret. This significantly enhances the overall security posture.

The private key is stored on the server

Why it fails: The private key must always reside securely on the client machine, never on the server, as it is the user's secret credential for proving identity. Conversely, the public key is stored on the server in the authorized_keys file, allowing the server to verify the client's authenticity without ever needing the private key. This fundamental separation ensures that the client retains sole control over its authentication secret, preventing the server from ever possessing the means to impersonate the client. Storing the private key on the server would negate the security benefits of asymmetric authentication.