Automatische Sleuteluitwisseling: snellere, post-quantum veilige origin-handshakes voor 45 miljard dagelijkse verbindingen (en meer)

Telkens wanneer Cloudflare een nieuwe TLS 1.3-verbinding opent naar een origin-server, moeten we een gok wagen: het protocol vereist dat we ons vastleggen op een algoritme voor sleutelovereenkomst in het allereerste pakket dat we verzenden, nog voordat de origin ons iets heeft verteld over zichzelf of wat deze ondersteunt. Als we juist gokken, wordt de handshake in één round trip voltooid. Gokken we fout, dan antwoordt de origin met een HelloRetryRequest, beginnen we opnieuw en kost de verbinding twee round trips.

Jarenlang was onze gok voor elke origin op het internet hetzelfde: X25519. Dit is breed ondersteund, maar zoals blijkt, suboptimaal voor ongeveer 30% van de origin-verbindingen die we sindsdien hebben gemeten.

Vandaag kondigen we Automatic Key Exchange aan, een uitbreiding van Automatic SSL/TLS die de gok vervangt door een meting. We scannen elke origin om te ontdekken welke algoritmen voor sleutelovereenkomst worden ondersteund en geprefereerd, en gebruiken vervolgens dat algoritme bij de eerste poging. Hierbij geven we de voorkeur aan de post-quantum hybride X25519MLKEM768, waar dat mogelijk is.

Met de lopende uitrol van Automatic Key Exchange over origin-verbindingen is het aantal HelloRetryRequests gedaald van ongeveer 52% naar 3,7%, wat de latentie van de connection handshake op p90 met meer dan 150 ms heeft verminderd. Daarnaast hebben, als onderdeel van deze uitrol, honderdduizenden domeinen nu post-quantum origin-verbindingen zonder dat iemand dit hoefde te configureren, een aantal dat dagelijks groeit.

Hoewel de milliseconden belangrijk zijn, is dat tweede deel wellicht belangrijker. Er is op dit moment waarschijnlijk een tegenstander die versleuteld verkeer opneemt dat hij nu nog niet kan lezen, in de gok dat dit in de toekomst wel kan (een aanval die bekend staat als harvest-now, decrypt-later). Cloudflare zet alles op alles om het internet tegen 2029 quantum-veilig te maken, het jaar waarin sommige experts schatten dat klassieke encryptie-algoritmen kunnen worden gekraakt. Die dag heeft een naam: Q-Day. Het halen van die deadline kan niet afhangen van miljoenen website-eigenaren die allemaal expert-cryptografen moeten worden. Het moet automatisch gaan. Tot today vereiste de voorkeur voor post-quantum verbindingen een handmatige instelling: of je schakelt ze in aan de zijde van Cloudflare, of je laat je origin-server erop staan. Het was makkelijk om dit fout te doen. Maar vandaag is het simpelweg... automatisch.

TLS 1.3-handshake: het raden van het sleuteluitwisselingsalgoritme

Elke beveiligde webverbinding begint met een TLS-handshake, die de server authenticeert en een gedeelde geheime sleutel afleidt.

Aangezien Cloudflare fungeert als een reverse proxy, bestaat wat lijkt op één enkele beveiligde verbinding in feite uit twee verbindingen: één tussen de bezoeker en Cloudflare, en een tweede tussen Cloudflare en de origin-server. Elke verbinding werkt onafhankelijk, met een eigen handshake, identiteitscontroles en encryptiesleutels.

Automatic Key Exchange heeft invloed op de tweede verbinding. Wanneer Cloudflare verbinding maakt met de origin, treedt Cloudflare op als de TLS-client en moet de handshake starten. We initiëren de verbinding door een ClientHello-bericht te sturen met de hostname en een lijst met ondersteunde algoritmen voor sleutelovereenkomst.

In het ideale scenario kan TLS 1.3 een nieuwe versleutelde verbinding opzetten in slechts één netwerk-round trip. In dit geval stuurt Cloudflare een ClientHello met de ondersteunde algoritmen, samen met één of meer client keyshares. Als de origin deze keuze accepteert, reageert deze en is de handshake voltooid. Deze voorspellende sleuteluitwisseling is een innovatie van TLS 1.3 en een belangrijke reden waarom het sneller is dan TLS 1.2.

Als de origin echter een andere optie prefereert, stuurt deze een HelloRetryRequest (HRR) en vraagt Cloudflare om het opnieuw te proberen. Cloudflare stuurt dan een tweede ClientHello en genereert een nieuwe client keyshare op basis van het door de origin opgegeven algoritme. De verbinding slaagt nog steeds, maar de retry voegt een volledige netwerk-round trip toe voordat Cloudflare content kan ophalen.

Ongeacht de methode genereert de server met behulp van de client keyshare de gedeelde sleutel. De server stuurt vervolgens een server keyshare terug, waarmee de client ook de gedeelde sleutel kan berekenen. Deze gedeelde sleutel wordt gebruikt om de rest van de verbinding te beveiligen met symmetrische cryptografie, zoals AES.

De kosten van de veilige gok

Jarenlang was onze initiële gok voor de client keyshare voor origin-verbindingen via TLS 1.3 statisch; we stuurden altijd X25519, terwijl we ondersteuning voor andere algoritmen adverteerden. Dit was een veilige strategie omdat meer dan 95% van de origins X25519 ondersteunt, en origins die dat niet deden een HelloRetryRequest (HRR) konden sturen zonder de verbinding te verbreken.

X25519 is echter kwetsbaar voor quantumcomputers. Sinds september 2023 adverteren we ondersteuning voor post-quantum sleutelovereenkomst aan origins: eerst als X25519Kyber768Draft00 en nu als X25519MLKEM768 (de gestandaardiseerde versie). Cruciaal is dat het adverteren van ondersteuning verschilt van het leiden met een keyshare in de ClientHello. Een X25519MLKEM768-keyshare is 1.216 bytes, vergeleken met de 32 bytes van X25519, waardoor de ClientHello groter wordt dan één enkel netwerkpakket. Hoewel de TLS-standaard multi-pakket segmenten toestaat, kunnen sommige verouderde middleboxes en origin-servers falen bij het ontvangen van ClientHello-berichten die over meerdere pakketten zijn verdeeld. In een eerdere studie faalden ongeveer 0,34% van de gescande origins bij het voltooien van de TLS-handshake wanneer ze eerst een post-quantum keyshare ontvingen, terwijl de overgrote meerderheid van de origins nog steeds vertrouwde op de klassieke X25519.

Om eventuele onderbrekingen van origin-verbindingen te voorkomen, gebruikten we de HRR als veiligheidsklep. We adverteerden alleen post-quantum ondersteuning, stuurden een klassieke X25519 keyshare, en vereisten dat capabele origins een post-quantum uitwisseling aanvragen via een retry. Voor origins die de HRR-flow niet ondersteunden, hadden klanten de optie om handmatig te kiezen voor het leiden met een X25519MLKEM768-keyshare. Tussen 2023 en nu is het percentage origins dat post-quantum sleuteluitwisselingsalgoritmen ondersteunt gegroeid van 0,5% naar 12,8%.

Hoewel veilig, voegde deze standaardinstelling (alleen upgraden naar post-quantum via retry) onnodige latentie toe om twee redenen:

  1. Hoewel alle moderne builds van OpenSSL, BoringSSL en rustls X25519MLKEM768 ondersteunen, gaan ze anders om met een klassieke X25519 keyshare. Sommige oudere builds accepteren deze standaard, tenzij ze expliciet zijn geconfigureerd om post-quantum keyshares te prioriteren, terwijl nieuwere builds direct een HRR versturen om post-quantum verbindingen te prioriteren.
  2. Meer dan 6% van de origins prefereert P-256 of P-384 boven X25519, wat zelfs voor puur klassieke verbindingen een HRR-round trip veroorzaakt door onze statische keuze voor de initiële client keyshare.

Om deze verloren round trips te elimineren, zijn we begonnen met het scannen van origin-servers om hun exacte mogelijkheden voor sleutelovereenkomst in kaart te brengen als onderdeel van Automatic SSL/TLS. Met deze scanresultaten passen we onze initiële keyshare automatisch aan per origin: we maximaliseren post-quantum verbindingen zonder risico op site-outages, terwijl we de verbindingen versnellen voor de betreffende domeinen.

Uitbreiding van Automatic SSL/TLS naar het post-quantum tijdperk

Automatic SSL/TLS omvat nu Automatic Key Exchange. Bij miljoenen origins brengt het gokken van verschillende keyshares operationele risico's met zich mee, omdat we vooraf geen kennis hebben van de configuratie van een individuele origin. In plaats van de capaciteit af te leiden, meten we deze direct via de scan-pipeline die al Automatic SSL/TLS aandrijft.

Voor een groeiend aantal origins betekent dit post-quantum sleutelovereenkomst bij de allereerste poging tijdens de setup van de verbinding, zonder extra round trips en zonder handmatige configuratie.

Zo werkt het:

  • Voor elke TLS 1.3-capabele origin voeren we een serie lichte TLS-handshakes uit, waarbij elke handshake precies één sleutelovereenkomstgroep aanbiedt: X25519, P-256, P-384, P-521, of X25519MLKEM768. Deze probes onthullen de volledige set algoritmen die de origin ondersteunt. Omdat het actieve scannen buiten het productieverkeer gebeurt, bevestigen we dat zowel uw origin als het netwerk ertussen verbindingen met een sterkere sleutelovereenkomst kunnen afhandelen voordat er echt verkeer van afhankelijk is.
  • Een enkel domein is vaak verbonden aan meerdere subdomeinen die naar verschillende origins met verschillende capaciteiten kunnen leiden. We evalueren elk subdomein onafhankelijk en wegen de resultaten op basis van het werkelijke verkeersvolume. Dit zorgt ervoor dat een domeinbrede voorkeur het HTTP-verkeersvolume weerspiegelt in plaats van een slapend subdomein gelijk te stellen aan het drukste eindpunt.
  • Van de ondersteunde groepen selecteren we de sterkste kandidaat volgens een strikte prioriteitsvolgorde: eerst post-quantum hybriden (X25519MLKEM768), gevolgd door het snelste klassieke algoritme dat door de origin wordt geaccepteerd (X25519, P-256, P-384, of P-521).
  • Zodra de optimale voorkeur bekend is, rollen we deze uit. De nieuwe voorkeur gaat eerst naar een klein deel van het verkeer van die origin, waarna het systeem de fouten en de HelloRetryRequest (HRR) rate bewaakt. Als de retries boven de baseline van die origin stijgen, draaien we de wijziging terug. In het slechtste geval kost een foutieve voorkeur ons een extra round trip latentie, maar geen gebroken TLS-verbinding.
  • Origin-configuraties veranderen over tijd. We scannen elke origin dagelijks, zodat een server die post-quantum ondersteuning toevoegt, of stopt met het ondersteunen van de curve die we gebruikten, bij de volgende scan een nieuwe voorkeur krijgt.

Voor de meeste klanten is er niets te configureren. Als uw origin TLS 1.3 spreekt, onderhandelen we automatisch de sterkste sleuteluitwisseling die deze ondersteunt.

Automatische Sleuteluitwisseling configureren

Automatic Key Exchange is standaard actief voor alle bestaande en nieuwe domeinen. Indien gewenst kunt u deze instellingen onafhankelijk beheren in het Cloudflare-dashboard onder SSL/TLS > Overview > Configure > Origin connection & post-quantum encryption.

Met de toggle voor Automatic Key Exchange ingeschakeld, scant Cloudflare uw origins out-of-band en leidt met een dynamisch geselecteerde keyshare. Als dit is uitgeschakeld, stopt het scannen en valt Cloudflare terug op een vaste/statische standaardvolgorde voor sleutelovereenkomst.

We hebben ook een nieuwe instelling voor Compliance requirements geïntroduceerd onder Automatic Key Exchange. U kunt filteren welke sleutelovereenkomsten Cloudflare mag gebruiken en adverteren voor origin-verbindingen:

  • Post-quantum hybrid: Beperkt de onderhandeling uitsluitend tot hybride post-quantum sleutelovereenkomsten (X25519MLKEM768), waarbij klassieke algoritmen volledig worden verwijderd. Alle succesvolle origin TLS 1.3-verbindingen zijn hiermee gegarandeerd post-quantum veilig.
  • Federal Information Processing Standards (FIPS): Beperkt de onderhandeling uitsluitend tot FIPS-conforme sleutelovereenkomsten.

Het selecteren van beide opties vereist een algoritme dat aan beide criteria voldoet; als er geen overlap is, wordt de configuratie geweigerd.

Let op: het afdwingen van post-quantum hybrid op een origin die geen ondersteuning biedt voor X25519MLKEM768, laat geen wederzijds ondersteund algoritme over, waardoor alle TLS 1.3-verbindingen zullen falen. Tenzij u een strikte beleidsverplichting heeft, is het aanbevolen beide opties uit te laten staan en Automatic Key Exchange de optimale algoritmen veilig te laten onderhandelen.

Samen het internet veiliger en sneller maken

Automatic Key Exchange werkt voor domeinen waarvan de origins TLS 1.3 spreken. Van de eerste cohort domeinen zagen we dat ongeveer 64% op de klassieke X25519 bleef als voorkeur. Ongeveer 33% heeft nu de voorkeur ingesteld op X25519MLKEM768, waardoor verkeer naar die origins in één round trip beschermd is tegen harvest-now, decrypt-later quantum-aanvallen. De resterende 3% selecteerde een andere klassieke curve, zoals P-384, P-256 of P-521.

Dagelijks krijgen ongeveer 9.000 domeinen een andere voorkeur dan X25519, waarbij bijna al deze domeinen direct overstappen op post-quantum sleuteluitwisseling.

Voorheen vereiste bijna elke post-quantum origin-handshake een HelloRetryRequest (HRR) omdat onze statische gok standaard op de klassieke X25519 stond. Het aandeel post-quantum origin TLS 1.3-verkeer dat wordt voltooid zonder een HelloRetryRequest is gestegen van 0% naar 99,2%.

Het post-quantum verkeer groeit van ongeveer 25 miljard naar 45 miljard verbindingen per dag, mede door de upgrade van klassieke verbindingen via Automatic Key Exchange. Actieve probing stelde ons in staat duizenden origins te ontdekken waarvan de post-quantum ondersteuning nooit in hun normale verkeer naar voren kwam.

Daarnaast helpt Automatic Key Exchange bij het koppelen van origins aan hun geprefereerde klassieke curve, wat de algemene HRR-percentages verlaagt. Voor de gescande domeinen daalde het percentage verbindingen dat een HRR vereiste van ongeveer 52% naar slechts 3,7%. Dit vermindert de p90 latentie met meer dan 150 ms voor de gescande origins, wat vooral voordelig is voor dynamische requests en CDN cache misses.

Is de server post-quantum capabel?

Er zijn verschillende tools om te controleren of een server post-quantum sleutelovereenkomst ondersteunt. Cloudflare biedt hiervoor een tool via Cloudflare Radar. Let op: als u een hostname invoert die via Cloudflare wordt geproxt, controleert Radar de verbinding met Cloudflare en niet met de origin-server daarachter.

Naast de ondersteuning van algoritmen kan de tool ook controleren op bugs in de post-quantum TLS-implementatie. Fouten komen vaak voort uit verouderde middleboxes, firewalls of server-buffers die multi-pakket payloads weggooien of falen bij het herassembleren van een ClientHello die over TCP-segmenten is verdeeld.

Automatic Key Exchange zal een domein waarvan de origin deze controles niet doorstaat niet omzetten, dus het oplossen van deze problemen is essentieel voor de upgrade.

Wat als uw origin-server nog geen post-quantum sleuteluitwisseling ondersteunt?

Zelfs als uw origin nu geen post-quantum encryptie ondersteunt, is het inschakelen van Automatic Key Exchange nog steeds nuttig. Het systeem vindt wat uw origin wél ondersteunt en kan onnodige HelloRetryRequest round trips vermijden door te leren welke klassieke curve uw origin prefereert.

Op dit moment ondersteunen meer dan 12% van de individuele origins in ons netwerk post-quantum encryptie. Deze ondersteuning neemt toe naarmate recente versies van BoringSSL, OpenSSL en rustls deze integreren.

Als u post-quantum bescherming wilt toevoegen voor uw origin-verbindingen, heeft u twee opties:

  1. Gebruik Cloudflare Tunnel. De verbinding tussen cloudflared en Cloudflare maakt al gebruik van post-quantum sleutelovereenkomst. Dit is de eenvoudigste optie als u de TLS-software op uw publieke origin-endpoint niet kunt wijzigen.
  2. Upgrade uw TLS-endpoint. Veel huidige frameworks en TLS-bibliotheken schakelen X25519MLKEM768 standaard in. Controleer echter of handmatige instellingen voor curves deze defaults overschrijven. Het is belangrijk om elk apparaat dat TLS beëindigt of inspecteert (load balancers, WAF-appliances, middleboxes) te controleren op ondersteuning voor X25519MLKEM768.

Wat is de volgende stap?

Automatic Key Exchange is de tweede stap in een langer traject. We werken momenteel aan de volgende punten:

  • Granulariteit per origin: Momenteel worden beslissingen op domeinniveau genomen. We werken aan granulariteit per subdomein/per origin, zodat de sleutelovereenkomst kan variëren over de meerdere origins die één domein bedienen.
  • On-demand scans: We bouwen een optie om via het dashboard of de API een scan on-demand te triggeren, zodat u na een upgrade van uw origin direct kunt overstappen op een betere sleutelovereenkomst. Deze scan zal ook dienen als diagnostische tool in het dashboard om te zien welke overeenkomsten succesvol worden onderhandeld.
  • Automatische post-quantum origin-authenticatie: Post-quantum sleutelovereenkomst voorkomt dat verkeer in de toekomst wordt ontsleuteld, maar niet dat een aanvaller een certificaat vervalst om uw origin te imiteren. Dit vereist post-quantum authenticatie. We plannen om Automatic SSL/TLS scanning uit te breiden naar het detecteren van ondersteuning voor post-quantum authenticatie (zoals ML-DSA certificaten). Zodra dit is gedetecteerd, kan Cloudflare voor klanten die strikte bescherming wensen de klassieke fallback uitschakelen, waardoor downgrade-risico's worden geëlimineerd.