# Encryption and encrypted traffic (FAQ)

> 40 questions on Encryption and encrypted traffic, in plain language: what to check, what NetSenX shows and what a sensor cannot see.

Source page: https://netsenx.com/en/faq/encryption

## Can NetSenX detect threats in encrypted traffic?

Yes, from metadata: encrypted traffic is never decrypted. NetSenX looks at flow metadata and a few protocol fields — timing, volume, destinations and the TLS handshake — so beaconing and unusual data transfers stay visible without breaking encryption or reading content.

https://netsenx.com/en/faq/can-netsenx-detect-threats-in-encrypted-traffic

## Can NDR detect threats in encrypted traffic without decrypting it?

Yes, from metadata. Timing, volume, destinations and the TLS handshake stay visible when the content is encrypted, so beaconing to a command-and-control server and unusual data transfers can be detected without breaking encryption. What stays invisible is the content of the session.

https://netsenx.com/en/faq/can-ndr-detect-threats-in-encrypted-traffic-without-decrypting-it

## What does NetSenX read from an encrypted connection?

Flow metadata (who connects to whom, when, how often and how much data moves) and a few protocol fields: the server name and the parameters in the TLS handshake, and the answers to DNS queries. NetSenX never decrypts the session and does not read its encrypted content.

https://netsenx.com/en/faq/what-does-netsenx-read-from-an-encrypted-connection

## Do I need TLS decryption to detect threats?

Not for many of them. Who talks to whom, when, how often and how much, together with the unencrypted TLS handshake and DNS answers, stays visible without decryption. That is enough to see beaconing to a command-and-control server, scanning, lateral movement between internal hosts and unusual uploads, which are steps most intrusions take before they do damage. Decryption is needed to see content, such as a malicious file inside a download or the text of a command, and it brings costs: an interception proxy that holds keys and decrypted data, a company certificate on every managed device, apps that break, privacy and works-council questions, and blind spots on unmanaged devices. Many companies get better value from endpoint protection for files and processes on each machine, plus network detection for behaviour across all devices. NetSenX never decrypts traffic: its core detections run on every plan, and TLS fingerprints from the Starter plan where the agent captures packets.

https://netsenx.com/en/faq/do-i-need-tls-decryption-to-detect-threats

## Why not decrypt TLS traffic for inspection?

Decryption gives payload visibility, but it means running an interception point that holds keys, installing an interception certificate on every device, and handling decrypted content that may include personal data. Since TLS 1.3, a passive sensor can no longer decrypt sessions with a copy of the server's private key.

https://netsenx.com/en/faq/why-not-decrypt-tls-traffic-for-inspection

## What does TLS inspection on a firewall break?

More than people expect. To inspect HTTPS, the firewall or proxy ends each connection, decrypts it, inspects it and opens a new encrypted connection to the real server, presenting its own certificate signed by a company root installed on every managed device. The side effects: apps with certificate pinning, many updaters, some banking and health apps and parts of cloud services refuse the substitute certificate, so exception lists keep growing; unmanaged devices, guests and machines cannot be inspected at all; the proxy becomes one place that holds decrypted traffic, including personal data, which raises GDPR and works-council questions; older proxies may not support recent TLS features or the new hybrid post-quantum groups and quietly weaken connections; and inspection costs performance. It still has its place, for example scanning downloads on managed laptops. But many threats are visible without it. NetSenX takes that approach: it never decrypts and works from metadata and the unencrypted handshake.

https://netsenx.com/en/faq/what-does-tls-inspection-on-a-firewall-break

## Can deep packet inspection work on encrypted traffic?

Only on the parts that are not encrypted, unless you decrypt. Deep packet inspection (DPI) means reading past the packet headers into the content. With TLS the content is encrypted, so classic signatures that look for a malicious file or command inside the stream no longer match. What stays readable are the unencrypted handshake messages, with the TLS version, cipher and key-exchange choices, a client fingerprint and usually the server name, and the DNS answers that came before the connection. Combined with flow metadata, meaning who, when, how often and how much, that is enough for many detections: beaconing to a command-and-control server, scanning, lateral movement and unusual uploads. To see content you need an interception proxy that decrypts and re-encrypts traffic, with its own costs and risks. NetSenX reads the handshake fields where its agent captures packets, on Linux or as a SPAN/TAP sensor, not in the basic macOS mode, and it never decrypts traffic.

https://netsenx.com/en/faq/can-deep-packet-inspection-work-on-encrypted-traffic

## Can malware be detected from flow statistics alone?

Often, yes, because malware has to behave in certain ways to be useful, and that behaviour shows in the flows. Flow records describe each connection: source and destination, ports, start time, duration, and bytes and packets in each direction. A compromised device that checks in with its controller at regular intervals produces a recognisable rhythm, called beaconing; one that explores the network touches many internal hosts and ports in a short time, which is scanning and lateral movement; one that steals data sends far more than it normally does, often at night. None of this needs decryption, and research on encrypted traffic analysis has shown for years that timing and size patterns carry a lot of information. The limits: a single connection to a well-known cloud service can look innocent, and patient attackers try to blend in. That is why flow analysis works best against a baseline of what is normal for each device. NetSenX detects beaconing, scanning, lateral movement and unusual outbound volume on every plan, Free included.

https://netsenx.com/en/faq/can-malware-be-detected-from-flow-statistics

## Can encrypted traffic reveal what is inside it?

Not the content, but more about it than people assume. Encryption hides the words, files and keystrokes, yet the size, timing and direction of packets leak patterns: a video call, a large upload, a remote desktop session and a software update each have a recognisable shape. Researchers have shown for years that such traffic analysis can identify websites visited or applications used, even through a VPN, with varying accuracy. For defence this is useful: it is how a network sensor can tell an interactive session from an automated check-in, or notice a server that suddenly sends gigabytes, without decrypting anything. For privacy it is a reminder that encryption is not invisibility. What traffic analysis cannot do is read a message, see which file was uploaded or know what someone typed into an AI chatbot. NetSenX uses flow metadata and the unencrypted handshake, never decrypts sessions and does not reconstruct content.

https://netsenx.com/en/faq/can-encrypted-traffic-reveal-what-is-inside

## Is network metadata personal data under GDPR?

It can be. The Court of Justice of the EU held in Breyer (Case C-582/14, 19 October 2016) that a dynamic IP address can be personal data. NetSenX publishes a data processing agreement under GDPR Article 28 and keeps customer data in the EU.

https://netsenx.com/en/faq/is-network-metadata-personal-data-under-gdpr

## Can you get malware from an HTTPS website?

Yes. HTTPS means the connection is encrypted and the server holds a valid certificate for the name in the address bar; it says nothing about whether the site or its downloads are safe. Attackers use HTTPS as routinely as everyone else, because certificates are free and automated, and much phishing and malware delivery runs over it. The padlock protects you from someone reading or altering traffic on the way, not from the content at the other end. Protection against malicious downloads comes from endpoint protection on the device, browser and e-mail filtering, keeping software updated and limiting who can install programs. On the network side, encryption hides the file but not the behaviour that usually follows an infection: a device suddenly contacting a new destination at regular intervals, scanning internal hosts or sending out unusual volumes of data. NetSenX detects those patterns on every plan, from flow metadata and without decrypting traffic.

https://netsenx.com/en/faq/can-you-get-malware-from-an-https-website

## Can HTTPS traffic be intercepted by a man in the middle?

Only if the client can be made to trust the interceptor. A man-in-the-middle attack on HTTPS needs a certificate the client accepts for the target name, a user who clicks through the warning, or an application that does not check certificates properly. Companies do it on purpose with TLS inspection proxies, by installing their own root certificate on managed devices. Attackers try the same by planting a rogue root certificate through malware, by getting users to accept warnings, or by exploiting apps with broken certificate checks. Defences: never train staff to click through certificate warnings, control which root certificates are installed on company devices, keep apps updated, and use HTTP Strict Transport Security (HSTS) on your own websites so browsers refuse plain connections. Certificate pinning in some apps refuses any interceptor, including your own proxy. In TLS 1.3 the server certificate is encrypted, so a passive network sensor cannot check who issued it; that check belongs on the device or in proxy logs.

https://netsenx.com/en/faq/can-https-traffic-be-intercepted

## What is JA4 TLS fingerprinting?

When a program opens a TLS connection, its first message lists the versions, ciphers and extensions it supports, in a characteristic order. A fingerprint such as JA4 condenses that message into a short string, so the same client software can be recognised across connections without decrypting anything. It helps spot unusual clients, such as a script posing as a browser. NetSenX computes TLS fingerprints from the handshake from the Starter plan, with its own implementation. The handshake is visible only where the agent captures packets: on Linux or as a sensor on a SPAN or TAP port, not in the basic mode used on macOS.

https://netsenx.com/en/faq/what-is-ja4-tls-fingerprinting

## What is the difference between JA3 and JA4?

Both fingerprint the client side of a TLS handshake, but JA4 copes with how modern browsers behave. JA3, published in 2017, hashes the fields of the ClientHello in the order they appear. From early 2023 Chrome began shuffling the order of TLS extensions on every connection, which changes the JA3 value each time and makes it far less useful for recognising browsers. JA4, published in 2023, sorts the fields before hashing, adds the TLS version, the transport (TCP or QUIC) and the first application protocol offered, and produces a readable string whose parts can be compared separately. Neither proves malice on its own: many programs share a fingerprint, and malware can imitate a browser. They are useful for spotting a client that does not fit the device, such as a script posing as a browser on a server. NetSenX computes TLS fingerprints from the Starter plan, with its own implementation, where its agent captures packets: on Linux or as a SPAN/TAP sensor, not in the basic macOS mode.

https://netsenx.com/en/faq/what-is-the-difference-between-ja3-and-ja4

## What is SNI, and why does it matter for monitoring?

Server Name Indication (SNI) is a field in the TLS ClientHello where the client names the site it wants, such as login.example.com, because many sites share one IP address and the server must know which certificate to present. It is sent before encryption starts, so anyone on the path can read it. For monitoring it is one of the most useful fields in encrypted traffic: it names the service behind an IP address, which helps tell an AI assistant, a file-sharing site or a known business application from an unknown server, without reading any content. Most web filters and many firewalls rely on it too. Two things reduce its value: connections made straight to an IP address carry no meaningful name, and Encrypted Client Hello (ECH) hides the real name behind a public front name. DNS answers and the history of each destination then matter more. NetSenX reads the server name from the handshake where its agent captures packets, on Linux or as a SPAN/TAP sensor.

https://netsenx.com/en/faq/what-is-sni-and-why-does-it-matter-for-monitoring

## What is Encrypted Client Hello (ECH)?

ECH is a TLS extension that encrypts the sensitive part of the ClientHello, including the real server name, with a public key the site publishes in DNS. On the wire, an observer sees only an outer ClientHello carrying a shared public name, typically that of the content-delivery network hosting the site, instead of the actual site. It was designed for privacy: to stop anyone on the path, from a café Wi-Fi to an internet provider, from learning which site you visit. Major browsers support it and some large content-delivery networks offer it, so a share of web traffic already uses it, while most corporate and internal servers do not. ECH usually comes together with encrypted DNS, because otherwise the name would still leak through the DNS query. The certificate and the session content were already encrypted under TLS 1.3; ECH closes one of the last readable fields. For security teams it means fewer names and more reliance on behaviour.

https://netsenx.com/en/faq/what-is-encrypted-client-hello

## Does Encrypted Client Hello blind network monitoring?

Partly. With ECH, a sensor no longer sees the real server name in the handshake, so name-based rules, web filters and simple shadow-IT lists lose precision for the sites that use it. What remains is a lot: the destination IP address and who operates it, the outer public name, usually that of a large content-delivery network, DNS answers when DNS is not encrypted end to end, the timing, volume and direction of every flow, and the client fingerprint. Behavioural detections such as beaconing, scanning, lateral movement and unusual uploads do not depend on the server name and keep working. Internal traffic is rarely affected, because internal servers seldom publish ECH keys. For managed devices you can influence it: point them at your own DNS resolver and use the browser's enterprise policies, which can control ECH and encrypted DNS. Name-based visibility of AI or file-sharing services from any network sensor, NetSenX included, becomes less complete for sites behind ECH.

https://netsenx.com/en/faq/does-encrypted-client-hello-blind-network-monitoring

## Do QUIC and HTTP/3 blind firewalls?

They reduce what older firewalls can see, but they do not make traffic invisible. QUIC (RFC 9000, 2021) is the transport under HTTP/3. It runs over UDP port 443 and encrypts almost everything, including much of what TCP left readable, such as packet numbers and acknowledgements. Its first packets carry a TLS 1.3 ClientHello protected only with keys anyone can derive, so a sensor that understands QUIC can still read the server name and handshake parameters. Firewalls and proxies built for TCP often cannot inspect QUIC at all. Common practice in companies that rely on TLS inspection or web filtering is to block UDP port 443, which makes browsers fall back to HTTP/2 over TCP without users noticing. Without such a policy, QUIC simply appears as UDP flows with timing and volume like any other traffic, and flow-based detections such as beaconing and unusual upload volume still apply. Check whether your firewall reports QUIC before assuming it is covered.

https://netsenx.com/en/faq/do-quic-and-http3-blind-firewalls

## Can DNS over HTTPS hide traffic from security monitoring?

It can hide the DNS lookups, not the connections that follow. DNS over HTTPS (DoH, RFC 8484) and DNS over TLS (DoT, RFC 7858) encrypt the questions a device asks its resolver. If browsers or apps use an outside DoH resolver, your company DNS server and its logs no longer see which names they look up, which weakens DNS-based filtering and investigations. Malware can use DoH for the same reason. The connections to the actual destinations still cross the network with their IP addresses, timing and volume, and often with the server name in the TLS handshake. Practical steps: run your own resolver, or use a provider's, that supports encrypted DNS, and point managed devices at it; use browser and operating-system policies to stop them using other resolvers; and look for devices that talk to public DoH services directly. DoT is easy to spot because it uses port 853; DoH looks like ordinary HTTPS. NetSenX alerts on DNS tunnelling; it does not filter or block DNS.

https://netsenx.com/en/faq/can-dns-over-https-hide-traffic-from-security-monitoring

## How do I decrypt TLS traffic for troubleshooting?

On a machine you control, the simplest way is to have the client write its session keys to a file and load that file into Wireshark. Browsers and many command-line tools built on OpenSSL or NSS honour the SSLKEYLOGFILE environment variable: set it, reproduce the problem while capturing with Wireshark or tcpdump, then point Wireshark's TLS settings to the key log. This also works for TLS 1.3, where having the server's private key is no longer enough. For a server you run, some web servers and proxies can log keys too, or you can test against a staging copy with logging turned on. Treat key logs like passwords: anyone with the file and the capture can read the traffic, so delete both afterwards, and never collect them from other people's devices without a clear basis and their knowledge. For everyday monitoring, decryption is rarely needed: flow metadata and the unencrypted handshake answer most questions about who talks to whom and how.

https://netsenx.com/en/faq/how-to-decrypt-tls-for-troubleshooting

## How does a TLS handshake work?

In TLS 1.3 it takes one round trip before data flows. The client sends a ClientHello listing the TLS versions, cipher suites and key-exchange groups it supports, a key share for its preferred group, and usually the name of the server it wants (SNI). The server answers with a ServerHello that picks the version, cipher and group, plus its own key share. From the two key shares both sides derive the same secret, and from that moment everything is encrypted, including the server's certificate and its proof that it holds the matching private key. The client checks the certificate against the authorities it trusts, and application data begins. The ClientHello and ServerHello travel unencrypted, which is why a passive sensor can see the TLS version, the chosen key-exchange group, for example classical X25519 or hybrid X25519MLKEM768, and a client fingerprint without decrypting anything. With Encrypted Client Hello, part of the ClientHello, including the server name, is hidden as well.

https://netsenx.com/en/faq/how-does-a-tls-handshake-work

## What changed between TLS 1.2 and TLS 1.3?

TLS 1.3 (RFC 8446, 2018) is faster and removes the weak options behind most past TLS attacks. It completes the handshake in one round trip instead of two. It keeps only key exchanges with forward secrecy, so recording traffic and later stealing the server's private key no longer decrypts past sessions. It drops old ciphers and modes such as RC4, 3DES, CBC-mode suites and static RSA key exchange, leaving a short list of modern authenticated ciphers. And it encrypts more of the handshake, including the server certificate. For monitoring, two consequences follow. A passive device can no longer decrypt sessions with a copy of the server's private key, so inspection now requires an active interception proxy. And less is visible in clear: the certificate is hidden, while the hello messages, the chosen group and the server name, unless Encrypted Client Hello is used, remain visible. Prefer TLS 1.3 everywhere, and keep TLS 1.2 only with strong cipher suites for older clients.

https://netsenx.com/en/faq/what-changed-between-tls-1-2-and-tls-1-3

## Should we disable TLS 1.0 and 1.1?

Yes. Both have been formally deprecated by the IETF since RFC 8996 (March 2021), major browsers no longer accept them, and they rely on old hash functions and cipher constructions with known weaknesses. If they are still enabled on a server, the risk is less a direct attack than a downgrade path, and a sign of neglect that auditors, insurers and scanners will flag. Before switching them off, find out who still uses them: old printers, scanners, industrial devices, legacy applications and embedded clients are the usual suspects, and turning the protocols off without checking can stop a production line or a payment terminal. Look at server logs where they record the TLS version, run an external scanner against public services, and inside the network look at the TLS versions in the handshakes. Then disable them, or isolate what cannot be upgraded in its own segment with a plan to replace it. The same inventory will serve your post-quantum work later.

https://netsenx.com/en/faq/should-we-disable-tls-1-0-and-1-1

## Which TLS ciphers should we turn off?

Anything without forward secrecy or authenticated encryption, and everything on the old lists. In practice: disable RC4, which RFC 7465 prohibits in TLS, 3DES and other 64-bit block ciphers, export-grade and NULL ciphers, static RSA key exchange, and CBC-mode suites with SHA-1 where your clients allow it. Keep the TLS 1.3 suites, AES-GCM and ChaCha20-Poly1305, and for TLS 1.2 use ECDHE key exchange with AES-GCM or ChaCha20-Poly1305. Use published configuration guides rather than inventing your own: Mozilla's server-side TLS recommendations and the technical guidelines of agencies such as Germany's BSI give tested profiles for modern and older clients. Before you change a production server, check which clients connect and what they offer, from server logs or a view of the handshakes, so you do not lock out an old device. Re-test from outside afterwards with a TLS scanner, and enable the hybrid group X25519MLKEM768 where your software supports it.

https://netsenx.com/en/faq/which-tls-ciphers-should-we-turn-off

## What is forward secrecy?

Forward secrecy means each session uses a fresh, temporary key that is thrown away afterwards, so stealing a server's long-term private key later does not decrypt sessions recorded earlier. It comes from ephemeral key exchanges such as ECDHE or X25519: the long-term key only proves the server's identity, while the session key comes from throwaway values chosen by both sides. Older TLS configurations with static RSA key exchange lacked it, so a single stolen key could unlock years of recorded traffic. TLS 1.3 makes forward secrecy mandatory, and well-configured TLS 1.2 servers offer it too. It also explains why harvest now, decrypt later is about the key exchange: forward secrecy protects against a future theft of the key, but not against a future quantum computer that can break the ephemeral elliptic-curve exchange itself. Hybrid post-quantum key exchange keeps forward secrecy and adds the missing protection. Check your servers with a TLS scanner: every suite they offer should have it.

https://netsenx.com/en/faq/what-is-forward-secrecy

## What is encryption, in plain terms?

Encryption turns readable data into scrambled data that only someone with the right key can turn back. The method, called the algorithm, is public; the secret is the key. Good encryption means that without the key, even a powerful computer cannot recover the data in any useful time. You use it every day: HTTPS on websites, the VPN to the office, messaging apps, disk encryption on laptops and phones, and backups. It protects data in transit against anyone who can listen on the network, and data at rest against anyone who steals the disk. It does not protect data from someone who already has the key, or who controls a device where the data is decrypted, such as malware on a logged-in laptop. That is why encryption sits alongside access control, patching and monitoring rather than replacing them. A network sensor sees that encrypted connections happen, with their metadata, but not their content.

https://netsenx.com/en/faq/what-is-encryption-in-plain-terms

## What is the difference between symmetric and asymmetric encryption?

Symmetric encryption uses one shared key to lock and unlock; asymmetric, or public-key, encryption uses a pair: a public key anyone may know and a private key only its owner holds. Symmetric algorithms such as AES are fast and encrypt almost all real data. Their weak point is sharing the key safely. Public-key methods such as RSA, elliptic-curve Diffie-Hellman and their post-quantum successors solve that: two parties who have never met can agree on a fresh symmetric key over an open network, and a private key can sign data so that anyone with the public key can check it. Real protocols combine both. A TLS connection uses public-key cryptography in the handshake to agree a key and prove the server's identity, then switches to AES or ChaCha20 for the data. That split also explains the quantum story: Shor's algorithm threatens the public-key part, while symmetric encryption with 256-bit keys stays strong.

https://netsenx.com/en/faq/what-is-the-difference-between-symmetric-and-asymmetric-encryption

## How long should an encryption key be?

It depends on the type of algorithm, because lengths are not comparable across types. For symmetric encryption, AES-128 is still considered strong and AES-256 gives extra margin, including against future quantum computers; use 256 bits for data that must stay secret for many years. For RSA, 2048 bits is the usual minimum today, and agencies such as Germany's BSI recommend at least 3000 bits for longer protection. Elliptic-curve keys are far shorter for the same strength: a 256-bit curve such as P-256 or X25519 is roughly comparable to RSA with about 3000 bits. For hashing, use SHA-256 or stronger. Two caveats matter more than the numbers. Key length does not help if the key is badly generated, kept in a script or never rotated. And RSA and elliptic curves of any length fall to a large quantum computer, which is why their long-term replacement is post-quantum algorithms, not bigger keys. Follow your national agency's current guidance for exact values.

https://netsenx.com/en/faq/how-long-should-an-encryption-key-be

## What is a hash function?

A hash function turns any amount of data into a short, fixed-length fingerprint, such as the 256-bit output of SHA-256. The same input always gives the same hash, a tiny change gives a completely different one, and nobody can work back from the hash to the input or find two inputs with the same hash. That makes hashes useful for checking that a download or a backup has not changed, for digital signatures, which sign the hash of a document, for storing passwords safely, and for the integrity checks inside TLS. Old functions have failed: MD5 and SHA-1 are broken for security purposes, and a public SHA-1 collision was demonstrated in 2017, so treat them as legacy wherever they still appear, for example in old certificates or file checks. SHA-256, SHA-384 and SHA-3 are current choices. A hash is not encryption: there is no key and nothing to decrypt. Quantum computers weaken hash functions only modestly.

https://netsenx.com/en/faq/what-is-a-hash-function

## Is hashing the same as encryption for passwords?

No, and for passwords hashing is the right choice. Encryption is reversible with a key, so anyone who steals both the encrypted passwords and the key gets every password back. A hash cannot be reversed, so the system stores only the hash and compares it at login. Ordinary fast hashes such as SHA-256 are still a poor choice for passwords, because attackers who steal a database can try enormous numbers of guesses per second on graphics cards. Use a function built for passwords, deliberately slow and with a random salt per user: Argon2id, scrypt or bcrypt, as the OWASP password storage guidance recommends. If a supplier or an old application stores passwords encrypted, or hashed with plain MD5 or SHA-1, treat it as a finding to fix. For your own staff, the bigger gains are elsewhere: multi-factor authentication (MFA), a password manager and blocking reused passwords. A network sensor does not see how a server stores passwords; that check belongs in an application review.

https://netsenx.com/en/faq/is-hashing-the-same-as-encryption-for-passwords

## What is a digital signature?

A digital signature is a value computed from data with a private key, which anyone holding the matching public key can check. If the check passes, two things are proven: the data comes from the holder of that private key, and it has not changed since it was signed. Signatures protect much of what you rely on without noticing: software updates and drivers, the TLS certificates that prove a website's identity, signed PDFs and e-invoices, e-mail signed with S/MIME, and the code your developers ship. In the EU, qualified electronic signatures under the eIDAS Regulation also carry legal weight. A signature is only as trustworthy as its private key: if the key is stolen, an attacker can sign malware that looks genuine, which is why signing keys belong in hardware security modules or similarly protected stores, with few people able to use them. Today's signatures use RSA or elliptic curves, which a large quantum computer would break; their post-quantum replacements are ML-DSA and SLH-DSA.

https://netsenx.com/en/faq/what-is-a-digital-signature

## What is a TLS certificate?

A TLS certificate is a signed document that binds a public key to a name, such as www.example.com, so that a browser or client can check it is talking to the real server and not an impostor. The signature comes from a certificate authority (CA) that the client already trusts, usually through a chain: a root CA, an intermediate CA, then the server's own certificate. During the handshake the server presents its certificate and proves it holds the matching private key. Certificates have an expiry date and can be revoked. What a certificate does not prove is that the site is safe or honest: a phishing site can have a perfectly valid certificate, because CAs mostly check control of the domain, not the business behind it. Inside companies, an internal CA often issues certificates for servers, VPNs and devices. Keep an inventory of all certificates with owners and expiry dates; forgotten ones cause outages and hide weak keys.

https://netsenx.com/en/faq/what-is-a-tls-certificate

## What happens when a TLS certificate expires?

Clients stop trusting the server: browsers show a full-page warning, and apps, APIs, VPN clients and devices usually refuse to connect at all. To users it looks like an outage, and in practice it is one: payment pages, customer portals, mail servers and machine-to-machine links can stop working at the moment of expiry, often at night or over a weekend. Expired certificates also train staff to click through warnings, which is exactly what an attacker intercepting traffic would want. The fix is process, not heroics: an inventory of every certificate with its owner and expiry date, alerts well in advance, and automatic renewal through the ACME protocol (RFC 8555) wherever the platform supports it. Do not forget certificates inside appliances, printers, internal services and code signing, which external scanners never see. Watching TLS handshakes on the internal network helps find servers that nobody listed, though in TLS 1.3 the certificate itself is encrypted and must be checked on the server.

https://netsenx.com/en/faq/what-happens-when-a-tls-certificate-expires

## Why are TLS certificate lifetimes getting shorter?

Because shorter lifetimes limit the damage from a stolen key or a wrongly issued certificate, and push everyone to automate renewal. In April 2025 the CA/Browser Forum, the body of certificate authorities and browser makers that sets the rules for public TLS certificates, adopted ballot SC-081: the maximum lifetime falls from 398 days to 200 days from 15 March 2026, to 100 days from 15 March 2027 and to 47 days from 15 March 2029. The rules apply to publicly trusted certificates, not to those issued by your own internal CA. For a company still renewing certificates by hand once a year, this changes the workload: renewals become frequent and manual processes will fail. The response is automation through ACME (RFC 8555) or your provider's tools, an inventory of every public certificate and where it is installed, including load balancers and appliances, and monitoring of expiry. Treat it as practice for crypto-agility: the same discipline helps with the post-quantum transition.

https://netsenx.com/en/faq/why-are-tls-certificate-lifetimes-getting-shorter

## Are self-signed certificates on internal servers a problem?

Not because they are self-signed, but because of what usually comes with them. A self-signed certificate encrypts as well as any other; the problem is trust. Clients cannot check it against a known authority, so users and admins learn to click through warnings or switch off verification in scripts, and the same habit lets a real interception go unnoticed. Self-signed certificates on appliances often have weak or default keys, no expiry tracking and no owner. The better pattern is an internal certificate authority, issuing through automation where possible, whose root is distributed to managed devices, with an inventory of every certificate and its expiry. For devices that only ship with self-signed certificates, such as printers or controllers, replace the certificate where the device allows it and keep the device in a segment with restricted access. Self-signed certificates also belong in your post-quantum inventory: each has a key type and size that will need to change one day.

https://netsenx.com/en/faq/are-self-signed-certificates-on-internal-servers-a-problem

## What is mutual TLS (mTLS)?

Mutual TLS means both sides of a connection present certificates, so the server proves its identity to the client and the client proves its identity to the server. In ordinary HTTPS only the server has a certificate, and the user proves who they are later with a password or a token. With mTLS the client needs a private key and a certificate issued by an authority the server trusts, which is hard to phish and easy to revoke. It is common between services in a microservice architecture, for APIs between companies, for device identity in IoT and OT, and in some zero-trust remote-access products. The costs are certificate management at scale, meaning issuing, rotating and revoking client certificates, and troubleshooting when something expires. On the network, mTLS looks like normal TLS. In TLS 1.3 the client certificate is encrypted, so a passive sensor sees that the connection exists and its handshake parameters, not which client certificate was used.

https://netsenx.com/en/faq/what-is-mutual-tls

## Does a VPN encrypt everything we send?

It encrypts traffic between your device and the VPN gateway, not the whole way to the destination. Behind the gateway, traffic continues to the office network or the internet protected only by whatever the application itself uses, such as HTTPS. A company VPN therefore protects staff on hotel or café Wi-Fi from local eavesdropping and gives them access to internal systems; it does not make an unencrypted internal application safe, and it hides nothing from the company network that receives the traffic. Split tunnelling sends only some traffic through the VPN and the rest directly, which helps performance but means company monitoring sees only part of it. A commercial VPN service moves your trust from the internet provider to the VPN provider. VPN gateways themselves are frequent targets and need fast patching and multi-factor authentication (MFA). From the network, VPN tunnels are visible as connections to the gateway, with their timing and volume, not their content.

https://netsenx.com/en/faq/does-a-vpn-encrypt-everything-we-send

## How do I find all SSH servers on our network, including forgotten ones?

Combine an active scan with passive observation, because each finds what the other misses. An authorised scan of your address ranges for port 22 and other common SSH ports, with a tool such as Nmap, lists every host that answers and the software version it announces. Check your cloud consoles and DNS records for servers outside the office ranges. Passive observation adds what scans miss: SSH on unusual ports, servers reachable only from certain segments, and how SSH is actually used, meaning which clients connect to which servers and when. Then go through the list with owners: every server needs a named person, a reason to exist and a patch schedule, and anything nobody claims gets switched off after a notice period. Restrict SSH to administrators' networks or a jump host, and use keys instead of passwords. NetSenX alerts on every plan when a host starts reaching many internal hosts on administration ports such as SSH, which is how scanning and lateral movement look.

https://netsenx.com/en/faq/how-to-find-all-ssh-servers-on-the-network

## How do I check which servers run an OpenSSH version affected by a new CVE?

Start with the version each server announces, then confirm against the vendor's patch status, because the announcement alone can mislead. Every SSH server sends an identification string such as SSH-2.0-OpenSSH_9.6p1 before anything else, and a scanner or a simple connection shows it. Compare that version with the range in the advisory. For regreSSHion (CVE-2024-6387), for example, the advisory published by Qualys on 1 July 2024 named OpenSSH from 8.5p1 up to, but not including, 9.8p1 on glibc-based Linux. Then check the package version on each server: Linux distributions often backport security fixes into an older version number, so a server announcing an affected version may already be patched, and the distribution's security tracker is the authority. Patch through the package manager, restart the service and check again. Keep a list of SSH servers from your inventory, so that the next advisory takes minutes rather than days.

https://netsenx.com/en/faq/how-to-check-openssh-versions-against-a-new-cve

## Does an SSH version banner prove a server is vulnerable?

No. It is a strong hint, not proof, in both directions. The banner is the text a server announces about its software, such as OpenSSH_8.9p1 Ubuntu-3ubuntu0.10. Linux distributions often fix security flaws by patching the old version instead of moving to the new upstream release, so a server can announce a version listed as affected and still be safe; the distribution's package suffix and its security tracker tell you. The banner can also be changed or hidden by an administrator, and some appliances announce misleading strings. Conversely, a current version number does not rule out problems in configuration, such as password logins open to the internet or weak host keys. Use the banner to sort servers into those worth checking first and those that are probably fine, then confirm on the host with the package manager or with an authenticated vulnerability scan. Never report a server to management as compromised or vulnerable on the strength of its banner alone.

https://netsenx.com/en/faq/does-an-ssh-version-banner-prove-a-server-is-vulnerable

FAQ: https://netsenx.com/en/faq