[Gelöst] OpenSSL verhält sich widersprüchlich

DarkTrinity

DarkTrinity

Member
Hallo liebe Community,

Auf meinem Testserver (VirtualBox, Ubuntu 20.04 LTS) habe ich leider ein "kleines Problem" mit TLS 1.3, was in meinen Augen ziemlich widersprüchlich bzw komisch ist:

Mein Anliegen:
Es soll für Apache eine der folgende Suites verwendet werden:
TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256

A. Problembeschreibung:
1. Ich lasse mir die zur Verfügung stehenden CipherSuites für TLS1.3 ausgeben - mit einem zunächst erfreulichen Ergebnis:
root@webqa1:/# openssl ciphers -s -tls1_3 TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256
2. Ich implementiere in einer von mehreren VHost- Dateien den folgenden Snip:
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2 SSLCipherSuite TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
3. Ich starte den Apache neu und falle auf die Nase
Jul 11 11:07:28 webqa1 apachectl[15219]: The Apache error log may have more information. Jul 11 11:07:28 webqa1 systemd[1]: apache2.service: Control process exited, code=exited, status=1/FAILURE Jul 11 11:07:28 webqa1 systemd[1]: apache2.service: Failed with result 'exit-code'. Jul 11 11:07:28 webqa1 systemd[1]: Failed to start The Apache HTTP Server.
4. Ich finde folgende Logs:
[Sun Jul 11 11:07:28.584236 2021] [ssl:emerg] [pid 15222:tid 139817452014912] AH01898: Unable to configure permitted SSL ciphers [Sun Jul 11 11:07:28.584308 2021] [ssl:emerg] [pid 15222:tid 139817452014912] SSL Library Error: error:1410D0B9:SSL routines:SSL_CTX_set_cipher_list:no cipher match

Das ist doch widersprüchlich, da OpenSSL ja behauptet, es könnte mit den verwendeten Ciphers umgehen .....

B. Merkwürdigkeit Nummer 2
1. Ok... Just for fun rolle ich die Cipher Direktive wie folgt auf Standard zurück in dem gleichen VHost:
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2 SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
2. Ich starte den Apache wieder durch und das klappt auch
3. Von einem anderen Rechner im Netzwerk aus untersuche ich nun die TLS Verbindung zu genau diesem Host - mit dem merkwüprdigen Ergebnis, daß die CipherSuite TLS_AES_256_GCM_SHA384 urplötzlich doch zu funktionieren scheint - obwohl sie garnicht in der entsprechenden Direktive enthalten ist (und immer wenn sie in der Direktive enthalten ist gehts ie nicht - siehe oben):
openssl s_client -connect meinhost.local:443 [...] No client certificate CA names sent Peer signing digest: SHA256 Peer signature type: RSA-PSS Server Temp Key: X25519, 253 bits --- SSL handshake has read 1601 bytes and written 407 bytes Verification error: self signed certificate --- New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 Server public key is 2048 bit Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 18 (self signed certificate) [...]

Was kann man da machen ?
- Ich habe mit der CA.pl eine eigene Zertifizierungsstelle angelegt und mir ein unterschriebenes Zertifikat gebastelt - brachte natürlich nix
- Mir fiel auf, daß ich die libssl in 2 Versionen hatte: 1.0.0 und 1.1. Die 1.0.0 hab eich dann entfernt (weil openssl ja Version 1.1.1 hat) - brachte auch nix (wär ja auch langweilig)....

Es muss doch machbar sein, in der Dirtektive SSL_CipherSuites Werte anzugeben, von denen OpenSSL behauptet diese zu beherrschen !
Ich vermute es ist ein Problem mit dem OpenSSL Paket. Das Betriebsystem wurde bereits von 16 auf 18 und dann auf 20.04 geupdated - vielleicht hat da ja für OpenSSL i-was nicht geklappt ?

Ich bin leider gerade ziemlich planlos wie es weiter gehen soll auf dieser Baustelle :(

Vielen lieben Dank für Rat und Anregung
 
RTFM:
Code: 
<IfModule ssl_module>
    SSLRandomSeed startup "file:/dev/urandom" 65536
    SSLRandomSeed connect "file:/dev/urandom" 65536
    SSLPassPhraseDialog builtin
    <IfModule socache_shmcb_module>
        SSLSessionCache "shmcb:/var/run/ssl_scache(512000)"
    </IfModule>
    <IfModule !socache_shmcb_module>
        <IfModule socache_dbm_module>
            SSLSessionCache "dbm:/var/run/ssl_scache"
        </IfModule>
        <IfModule !socache_dbm_module>
            SSLSessionCache "nonenotnull"
        </IfModule>
    </IfModule>
    SSLHonorCipherOrder On
    SSLStrictSNIVHostCheck On
    SSLProtocol -ALL +TLSv1.2 +TLSv1.3
    SSLOptions +StrictRequire +StdEnvVars
    SSLCipherSuite "TLSv1.2 +CHACHA20 +AESGCM !DH !AESCCM !CAMELLIA !PSK !RSA !SHA1 !SHA256 !SHA384 !kDHd !kDHr !kECDH !aDSS !aNULL"
    SSLCipherSuite TLSv1.3 "TLS_CHACHA20_POLY1305_SHA256:TLS_AES_256_GCM_SHA384:TLS_AES_128_GCM_SHA256"
    SSLOpenSSLConfCmd Curves "X448:X25519:secp384r1:prime256v1"
    SSLOCSPEnable On
    SSLStaplingFakeTryLater Off
    SSLStaplingResponderTimeout 2
    SSLStaplingReturnResponderErrors Off
    SSLStaplingStandardCacheTimeout 86400
    <IfModule socache_shmcb_module>
        SSLUseStapling On
        SSLStaplingCache "shmcb:/var/run/stapling_cache(128000000)"
    </IfModule>
    <IfModule !socache_shmcb_module>
        <IfModule socache_dbm_module>
            SSLUseStapling On
            SSLStaplingCache "dbm:/var/run/stapling_cache"
        </IfModule>
        <IfModule !socache_dbm_module>
            SSLUseStapling Off
        </IfModule>
    </IfModule>
    Include "etc/apache24/vhosts-ssl.conf"
    <IfModule headers_module>
        Header set Public-Key-Pins "max-age=0; includeSubdomains"
        Header set Strict-Transport-Security "max-age=15768000; includeSubdomains; preload"
        Header set Expect-CT "max-age=0"
    </IfModule>
</IfModule>
 
Was ausschließliches TLS 1.3 angeht, so habe ich das nun wie folgt erreicht:
[...] SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1 -TLSv1.2 SSLHonorCipherOrder off SSLSessionTickets off SSLUseStapling On SSLStaplingCache "shmcb:logs/ssl_stapling(32768)" [...]

@Joe User
Mit Deinem Snip lässt Du vor allen Dingen auch TLS 1.2 Verbindungen zu (neben ein paar anderen Unschönheiten)

Zwischen die Direktive "SSLCipherSuite" und den vorgegebenen Algorithmen ein "TLSv1.3" zu packen scheint aber immerhin den Fehler aus meinem ersten Posting zu beheben ^^ So hab ich es auch auf dem Gerät überniommen jetzt.

Also Danke dafür (trotz Deines eher unnötigen "RTFM")

Keine Ahnung in welchem "F*cking Manual" Du das gelesen hast, aber ich sehe es zum ersten mal.

Bis jetzt habe ich das immer nur als
SSLCipherSuite <Per Doppelpunkt getrennte Liste>
gesehen, wo es, zumindest bis TLS 1.2, auch immer gut funktioniert ^^

:cool:
 
Ok, der Punkt geht wohl klar an Dich - sticht ins Auge und scheint zu passen natürlich Dein Link:
If the SSL library supports TLSv1.3 (OpenSSL 1.1.1 and later), the protocol specifier "TLSv1.3" can be used to configure the cipher suites for that protocol.
Click to expand...
Wie dort erklärt ist das offenbar "neu" mit TLS 1.3. Aber ich gebe zu dort zuvor nicht gelesen zu haben - jedenfalls nicht zu diesem Thema. Dafür auf 1000 anderen Seiten die mich nicht weiter brachten :) Das war wirklich ein hilfreicher Hinweis

Mit Unschönheiten meinte ich zB daß ich
  1. SSLCompression off
  2. SSLSessionTickets off
vermissen würde (ohne zu wissen was zB in Deiner includeten "etc/apache24/vhosts-ssl.conf" steht).

Mit Ubuntu und einem via Paketmanager installierten Apache scheinst Du ja offenbar nicht zu arbeiten, wie ich diesem Pfad entnehme - muss man natürlich auch nicht :)
 
DarkTrinity said:
Mit Unschönheiten meinte ich zB daß ich
  1. SSLCompression off
  2. SSLSessionTickets off
vermissen würde (ohne zu wissen was zB in Deiner includeten "etc/apache24/vhosts-ssl.conf" steht).
Click to expand...
Erstes ist Default und Zweites ist unnötig.
In der vhosts-ssl.conf stehen ausschliesslich VHosts und für mod_ssl lediglich die Zertifikate.

DarkTrinity said:
Mit Ubuntu und einem via Paketmanager installierten Apache scheinst Du ja offenbar nicht zu arbeiten, wie ich diesem Pfad entnehme - muss man natürlich auch nicht :)
Click to expand...
FreeBSD.
So ein völlig veralteter Müll wie Debian und dessen Derivate kommt nicht auf meine Systeme...
 
Hat Dir schon mal jemand gesagt, daß Dich die Art wie Du schreibst total symphatisch macht ? :oops:

Ich könnte jetzt argumentieren daß Free-BSD keine Opensource ist - im Gegensatz zu Ubuntu. Oder daß Ubuntu wohl flexibler ist.
Und "veralteter Müll" finde ich ist auch nicht gerade eine gerechtfertigte Bezeichnung für Ubuntu.

Aber ich habe keine Lust das hier auszudiskutieren ^^
 
DarkTrinity said:
Hat Dir schon mal jemand gesagt, daß Dich die Art wie Du schreibst total symphatisch macht ? :oops:
Click to expand...
Jepp.

DarkTrinity said:
Ich könnte jetzt argumentieren daß Free-BSD keine Opensource ist - im Gegensatz zu Ubuntu. Oder daß Ubuntu wohl flexibler ist.
Click to expand...
FreeBSD ist seit seinem ersten Tag (1993) OpenSource und das war auch nie anders.
Ubuntu flexible? Sorry, aber eine Binary-Distro kann nicht flexible sein.

DarkTrinity said:
Und "veralteter Müll" finde ich ist auch nicht gerade eine gerechtfertigte Bezeichnung für Ubuntu.
Click to expand...
Wie würdest Du völlig veraltete und völlig überfrachtete und ungepatchte Pakete denn sonst nennen?
 
Joe User said:
[...]
FreeBSD ist seit seinem ersten Tag (1993) OpenSource und das war auch nie anders.
[...]
Click to expand...
Zumindest hat es ein abweichendes Lizenzmodell - nämlich nicht das gängige GPL sondern eben ein wahrscheinlich eher eigenbrötlerisches Modell "BSD Lizenz", was ich jedoch im Detail zugegebenerweise nicht kenne. Free-BSD ist auch kein "wirklich echtes Linux", sei es noch so ähnlich aufgebaut und noch so kompatibel.

Aber ich will hier auch garnichts schlecht reden. Meine Favoriten sind und bleiben allerdings Ubuntu für Server und Opensuse für Desktops.

Und wenn die Paketmanager und dessen Angebote mal nicht flexibel genug sind, so kann man immer noch eine selbst kompilierte Softwareversion installieren, was aber nur selten wirklich erforderlich ist.
 
DarkTrinity said:
Zumindest hat es ein abweichendes Lizenzmodell
Click to expand...
Glücklicherweise.
DarkTrinity said:
- nämlich nicht das gängige GPL
Click to expand...
Die GPL ist nicht "gängig", war es nie, kann und wird es nie sein, sie existiert lediglich.
DarkTrinity said:
sondern eben ein wahrscheinlich eher eigenbrötlerisches Modell "BSD Lizenz", was ich jedoch im Detail zugegebenerweise nicht kenne.
Click to expand...
Dann solltest Du Dich erstmal damit beschäftigen, bevor Du Dich weiter blamierst.
DarkTrinity said:
Free-BSD ist auch kein "wirklich echtes Linux", sei es noch so ähnlich aufgebaut und noch so kompatibel.
Click to expand...
Richtig, FreeBSD ist ein echtes UNIX. Etwas, was Linux nie werden wird, egal wie kompatibel es gefrickelt wird...
 
You must log in or register to reply here.
Back
Top