Ergebnis 1 bis 10 von 10

Thema: Angriff über OpenVPN?

  1. #1
    IPPF-Fortgeschrittener
    Registriert seit
    26.08.2007
    Beiträge
    68

    Frage Angriff über OpenVPN?

    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?
    --
    betreute Boxen:
    1+2: Fritz!Box 7490 (FRITZ!OS 06.30-freetz-devel-13474M) - O2-VDSL50@51K
    3: Fritz!Box 7270v3 (FRITZ!OS 05.54-freetz-2.0-13058M) - UMTS-Stick
    4: Fritz!Box 7170v2 (Fritz!OS 04.xx 29.04.88-freetz-2.0-stable 12597M) - UMTS-Stick

  2. #2
    Gesperrt
    Registriert seit
    27.04.2013
    Beiträge
    271
    Verwarnungen
    0/1 (999)
    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.

  3. #3
    IPPF-Fortgeschrittener
    Registriert seit
    26.08.2007
    Beiträge
    68
    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
    --
    betreute Boxen:
    1+2: Fritz!Box 7490 (FRITZ!OS 06.30-freetz-devel-13474M) - O2-VDSL50@51K
    3: Fritz!Box 7270v3 (FRITZ!OS 05.54-freetz-2.0-13058M) - UMTS-Stick
    4: Fritz!Box 7170v2 (Fritz!OS 04.xx 29.04.88-freetz-2.0-stable 12597M) - UMTS-Stick

  4. #4
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.970
    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ß).

  5. #5
    IPPF-Fortgeschrittener
    Registriert seit
    26.08.2007
    Beiträge
    68
    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
    --
    betreute Boxen:
    1+2: Fritz!Box 7490 (FRITZ!OS 06.30-freetz-devel-13474M) - O2-VDSL50@51K
    3: Fritz!Box 7270v3 (FRITZ!OS 05.54-freetz-2.0-13058M) - UMTS-Stick
    4: Fritz!Box 7170v2 (Fritz!OS 04.xx 29.04.88-freetz-2.0-stable 12597M) - UMTS-Stick

  6. #6
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.970
    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.

  7. #7
    Gesperrt
    Registriert seit
    27.04.2013
    Beiträge
    271
    Verwarnungen
    0/1 (999)
    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.

  8. #8
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.970
    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.

  9. #9
    Gesperrt
    Registriert seit
    27.04.2013
    Beiträge
    271
    Verwarnungen
    0/1 (999)
    cipher BF-CBC:

    http://www.golem.de/news/sweet32-kur...08-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
    Geändert von grauGolz (04.12.2016 um 13:58 Uhr)

  10. #10
    IPPF Siebentausend-VIP Avatar von PeterPawn
    Registriert seit
    10.05.2006
    Ort
    Berlin
    Beiträge
    7.970
    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.

Ähnliche Themen

  1. Angriff auf meine Fritzbox
    Von Flatbury im Forum Freetz
    Antworten: 6
    Letzter Beitrag: 17.05.2012, 06:23
  2. ftp Angriff
    Von element im Forum Freetz
    Antworten: 15
    Letzter Beitrag: 11.02.2010, 12:36
  3. Angriff auf WPA verfeinert
    Von doc456 im Forum Lesestoff
    Antworten: 2
    Letzter Beitrag: 30.08.2009, 19:39
  4. Hacker Angriff auf Telekom Kunden?
    Von Timmbo im Forum Allgemeines
    Antworten: 5
    Letzter Beitrag: 29.11.2008, 21:38
  5. Antworten: 12
    Letzter Beitrag: 27.08.2006, 01:47

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •