TLS, VPN, API Gateway: kje se vaša kriptografska zaščita dejansko konča?

Izdaja 11 serije »Postkvantna varnost v slovensko-nemški dobavni verigi«. Za skrbnike omrežij in sistemov, ki vzdržujejo povezave do nemških naročnikov.

Nemški naročnik vam sporoči, da njegov portal za dobavitelje zdaj podpira hibridni dogovor o ključu z ML-KEM. Odprete portal v brskalniku, pogledate podrobnosti povezave in vidite klasični X25519. Brskalnik je nov, portal tudi. Vmes pa stoji vaš požarni zid, ki odhodni promet zaradi pregleda vsebine razbije in znova vzpostavi. In vaš požarni zid hibridnega postopka ne pozna.

V tem članku: Povezava ni puščica · Kje se šifriranje konča · Kaj je mogoče že danes · Kaj kanal ne varuje · Primer · Kateri odseki so vaši · Pregled TLS · Kako preveriti · Kaj pravi URSIV · Vprašanje za naročnika · Priloga: odseki

Na shemi je povezava do naročnika ena puščica: od vašega sistema ERP do njegovega, nad njo ključavnica. V resnici je to veriga. Vsaka naprava, ki šifrirano povezavo sprejme, jo dešifrira in po potrebi vzpostavi novo.

Za postkvantno načrtovanje iz tega sledi preprosto pravilo: vsak odsek ima svoj dogovor o ključu. Napadalec, ki promet prestreza danes, da bi ga dešifriral pozneje, si izbere odsek, ki se še vedno dogovarja klasično. Da je drug odsek zaščiten hibridno, njemu ne škodi in vam ne pomaga.

Na vaši strani so tipična mesta, kjer se povezava konča in začne nova:

• požarni zid ali posrednik s pregledom TLS, ki razbije odhodne povezave, da bi pregledal vsebino;
• odjemalec za izmenjavo datotek (SFTP, AS2, HTTPS), pogosto vgrajen v sistem ERP ali v skripto;
• naprava VPN za povezavo med lokacijami ali za dostop serviserjev;
• lastni API Gateway ali obratni posrednik, če naročnik kliče vas;
• storitve v oblaku, ki v vašem imenu pošiljajo ali sprejemajo podatke.

Na naročnikovi strani so podobna mesta: omrežje za dostavo vsebin, izenačevalnik obremenitve, strežnik za izmenjavo datotek v DMZ, integracijska platforma.

Vsako tako mesto je meja zaupanja: kdor napravo upravlja, vidi podatke; kdor jo nastavlja, določa dogovor o ključu naslednjega odseka.

Za dogovor o ključu že obstajajo hibridni postopki, ki združijo klasični in postkvantni postopek:

• TLS 1.3: skupina X25519MLKEM768, specificirana kot osnutek IETF (draft-ietf-tls-ecdhe-mlkem). Podpirajo jo sodobni brskalniki in OpenSSL od različice 3.5 (april 2025). TLS 1.2 takšnega mehanizma nima.
• SSH: OpenSSH od različice 10.0 (april 2025) privzeto uporablja hibridni dogovor o ključu z ML-KEM, če ga poznata obe strani.
• IPsec/IKEv2: RFC 9370 (maj 2023) omogoča več zaporednih dogovorov o ključu; podpora je odvisna od proizvajalca in strojne programske opreme naprave.

Pri vseh velja isto: dogovori se tisto, kar znata obe strani. Sodoben odjemalec ob starejšem strežniku se dogovori klasično, brez opozorila.

Kanal s postkvantnim dogovorom o ključu je dragocen, a varuje natanko eno: podatke med prenosom po tem odseku. Ne varuje:

• podatkov na koncih odsekov: izhodnih map, čakalnih vrst, začasnih datotek, dnevnikov z vsebino;
• shranjenih podatkov v bazah, arhivih in varnostnih kopijah; to je posebna tema;
• identitete druge strani. Kdo govori s kom, določa overjanje s potrdili in ključi, ne dogovor o ključu.

Recimo, da ima dobavitelj odlitkov z Gorenjske tri nemške naročnike. Povezave:

Skrbnik ugotovi, da so vse tri šibke točke na njegovi strani: pregled TLS na požarnem zidu, stara knjižnica v integraciji in strojna programska oprema naprave VPN. Nobenega od teh ne more urediti naročnik. Prvi trenutek je to neprijetno spoznanje, drugi olajšanje. Vsi trije pa so rešljivi: izjema za pregled TLS pri znanih naslovih naročnikov, posodobitev knjižnice, načrtovana posodobitev požarnega zidu.

Za vsak odsek veljajo tri vprašanja: kdo upravlja levi konec, kdo desnega, kdo določa nastavitve. Razmejitev je praviloma jasna:

• Vaši so odseki od vašega sistema do vašega roba omrežja ter vaša stran odseka do naročnika: odjemalec, požarni zid, naprava VPN, nastavitve.
• Naročnikovi so njegova stran in vse za njegovim robom.
• Skupen je samo odsek med obema robovoma. Dogovor o ključu tam deluje šele, ko obe strani podpirata isti postopek.

Če naročnik od vas zahteva »kvantno varno povezavo«, ne potrjujte povezave. Potrdite svoje odseke in vprašajte za njegove.

Pregled šifriranega prometa na požarnem zidu ali posredniku je pogosta in smiselna varnostna praksa. Za postkvantni prehod pa pomeni, da se povezava do naročnika ne začne pri odjemalcu, ampak pri vašem požarnem zidu. Ne glede na to, kaj zna brskalnik ali odjemalec, se z naročnikom dogovarja požarni zid.

Možnosti so tri, in vsaka ima svojo ceno:

• Posodobitev naprave, ko proizvajalec podpira hibridne skupine. Najčistejša rešitev, odvisna od proizvajalčevega načrta in vaše licence.
• Izjema za znane naslove naročnikov: promet do njih požarni zid prepusti brez razbijanja. Odjemalec se dogovarja neposredno, vi pa se odpoveste pregledu tega prometa. Odločitev zapišite in utemeljite.
• Zavestno sprejeto tveganje do posodobitve, z rokom in odgovorno osebo.

Nobena od teh odločitev ni napačna. Napačno je samo, da je nihče ne sprejme in se odsek preprosto pozabi.

Trditev »podpiramo« ni dokaz. Preverite dejanski dogovor:

• TLS: orodje openssl s_client od različice 3.5 izpiše dogovorjeno skupino; podrobnosti povezave v brskalniku pokažejo isto za prvi odsek.
• SSH: ssh -v izpiše dogovorjeni postopek za izmenjavo ključev.
• IPsec: dnevnik naprave VPN ali stanje varnostnih povezav (SA) pokaže dogovorjene skupine.

Meritev opravite z istega mesta, s katerega teče produkcijski promet. Meritev z vašega prenosnika mimo požarnega zidu meri drug odsek.

Urad Vlade RS za informacijsko varnost je 20. aprila 2026 objavil gradivo »Varna digitalna prihodnost v dobi kvantnih računalnikov – prehod v post-kvantno kriptografijo (PQC)«. V obvestilu priporoča, da zavezanci po Zakonu o informacijski varnosti (ZInfV-1) in druge organizacije začnejo s prehodom: s pregledom obstoječe uporabe kriptografije, pripravo načrtov prehoda in postopnim uvajanjem kvantno odpornih rešitev. Rokov obvestilo ne določa.

Za dobavitelja nemškega naročnika to pomeni dvoje. Prvič: priporočilo velja tudi za podjetja, ki niso zavezanci. Drugič: »pregled obstoječe uporabe kriptografije« pri povezavah pomeni natanko popis odsekov iz tega članka.

„Welche Verfahren für den Schlüsselaustausch unterstützt Ihr Endpunkt für unsere Anbindung heute, wann planen Sie eine Umstellung, und können Sie uns das tatsächlich verhandelte Verfahren aus Ihren Protokollen bestätigen?“

Prevod: Katere postopke za dogovor o ključu podpira vaša končna točka za našo povezavo danes, kdaj načrtujete spremembo in ali nam lahko dejansko dogovorjeni postopek potrdite iz svojih dnevnikov?

Zakaj tako? Ker skupni odsek deluje šele, ko sta obe strani pripravljeni, in ker potrditev iz naročnikovih dnevnikov preveri tudi vašo stran. Če naročnik vidi klasični postopek, čeprav ste svojo stran posodobili, je vmes še ena meja, ki je niste upoštevali.

Nemška izdaja te teme se obrača na omrežne in integracijske arhitekte pri naročnikih: „Der verschlüsselte Kanal allein macht Ihre Lieferantenanbindung nicht quantensicher“ (v nemščini). Prejšnja izdaja: Postkvantna PKI: zakaj zamenjava certifikata ne zadostuje

Shema povezave z naročnikom (poenostavljeno, za izmenjavo datotek). Vsaka navpična črta je meja zaupanja; vsak odsek med njimi ima svoj dogovor o ključu. V nemški izdaji je vsebinsko enaka.

 DOBAVITELJ                         |  INTERNET  |        NAROČNIK
                                    |            |
 [ERP] --A--> [odjemalec SFTP] --B--> [požarni zid] ===== C =====> [strežnik DMZ] --D--> [ERP]
                                    |            |        |
          (izhodna mapa:            |            |   (vhodna mapa:
           podatki v mirovanju)     |            |    podatki v mirovanju)

Preglednica odsekov za izpolnjevanje:

Za vsak konec dopolnite: kako dolgo ležijo podatki, ali so šifrirani v mirovanju, kdo ima dostop (izvajalci, ponudniki oblaka), ali dnevniki beležijo vsebino.

Kako brati: A in B sta vaša, D je naročnikov, o C se morata dogovoriti. Če vaš požarni zid razbija povezave, je B samostojen odsek; brez tega se odjemalec dogovarja neposredno z naročnikom.

Vse objavljene izdaje serije: pregled »Postkvantna varnost v dobavni verigi«

Naslednja izdaja (1. 6. 2026): »Postkvantna migracija bo stala. Nepripravljenost lahko stane več.«

Viri (stanje 4. 5. 2026): osnutek IETF draft-ietf-tls-ecdhe-mlkem, revizija 04 (februar 2026); OpenSSL 3.5 Release Notes (april 2025); OpenSSH 10.0 Release Notes (april 2025); RFC 9370 »Multiple Key Exchanges in the Internet Key Exchange Protocol Version 2 (IKEv2)« (maj 2023); NIST FIPS 203 (avgust 2024); URSIV, »Objavljeno gradivo o prehodu v post-kvantno kriptografijo«, gov.si, 20. 4. 2026.

Če vaš požarni zid razbija povezave do naročnikov in ne veste, kaj se za njim dogovori, nam pišite.