Cryptographic Protocol Coverage

The scanner performs a full TLS handshake against each target port, offering all known cipher suites and collecting the server's negotiated cipher, protocol version, certificate chain, and key exchange group. A fast-path probe (-cipherscanquick) collects the single negotiated suite without full enumeration.

The scanner performs a full SSH handshake, collecting all negotiated algorithms for key exchange, host key type, symmetric encryption, and MAC. No authentication is attempted.

An SMB2 NEGOTIATE Request is sent to 127.0.0.1:445 offering all dialects 2.0.2 through 3.1.1. The server's NEGOTIATE Response is parsed for the negotiated dialect and, for SMB 3.1.1, the NegotiateContextList encryption cipher IDs. On Windows the LanmanServer EncryptData registry DWORD is also checked.

Note: SMB symmetric encryption (AES-GCM/CCM) is quantum-safe. The primary risk is unencrypted SMBv1/v2 traffic which can be captured and replayed. Upgrade path: enable SMB 3.1.1 with EncryptData=1 (Windows) and prefer AES-256-GCM.

No active network probe is sent (USM responses require valid credentials). On Linux/macOS /etc/snmp/snmpd.conf is parsed for createUser directives, collecting auth and priv protocol names. On Windows the SNMP service registry key is checked — Windows SNMP supports only v1/v2c (community strings, no encryption).

Windows reads SupportedEncryptionTypes from the Group Policy or LSA registry key (or infers the OS-version default). Linux/macOS parses /etc/krb5.conf [libdefaults] for permitted_enctypes, default_tkt_enctypes, and allow_weak_crypto. RC4-HMAC is exploitable via Kerberoasting (RFC 8429 deprecates it); DES is banned by CNSA 2.0.

VPN clients are detected by process name, registry presence, and configuration file paths. Tunnel protocol, cipher suite, and key exchange algorithm are extracted from config files when available.

Fields captured: protocol (IKEv1/IKEv2), mode (tunnel/transport), authentication method (PSK/certificate/EAP), encryption algorithm, integrity algorithm, DH group, tunnel endpoint addresses.

Additional flags assessed: encrypt (authentication-only vs. confidentiality), replay_protect (replay window size), MKA (802.1X key agreement) enabled, validate: strict/check/disabled.

IBM MQ uses TLS at the TCP layer — the TLS handshake completes before any MQ protocol bytes are exchanged. On port 1414 (standard listener), a 28-byte MQTSH probe is sent after TLS fails; a TSH  signature in the response confirms MQ presence without TLS. Port 1415 (dedicated SSL listener) and port 9443 (MQ REST API) receive a direct TLS ClientHello. TLS-protected MQ channels are also detected by the standard TLS probe and labeled ibmmq+tls.

MQTSH probe: 28-byte Transmission Segment Header (StrucId="TSH ", SegmentType=INITIAL). IBM MQ responds with a recognizable error frame when TLS is absent, exposing the channel without authentication or encryption. Common IBM MQ process names monitored: amqrmppa, runmqlsr, amqzmgr0.

Local NFS mounts and server exports are parsed from the OS mount table — no network probing required for local detection. For remote scans, port 2049 receives a direct TLS ClientHello (RFC 9289 NFS-over-TLS) first; if TLS fails, a 40-byte ONC RPC NULL call (XID 0x12345678, Program 100003 / NFS, Procedure 0) confirms NFS presence. Security flavor is classified from mount options or export configuration.

NFS version detected from mount options (vers= or nfsvers=). Linux server exports are read from /proc/fs/nfsd/exports; client mounts from /proc/mounts. macOS mount table parsed via /sbin/mount. Windows NFS stub returns no results (Windows NFS client usage is rare in enterprise environments). Remote detection: port 2049 labeled nfs+tls when TLS succeeds.

DTLS is TLS over UDP. The active scanner probes DTLS 1.2 (RFC 6347) on well-known VoIP, gaming, IoT, and VPN ports. The passive sniffer parses DTLS record-layer headers from SPAN/TAP traffic without decryption, extracting version, cipher suite, and epoch. Common ports: 443 (QUIC), 4433 (test), 5349 (STUN/TURN over TLS), 5061 (SIP-TLS), 10000 (Jitsi/WebRTC).

Cisco AnyConnect, Zscaler, and WebRTC all rely on DTLS for low-latency encrypted transport. The scanner probes DTLS by sending a DTLS 1.2 ClientHello fragment over UDP and parsing any valid DTLS ServerHello or Alert response.

QUIC (RFC 9000) is a UDP-based multiplexed transport that carries TLS 1.3 handshake packets in Long Header Initial packets. The passive sniffer parses QUIC Initial packets to extract the ClientHello embedded inside CRYPTO frames, revealing the offered cipher suites and PQC key exchange groups — without decryption. HTTP/3 (RFC 9114) runs exclusively over QUIC. Active probing of QUIC is not performed by the scanner (QUIC requires a full implementation stack).

RADIUS (RFC 2865) uses a shared-secret MD5-based authenticator — classically weak, quantum-catastrophic. RADIUS over TLS (RadSec, RFC 6614) and RADIUS over DTLS (RFC 7360) provide transport encryption. The passive sniffer distinguishes cleartext RADIUS from RadSec by protocol and port, and parses EAP-TLS / EAP-TTLS handshakes from Access-Request attributes to extract the inner TLS cipher suite.

TACACS+ (Cisco proprietary, RFC 8907) obfuscates its payload using MD5 XOR with a shared secret — this provides confidentiality against passive capture but is not encryption and is trivially reversible with the shared secret. TACACS+ over TLS (RFC 9105) wraps the protocol in TLS 1.3. The passive sniffer identifies cleartext TACACS+ frames by the 12-byte header magic and detects TLS-wrapped TACACS+ by the TLS record on port 49.

NTPv4 (RFC 5905) has no built-in encryption. NTS (RFC 8915) adds authenticated time synchronization using a TLS 1.3 Key Exchange (NTS-KE on TCP port 4460) followed by AEAD-authenticated NTP packets over UDP 123. The passive sniffer identifies NTP packets by version and mode fields and detects NTS-KE TLS sessions by port and ALPN extension (ntske/1).

Time tampering enables HNDL (Harvest Now Decrypt Later) by shifting timestamps on certificate revocation or key rotation events. NTS is the recommended migration path; NTS-KE cipher suite is captured by the passive sniffer from the TLS ClientHello ALPN extension.

WireGuard (RFC-like, in-kernel since Linux 5.6) uses a fixed, opinionated crypto stack: Noise_IKpsk2 handshake, ChaCha20-Poly1305 for data, Curve25519 for key agreement, BLAKE2s for hashing, and SipHash for cookie MAC. The passive sniffer identifies WireGuard handshake initiation packets by the 4-byte type field (0x00000001) and 32-byte ephemeral public key prefix at a fixed offset in the UDP payload.

Modern data-center and cloud networks use overlay encapsulation for east-west traffic. The passive sniffer decapsulates VXLAN (RFC 7348), GENEVE (RFC 8926), GRE (RFC 2784), and ERSPAN (Cisco) frames and analyzes the inner payload for TLS, SSH, QUIC, and other protocol patterns. This enables visibility into VM-to-VM encrypted and unencrypted traffic without agent deployment on each guest.

Outer encapsulation itself provides no encryption — inner traffic analysis reveals cleartext protocols (HTTP, Telnet, FTP) as well as TLS/SSH. The sniffer recursively parses up to 3 levels of encapsulation to find the innermost protocol.

Mutual TLS requires the client to present a certificate in addition to the server. The scanner detects mTLS by observing whether the server sends a TLS CertificateRequest message during the handshake. If detected, the requires_client_cert field is set in the event. This is common for Elastic Agent (port 6789), internal service meshes (Istio, Linkerd), and zero-trust API gateways.

When TLS and SSH probes fail on a port, the scanner falls back to a library of 44+ protocol-specific probes to determine if the service is running in cleartext. Each probe sends a minimal protocol-appropriate request and matches the response against known signatures. A positive match produces a tychon.plaintext event flagging the protocol, encryption state, and compliance references.

Output fields: service_name, protocol, encryption_state (plaintext/encrypted/unknown), encryption_detail, is_vulnerable, compliance_refs, recommendations. Events are emitted only when a cleartext service is positively identified — TLS/SSH services are not re-emitted here.

The NTLM authentication level is read from the Windows Local Security Authority registry key. LmCompatibilityLevel controls whether the system sends LM, NTLMv1, or NTLMv2 responses. NTLMv1 uses DES encryption and MD4 hashing — classically broken and exploitable via pass-the-hash and relay attacks. NTLMv2 is the minimum acceptable standard.

NTLM is inherently vulnerable to relay attacks regardless of version. Migration to Kerberos with AES is strongly recommended. NTLM is detected via registry-only (no network probe). Events emitted as part of tychon.non_tls_cipher with protocol: ntlm.

FIPS 140-2/3 mode restricts the OS and cryptographic modules to NIST-approved algorithms. The scanner detects FIPS enforcement state via platform-native APIs: Windows registry HKLM\System\CurrentControlSet\Control\Lsa\FipsAlgorithmPolicy\Enabled, Linux /proc/sys/crypto/fips_enabled, and macOS security framework APIs. FIPS mode is reported in tychon.quantum_readiness as a positive compliance indicator.

FIPS mode does not itself provide PQC protection — it restricts algorithms to approved NIST primitives. FIPS 140-3 (which includes modules certified for ML-KEM/ML-DSA) is the path to PQC-compliant cryptographic enforcement.

AirPlay 2 uses a proprietary authentication layer (SRP-based pairing) over TCP and encrypts media via AES-128-CTR derived from the pairing session. The scanner probes port 7000 (RTSP-based AirPlay control channel) and identifies AirPlay services by process name, mDNS _airplay._tcp advertisement, and HTTP response header patterns. Encryption quality depends on pairing PIN enforcement and network isolation.

The scanner reads the active wireless profile from the OS to determine the 802.11 authentication and encryption settings. On Windows it reads WLAN profile XML via the WlanGetProfileList API. On Linux it parses wpa_supplicant.conf or NetworkManager config files. On macOS it uses CoreWLAN framework APIs to query the active SSID and security type.

OPC-UA (IEC 62541) is the dominant industrial automation protocol for factory-floor communication. The scanner probes port 4840 (unencrypted) and 4843 (TLS) for OPC-UA Binary protocol HEL messages. It also detects OPC-UA over WebSockets (port 443/8443 via HTTP Upgrade). The binary protocol includes a built-in Security Mode: None, Sign, or SignAndEncrypt.

Operational Technology (OT) protocols used in utilities, SCADA, and substation automation have security extensions that TQC detects and assesses.

The Noise Protocol Framework (Noise Spec v34) is a cryptographic framework for building secure handshake protocols. It underlies WireGuard, Lightning Network (BOLT #8), and various P2P messaging apps. The scanner detects Noise-based services via process name, config file patterns, and TCP port 9735 (Lightning Network). Lightning Network uses Noise_XK with secp256k1 for authentication.

The Signal Protocol (used by Signal, WhatsApp, Facebook Messenger) and the IETF MLS (Messaging Layer Security, RFC 9420) protocol are end-to-end encrypted messaging protocols. The scanner detects these via installed application inventory and process detection. These are noted for their end-to-end encryption posture — neither currently has PQC-capable deployments in production, though Signal has a PQXDH experimental mode (X25519 + Kyber768).

Tor (The Onion Router) is detected by process name (tor, tor.exe), SOCKS proxy port 9050/9150, installed application fingerprinting, and Tor Browser bundle directory patterns. Tor uses a custom onion routing protocol with AES-128-CTR for relay encryption and Curve25519/ed25519 for circuit construction — not PQC-capable. In enterprise environments, Tor presence is typically a policy violation flag.

ZRTP (RFC 6189) is a key agreement protocol for securing RTP media streams without a PKI. It uses DH (Curve25519, DH3k, EC25519) to derive SRTP keys for AES encryption. The scanner detects ZRTP via SIP/VoIP client process names and UDP media stream signatures. ZRTP is commonly used by Linphone, Jitsi, Signal Desktop, and government secure voice systems.

WebRTC mandates DTLS-SRTP (RFC 5764) for all media encryption. The DTLS handshake occurs on ephemeral UDP ports negotiated via SDP; the scanner probes these on common WebRTC port ranges (49152–65535) after detecting browser/conferencing app processes. DTLS establishes the master secret, then SRTP (RFC 3711) encrypts the media stream using AES-128-CM or AES-256-CM.

S/MIME (RFC 8551) provides email encryption and digital signatures using X.509 certificates and CMS (Cryptographic Message Syntax). The scanner detects S/MIME usage via filesystem certificate scan (looking for S/MIME-specific EKU: id-kp-emailProtection), mail client profile files (Outlook profile registry, Thunderbird profile), and process detection. S/MIME certificates found on disk are included in the standard certificate inventory.

OpenPGP (RFC 4880, RFC 9580) keys are detected by scanning for GnuPG keyring files in standard locations. Public and secret key packets are parsed for key algorithm, size, and creation date. OpenPGP v6 (RFC 9580) adds support for ML-KEM and ML-DSA as per NIST FIPS 203/204, but v4 keys (the overwhelming majority) use RSA or Curve25519.

OpenVPN wraps TLS in its own framing over UDP (default) or TCP on port 1194. The scanner probes port 1194 for the OpenVPN control channel signature (HMAC-authenticated TLS record) and parses .ovpn config files for cipher, auth, tls-cipher, tls-auth, and tls-crypt directives. TLS-auth and tls-crypt provide HMAC authentication of the control channel before the TLS handshake begins.

Beyond IKE negotiation, the scanner reads the specific ESP and AH transform sets in active Security Associations (SA). This captures the actual encryption and integrity algorithms used for packet-level protection, which may differ from what IKE advertised.

IBM BigFix (now HCL BigFix) uses a proprietary protocol over TCP port 52311 for agent-to-server communication. Relay and root server connections can be TLS-encrypted, but older deployments use the unencrypted BES protocol with SHA-1 signed content. The scanner detects BigFix by process name (BESClient, BESRootServer), probes port 52311 for the BES protocol handshake signature, and parses the client configuration file.

Cert metadata captured: subject, issuer, serial, not-before, not-after, SHA-1 and SHA-256 fingerprints, key usage / EKU, SANs, chain depth, CRL/OCSP endpoints, FIPS 140 certification flag, signature algorithm.

The Security framework SecItemCopyMatching(kSecClassIdentity) enumerates all certificate+private key pairs in the process's keychain search list (login + System keychains). Private key bytes never leave securityd or the Secure Enclave — only metadata is accessed via SecKeyCopyAttributes. Common identities include Microsoft AAD, GlobalProtect VPN, and MDM enrollment certificates.

Private key bytes are never read from memory. Library detection uses shared-object paths, version strings, and module signatures found in process memory maps. Java crypto libraries are detected via class loading patterns in the JVM heap.

The quantum readiness score is a composite of four independently scored dimensions. Scores influence the letter-grade (A–F) and readiness status reported in tychon.quantum_readiness.