Archive for the ‘Server-Software’ Category
PHP 7.3.0 RC 4: Performanceboost und bitte testen!
Vor 3 Tagen ist der nach Plan drittletzte Release-Candidate von PHP 7.3 erschienen: RC4. Es wird noch einen RC5 und RC6 geben, bevor hoffentlich pünktlich zu Nikolaus am 06.12.2018 das finale PHP 7.3.0 GA erscheinen wird.
Es ist also höchste Zeit, dem PHP-Team dabei zu helfen, Bugs zu finden. Eigentlich sollte man das schon früher getan haben, aber besser spät als nie!
PHP 7.3 bringt erstaunliche Performanceverbesserungen im Bereich des Garbage-Collectors. Früher konnte man einiges an Performance gewinnen, indem man stellenweise den Garbage-Collector deaktiviert. Vor allem wenn mit vielen Objekten gearbeitet wird, hat das Deaktivieren einiges an Performance gebracht (teilweise >70%, siehe DomPDF oder Composer). Mit PHP 7.3 ist das nicht mehr nötig, man bekommt die Performanceverbesserungen frei Haus, man muss den GC nicht mehr deaktivieren. Gratis Performanceboost ohne eine Zeile Code zu ändern!
Selbst kompilieren
Also los, wir kompilieren PHP 7.3.0 RC4 selbst, in diesem Fall auf einem Ubuntu 18.04 Server. Damit es nicht langweilig wird, nehmen wir diverse Extensions mit dazu, ihr nehmt am besten eure, die ihr so braucht für eure Applikationen. Weiterlesen »
TLS 1.0/1.1 Abschaltung: Eigene Versionsverteilung herausfinden und serverseitig abschalten
Browserhersteller planen, ab 2020 die TLS-Versionen 1.0 und 1.1 nicht mehr zu unterstützen:
https://www.heise.de/security/meldung/Verschluesselung-im-Web-Chrome-Firefox-Co-verabschieden-sich-von-TLS-1-0-1-1-4191864.html
https://www.golem.de/news/https-browser-wollen-alte-tls-versionen-2020-abschalten-1810-137135.html
Mit den richtigen Einstellungen und Ciphers ist TLS 1.0 noch sicher zu betreiben, aber man muss es eben richtig konfigurieren, wenn man alles beachten will: BEAST, POODLE, Sloth, DROWN, CRIME und BREACH, RC4, MD5, ROBOT, Sweet32, Bleichenbacher, Heartbleed, FREAK und Logjam, …
Da es schon ein Dutzend Probleme gab in den letzten Jahren, möchte man sich des Problems lieber früher als später entledigen, gern bevor es zum großen Knall kommt. TLS 1.2 ist nicht gegen all diese Probleme gewappnet, man muss nach wie vor aufpassen wie man die Ciphers konfiguriert. Aber man kann weniger Fehler machen. Und das Ziel ist es, TLS 1.3 zu nutzen, wo all dieses Probleme gelöst sind, da alles unsichere radikal entfernt wurde, und nicht mehr 100 Ciphers zur Auswahl stehen, sondern nur noch eine Handvoll. Weniger Auswahl ist eben manchmal besser.
Ich schrieb 2014 über die Abschaltung von SSLv3, und im Dezember 2017 darüber, dass ab dem 30. Juni 2018 im Kreditkarten-/Payment-Bereich TLS 1.2 als Minimum genutzt werden muss.
PHP, curl und TLS 1.2 als Minimum
TLS 1.2 ist im Payment-Bereich weiter auf dem Vormarsch, immer mehr Zahlungsanbieter setzen TLS 1.2 als Minimumversion fest. Das Payment Card Industry Security Standards Council (PCI SSC) hat die Frist von 2016 auf 2018 verschoben. PayPal wird am 30. Juni 2018 TLS 1.0 und 1.1 abschalten. Paysafecard wird selbiges bereits im Februar 2018 tun.
Wer einen Zahlungsanbieter eingebunden hat, und deren API nutzt, sollte baldmöglichst prüfen ob seine Systeme TLS 1.2 beherrschen. Für halbwegs aktuelle Systeme sollte das gelten, Ubuntu 14.04 geht so gerade noch. Doch seht selbst.
Folgendes Script testet die TLS-Einstellungen von PHP (curl) mit Hilfe der Webseite https://www.howsmyssl.com:
<?php $ch = curl_init('https://www.howsmyssl.com/a/check'); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $data = curl_exec($ch); curl_close($ch); $json = json_decode($data); var_dump($json);
Die Ergebnisse:
Blog mittels Let’s Encrypt dauerhaft via SSL erreichbar
Nach einer viel zu langen Pause habe ich wieder etwas Luft für meinen Blog. Endlich…
Ein Kommentar von YamYamL hat mich daran erinnert, die HTTPS-Umstellung meiner Domain endlich abzuschliessen, und noch einen Endspurt einzulegen, die Domain verschlüsselt erreichbar zu machen.
Wäre hier nur ein einfaches WordPress-Blog gehostet, wäre es vermutlich eine Sache von einer Stunde gewesen. Ein Zertifikat besorgen, WordPress umkonfigurieren (Einstellungen -> Allgemein), und alle selbst gehosteten Bilder in den Posts in der Datenbank ändern von http://www.phpgangsta.de auf https://www.phpgangsta.de (ich habe das WordPress-Plugin Better Search & Replace genutzt). Aber…
Leider ist unter phpgangsta.de nicht nur dieser Blog erreichbar, sondern auch zig andere Projekte, selbst geschriebenes Zeug, teils 10 Jahre alt, und nicht HTTPS-fähig. Es ist also doch etwas mehr Arbeit gewesen, als „nur“ den Blog auf HTTPS umzustellen.
Der Port 443 war bereits seit langem offen, aber mit einem selbst signierten Zertifikat versehen. Da ich gern Let’s Encrypt (LE) verwende, LE aber keine Wildcards erlaubt (dann wäre es verhältnismäßig einfach gewesen, einfach für alle Subdomains ein zentrales Zertifikat zu hinterlegen), musste ich mein Domain-Verwaltungs-Reseller-Tool froxlor, das ich hier laufen habe, erstmal updaten auf eine Version, die LE unterstützt, so dass ich nun für einzelne Subdomains SSL aktivieren kann, und die Zertifikate auch via Cronjob immer brav erneuert werden.
Nicht vergessen darf man: In den Google Webmaster-Tools eine neue Property anlegen, den WordPress-Cache zu leeren falls man ein Cache-Plugin verwendet, Analytics umzustellen falls man es verwendet, und alle WordPress-Plugins prüfen dass sie HTTPS-fähig sind (bei mir waren sie das anscheinend dankenswerterweise).
Ich hoffe ich habe die meisten Mixed-Content-Probleme gelöst, könnte sein dass es noch irgendwo externen Content gibt (Bilder), der noch via HTTP eingebunden ist. Meldet ihn gern bei mir, sollte das Bild via HTTPS erreichbar sein, fixe ich das schnell, oder lade es auf meinen Space.
All in All durchaus einiges an Aufwand in den letzten Tagen und Wochen, aber seit heute ist der Blog nun via HTTPS verfügbar, incl. Let’s Encrypt Zertifikat, HTTP->HTTPS Weiterleitung und HSTS Header. Diverse Subdomains und andere (kleinere) Domains muss ich in den nächsten Wochen nach und nach umstellen, das kann noch etwas dauern.
SSLv3: Uralt, bröckelig, abschalten!
[EDIT] Tja, da schreibt man gerade drüber und ein paar Minuten später wird die Lücke veröffentlicht: Poodle . Details im Google Blog. Das Problem liegt im SSLv3 Protokoll selbst, es wird keine Patches geben, es muss ausgeschaltet werden. Eigentlich wäre nur uralt-Software wie der IE6 unter WindowsXP betroffen, aber durch Downgrade-Attacken die bei TLS möglich sind, sind alle betroffen und können auf das schwache SSLv3 downgegraded werden wenn es denn auf Server+Client unterstützt wird. Also abschalten!
Seit 2 Tagen gibt es Gerüchte über eine kritische Lücke in SSLv3. Aktuell (Mitternacht) ist noch nichts publik geworden außer ein eventuell interessanter Patch von Microsoft, und eine Falschmeldung eines OpenBSD-Patches, der in Wirklichkeit schon einige Monate alt ist.
Sicher ist dass SSLv3 18 Jahr alt ist, und vor 15 Jahren durch TLSv1.0 abgelöst wurde. Bei mail.de haben wir SSLv3 bereits vor einigen Monaten deaktiviert auf den Webseiten da kaum ein Client dieses alte Protokoll benutzte außer der IE6 auf WindowsXP Systemen. Da wir den IE6 eh schon lange nicht mehr unterstützen war es sehr einfach, SSLv3 abzuschalten.
Für die anderen Protokolle wie IMAP, POP3 und SMTP haben wir SSLv3 allerdings noch aktiviert gelassen da es noch diverse E-Mail-Clients gibt die TLS >1.0 noch nicht beherrschen. Auch einige ältere Smartphones beherrschen noch kein TLS1.0 oder neuer, sodass es Sinn machte es noch aktiviert zu lassen, denn es gab auch (noch) keine bekannten Angriffsvektoren.