Cyber Security Quiz: Tls Https
10 questions · exam conditions
0:00
Tls HttpsQuestion 1 of 10

A workstation is infected with malware that can read browser memory and capture keystrokes. The user then signs in to a correctly configured HTTPS service with a valid certificate.

Which outcome is most consistent with the protection HTTPS provides?

The password remains protected because HTTPS encrypts it before either the keyboard driver or browser can access it
The malware can capture the password or session data at the endpoint even though network traffic is protected in transit
The malware can read only certificate information because TLS keeps application data encrypted within browser memory
The login fails automatically because TLS detects endpoint malware as part of server certificate validation
← Back to quizzes

Cyber Security Quiz

Cyber Security Quiz: Tls Https

Practice Tls Https in Cyber Security with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Tls Https, giving you a quick way to practice the rules, question types, and explanations that matter most for Cyber Security.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A workstation is infected with malware that can read browser memory and capture keystrokes. The user then signs in to a correctly configured HTTPS service with a valid certificate.

Which outcome is most consistent with the protection HTTPS provides?

  1. The password remains protected because HTTPS encrypts it before either the keyboard driver or browser can access it
  2. The malware can capture the password or session data at the endpoint even though network traffic is protected in transit (correct answer)
  3. The malware can read only certificate information because TLS keeps application data encrypted within browser memory
  4. The login fails automatically because TLS detects endpoint malware as part of server certificate validation
Explanation: When tackling questions about HTTPS and TLS, the critical framework is understanding where protection applies — specifically, that encryption governs data in transit across the network, not data at the endpoints where it originates or terminates. HTTPS/TLS creates an encrypted tunnel between the browser and the server, preventing eavesdroppers on the network from reading your credentials. However, that encryption only kicks in after the browser has already processed the plaintext input. A keylogger captures your password at the keyboard driver level — before TLS ever touches it. Similarly, malware with browser memory access can extract credentials or session tokens directly from RAM, completely bypassing network-layer protections. This is why B is correct: the malware exploits the endpoint, which TLS was never designed to protect. A describes something physically impossible. HTTPS encryption happens at the transport layer, well after your keyboard input travels through the OS and into the browser. The keyboard driver and browser both handle plaintext — TLS has no presence there. C is a seductive distractor because TLS does encrypt application data in transit, but it doesn't maintain encrypted storage within browser memory; that memory is accessible to processes with sufficient privileges. D invents a capability TLS simply doesn't have — certificate validation authenticates the server's identity, not the security state of the client endpoint. Malware detection is not part of the TLS handshake. The study tip here: always ask "at what layer does this protection operate?" HTTPS secures the wire, not the machine. Endpoint security (antivirus, EDR tools) is an entirely separate defense layer.

Question 2

An online portal uses an ordinary server-authenticated HTTPS connection. It has no client certificates. After TLS is established, the application asks users for a password and checks their permissions before displaying records.

Why are the application's login and authorization checks still necessary?

  1. Server-authenticated TLS normally validates the server to the client, but it does not identify the user or decide which records the user may access (correct answer)
  2. TLS identifies the user from the device's IP address, but the application must translate that identity into a password before use
  3. TLS authenticates both parties automatically, but application checks are needed only to strengthen the encryption algorithm
  4. TLS provides authorization without authentication, so the password is required only to validate the portal's certificate chain
Explanation: When you see a question mixing TLS with application-layer security, ask yourself: what layer handles what? TLS and application logic operate independently, and confusing their responsibilities is a classic exam trap. TLS in server-authenticated mode does one specific job — it verifies to the client that the server is who it claims to be (via certificate) and establishes an encrypted channel. That's it. TLS says nothing about who the human on the other end is or what they're allowed to do. Those concerns belong to the application layer. This is exactly why A is correct: the login check identifies the user, and the authorization check decides which records that user may see — neither of which TLS handles. B is wrong because TLS does not use IP addresses to identify users. IP addresses aren't part of TLS authentication at all, and the idea that a password "translates" an IP identity is fabricated — it doesn't reflect how either protocol works. C is wrong on two counts. First, server-authenticated TLS does not authenticate both parties — only the server is authenticated (there are no client certificates here). Second, application checks have nothing to do with the encryption algorithm's strength; they are identity and access controls, not cryptographic enhancements. D reverses the definitions entirely. TLS provides authentication (of the server), not authorization. Authorization — deciding what an authenticated entity may access — is an application concern. Saying TLS provides authorization "without authentication" is backwards and nonsensical. A good study rule: always separate who encrypts the channel (TLS) from who authenticates the user and who enforces permissions (the application). These are distinct layers with distinct responsibilities.

Question 3

While visiting an internal payroll site, an employee receives a certificate-name mismatch warning. The employee selects the browser option to continue anyway. An attacker is intercepting the connection and forwarding requests to the real payroll server.

Which statement best describes the resulting security risk?

  1. The connection remains safe because TLS encryption prevents an intermediary from reading data even when certificate validation fails
  2. The attacker may terminate one encrypted connection and create another, allowing access to or modification of payroll traffic (correct answer)
  3. Only availability is affected because a certificate-name mismatch can interrupt service but cannot expose protected information
  4. Only the payroll server is at risk because the browser's local certificate warning does not affect data sent by the employee
Explanation: When you see a question involving certificate warnings and intercepted connections, think about what TLS actually protects — and what it requires to work. TLS encryption is only meaningful when you've verified who you're encrypting to. A certificate-name mismatch warning is your browser telling you it cannot confirm the server's identity, which is precisely the condition an attacker exploits in a man-in-the-middle (MITM) attack. Here's why B is correct: when an attacker sits between the browser and the payroll server, they can terminate the browser's TLS session on their own machine, read or modify the plaintext data, then re-encrypt it and forward it to the real server. The employee sees a functioning connection; the payroll server receives seemingly normal requests — but the attacker has full visibility into credentials, salary data, and any changes submitted. By ignoring the mismatch warning, the employee essentially handed the attacker a valid interception point. A is dangerously wrong — it's the most tempting trap. TLS encryption does protect data, but only when certificate validation succeeds. Without validation, you don't know whose key you're encrypting to, so the encryption protects the attacker's tunnel, not yours. C is wrong because confidentiality and integrity are both compromised, not just availability — the attacker can read and alter data. D incorrectly shifts risk entirely to the server; in reality, the employee's submitted data (passwords, banking details) is the primary exposure. Remember this pattern: encryption without authentication is not security. On exam questions, anytime certificate validation is bypassed, treat the connection as unencrypted from a trust perspective.

Question 4

A medical application sends patient forms to its server exclusively through correctly configured HTTPS. The server later stores the submitted forms in an unencrypted database and includes sensitive fields in plaintext diagnostic logs.

Which statement best characterizes the protection in this system?

  1. HTTPS protects the forms in transit, but separate controls are needed for database storage, logs, backups, and server access (correct answer)
  2. HTTPS protects the forms after arrival because data received through TLS remains cryptographically marked as encrypted on the server
  3. HTTPS protects the database but not the logs because TLS encryption applies automatically to structured storage systems rather than flat text files
  4. HTTPS provides no useful protection here because confidentiality must cover both transit and storage simultaneously to be effective in either location
Explanation: When a question describes a system with multiple data handling stages, your job is to evaluate each stage independently — transit, storage, logs, backups, and access controls are all separate attack surfaces that each require their own protections. HTTPS (which uses TLS) is a transport-layer control. It encrypts data while it moves between a client and server. Once that data arrives at the server and TLS terminates, the encryption is gone — the server decrypts it so it can actually process the content. What happens to that data afterward is entirely outside HTTPS's scope. So in this scenario, HTTPS does its job correctly during transit, but the unencrypted database and plaintext logs represent real, separate vulnerabilities that HTTPS was never designed to address. A captures this precisely: transit protection exists, but storage-at-rest encryption, log sanitization, backup controls, and access management are all independently necessary. B is based on a fundamental misconception — TLS does not leave a "cryptographic mark" on data after delivery. Once decrypted at the server, the data is plaintext. There is no residual encryption. C invents a distinction that doesn't exist. TLS has no automatic applicability to databases over flat files; neither storage type inherits any protection from transport encryption. D goes too far in the wrong direction. Partial protection is still meaningful. HTTPS genuinely prevents interception during transit — that's a real security gain, even if storage is unprotected. The study tip here: on security exams, never let one strong control imply coverage of others. Ask yourself, "at what point does this control start and stop?" Each data lifecycle phase needs its own answer.

Question 5

An HTTPS page loads a JavaScript library using an explicit http:// URL. Assume the browser permits this active mixed content rather than blocking or upgrading it. An attacker can modify traffic on the user's local network but cannot break TLS.

What is the most significant risk?

  1. The attacker can modify the HTTP-delivered script, which can then alter page behavior or access data available to that page (correct answer)
  2. The attacker can decrypt the HTTPS document because loading one HTTP resource reveals the page's TLS session keys
  3. The attacker can replace only images and styles because scripts inherit the encryption status of the main HTTPS document
  4. The attacker can observe that a script was requested, but TLS authenticates all resources referenced by an HTTPS page
Explanation: When an HTTPS page loads resources over plain HTTP, you're in the territory of mixed content — a critical web security concept. The key question to ask is: what can an attacker who controls the network actually do with an unencrypted resource? Because the JavaScript library travels over HTTP, it has no integrity protection. A network attacker performing a man-in-the-middle attack can intercept that HTTP response and inject arbitrary code before it reaches the browser. Since JavaScript runs in the context of the parent page, that injected script inherits full access to the page's DOM, cookies, form fields, and any sensitive data the HTTPS page contains. This makes A the correct answer — a tampered script is effectively a complete compromise of the page, regardless of the main document's encryption. Choice B describes something that doesn't exist. TLS session keys are never exposed by the content of a page or its sub-resources. Loading one HTTP resource doesn't reveal cryptographic secrets for the HTTPS connection — these are completely separate mechanisms. Choice C is backwards. Scripts are more dangerous than images or styles precisely because they execute code. Mixed content rules are actually stricter for scripts (called "active mixed content") than for passive resources like images. Scripts absolutely do not inherit the encryption of the parent document. Choice D is wrong on two counts: TLS only authenticates and encrypts the resources delivered over HTTPS. It provides zero protection for HTTP sub-resources, and an attacker can do far more than merely observe the request — they can modify the response. Study tip: Remember the phrase "active mixed content = full page compromise." If a script loads over HTTP inside an HTTPS page, the attacker owns the whole page.

Question 6

A user types example.com into a browser on a hostile network. The browser first requests http://example.com, and the server normally redirects that request to HTTPS. The browser has no cached HSTS policy for the site, and the domain is not preloaded for HSTS.

Which attack remains possible before a validated HTTPS connection is established?

  1. The attacker can forge a trusted certificate for the site merely by modifying the server's HTTP redirect response
  2. The attacker can modify the later HTTPS response without detection because the session began with an HTTP request
  3. The attacker can derive the site's TLS private key from the plaintext HTTP request and decrypt later HTTPS sessions
  4. The attacker can suppress or alter the unprotected redirect and attempt to keep the user on an HTTP version of the site (correct answer)
Explanation: When a browser visits a site over HTTP before any HSTS policy is in place, that initial request travels completely unprotected — and that's the vulnerability this question is testing. Think about what an on-path attacker (someone between you and the server) can actually do versus what the underlying protocols actually allow. The redirect from HTTP to HTTPS is just a plain HTTP response (typically a 301 or 302). Because it's unencrypted and unauthenticated, an attacker sitting on a hostile network can intercept it and do one of two things: strip it entirely or replace it with a response that keeps the user on HTTP. This is the classic SSL stripping attack, and it's exactly what D describes — the attacker suppresses or alters the unprotected redirect before a secure channel is ever established. HSTS exists precisely to prevent this, but only after a policy has been cached or preloaded. Answer A is wrong because TLS certificates are issued by Certificate Authorities through a rigorous validation process entirely independent of HTTP responses. An attacker modifying a redirect cannot influence CA trust chains whatsoever. Answer B is wrong because HTTPS security is independent of how the session started. Once a valid TLS handshake completes with a trusted certificate, the encrypted channel is fully secure regardless of prior HTTP activity. Answer C is wrong and reflects a fundamental misunderstanding of cryptography. The plaintext HTTP request contains no TLS private key material — private keys never leave the server, and observing HTTP traffic gives an attacker nothing useful for breaking TLS. Study tip: When you see questions about HSTS, always ask "has the policy been established yet?" If not, that first HTTP hop is exposed — and SSL stripping is the canonical threat to remember.

Question 7

A company places a cloud load balancer in front of an application. Clients use HTTPS to the load balancer, which decrypts each request and forwards it to the application server over unencrypted HTTP on the company's internal network. Users see a valid padlock.

Which assessment of this design is most accurate?

  1. The padlock proves the request remains encrypted until the application processes it, regardless of load-balancer settings
  2. TLS protects only the internal segment because the load balancer transfers its certificate protection to the application server
  3. TLS protects the client-to-load-balancer segment, but traffic on the internal HTTP segment can be read or altered there (correct answer)
  4. The request is exposed only inside the user's browser because HTTP forwarding automatically re-encrypts data on private networks
Explanation: When a load balancer terminates TLS, it creates two separate communication legs, not one continuous encrypted tunnel. Understanding this split is the key to answering any question about TLS offloading or SSL termination. Ask yourself: where does encryption start, and where does it end? In this design, encryption exists only between the client and the load balancer. The load balancer decrypts the request, then forwards it as plain HTTP to the application server. That internal segment is unprotected, meaning anyone with access to that network — a compromised host, a misconfigured switch, or a malicious insider — can read or modify the traffic in transit. Answer C correctly identifies this boundary: TLS covers the first leg, but the internal HTTP segment is exposed. Answer A is wrong because the padlock icon reflects only the client's connection to the load balancer. It makes no claim whatsoever about what happens after decryption. The padlock is scoped to one hop, not the entire request lifecycle. Answer B inverts reality — TLS certificates are not transferable objects that travel with the data. Once the load balancer decrypts traffic, the certificate's protection ends there; nothing is "transferred" to the application server. Answer D is a classic trap: private or internal networks are not automatically encrypted. HTTP is HTTP regardless of whether the network is public or private; it sends data in plaintext. As a study habit, always trace the full path of data in architecture questions — from client to final destination — and identify every segment where encryption does or does not exist. Never assume a single padlock secures the entire chain.

Question 8

A customer submits a recovery token in the URL https://accounts.example/reset?token=SECRET. The HTTPS certificate is valid and the connection is not intercepted. The full URL is later retained in the customer's browser history and in the web server's request logs.

Which conclusion is most accurate?

  1. The token is visible to passive network observers because TLS encrypts response bodies but leaves URL paths and query strings exposed
  2. The token remains confidential everywhere because valid HTTPS extends encryption to browser history and server-generated logs
  3. The token is removed from browser history by TLS, although the server can recover it by decrypting captured network packets
  4. The token is protected while crossing the network, but HTTPS does not prevent endpoints or their logs from retaining the full URL (correct answer)
Explanation: When you see a question about HTTPS and sensitive data, train yourself to separate what TLS protects from where TLS applies. TLS encrypts data in transit between two endpoints — it says nothing about what happens once data arrives at either end. That framing makes D the clear winner. The token is fully encrypted while traveling across the network, so a passive eavesdropper captures only ciphertext. But once the request reaches the server, the server decrypts it completely — full URL, query string, and all. That decrypted URL lands in access logs. Simultaneously, the browser records the full URL in its history the moment you navigate there. Neither of those storage events involves the network, so TLS offers zero protection against them. A is wrong because it inverts how TLS works. TLS encrypts everything in the HTTP request — including the path and query string — from the client to the server. A passive network observer sees none of it. The vulnerability here is at the endpoints, not on the wire. B is wrong because it dramatically overstates TLS's scope. A valid HTTPS certificate guarantees an encrypted channel; it has no mechanism to reach into a browser's local storage or a server's log files and protect data there. C is wrong on two counts: TLS does not touch browser history at all, and a network attacker who captures encrypted packets cannot decrypt them simply because the server can — the server's private key isn't exposed to the attacker. Study tip: Any time a question mentions "HTTPS protects X," ask yourself where X lives. If it's a log file, browser cache, or local database, HTTPS is irrelevant — it only protects the wire.

Question 9

An employee connects to a banking site over a public Wi-Fi network. The browser shows a valid HTTPS connection, and the employee does not bypass any certificate warnings. An attacker on the same Wi-Fi network passively captures traffic but does not control the employee's device or the bank's server.

Which information can the attacker most reasonably obtain from the captured traffic?

  1. The account password and transaction amounts, because public Wi-Fi traffic is visible to nearby devices
  2. The destination IP address and traffic timing, but not the protected HTTP content carried inside TLS (correct answer)
  3. The complete URL path and request body, but not the bank's response content or session cookie
  4. Only the total connection duration, because HTTPS conceals destination addresses and packet sizes
Explanation: When you see a question about network eavesdropping on encrypted connections, anchor your thinking to the TLS/HTTPS layered model: encryption protects application-layer content, but lower-layer metadata remains visible to anyone who can observe packets on the network. HTTPS wraps HTTP inside TLS, which encrypts the request body, headers, URL paths, cookies, and response content before transmission. What TLS cannot hide is the IP layer beneath it — specifically, the destination IP address and port (how else would routers know where to send packets?). An attacker passively capturing traffic can therefore see which server you're communicating with, packet sizes, and timing patterns. They cannot decrypt the protected payload without the session keys, which are negotiated using asymmetric cryptography during the TLS handshake and never transmitted in plaintext. This makes B correct. A is wrong because it describes HTTP behavior, not HTTPS. Public Wi-Fi does make traffic visible to nearby devices, but HTTPS encryption means that visibility yields ciphertext, not readable passwords or amounts. C is wrong in the opposite direction — it partially acknowledges encryption but incorrectly claims URL paths and request bodies are exposed. URL paths are part of the HTTP request, which sits inside TLS and is therefore encrypted. D goes too far in the other direction: HTTPS does not conceal destination IP addresses or packet sizes; those are necessarily visible for routing to function. A useful rule of thumb: HTTPS encrypts content, not metadata. Destination IP, timing, and packet volume are always observable — remember this distinction, because exam questions frequently test whether you conflate traffic visibility with content exposure.

Question 10

A user receives an email linking to https://secure-payments-example.net. The browser displays a padlock and reports that the site's certificate is valid for that domain. The page closely imitates the user's bank and asks for banking credentials.

What is the most accurate conclusion about the padlock in this situation?

  1. It confirms the site is operated by the bank because certificate authorities verify business legitimacy before enabling HTTPS
  2. It confirms the page content is nonmalicious because TLS certificate validation includes a security review of the website
  3. It confirms an encrypted connection to the named domain, but does not establish that the domain is trustworthy or belongs to the bank (correct answer)
  4. It confirms only that the domain resolves correctly in DNS, while providing no confidentiality for credentials sent to the page
Explanation: When you see a question about HTTPS padlocks and phishing, the core concept being tested is what TLS encryption actually guarantees — and, critically, what it does not guarantee. A padlock means your browser successfully negotiated an encrypted TLS connection with the server hosting that domain, and that a certificate authority (CA) confirmed the certificate is valid for that specific domain name. That's it. The encrypted tunnel protects your data in transit — but it says nothing about who controls the domain or what their intentions are. An attacker can register secure-payments-example.net, obtain a perfectly legitimate TLS certificate for it (CAs issue these routinely for any domain the requester controls), and serve a convincing phishing page — all while your browser happily displays the padlock. Answer C captures this precisely: encrypted connection to the named domain, no guarantee of trustworthiness or ownership by the bank. A is wrong because Domain Validation (DV) certificates — the most common type — require only proof of domain control, not any verification of business identity or legitimacy. Even Organization Validation (OV) certificates don't confirm a site is safe to use. B is wrong because CAs perform zero review of page content or intent; TLS validation is entirely separate from malware or phishing detection. D is wrong in the opposite direction — it dramatically understates what HTTPS provides. TLS absolutely does encrypt credentials in transit; the problem is simply that they're being sent to the wrong party. A useful rule of thumb: the padlock answers "is this connection private?" not "is this destination safe?" Keep those two questions separate on exam day.