TLS-Cipher-Suites

Website-Test: enumeriert die Suites einzeln – er bietet wiederholt alles an, was die Engine kodieren kann (mit OpenSSL @SECLEVEL=0, sodass auch schwache Suites angeboten werden), abzüglich dessen, was der Server bereits gewählt hat, und prüft jede der fünf TLS 1.3-Suites, um zu melden, welche ein Server akzeptiert. Die Iteration ist durch eine Suite-Obergrenze und ein Zeitbudget begrenzt; bricht sie vorzeitig ab, sagt der Bericht das – ein Teilergebnis wird mit vorangestelltem „≥“ markiert und nie für die Aussage benutzt, etwas sei nicht vorhanden.

Mail-Test (STARTTLS): klassifiziert die Suite, die der Mailserver aushandelt, führt zwei gezielte Downgrade-Probes pro MX aus – eine für veraltetes TLS ≤ 1.1 und eine für die schwachen Familien (RC4, 3DES, DES, Export, NULL) – und enumeriert die Suites je TLS-Version für einen repräsentativen MX: den erreichbaren Host mit der niedrigsten Preference. Die übrigen erreichbaren MX werden über Zertifikats-Fingerprint und ausgehandelte Suite verglichen statt enumeriert; das hält den ausgehenden Port-25-Fußabdruck klein (Blacklist-Schutz). Die Enumeration hat ein Verbindungs- und Zeitbudget, und der Bericht sagt es, wenn es erreicht wurde.

Hinweis zur Engine: Die Liste unten ist das, was unsere TLS-Engine (Node.js / OpenSSL) als aktiviert meldet, dazu die fünf TLS-1.3-Suites. Modernes OpenSSL 3.x kann einige seit Langem gebrochene Familien gar nicht mehr kodieren – unsere Probes können sie nicht hervorlocken, und der Bericht benennt sie bei jedem Scan namentlich, statt Entwarnung zu geben. NULL- und anonyme Suites sind ein anderer Fall: Sie fehlen in der Liste, unsere Probes können sie bei @SECLEVEL=0 aber sehr wohl anbieten – ein Server, der eine davon akzeptiert, wird erkannt und auf F gedeckelt. Die verbleibenden Legacy-Einträge (CBC-Modus oder statischer RSA-Schlüsselaustausch) werden als Legacy/akzeptabel markiert, nicht als schwach.