{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig3x6k6fy5dlautvcwr3cmi6ttbto3fga2zbhd62mont6fo6lcf24",
    "uri": "at://did:plc:nkxz2ojdvmieg2nhphvputvp/app.bsky.feed.post/3mmo5oc3tccd2"
  },
  "coverImage": {
    "$type": "blob",
    "ref": {
      "$link": "bafkreidpu5qzkirh6q3lxjqt5yq2bdemvpf35zvftcv3xnioh56ynglrla"
    },
    "mimeType": "image/png",
    "size": 614783
  },
  "description": "Fuenfzehn Tage Nginx-Logs mit $ssl_curve. Wer spricht schon X25519MLKEM768, wer haengt noch auf klassischem X25519 oder sogar TLS 1.2? Ein Blick auf Browser, AI-Crawler, Suchmaschinen, Fediverse, RSS-Reader und ein paar ueberraschende Ausreisser.",
  "path": "/2026/04/22/post-quantum-tls-15-tage-ssl-curve-auswertung/",
  "publishedAt": "2026-05-25T09:21:31.000Z",
  "site": "https://www.kernel-error.de",
  "tags": [
    "FreeBSD",
    "Hardening",
    "InfoSec",
    "Networking",
    "nginx",
    "PostQuantum",
    "Sysadmin",
    "TLS",
    "Post-Quantum TLS für Nginx auf FreeBSD 15",
    "von SEO zu AEO: llms.txt und llms-full.txt",
    "den Einstellungs-Beitrag",
    "Post-Quantum TLS für Nginx, X25519MLKEM768 auf FreeBSD 15 konfigurieren",
    "Post-Quantum TLS für E-Mail, Postfix und Dovecot",
    "Quantensichere Kryptografie mit OpenSSH auf FreeBSD 15",
    "TLS-ECDHE mit AES-256-GCM-SHA384 einfach erklärt",
    "fragen"
  ],
  "textContent": "Vor einigen Wochen habe ich Nginx hier auf **X25519MLKEM768** umgestellt und den Weg dorthin in einem eigenen Beitrag dokumentiert: Post-Quantum TLS für Nginx auf FreeBSD 15. Am Ende des Beitrags stand ein kleines Versprechen. Ich erweitere das Logging um die ausgehandelte Key-Exchange-Gruppe, lasse das ein paar Wochen laufen und werte dann aus, wer was tatsächlich spricht. Das ist jetzt eingelöst.\n\n### Der Messaufbau, in zwei Zeilen\n\nNginx kennt die Variable `$ssl_curve`. Die ist seit Ewigkeiten verfügbar und liefert pro Verbindung zurück, welche Kurve bzw. Gruppe beim TLS-Handshake benutzt wurde. Also `X25519MLKEM768`, `X25519`, `secp384r1`, `prime256v1` und so weiter. Im Log-Format einfach nach `$ssl_cipher` eingehängt, einen Reload in den Nginx geschickt, fertig.\n\n\n    log_format goa_ext\n      '$remote_addr - $remote_user [$time_local] '\n      '\"$request\" $status $body_bytes_sent '\n      '\"$http_referer\" \"$http_user_agent\" '\n      '$host $server_protocol $scheme '\n      '$request_time $upstream_response_time $upstream_status $upstream_addr '\n      '$ssl_protocol $ssl_cipher $ssl_curve $upstream_cache_status';\n\nNach rund 15 Tagen liegen grob **180.000 HTTPS-Handshakes** im Log, verteilt über alles, was so an HTTPS-Clients vorbeikommt. Das ist genug Masse, um ein paar belastbare Muster zu sehen, ohne dass einzelne Ausreißer das Gesamtbild kippen. Exakte Besucherzahlen werde ich in diesem Beitrag bewusst nicht auflisten, das ist auch nicht das Thema. Mich interessiert die relative Verteilung. Wer macht PQ, wer macht es nicht?\n\n### Die eine Zahl vorweg\n\nÜber alle HTTPS-Verbindungen (Browser, Bots, Crawler, Monitore, alles) sieht die Verteilung der Kurven so aus:\n\n\n    X25519MLKEM768   57,0 %   <- Post-Quantum-Hybrid\n    X25519           40,0 %   <- klassisches TLS 1.3\n    secp384r1         2,2 %   <- meist TLS 1.2\n    prime256v1        0,8 %   <- meist TLS 1.2\n\nKlingt erstmal ordentlich. 57 % PQ über das komplette Gemisch, 98 % TLS 1.3, lediglich 2 % TLS 1.2. Aber in dieser Zahl stecken ein paar Dinge versteckt drin, die man erst sieht, sobald man die User-Agents grob auseinandersortiert. Ich habe das in ein paar Kübel geworfen: Browser, AI-Crawler, klassische Suchmaschinen, SEO-Spider, Fediverse-Software, RSS-Reader, Monitore und CLI-Tools. Nicht perfekt, aber brauchbar.\n\n### Browser, die Post-Quantum-Avantgarde\n\nBei echten Browsern (Chrome, Firefox, Safari, Edge) sieht es deutlich freundlicher aus. Zusammengenommen sprechen rund **77 %** der Browser-Verbindungen bereits MLKEM768. Aufgeschlüsselt:\n\n\n    Firefox    87 % PQ   <- klarer Champion\n    Safari     75 % PQ\n    Edge       73 % PQ\n    Chrome     72 % PQ\n    Opera       2 % PQ   <- haengt seltsam weit hinten\n\nFirefox liegt erkennbar vorn. Nicht weltbewegend weit, aber deutlich. Mozilla hat MLKEM768 früh aktiviert und nutzt standardmäßig die Hybrid-Gruppe, wenn der Server sie anbietet. Chrome hängt etwas hinter den anderen und ich vermute, das liegt an den ganzen älteren Chrome-Builds, die in Embedded-Devices, WebViews und seltsamen Apps stecken und auch als Chrome im User-Agent stehen. Opera dagegen nimmt fast immer nur klassisches X25519. Keine Ahnung warum, schaue ich mir vielleicht mal gesondert an.\n\nDas Schöne daran ist: Ich habe für diese 77 % exakt nichts getan außer die Nginx-Konfiguration anzupassen. Kein Opt-in, kein Banner, keine Weiche. X25519MLKEM768 steht ganz oben in `ssl_ecdh_curve` und wird genommen, wenn der Client es kann. Der Rest ist reines Client-Upgrade-Verhalten. Das ist eigentlich die schönste Erkenntnis aus der ganzen Auswertung. Wenn die Serverseite rechtzeitig aktualisiert wird, zieht die Clientseite fast geräuschlos nach.\n\n### AI-Crawler, flächendeckend bei null\n\nJetzt kommt der Teil, den ich so nicht erwartet hätte. Die großen AI-Crawler holen sich hier regelmäßig Inhalte ab (siehe auch von SEO zu AEO: llms.txt und llms-full.txt), der TLS-Stack dahinter ist bei praktisch allen auf dem Stand von vor zwei Jahren:\n\n\n    OpenAI GPTBot             0 % PQ    -> X25519\n    Anthropic ClaudeBot       0 % PQ    -> X25519\n    Meta AI (ExternalAgent)   0 % PQ    -> X25519\n    PerplexityBot             0 % PQ    -> X25519\n    ChatGPT-User              0 % PQ    -> X25519\n    OpenAI SearchBot          0 % PQ    -> X25519\n    GoogleOther               0 % PQ    -> X25519\n    Amazonbot                 0 % PQ    -> TLS 1.2 + secp384r1\n\nAmazon ist nochmal ein eigenes Kapitel. Amazonbot kommt hier ausschließlich mit **TLS 1.2** und **secp384r1**. Das ist ein TLS-Stack, den ich persönlich bei einem Unternehmen, das Cloud-Sicherheit verkauft, nicht mehr erwartet hätte. Aber Messungen lügen nicht.\n\nZwei echte Ausnahmen gibt es:\n\n\n    ByteDance Bytespider     91 % PQ   <- ueberraschend\n    DuckAssistBot           100 % PQ   <- auch ueberraschend\n\nAuf diese zwei hätte ich nicht gesetzt. TikToks Crawler macht zu über 90 % PQ, DuckDuckGos AI-Helper zu 100 %. Wer hätte das gedacht.\n\n### Klassische Suchmaschinen, auch nicht besser\n\nBei den traditionellen Suchmaschinen ist das Bild fast identisch zum AI-Lager:\n\n\n    Googlebot       0 % PQ\n    Applebot        0 % PQ\n    PetalBot        0 % PQ\n    Baiduspider     0 % PQ\n    SeznamBot       0 % PQ\n    Qwant           0 % PQ\n    YandexBot       1 % PQ\n    Bingbot         0 % PQ und zu 99,6 % auf TLS 1.2 + secp384r1\n    DuckDuckBot    84 % PQ   <- der einzige helle Fleck\n\nBesonders bitter: Bingbot. Der läuft hier praktisch ausschließlich auf TLS 1.2 mit secp384r1. Microsofts Produktions-Webcrawler, 2026, mit einem TLS-Stack, den Webauditoren seit Jahren rot anstreichen. Googlebot ist immerhin auf TLS 1.3, aber halt ohne PQ. Der einzige, der fürs Thema etwas tut, ist DuckDuckBot. Respekt dafür.\n\n### SEO-Spider, am weitesten hinten\n\nDer traurigste Haufen. AhrefsBot, SemrushBot, MJ12bot, DotBot, Barkrowler, DataForSeoBot, SeekportBot, Vebidoobot, alle zwischen 0 % und 3 % PQ. Vebidoobot kommt komplett auf TLS 1.2 rein. Das sind kommerzielle Produkte, die von Seitenbetreibern dafür bezahlt werden, Webseiten zu analysieren und Empfehlungen auszusprechen. Analysieren tun sie mit einem TLS-Stack, den sie ihren eigenen Kunden vermutlich als kritischen Finding in den Bericht schreiben würden. Kurios.\n\n### Fediverse, alles drin je nach Codebase\n\nSeit dem Anschluss ans Fediverse ist das hier die zweitgrößte Traffic-Quelle nach den Browsern, deshalb habe ich mir das extra angeschaut. Mastodon stellt davon den Löwenanteil, weil es schlicht die meisten Instanzen gibt:\n\n\n    Mastodon                  62 % PQ\n    snac / GoToSocial /\n      Friendica / Hubzilla    73 % PQ   <- Go/C-basiert\n    Misskey / Sharkey / ...   34 % PQ\n    Akkoma                     0 % PQ\n    Pleroma                    0 % PQ\n\nBei Mastodon gibt es eine große Varianz zwischen den Instanzen, weil die Ruby- und OpenSSL-Version des jeweiligen Server-Hosts entscheidet, ob PQ geht. Aktuelle Distribution mit OpenSSL 3.5 oder neuer: dabei. Noch auf OpenSSL 3.0 festhängend: nicht dabei. Der Schnitt liegt bei 62 %, was für ein so diverses Ökosystem schon erstaunlich ordentlich ist.\n\nsnac und GoToSocial liegen deutlich höher, weil sie in Go beziehungsweise C geschrieben sind und moderne TLS-Stacks mitbringen. Akkoma und Pleroma (beide Elixir/Erlang) zeigen dagegen gar keine PQ-Adoption. Das hängt an der OpenSSL-Version, die die BEAM-VM dort nutzt. Misskey und die ganzen Forks dazwischen liegen bei rund einem Drittel.\n\n### RSS-Reader, unerwartet modern\n\nHätte ich vorher schätzen sollen, hätte ich RSS-Reader eher am Ende dieser Liste verortet. Alte Technologie, alte Software, wahrscheinlich alter TLS-Stack. Stimmt aber nicht:\n\n\n    Miniflux              100 % PQ   <- Go-basiert\n    FreshRSS               82 % PQ\n    NextCloud-News         81 % PQ   <- zahlenmaessig vorn\n    Tiny Tiny RSS          37 % PQ\n    Inoreader               0 % PQ\n    Feedly                  0 % PQ   <- haengt auch hinten\n\nMiniflux macht 100 % PQ, weil es in Go geschrieben ist und ab Go 1.24 MLKEM768 standardmäßig im TLS-Stack sitzt. FreshRSS und NextCloud-News laufen meist auf aktuellen PHP/curl-Umgebungen und ziehen MLKEM darüber mit. Feedly als kommerzieller Anbieter: 0 %. Also genau das Gegenteil dessen, was ich erwartet hätte. Self-Hosted ist hier eindeutig moderner unterwegs als die SaaS-Variante.\n\n### CLI-Werkzeuge und Kuriositäten\n\n\n    go-http-client     93 % PQ   <- Go 1.24+\n    curl               30 % PQ   <- je nach OpenSSL-Build\n    python-requests    16 % PQ\n    Node (axios)       61 % PQ\n    okhttp              0 % PQ\n    wget                0 % PQ\n    Twitterbot         97 % PQ   <- unerwartet weit vorn\n\nDas Muster ist eigentlich immer dasselbe. Der TLS-Stack der Laufzeitumgebung entscheidet. Go ≥ 1.24 macht es automatisch, moderne Node-Versionen bringen einen aktuellen OpenSSL mit, Python und curl hängen an der Distribution. okhttp auf Android und wget: Fehlanzeige.\n\nKleiner Spaß am Rande. Twitterbot ist zu 97 % auf MLKEM. Also ausgerechnet der Link-Preview-Crawler von X/Twitter ist moderner unterwegs als alle anderen Social-Preview-Bots zusammen. WhatsApp: 4 %, Discord: 0 %, LinkedIn ist kaum vertreten. Warum Twitter? Keine Ahnung. Vermutlich ein moderner Go-Client unter der Haube.\n\n### TLS 1.2, wer hängt noch ganz unten?\n\n2 % des Traffics kommen komplett mit TLS 1.2, also ohne jede Chance auf PQ. Die Top-Kandidaten sind:\n\n\n    vebidoobot (SEO-Spider)\n    Amazonbot\n    DotBot, MJ12bot (SEO)\n    theoldreader.com (RSS-SaaS)\n    http.rb/Mastodon auf aelteren Instanzen\n    ein paar vereinzelte Alt-Browser und Skype-Link-Previews\n\nAlso fast ausschließlich kommerzielle Crawler, deren TLS-Library vor der ganzen 1.3-Welle kompiliert wurde, und ein paar ältere Mastodon-Instanzen. Reale Leser sind so gut wie nicht betroffen. Wer heute einen Feed-Reader mit TLS 1.2 nutzt, hat vermutlich andere Probleme zuerst zu lösen.\n\n### Gibt es einen Trend in den 15 Tagen?\n\nNicht wirklich. Der PQ-Anteil pro Tag schwankt zwischen 46 % und 65 %, je nach Traffic-Mix (mehr Browser an Wochentagen, mehr Crawler nachts und am Wochenende). Einen klaren Aufwärts- oder Abwärtstrend gibt es nicht. Wir sind im Plateau. Die Browser haben den Sprung gemacht, der Rest der Welt noch nicht. Der nächste Sprung kommt, wenn die großen Crawler-Betreiber ihre Go-, Python- oder Node-Stacks aktualisieren oder OpenSSL 3.5+ in den gängigen Distributionen ankommt. Bei Debian Trixie, RHEL 10 und Ubuntu 26.04 sollte das passieren, dann reden wir in einem Jahr nochmal.\n\n### Was ich daraus mitnehme\n\n  * Echte Besucher sind bei MLKEM768 schon sehr weit. Browser-Entwicklung funktioniert erstaunlich gut.\n  * AI- und SEO-Crawler sind deutlich hinter dem, was man erwarten würde. Cutting Edge in der Marketing-Abteilung, Uralt-Stack im Maschinenraum.\n  * Fediverse-Software ist so divers wie ihre Codebasen. Bei Mastodon entscheidet die Instanz, nicht die Software.\n  * RSS-Reader sind unerwartet modern unterwegs. Self-Hosted schlägt SaaS auch hier.\n  * Am Ende hängt fast alles an der OpenSSL-Version unter der Anwendung. Wieder mal.\n  * Bingbot auf TLS 1.2 ist 2026 trotzdem noch bemerkenswert.\n\n\n\nWas mich am meisten gefreut hat: Ich habe keinerlei Reibungsverluste gesehen. Kein Client ist wegen PQ gestolpert, keine Verbindung ist fehlgeschlagen, die vorher funktioniert hätte. Der Handshake wählt einfach die beste gemeinsame Gruppe und gut ist. Deshalb nochmal der Appell an alle, die den Einstellungs-Beitrag noch vor sich haben: Das ist wirklich ein Zweizeiler. Macht es einfach.\n\n### Nächster Check in ein paar Monaten\n\nIch lasse das Logging weiterlaufen und schaue in ein paar Monaten nochmal rein. Was mich besonders interessiert:\n\n  * Wann machen OpenAI, Anthropic und Meta ihren Crawler modern? Bleibt das auf Jahre bei 0 % PQ, oder kommt da plötzlich ein Sprung?\n  * Schafft es OpenSSL 3.5 in die nächsten Long-Term-Release-Linuxe, und wie schnell ziehen Mastodon-Instanzen nach?\n  * Springt Googlebot irgendwann auf PQ um? Bisher nein. Wenn das kommt, dürfte das unmittelbar sichtbar sein.\n  * Kommt TLS 1.3 für Amazonbot? Zumindest das wäre ein Anfang.\n\n\n\n### Siehe auch\n\n  * Post-Quantum TLS für Nginx, X25519MLKEM768 auf FreeBSD 15 konfigurieren (der Vorgängerbeitrag)\n  * Post-Quantum TLS für E-Mail, Postfix und Dovecot\n  * Quantensichere Kryptografie mit OpenSSH auf FreeBSD 15\n  * TLS-ECDHE mit AES-256-GCM-SHA384 einfach erklärt\n\n\n\nWie immer: Bei Fragen, fragen.",
  "title": "Post-Quantum TLS auf Nginx: 15 Tage $ssl_curve ausgewertet, wer macht mit?"
}