66 lines
3.3 KiB
Django/Jinja
66 lines
3.3 KiB
Django/Jinja
# OpenSSL-Konfiguration AUSSCHLIESSLICH fuer den guacd-Prozess.
|
|
#
|
|
# Wird ueber Environment=OPENSSL_CONF= in der guacd-Unit gesetzt (siehe
|
|
# guacd.service.j2) und gilt damit NUR fuer guacd/FreeRDP -- nicht fuer
|
|
# nginx, nicht fuer die Jumphost-App, nicht fuer SSH, nicht fuer apt.
|
|
# Systemweit (/etc/ssl/openssl.cnf) bleibt alles unveraendert streng.
|
|
#
|
|
# Wozu: Debian 12 setzt systemweit MinProtocol = TLSv1.2 und
|
|
# CipherString = DEFAULT@SECLEVEL=2. Ein Windows-Ziel, dessen SCHANNEL-
|
|
# Konfiguration nur aeltere TLS-Versionen oder schwaechere Cipher anbietet,
|
|
# ist damit von diesem Host aus NICHT erreichbar: OpenSSL bricht den
|
|
# Handshake ab, BEVOR ueberhaupt ein Zertifikat geprueft wird. guacd meldet
|
|
# das als "SSL/TLS connection failed (untrusted/self-signed certificate?)"
|
|
# -- der Klammerzusatz ist eine feste Vermutung im guacd-Quelltext und in
|
|
# diesem Fall irrefuehrend; die Hosteinstellung "Zertifikat ignorieren"
|
|
# kann daran folglich nichts aendern.
|
|
#
|
|
# Gemessener Fall (jumphost-97 -> 10.0.0.12, 3.9.): der Handshake gelingt erst
|
|
# ab Sicherheitsstufe 0; Stufe 1 UND 2 scheitern beide gleich mit einem TCP-RST
|
|
# der Gegenstelle. Das deutet auf die signature_algorithms-Erweiterung: OpenSSL
|
|
# 3.0 bietet ab Stufe 1 kein SHA-1 mehr als Signaturverfahren an, und das Ziel
|
|
# kann den ServerKeyExchange offenbar nicht anders signieren. Nicht das
|
|
# ZERTIFIKAT ist das Problem -- dessen Signatur prueft bei ignore-cert ohnehin
|
|
# niemand (eigens gegengeprueft).
|
|
#
|
|
# ABWAEGUNG (bewusst zu treffen, deshalb standardmaessig AUS):
|
|
# Diese Datei senkt die TLS-Anforderungen fuer die Strecke
|
|
# Jumphost -> Windows-Ziel. Die Strecke Browser -> Jumphost ist davon nicht
|
|
# betroffen. Innerhalb eines abgeschotteten Verwaltungsnetzes ist das
|
|
# vertretbar; die saubere Loesung bleibt, TLS 1.2 auf dem Windows-Ziel zu
|
|
# aktivieren. Nur so weit lockern wie noetig -- guacd_tls_min_protocol und
|
|
# guacd_tls_security_level einzeln nachziehen, statt pauschal auf TLSv1/0.
|
|
# Auch bei SECLEVEL=0 schliesst 'DEFAULT' weiterhin NULL- und anonyme Cipher
|
|
# aus -- eine ungeschuetzte Verbindung wird dadurch also nicht moeglich.
|
|
# Zusammen mit MinProtocol=MaxProtocol=TLSv1.2 bleibt die Lockerung eng.
|
|
|
|
openssl_conf = default_conf
|
|
|
|
[default_conf]
|
|
ssl_conf = ssl_sect
|
|
|
|
[ssl_sect]
|
|
system_default = system_default_sect
|
|
|
|
[system_default_sect]
|
|
MinProtocol = {{ guacd_tls_min_protocol }}
|
|
{% if guacd_tls_max_protocol | default('', true) | length > 0 %}
|
|
MaxProtocol = {{ guacd_tls_max_protocol }}
|
|
{% endif %}
|
|
CipherString = DEFAULT@SECLEVEL={{ guacd_tls_security_level }}
|
|
{% if guacd_tls_signature_algorithms | default('', true) | length > 0 %}
|
|
# Explizite Liste der angebotenen Signaturverfahren. Gemessen am 3.9.:
|
|
# die Cipher-Liste ist auf allen Sicherheitsstufen IDENTISCH
|
|
# (openssl ciphers -s 'DEFAULT@SECLEVEL=0|1|2' -> jeweils dieselben 30),
|
|
# der Unterschied liegt also in der signature_algorithms-Erweiterung:
|
|
# OpenSSL 3.0 bietet SHA-1 ab Stufe 1 nicht mehr an. Achtung -- die
|
|
# Sicherheitsstufe filtert diese Liste NACHTRAEGLICH nochmals, ohne
|
|
# guacd_tls_security_level: 0 bleibt SHA-1 also trotzdem draussen.
|
|
SignatureAlgorithms = {{ guacd_tls_signature_algorithms }}
|
|
{% endif %}
|
|
{% if guacd_tls_unsafe_legacy_renegotiation %}
|
|
# Manche aeltere Windows-/SCHANNEL-Staende koennen die in OpenSSL 3
|
|
# standardmaessig abgeschaltete unsichere Neuverhandlung verlangen.
|
|
Options = UnsafeLegacyRenegotiation
|
|
{% endif %}
|