Chapter 11 — Secure Protocols, Email Security, DNS Security, and Application Protections

Secure protocol

A secure protocol protects network communication using security features such as encryption, authentication, and integrity checking.Example: An administrator uses an encrypted remote-management protocol instead of a clear-text one.Memory trick: Secure protocol = protected conversation.Trick question tip: Encryption, protected login data, certificates, and secure alternatives are secure-protocol clues.

Insecure protocol

An insecure protocol transmits data without adequate protection, often exposing information in clear text.Example: A legacy remote-management protocol sends commands and login information without encryption.Memory trick: Insecure means readable on the wire.Trick question tip: Clear text, easy packet inspection, and legacy protocol design indicate insecure communication.

Clear text

Clear text is readable data transmitted or stored without encryption.Example: A captured packet reveals the content of an unprotected login request.Memory trick: Clear text = anyone who sees it can read it.Trick question tip: If intercepted traffic can be read directly, the protocol lacks confidentiality protection.

HTTP

Hypertext Transfer Protocol is an insecure web protocol that does not encrypt web traffic by default.Example: A basic webpage request is sent without transport encryption.Memory trick: HTTP has no secure S.Trick question tip: HTTP commonly uses TCP port 80 and should not be used for sensitive data.

HTTPS

Hypertext Transfer Protocol Secure protects web communication using SSL/TLS encryption.Example: A user submits login information through a protected web session.Memory trick: HTTPS = HTTP secured.Trick question tip: HTTPS commonly uses TCP port 443 and is preferred for websites handling sensitive data.

HTTP vs HTTPS

HTTP sends web traffic without built-in encryption, while HTTPS protects web traffic using SSL/TLS.Example: A login page should use HTTPS rather than HTTP.Memory trick: The S means secure.Trick question tip: Sensitive form data, credentials, and browser security warnings point to HTTPS.

Telnet

Telnet is an insecure remote-access protocol that transmits session data in clear text.Example: An administrator avoids Telnet because intercepted traffic could reveal login information and commands.Memory trick: Telnet tells everything.Trick question tip: Telnet should be replaced with SSH for secure remote administration.

Secure Shell (SSH)

Secure Shell is a secure remote-administration protocol that encrypts logins, commands, and session traffic.Example: A network engineer uses SSH to manage a router securely.Memory trick: SSH = secure shell session.Trick question tip: Choose SSH instead of Telnet when remote command-line management must be protected.

Telnet vs SSH

Telnet sends remote-management traffic in clear text, while SSH encrypts the management session.Example: A server administrator disables Telnet and permits SSH for remote access.Memory trick: Telnet exposes; SSH encrypts.Trick question tip: Remote-management credentials and commands require SSH, not Telnet.

SSL/TLS certificate

An SSL/TLS certificate helps prove a server’s identity and supports encrypted HTTPS communication.Example: A web server presents a valid certificate during a protected browser session.Memory trick: Certificate proves who the server claims to be.Trick question tip: HTTPS configuration requires a valid certificate installed and maintained correctly.

Certificate Authority (CA)

A Certificate Authority is a trusted entity that issues digital certificates used to support secure communication.Example: An organization obtains a certificate from a trusted CA for its web service.Memory trick: CA signs trust into certificates.Trick question tip: Public trust for HTTPS commonly depends on a trusted CA.

Certificate expiration

Certificate expiration occurs when a certificate reaches the end of its validity period and must be renewed or replaced.Example: A web service generates browser warnings because its certificate was not renewed on time.Memory trick: Certificates have expiration dates.Trick question tip: Expired certificates can break trust even when encryption settings are otherwise correct.

Certificate management

Certificate management includes obtaining, installing, configuring, monitoring, renewing, and revoking certificates.Example: Administrators track certificate expiration dates to prevent service disruptions.Memory trick: Certificates need lifecycle care.Trick question tip: Secure protocols often fail because certificates are misconfigured, expired, or not trusted.

Cryptographic key handling

Cryptographic key handling includes creating, storing, distributing, protecting, and revoking keys used by secure protocols.Example: Private keys are stored securely so unauthorized users cannot decrypt protected communication.Memory trick: Protect the keys that protect the data.Trick question tip: Strong encryption is weakened if keys are poorly managed.

Encryption overhead

Encryption overhead is the additional processing and management effort required to encrypt and decrypt network traffic.Example: A secure service requires certificate configuration and key management before deployment.Memory trick: Security adds work, but protects data.Trick question tip: Complexity is not a valid reason to use insecure protocols without documented justification.

Secure protocol complexity

Secure protocols are often more complex to deploy, troubleshoot, and maintain than insecure protocols.Example: HTTPS requires certificate installation, proper configuration, and renewal planning.Memory trick: Secure setup takes more care.Trick question tip: Complexity increases misconfiguration risk but does not remove the need for secure protocols.

Secure protocol troubleshooting challenge

Secure protocols can be harder to troubleshoot because encrypted packets cannot be easily read during normal packet inspection.Example: An administrator must rely on logs and approved tools instead of simply reading protected packet contents.Memory trick: Encryption hides data from attackers and admins.Trick question tip: Encryption improves confidentiality but can reduce visibility during troubleshooting.

Secure protocol misconfiguration

A secure protocol misconfiguration occurs when security settings are incorrectly applied, weakening protection or breaking access.Example: A server uses an invalid certificate and causes users to receive trust warnings.Memory trick: Secure settings must be correct to be secure.Trick question tip: Misconfigured encryption, certificates, ports, or authentication can undermine secure protocols.

Default protocol port

A default protocol port is the standard network port normally associated with a protocol.Example: HTTP commonly uses port 80, while HTTPS commonly uses port 443.Memory trick: Default port = usual service number.Trick question tip: Changing a default port does not make an insecure protocol secure.

Port 80

Port 80 is commonly associated with HTTP web traffic.Example: A firewall rule allowing TCP port 80 permits ordinary HTTP traffic.Memory trick: 80 = HTTP.Trick question tip: HTTP on port 80 does not protect sensitive information by default.

Port 443

Port 443 is commonly associated with HTTPS web traffic.Example: A firewall allows TCP port 443 for protected web sessions.Memory trick: 443 = HTTPS.Trick question tip: Opening port 443 allows HTTPS traffic but does not prove the web application is secure.

Changing default ports

Changing default ports moves a service away from its commonly expected port but does not provide real cryptographic security.Example: An administrator changes a management service port but still uses a secure protocol and strong authentication.Memory trick: Moving the door is not locking the door.Trick question tip: Port changes may obscure a service but should not replace hardening or secure protocols.

Security through obscurity

Security through obscurity attempts to hide a system or service detail instead of directly securing it.Example: A service is moved to a nonstandard port but still requires encryption and access controls.Memory trick: Hiding is not the same as protecting.Trick question tip: Obscurity may slow discovery but should not be the primary control.

Transmission Control Protocol (TCP)

Transmission Control Protocol is a connection-oriented transport protocol that provides reliability, ordering, and error checking.Example: A secure web session uses TCP because reliable delivery matters.Memory trick: TCP checks and orders the conversation.Trick question tip: Reliability, ordering, and connection-oriented communication indicate TCP.

User Datagram Protocol (UDP)

User Datagram Protocol is a connectionless transport protocol that prioritizes speed and low overhead over guaranteed delivery.Example: Real-time communication may use UDP because occasional packet loss is less disruptive than delay.Memory trick: UDP sends fast without a full conversation setup.Trick question tip: Streaming, gaming, voice, and connectionless traffic often point to UDP.

TCP vs UDP

TCP provides reliable, ordered, connection-oriented delivery, while UDP provides faster, connectionless delivery without the same reliability guarantees.Example: File transfer favors TCP, while real-time media may favor UDP.Memory trick: TCP is reliable; UDP is quick.Trick question tip: Match the transport method to reliability versus performance needs.

Protocol selection

Protocol selection is the process of choosing communication methods based on data sensitivity, security requirements, performance, compatibility, and cost.Example: Sensitive file transfer uses a secure protocol instead of an unencrypted legacy method.Memory trick: Choose protocol by risk and purpose.Trick question tip: Sensitive or private data should trigger secure protocol selection.

Data sensitivity

Data sensitivity describes how much protection information requires based on its value, privacy, or potential impact if exposed.Example: Login credentials and private form data require secure transmission.Memory trick: More sensitive data needs stronger protection.Trick question tip: Sensitive data should not be sent over clear-text protocols.

Secure protocol documentation

Secure protocol decisions should be documented to support audits, compliance, baselines, and configuration management.Example: A standard documents which protocols are allowed for remote administration.Memory trick: Document the secure choice and why.Trick question tip: Formal protocol selection affects baselines and configuration management systems.

Risk assessment for protocol selection

Risk assessment evaluates threats, data sensitivity, business needs, and impact before selecting or approving protocols.Example: A team rejects clear-text management protocols after assessing credential-exposure risk.Memory trick: Risk decides how much protection is needed.Trick question tip: Secure protocol choices should be based on documented risk, not convenience.

Policy review for protocol selection

Policy review ensures selected protocols align with organizational security requirements and acceptable-use rules.Example: A policy requires encrypted protocols for administration and sensitive user data.Memory trick: Protocol choices must match policy.Trick question tip: Policy drives allowed protocols and exceptions.

Security baseline impact

Protocol-selection decisions affect secure baselines by defining which communication methods are approved or prohibited.Example: A server baseline requires HTTPS and SSH while disabling HTTP management and Telnet.Memory trick: Baseline turns protocol decisions into standard settings.Trick question tip: Approved protocol choices should become configuration requirements.

Configuration management impact

Protocol decisions affect configuration management because approved settings must be deployed, tracked, and maintained consistently.Example: Automation disables insecure protocols across managed servers.Memory trick: Decide once, enforce everywhere.Trick question tip: Configuration management helps prevent insecure protocol drift.

Secure protocol exception

A secure protocol exception is a documented justification for using an insecure protocol when a secure alternative is not feasible.Example: A legacy device requires temporary use of an insecure protocol while replacement is planned.Memory trick: Exception means documented risk, not convenience.Trick question tip: Insecure protocols should require specific justification and compensating controls.

Secure File Transfer Protocol (SFTP)

Secure File Transfer Protocol provides secure file transfer over SSH.Example: Administrators use SFTP to move sensitive files securely between systems.Memory trick: SFTP = file transfer through SSH.Trick question tip: Do not confuse SFTP with FTPS; both protect file transfer differently.

File Transfer Protocol Secure (FTPS)

File Transfer Protocol Secure protects FTP communication using SSL/TLS.Example: A business partner transfers files using an FTP service protected with TLS.Memory trick: FTPS = FTP plus TLS.Trick question tip: FTPS uses SSL/TLS, while SFTP uses SSH.

SFTP vs FTPS

SFTP secures file transfer through SSH, while FTPS secures FTP using SSL/TLS.Example: One organization chooses SFTP for SSH-based administration workflows, while another uses FTPS for TLS-protected file transfer.Memory trick: SFTP rides SSH; FTPS rides TLS.Trick question tip: The similar names are a common Security+ trap.

Secure protocol balance

Secure protocol selection balances security, maintainability, performance, and cost.Example: A team chooses a secure protocol that meets confidentiality requirements without creating unacceptable performance issues.Memory trick: Secure enough and manageable enough.Trick question tip: The best answer often balances protection with operational requirements.

Secure protocols as default

Organizations should use secure protocols by default unless a specific documented justification supports an insecure alternative.Example: New services are deployed with encrypted management and user access enabled.Memory trick: Secure unless proven otherwise.Trick question tip: “Convenient” or “easier to troubleshoot” is not enough justification for clear-text protocols.

Secure protocol defense in depth

Secure protocol use should be combined with proper certificate management, strong authentication, key protection, firewall rules, monitoring, and configuration baselines.Example: A web service uses HTTPS, a valid certificate, strong access controls, and monitored configuration settings.Memory trick: Encrypt, authenticate, manage keys, monitor, maintain.Trick question tip: A secure protocol is only one layer of protection and must be configured and maintained correctly.

Small accuracy note: SSL is deprecated and should not be used; modern secure deployments use TLS, especially TLS 1.2 or TLS 1.3 depending on requirements and support.

Here’s Chapter 11 Safe Version, Part 2 for 11.1.2 Transport Layer Security. Copy from the code box.

Transport Layer Security (TLS)

Transport Layer Security is a cryptographic protocol that protects network communication by providing encryption, authentication, and integrity.<b>Example:</b> A website uses TLS to protect login credentials submitted through a browser.<b>Memory trick:</b> TLS protects data in transit.<b>Trick question tip:</b> HTTPS, certificates, cipher suites, and encrypted sessions are TLS clues.

Secure Sockets Layer (SSL)

Secure Sockets Layer is the older predecessor to TLS and is no longer considered safe for modern secure communication.<b>Example:</b> A server disables SSL support and allows only approved TLS versions.<b>Memory trick:</b> SSL is old; TLS is current.<b>Trick question tip:</b> If the exam asks for the secure modern choice, choose TLS instead of SSL.

SSL vs TLS

SSL is the deprecated older protocol, while TLS is the modern protocol used to secure network communications.<b>Example:</b> A company replaces legacy SSL settings with TLS 1.2 or TLS 1.3.<b>Memory trick:</b> SSL started it; TLS replaced it.<b>Trick question tip:</b> The term SSL may still appear informally, but TLS is the safe protocol family.

HTTP security problem

HTTP does not encrypt traffic by default, so intercepted requests and responses may be readable.<b>Example:</b> A login form sent over plain HTTP could expose credentials to someone capturing traffic.<b>Memory trick:</b> HTTP is readable web traffic.<b>Trick question tip:</b> Sensitive web data should use HTTPS, not HTTP.

HTTPS

Hypertext Transfer Protocol Secure is HTTP protected with TLS.<b>Example:</b> A browser uses HTTPS to submit private form data securely.<b>Memory trick:</b> HTTPS = HTTP plus TLS.<b>Trick question tip:</b> HTTPS commonly uses TCP port 443 and is indicated by a protected URL and browser security indicators.

HTTPS port

HTTPS uses TCP port 443 by default.<b>Example:</b> A firewall rule permits TCP 443 for secure web traffic.<b>Memory trick:</b> 443 = secure web.<b>Trick question tip:</b> HTTP commonly uses 80, while HTTPS commonly uses 443.

HTTPS URL indicator

An HTTPS URL begins with a protected web scheme that indicates the browser is using TLS for the connection.<b>Example:</b> A user confirms the protected web scheme before submitting credentials.<b>Memory trick:</b> Secure web address starts with secure web protocol.<b>Trick question tip:</b> Browser indicators help users recognize protected sessions but do not prove the site itself is trustworthy.

Browser padlock icon

A browser padlock icon indicates that the browser has established an encrypted HTTPS connection with a certificate it accepts.<b>Example:</b> A user sees a padlock before entering information on a web form.<b>Memory trick:</b> Padlock means encrypted connection.<b>Trick question tip:</b> A padlock confirms transport encryption, not that the business or page content is safe.

TLS digital certificate

A TLS digital certificate binds a server identity to a public key and is signed by a certificate authority.<b>Example:</b> A web server presents a certificate so the browser can verify the server identity.<b>Memory trick:</b> Certificate links identity to key.<b>Trick question tip:</b> Certificates support authentication and key trust, not just encryption.

Certificate Authority (CA)

A Certificate Authority is a trusted entity that signs certificates so clients can validate server identity.<b>Example:</b> A browser trusts a website certificate because it chains to a trusted CA.<b>Memory trick:</b> CA says, “This key belongs to this identity.”<b>Trick question tip:</b> Client trust depends on whether the issuing CA is trusted.

Server authentication

Server authentication proves the identity of a server to a client using a trusted certificate.<b>Example:</b> A browser validates the certificate before creating a secure session with a website.<b>Memory trick:</b> Server proves who it is.<b>Trick question tip:</b> Standard HTTPS usually authenticates the server, not necessarily the client.

Public/private key pair

A public/private key pair consists of a public key shared with others and a private key kept secret by its owner.<b>Example:</b> A server certificate contains the public key while the private key remains protected on the server.<b>Memory trick:</b> Public shares; private stays secret.<b>Trick question tip:</b> If the private key is exposed, the certificate and protected sessions are at risk.

TLS session negotiation

TLS session negotiation is the process where client and server agree on supported protocol settings and create protected communication keys.<b>Example:</b> A browser and server select compatible algorithms before exchanging encrypted data.<b>Memory trick:</b> Agree first, encrypt second.<b>Trick question tip:</b> TLS negotiation includes protocol version, supported algorithms, and key establishment.

TLS handshake

The TLS handshake is the setup process that authenticates parties as required, negotiates security parameters, and establishes session keys.<b>Example:</b> A browser performs a handshake before displaying protected web content.<b>Memory trick:</b> Handshake sets up the secure conversation.<b>Trick question tip:</b> Fewer handshake messages and faster setup are TLS 1.3 improvements.

Cipher suite

A cipher suite is a named set of cryptographic algorithms used by TLS to protect a session.<b>Example:</b> A server and client agree on a cipher suite that supports approved encryption and hashing.<b>Memory trick:</b> Cipher suite = crypto recipe.<b>Trick question tip:</b> Cipher suites define algorithms, not the application protocol itself.

Cipher-suite preference

Cipher-suite preference determines which supported cipher suites are selected first during negotiation.<b>Example:</b> A server lists stronger approved suites before weaker compatible ones.<b>Memory trick:</b> Preferred suites are offered first.<b>Trick question tip:</b> Strong configuration disables weak suites rather than merely listing them later.

Legacy cipher suite

A legacy cipher suite may use older or weaker algorithms that should be disabled in secure environments.<b>Example:</b> Administrators remove weak legacy options from a server’s supported cipher list.<b>Memory trick:</b> Old crypto invites downgrade risk.<b>Trick question tip:</b> Secure TLS configuration requires disabling insecure versions and weak algorithms.

TLS downgrade attack

A downgrade attack attempts to force a connection to use a weaker protocol version or weaker cipher suite.<b>Example:</b> An on-path attacker tries to make a client and server use an older insecure TLS version.<b>Memory trick:</b> Downgrade means force weaker security.<b>Trick question tip:</b> Blocking old versions and weak algorithms helps prevent downgrade attacks.

On-path attacker

An on-path attacker can intercept, relay, or modify communication between two parties.<b>Example:</b> An attacker positioned between a client and server attempts to alter TLS negotiation.<b>Memory trick:</b> On path = standing between both sides.<b>Trick question tip:</b> Downgrade and person-in-the-middle scenarios often involve an on-path attacker.

TLS 1.0 and TLS 1.1

TLS 1.0 and TLS 1.1 are legacy TLS versions that should not be used for modern secure deployments.<b>Example:</b> A security baseline disables TLS 1.0 and TLS 1.1 on public-facing services.<b>Memory trick:</b> Early TLS versions are outdated.<b>Trick question tip:</b> Legacy-client compatibility can weaken security.

TLS 1.2

TLS 1.2 is a widely supported TLS version that can provide strong security when configured with approved cipher suites.<b>Example:</b> A server allows TLS 1.2 using only strong modern cipher suites.<b>Memory trick:</b> TLS 1.2 can be secure when configured well.<b>Trick question tip:</b> TLS 1.2 security depends heavily on disabling weak algorithms and options.

TLS 1.3

TLS 1.3 is a modern TLS version that removes many insecure legacy features and improves handshake efficiency.<b>Example:</b> A web service enables TLS 1.3 to reduce use of older weak negotiation options.<b>Memory trick:</b> TLS 1.3 = cleaner, faster, safer TLS.<b>Trick question tip:</b> TLS 1.3 reduces downgrade risk and simplifies supported cipher suites.

TLS 1.3 downgrade protection

TLS 1.3 helps prevent downgrade attacks by removing insecure legacy algorithms and features from the protocol.<b>Example:</b> A server using TLS 1.3 does not negotiate SSL 3.0 features.<b>Memory trick:</b> TLS 1.3 refuses old weak baggage.<b>Trick question tip:</b> Preventing use of insecure previous-version features is a TLS 1.3 clue.

TLS 1.3 handshake improvement

TLS 1.3 reduces the number of handshake messages required to establish a secure connection.<b>Example:</b> A client connects more quickly because fewer setup exchanges are needed.<b>Memory trick:</b> Fewer messages, faster setup.<b>Trick question tip:</b> Speeding up secure connection setup is a TLS 1.3 benefit.

TLS version downgrade support risk

Allowing older protocol versions for legacy clients can weaken the overall security of a service.<b>Example:</b> A server that supports TLS 1.2 but also permits older versions may be exposed to downgrade risk.<b>Memory trick:</b> Backward compatibility can drag security backward.<b>Trick question tip:</b> Supporting legacy clients is convenient but less secure.

Mutual authentication

Mutual authentication occurs when both sides authenticate each other, often using certificates on both the server and the client.<b>Example:</b> A VPN requires the server and client device to present valid certificates.<b>Memory trick:</b> Both sides prove identity.<b>Trick question tip:</b> Client certificates and enterprise VPN scenarios often indicate mutual authentication.

Client certificate

A client certificate is installed on a user device or client system so the server can authenticate the client.<b>Example:</b> An enterprise network requires a managed laptop certificate before allowing access.<b>Memory trick:</b> Client certificate lets the client prove itself.<b>Trick question tip:</b> Client certificates are less common for ordinary websites but common in VPNs and enterprise networks.

TLS for VPN

TLS can be used to secure virtual private network connections by encrypting traffic and authenticating endpoints.<b>Example:</b> A remote worker connects through a TLS-protected VPN service.<b>Memory trick:</b> TLS can secure more than websites.<b>Trick question tip:</b> TLS is not limited to HTTPS.

TLS for other protocols

TLS can protect application protocols beyond HTTP when supported and properly configured.<b>Example:</b> A service adds TLS to protect transmitted application data.<b>Memory trick:</b> TLS is a security layer for many apps.<b>Trick question tip:</b> HTTPS is the common example, but TLS can secure other protocols too.

Key agreement

Key agreement is the process that allows two parties to establish shared secret material used to protect a session.<b>Example:</b> A TLS handshake establishes session keys without sending the final symmetric key directly.<b>Memory trick:</b> Agree on a secret without exposing it.<b>Trick question tip:</b> Diffie-Hellman-style methods are used for session key agreement.

Elliptic Curve Diffie-Hellman Ephemeral (ECDHE)

Elliptic Curve Diffie-Hellman Ephemeral is a temporary key-agreement method that helps create session keys with forward secrecy.<b>Example:</b> A TLS 1.2 cipher suite uses ECDHE during session setup.<b>Memory trick:</b> Ephemeral means temporary session secrets.<b>Trick question tip:</b> ECDHE in a cipher suite indicates ephemeral key agreement.

Ephemeral key agreement

Ephemeral key agreement uses temporary key material for each session rather than reusing long-term key material directly.<b>Example:</b> A new session creates fresh key material that is discarded afterward.<b>Memory trick:</b> Ephemeral = short-lived.<b>Trick question tip:</b> Ephemeral key agreement supports forward secrecy.

Forward secrecy

Forward secrecy protects past sessions even if a long-term private key is compromised later.<b>Example:</b> An attacker who steals a server private key cannot decrypt previously captured sessions that used proper ephemeral key agreement.<b>Memory trick:</b> Past sessions stay secret.<b>Trick question tip:</b> Ephemeral Diffie-Hellman methods are associated with forward secrecy.

RSA signature in TLS

RSA signatures can be used to authenticate the server’s certificate-based identity in TLS.<b>Example:</b> A TLS 1.2 cipher suite includes RSA for authentication signatures.<b>Memory trick:</b> RSA can sign identity proof.<b>Trick question tip:</b> In older-style TLS cipher suites, RSA often appears as the signature or authentication algorithm.

AES-GCM

AES-GCM is an authenticated-encryption mode that provides confidentiality and integrity for protected data.<b>Example:</b> A TLS cipher suite uses AES-GCM for symmetric encryption of session traffic.<b>Memory trick:</b> GCM encrypts and checks integrity.<b>Trick question tip:</b> AES-GCM is used for bulk encryption in modern TLS cipher suites.

Bulk encryption

Bulk encryption is the symmetric encryption used to protect the main application data after the TLS session is established.<b>Example:</b> After the handshake, TLS uses symmetric encryption to protect transmitted web data.<b>Memory trick:</b> Bulk encryption protects the actual session data.<b>Trick question tip:</b> Asymmetric cryptography helps setup and authentication; symmetric cryptography protects most session traffic.

Symmetric session key

A symmetric session key is a temporary shared key used to encrypt and decrypt traffic during one protected session.<b>Example:</b> A TLS session uses derived symmetric keys after handshake completion.<b>Memory trick:</b> Session key = temporary traffic key.<b>Trick question tip:</b> Session keys are negotiated or derived, not manually typed by users during HTTPS browsing.

Hash-based Message Authentication Code (HMAC)

HMAC uses a cryptographic hash and a secret key to verify message integrity and authenticity.<b>Example:</b> A pre-TLS 1.3 cipher suite lists SHA for HMAC functions.<b>Memory trick:</b> HMAC checks that the message was not changed.<b>Trick question tip:</b> HMAC provides integrity, not bulk encryption.

Secure Hash Algorithm (SHA)

Secure Hash Algorithm is a family of cryptographic hash functions used in TLS-related integrity and key-derivation operations.<b>Example:</b> A TLS cipher suite lists SHA256 or SHA384 as the hash component.<b>Memory trick:</b> SHA creates a fixed-size digest.<b>Trick question tip:</b> SHA in a cipher suite is a hash function, not the symmetric encryption algorithm.

TLS 1.2 cipher suite format

A TLS 1.2-style cipher suite commonly lists key agreement, authentication, bulk encryption, encryption mode, and hash function.<b>Example:</b> One suite name shows ECDHE for key agreement, RSA for authentication, AES-GCM for encryption, and SHA for hashing.<b>Memory trick:</b> Older suite names list the full crypto recipe.<b>Trick question tip:</b> Pre-TLS 1.3 cipher suites are longer and include more algorithm roles.

TLS 1.3 cipher suite format

A TLS 1.3 cipher suite name is shorter because key agreement is ephemeral and certificate signature type is handled separately.<b>Example:</b> A TLS 1.3 suite lists AES-GCM and SHA but not ECDHE or RSA in the suite name.<b>Memory trick:</b> TLS 1.3 suite names are simplified.<b>Trick question tip:</b> TLS 1.3 cipher suites usually list bulk encryption and hash only.

TLS_AES_256_GCM_SHA384

TLS_AES_256_GCM_SHA384 is a TLS 1.3 cipher suite using AES-256-GCM and SHA384.<b>Example:</b> A TLS 1.3 connection negotiates this suite for protected communication.<b>Memory trick:</b> AES-256-GCM protects; SHA384 supports hashing.<b>Trick question tip:</b> The shorter format strongly indicates TLS 1.3.

TLS_AES_128_GCM_SHA256

TLS_AES_128_GCM_SHA256 is a TLS 1.3 cipher suite using AES-128-GCM and SHA256.<b>Example:</b> A packet capture shows TLS 1.3 using this shortened cipher-suite format.<b>Memory trick:</b> Short TLS suite = TLS 1.3 style.<b>Trick question tip:</b> AES_128_GCM is the bulk encryption portion, and SHA256 is the hash portion.

Hash-based Key Derivation Function (HKDF)

HKDF is used in TLS 1.3 to derive symmetric session keys from shared secret material.<b>Example:</b> After key agreement establishes shared secret material, HKDF derives keys for protecting traffic.<b>Memory trick:</b> HKDF turns shared secret into session keys.<b>Trick question tip:</b> HKDF is key derivation, not the encryption algorithm itself.

Diffie-Hellman shared secret

A Diffie-Hellman shared secret is secret material independently computed by both parties during key agreement.<b>Example:</b> Client and server use key-agreement values to produce matching shared secret material.<b>Memory trick:</b> Both sides calculate the same secret.<b>Trick question tip:</b> The shared secret is used to derive session keys rather than being sent directly.

Wireshark TLS analysis

Wireshark can show TLS handshake metadata such as version and selected cipher suite, but encrypted application data is not normally readable.<b>Example:</b> A packet capture shows TLS 1.3 and the selected cipher suite.<b>Memory trick:</b> See the handshake, not the protected contents.<b>Trick question tip:</b> Encryption limits packet-content visibility during troubleshooting.

TLS inspection limitation

TLS protects confidentiality, which means ordinary packet capture cannot easily show application payload content.<b>Example:</b> Troubleshooting a secure web issue requires logs or approved inspection methods instead of simply reading packet contents.<b>Memory trick:</b> TLS hides the payload.<b>Trick question tip:</b> TLS improves privacy but complicates traffic inspection.

TLS configuration baseline

A TLS configuration baseline defines approved versions, cipher suites, certificates, and related secure settings for protected services.<b>Example:</b> A server baseline disables SSL and older TLS versions while permitting approved TLS 1.2 and TLS 1.3 suites.<b>Memory trick:</b> Baseline tells TLS what is allowed.<b>Trick question tip:</b> Secure TLS requires configuration management, not just turning HTTPS on.

TLS defense in depth

TLS should be combined with trusted certificates, protected private keys, secure cipher suites, current protocol versions, monitoring, and renewal processes.<b>Example:</b> A website uses TLS 1.3, a valid certificate, strong cipher suites, and certificate-expiration monitoring.<b>Memory trick:</b> TLS needs versions, keys, certs, and care.<b>Trick question tip:</b> TLS protects transport, but weak configuration or expired certificates can still break security.

Network directory

A network directory stores information about network subjects, objects, and the permissions that control access between them.<b>Example:</b> A directory lists users, computers, services, files, and access permissions.<b>Memory trick:</b> Directory = network phonebook plus permissions.<b>Trick question tip:</b> Users, computers, services, objects, authentication, and authorization point to directory services.

Directory subject

A directory subject is an active entity such as a user, computer, or service that can request access to resources.<b>Example:</b> A user account authenticates before accessing a shared folder.<b>Memory trick:</b> Subject does the action.<b>Trick question tip:</b> Users, computers, and services are subjects because they request access.

Directory object

A directory object is a resource or stored item managed by the directory, such as a file, folder, printer, computer record, or group.<b>Example:</b> A shared directory has permissions assigned to specific users and groups.<b>Memory trick:</b> Object is what gets accessed or managed.<b>Trick question tip:</b> Files, folders, groups, and resource records are directory objects.

Directory permissions

Directory permissions define what actions subjects are allowed to perform on objects.<b>Example:</b> One group can read a shared folder, while another group can modify it.<b>Memory trick:</b> Permissions say who can do what.<b>Trick question tip:</b> Access rights over directory objects indicate authorization.

Directory authentication

Directory authentication verifies the identity of a subject before granting access to directory-managed resources.<b>Example:</b> A user signs in with credentials before accessing network resources.<b>Memory trick:</b> Authentication asks, “Who are you?”<b>Trick question tip:</b> Verifying identity is authentication, not authorization.

Directory authorization

Directory authorization determines what an authenticated subject is allowed to access or modify.<b>Example:</b> A user can read one folder but cannot update another folder.<b>Memory trick:</b> Authorization asks, “What can you do?”<b>Trick question tip:</b> Permissions, access levels, and allowed actions indicate authorization.

Directory service security

A directory service must be strongly protected because it controls authentication, authorization, identities, and permissions across the network.<b>Example:</b> Administrators restrict directory access and secure directory communication.<b>Memory trick:</b> Protect the system that decides access.<b>Trick question tip:</b> If the directory is compromised, many accounts and resources may be affected.