AG:Technik/Protokolle/Meeting 2013-12-04
| Arbeitsgruppe |
| Technik |
|---|
Protokoll der letzten Sitzung im Wiki:
http://wiki.piratenpartei.at/wiki/AG:Technik/Protokolle/Meeting_2013-11-27
Dieses Protokoll im Wiki:
http://wiki.piratenpartei.at/wiki/AG:Technik/Protokolle/Meeting_2013-12-04
Beginn: 04.12.2013 - 18:00 Uhr
Ende: 04.12.2013 - 20:00 uhr
Anwesend:
- considerator
- burns
Gäste:
Inhaltsverzeichnis |
Agendapunkte
Reverseproxy / HTTPS
Vilinthril: https://www.ssllabs.com/ssltest/analyze.html?d=piratenpartei.at Wir haben hier zwar ein A (yay!), aber in zwei Kategorien 90%, in einer 80%. Kann man da noch was nachbessern?
considerator: rein optisch ja - der 80-er ist der default key bei DHE key exchange - 1024 bit. wird in unserer Konfiguration meines wissens nur schlagend bei eher exotischen Konfigurationen. Laut ssllabs wäre das bei bing-bot, java & openssl der Fall. Soweit ich weiss hat unter anderem Redhat/Fedora meist keine ecdhe ciphers und wäre auch betroffen. eine Verbesserung in dem bereich ist wieder einmal win/lose - viele clients akzeptieren auch keinen 4096 bit DHE key exchage. (Hier ist echt die Frage welche betroffenen clients können profitieren und welche länge wird dort akzeptiert?) - windows kommt laut "google" zumindest bis win7 nicht zurande, allerdings gibt es da in der Regel ECDHE. Java erst ab 7.0.24. Wie üblich sollte die performance des key exchange mit der länge skalieren - gerade DHE ist langsam! die 90 bei protocol support bezieht sich auf ssl3 - sollte nur bei ie6@WinXP/SP3 relevant sein. Ältere WinXP versionen scheitern ohnehin am sha256 hash des Zertifikats (etwa SP2). Das Problem betrifft übrigens praktisch alle außer mozilla basierte browser - auch chrome... Sicherheitstechnisch problematischer ist eher RC4 - auf WinXP aber kaum zu vermeiden. Über 95 funktioniert nur mehr bei eher exotischen (top aktuellen) Clients Bei Cipher Strength wird es noch schwieriger - das scheint sich laut dokumentation auf die "bits" der verschlüsselung zu beziehen. 90 heißt, dass <256 angeboten werden. aktuell scheint 256 aes gcm + tls1.2 in kombination überhaupt nicht möglich zu sein.
considerator: EINE echte Verbesserung habe ich noch gefunden - das intermediate CA cert ist noch die sha1 Version. Das wäre tauschbar, macht den ssl handshake eben etwas aufwändiger. Der Key exchange wäre verbesserbar - solte aber vorher besser auf betroffenen linux distributionen getestet werden Vermutlich 2048 oder 4096 bit problemlos, das java Problem oder bing ist glaube ich vernachlässigbar. Sicherheitstechnisch problematischer dürfte das mit RC4 sein, auf WinXP und diversen legacy Systemen gibt es aber keine wirklich bessere Alternative. Hier ist nur die Wahl aussperren oder minderwertige Verschlüsselung. Sofern der client etwas besseres unterstützt wird normalerweise ohnehin etwas besseres verwendet. So sieht das in etwa aus: https://www.ssllabs.com/ssltest/analyze.html?d=test.piratenpartei.at (wobei die aktuelle version, siehe oben, nur eher exotische Konfigurationen ausschließt, vor allem nur solche, die ohnehin nicht mit dem Zertifikat kompatible sind. Hier sind es etwas mehr)
forum
Übernahme der forum administartion durch menodoros
piratepad
considerator: Genauer: etherpad lite - das neue etherpad. Das piratepad ist an sich das alte etherpad... Letzter Versuch ist vor ein paar Wochen an einem zu diesen Zeitpunkt gerade aktuellen Bug im "stable" von node.js (Installation mit der version unmöglich) Hauptproblem ist angeblich stabilität und die IO auf der Festplatte - konnte ich bisher nicht selbst testen.
alter Wiki
considerator: Weil es gerade in letzter Zeit immer wieder gefragt wird: Der alte Bundeswiki (Herbst 2012 und früher), da gibt es theoretisch ein beschädigtes image, ich habe es allerdings selbst nie zur Verfügung gehabt. Der alte Wiki der salzburger LO, der zeitweise als der Bundeswiki verwendet wurde ist die Basis des aktuellen Bundeswiki. Ich habe seinerzeit die gesamte Datenbank und das upload Verzeichnis auf unseren Server migriert, danach leitete der salzburger Wiki alle zugriffe auf den Bundeswiki um. Seither ist der Bundeswiki noch ein paar mal migriert und upgedated und upgraded worden, sonst ist es aber noch immer der selbe Mediawiki.
Kalender
burns: Wunsch, dass zukünftige AG Technik Termine im Piratenkalender eingetragen werden (Homepage) considerator: Wäre vermutlich eine gute Idee, in der Praxis sind aber midestens die hälfte der Termine quasi ohne Teilnehmer (schau bei den Protokollen im Wiki nach. Theoretisch war seit vielen Monaten wöchentlich eine Sitzung... burns: Ja gut das kann sein... Ist aber eher ein Thema der Aktivität nicht? Ich denke auch selbst wenn niemand kommt (zumindest die letzten drei Sitzung hab ich vorbei geschaut da war mal zumindest irgendjemand) sollten Termine angekündigt werden denkst du nicht? Es ist halt eine Frage der 'Konsequenz' - ohne welche ich denke es immer schwierig bleiben wird sich gut zu organisierne, vor allem als Internet-Partei... considerator: Bis jetzt steht der Termin zwar immer im Wiki, aber auf einem Platz (im Kalender) ist besser. Das ist eigentlich noch ein Relikt aus der Anfangszeit - April 2012. (noch vor dem Vorgänger der aktuellen Bundesseite - das war die, mit der bewegeten javascript welle/schifff am unteren Rand.) burns: Kalender auf der HP hätte halt auch den Vorteil, dass man Termine bei denen schon vorher klar ist, dass keiner vom Kernteam Zeit hat, abgesagt/gelöscht werden können... considerator: Bezweifle ich. Ich habe nie vorher gewusst, ob ich nicht allein herumgewartet habe. Nach der definition wären trotzdem fast alle geblieben - ich bin bei vielleicht 5 im letzten Jahr absehbar ausgefallen.
--- nächster Sitzungstermin: Mittwoch, 11. 12. 2013 https://ppoe.piratenpad.de/AG-Tech-2013-12-11
