Zwei große Themenblöcke haben wir diesmal dabei:
- Clemens und ich müssen noch ein paar Krümel zusammenkehren, die in den ersten beiden Folgen noch keinen Platz gefunden haben: Zunächst klären wir, wie Router sich untereinander darüber unterhalten, wer denn den Hut auf hat. Dann kommen wir mal zu Firewalls, um dann noch den Schwenk über Load Balancer und Policy Routing zu machen und mit einem neuen ‘Schmankerl’ (s.u.) abzuschließen.
- In eigener Sache: Der Podcast-Feed produziert bei einigen von euch Fehlermeldungen. Ich habe mit Lieblingsserveradmin danimo darüber gesprochen was denn da los ist. Ich hoffe, dass wir uns dem Thema halbwegs verständlich annähern können. Vielen Dank an dieser Stelle schonmal in Richtung unserer Hörerinnen und Hörer sowie an die Entwickler*innen diverser Podcastclients für die Unterstützung. Confetti auch in Richtung des Antennapod-Teams, die das Thema am häufigsten abbekommen haben.
Schmankerl: Per SSH remote auf Router/Switch/Access Point/whatever einloggen und im Wireshark zuschauen: sudo tcpdump -i [interface] -U -w -port 22 | wireshark -i – -k
Wir freuen uns übrigens wie immer über eure Bewertungen bei iTunes!
Anna-Lena
Clemens Schrimpe
Danimo
Serveradmin RFC-Podcast
podseed.org
CDN RFC-Podcast
[shownotes mode=”block”]
| Feed | Enclosure |
|---|---|
| Podcast Feed: Request for Comments (Request for Comments (MPEG-4 AAC Audio)) | MPEG-4 AAC Audio |
| Podcast Feed: Request for Comments (Request for Comments (MP3 Audio)) | MP3 Audio |
| Podcast Feed: Request for Comments (Request for Comments (Opus Audio)) | Opus Audio |
| Podcast Feed: Request for Comments (Request for Comments (Ogg Vorbis Audio)) | Ogg Vorbis Audio |
Bin grade am verzweifeln
Nach dem Kommando
ssh root:192.168.1.200 “tcpdump -i eth0 U -w – port not 22” | wireshark -i – -k
kommt die Fehlermeldung von Wireshark:
End of file on pipe magic during open
Was will mir das sagen ?
Noch einmal riesen Dank an Clemens; Super Tipp!
So sollte der komplette Befehl so aussehen.
ssh [user]:[remoteServer] “tcpdump -i [remoteInterface] -U -w – port not 22” | wireshark -i – -k
Ich bin noch nicht ganz durch die Episode, möchte aber 2 Dinge anmerken (die nix mit AntennaPod zu tun haben xD)
Zum einen wurde gerade die “Haarnadel-Technik” besprochen und dass das auf billiger Hardware schonmal schief geht oder so. Ich habe da nämlich eine gute Erfahrung gemacht.
Zutaten:
Billig-Plasterouter von technikcolor, bereit gestellt von Unitymedia
Pidgin auf Windows
Pidgin auf Linux
Beide Pidgin im gleichen LAN aber verbunden über 2 unterschiedliche XMPP-Provider
Wenn man mit XMPP/Jabber nun Binärdaten versenden will, dann passiert das in der Regel p2p (die Server vermitteln das nur) und mit der Jingle-Erweiterung. Und wenn ich nun vom Linux-pidgin auf das Windows-Pidgin mal eben ein paar Gigabyte rüber schiebe, so geht das reichlich flott. Also so flott, dass diese Packete nie das Internet gesehen haben können, sondern schön zügig durchs Gigabit-LAN rauschen.
Die XMPP-Server **können** aber nur vermittelt haben, dass 23.23.23.23:9876 mit 23.23.23.23:9875 reden will.
Also muss mein billiger Plastiktouter das Problem doch gelöst haben oder?
Zum anderen kam mir am Anfang der Sendung eine äh fixe Idee wie man außerordentlich simpel loadbalancing und Redundanz bei 2 Internetverbindungen erledigen kann, man sendet einfach konsequent gleichmäßig an beide Interfaces, so ein Packet (oder ein Flow) links, eins rechts und alles was nicht ankommt versucht man eben nochmal und verteilt es dann wieder links und rechts.
Das hieße doch in “Friedenszeiten” habe ich eine schön gleichmäßige Belastung und wenn eine Verbindung ausfällt hab ich halt 50% packetloss, aber ich probe auch ständig ob die andere Verbindung nochmal wieder kommt.
Wie gesagt, ich spinne nur so rum.
Antwort kommt noch per Mail. ;)
Clemens meinte vor ein paar Folgen mal, das er auf den UBNT EdgeRoutern die Routing-Engine austauscht. Weiss jemand auf was man da tauschen kann?
Wann soll er das in etwa gesagt haben ? Findest du die Stelle wieder ??
möglicherweise das hier: https://community.ubnt.com/t5/EdgeMAX-Stories/EdgeRouter-as-BGP-router/cns-p/1716321 ?
FYI, die Folge ist bei mir (Android 7.0) ueberraschend im AntennaPod aufgetaucht. Scheint also zu funktionieren … (Update auf 7.1.1 fuer mein Handy ist wohl in den Startloechern, manche Weltregionen habens schon, andre nicht .. meh – ich werd auch nie verstehen wieso mein Fucking Netzprovider da was mitzureden hat, wenn ich das Handy gar nicht bei ihm gekauft hab. Es gibt naemlich Faelle, wo man das Update schneller kriegt, wenn man die SimCard aus dem Handy rauszieht. Ganz toll.)
Danke für das Feedback!
Kurze Randnotiz zum Mondkalender:
Ostern ist am jüdischen Pessachfest. Darum die Ausrichtung von Ostern am 1. Vollmond im Frühling.
Die folgenden Abstände berechnen sich aus dem neuen Testatment und den Schilderungen darin. Christi Himmelfahrt fand 40 Tage nach Ostern statt, darum ist es immer ein Donnerstag.
Pfingsten ist 50 Tage nach Ostern, bzw. eig. 10 Tage nach der Himmelfahrt Christi.
Bundeseinheitlich sind die Feiertage, da die katholische und die protestantischen Kirchen diese Tage nicht unterschiedlich zählen und es darum keine Konflikte zwischen protestantischen und katholischen Gebieten gibt. Alle anderen (regionalen) Friertage sind entweder katholische oder protestantische Feiertage.
Falls sich jemand für die genaue Berechnung von variablen Feiertagen interessiert:
https://de.wikipedia.org/wiki/Gau%C3%9Fsche_Osterformel
Hallo und vielen Dank für Euer Engagement!
Wieso nur Android 7.0?
Auf Android 4.1.2 tut Antennapod auch bloß nicht.
Udates von der Weltfirma SAMSUNG? Muuuuhahahaha. Zum Abspielen von Podcasts tut das alte 7 Zoll WiFi only Tablet. Es lädt sogar den einen oder anderen Feed. Apple = Man ist nicht Herr im eigenen Haus. Android = Man ist nicht Herr im eigenen Haus und bekommt keine Instandhaltung (ohne durch Reifen zu springen).
:-)
Wie du hier siehst (https://www.ssllabs.com/ssltest/analyze.html?d=requestforcomments.de&s=2a01%3a4f8%3a172%3a24d4%3a1%3a0%3a0%3a100&latest) ist das der Protokoll-Kompatibilitaet geschuldet: Ich habe vor geraumer Zeit den Support fuer TLS 1.0 deaktiviert, weil Mottenkiste.
Android 4.x ist nichts, was man im GBI (“Grossen Boesen Internet”) benutzen sollte. Auch nicht zum Podcast hoeren, denn es gibt mehrere Exploits. Auf die Schnelle gefunden habe ich:
http://www.cvedetails.com/cve/CVE-2015-3879/
http://www.cvedetails.com/cve/CVE-2016-3913/
Wenn du unseren Dateien und deinem Mediaplayer traust, kannst du natuerlich weiter per Chrome runterladen und dann hoeren, aber mit Apps, die nicht wie Chrome das halbe Userland als Neuimplementierung mitliefern (und die Programmierer dabei genau wissen, was sie tun), waere ich vorsichtig — es gibt mehr CVEs gegen andere Features von Chrome, die Apps ueber APIs ansteuern. Dazu muss der App-Autor noch nicht mal boese Absichten haben.
Samsung wird bezogen auf Updates wohl besser (https://www.sammobile.com/2016/12/08/samsung-update-policy-improving/), aber Updates fuer alte Devices wirds wohl nicht mehr geben. Eventuell mal mit Lineage OS probieren? Rooten ist ggf. das kleinere Uebel.
Hallo Danimo,
leider bin ich bis heute noch keine funktionierende Methode gefunden bei meinem alte S4 Model SGH-I337 unter 4.4.2 root und den Bootloader freizuschalten. Irgend etwas hat AT&T da anders als bei den anderen S4 gemacht.
Solltest Du jemanden kennen der mir einen Zielführenden Tipp geben kann wie ich ein Linage OS installiert bekomme wäre ich Dir sehr verbunden.
Funktionierende Hardware deshalb wegzuwerfen, weil der Hersteller der Meinung ist das man sie nur wenige Jahre lang nutzen sollte, ist eine Einstellung der ich mich nicht anschließen möchte.
Zum Schmankerl: Der Command passt aber nicht so ganz, ich hab das mal ein bisschen verfeinert:
SSH_USER=root && \
SSH_HOST=test.example.com && \
SSH_PORT=22 && \
INTERFACE=eth0 && \
ssh -p ${SSH_PORT} ${SSH_USER}@${SSH_HOST} tcpdump -i ${INTERFACE} -U -w – port not ${SSH_PORT} | wireshark -i – -k
(Getestet auf macOS mit standard Shell und standard Wireshark)
PS: Danke Clemens für den Tipp, ich war bisher immer am tcpdump in der Shell zugucken.
mmh bei mir kriege ich lieder nur die Antwort, daß das Interface “-” nicht existiert (macOS 10.12.5 Wireshark 2.2.7) Schade…
Das Kommando in den Shownotes oben müsste folgendermaßen heißen:
sudo tcpdump -i [interface] -U -w - port not 22 | wireshark -i - -kSprich: Space zwischen Minus und port, und ein zusätzliches “not” im capture filter. Außerden nur “normale” Minuszeichen verwenden, keine Gedankenstriche.
zum TLS Problem, andere Podcast haben dieses Problem nicht, weil sie neben der ECC (Elliptic curve cryptography) auch noch normale RSA Kryptografie verwenden.
In der Aftershow hörte sich das so an, also ob TLS1.2 nur mit EC Chiffren funktioniert und alle anderen vorboten sind. Das ist nicht der Fall! Ungewöhnlich ist schon eher einen Webserver zu betreiben der nur ECC verwendet.
Es spricht normalerweise überhaupt nichts dagegen, eine Chiffre wie „DHE-RSA-AES256-GCM-SHA384“ zu aktiveren. Das ist auch in keiner Form ein Downgrade. Durch den Diffie-Hellman-Schlüsselaustausch gibt es Forward Secrecy und mit einem nicht zu klein gewählten DH Parameter ist es so sicher wie mit ECC. Besonders da es unterschiedliche Meinungen über die Qualität von vielen Elliptischen Kurven gibt, übrigens auch zu der secp384r1, die dieser Server einsetzt. Diese Kurve kommt aus der selben Familie wie secp256r1.
Würden DHE-RSA Chiffren auf dem Server aktiviert, könnten alle Systeme die kein secp384r1 sprechen wollen auf diese Chiffre zurückfallen und trotzdem sicher mit requestforcomments kommunizieren.
Da aber Danimo ziemlich deutlich gesagt hat, dass er nichts daran ändern möchte, bleiben nur andere Lösungen. Eine die in der Aftershow nicht genannt wurde, ist ein Proxy zu verwenden. Jeder der irgendwo einen eigenen Server hat kann sehr einfach einen Reverse proxy für die Feed URL konfigurieren. Da der Download über ein CDN läuft und die Shownots meist über ein Webview dargestellt werden muss der Feed noch nicht einmal modifiziert werden. Im Podcast Client muss nur eine andere URL eingetragen werden. Ist vielleicht einfacher für alle die zugriff auf einen Server haben und nicht Java programmieren können.
Zum TLS-Problem: Man kann sowohl bei aktuellen nginx-Versionen als auch bei aktuellen Apache-Versionen mehrere Kurven für für ECDHE-Ciphersuites angeben, und dabei auch ne Reihenfolge angeben.
Wenn man schon OpenSSL 1.1 auf dem Server hat, kann man sogar schon X25519 für die Schlüsselaushandlung nehmen (man muss da nur auf die Groß-/Kleinschreibung achten, das X muss groß geschrieben sein).
Für nginx >= 1.11.0 mit OpenSSL >= 1.0.2 wäre die entsprechende Konfigurationsdirektive:
ssl_ecdh_curve secp521r1:secp384r1:prime256v1;
Für Apache >= 2.4.8 mit OpenSSL >= 1.0.2:
SSLOpenSSLConfCmd Curves secp521r1:secp384r1:prime256v1
Wenn man OpenSSL >= 1.1 (*nicht* 1.0.1!) hat, würde ich folgendes empfehlen:
ssl_ecdh_curve X25519:secp521r1:secp384r1:prime256v1;
bzw.
SSLOpenSSLConfCmd Curves X25519:secp521r1:secp384r1:prime256v1
Soweit ich das sehe, läuft der Server unter Debian 8 – nen hinreichend aktuellen nginx gibt’s bislang in den offiziellen Debian-Repos leider nur für Debian Sid. Würde der Server unter Ubuntu laufen, könnte man das PPA hier verwenden:
https://launchpad.net/~nginx/+archive/ubuntu/stable
Carsten: An der Stelle, wo das Problem auftritt, will man kein RSA. Es geht *nicht* um die ECDSA-Signatur des TLS-Zertifikats, sondern um die Schlüsselaushandlung. Der Server verwendet ohnehin schon ein Zertifikat mit RSA-Schlüsselpaar (könnte man IMHO auch gleich auf secp384r1 umstellen – Let’s Encrypt lässt da neben RSA jedenfalls auch secp256r1 und secp384r1 zu).
Das Problem, um das es hier geht, ist aber nicht das Zertifikat, sondern die Schlüsselaushandlung. Da *kann* man zwar auch RSA verwenden, aber das will man nicht, weil man dann keine Perfect Forward Secrecy mehr hat. Stattdessen will man in der Praxis ECDHE (bei älteren OpenSSL-Versionen mitunter auch “EECDH” genannt), oder als Fallback vielleicht noch “normales” DHE (“normales” DHE ohne elliptische Kurven verursacht aber deutlich mehr CPU-Last als ECDHE, und hat in der Praxis sehr viel mehr Fallstricke, weil man dann eigentlich auch noch ne eigene DH-Gruppe erzeugen und auf dem Server einrichten muss, wenn man seinen Job richtig macht).
Das Problem hier ist, dass *eigentlich* alle TLS-Stacks, die in irgend einer elliptische Kurven unterstützen, immer *mindestens* secp256r1 und secp384r1 implementieren. Das ergibt sich schlicht daraus, dass die “NSA Suite B” diese beiden Kurven als Mindeststandard vorschreibt (für ein Sicherheitsniveau von 128 Bit symmetrischer Verschlüsselung wird dort secp256r1 vorgeschrieben, für ein Niveau von 192 Bit entsprechend secp384r1). Es gibt dazu auch zwei RFCs:
https://tools.ietf.org/html/rfc5430 (veraltet, wurde durch RFC 6460 ersetzt)
https://tools.ietf.org/html/rfc6460 (aktuell)
Diese beiden Kurven sind der Mindeststandard, wenn ein TLS-Stack elliptische Kurven unterstützt. Manche TLS-Stacks (insbesondere OpenSSL) unterstützen allerdings noch dutzende weitere Kurven, aber die üblichen Browser unterstützen diese Kurven (aus guten Gründen) nicht. Konkret sieht es aktuell so aus:
Firefox: X25519, secp256r1, secp384r1, secp521r1
Chrome: X25519, secp256r1, secp384r1, bis vor ein oder zwei Jahren auch secp521r1.
Windows/InternetExplorer/Edge: secp256r1, secp384r1.
Bei Opera/Vivaldi weiß ich’s nicht genau, aber es würde mich wundern, wenn der mehr Kurven als Firefox unterstützen würde.
Das oben erwähnte X25519 ist dabei ne relativ neue Entwicklung, die insbesondere auf älteren Android-Gurken noch nicht unterstützt wird. vom Sicherheitsniveau her sollte das theoretisch gleichauf mit secp256r1 liegen, aber die Kurve lässt sich sehr viel schneller berechnen und ist explizit darauf ausgelegt, möglichst einfach und sicher zu implementieren zu sein. Die ganzen anderen Kurven bieten in der Praxis nämlich leider zig Möglichkeiten, sich in den Fuß zu schießen (insbesondere was die Anfälligkeit für Seitenkanalangriffe angeht).
//EDIT: Damit wir von der gleichen Sache reden:
https://www.ssllabs.com/ssltest/analyze.html?d=requestforcomments.de
Das Problem ist die Zeile “Supported EC Named Curves”, wo nur “secp384r1” steht.
Zum Vergleich mal, wie das mit aktuellem nginx und aktuellem OpenSSL aussehen kann:
https://www.ssllabs.com/ssltest/analyze.html?d=hardfalcon.net
(Ja, da steht auch kein secp256r1 drin, aber das könnte man dort problemlos eintragen. Dass ich kein secp256r1 haben will, ist ne bewusste Entscheidung von mir als Admin.)
Hallo Pascal!
Danke. Das man mehrere Curves angeben kann, scheint neu zu sein, oder ich habe mich gewaltig vertan, als ich das probiert habe.
Wie dem auch sei: Ich hab jetzt mal das ohnehin geplante Stretch-Update gemacht und bei der Gelegenheit auch gleich wieder auf mainline gewechselt, Certs mit OCSP-Must-Staple policy generiert und vor allem deine Curves eingetragen. Die secp256r1 als Fallback betrachte ich als temporaer vertretbar, wuerde trotzdem aber gerne mittelfristig einen Workaround fuer den Android-SSL Stack sehen.
Mag mal jemand mit Android 7.0.0 testen?
Von Must-Staple würde ich bislang eher abraten (auch wenn ich es selber auf einigen Seiten/Servern einsetze). Der Grund ist, dass die Implementierung für OCSP-Stapling sowohl bei Apache als auch bei nginx mit “klapprig” noch sehr wohlwollend umschrieben ist – insbesondere wird da in der Praxis entweder gar nichts gecached, oder der Cache ist völlig unbrauchbar:
https://blog.crashed.org/nginx-stapling-busted/
https://blog.hboeck.de/archives/886-The-Problem-with-OCSP-Stapling-and-Must-Staple-and-why-Certificate-Revocation-is-still-broken.html
Und keine Sorge, die nginx-Entwickler scheinen nicht vorzuhaben, das zu fixen:
https://trac.nginx.org/nginx/ticket/990
Selbst durfte ich das kürzlich bei nem zweitägigen Ausfall der OCSP-Responder von Let’s Encrypt am eigenen Leib erleben, wo meine Seiten dann in Firefox gar nicht mehr funktioniert haben (Chrome/Chromium ignoriert OCSP bislang komplett, inkl. Must-Staple).
Ich meine kürzlich irgendwo gelesen zu haben, dass zumindest die Apache-Leute den Let’s-Encrypt-Vorfall zum Anlass nehmen wollen, ihre OCSP-Stapling-Implementierung zu verbessern – leider finde ich das aber grade nicht wieder.
Angeblich soll die Implementierung von OCSP-Stapling bei Caddy besser sein, aber ich habe das selber noch nicht getestet und kann daher keine Aussage dazu treffen.
https://caddyserver.com/
Ja, die Problematiken rund um Stapling sind mir bekannt. Ich mache daher nach jedem Server nginx restart erstmal per Script ein paar Dummy curl’s auf meine Domains (n = Anzahl Worker-Prozesse). Schoen ist aber wirklich anders. Den Wunsch, parallel RSA und ECDSA anbieten zu wollen habe ich (derzeit) noch nicht.
Von den Implementierungsproblemen abgesehen bin ich mir auch nicht sicher, ob OCSP stapling angesichts der relativ langen Cache-Zeiten sinnvoll ist. Ich hab es bislang noch nicht probiert und erst jetzt entdeckt, dass LE das entsprechende Property im Certificate Request honoriert. Da bin ich neugierig geworden.
Was die OCSP-Server-Outage bei LE angeht: Die war bei Firefox auch ohne Stapling problematisch. Hier haette Stapling sogar geholfen, eben weil die Tickets vergleichsweise lange gueltig sind und der Browser so nicht beim OCSP-Server direkt anfragen (und failen) wuerde.
Sollte mir das auf die Fuesse fallen, beantrage ich notfalls kurzfristig neue Certs ohne Stapling. Is natuerlich Pech, wenn die LE Infrastruktur komplett zusammenklappt, aber Risiko nehme ich erstmal auf mich.
Unter Android 7.0 im Podcast App Addict läuft der Feed jetzt ohne Probleme. Danke für deine Mühe