[gelöst] OpenVPN benutzt AES-256-GCM statt CAMELLIA-256-CBC

[rne]

Hallo zusammen,

im Rahmen einer Routine-Logdurchsicht ist mir aufgefallen, dass auf einem unserer OpenVPN Netze etwas sehr merkwürdiges passiert.
Die Clients sind alle ArchLinux, der Server Debian 8.9.
Sowohl in der Konfiguration der Clients, als auch in jener des Servers ist cipher CAMELLIA-256-CBC angegeben.
Bis einschließlich 28.07.2017 10:06 Uhr liefen auch alle Clients laut Server- und Client-Journal mit dieser Chiffre (und zudem mit auth SHA-512).
Seit ca. 28.07.2017 10:54 Uhr werden die meisten Verbindungen jedoch über AES-256-GCM aufgebaut, obwohl dies gar nicht in den Konfigurationsdateien steht.

Code: Alles auswählen

Aug 01 15:40:01 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Aug 01 15:41:36 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'CAMELLIA-256-CBC' initialized with 256 bit key
Aug 01 15:41:36 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Aug 01 15:41:41 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 01 15:42:25 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 01 15:43:36 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'CAMELLIA-256-CBC' initialized with 256 bit key
Aug 01 15:43:36 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Aug 01 15:43:42 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 01 15:45:17 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 01 15:45:31 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'CAMELLIA-256-CBC' initialized with 256 bit key
Aug 01 15:45:31 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Aug 01 15:45:52 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'CAMELLIA-256-CBC' initialized with 256 bit key
Aug 01 15:45:52 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Aug 01 15:45:54 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'CAMELLIA-256-CBC' initialized with 256 bit key
Aug 01 15:45:54 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Aug 01 15:46:03 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'CAMELLIA-256-CBC' initialized with 256 bit key
Aug 01 15:46:03 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Aug 01 15:47:10 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'CAMELLIA-256-CBC' initialized with 256 bit key
Aug 01 15:47:10 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Aug 01 15:47:13 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 01 15:47:14 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'CAMELLIA-256-CBC' initialized with 256 bit key
Aug 01 15:47:14 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Aug 01 15:48:15 <host> openvpn[24932]: <common_name_ip> Channel Encrypt: Cipher 'CAMELLIA-256-CBC' initialized with 256 bit key
Aug 01 15:48:15 <host> openvpn[24932]: <common_name_ip> Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Aug 01 15:48:54 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 01 15:50:49 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'CAMELLIA-256-CBC' initialized with 256 bit key
Aug 01 15:50:49 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Aug 01 15:52:30 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 01 15:52:51 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 01 15:54:26 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'CAMELLIA-256-CBC' initialized with 256 bit key
Aug 01 15:54:26 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Using 512 bit message hash 'SHA512' for HMAC authentication
Aug 01 15:55:56 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key
Aug 01 15:56:06 <host> openvpn[24932]: <common_name_ip> Data Channel Encrypt: Cipher 'AES-256-GCM' initialized with 256 bit key

Ich habe die Anmeldevorgänge Stichprobenartig überprüft. Es sind tatsächlich unsere Systeme, die da mit einer anderen Chriffre die Verbindung aufbauen.
Ich wollte tatsächlich irgendwann mal auf AES-256-GCM migrieren, jedoch habe ich in keiner produktiven Konfigurationsdatei auf dem Server oder den Clients jemals eine Änderung diesbezüglich vorgenommen (mehrfach gecheckt).
Das einzige, was ich in fraglichem Zeitraum gemacht habe, ist OpenVPN auf dem Server aus den Backports aktualisiert, da der Port von Jessie noch kein AES-256-GCM kann.

Code: Alles auswählen

Log started: 2017-07-28  10:50:09
Vormals nicht ausgewähltes Paket liblz4-1:amd64 wird gewählt.
(Lese Datenbank ... ^M(Lese Datenbank ... 5%^M(Lese Datenbank ... 10%^M(Lese Datenbank ... 15%^M(Lese Datenbank ... 20%^M(Lese Datenbank ... 25%^M(Lese Datenbank ... 30%^M(Lese Datenbank ... 35%^M(Lese Datenbank ... 40%^M(Lese Datenbank ... 45%^M(Lese Datenbank ... 50%^M(Lese Datenbank ... 55%^M(Lese Datenbank ... 60%^M(Lese Datenbank ... 65%^M(Lese Datenbank ... 70%^M(Lese Datenbank ... 75%^M(Lese Datenbank ... 80%^M(Lese Datenbank ... 85%^M(Lese Datenbank ... 90%^M(Lese Datenbank ... 95%^M(Lese Datenbank ... 100%^M(Lese Datenbank ... 61150 Dateien und Verzeichnisse sind derzeit installiert.)
Vorbereitung zum Entpacken von .../liblz4-1_0.0~r122-2_amd64.deb ...
Entpacken von liblz4-1:amd64 (0.0~r122-2) ...
Vorbereitung zum Entpacken von .../openvpn_2.4.0-6+deb9u1~bpo8+1_amd64.deb ...
Entpacken von openvpn (2.4.0-6+deb9u1~bpo8+1) über (2.3.4-5+deb8u2) ...
Trigger für systemd (215-17+deb8u7) werden verarbeitet ...
Trigger für man-db (2.7.0.2-5) werden verarbeitet ...
liblz4-1:amd64 (0.0~r122-2) wird eingerichtet ...
openvpn (2.4.0-6+deb9u1~bpo8+1) wird eingerichtet ...

Konfigurationsdatei »/etc/init.d/openvpn«
 ==> Gelöscht (von Ihnen oder von einem Skript) seit der Installation.
 ==> Paketverteiler hat eine aktualisierte Version herausgegeben.
   Wie möchten Sie vorgehen? Ihre Wahlmöglichkeiten sind:
    Y oder I : Die Version des Paket-Betreuers installieren
    N oder O : Die momentan installierte Version beibehalten
       D     : Die Unterschiede zwischen den Versionen anzeigen
       Z     : Eine Shell starten, um die Situation zu begutachten
 Der Standardweg ist das Beibehalten der momentanen Version.
*** openvpn (Y/I/N/O/D/Z) [Vorgabe=N] ? Y
Neue Version der Konfigurationsdatei /etc/init.d/openvpn wird installiert ...
[....] Restarting virtual private network daemon.:ESC[?25lESC7ESC[1G[ESC[32m ok ESC[39;49mESC8ESC[?12lESC[?25h.
Trigger für libc-bin (2.19-18+deb8u10) werden verarbeitet ...
Trigger für systemd (215-17+deb8u7) werden verarbeitet ...
Log ended: 2017-07-28  10:50:46

Die große Frage ist nun, warum in den meisten Fällen nun AES-256-GCM verwendet wird.
Hängt das womöglich mit dem Update des VPN Servers auf dem Server zusammen?
Gibt es einen Bug im OpenVPN Server diesbezüglich?
Allerdings sollte auch die neueste Version CAMELLIA-256-CBC beherrschen:

Code: Alles auswählen

server:~ $ openvpn --show-ciphers | grep CAMELLIA-256-CBC
CAMELLIA-256-CBC  (256 bit key, 128 bit block)

Edit:
Definitiv ein Server Problem.
Auf dem Client:

Code: Alles auswählen

Aug 01 16:53:20 <host> openvpn[302]: PUSH: Received control message: 'PUSH_REPLY,route [...],cipher AES-256-GCM'

Woher kommt das?
Auf dem Server:

Code: Alles auswählen

$ grep -E "AES|CAMELLIA" terminals.conf 
cipher CAMELLIA-256-CBC

[mat6937]

Konfigurationsdatei »/etc/init.d/openvpn«
==> Gelöscht (von Ihnen oder von einem Skript) seit der Installation.
==> Paketverteiler hat eine aktualisierte Version herausgegeben.
Wie möchten Sie vorgehen? Ihre Wahlmöglichkeiten sind:
Y oder I : Die Version des Paket-Betreuers installieren
N oder O : Die momentan installierte Version beibehalten
D : Die Unterschiede zwischen den Versionen anzeigen
Z : Eine Shell starten, um die Situation zu begutachten
Der Standardweg ist das Beibehalten der momentanen Version.
*** openvpn (Y/I/N/O/D/Z) [Vorgabe=N] ? Y

Hängt das womöglich mit dem Update des VPN Servers auf dem Server zusammen?

Evtl. ja, denn Du hast deine Konfiguration nicht beibehalten (N), sondern die des maintainers (Y) gewählt.

[rne]

Die Datei

Code: Alles auswählen

/etc/init.d/openvpn

ist das alte SystemV-Compat Init-Skript und keine Konfigurationsdatei.
Keine Ahnung, warum der Paketmanager das behauptet.
Ich hatte die zuvor gelöscht, da ich zur Steuerung des Dienstes Systemd mit dem zugehörigen Service-Unit verwende.
Beim Upgrade auf OpenVPN 2.4 aus den Backports habe ich dann die Installtion dieser Datei abgenickt, da ich nicht wusste, ob das neue Paket die eventuell braucht (nein, tut es nicht).
Kurzum: Die Datei hat mit meinem Problem nicht das geringste zu tun.
OT: Ich verstehe so wie so nicht, warum Debian nach der Migration auf Systemd den ganzen /etc/init.d Müll behalten hat.
Würde ich das nutzen wollen, wäre ich in einem Devuan-Forum unterwegs.

[mat6937]

..., da ich nicht wusste, ob das neue Paket die eventuell braucht (nein, tut es nicht).
Kurzum: Die Datei hat mit meinem Problem nicht das geringste zu tun.

Wie genau hast Du festgestellt, dass diese Datei mit deinem Problem nichts zu tun hat?

[rne]

..., da ich nicht wusste, ob das neue Paket die eventuell braucht (nein, tut es nicht).
Kurzum: Die Datei hat mit meinem Problem nicht das geringste zu tun.

Wie genau hast Du festgestellt, dass diese Datei mit deinem Problem nichts zu tun hat?

Ich danke Dir für Deine versuchte Unterstützung. Aber auf diesem Weg kommen wir nicht weiter.
Wenn ich Dir jetzt erklären muss, was ein SysV-Init Sktript ist und warum sich seine Existenz oder Abwesenheit nicht auf einen Service auswirkt, wenn es so wie so nicht benutzt wird, da der Service über Systemd-Units gesteuert wird, wird dieser Thread einfach nur ad absurdum geführt.
Aber um deine Frage zu beantworten:
Ich habe sie mittels vim eingesehen und nach dem Upgrade auf OpenVPN 2.4 folgendes ausgeführt:

Code: Alles auswählen

$ dpkg -L openvpn | grep .service
/lib/systemd/system/openvpn-client@.service
/lib/systemd/system/openvpn@.service
/lib/systemd/system/openvpn-server@.service
/lib/systemd/system/openvpn.service

Daher weiß ich, dass ich das Init-Skript nicht brauche.

[mat6937]

Wenn ich Dir jetzt erklären muss, was ein SysV-Init Sktript ist und warum sich seine Existenz oder Abwesenheit nicht auf einen Service auswirkt, wenn es so wie so nicht benutzt wird, da der Service über Systemd-Units gesteuert wird, wird dieser Thread einfach nur ad absurdum geführt.

Keine Angst, das musst Du nicht.

Aber um deine Frage zu beantworten:
Ich habe sie mittels vim eingesehen und nach dem Upgrade auf OpenVPN 2.4 folgendes ausgeführt:

Code: Alles auswählen

$ dpkg -L openvpn | grep .service
/lib/systemd/system/openvpn-client@.service
/lib/systemd/system/openvpn@.service
/lib/systemd/system/openvpn-server@.service
/lib/systemd/system/openvpn.service

Daher weiß ich, dass ich das Init-Skript nicht brauche.

Besser mit:

Code: Alles auswählen

systemctl list-units --all | grep -i openvpn
systemctl cat openvpn@server.service
systemctl cat openvpn.service

etc.

BTW: Es gibt z. Zt. auch noch service-units, die das start-stop-Script aus dem Verzeichnis "/etc/init.d" verwenden. Z. B.:

Code: Alles auswählen

systemctl cat ntp

D. h., auch wenn systemd drauf steht, ist nicht immer auch systemd drin.

[rne]

Besser mit:

Code: Alles auswählen

systemctl list-units --all | grep -i openvpn
systemctl cat openvpn@server.service
systemctl cat openvpn.service

etc.

Wohl kaum.

Code: Alles auswählen

$ systemctl list-units --all | grep openvpn-client

Listet nämlich nicht das vorhandene, aber nicht aktivierte Unit-Template openvpn-client@.service.
Außerdem wollte ich nicht wissen, welche Units mit "openvpn" im Namen aktiv sind, sondern, ob und falls ja welche Systemd Services mir das Paket openvpn zur Verfügung stellt.

BTW: Es gibt z. Zt. auch noch service-units, die das start-stop-Script aus dem Verzeichnis "/etc/init.d" verwenden. Z. B.:

Code: Alles auswählen

systemctl cat ntp

D. h., auch wenn systemd drauf steht, ist nicht immer auch systemd drin.

Das ist ein Problem der Debian-Paketmaintainer.
Unter Arch haben wir:

Code: Alles auswählen

$ cat /usr/lib/systemd/system/ntpd.service
[Unit]
Description=Network Time Service
After=network.target nss-lookup.target
Conflicts=systemd-timesyncd.service

[Service]
Type=forking
PrivateTmp=true
ExecStart=/usr/bin/ntpd -g -u ntp:ntp
Restart=always

[Install]
WantedBy=multi-user.target

Das zeigt wenn, dann nur, dass Debian bis heute keine konsequente Migration auf Systemd auf die Kette bekommen hat.
Aber jetzt haben wir uns schon vollständig vom eigentlichen Thema entfernt.

[dufty2]

Ohne mich mit OpenVPN auszukennen lese ich in der "man openvpn" was von NCP, was es ab 2.4 gibt,
also die Cipher negotiation.
Und bei diesem ist default "AES-256-GCM:AES-128-GCM".
Keine Ahnung ob NCP dann die "cipher ...."-Direktive "overruled".

[rne]

Jawohl. Vielen Dank für den Hinweis.
Hatte das offenbar völlig überlesen.
Ich probiere die NCP Optionen mal aus.
Ich bin mir aber jetzt schon sicher, dass es das sein wird, da es mein Problem vollständig erklären würde.

If both peers support and do not disable NCP, the negotiated cipher will override the cipher specified by --cipher.

Das erklärt auch, warum einige Clients mit älteren OpenVPN Versionen auf CAMELLIA-256-CBC zurück fallen.
Sie können nämlich noch kein NCP.

Lösung:
Es ist NCP, was zu dem beschriebenen Verhalten führt.