[Frage] Angriff über OpenVPN?

dad401

Neuer User
Mitglied seit
26 Aug 2007
Beiträge
86
Punkte für Reaktionen
2
Punkte
8
Hallo,

auf meiner gefreetzten Box habe ich OpenVPN installiert. Kürzlich habe ich entdeckt, dass ich unter "Verbundene Clients" immer einen UNDEF Eintrag habe. Aktuell dieser hier:
Code:
UNDEF 2.247.242.142 Sat Dec  3 11:43:36 2016

Die IP ist von keinem meiner Clients. Im Syslog steht folgendes:
Code:
Dec  3 11:35:10 fritz daemon.err openvpn[18329]: 2.247.242.142:9173 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  3 11:35:10 fritz daemon.err openvpn[18329]: 2.247.242.142:9173 TLS Error: TLS handshake failed
Dec  3 11:35:10 fritz daemon.notice openvpn[18329]: 2.247.242.142:9173 SIGUSR1[soft,tls-error] received, client-instance restarting
Dec  3 11:35:12 fritz daemon.notice openvpn[18329]: MULTI: multi_create_instance called
Dec  3 11:35:12 fritz daemon.notice openvpn[18329]: 2.247.242.142:16794 Re-using SSL/TLS context
Dec  3 11:35:12 fritz daemon.notice openvpn[18329]: 2.247.242.142:16794 Control Channel MTU parms [ L:1541 D:166 EF:66 EB:0 ET:0 EL:0 ]
Dec  3 11:35:12 fritz daemon.notice openvpn[18329]: 2.247.242.142:16794 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Dec  3 11:35:12 fritz daemon.notice openvpn[18329]: 2.247.242.142:16794 TLS: Initial packet from [AF_INET]2.247.242.142:16794, sid=21fd11d1 2a7da409
Dec  3 11:36:13 fritz daemon.err openvpn[18329]: 2.247.242.142:16794 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  3 11:36:13 fritz daemon.err openvpn[18329]: 2.247.242.142:16794 TLS Error: TLS handshake failed
Dec  3 11:36:13 fritz daemon.notice openvpn[18329]: 2.247.242.142:16794 SIGUSR1[soft,tls-error] received, client-instance restarting
Dec  3 11:36:16 fritz daemon.notice openvpn[18329]: MULTI: multi_create_instance called
Dec  3 11:36:16 fritz daemon.notice openvpn[18329]: 2.247.242.142:21445 Re-using SSL/TLS context
Dec  3 11:36:16 fritz daemon.notice openvpn[18329]: 2.247.242.142:21445 Control Channel MTU parms [ L:1541 D:166 EF:66 EB:0 ET:0 EL:0 ]
Dec  3 11:36:16 fritz daemon.notice openvpn[18329]: 2.247.242.142:21445 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Dec  3 11:36:16 fritz daemon.notice openvpn[18329]: 2.247.242.142:21445 TLS: Initial packet from [AF_INET]2.247.242.142:21445, sid=49a7f480 cb8e30f6
Dec  3 11:37:16 fritz daemon.err openvpn[18329]: 2.247.242.142:21445 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  3 11:37:16 fritz daemon.err openvpn[18329]: 2.247.242.142:21445 TLS Error: TLS handshake failed
Dec  3 11:37:16 fritz daemon.notice openvpn[18329]: 2.247.242.142:21445 SIGUSR1[soft,tls-error] received, client-instance restarting
Dec  3 11:37:19 fritz daemon.notice openvpn[18329]: MULTI: multi_create_instance called
Dec  3 11:37:19 fritz daemon.notice openvpn[18329]: 2.247.242.142:29082 Re-using SSL/TLS context
Dec  3 11:37:19 fritz daemon.notice openvpn[18329]: 2.247.242.142:29082 Control Channel MTU parms [ L:1541 D:166 EF:66 EB:0 ET:0 EL:0 ]
Dec  3 11:37:19 fritz daemon.notice openvpn[18329]: 2.247.242.142:29082 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Dec  3 11:37:19 fritz daemon.notice openvpn[18329]: 2.247.242.142:29082 TLS: Initial packet from [AF_INET]2.247.242.142:29082, sid=0c17ab7e 6921fc02
Dec  3 11:38:19 fritz daemon.err openvpn[18329]: 2.247.242.142:29082 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  3 11:38:19 fritz daemon.err openvpn[18329]: 2.247.242.142:29082 TLS Error: TLS handshake failed
Dec  3 11:38:19 fritz daemon.notice openvpn[18329]: 2.247.242.142:29082 SIGUSR1[soft,tls-error] received, client-instance restarting
Dec  3 11:38:22 fritz daemon.notice openvpn[18329]: MULTI: multi_create_instance called
Dec  3 11:38:22 fritz daemon.notice openvpn[18329]: 2.247.242.142:5834 Re-using SSL/TLS context
Dec  3 11:38:22 fritz daemon.notice openvpn[18329]: 2.247.242.142:5834 Control Channel MTU parms [ L:1541 D:166 EF:66 EB:0 ET:0 EL:0 ]
Dec  3 11:38:22 fritz daemon.notice openvpn[18329]: 2.247.242.142:5834 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Dec  3 11:38:22 fritz daemon.notice openvpn[18329]: 2.247.242.142:5834 TLS: Initial packet from [AF_INET]2.247.242.142:5834, sid=66c13e2e 10182158
Dec  3 11:39:22 fritz daemon.err openvpn[18329]: 2.247.242.142:5834 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  3 11:39:22 fritz daemon.err openvpn[18329]: 2.247.242.142:5834 TLS Error: TLS handshake failed
Dec  3 11:39:22 fritz daemon.notice openvpn[18329]: 2.247.242.142:5834 SIGUSR1[soft,tls-error] received, client-instance restarting
Dec  3 11:39:24 fritz daemon.notice openvpn[18329]: MULTI: multi_create_instance called
Dec  3 11:39:24 fritz daemon.notice openvpn[18329]: 2.247.242.142:7180 Re-using SSL/TLS context
Dec  3 11:39:24 fritz daemon.notice openvpn[18329]: 2.247.242.142:7180 Control Channel MTU parms [ L:1541 D:166 EF:66 EB:0 ET:0 EL:0 ]
Dec  3 11:39:24 fritz daemon.notice openvpn[18329]: 2.247.242.142:7180 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Dec  3 11:39:24 fritz daemon.notice openvpn[18329]: 2.247.242.142:7180 TLS: Initial packet from [AF_INET]2.247.242.142:7180, sid=1caf1e72 d93154e5
Dec  3 11:40:25 fritz daemon.err openvpn[18329]: 2.247.242.142:7180 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  3 11:40:25 fritz daemon.err openvpn[18329]: 2.247.242.142:7180 TLS Error: TLS handshake failed
Dec  3 11:40:25 fritz daemon.notice openvpn[18329]: 2.247.242.142:7180 SIGUSR1[soft,tls-error] received, client-instance restarting
Dec  3 11:40:28 fritz daemon.notice openvpn[18329]: MULTI: multi_create_instance called
Dec  3 11:40:28 fritz daemon.notice openvpn[18329]: 2.247.242.142:14992 Re-using SSL/TLS context
Dec  3 11:40:28 fritz daemon.notice openvpn[18329]: 2.247.242.142:14992 Control Channel MTU parms [ L:1541 D:166 EF:66 EB:0 ET:0 EL:0 ]
Dec  3 11:40:28 fritz daemon.notice openvpn[18329]: 2.247.242.142:14992 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Dec  3 11:40:28 fritz daemon.notice openvpn[18329]: 2.247.242.142:14992 TLS: Initial packet from [AF_INET]2.247.242.142:14992, sid=14f78c6f eed8c98f
Dec  3 11:41:28 fritz daemon.err openvpn[18329]: 2.247.242.142:14992 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  3 11:41:28 fritz daemon.err openvpn[18329]: 2.247.242.142:14992 TLS Error: TLS handshake failed
Dec  3 11:41:28 fritz daemon.notice openvpn[18329]: 2.247.242.142:14992 SIGUSR1[soft,tls-error] received, client-instance restarting
Dec  3 11:41:31 fritz daemon.notice openvpn[18329]: MULTI: multi_create_instance called
Dec  3 11:41:31 fritz daemon.notice openvpn[18329]: 2.247.242.142:12478 Re-using SSL/TLS context
Dec  3 11:41:31 fritz daemon.notice openvpn[18329]: 2.247.242.142:12478 Control Channel MTU parms [ L:1541 D:166 EF:66 EB:0 ET:0 EL:0 ]
Dec  3 11:41:31 fritz daemon.notice openvpn[18329]: 2.247.242.142:12478 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Dec  3 11:41:31 fritz daemon.notice openvpn[18329]: 2.247.242.142:12478 TLS: Initial packet from [AF_INET]2.247.242.142:12478, sid=17a6f618 76138283
Dec  3 11:42:31 fritz daemon.err openvpn[18329]: 2.247.242.142:12478 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  3 11:42:31 fritz daemon.err openvpn[18329]: 2.247.242.142:12478 TLS Error: TLS handshake failed
Dec  3 11:42:31 fritz daemon.notice openvpn[18329]: 2.247.242.142:12478 SIGUSR1[soft,tls-error] received, client-instance restarting
Dec  3 11:42:34 fritz daemon.notice openvpn[18329]: MULTI: multi_create_instance called
Dec  3 11:42:34 fritz daemon.notice openvpn[18329]: 2.247.242.142:14974 Re-using SSL/TLS context
Dec  3 11:42:34 fritz daemon.notice openvpn[18329]: 2.247.242.142:14974 Control Channel MTU parms [ L:1541 D:166 EF:66 EB:0 ET:0 EL:0 ]
Dec  3 11:42:34 fritz daemon.notice openvpn[18329]: 2.247.242.142:14974 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Dec  3 11:42:34 fritz daemon.notice openvpn[18329]: 2.247.242.142:14974 TLS: Initial packet from [AF_INET]2.247.242.142:14974, sid=fff5df44 78b0c55e
Dec  3 11:43:35 fritz daemon.err openvpn[18329]: 2.247.242.142:14974 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  3 11:43:35 fritz daemon.err openvpn[18329]: 2.247.242.142:14974 TLS Error: TLS handshake failed
Dec  3 11:43:35 fritz daemon.notice openvpn[18329]: 2.247.242.142:14974 SIGUSR1[soft,tls-error] received, client-instance restarting
Dec  3 11:43:36 fritz daemon.notice openvpn[18329]: MULTI: multi_create_instance called
Dec  3 11:43:36 fritz daemon.notice openvpn[18329]: 2.247.242.142:22697 Re-using SSL/TLS context
Dec  3 11:43:36 fritz daemon.notice openvpn[18329]: 2.247.242.142:22697 Control Channel MTU parms [ L:1541 D:166 EF:66 EB:0 ET:0 EL:0 ]
Dec  3 11:43:36 fritz daemon.notice openvpn[18329]: 2.247.242.142:22697 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Dec  3 11:43:36 fritz daemon.notice openvpn[18329]: 2.247.242.142:22697 TLS: Initial packet from [AF_INET]2.247.242.142:22697, sid=a506701e 06384d96
Dec  3 11:44:36 fritz daemon.err openvpn[18329]: 2.247.242.142:22697 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  3 11:44:36 fritz daemon.err openvpn[18329]: 2.247.242.142:22697 TLS Error: TLS handshake failed
Dec  3 11:44:36 fritz daemon.notice openvpn[18329]: 2.247.242.142:22697 SIGUSR1[soft,tls-error] received, client-instance restarting
Dec  3 11:44:40 fritz daemon.notice openvpn[18329]: MULTI: multi_create_instance called
Dec  3 11:44:40 fritz daemon.notice openvpn[18329]: 2.247.242.142:20665 Re-using SSL/TLS context
Dec  3 11:44:40 fritz daemon.notice openvpn[18329]: 2.247.242.142:20665 Control Channel MTU parms [ L:1541 D:166 EF:66 EB:0 ET:0 EL:0 ]
Dec  3 11:44:40 fritz daemon.notice openvpn[18329]: 2.247.242.142:20665 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Dec  3 11:44:40 fritz daemon.notice openvpn[18329]: 2.247.242.142:20665 TLS: Initial packet from [AF_INET]2.247.242.142:20665, sid=a55f35ae c62bf8cf
Dec  3 11:45:40 fritz daemon.err openvpn[18329]: 2.247.242.142:20665 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  3 11:45:40 fritz daemon.err openvpn[18329]: 2.247.242.142:20665 TLS Error: TLS handshake failed
Dec  3 11:45:40 fritz daemon.notice openvpn[18329]: 2.247.242.142:20665 SIGUSR1[soft,tls-error] received, client-instance restarting
Dec  3 11:45:44 fritz daemon.notice openvpn[18329]: MULTI: multi_create_instance called
Dec  3 11:45:44 fritz daemon.notice openvpn[18329]: 2.247.242.142:20525 Re-using SSL/TLS context
Dec  3 11:45:44 fritz daemon.notice openvpn[18329]: 2.247.242.142:20525 Control Channel MTU parms [ L:1541 D:166 EF:66 EB:0 ET:0 EL:0 ]
Dec  3 11:45:44 fritz daemon.notice openvpn[18329]: 2.247.242.142:20525 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Dec  3 11:45:44 fritz daemon.notice openvpn[18329]: 2.247.242.142:20525 TLS: Initial packet from [AF_INET]2.247.242.142:20525, sid=d871cd47 73b54890
Dec  3 11:46:45 fritz daemon.err openvpn[18329]: 2.247.242.142:20525 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
Dec  3 11:46:45 fritz daemon.err openvpn[18329]: 2.247.242.142:20525 TLS Error: TLS handshake failed
Dec  3 11:46:45 fritz daemon.notice openvpn[18329]: 2.247.242.142:20525 SIGUSR1[soft,tls-error] received, client-instance restarting
Dec  3 11:46:47 fritz daemon.notice openvpn[18329]: MULTI: multi_create_instance called
Dec  3 11:46:47 fritz daemon.notice openvpn[18329]: 2.247.242.142:16974 Re-using SSL/TLS context
Dec  3 11:46:47 fritz daemon.notice openvpn[18329]: 2.247.242.142:16974 Control Channel MTU parms [ L:1541 D:166 EF:66 EB:0 ET:0 EL:0 ]
Dec  3 11:46:47 fritz daemon.notice openvpn[18329]: 2.247.242.142:16974 Data Channel MTU parms [ L:1541 D:1450 EF:41 EB:4 ET:0 EL:0 ]
Dec  3 11:46:47 fritz daemon.notice openvpn[18329]: 2.247.242.142:16974 TLS: Initial packet from [AF_INET]2.247.242.142:16974, sid=212eddd1 8480327c

Es scheint als wolle jemand ständig einen Tunnel aufbauen, ohne berechtigt zu sein. Was haltet Ihr davon? Sollte ich den OpenVPN-Port ggf. ändern oder wie wehre ich sowas ab?
 
1. Keine Panik verbreiten.

2. Die von OpenVPN verwendeten Komponenten und auch OpenVPN selbst sind zu aktualisieren. Wer arbeitet noch mit löchrigen Bibliotheken?

3. Den Rest erledigen dann ein gut konfiguriertes OpenVPN in Verbindung mit der PKI.
 
Gut, dass heisst aber Du bist auch der Meinung, dass sich da jemand zu schaffen macht?!
Die IP hat inzw. gewechselt zu
2.247.243.103
 
Ohne die passende OpenVPN-Konfiguration kann man zwar nur raten, aber wenn ich hier mal UDP als Transport-Protokoll unterstelle, dann kann man fast davon ausgehen, daß da einfach nur ein UDP-Paket eingeht (von irgendeinem Port-Scanner), das zum Starten einer neuen Instanz führt.

Eigentlich gibt es genau gegen solche "Angriffe" beim OpenVPN die Möglichkeit, einen zusätzlichen (gemeinsamen) Schlüssel zu verwenden, so daß Pakete ohne passende HMAC auf der Basis dieses gemeinsamen Wissens einfach "unter den Tisch fallen" können.

Das sieht für mich (ich kann mich auch täuschen, ich habe noch nie eine OpenVPN-Installation ohne "tls-auth" verwendet) hier irgendwie so aus, als würde auf diese Vorsichtsmaßnahme verzichtet - im Ergebnis startet eben irgendein Client mit einem UDP-Paket eine neue Instanz, die jetzt auf einen TLS-Verbindungsaufbau wartet, der entweder gar nicht stattfindet oder scheitern muß/sollte.

Ohne den passenden "tls-auth"-Key sollte ein solches "initial packet" gar nicht erst bis zum Erstellen einer neuen Instanz durchdringen - das hindert den Absender noch nicht daran, so ein Paket zu senden ... aber es wird weder akzeptiert noch protokolliert, solange es nicht die richtige Signatur trägt.

Ein kleiner kryptographischer Zusatzaufwand, der aber Angreifern das Leben erheblich erschwert, weil einfach alles ohne passende Signatur komplett verworfen werden kann und gar keine weiteren Ressourcen belegt (außer eben die Signaturprüfung, die (zusätzlich) durchgeführt werden muß).
 
Also TLS-Authentifizierung verwende ich i.V.m. dem statischen Key. UDP ist richtig erkannt.

Hier mal die Serverkonfiguration:
Code:
#  OpenVPN 2.1 Config, Mon Nov 28 23:54:15 CET 2016
proto udp
dev tun
ca /tmp/flash/openvpn/ca.crt
cert /tmp/flash/openvpn/box.crt
key /tmp/flash/openvpn/box.key
dh /tmp/flash/openvpn/dh.pem
tls-server
tls-auth /tmp/flash/openvpn/static.key 0
port xxxx
ifconfig 10.0.yy.yy 255.255.255.0
push "route-gateway 10.0.yy.yy"
topology subnet
push "topology subnet"
push "route 192.168.xx.xx 255.255.255.0"
max-clients 5
mode server
client-config-dir clients_openvpn
route 192.168.xx.xx 255.255.255.0 10.0.0.2
client-to-client
push "dhcp-option DNS 192.168.xx.xx"
tun-mtu 1500
mssfix
verb 3
cipher BF-CBC
keepalive 10 120
status /var/log/openvpn.log
cd /var/tmp/openvpn
chroot /var/tmp/openvpn
user openvpn
group openvpn
persist-tun
persist-key
 
Dann sollte auch kein Paket ohne passende Signatur "durchkommen" ... damit muß man wohl unterstellen, daß irgendein Gerät mit einem mobilen Zugang (das sind ja Telefonica-Adressen, ich tippe auf irgendein Gerät im Netz von e-plus/o2 und nicht an einem o2-Festnetzanschluß, auch wenn ich die tatsächliche Verwendung des Blocks im AS6805 nicht kenne) mit dem richtigen Key einen Verbindungsversuch beginnt, aber die Antwort der FRITZ!Box (hier bin ich, authentifiziere Dich) wohl gar nicht erhält.

Vielleicht überdenkst Du ja noch mal die Geräte, auf denen Du diesen OpenVPN-Zugang (samt statischem "auth"-Key) installiert hast ... ansonsten wechsele einfach diesen Key (natürlich auch auf den entsprechenden Clients) und dann sollte das Problem auch verschwinden.
 
Handlungsbedarf besteht nur hinsichtlich der Verwendung aktueller Komponenten von OpenVPN.

Wie man sieht wird die Absicherung des "control channel" mit "tls-auth" genutzt. Das sollte eigentlich selbstverständlich sein.

Auch die "cipher BF-CBC" kann man verwenden. Die bekannten Angriffe darauf sind ziemlich realitätsfern.
 
Tja, da kann sich der geneigte Verwender von OpenVPN jetzt aussuchen, ob er der Expertise des @grauGolz traut oder sich doch lieber auf die Warnung der OpenVPN-Macher (und der dort versammelten Community) verläßt, wenn es um Empfehlungen zum Einsatz von Blowfish im "cipher block chaining"-Mode geht: https://community.openvpn.net/openvpn/wiki/SWEET32 - aber deshalb lesen hier ja auch nur Erwachsene mit entsprechend entwickelter Medienkompetenz, die können das dann selbst einschätzen.

Wenn natürlich die Realitätsferne bereits bei "für mich interessiert sich ohnehin niemand" beginnen sollte, stellt sich ja die Frage, warum man dann überhaupt verschlüsseln sollte ... es wird in jedem Falle (selbst bei der potentesten Hard-/Software, die locker mehr als die WAN-Anbindung leisten kann) den Durchsatz negativ beeinflussen, weil zumindest die Latenz steigt, denn das Verschlüsseln benötigt auf jeder Hardware zusätzliche Zeit.
 
cipher BF-CBC:

http://www.golem.de/news/sweet32-ku...ecke-sorgen-fuer-kollisionen-1608-122887.html

Was sagt OpenVPN zu diesem "Problem"?

"If changing the cipher is not possible, for example because you don't control the server, or can not update all client configs on a short notice, you can renegotiate new keys more often.
For example, add --reneg-bytes 64000 to your config to renegatiate after every 64 megabytes."

Viel Spaß beim Brechen von BF-CBC wünscht der

grauGolz
 
Zuletzt bearbeitet:
Ja, man kann freilich auch die zweitbeste Lösung wählen ... die beginnt ja nicht umsonst mit den Worten

If changing the cipher is not possible, [...]

Der Umkehrschluß wäre

If changing the cipher is possible, don't hesitate to do it.

Aber was weiß ich denn schon ... ich wußte ja nicht einmal, daß der nach "reneg-bytes" anzugebende numerische Wert automatisch als "KBytes" interpretiert wird, entgegen allen Dokumentationen, wo immer etwas von "bytes" steht. Vielleicht beobachte ich deshalb (auch bei anderen verwendeten Algorithmen) so selten einen Schlüsselwechsel wg. des Erreichens der max. mit einem Schlüssel zu verschlüsselnden Datenmenge. Dann ergibt ja mein verwendeter Wert von 536.870.912 gar nicht die von mir erwarteten 512 MB (512 * 1024 * 1024), sondern 512 GB und die übertrage ich niemals rechtzeitig, bevor der Schlüssel seine "lifetime" überschreitet.

Dabei hätte ich aus dem Parameter "--reneg-bytes 64000" zunächst mal geschlossen, daß damit nach nicht einmal 64 KBytes übertragener Daten (2 ** 16 = 64 KB wäre dann 65536) schon ein neuer symmetrischer Schlüssel ausgehandelt würde - na ja, ich bin halt etwas einfältig und habe es tatsächlich versäumt, die Angaben in den entsprechenden Manuals auf ihre Richtigkeit und/oder Plausibilität zu prüfen.

Abgesehen davon können meinetwegen Sekundärquellen schreiben, was sie wollen (dazu gehört nun mal "golem.de") ... leider stellt man allzu oft im Nachhinein fest, daß da jemand das Thema gar nicht in vollem Umfang durchschaut hatte und wenn es nach praktikablen Angriffen für alle geht, dann kannst Du auch ganz beruhigt noch RC4 mit MD5 benutzen.

Wenn die direkte Quelle bei OpenVPN (von mir bereits verlinkt) den Verzicht auf BF-CBC empfiehlt, dann gibt es dafür Gründe ... wer es dann (nachweislich, das sollte man vermutlich zur Voraussetzung machen - zumindest plausible und eigene Erklärungen sollten dem vorausgehen) besser weiß, sollte das dann ebenfalls "an der Quelle" besser wissen und diese ggf. ändern lassen (wobei sich ja manche Quellen auch standhaft verweigern, das will ich nicht verkennen).

Mir wäre trotzdem total entgangen (und ich habe sogar extra nach "weißem Text auf weißem Hintergrund" gesucht), daß in #7 irgendetwas von einem Hinweis auf die Notwendigkeit für eine erhöhte Frequenz des Schlüsselwechsel (egal ob nach übertragener Datenmenge oder nach Zeit) gestanden hätte.
 

Neueste Beiträge

Statistik des Forums

Themen
244,695
Beiträge
2,216,690
Mitglieder
371,314
Neuestes Mitglied
Gjorstn
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.