Verbindungsabbruch bei https

Technik
1

98% der Fehler sitzen vor dem Bildschirm, daher meine Frage:
Was mache ich falsch?

Szenario:
28.06., 22:15
https://service.freifunk-muensterland.de/maps/map50/#!v:m;n:c4e984317e42
Domäne 50 - Nottuln

  • Linux und Firefox und normales http via FF null problemo.
  • Linux und Firefox und https zu webmailinterface von 1und1 via FF: Verbindungsabbruch.
  • Linux und Chromium und https zu webmailinterface von 1und1 via FF: Verbindungsabbruch.
  • Linux und Firefox/Chromium und https zu diesem Forum via FF: null problemo (was auch schon mal nicht ging, dann aber nur mit Ipad und Android nicht).
  • Gleiches client-system via privatem Wlan: null problemo bei https zur gleichen Adresse.

FF-router-Neustart: keine Änderung.

Angenommen, es läge an 1und1, da die u.U. bestimmte IPs sperren, müssten wir trotzdem aktiv werden, finde ich. Ist aber nur eine Annahme.

2

Kannst du bitte noch die Domäne ergänzen?

3

Domäne 50 - Nottuln, steht jetzt auch oben drin.

4

Ich habe ein ähnliches Verhalten auch beobachten können, als das Forum aus Domäne 46 nicht aus dem Freifunk-Netz erreichbar war. Mit Wireshark habe ich dann gesehen, dass bei Nutzung meines privaten Netzes ein “Hello” via TLS1.2 kam. Wenn man sich im Freifunk-Netz befand, dann kam das “Hello” jedoch als SSL-Paket und danach nichts mehr. Ich hab’ das dann nicht weiter verfolgt, weil das Problem verschwunden ist, aber vielleicht ist das bei dir ja ähnlich. Mir ist nur nicht ganz klar, wieso Freifunk einen Einfluss auf die Aushandlung der Verschlüsselung haben sollte.

5

Nur als Ergänzung zu Handle:
Das von dir beschriebene Szenario hatte ich per Signal damals am 22.06. bestätigt. Allerdings nur mit Android oder Ipad als client. Mit dem oben beschriebenen Linux konnte ich das Problem nicht bestätigen (am gleichen FF-Knoten).
Ob es einen klaren Zusammenhang gibt?

6

Hat es nicht.

7

Am besten mit Wireshark reinschauen, wenn du das kannst.

Und bitte Browser “frisch” starten, da die Browser State von TLS Verbindnugen behalten (Session Resumption)

8

Mache ich heute Abend. Hoffe, dass das Problem reproduzierbar sein wird. Berichte dann.
Tipp für Filter?

9

Source&Target IP

10

Problem ist aktuell nicht reproduzierbar.
Weder mit der 1und1 https-Adresse noch bei diesem Forum. Auch nicht nach absichtlichem Hin- und Herwechseln zwischen privatem Wlan und FF (und extra alle Browsercaches belassen).
Sobald es wieder auftritt, sehe ich mir die Komunikation per tcpdump/wireshark genauer an.

1 „Gefällt mir“
11

ff-1und1.png1317×162 31.4 KB

01.07.16, ca. 20 Uhr
Prozedur wie oben beschrieben, TLS-Handshake erfolgreich, dann Post der Anmeldemaske führt zu Verbindungsabbruch.
Musste das mehrfach wiederholen, um den Fehler zu reproduzieren (ca. 2 von 10 schlugen fehl).
Bin kein tcpdump-Experte, aber sieht für mich so aus, dass einige Pakete vom Server zu meinem Client nicht ankamen?
Kann ich leider nicht schlicht auf den Webseitenbetreiber 1und1 schieben, da dieses AbbruchPhänomen nicht via privatem Wlan von mir beobachtet wird.

12

Absender der TCP Resets ist 1&1 wie ich das aus dem Schnipsel raten kann.

13

ff-1und1-davor.png1332×165 12.1 KB

Hier die Kommunikation ab Formularabsendung bis zum Bild davor.
RST ist von 1und1, ja.
Er sendet dann danach aber auch 2 syn-ack, die nicht klappen (Nr. 804 und 806). Warum (erstes Bild)?

14

In dem Schnipsel werden mehrere Verbindungen korrekt aufgebaut. Wieso “nicht klappt”?

15

Ich meine die Nummern Nr. 804 und 806. Aber wie gesagt: ich bin kein tcp-Experte. Wireshark markiert die beiden mit “spurious”, was nach meiner Recherche grob timing-Problem bedeuten kann.
Die Werte in Spalte 2 deuten für mich ebenfalls darauf hin.
Beide Bilder zusammen:

ff-1und2-insgesamt.png1314×284 59.5 KB

Von meinem Client werden die RST dann ebenfalls gesendet und dann ist Ende.

16

Ich kann die tcp-resets in dom43 bestätigien. Hier kann ich leider kein pcap hochladen. Daher hier … Denke, dass da jemand auf fanlin und barristan genauer hinschauen muss …

17

Danke für die Mühe!
In deinem pcap sehe ich nur eine Zeile mit client hello und keinen RST?

18

Habe jetzt die ganze Datei hochgeladen und link oben korrigiert.

19

Interessant, entspricht eher dem Verbindungs-Verhalten wie von Handle beschrieben. RST noch vor dem SSL-Handshake.

20

@paulinsche: Woher kann das denn überhaupt kommen? Wir transportieren die Pakete doch nur? Oder blocken die vielleicht unsere IP, was aber auch wenig Sinn ergibt.