POST-QUANTUM CRYPTOGRAPHY-SUPPORTED LOCAL NETWORK GATEWAY SYSTEM AND MULTILAYER BRIDGE METHOD

Abstract

The invention relates to a local gateway system and method that provides transparent access to remote server resources protected by ML-DSA signed certificates in a computing environment with a standard TLS client library that does not directly support post-quantum digital signature algorithms, specifically the Modular-Laffle Based Digital Signature Algorithm (ML-DSA; NIST FIPS 204). The local gateway receives requests in the format / proxy / {domain} / {path} by listening over unencrypted HTTP on the client application side and executes a three-stage prioritized fallback mechanism: (1) spawning a post-quantum TLS client binary embedded in the gateway binary as a subprocess at runtime, (2) routing to a configured remote bridge endpoint, and (3) direct connection with the standard TLS client.HTML and CSS content retrieved from the target server is rewritten using a W3C-compliant DOM parser and regular expression-based rules, and all sub-sources are served through the same local gateway origin. The system is complemented by an embedded HTML dashboard offering a tray interface and live activity monitoring.

Description

1 TARIFF POST-QUANTUM CRYPTOGRAPHY-SUPPORTED LOCAL NETWORK GATEWAY SYSTEM AND MULTILAYERED BRIDGE METHOD 1. TECHNICAL FIELD The present invention relates to the field of computer networks and information security. More specifically, post- Quantum cryptography (Post-Quantum Cryptography — PQC) algorithms, especially Module-Laffed algorithms Module-Lattice Digital Signature Algorithm (ML-DSA); Directly applying these algorithms to remote server resources protected by NIST FIPS 204 is prohibited. Standard Transport Layer Security (TLS) client that does not support a local gateway that provides access from software environments that have libraries It relates to the system and method. The invention also suggests that the said local gateway includes an embedded post-quantum TLS client binary. by running the file as a subprocess and / or a remote bridge by applying to the service, a transparent multi-layered fallback mechanism is available. It relates to a method by which it provides access. 2. STATE OF KNOWLEDGE OF THE ART 2.1 Post-Quantum Cryptography and NIST Standardization Quantum computers can use traditional asymmetric cryptographic algorithms such as RSA and Diffie- Hellman and Elliptic Curve Cryptography (ECC) can be theoretically broken via the Shor algorithm. This has been proven. In response to this threat, the US National Institute of Standards and Technology... (NIST), as a result of a standardization process initiated in 2016, aims to achieve three post-standardization goals by 2024. It has formally standardized the quantum algorithm: • FIPS 203 — ML-KEM (Module-Lattice Key-Encapsulation Mechanism): key encapsulation mechanism • FIPS 204 — ML-DSA (Module-Lattice Digital Signature Algorithm): digital signature algorithm (Three security levels: ML-DSA-44, ML-DSA-65, ML-DSA-87) • FIPS 205 — SLH-DSA (Stateless Hash-based DSA): a backup digital signature algorithm. At the ML-DSA-44 level, the public key size is approximately 1312 bytes and the signature size is approximately 2420 bytes. This is in bytes. For ML-DSA-65, these values ​​are 1952 and 3293 bytes respectively. For ML-DSA-87, they are 2592 and... It is 4595 bytes. These dimensions are different from the classic RSA-2048 or ECDSA-P256 signatures (72-256 bytes). 2 (in the range) is many times larger, and this situation makes it difficult to re-enable TLS handshake messages. This necessitates its design. 2.2 Lack of ML-DSA Support in Existing TLS Client Libraries As of the invention priority date, the following commonly used TLS client libraries are available in ML-DSA digital format. It does not support signature algorithms: • Go programming language crypto / TLS package: Go version 1.24 ML-KEM-768 (for key exchange) Although it includes hybrid X25519+Kyber768 support, ML-DSA is used for certificate validation. It does not support signatures. A Go client cannot provide an ML-DSA signed server certificate. When trying to handshake with a TLS server, it encounters an "unknown signature algorithm". You will receive a signature algorithm error and the connection cannot be established. • Google Chrome and Chromium derivatives: Current Chrome versions, including Cloudflare. preferring the developed Merkle Tree Certificates (MTC) approach However, it does not provide built-in support for ML-DSA signatures in traditional X.509 certificates. Google officially announced its MTC approach in February 2026; however, this is based on the current X.509. It is not compatible with the existing infrastructure. • Mozilla Firefox: Supports hybrid X25519+Kyber768 key exchange, but lacks ML-DSA. It does not support signed certificate verification. • Apple Safari / WebKit: No built-in support for ML-DSA has been announced. • Microsoft Windows Platform: Cryptography API Next Generation (CNG) library 2025 As of that year, it has made the ML-KEM and ML-DSA APIs generally available; however, this is not the application Developer-level support for browser and HTTP client libraries is included. It does not provide. 2.3 Server-Side PQC TLS Solutions The following open-source and commercial solutions can be used to enable post-quantum TLS on the server-side. Solutions are available: 1. Open Quantum Safe (OQS) project: liboqs library and its integration with BoringSSL and OpenSSL integrations (open-quantum-safe / boringssl, open-quantum-safe / oqs-provider). This derivative Forks and provider plugins enable PQC TLS handshake on the server side. (handshake) makes it possible, but a local proxy architecture on the client side. It does not offer. 3 2. OQS-nginx (container image openquantumsafe / nginx): A ready-made solution with OpenSSL3 and oqs-provider. Nginx is a software container. It runs on the server side and is used by the end-user client. It won't solve the problem. 3. Stunnel + oqs-provider: Stunnel, OpenSSL3, and oqs-provider are used together to provide TLS. Tunneling is possible. It is a monolithic installation; multi-layered backup. It does not contain fallback and does not rewrite HTML content. 4. AWS Private Certificate Authority: ML-DSA as of November 2025 It supports certificate production. This is a Certificate Authority (CA). It's a service that doesn't resolve the client's TLS connection issue. 5. DigiCert Private Certificate Authority (Private CA): Offers ML-DSA certificate support. Again, a It is a certificate authority service. 6. Cloudflare Post-Quantum Cryptography: Hybrid ML-KEM (key) by 2025 (code change) support has been offered, ML-DSA (authentication / certificate signature) support will be available by mid-2026. for edge-origin connections and for end-user connections in 2027. It is planned using the Merkle Tree Certificates approach. This is a content distribution network (Content A Delivery Network (CDN) is an edge solution; it is not a local client proxy. 2.4 Local Proxy Software Traditional local proxy software falls into the following categories: 1. Debugging / man-in-the-middle proxy servers (e.g., mitmproxy, Charles, Fiddler: These tools generate a self-signed CA certificate and allow the user to... It decodes all TLS traffic by being loaded onto its machine. However, it requires special post-quantum algorithms. There is no backup support or multi-layered backup mechanism. 2. Forward proxy servers (e.g., Squid, Privoxy): Process HTTP / HTTPS requests. It redirects; however, it aims to overcome the algorithmic shortcomings of the TLS client library. It does not contain a mechanism. 3. Reverse proxy servers (e.g., nginx, HAProxy, Envoy): In front of the server It is positioned; it is not a client-side solution. 4. SOCKS5 proxy servers: Provide TCP tunneling; however, require browser proxy server configuration. And the algorithm support of the client TLS library remains unchanged. 2.5 Previous Solutions Closest to This Invention 4 The closest technological solutions to this invention are (a) Cloudflare's edge-to-edge solutions planned for mid-2026. (a) edge-origin ML-DSA support, (b) OQS-nginx server container, and (c) stunnel+oqs- Although it is a provider tunnel, none of these: • It does not function as a local gateway on the client side; • Working on the lack of ML-DSA in the standard TLS client library (e.g., Go crypto / tls) It does not compensate in a timely manner through the sub-process; • It does not offer multi-layered (embedded sub-process → remote bridge → standard TLS) hierarchical backup; • A single-origin experience from a browser perspective through transparent rewriting of HTML and CSS content. does not provide; • Post-quantum within a single executable file (statically linked Go executable binary) TLS does not embed client capability. 3. THE TECHNICAL PROBLEM THAT THE INVENTION AIMS TO SOLVE. In light of the shortcomings of the solutions described above in the current state of the art, the present invention It aims to solve the following technical problems: TP-1: Does not directly support post-quantum digital signature algorithms (especially ML-DSA). information that uses a standard TLS client library (e.g., Go crypto / tls, browser TLS stack) in the processing environment, remote HTTP resources protected by ML-DSA signed server certificates Access is required. In current solutions, this requires a completely rewritten TLS. This requires either a client library or a specific browser version, both of which (a) It is unacceptable in terms of (b) deployment complexity, (c) maintenance burden, and (b) user experience. TP-2: Additional setup steps (external) in deploying post-quantum TLS capability to the end user. (uploading binary files, adding CAs to system certificate stores, configuring proxy settings) providing a ready-to-use solution through a single executable file without needing to It is a requirement. The existing OQS-BoringSSL and OQS-OpenSSL solutions are system-level. This requires library setup or containerization. TP-3: Post-quantum TLS client capability is unavailable at runtime. in situations (for example, restricted container environments where the embedded binary cannot be executed or (Situations with restricted permissions in Windows), the user can continue without experiencing service interruption. a backup mechanism that allows access to the target resource via an alternative path The problem is that it is not available. Known solutions do not include such an automatic hierarchical backup (fallback). There isn't; the user is dependent on a single solution. TP-4: In an HTML page accessed through a local gateway, the hyperlink on that page The links, uploaded image, stylesheet, and script resources are automatically sent to the gateway. It requires redirection. With standard proxy methods, the browser redirects the HTML within the browser. It attempts to link to absolute URLs, and as a result, sub-resources link directly to the original PQC. It tries to go to the server — which again leads to the TLS handshake error. Single-origin A content rewrite mechanism that ensures transparency is needed. TP-5: When a TLS handshake error occurs in current browsers, a browser extension to automatically redirect the page to the local gateway It is necessary to establish a mechanism that works in coordination between the extension and the local gateway. In current proxy solutions, there is no such connection between the browser extension and the local proxy. There is no automatic error detection and routing flow. TP-6: Local area gateway runtime status (running, stopped, connection failed, vs.) intuitively presents the end user with a system tray (menu bar) interface. presentation and also live information on which backup layer of the gateway was successful. The need is to provide visibility. Existing solutions lack this type of graphical management layer. There isn't any. 4. PURPOSE AND BRIEF DESCRIPTION OF THE INVENTION The primary purpose of the present invention is to provide the end user with a solution to the technical problems mentioned above. through a local gateway process running on the machine, post-quantum Despite being a standard TLS client library that does not support digital signature algorithms, ML- A system that provides transparent and automated access to remote server resources with DSA-signed certificates. The goal is to present systems and methods. The main elements of the invention are as follows: A) Asymmetric TLS Proxy Architecture: The local gateway has a simple connection with the client side. It uses HTTP (unencrypted, over a local circular interface — localhost); however, the target In its connection with the server, ML-DSA is used via an embedded post-quantum TLS client. It uses supported TLS. This asymmetry allows for any certificate store changes on the client machine. or does not require any browser settings changes. B) Three-Tier Hierarchical Backup Mechanism: The local gateway provides backup to the target server. It attempts to connect by trying three consecutive steps in a prioritized order: • Stage 1 (embedded sub-process): Statically linked (embedded) to the gateway executable binary. A post-quantum TLS client binary is extracted to a temporary directory at runtime, and a 6 It is run as a sub-process. The sub-process has standard input (stdin) and standard output (stdout) streams. It communicates with the main process via raw HTTP / 1.1 messages. • Stage 2 (remote bridge): If Stage 1 is unavailable or fails, the gateway will be pre-configured. It sends an HTTPS request to a configured remote bridge endpoint. The remote bridge then uses its own post- It connects to the target server using a quantum TLS client and transmits the result back. • Stage 3 (standard TLS): If the previous two stages fail, the standard TLS client will be used. (if the library cannot verify the ML-DSA signature but supports ML-KEM key exchange) (It may work with some servers) A direct connection is attempted. C) Statically Embedded Post-Quantum TLS Client Binary: Post-quantum TLS client binary (e.g., patched BoringSSL BSSL client tool), gateway assembly Go (or another language) can be executed in a timely manner via go:embed or a similar directive. It is statically linked to the binary file. On the first call of runtime, the binary file is temporarily linked. extracted to the file system location, granted executable permissions, and then executed as a sub-process on each subsequent request. This approach requires no additional installation step or external binary in the package distributed to the end user. It eliminates the need for a file. D) Path-Based Domain Name Routing: The local gateway routes incoming requests to / proxy / {domain} / {path} It accepts a uniform URL structure in this format. This structure is displayed in the browser's address bar as a local network URL. the gateway shows the origin (http: / / localhost:8443), therefore the browser status related to the page. information (cache, cookies, local storage) and security policies (Same Origin Its policy (inter-origin resource sharing) leads to it being stored at the local gateway origin. E) HTML and CSS Content Rewriting: HTML content retrieved from the target server is subject to a W3C It is processed with a compatible DOM parser (e.g., golang.org / x / net / html) and includes src, href, action, poster, data, All attributes containing URLs, such as srcset, are rewritten to the format / proxy / {domain} / {path}. srcset The multiple URL format (url1 1x, url2 2x) is correctly parsed for the attribute. Style <style> etiketi içi ve yüklenen CSS dosyaları içindeki url(...) çağrıları düzenli ifade tabanlı bir kural kümesiyle yeniden yazılır. Bu sayede yüklenen sayfanın tüm alt-kaynakları aynı yerel ağ geçidi orijini üzerinden servis edilir.F) Tarayıcı Uzantısı ile Koordineli Hata Kurtarma: Buluşun bir uygulamasında, bir tarayıcı uzantısı webNavigation.onErrorOccurred veya benzer bir hata yakalama uygulama programlama arayüzünü kullanarak tarayıcıda meydana gelen TLS el sıkışması hatalarını dinler. Bir PQC ile korunan alan adı için el sıkışması hatası tespit edildiğinde, uzantı tarayıcı sekmesini otomatik olarak yerel ağ geçidinin / proxy / {alan} / {yol} URL'sine yönlendirir. Bu sayede kullanıcı herhangi bir manuel eylem gerçekleştirmeden, PQC ile korunan siteye erişim sağlar.7G) Sistem Tepsisi Grafiksel Yönetim Arayüzü: Buluşun bir uygulamasında, yerel ağ geçidi işlemi bir sistem tepsisi (macOS menu bar, Windows system tray veya Linux indicator) simgesi aracılığıyla son kullanıcıya durum bilgisi (çalışıyor / durduruldu, port numarası, etkin alan adı listesi, gömülü alt-sürecin erişilebilirlik durumu) sunar ve başlat / durdur, dashboard açma, oturum açıldığında otomatik başlatma ve çıkış gibi eylemlere erişim sağlar.H) Dashboard ve Canlı Aktivite İzleme: Yerel ağ geçidi, kök ( / ) yolda gömülü bir HTML panel (dashboard) sunar. Bu panelde, her işlenmiş istek için, hangi yedekleme aşamasının başarılı olduğu (bssl-direct, bridge, go-direct) bir method etiketiyle canlı aktivite tablosunda gösterilir. Panel, / pqc-gateway / status ve / pqc-gateway / activity uç noktalarını JavaScript aracılığıyla düzenli aralıklarla yoklar.Buluşun ayrıntılı uygulama örnekleri Şekiller 1 ila 7'de gösterilmiş ve aşağıda "Buluşun Detaylı Açıklaması" bölümünde ayrıntılı olarak açıklanmıştır.5. ŞEKİLLERİN AÇIKLAMASIAşağıdaki şekiller buluşun tercih edilen uygulamalarını göstermek amacıyla verilmiştir ve buluşun kapsamını sınırlamaz.Şekil 1: Buluşun bir uygulamasına göre, post-kuantum kriptografi destekli yerel ağ geçidi sisteminin (100) genel bileşen mimarisini gösteren blok diyagramı. İstemci makinesi (10), tarayıcı (20), tarayıcı uzantısı (30), uzak köprü sunucusu (40), hedef sunucu (50), yerel ağ geçidi işlemi (100), HTTP sunucu modülü (110), alan adı izin listesi yöneticisi (120), üç-katmanlı çağrı düzenleyicisi (130), içerik yeniden yazma modülü (140), gömülü bssl alt-süreç istemcisi (150), uzak köprü HTTP istemcisi (160) ve standart TLS istemcisi (170) bileşenlerinin birbirleriyle olan ilişkilerini gösterir.Şekil 2: Üç-katmanlı hiyerarşik yedekleme mekanizmasının karar akışını gösteren akış diyagramı. 210 numaralı adımda bir HTTP isteği alınır; 212 numaralı adımda söz konusu istekten hedef alan adı ve yol bileşeni çıkarılır. 220 numaralı aşamada, gömülü bir post-kuantum TLS istemcisi bir alt-süreç olarak çalıştırılır; bu aşama başarılı olursa 280 numaralı içerik yeniden yazma adımına geçilir. Birinci aşama başarısız veya kullanılamaz olduğunda, 240 numaralı aşamada bir uzak köprü uç noktasına HTTP çağrısı yapılır. İkinci aşama da başarısız veya yapılandırılmamış olduğunda, 260 numaralı aşamada standart bir TLS istemcisi ile doğrudan bağlantı denenir. Herhangi bir aşamanın başarılı olması durumunda alınan yanıt 280 numaralı adımda içerik yeniden yazma modülünden geçirilir ve 284 numaralı adımda istemci uygulamaya iletilir. Tüm aşamaların başarısız olması durumunda, 290 numaralı adımda istemci uygulamaya hata yanıtı iletilir.8Şekil 3: Gömülü post-kuantum TLS istemci ikili dosyasının çalışma zamanında bir alt-süreç olarak çağrılması dizi diyagramıdır. İlk çalıştırma sırasında, 320 numaralı adımda işletim sisteminden geçici bir dizin oluşturulması talep edilir; 322 numaralı adımda ikili dosya yürütülebilir izinlerle söz konusu dizine yazılır; 324 numaralı adımda dosya yolu alt-süreç sarmalayıcısında saklanır. Sonraki her istek için, 330 numaralı adımda alt-süreç başlatılır; 332 numaralı adımda alt-sürecin standart giriş akışına ham bir HTTP istek mesajı yazılır; 334 numaralı adımda alt-süreç çalıştırılır; 340 numaralı adımda alt-sürecin standart çıkış akışından ham HTTP yanıtı alınır; 342 numaralı adımda ayrıştırılmış yanıt çağrı düzenleyicisine döndürülür.Şekil 4: Yol tabanlı URL yönlendirme ve içerik yeniden yazma akışını gösteren akış diyagramı. 410 numaralı adımda yapılandırılmış bir URL biçiminde bir istek alınır; 412 numaralı adımda söz konusu URL'den alan adı ve yol bileşeni ayrıştırılır. Alınan içerik 422 numaralı adımda bir Belge Nesne Modeli (DOM) ağacına ayrıştırılır. 430 numaralı adımda URL içeren öznitelikler bir yeniden yazma kural kümesine göre dönüştürülür. 440 numaralı adımda stil içeriğindeki URL çağrıları ayrı bir kural kümesi ile dönüştürülür. 450 numaralı adımda dönüştürülmüş içerik istemci uygulamaya iletilir.Şekil 5: Yerel ağ geçidi işleminin yaşam döngüsü durum diyagramı. Durumlar: Oluşturuldu (510), Bağlanıyor (520), Çalışıyor (530), Durduruluyor (540) ve Durduruldu (550). Geçişler iş parçacığı güvenli bir durum değişkeni üzerinden koordine edilir.Şekil 6: Tarayıcı uzantısı ile yerel ağ geçidi arasındaki koordineli hata kurtarma dizi diyagramı. 610 numaralı adımda tarayıcı doğrudan hedef sunucuya bir HTTPS isteği yapar. 620 numaralı adımda post-kuantum TLS el sıkışması, tarayıcının TLS istemci kütüphanesinde post-kuantum imza algoritması desteği bulunmadığı için başarısız olur. 630 numaralı adımda uzantı söz konusu el sıkışması hatasını bir hata yakalama arayüzü üzerinden yakalar. 640 numaralı adımda uzantı, söz konusu sekmeyi yerel ağ geçidinin yapılandırılmış URL biçimine yeniden yönlendirir. 650 numaralı adımda yerel ağ geçidinden dönen yanıt tarayıcıya iletilir.Şekil 7: Çok platformlu dağıtım için kullanılan derleme hattı akış diyagramı. 710 numaralı adımda bir post-kuantum TLS istemci ikili dosyası bir uzak derleme ortamında derlenir. 720 numaralı adımda söz konusu ikili dosya, hedef platformlara göre yerel bir derleme ortamına paketlenir. 730 numaralı adımda ikili dosya ağ geçidi kaynak kodunun gömme konumuna kopyalanır. 740 numaralı adımda ağ geçidi derleyicisi söz konusu ikili dosyayı statik olarak bağlar. 750 numaralı adımda tek bir yürütülebilir ikili dosya çıktısı oluşur. 760 numaralı adımda, isteğe bağlı olarak, grafiksel kullanıcı arayüzü içeren bir uygulama paketi hazırlanır.96. BULUŞUN DETAYLI AÇIKLAMASIAşağıdaki açıklama, buluşun tercih edilen uygulamalarını ayrıntılı olarak sunar. Bu açıklamalar örnek niteliğinde olup, buluşun kapsamı istemlerde tanımlanan şekilde yorumlanmalıdır. "Bir uygulamada", "tercihen" ve "alternatif olarak" gibi ifadeler, açıklanan unsurun zorunlu olmadığını, buluşun başka uygulamalarının da mümkün olduğunu gösterir.6.1 Genel Sistem Mimarisi (Şekil 1)Şekil 1'de gösterildiği gibi, buluşun bir uygulamasına göre bir post-kuantum kriptografi destekli yerel ağ geçidi sistemi (100), bir istemci makinesi (10) üzerinde bir bilgisayar süreci (process) olarak çalışır. İstemci makinesi (10), bir veya daha fazla tarayıcı (20) uygulamasını ve isteğe bağlı olarak bir tarayıcı uzantısını (30) içerir. Yerel ağ geçidi sistemi (100), bir HTTP sunucu modülü (110), bir alan adı izin listesi yöneticisi (120), bir üç-katmanlı çağrı düzenleyicisi (130), bir içerik yeniden yazma modülü (140), bir gömülü bssl alt-süreç istemcisi (150), bir uzak köprü HTTP istemcisi (160) ve bir standart TLS istemcisi (170) içerir.Bir uygulamada, yerel ağ geçidi sistemi (100) bir kullanıcı makinesinde yerel döngüsel arayüz (loopback interface) üzerinden, tercihen port 8443 olmak üzere bir TCP portunda dinleme yapar. İstemci makinesindeki tarayıcı (20), yerel ağ geçidine http: / / localhost:8443 / proxy / {alan} / {yol} biçimindeki URL'ler üzerinden HTTP istekleri gönderir. Yerel ağ geçidi bu istekleri alır, alan adı izin listesi yöneticisi (120) aracılığıyla hedef alan adının izinli olup olmadığını doğrular ve üç-katmanlı çağrı düzenleyicisi (130) aracılığıyla aşağıda 6.3 ve 6.4'te ayrıntılı olarak açıklanan yedekleme mekanizmasını çalıştırır.Uzak köprü sunucusu (40), buluşun bir uygulamasında, ağ geçidinin yerel olarak bir post-kuantum TLS istemci alt-sürecini çalıştıramadığı durumlar için bir yedekleme mekanizması olarak konumlanır. Uzak köprü sunucusu (40), kendi ortamında bir post-kuantum TLS istemcisini (örneğin bir Python betiği ile düzenlenen bir bssl istemci aracını) çalıştırır ve yerel ağ geçidinden gelen HTTPS isteklerini alarak hedef sunucuya (50) post-kuantum TLS üzerinden iletir. Uzak köprü sunucusunun konumu, yapılandırma dosyası veya komut satırı bayrakları aracılığıyla her alan adı için ayrı olarak tanımlanabilir.Hedef sunucu (50), ML-DSA dijital imzalı bir sertifika sunan ve Aktarım Katmanı Güvenliği (TLS) 1.3 veya sonraki sürümlerde çalışan bir HTTPS sunucusudur. Bir uygulamada, hedef sunucu yamalanmış BoringSSL üzerine inşa edilmiş bir HTTPS sunucu gerçeklemesi (örneğin bssl_https_server_pqc aracı) çalıştırır.6.2 HTTP Sunucu Modülü (110) ve İstek YönlendirmeHTTP sunucu modülü (110), standart kütüphanede bulunan bir HTTP sunucu sınıfını (Go dilinde net / http paketinin http.Server tipi) temel alır. Buluşun bir uygulamasında, sunucu başlatıldığında dört ana uç nokta kayıt edilir:• GET / pqc-gateway / status: Sistemin çalışma durumunu ve yeteneklerini bildiren bir JSON yanıtı döner. Yanıtın içeriği en az bir versiyon belirteci, dinleme portu, etkin alan adı listesi ve gömülü post-kuantum TLS istemcisinin erişilebilirlik durumunu içerir.• GET / pqc-gateway / activity: Son N (tercihen 50) işlenmiş istek için bir aktivite günlüğünü JSON dizisi olarak döner. Her girdinin en az bir zaman damgası, alan adı, yol, başarılı olan yedekleme aşamasının etiketi (bssl-direct, bridge veya go-direct) ve HTTP durum kodunu içerir.• GET / proxy / ...: Yukarıda açıklanan yol-tabanlı alan adı yönlendirme uç noktasıdır. Bu uç nokta, alt bölüm 6.4'te anlatılan üç-katmanlı yedekleme mekanizmasını çalıştırır.• GET / : Gömülü bir HTML gösterge panelini (dashboard) döner. Gösterge paneli, yukarıdaki iki JSON uç noktasını düzenli aralıklarla (tercihen 2 saniye) JavaScript aracılığıyla yoklayarak canlı bir durum gösterimi sağlar.HTTP sunucu modülü, istekleri işlemeden önce sırasıyla şu ara katmanları (middleware) uygular:1. Kökenler arası kaynak paylaşımı (CORS) ara katmanı: Access-Control-Allow-Origin: * ve Access-Control-Allow-Methods: GET, OPTIONS başlıklarını yanıta ekler. Bu, tarayıcı uzantılarından veya başka tarayıcılardan yapılabilecek kökenler arası (cross-origin) isteklerin kabul edilmesini sağlar.2. Hız sınırlama ara katmanı: Tercihen jeton-kovası (token-bucket) veya kayan-pencere (sliding-window) algoritmasıyla ağ protokolü adresi (IP) başına istek hızını sınırlar. Varsayılan olarak yerel döngüsel arayüz istekleri için 1000 istek / dakika.3. Günlükleme ara katmanı: İstekleri yapılandırma bayrakları doğrultusunda belirlenen günlükleme ayrıntı seviyesinde (ayrıntılı veya sessiz) günlüğe kaydeder.Sunucu başlatma akışı aşağıdaki sırayla çalışır:Sunucu durdurma akışı (Şekil 5, durum geçişi 540 → 550):Atomik (atomic) bir mantıksal durum değişkeni kullanımı, birden fazla istemcinin (örneğin sistem tepsisi menüsü ile yönetilen bir uygulama ve aynı anda çalışan bir test betiği) yarış durumuna girmesini engeller. Sonuç olarak aynı ağ geçidi işlemi birden fazla kere başlatılamaz veya durdurulamaz.116.3 Yol-Tabanlı Alan Adı Yönlendirme ve İzin Listesi KontrolüYerel ağ geçidine gelen her / proxy / ... isteği, aşağıdaki adımlarla işlenir:Adım 1 — Önek ayrıştırma (Şekil 4, adım 412): HTTP isteğinin yolu (örn. / proxy / demo.pqcnow.com / auth / login) alınır. İstek yolundan / proxy / öneki (prefix) çıkarılır ve kalan kısım eğik çizgi ayracıyla en fazla iki parçaya bölünür. İlk parça alan adı olarak kabul edilir (demo.pqcnow.com), ikinci parça (varsa) hedef yol olarak yorumlanır ( / auth / login). İkinci parça boşsa veya eksikse, varsayılan olarak kök yol ( / ) kullanılır.Adım 2 — Alan adı izin listesi kontrolü (Şekil 4, Allow? karar noktası): Alan adı izin listesi yöneticisi (120), ağ geçidinin yapılandırmasındaki izinli alan adları kümesiyle çıkarılan alan adını karşılaştırır. İzin listesi iki kaynaktan beslenebilir: (a) komut satırı bayrağı --domains ile virgül ayracıyla belirtilen liste, (b) JSON yapılandırma dosyası içindeki allowedDomains alanı. Eşleşme bulunmazsa, istemciye HTTP 403 (erişim yasak) yanıtı döndürülür ve işlem sonlanır.Adım 3 — Sorgu dizesi korunumu: Orijinal HTTP isteğindeki sorgu dizesi (query string) ayrıştırılmış yolla birleştirilerek hedef istek URL'sinin oluşturulması için saklanır.Adım 4 — HTTP başlık yönlendirme: Tarayıcıdan gelen HTTP başlıkları arasından güvenlik açısından hassas olmayanlar (örn. Accept, Accept-Language, User-Agent) yeniden iletilmek üzere kopyalanır. Başlıklardan Host, Connection ve Proxy-* başlıkları çıkarılır.Adım 5 — Üç-katmanlı çağrı düzenleyicisine iletme: Hazırlanan alan adı, yol, sorgu dizesi ve iletilecek başlıklar, üç-katmanlı çağrı düzenleyicisine (130) iletilir.Buluşun bir uygulamasında, yol-tabanlı URL yapısının avantajı şudur: tarayıcı adres çubuğunda http: / / localhost:8443 / proxy / demo.pqcnow.com / auth / login gösterir ve bu URL'nin yerel döngüsel arayüz üzerindeki orijini http: / / localhost:8443'tür. Aynı sayfadan yüklenen tüm alt-kaynaklar (stil sayfaları, betikler, resimler) — bu alt-kaynaklar HTML içerik yeniden yazma modülü (140) aracılığıyla yeniden yazıldığı için — aynı http: / / localhost:8443 orijini üzerinden sunulur. Bu sayede tarayıcının tek-orijin politikası (Same-Origin Policy — Aynı Köken Politikası), çerez yönetimi ve yerel depolama (localStorage, sessionStorage) mekanizmaları yerel ağ geçidi orijinine bağlı kalır.6.4 Üç-Katmanlı Hiyerarşik Yedekleme Mekanizması (Şekil 2)Üç-katmanlı çağrı düzenleyicisi (130), aşağıdaki ardışık aşamaları önceliklendirilmiş sırayla dener. Her aşamanın başarısı durumunda sonraki aşamalar atlanır.6.4.1 Aşama 1 — Gömülü Alt-Süreç (bssl-direct)12Girdi: alan adı, port (varsayılan 443), yol, sorgu dizesi, iletilecek başlıklar.Koşul: Gömülü bssl alt-süreç istemcisi (150) erişilebilir durumdadır. Erişilebilirlik, ikili dosyanın başarıyla çıkarılmış ve yürütme izninin verilmiş olması anlamına gelir (bkz. 6.5).İşlem: 1. Gömülü bssl alt-süreç istemcisinin istek gönderme yöntemi (Do() metodu) çağrılır. 2. İstemci, bir bayt tamponu (bytes.Buffer) içinde ham bir HTTP / 1.1 GET isteği oluşturur:3. exec.CommandContext(ctx, bsslPath, "client", "-connect", "demo.pqcnow.com:443") komutu bir bağlam zaman aşımıyla (tercihen 30 saniye) yapılandırılır. 4. Alt-sürecin standart girişi yukarıdaki tampon bellek olarak ayarlanır. 5. Alt-sürecin standart çıkışı ve standart hatası birer tampon belleğe yönlendirilir. 6. cmd.Run() çağrısıyla alt-süreç çalıştırılır. BoringSSL bssl client aracı, normal bitirme durumunda bile sıfır-olmayan çıkış kodu ile sonlanabilir (çünkü Connection: close ile sunucu bağlantıyı kapatır). Bu nedenle çıkış kodu yoksayılır ve yalnızca standart çıkışın dolu olup olmadığına bakılır. 7. Standart çıkışın içeriği bir bufio.Reader üzerinden http.ReadResponse() fonksiyonuna verilir ve ham HTTP yanıtı ayrıştırılır. 8. Ayrıştırılan http.Response nesnesi çağrana döndürülür.Başarı: Ayrıştırma başarılıysa, yanıt method=bssl-direct etiketiyle aktivite günlüğüne kaydedilir ve işlem biter.Başarısızlık: Alt-süreç çalıştırılamazsa, yanıt ayrıştırılamazsa veya standart çıkış boşsa, çağrı düzenleyicisi Aşama 2'ye geçer.6.4.2 Aşama 2 — Uzak Köprü (bridge)Koşul: Yapılandırmada bu alan adı için bir uzak köprü URL'si tanımlanmıştır. Yapılandırma, komut satırı bayrağı --bridges alan=köprü-URL,alan=köprü-URL şeklinde veya JSON yapılandırma dosyasının bridgeURLs alanı üzerinden alınır.İşlem: 1. Yapılandırmadan köprü URL'si alınır (örn. https: / / bridge.example.com / pqc-bridge). 2. Hedef URL oluşturulur: https: / / bridge.example.com / pqc-bridge / {yol}?{sorgu}. 3. http.NewRequestWithContext(ctx, "GET", hedefURL, nil) ile bir yeni istek oluşturulur. 4. Orijinal istekten iletilecek başlıklar kopyalanır. 5. Standart Go TLS istemcisi (http.DefaultTransport veya özel yapılandırılmış bir http.Client) kullanılarak köprü sunucusuna bağlantı kurulur. 6. Uzak köprü sunucusu (40), kendi tarafında bir post-kuantum TLS istemcisini (örn. Python script ile orkestre edilmiş bssl client aracı) kullanarak hedef sunucuya (50) bağlanır ve gelen isteği iletir. 7. Yanıt köprüden geri alınır.Başarı: Yanıt alınırsa method=bridge etiketiyle kaydedilir.13Başarısızlık: HTTP hatası (5xx), zaman aşımı veya köprü erişilemezlik durumunda Aşama 3'e geçilir.6.4.3 Aşama 3 — Standart TLS (go-direct)Koşul: Her zaman çalıştırılabilir; son aşama olarak konumlanmıştır.İşlem: 1. Hedef URL oluşturulur: https: / / {alan} / {yol}?{sorgu}. 2. Standart TLS istemcisi (170) ile doğrudan bağlantı denenir. 3. Standart TLS istemcisi ML-DSA imzalı sertifikayı doğrulayamaz ve TLS el sıkışması (handshake) başarısız olur; ancak hedef sunucu klasik (RSA / ECDSA) imzalı bir alternatif sertifika sunuyorsa veya istemcinin desteklediği şifreleme paketleriyle (cipher suite) uyumluysa bağlantı kurulabilir.Başarı: Yanıt alınırsa method=go-direct etiketiyle kaydedilir. Bu durum, hedef sunucunun ML-DSA imzalı sertifikalı olmadığını veya istemcinin klasik yedek sertifikayla çalışabildiğini gösterir.Tüm aşamaların başarısızlığı: Tüm üç aşama başarısızsa, istemciye HTTP 502 (hatalı ağ geçidi) yanıtı döndürülür ve aktivite günlüğüne başarısızlık kaydı yazılır.6.5 Gömülü Post-Kuantum TLS İstemci İkili Dosyası (150) (Şekil 3)Gömülü bssl alt-süreç istemcisi (150), aşağıdaki adımlarla derleme zamanında ağ geçidi yürütülebilir ikili dosyasına bağlanır ve çalışma zamanında alt-süreç olarak çağrılır.6.5.1 Derleme Zamanı Gömme (Şekil 3, adım 310)Ağ geçidi derlenirken, post-kuantum TLS istemcisinin ikili dosyası (örn. yamalanmış BoringSSL'nin bssl aracı) Go programlama dilinin go:embed direktifi veya başka bir dilin eşdeğeri (Rust'ın include_bytes! makrosu, Python'un importlib.resources, vs.) aracılığıyla ağ geçidi kaynak koduna statik olarak dahil edilir.Go dilinde tipik bir kullanım:Alternatif olarak, gömmenin istenmediği durumlar (örneğin bir geliştirme ortamında veya sistem bssl'sinin kullanıldığı ortamlarda) için bir taslak (stub) derleme birimi de sağlanır:Böylece go build -tags embed_bssl komutu ile gömülü versiyon, bayrak olmadan derleme ile ise boş versiyon seçilir.Derleme sırasında, platform-başına ayrı bir bssl ikili dosyası kullanılır. Bir tercih edilen uygulamada, her desteklenen platform için (darwin / amd64, darwin / arm64, linux / amd64, linux / arm64, windows / amd64) önceden derlenmiş bir bssl ikili dosyası bssl-bin / {os} / {arch} / bssl 14dizin yapısında saklanır. Derleme betiği (bkz. Şekil 7 ve alt bölüm 6.9), her platform için uygun ikili dosyayı cmd / app / bssl veya cmd / cli / bssl konumuna kopyalar ve ardından go build çalıştırılır. Bu sayede her platform için bağımsız bir statik bağlı yürütülebilir ikili dosya üretilir.6.5.2 Çalışma Zamanı Çıkarma (Şekil 3, adımlar 320-324)İstemci ilk başlatıldığında, aşağıdaki mantık izlenir:Öncelik 1 — Açık bayrak: Kullanıcı --bssl-path / path / to / bssl komut satırı bayrağı ile sistem üzerindeki bir bssl konumunu belirtmişse, bu yol doğrudan kullanılır.Öncelik 2 — Sistem PATH: Bayrak belirtilmemişse, işletim sistemi PATH değişkeni içindeki bssl ikili dosyası aranır. Bulunursa, yol kullanılır.Öncelik 3 — Gömülü ikili: Yukarıdaki ikisi bulunamazsa, derleme zamanında gömülmüş embeddedBSSL bayt dizisi kullanılır. Eğer len(embeddedBSSL) > 0 ise, aşağıdaki adımlarla çıkarma yapılır:Öncelik 4 — Erişilemez: Yukarıdakilerin hiçbiri başarılı değilse, istemci nesnesi available=false durumunda oluşturulur ve Aşama 1 çağrıları atlanır.6.5.3 Alt-Süreç İletişimi (Şekil 3, adımlar 330-342)Her HTTP isteği için, istemci aşağıdaki adımlarla alt-süreç çalıştırır:6.5.4 Kapanış ve Temizleme (Şekil 3, adım 360)Ağ geçidi Stop() çağrısı aldığında, bsslClient.cleanup() metodu çağrılır ve bu metod çalışma zamanında oluşturulan geçici dizini (tempDir) os.RemoveAll() ile kaldırır. Böylece çıkarılan ikili dosya diskte kalmaz.6.6 İçerik Yeniden Yazma Modülü (140) (Şekil 4)Hedef sunucudan alınan HTTP yanıtı, yanıt gövdesi HTML veya CSS türünde ise, içerik yeniden yazma modülüne (140) iletilir. Modül, aşağıdaki adımlarla içeriği dönüştürür.6.6.1 HTML DOM Ayrıştırma (Şekil 4, adım 422)Yanıt gövdesi, W3C uyumlu bir HTML ayrıştırıcısı (örneğin Go dilinde golang.org / x / net / html paketi) aracılığıyla bir Belge Nesne Modeli (Document Object Model — DOM) ağacına dönüştürülür. Bu yaklaşım, düz metin veya düzenli ifade (regular expression) tabanlı dönüştürmenin aksine, HTML yapısını doğru şekilde anlamlandırır ve <script> içindeki karakter dizileri gibi yanlış eşleşmeleri önler.6.6.2 Öznitelik Yeniden Yazma Kuralları (Şekil 4, adımlar 430-436)DOM ağacı yürütülür ve her düğüm için, düğümün etiket adı (tag name) ve öznitelikleri kontrol edilir. Aşağıdaki öznitelikler "yeniden yazılacak" olarak işaretlenir:• src (örn. , <script src="...">, <iframe src="...">)• href (örn. , <link href="...">)• action (örn. <form action="...">)• poster (örn. <video poster="...">)• data (örn. <object data="...">)• srcset (örn. )Diğer öznitelikler değişmeden kalır.srcset özniteliği için özel bir ayrıştırma mantığı kullanılır. Değer virgülle ayrılır; her parça için URL kısmı ve tanımlayıcı kısmı (örn. 1x, 2x, 320w) ayrılır. URL kısmı yeniden yazılır, tanımlayıcı değişmeden kalır ve sonuç yeniden birleştirilir.6.6.3 URL Yeniden Yazma KurallarıHer bir URL, aşağıdaki kategorilere göre yeniden yazılır:Giriş Kategorisi Örnek ÇıkışMutlak aynı-alan adı https: / / demo.pqcnow.com / img.png / proxy / demo.pqcnow.com / img.pngMutlak dış alan adı https: / / other.com / x (değiştirilmez)Protokol-göreli / / demo.pqcnow.com / x / proxy / demo.pqcnow.com / xKök-göreli / img.png / proxy / demo.pqcnow.com / img.pngGöreli sub / img.png / proxy / demo.pqcnow.com / sub / img.pngVeri (data:) şeması data:image / png;base64,... (değiştirilmez)JavaScript şeması javascript:void(0) (değiştirilmez)Yalnızca sayfa-içi çapa #section (değiştirilmez)E-posta (mailto:) şeması mailto:... (değiştirilmez)Mutlak aynı-alan adı kontrolü, URL'nin şemadan sonraki ana bilgisayar (host) kısmının, orijinal hedef alan adıyla eşleşip eşleşmediğine bakılarak yapılır.6.6.4 CSS İçerik Yeniden Yazma (Şekil 4, adım 440)16CSS içeriği iki durumda karşımıza çıkar: (a) HTML içindeki satır-içi (inline) <style> etiketleri, (b) ayrı CSS dosyaları. Her iki durumda da, CSS içindeki url(...) çağrıları bir düzenli ifade (regular expression) aracılığıyla yeniden yazılır.Düzenli ifade:Bu ifade, url(...) çağrıları içindeki URL'leri yakalar. Çift tırnak, tek tırnak veya tırnaksız varyantları destekler. Her eşleşme için, yakalanan URL yukarıdaki URL yeniden yazma kuralları tablosuna göre dönüştürülür ve geri değiştirilir.Bu yaklaşım bilerek düz-metin tabanlıdır çünkü CSS soyut sözdizim ağacı (Abstract Syntax Tree — AST) ayrıştırma yükü, yeniden yazma amacı için gereksiz karmaşıklık yaratır.6.6.5 Yeniden Birleştirme ve Yanıt (Şekil 4, adım 450)DOM ağacı tüm dönüşümlerden sonra HTML metni olarak yeniden serileştirilir (html.Render()) ve tarayıcıya HTTP yanıt gövdesi olarak iletilir. HTTP başlıkları (özellikle Content-Type, Content-Length) güncellenir.6.7 Tarayıcı Uzantısı ile Koordineli Hata Kurtarma (Şekil 6)Buluşun bir uygulamasında, bir tarayıcı uzantısı (30), tarayıcının (20) TLS el sıkışması (handshake) hatalarını otomatik olarak yakalayıp yerel ağ geçidine yönlendirir. Uzantı, manifest sürüm 3 (veya daha eski sürüm 2) standardını kullanan bir arka plan hizmet betiği (background service worker) içerir.6.7.1 Hata YakalamaBetik, Chromium tabanlı tarayıcılarda (chrome.webNavigation.onErrorOccurred) veya Firefox'ta (browser.webNavigation.onErrorOccurred) hata yakalama dinleyicisini kaydeder. Bu uygulama programlama arayüzü (API), bir sayfa yüklenmesi sırasında oluşan gezinme (navigation) hatalarını yakalar ve hata kodunu, URL'yi, sekme kimliğini ve çerçeve (frame) bağlamını bildirir.6.7.2 PQC Alan Adı EşleştirmeBetik, uzantı yapılandırmasındaki "bilinen PQC alan adları" listesini bellekte tutar. Bir gezinme hatası alındığında:1. Hata kodunun TLS / SSL el sıkışması ailesi olup olmadığı kontrol edilir (örneğin net::ERR_SSL_PROTOCOL_ERROR, net::ERR_SSL_VERSION_OR_CIPHER_MISMATCH). 2. Gezinme URL'sinin ana bilgisayar 17(host) adı çıkarılır. 3. Bu ana bilgisayar adının PQC alan adı listesinde olup olmadığı kontrol edilir.Her iki koşul da sağlanırsa, uzantı chrome.tabs.update() çağrısıyla sekmeyi yerel ağ geçidi URL'sine yönlendirir:6.7.3 Alternatif UygulamalarBuluşun bir alternatif uygulamasında, tarayıcı uzantısı yerine doğrudan tarayıcının vekil sunucu ayarları, bir vekil sunucu otomatik yapılandırma betiği (Proxy Auto-Configuration — PAC) aracılığıyla yapılandırılır. Söz konusu betik, belirli alan adlarını yerel ağ geçidine yönlendirir. Bu yaklaşım, tarayıcı uzantısı kurulamamasının söz konusu olduğu kısıtlı ortamlarda (örn. kurumsal tarayıcı kısıtlamaları) kullanılabilir.Bir başka alternatif uygulamada, kullanıcı tarayıcı adres çubuğuna manuel olarak http: / / localhost:8443 / proxy / {alan} / {yol} yazarak yerel ağ geçidini doğrudan kullanır. Bu, otomasyon olmadan bir hatırlatma gerektirir ancak hiçbir uzantı kurulumuna ihtiyaç duymaz.6.8 Sistem Tepsisi Grafiksel Yönetim ArayüzüBuluşun bir uygulamasında, yerel ağ geçidi işlemi bir sistem tepsisi (macOS'ta menü çubuğu, Windows'ta sistem tepsisi, Linux'ta gösterge) simgesi aracılığıyla son kullanıcıya durum bilgisi ve kontrol eylemleri sunar. Bu uygulama, Go dilinde fyne.io / systray gibi bir çok platformlu sistem tepsisi kütüphanesi kullanılarak gerçekleştirilir.Sistem tepsisi menüsü aşağıdaki öğeleri içerir:• Durum (etkin değil, sadece bilgilendirme): "PQC Gateway: Çalışıyor (port 8443)" veya "PQC Gateway: Durduruldu".• Başlat / Durdur: Tıklandığında ağ geçidi çalışıyorsa durdurma yöntemi, çalışmıyorsa başlatma yöntemi çağrılır ve simge ile durum metni güncellenir.• Gösterge Panelini Aç: Tıklandığında http: / / localhost:8443 / URL'si varsayılan tarayıcıda açılır.• bssl Durumu (etkin değil, sadece bilgilendirme): Gömülü post-kuantum TLS istemcisinin kullanılabilir olup olmadığı gösterilir (ör. "bssl: erişilebilir" veya "bssl: erişilemez").• Alan Adları Listesi (etkin değil, sadece bilgilendirme): İzin listesindeki her alan adı ayrı bir menü öğesi olarak gösterilir.• Oturum Açıldığında Otomatik Başlat (işaret kutusu): İşaretli olduğunda, işletim sistemine özgü bir otomatik başlatma mekanizması (macOS için bir başlatma aracı yapılandırma dosyası, Linux 18için bir kullanıcı seviyesi sistem hizmeti, Windows için bir görev zamanlayıcı girdisi) kurulur veya kaldırılır.• Çık: Ağ geçidini durdurur ve süreci sonlandırır.macOS'ta, buluşun bir uygulamasında, .app uygulama paketinin Info.plist dosyasında LSUIElement=true ayarı kullanılarak uygulama görev çubuğunda (Dock) görünmez hale getirilir ve yalnızca menü çubuğunda simge olarak kalır. Bu, kullanıcının görev çubuğunu temiz tutar ve yerel ağ geçidini bir arka plan yardımcı programı olarak konumlandırır.Sistem tepsisi menüsünden başlatılan ağ geçidi, komut satırı arayüzü (CLI) üzerinden başlatılan ağ geçidi ile aynı sunucu sınıfını (Server) ve aynı yapılandırma modelini paylaşır. Bu sayede komut satırı arayüzü ve menü çubuğu uygulaması tek bir kod tabanından yönetilir ve farklı sürümler arasında davranış tutarlılığı sağlanır.6.9 Çok Platformlu Derleme ve Paketleme (Şekil 7)Buluşun bir uygulamasında, ağ geçidi birden fazla işletim sistemi ve mimari için aşağıdaki şekilde derlenir:6.9.1 Uzak bssl Derleme (Şekil 7, adım 710): Post-kuantum TLS istemcisinin ikili dosyası (bssl), bir uzak derleme sunucusunda (yamalanmış BoringSSL kaynak ağacı ile donatılmış) derlenir. Derleme komutu:Sonuç olarak statik bağlı, taşınabilir bir bssl ikili dosyası üretilir. Bu dosya, SCP veya benzer bir dosya aktarım protokolü aracılığıyla yerel derleme ortamına bssl-bin / {os} / {arch} / bssl dizin yapısında kopyalanır.6.9.2 Yerel Go Derlemesi (Şekil 7, adımlar 720-750):build.sh betiği, desteklenen her platform için aşağıdaki döngüyü çalıştırır:CGO_ENABLED=0 bayrağı, Go derleyicisinin saf Go dilinde, C diline bağlanmadan statik bir yürütülebilir ikili dosya üretmesini sağlar — bu sayede çapraz derleme (cross-compile) tek bir derleme makinesinden yapılabilir ve hedef sistemde C standart kütüphanesi (libc) uyumluluğu sorunu yaşanmaz.6.9.3 macOS Uygulama Paketi (.app) Oluşturma (Şekil 7, adım 760):macOS için build-app.sh betiği, CGO_ENABLED=1 (sistem tepsisi için Cocoa çatısı gerektiğinden) ile derler ve bir .app uygulama paketi oluşturur:Bu süreç, son kullanıcıya tek bir tıklanabilir .app uygulama paketi sunar. Kullanıcının bssl veya başka bir bağımlılık yüklemesine gerek yoktur.196.10 Yapılandırma YönetimiYapılandırma, aşağıdaki öncelikli sırayla yüklenir:1. Komut satırı bayrakları: En yüksek öncelik. Örnekler: --port 8443, --domains d1.com,d2.com, --bridges d1.com=https: / / bridge.com, --bssl-path / usr / bin / bssl, --verbose.2. JSON yapılandırma dosyası: Komut satırı bayrakları belirtilmemiş alanlar için kullanılır. macOS'ta ~ / Library / Application Support / PQC Gateway / config.json, Linux'ta ~ / .config / pqc-gateway / config.json, Windows'ta %APPDATA%\PQC Gateway\config.json.3. Varsayılan değerler: DefaultConfig() fonksiyonu aracılığıyla sağlanır. Varsayılan port 8443, varsayılan alan adı listesi ["demo.pqcnow.com"].Yapılandırma dosyası JSON yapısı:SaveToFile() fonksiyonu, yapılandırmayı okunabilir girintili JSON olarak kaydeder. LoadFromFile() fonksiyonu dosyayı okuyup bir yapılandırma nesnesine (Config) dönüştürür.6.11 Dashboard ve Aktivite İzlemeAğ geçidinin kök URL'si ( / ) gömülü bir HTML gösterge paneli (dashboard) döner. Panel aşağıdaki bölümleri içerir:1. Durum başlığı: Ağ geçidinin çalışma durumunu, portunu ve sürümünü gösterir. 2. Yetenek listesi: Desteklenen özellikler (ml-kem-768, tls1.3, proxy, bssl-direct vs.). 3. İzin verilen alan adları listesi: Yapılandırmadaki tüm alan adları. 4. Canlı aktivite tablosu: Son N (varsayılan 50) işlenmiş istek; her satır için zaman, alan adı, yol, hangi yedekleme aşamasının kullanıldığı (method sütunu) ve HTTP durum kodu.Gösterge paneli, JavaScript setInterval() fonksiyonu kullanarak / pqc-gateway / status ve / pqc-gateway / activity uç noktalarını düzenli aralıklarla (tercihen 2 saniye) yoklar ve tabloyu canlı olarak günceller.Aktivite tablosundaki yöntem (method) sütunu kritik bir özgünlük unsurudur çünkü son kullanıcıya hangi yedekleme aşamasının hangi istek için kullanıldığını görsel olarak gösterir. Bu bilgi, hem hata ayıklama hem de PQC altyapısının "sağlığı" hakkında hızlı fikir vermek için değerlidir. Örneğin, eğer son 20 istek ağırlıklı olarak bridge kullandıysa, kullanıcı gömülü bssl alt-süreç istemcisinin çalışmadığını fark eder ve yapılandırmasını gözden geçirebilir.Aktivite günlüğü, ağ geçidi işleminin belleğinde saklanır ve bir karşılıklı dışlama kilidi (mutex) ile korunan bir dairesel tampon (circular buffer) yapısı kullanır. Yeniden başlatılma durumunda geçmiş günlükler kaybolur; kalıcı günlükleme, buluşun bir alternatif uygulamasında bir dosyaya veya sistem günlük servisine yönlendirilebilir.< / style>

Claims

21 REQUESTS 1. A standard that does not directly support post-quantum digital signature algorithms. Information that has a Transport Layer Security (TLS) client library in the transaction environment, remote resources protected by post-quantum digital signature server certificates This is a method implemented in a local gateway operation to provide transparent access, The method is characterized by including the following steps: a) the local gateway operation in question involves a client application accessing a configured URL A Hypertext Transfer Protocol that includes a destination domain name and a path component from a location. Receiving an (HTTP) request; b) a call operator processing the request must have permission for the target domain in question. Verification that it belongs to the domain name set; c) In the first prioritized stage, the call organizer in question, the local network in question a post-quantum TLS embedded in the executable binary of the gateway operation the client binary as a subprocess for connecting to the target domain in question. to run; d) if the first stage fails or is unusable, the second prioritization At this stage, the call organizer in question has a configured name for the target domain in question. sending an HTTP request to the remote bridge endpoint, and that remote bridge endpoint Using its own post-quantum TLS client, it connects to the target domain and responds. transmission; e) if the aforementioned second stage also fails or is not structured, the third In the prioritized phase, the call arranger in question, the standard TLS client in question attempting to connect directly to the target domain name through its library; f) If any of the three aforementioned stages are successful, then the successful It records the phase in an activity log with a method identifier tag; and g) Transmitting the HTTP response received from the target server to the client application.

2. The method, according to claim 1, is characterized by the following feature: the post-quantum TLS in question. the client binary to the executable binary of the local gateway process in question the embedding of a compiler that compiles the source code of the local gateway process in question by statically mounting it at compile time via the embed directive It is the realization of. 22 3. The method, according to claim 2, is characterized by the following feature: the post-quantum TLS in question. On the first call of the client binary runtime, to a temporary file system location; (i) (i) requesting the creation of a temporary directory from the operating system, (ii) the embedded binary a file within that temporary directory with executable permissions (e.g., 0755 Unix permission mode) (iii) writing and storing the absolute path of the written file for the sub-process calls in question. It is removed step by step.

4. The method according to Claim 1 is characterized by the following feature: in the first stage in question, the sub- the process call involves: (i) preparing a sub-process instruction with a context timeout, (ii) the word The subject is a raw HTTP / 1.1 request message using the target domain, port, path, and query string. (iii) the creation of the raw HTTP / 1.1 request message of the sub-process in question. (iv) writing to the input (stdin) stream, executing the sub-process in question and standard output (stdout) redirection of the stream to a buffer memory, (v) the raw in the standard output stream in question Parsing the HTTP / 1.1 response as an HTTP response and (vi) the parsed response in question It includes the steps to return it to the call organizer.

5. This method, according to claim 1, is characterized by the following feature: the HTTP response in question... The subject is rewritten by a content rewrite module before being passed to the client application. processing; the content rewrite module in question processes the body of the response into a W3C converting it into a Document Object Model (DOM) tree using a compatible HTML parser and the word The subject is src (source), href (hyperlink), action (form action address), poster in the DOM tree. (video thumbnail), data (embedded object data), and srcset (resolution-sensitive visual resource). (set of attributes) uniform resource locators (Uniform Resource Locator) — URL) is rewritten in the format / proxy / {domain} / {path}.

6. This method, according to claim 5, is characterized by the following feature: rewriting the content in question. The module also handles the inline CSS content and CSS related elements within the HTTP response. URL calls within files are a set of regular expression rules. It is rewriting through [the medium / method].

7. The method according to claim 5 is characterized by the following feature: for the srcset attribute, the relevant content rewrite module's multi-URL format<url1 descriptor1, url2 descriptor2> parsing, rewriting each URL part separately, and resulting in the same multiple URL. It is the recombination in this form.

8. This method, according to Claim 1, is characterized by the following feature: the target domain and path in question. the component receives the HTTP request in question, structured in the form of / proxy / {domain} / {path} It is the process of extracting the URL by parsing it. 23 9. The method is defined in Claim 1 and is characterized by the following feature: the permitted area in question. The set of names can be selected via command-line flags or a JSON configuration file. It is configurable.

10. According to Claim 1, it is a method and is characterized by the following property: the method in question is a descriptive term. The tags are "bssl-direct" for the first stage, "bridge" for the second stage, and "bssl-direct" for the third stage, respectively. It should include "go-direct" values.

11. This method, according to Claim 1, is characterized by the following feature: the local gateway in question. the process uses unencrypted HTTP in its connection with the client application in question However, what stands out is its use of post-quantum TLS in its connection to the target domain name in question; the subject is an unencrypted HTTP connection to the local circular network interface on the client machine. It works via loopback.

12. This method, according to Claim 1, is characterized by the following feature: the local gateway in question. the process's; (i) creation status, (ii) connection status (port connection), (iii) running status, (iv) work in a coordinated manner between the suspended state and (v) stopped state phases. It performs lifecycle management via a particle-safe state variable and promises The subject is being paused in a contextual timeout, with the sub-process in question experiencing a speeding down. a rate limiter component and a Hypertext Transfer Protocol (HTTP) server It is the process of turning off the component sequentially.

13. The method according to claim 1 is characterized by the following feature: the client application in question and the HTTP request in question must be made to a browser application, a browser extension installed by the browser application TLS handshake error detection application programming interface (Application) Detected via Programming Interface — API (e.g., webNavigation.onErrorOccurred). Following a post-quantum TLS handshake error, the local gateway in question... The process is triggered by redirecting to the URL / proxy / {domain} / {path}.

14. The method according to Claim 1 is characterized by the following feature: the remote bridge end in question the configuration of the point with a separate hyperlink URL mapping table for each target domain name It is configurable.

15. The method according to Claim 1 is characterized by the following feature: the activity log in question, memory acts as a circular buffer for the duration that the local gateway process is running. kept within and presented to the end user via an embedded HTML dashboard It is shown live. 24 16. The method according to claim 15 is characterized by the following feature: the embedded HTML in question. the dashboard's local gateway is accessed via a JavaScript scripting scheduler. The process checks the / pqc-gateway / status and / pqc-gateway / activity endpoints at regular intervals. It is a (preferably 2-second) attendance check.

17. The method, according to Claim 1, is characterized by the following feature: the post-quantum TLS in question. The client binary file must be ML-DSA-44, ML-DSA-65, or as defined in the NIST FIPS 204 standard. TLS handshake with signed server certificates at ML-DSA-87 security levels. It is a binary file that is capable of doing so.

18. It is a local gateway system supported by post-quantum cryptography, and the system in question... It is characterized by including the following elements: a) a Hypertext Transfer Protocol (HTTP) server module (110) which is a A Transmission Control Protocol (TCP) is used over the local cyclic interface on the client machine. It listens on the Control Protocol (TCP) port and uses a uniform format of / proxy / {domain} / {path}. It accepts requests coming through resource locators (URLs); b) a domain name permission list administrator (120) who is responsible for a structured permission list. It compares the target domains of the incoming requests with the domain name set; c) a call regulator (130) which includes the following three access layers It coordinates in a prioritized order: • an embedded post-quantum TLS client sub-process wrapper (150), • a remote bridge HTTP client (160) and • a standard TLS client (170); d) the embedded post-quantum TLS client sub-process wrapper (150) which is The wrapper wraps a post-quantum TLS client binary onto the executable binary of the system in question. embedding it in a file, extracting it to a temporary file system location at runtime, and embedding it on each request. It has the ability to run as a sub-process; and e) a content rewriting module (140) which is the module that receives HTML from the target server. And it rewrites the URLs in the CSS content to the format / proxy / {domain} / {path}.

19. According to claim 18, the system is characterized by the following feature: that the system in question also has a The system tray (menu bar) includes a graphical user interface component; that component... the operational status (running / stopped) of the local gateway in question, port number, etc. The subject is the accessibility status of the embedded post-quantum TLS client and the permission in question. It displays a list of available domain names.

20. The system, according to claim 19, is characterized by the following feature: the system tray in question. The component also allows you to start / stop and open the embedded HTML dashboard in the browser. and it offers a menu that includes automatic startup options when logging in.

21. According to claim 18, the system is characterized by the following feature: that the system in question is a command a command-line interface (CLI) version and a graphical system tray that the two versions share the same server class (Server) and the same configuration model, so the two The version exhibits consistent behavior.

22. According to claim 18, the system is characterized by the following feature: the system in question has many It supports at least Darwin (macOS) as a cross-platform operating system. It is available in Linux and Windows.

23. The system, according to claim 18, is characterized by the following feature: the content in question is re-edited. The writing module's; (i) absolute same-domain URLs (https: / / domain / path), (ii) absolute external URLs (immutable), (iii) protocol-relative URLs ( / / domain / path), (iv) root-relative URLs ( / path), (v) relative URLs (sub / file) and (vi) data:, javascript:, mailto: uniform resource identifier (Uniform Resource Different rewrite rules for Identifier (URI) schemas (immutable) categories. It is an application.

24. The system, according to Claim 18, is characterized by the following feature: the embedded post- The quantum TLS client subprocess wrapper is the subject of the post-quantum TLS client binary. The file has priority over (a) an explicit flag path specified by the user, (b) system via PATH environment variable, and (c) only when the above two fail It supports loading from the embedded version at compile time.

25. The system according to claim 18 is characterized by the following property: that the system in question is pure Go (Go In version 1.24 or later, a single statically linked file compiled without CGO (CGO_ENABLED=0). It can be distributed as an executable file; the distribution package in question may contain an external library or No installation is required.

26. According to claim 18, the system is characterized by the following feature: the compilation of the system in question. build pipeline; (i) a patched BoringSSL source on a remote build server (ii) compiling the bssl post-quantum TLS client binary from the tree, (ii) the binary in question the file is a local assembly in a per-platform directory structure (bssl-bin / {os} / {arch} / bssl) (iii) transferring the file to the environment, cmd / cli / bssl or for each supported platform (iv) copying the said to cmd / app / bssl location with the command go build -tags embed_bssl statically linking the binary to the Go binary and (v) consequently platform-specific It includes the steps for generating single-file and binary outputs. 26 27. According to Claim 1, it is a method characterized by the following feature: the method in question also includes the following: The subject is a three-tier call arranger that processes each request after a reciprocal interaction. The creation of an activity input in a circular buffer protected by an exclusion lock (mutex); The subject of the activity input is at least a timestamp, the target domain name, the path, and the successful method. This includes the identification tag and HTTP status code fields.

28. The method according to Claim 1 is characterized by the following feature: the remote bridge end in question the point is to have a post-quantum TLS client tool (e.g., a BSSL client tool) on its side. It is an HTTP server that is managed with the help of a scripting language (for example, Python).

29. This method, according to Claim 1, is characterized by the following feature: the local gateway in question. The process involves applying the following to every request from the client application: (i) Access-Control-Allow-Origin: * Cross-Origin Resource Sharing sets the title in the response. — CORS) intermediary layer, (ii) request rate per network protocol address (Internet Protocol — IP) (iii) a rate limiting middleware and a structured one for each request a logging middleware that records the log in this way It is an application.

30. The method, according to claim 1, is characterized by the following feature: the standard TLS client in question. the library being the crypto / tls package for the Go programming language and in the aforementioned first stage post-quantum TLS client binary from BoringSSL or a derivative branch based on BoringSSL It is a derivation of (fork).

Images