sgcWebSockets kann vollständig ohne OpenSSL-Bibliothek laufen. Zwei unabhängige Einstellungen ermöglichen dies, und beide bauen auf den in reinem Pascal geschriebenen sgcCrypto-Units auf, die ab der Standard-Edition ausgeliefert werden.
iohNativeTLS ist ein IOHandler-Wert. Er ersetzt OpenSSL für die Verbindungen einer Komponente: TLS, QUIC und DTLS. Siehe Native TLS.
sgcCryptoBackend ist ein Laufzeitschalter. Er wählt das Backend der Anwendungskryptografie, also alles, was keine Verbindung ist: Hashes, Signaturen, Schlüsselvereinbarung und Zertifikatsverarbeitung.
Eine Anwendung, die weder für ihre Verbindungen noch für ihre sonstige Kryptografie OpenSSL benötigt, verwendet beide.
Die Unit sgcBase_Helpers deklariert die globale Variable sgcCryptoBackend vom Typ TsgcCryptoBackend:
cbOpenSSL (Standard): Die Anwendungskryptografie läuft auf OpenSSL, wie in früheren Versionen.
cbNative: Sie läuft auf sgcCrypto, und OpenSSL wird dafür nie geladen.
cbAuto: OpenSSL wird verwendet, wenn es geladen werden kann, sonst sgcCrypto. Die Prüfung läuft einmal, und das Ergebnis wird zwischengespeichert.
Der Schalter ist global, nicht pro Komponente. Setzen Sie ihn einmal beim Start, bevor eine Komponente erzeugt wird. sgcUseNativeCrypto liefert True, wenn das native Backend verwendet wird. Das native Backend benötigt die einkompilierten sgcCrypto-Units (SGC_CRYPTO). Ohne sie löst cbNative die Ausnahme "Native crypto not available, sgcCrypto units are not compiled in" aus. Rufen Sie sgcCheckNativeCrypto auf, um diesen Fehler bereits beim Start statt erst bei der ersten Verwendung zu erhalten.
uses
sgcBase_Helpers;
begin
sgcCryptoBackend := cbNative;
sgcCheckNativeCrypto;
Application.Initialize;
...
Diese Bereiche folgen dem Schalter:
| Bereich | Was nativ läuft |
| Hash- und HMAC-Hilfsfunktionen | Die Hash- und HMAC-Funktionen von sgcBase_Helpers sowie sgcEncryptString / sgcDecryptString. |
| JWT-, JWS-Signaturen | HMAC-, RSA-, RSA-PSS-, ECDSA- und EdDSA-Signieren und -Verifizieren (sgcSSL_RSA, sgcSSL_PS, sgcSSL_ES, sgcSSL_ED). sgcES_GetCurveFromPublicKey funktioniert nur mit einem OpenSSL-Schlüssel und löst beim nativen Backend eine Ausnahme aus. |
| Zertifikate | Die sgcSSL-Hilfsfunktionen: PEM-/DER-Konvertierung, Zertifikatsladen, CRL-URI und Zertifikatskettenprüfung. |
| OAuth2 und DPoP | Die OAuth2-JWK-Hilfsfunktion sowie die DPoP-Proof-Prüfung des OAuth2-Servers (ES256, ES384, ES512, RS256, RS384, RS512). Siehe DPoP. |
| Amazon | AWS Signature V4, die signierte CloudFront-URL sowie die Signature-V4-Authentifizierung des Amazon-IoT-MQTT-Clients, dessen SignatureV4.OpenSSL_Options dann ignoriert werden. |
| Web Push | Das VAPID-ES256-Token, die ECDH-Schlüsselvereinbarung, HKDF und die AES-128-GCM-Payload-Verschlüsselung. Nur eine https-Verbindung zum Push-Dienst lädt eine TLS-Bibliothek, über ihren IOHandler. |
| E2EE | Schlüsselvereinbarung, AES-GCM und der Zufallsgenerator. Die öffentlichen Schlüssel werden bei beiden Backends als PEM übertragen, rohe Schlüssel werden weiterhin akzeptiert, sodass Peers mit unterschiedlichen Backends interoperieren. |
| WebAuthn, SAML, OIDC | Die WebAuthn-Zertifikats-, COSE-Schlüssel- und Attestierungsprüfungen sowie die von SAML und OIDC verwendete XMLDSig-Signaturprüfung. |
| NTLM | Der MD4- und DES-Code der NTLM-Authentifizierung. Er ist in jedem Build nativ und benötigt kein Define mehr. |
| AEAD, KEM, HKDF | sgcSSL_AEAD (AES-128-GCM, AES-256-GCM, ChaCha20-Poly1305), sgcSSL_KEM (ML-KEM-768 und ECDH P-256) und sgcSSL_HKDF (jetzt auch mit sgcHKDF_MD_SHA384). ML-KEM-768 benötigt kein OpenSSL 3.5, und die Schlüssel verwenden dieselben Kodierungen wie OpenSSL 3.5. In einem FIPS-Build ist ChaCha20-Poly1305 nicht verfügbar und löst eine Ausnahme aus. |
| QUIC, DTLS, SRTP | QUIC-Paketschutz, das DTLS-Zertifikat und SRTP. Mit iohNativeTLS sind diese bereits pro Verbindung nativ, unabhängig davon, was der Schalter sagt. |
sgcCryptoBackend ändert nicht die TLS-Verbindung einer Komponente. Eine Komponente, die bei IOHandler = iohOpenSSL bleibt, lädt beim Verbinden weiterhin OpenSSL.
Das Define ist standardmäßig ausgeschaltet und wird nicht mehr benötigt, um ohne OpenSSL zu laufen. Ohne es werden sowohl der OpenSSL- als auch der native Code kompiliert, und sgcCryptoBackend entscheidet zur Laufzeit. Mit ihm wird das native Backend erzwungen, unabhängig davon, was sgcCryptoBackend sagt, und der OpenSSL-Code wird aus den Anwendungskryptografie-Units entfernt, sodass die ausführbare Datei kleiner wird. Um es zu aktivieren, öffnen Sie sgcVer.inc und entfernen Sie den Punkt aus der Zeile
{.$DEFINE SGC_NATIVE_CRYPTO}
oder fügen Sie SGC_NATIVE_CRYPTO zu den bedingten Defines Ihres Projekts hinzu. SGC_NATIVE_CRYPTO schaltet außerdem SGC_CRYPTO ein, die dafür benötigten sgcCrypto-Units. DISABLE_SGC_NATIVE_CRYPTO schaltet es wieder aus.
Welche Einstellungen Sie benötigen, hängt davon ab, was die Anwendung verwendet:
| Bereich | Einstellungen für kein OpenSSL |
| TLS über TCP: WebSocket, HTTP/1, HTTP/2, TCP, MQTT und die anderen Protokolle | TLSOptions.IOHandler (Client) oder SSLOptions.IOHandler (Server) = iohNativeTLS. Siehe Native TLS. |
| QUIC und HTTP/3 | IOHandler = iohNativeTLS. Der Handshake, der Paketschutz, die Schlüsselaktualisierung und das Retry-Tag sind alle nativ. Siehe QUIC und HTTP/3. |
| DTLS und WebRTC | DTLSOptions.IOHandler = iohNativeTLS. Der Handshake, das DTLS-Zertifikat und die SRTP-Schlüssel sind nativ. Siehe DTLSOptions und WebRTC DTLS. |
| Anwendungskryptografie: JWT, OAuth2, Web Push, Amazon Signature V4, E2EE, WebAuthn, SAML und die anderen Bereiche der ersten Tabelle | sgcCryptoBackend := cbNative beim Start, oder das Define SGC_NATIVE_CRYPTO. |
Die iohNativeTLS-Zeilen benötigen kein Define und keine sgcCryptoBackend-Einstellung. Die Auswahl von iohNativeTLS in einem Build ohne die sgcCrypto-Units löst eine Ausnahme aus, es fällt nie stillschweigend auf OpenSSL zurück.
Mit iohNativeTLS laufen der TLS-1.3- und TLS-1.2-Handshake sowie die Record-Schicht auf der nativen Engine. Es funktioniert für den WebSocket-, HTTP/1-, HTTP/2- und TCP-Client und -Server sowie für alles, was darauf aufbaut: MQTT, AMQP, STOMP und die anderen Protokolle, die API-Komponenten, die IoT-Clients (Certificate.IOHandler), die Upstream-Verbindung des Proxy-Servers (Proxy.TLSOptions) und den LDAP-Client. Das Zertifikat kann PEM, DER oder eine .pfx-/.p12-Datei sein.