PHP Gangsta – Der PHP Blog mit Praxisbezug

PHP 7.4.0 RC 5: Selbst kompilieren und testen

Michael Kliewe — Mon, 04 Nov 2019 20:15:25 +0000

Letzte Woche Donnerstag ist der nach Plan fünfte Release-Candidate von PHP 7.4 erschienen: RC5. Es wird noch einen weiteren Release-Candidate geben, bevor hoffentlich am 28. November 2019 das finale PHP 7.4.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.4 bringt einige interessante neue Features (Array Spread Operator, Typed Properties, Preloading, FFI, Improved Type Variance, Arrow Functions, …), aber auch wieder ein paar Prozent mehr Performance. Eine komplette Liste aller neuen Funktionen, Änderungen, Deprecations, backwards-incompatible Changes etc. befindet sich in der UPGRADING Datei.

Selbst kompilieren

Um die PHP Tests durchlaufen zu lassen, kompilieren wir PHP 7.4 RC5 selbst. Natürlich kann das dann entstandene PHP auch genutzt werden, beispielsweise um die PHPUnit Tests seiner Projekte durchlaufen zu lassen, oder mal einen Test-Webserver zu konfigurieren (Apache, PHP-FPM).

cd /tmp
wget https://downloads.php.net/~derick/php-7.4.0RC5.tar.gz
tar -xzvf php-7.4.0RC5.tar.gz
cd php-7.4.0RC5/
./configure --prefix=/usr/local/php7.4.0rc5 --with-zlib --with-config-file-path=/usr/local/php7.4.0rc5/etc --enable-mbstring --with-zip --with-imap --with-kerberos --with-imap-ssl --with-openssl --enable-gd --with-gettext --enable-ftp --with-pspell --with-curl
make
make test

Falls beim configure Fehler auftreten, guckt unten in der Liste am Ende dieses Artikels, da habe ich die aufgeschrieben, die bei mir aufgetreten sind. Es fehlten Developer-Pakete zum Kompilieren einiger Features und/oder Extensions.

Im Gegensatz zu alten configure-Befehlen hat sich etwas geändert:

früher:
 --enable-zip
 Seit 7.4:
 --with-zip

 früher:
 --with-gd
 Seit 7.4
 --enable-gd

Am Ende des „make test“-Durchlaufs der über 12.300 Tests erhaltet ihr das Ergebnis. Falls Fehler aufgetreten sind, könnt ihr den Fehlerbericht direkt an das QA-Team schicken indem ihr Y drückt und eure E-Mail-Adresse eingebt zwecks eventueller Rückfragen. Eine Liste aller fehlgeschlagenen Tests von allen Testern gibt es auf qa.php.net.

Bei mir sind beispielsweise 3 Tests fehlgeschlagen:

=====================================================================
FAILED TEST SUMMARY
---------------------------------------------------------------------
Bug #61948 (CURLOPT_COOKIEFILE '' raises open_basedir restriction) [ext/curl/tests/bug61948-unix.phpt]
Bug #41655 (open_basedir bypass via glob()) 1/2 [ext/standard/tests/file/bug41655_1.phpt]
Test glob() function: ensure no platform difference, variation 3 [ext/standard/tests/file/glob_variation5.phpt]
=====================================================================

Nach „make“ bzw. „make test“ kann PHP genutzt werden, beispielsweise kann man damit seine PHPUnit-Tests mal durchlaufen lassen.

$ /tmp/php-7.4.0RC5/sapi/cli/php -v
PHP 7.4.0RC5 (cli) (built: Nov  4 2019 20:58:52) ( NTS )
Copyright (c) The PHP Group
Zend Engine v3.4.0-dev, Copyright (c) Zend Technologies

Um nach den ganzen Tests wieder aufzuräumen, kann der Ordner /tmp/php-7.4.0RC5/ einfach wieder gelöscht werden. Oder wenn man es länger behalten möchte, installiert man die PHP-Version nach /usr/local/php7.4.0rc5 (siehe prefix Parameter beim configure):

sudo make install

Sollte man auf einem Testsystem machen, je nach Parametern (–with-apxs2) verändert/zerstört ihr eventuell euren laufenden Apache.

Bis zum „make test“ macht ihr auf jeden Fall nichts kaputt, und ihr könnt in Ruhe testen.

Viel Spass beim Testen und Bugs melden!

Mögliche Fehlermeldungen beim Kompilieren

Hier sind die Fehlermeldungen, die auf meinem Ubuntu 18.04 aufgetreten sind, inklusive der Lösungen:

configure: error: Package requirements (sqlite3 > 3.7.4) were not met:
No package 'sqlite3' found

sudo apt-get install libsqlite3-dev

--------

configure: error: Package requirements (oniguruma) were not met:
No package 'oniguruma' found

sudo apt-get install libonig-dev

--------

configure: error: Package requirements (libpng) were not met:
No package 'libpng' found

sudo apt-get install libpng-dev

--------

configure: error: Package requirements (libzip >= 0.11) were not met:
No package 'libzip' found

sudo apt-get install libzip-dev

--------

configure: error: xml2-config not found. Please check your libxml2 installation.
sudo apt-get install libxml2-dev

--------

configure: error: Cannot find OpenSSL's <evp.h>
sudo apt-get install libssl-dev

--------

checking for cURL 7.15.5 or greater… configure: error: cURL version 7.15.5 or later is required to compile php with cURL support
sudo apt-get install libcurl4-openssl-dev

--------

configure: error: Cannot find OpenSSL's libraries
sudo apt-get install pkg-config

--------

configure: error: Cannot find zlib
sudo apt-get install zlib1g-dev

--------

checking whether to enable JIS-mapped Japanese font support in GD… no
If configure fails try --with-webp-dir=<DIR>
configure: error: jpeglib.h not found.
sudo apt-get install libjpeg-turbo8-dev

--------

configure: error: png.h not found.
sudo apt-get install libpng-dev

--------

configure: error: freetype-config not found.
sudo apt-get install libfreetype6-dev

--------

configure: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing. This should not happen. Check config.log for additional information.
sudo apt-get install libc-client2007e-dev

--------

configure: error: Kerberos libraries not found.
Check the path given to --with-kerberos (if no path is given, searches in /usr/kerberos, /usr/local and /usr )
sudo apt-get install libkrb5-dev

--------

configure: error: Cannot find pspell
sudo apt-get install libpspell-dev

--------

configure: error: Please reinstall the libzip distribution
sudo apt-get install libzip-dev

Applikationen migrieren von PHP 5.6 auf PHP 7.3

Michael Kliewe — Thu, 19 Sep 2019 21:56:45 +0000

PHP 7.0 ist nun schon über drei Jahre verfügbar, 7.3 ist auch schon wieder 9 Monate alt. PHP 7.4 wird Ende diesen Jahres erscheinen.

In den letzten 2 Jahren habe ich mehrere Projekte von PHP 5.6 auf eine 7er Version bringen dürfen. Zwei davon waren etwas größer, von denen möchte ich hier berichten.

Ich hatte in einem Artikel „PHP 7: Migration eines Projekts„, der kurz vor dem Release von PHP 7.0 erschien, schon einige kleine Tipps gegeben wie man einen Überblick bekommen kann über die zu bearbeitenden Baustellen. Heute soll es etwas mehr ins Eingemachte gehen.

Die 2 Projekte haben jeweils über 100.000 Zeilen „eigenen Code“, also ohne externe Libraries, so dass ich sie als „groß“ bezeichnen möchte. Das eine Projekt wurde zu Zeiten von PHP 5.3 gestartet und entwickelt, hat in den letzten 9 Jahren auch einiges an Pflege und Aktualisierungen erfahren. Externe Bibliotheken wurden ab und zu erneuert, es wurde teils auf Composer umgestellt, und hat auch in den letzten Jahren das ein oder andere PHP 5.4, 5.5 und 5.6 Feature erhalten.
Das andere Projekt ist etwas älter und stammt aus dem Jahr 2009, d.h. PHP 5.2 war damals aktuell, und es wurde noch kompatibel zu PHP 4 erstellt, da noch nicht alle Welt PHP 5 nutzte. Außerdem hat das Projekt seitdem kaum Aktualisierungen bekommen, quasi alles stammt noch aus der damaligen Zeit, ihr werdet später hier im Artikel sehen was ich damit meinen könnte 🙂

PHPStorm „Deprecated“-Inspection

Also gut, zuerst wollte ich mir jeweils einen Überblick verschaffen, und haben diverse Analyse-Tools über die Projekte laufen lassen. Als erstes ließ ich die „Deprecated“-Inspection von PHPStorm laufen. Dazu habe ich die genutzte PHP-Version auf 7.3 gestellt, und danach mittels Code->“Run inspection by name“->“Deprecated“ laufen lassen. Im ersten Projekt waren es nur 14 Einträge, recht übersichtlich und schnell zu beheben.
Im zweiten Projekt jedoch wurden 79 Probleme erkannt. Die häufigsten waren:

Function „ereg“ is deprecated
Function „eregi“ is deprecated
Function „ereg_replace“ is deprecated
Function „eregi_replace“ is deprecated
Function „split“ is deprecated
Function „set_socket_blocking“ is deprecated
Function „set_magic_quotes_runtime“ is deprecated
Function „mysql_*“ is deprecated

ereg(), eregi(), ereg_replace(), eregi_replace()

ereg() ist leicht zu ersetzen durch preg_match(), der Name der Funktion muss geändert werden, und dem Pattern fügt man Begrenzungszeichen (Delimiter) hinzu (meistens /, | oder #).
Aus

ereg('[a-z]', $string)

wird also

preg_match('/[a-z]/', $string)

eregi() wird ebenfalls durch preg_match() ersetzt, Begrenzungszeichen hinzugefügt, und hinter dem hinteren Begrenzungszeichen der Modifikator i eingesetzt.

Aus

eregi('[a-z]', $string)

wird also

preg_match('/[a-z]/i', $string)

Selbiges gilt für ereg_replace() und eregi_replace().

split(), set_socket_blocking(), set_magic_quotes_runtime()

split() kann durch explode() ersetzt werden wenn kein Regex im Suchbegriff enthalten ist, sondern nur „normale Strings“ (Literals). Ansonsten muss preg_split() genutzt werden.

set_socket_blocking() kann in den meisten (oder gar allen?) Fällen durch stream_set_blocking() ersetzt werden.

set_magic_quotes_runtime() war im Code dankenswerterweise eh an allen Stellen bereits in einem if-Konstrukt verschachtelt, so dass set_magic_quotes_runtime() seit PHP 5.4 nie aufgerufen wurde:

if (get_magic_quotes_runtime()) {
   @set_magic_quotes_runtime(0);
}

Seit PHP 5.3 ist set_magic_quotes_runtime() deprecated, in PHP 7.0 wurde es entfernt.
Seit PHP 5.4 liefert get_magic_quotes_runtime() immer FALSE, und ist bis 7.3 immer noch verfügbar.

mysql_* Funktionen

Hier gilt es, eine Langzeitbaustelle endlich zu beackern. Im „moderneren“ Projekt haben wir das die letzten Jahre kontinuierlich erledigt, und alles auf PDO umgestellt, bzw. neue Scripte immer direkt mit PDO geschrieben. Hier gab es nichts zu tun.

Im zweiten, älteren Projekt war dankenswerterweise die Wahl zwischen mysql_* und mysqli_* bereits vorhanden, man konnte es einfach per Konfiguration umschalten (es wurde dann die Datenbank-Abstraktionsklasse „project_mysqli extends project_database“ statt „project_mysql extends project_database“ genutzt). ABER: Beim Durchgehen fiel auf, dass der ursprüngliche Entwickler nicht an allen Stellen mysql_* und mysqli_* variabel programmiert hatte, denn an einigen wenigen Stellen wurde noch

return mysql_result($res, 0, "col");

im Code genutzt. Wenn mysqli genutzt wird, nutze ich nun:

return mysqli_fetch_array($res, MYSQLI_ASSOC)['col'];

php7mar

Nachdem diese ersten Schritte gemacht sind, und alle Deprecated-Meldungen aus PHPStorm berichtigt wurden, ließ ich php7mar nochmal laufen. Dort wurden mir dann „nur noch“ folgende Probleme angezeigt:

oldClassConstructors
funcGetArg
variableInterpolation

PHP4-Style Konstruktoren

Ersteres sind Überbleibsel aus der PHP4 Zeit, da das alte Projekt vermutlich zu PHP4-Zeiten begonnen wurde, oder zumindest noch kompatibel und mit alten PHP4-Versionen lauffähig sein sollte.

Diese alten Konstruktoren sind schnell ersetzt durch die modernen __construct() Konstruktoren, jedoch gibt es dabei ein Problem, bzw. eine Sache, auf die geachtet werden sollte:

Die alten Konstruktor-Funktionen könnten explizit aufgerufen werden in Kindklassen. Beispielsweise gibt es eine Vaterklasse „database“ und eine Kindklasse „mysql“, die folgendermaßen aussehen:

class database
{
  function database() {

  }
}

class mysql extends database
{
  ....
  function do() {
    $this->database();
  }
}

Nun gibt es 2 Möglichkeiten:
1. Einfach den Namen aller Konstruktoren ändern auf __construct(), und danach im ganzen Projekt suchen nach expliziten Aufrufen der alten Methode „database()“. Diese werden dann auch durch parent::__construct() ersetzt.
2. Man lässt die alte Methode der Vaterklasse bestehen, und fügt zusätzlich noch einen neuen Konstruktor __construct() hinzu. In diesem Fall müsste man nur die Vaterklasse „database“ ändern, und die Kindklasse „mysql“ könnte so belassen werden wie sie ist, denn die alte Methode „database()“ gibt es nach wie vor, und sie funktioniert.

class database
{
  function __construct() {  // neu hinzugefügt, VOR dem alten PHP4-Style Konstruktor

  }

  function database() {
    $this->__construct();
  }
}

Für welche der beiden Möglichkeiten man sich entscheidet, hängt vielleicht auch von der Anzahl an Kindklassen ab. Oder falls es eine öffentlich verfügbare und von fremden Leuten genutzte Bibliothek ist, sollte man vielleicht auch die zweite Methode wählen, so dass bestehender Fremdcode (Kindklassen) weiterhin ohne Änderungen funktionieren.

func_get_arg() + variableInterpolation

Zu func_get_arg() hatte ich bereits etwas geschrieben. Man kann schnell prüfen ob die Verhaltensänderung eintritt oder nicht, in den aller meisten Fällen kann man es so lassen wie es ist.

Eine der gefährlichsten Änderungen an PHP 7.0 ist die Änderung der Uniform Variablen Syntax. Darüber hatte ich im letzten Artikel bereits ausführlich geschrieben. Da es keine Warnungen, Deprecation-Meldungen, oder „undefined function“-Errors gibt, sondern der Bug evtl. unsichtbar ausgeführt wird, finde ich ihn gefährlich.
Dankenwerterweise gibt php7mar einige mögliche Stellen aus, die man sich angucken sollte. Es sind evtl. auch einige Falschmeldungen dabei, aber auch welche, bei denen man aktiv werden muss.

Zwischenfazit

Nachdem nun all diese Fehler berichtigt wurden, sind die meisten Fehler verschwunden, das Error-Log bleibt leer, und die Webseiten und Scripte funktionieren. Aber fertig sind wir noch nicht, denn die bisherigen Tools haben noch nicht alles gefunden. Ich habe ein drittes Tool genutzt, um die beiden Projekte zu analysieren und mir weitere PHP 7.x Probleme anzeigen zu lassen.

Exakat

PHP 7.3.0 RC 4: Performanceboost und bitte testen!

Michael Kliewe — Sat, 27 Oct 2018 20:23:43 +0000

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.

cd /tmp
wget https://downloads.php.net/~cmb/php-7.3.0RC4.tar.gz
tar -xzvf php-7.3.0RC4.tar.gz
cd php-7.3.0RC4/
./configure --prefix=/usr/local/php7.3.0RC4 --with-zlib --with-config-file-path=/usr/local/php7.3.0RC4/etc --enable-mbstring --enable-zip --with-imap --with-kerberos --with-imap-ssl --with-openssl --with-jpeg-dir --with-gd --with-gettext --with-freetype-dir --enable-ftp --with-pspell --with-curl
make
make test

Falls beim configure Fehler auftreten, guckt unten in der Liste am Ende dieses Artikels, da habe ich die aufgeschrieben, die bei mir aufgetreten sind. In allen Fällen fehlten Developer-Pakete zum Kompilieren einiger Extensions.

Am Ende des „make test“-Durchlaufs der über 13.000 Tests erhaltet ihr das Ergebnis. Falls Fehler aufgetreten sind, könnt ihr den Fehlerbericht direkt an das QA-Team schicken indem ihr Y drückt und eure E-Mail-Adresse eingebt zwecks eventueller Rückfragen. Eine Liste aller fehlgeschlagenen Tests von allen Testern gibt es auf qa.php.net.

Bei mir sind beispielsweise 6 Tests fehlgeschlagen:

FAILED TEST SUMMARY
---------------------------------------------------------------------
Bug #61948 (CURLOPT_COOKIEFILE '' raises open_basedir restriction) [ext/curl/tests/bug61948.phpt]
Bug #72333: fwrite() on non-blocking SSL sockets doesn't work [ext/openssl/tests/bug72333.phpt]
Bug #41655 (open_basedir bypass via glob()) 1/2 [ext/standard/tests/file/bug41655_1.phpt]
Test glob() function: ensure no platform difference, variation 3 [ext/standard/tests/file/glob_variation5.phpt]
int stream_socket_sendto ( resource $socket , string $data [, int $flags = 0 [, string $address ]] ); [ext/standard/tests/streams/stream_socket_sendto.phpt]
file upload greater than 2G [sapi/cli/tests/upload_2G.phpt]

Nach „make“ kann PHP genutzt werden, beispielsweise kann man damit seine PHPUnit-Tests mal durchlaufen lassen.

$ /tmp/php-7.3.0RC4/sapi/cli/php -v
PHP 7.3.0RC4 (cli) (built: Oct 27 2018 19:15:31) ( NTS )
Copyright (c) 1997-2018 The PHP Group
Zend Engine v3.3.0-dev, Copyright (c) 1998-2018 Zend Technologies

Um nach den ganzen Tests wieder aufzuräumen, kann der Ordner /tmp/php-7.3.0RC4/ einfach wieder gelöscht werden. Oder wenn man es länger behalten möchte, installiert man die PHP-Version nach /usr/local/php7.3.0RC4 (siehe prefix Parameter beim configure):

sudo make install

Sollte man auf einem Testsystem machen, je nach Parametern (–with-apxs2) verändert/zerstört ihr eventuell euren laufenden Apache.

Bis zum „make test“ macht ihr auf jeden Fall nichts kaputt, und ihr könnt in Ruhe testen.

Viel Spass beim Testen, und beim Messen der Performanceboosts eurer Applikationen! 🙂

Mögliche Fehlermeldungen beim Kompilieren

Hier sind die Fehlermeldungen, die auf meinem Ubuntu 18.04 aufgetreten sind, inklusive der Lösungen:

configure: error: xml2-config not found. Please check your libxml2 installation.
sudo apt-get install libxml2-dev

--------

configure: error: Cannot find OpenSSL's <evp.h>
sudo apt-get install libssl-dev

--------

checking for cURL 7.15.5 or greater... configure: error: cURL version 7.15.5 or later is required to compile php with cURL support
sudo apt-get install libcurl4-openssl-dev

--------

configure: error: Cannot find OpenSSL's libraries
sudo apt-get install pkg-config

--------

configure: error: Cannot find zlib
sudo apt-get install zlib1g-dev

--------

checking whether to enable JIS-mapped Japanese font support in GD... no
  If configure fails try --with-webp-dir=<DIR>
  configure: error: jpeglib.h not found.
sudo apt-get install libjpeg-turbo8-dev

--------

configure: error: png.h not found.
sudo apt-get install libpng-dev

--------

configure: error: freetype-config not found.
sudo apt-get install libfreetype6-dev

--------

configure: error: utf8_mime2text() has new signature, but U8T_CANONICAL is missing. This should not happen. Check config.log for additional information.
sudo apt-get install libc-client2007e-dev

--------

configure: error: Kerberos libraries not found.
      Check the path given to --with-kerberos (if no path is given, searches in /usr/kerberos, /usr/local and /usr )
sudo apt-get install libkrb5-dev

--------

configure: error: Cannot find pspell
sudo apt-get install libpspell-dev

--------

configure: error: Please reinstall the libzip distribution
sudo apt-get install libzip-dev

TLS 1.0/1.1 Abschaltung: Eigene Versionsverteilung herausfinden und serverseitig abschalten

Michael Kliewe — Wed, 17 Oct 2018 17:06:52 +0000

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.

Auch das BSI fordert bzw. empfiehlt den Behörden, TLS 1.2 als Minimum zu nutzen („fordert“ bei Neusystemen, „empfiehlt“ bei Altsystemen, aber auch nur wenn es den Bürgern zugemutet werden kann… Also recht schwammig das ganze).

Nun ist es Zeit, sich über TLS 1.0 und 1.1 Gedanken zu machen, auch für Seiten, die nicht durch Kreditkartenkonsortien dadurch gezwungen werden. Und es ist gut, sich damit zu beschäftigen: TLS 1.0 stammt aus dem Jahr 1999, TLS 1.1 aus 2006, und TLS 1.2 aus 2008.

Prozentuale Verteilung von TLS 1.0, 1.1 und 1.2 herausfinden

Einige Browserhersteller nennen Daten ihrer Nutzer:

Mozilla:
– TLS 1.3: 5%
– TLS 1.2: 93%
– TLS 1.0: 1,1%
– TLS 1.1: 0,09%

Chrome:
– TLS 1.0 + 1.1: 0,5%

Safari:
– TLS 1.0 + 1.1: 0,36%

Eine weitere Statistik bietet caniuse.com, bei der auch mobile Browser einbezogen werden:

NICHT kompatibel mit TLS 1.2 sind (Quelle):

Desktop IE Versionen 8, 9, und 10 auf Windows Vista und älter
Desktop IE Versionen 7 und darunter
Mobile IE Versionen 10 und darunter
Firefox 26 und darunter
Google Chrome 22 bis 37 auf Windows XP SP2 und älter
Google Chrome 21 und darunter
Android 4.4 (KitKat), je nach Gerät
Android 4.3 (Jelly Bean) und darunter
Desktop Safari Versionen 6 und darunter für OS X 10.8 (Mountain Lion) und darunter

Eigentlich alles Browser bzw. Betriebssysteme, die niemand mehr nutzen sollte 🙂

Wer den Verdacht hat, dass sein Browser kein TLS 1.2 unterstützt, kann den Client-Test von Qualys nutzen, und sich die Sicherheitsfeatures des eigenen Browsers anzeigen lassen.

Am einfachsten prüft man die aktuelle Verteilung der TLS-Versionen der eigenen Webseitenbesucher mit Hilfe des Webserver-Logs. Im nginx Webserver beispielsweise so:

log_format tls '$remote_addr - $remote_user [$time_local] "$request" '
  '$status $body_bytes_sent "$http_referer" '
  '"$http_user_agent" $http_host - $upstream_status - $upstream_addr [$request_time/$upstream_response_time] '
  '[SSL]: $ssl_protocol $ssl_cipher';
access_log /var/log/nginx/access_tls.log tls;

Im „log_format“ werden Variablen genutzt, um die SSL-Protokoll-Version und den genutzten Cipher in jeder Logzeile hinzuzufügen. Mit Hilfe der „access_log“ Zeile wird das gerade angelegte Format „tls“ in eine access_tls.log Datei geschrieben. Das Format der Original access.log zu ändern kann problematisch sein, wenn man mit Auswertungstools darauf zugreift, dann passt das Format evtl. nicht mehr. Deshalb mag es sinnvoller sein, es wie hier im Beispiel in eine separate Datei zu schreiben, die man auch nur einige Tage mitlaufen lässt, denn im Normalfall benötigt man diese Informationen nicht (außer man interessiert sich dafür 🙂 )

Mit ein paar grep-Befehlen oder einem kurzen PHP-Analyse-Script sollte sich nun herausfinden lassen, wie sich der Traffic auf die jeweiligen TLS-Versionen verteilt.

Man kann es auch mittels Javascript herausfinden, und das Ergebnis an den Server senden. Mehr dazu unten.

Sind es nur sehr wenige Nutzer, oder alte Bots auf der Suche nach E-Mail-Adressen, die noch TLS 1.0 nutzen, kann man TLS abschalten, eventuell nach vorheriger Ankündigung für die Nutzer. Doch was tun, wenn es zu viele Nutzer sind, die es noch nutzen?

Eine Warnung anzeigen via Javascript

Mit einem kleinen Javascript kann Nutzern angezeigt werden, dass ihr Browser noch kein TLS 1.2 beherrscht (also die Webseite via TLS 1.0/1.1 aufruft). Hier ein Beispiel:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>

<script type="application/javascript">
    jQuery('<img />').on({
        load: function() {
            alert("This browser supports TSL 1.2");
        },
        error: function() {
            alert('This browser does not support TSL 1.2');
        }
    }).attr('src','https://tls1.2.only.host.de/some.png');
</script>

(Aufgabe an die Leser: browserübergreifende Umsetzung ohne das überfrachtete jQuery zu nutzen 🙂 )

Das Script muss natürlich angepasst werden, ein „alert()“ ist keine schöne Anzeige. Besser wäre es, eine auffällige Box anzuzeigen mit einer ausführlichen Erklärung, Links zu Test- und Hilfeseiten usw.

Außerdem muss für die URL des Bildes eine Domain genommen werden, die nur TLS 1.2 unterstützt. Entweder man hat bereits eine, oder fragt jemanden der eine solche Domain hat, oder schaltet beispielsweise Cloudflare vor eine Domain, und setzt dort die TLS-Minimum-Version auf TLS 1.2. Man sollte darauf achten, einen TLS1.2-only-Webserver zu nehmen, der 24/7 online ist, denn wenn der Webserver nicht antwortet und das Bild nicht geladen werden kann, gibt es sonst falsche Ergebnisse bzw. Warnungen.

Statt dem User die Warnung anzuzeigen, kann der Javascript-Code auch zur Ermittlung der TLS 1.2 Unterstützung genutzt werden. Ein (ungetestetes) Beispiel:

<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js" integrity="sha256-FgpCb/KJQlLNfOu91ta32o/NMZxltwRo8QtmkMRdAu8=" crossorigin="anonymous"></script>

<script type="application/javascript">
    jQuery('<img />').on({
        load: function() {
            jQuery('<img />').attr('src','https://meinewebsite.de/tlsinfo.php?v=1.2');
        },
        error: function() {
            jQuery('<img />').attr('src','https://meinewebsite.de/tlsinfo.php?v=no1.2');
        }
    }).attr('src','https://tls1.2.only.host.de/some.png');
</script>

meinewebsite.de sollte natürlich TLS 1.0 und 1.2 unterstützen, sonst klappt es nicht. In der tlsinfo.php schreibt man den erhaltenen „v“ Parameter z.B. in eine Datenbank, und zählt die Vorkommnisse (man sollte doppelte Requests von IP-Adressen vermutlich rausfiltern).

OK, wir haben nur noch wenige Nutzer, die noch TLS 1.0/1.1 benötigen, wir schalten es ab.

TLS 1.0 und 1.1 im Webserver abschalten

Kurz und bündig:

nginx:
ssl_protocols TLSv1.2;

Apache:
SSLProtocol All -SSLv2 -SSLv3 -TLSv1 -TLSv1.1

Obiges ist besser als
SSLProtocol TLSv1.2
denn wenn in Zukunft TLSv1.3 in „All“ aufgenommen wird, ist es bereits frühestmöglich aktiv, und muss nicht manuell hinzugefügt werden.

Man sollte sich natürlich sicher sein, dass dann noch TLS 1.2 übrig bleibt, das Betriebssystem bzw. OpenSSL sollte nicht zu alt sein (OpenSSL >= 1.0.1 bietet TLS 1.2). Ein kurzer Test vorher und nachher ist eine gute Idee:
https://www.ssllabs.com/ssltest/
https://sslanalyzer.comodoca.com/

Besonders zu beachten sind die unterstützten TLS-Versionen und die Ciphers. Natürlich bietet es sich auch an, alle anderen verbesserungswürdigen Einstellungen anzupassen, aber das sollte man eh ab und zu mal prüfen.

Noch ist das ganze nicht wirklich dringend, selbst 2020 wird es keine Probleme geben wenn man bis dahin TLS 1.2 unterstützt. Doch ich finde, es ist langsam an der Zeit, TLS 1.0 und 1.1 den Laufpass zu geben, und das lieber kontrolliert zu tun, als überhastet im Notfall. Wer weiß, vielleicht ist TLS 1.0 ja auch bereits gebrochen, nur wissen das bisher allein die Geheimdienste…

Performanceboost durch temporäres Abschalten des PHP Garbage Collectors

Michael Kliewe — Fri, 12 Oct 2018 08:46:27 +0000

Update 27.10.2018: Mit PHP 7.3 ist das selektive Abschalten des Garbage Collectors wohl nicht mehr nötig.

Auf der Suche nach einfachen Möglichkeiten, die Performance eines CPU-bound PHP-Scripts zu steigern, fiel mir wieder ein, wie der Composer Installer einen drastischen Performanceboost hinbekommen hat. Selbst ausprobiert, und siehe da: Statt 7 Sekunden Laufzeit nur noch 2,7 Sekunden. Whao!

Wie macht man sowas mit nur 1-3 Zeilenänderungen?

Garbage Collection

Ein paar kurze Worte zum Garbage Collector. Am Ende dieses Blogartikels sind ein paar Links für diejenigen, die mehr wissen wollen. Ich versuche es einfach darzustellen.

Der Garbage Collector läuft im Hintergrund eines PHP-Scripts in der PHP-Engine, seine Aufgabe ist es, ungenutzten, nicht mehr gebrauchten Arbeitsspeicher wieder frei zu machen. Dazu durchläuft er alle Variablen und Datenstrukturen, um zu schauen ob sie noch gebraucht werden. Wenn ein Speicherbereich noch gebraucht wird, dann gibt es eine Referenz darauf (eine Variable im einfachsten Fall). Er findet also alle Speicherbereiche, zu denen es keine Variable mehr gibt, und gibt den Speicher wieder frei.

Das ist nur der einfachste Fall, sehr simpel erklärt. Im Detail muss man auch über Objekte nachdenken, Ressourcen, zyklische Referenzen (wenn X Variablen sich „im Kreis“ referenzieren), und so weiter. Es ist sogar so, dass es beim Garbage Collector von PHP nur um die zyklischen Referenzen geht, normale Variablen werden beim Verlassen eines Scopes (einer Funktion/Methode) schon wieder freigegeben, problematisch sind aber die komplizierteren Referenzen zwischen Objekten und mehreren Variablen, die gegenseitig auf sich zeigen.

Garbage Collection gibt es in allen Programmiersprachen, bei denen der Programmierer sich nicht manuell selbst drum kümmern muss/soll, Speicher wieder freizugeben. In C beispielsweise muss sich der Programmierer selbst drum kümmern, und das geht häufig schief und führt zu Memory Leaks, Sicherheitsproblemen, „double-free“ Fehlern und so weiter. Deshalb nehmen moderne/sicherere Hochsprachen einem Programmierer diese Arbeit ab, die aller meisten modernen Programmiersprachen haben Garbage Collectoren.

Garbage Collectoren laufen also im Hintergrund mit, und versuchen „ab und zu“ Speicher freizubekommen. Dabei durchsucht er alle existierenden Variablen/Datenstrukturen, ob eine davon verworfen werden kann, weil sie nicht mehr gebraucht wird. Hat man sehr viele (Millionen) Objekte, dauert solch ein Durchlauf entsprechend lang, und im schlimmsten Fall ist das Ergebnis: Alle Speicherbereiche werden noch benötigt, es gibt nichts zu tun.

Wie gesagt, recht vereinfacht, in den letzten Jahren gab es sehr viele verbesserte Garbage Collectoren, die nicht immer alle Datenstrukturen durchsuchen, und deren Laufzeit beschränkt wird wenn es zu viel zu durchsuchen gibt, usw. Stichworte: „Serial collector“, „Parallel collector“, „Concurrent Mark Sweep (CMS) Collector“, „Generational Garbage Collector“.

Garbage Collector temporär abschalten

Wie kommt man auf die Idee, die Garbage Collection temporär zu deaktivieren? Es gibt einen bekannten Fall im PHP-Universum: Der Composer Installer. Er war berühmt-berüchtigt für seine Langsamkeit, da die Berechnung der Dependency-Bäume sehr langsam war. Durch eine einzige Zeilenänderung (gc_disable();) konnte der Installer um 30-90% beschleunigt werden.
https://tideways.com/profiler/blog/how-to-optimize-the-php-garbage-collector-usage-to-improve-memory-and-performance
https://blog.blackfire.io/performance-impact-of-the-php-garbage-collector.html

Wenn man als Programmierer weiß, dass in einem bestimmten Code-Block, oder einer Methode, oder gar einem ganzen PHP-Script, der Garbage Collector nur unnötig versucht, Speicher frei zu machen, dann kann man ihn deaktivieren, um der Engine die unnötige Arbeit zu ersparen. Bei PHP-Scripten, die sehr viel CPU benötigen, und die mit vielen Objekten und Speicher arbeiten, kann das Wunder bewirken.

Erst heute morgen habe ich es beim DomPDF Projekt ausprobiert. Mit DomPDF kann man sehr einfach aus (einfachem) HTML ein PDF rendern. Doch DomPDF ist recht langsam bei großen, mehrseitigen Dokumenten, da dauert es gern mal mehrere Hundert Millisekunden oder gar Sekunden. Da gerade in einem Issue über Performance diskutiert wurde, habe ich in der render() Methode den Garbage Collector am Anfang deaktiviert, und am Ende wieder aktiviert. Ein (künstliches) Test-HTML-Dokument benötigt nur noch 2.7 Sekunden statt 7 Sekunden, also eine ähnliche Performancesteigerung wie beim Composer Installer. Und das mit nur 3 Zeilen Code.

$ git diff
diff --git a/src/Dompdf.php b/src/Dompdf.php
index d031938..df37e8d 100644
--- a/src/Dompdf.php
+++ b/src/Dompdf.php
@@ -701,6 +701,8 @@ class Dompdf
      */
     public function render()
     {
+        gc_disable();
+
         $this->saveLocale();
         $options = $this->options;

@@ -864,6 +866,9 @@ class Dompdf
         }

         $this->restoreLocale();
+
+        gc_enable();
+        gc_collect_cycles();
     }

Vorher:

$ php test_performance.php break_tag 10000
Profiling PDF generation using 'break_tag' over 10000 iterations.
STEP          MEMORY USE    PEAK MEMORY   EXECUTION TIME
Start         2,528,280     2,883,608     -
Load          2,553,104     2,883,608     0.0082650184631348
Render        36,158,096    49,725,776    6.9973478317261     <======
Output        36,168,776    49,725,776    0.00060415267944336
End           36,169,232

Nachher:

$ php test_performance.php break_tag 10000
Profiling PDF generation using 'break_tag' over 10000 iterations.
STEP          MEMORY USE    PEAK MEMORY   EXECUTION TIME
Start         2,528,584     2,883,912     -
Load          2,553,408     2,883,912     0.0081119537353516
Render        36,158,432    49,719,360    2.7755401134491    <======
Output        36,169,112    49,719,360    0.00069785118103027
End           36,169,568

Es kommt, wie häufig, auf den Anwendungsfall an, ob dieses temporäre Abschalten des Garbage Collectors etwas bringt oder nicht. Man sollte dabei beachten, dass man dadurch eventuell den Speicherverbrauch erhöht, da eben kein Speicher mehr freigemacht wird wenn der Garbage Collector abgeschaltet ist. Man sollte es also nur nutzen, wenn man dadurch nicht in Speicherprobleme gerät.

Ob man den Garbage Collector am Ende wieder aktiviert, oder bis zum Scriptende ausgeschaltet lässt, kommt drauf an: Wenn man das Script komplett unter der eigenen Kontrolle hat, und es sich nicht um einen langlaufenden Daemon handelt, dann kann man ihn eventuell deaktiviert lassen. Im Falle von DomPDF ist es aber eine Library, die eventuell in einem Daemon genutzt wird, man sollte also unbedingt am Ende den Garbage Collector wieder aktivieren, sonst wundert sich der Nutzer der Library über einen sehr hohen Speicherverbrauch in seinem Script. Deshalb wird in DomPDF der Garbage Collector wieder aktiviert, der Composer Installer jedoch lässt ihn bis zum Ende ausgeschaltet.

Probiert es mal aus in euren langsamen Scripten, die CPU-bound sind und mit vielen Objekten/Referenzen etc. arbeiten. Vielleicht habt ihr dann ähnliche Erfolgserlebnisse 🙂

Und hier die versprochenen Links zu Details des (PHP) Garbage Collectors:

https://blog.ircmaxell.com/2014/12/what-about-garbage.html
https://react-etc.net/entry/improvements-to-garbage-collection-gc-php-7-3-boosts-performance-in-benchmark
https://www.sitepoint.com/better-understanding-phps-garbage-collection/
http://php.net/manual/de/features.gc.performance-considerations.php

Der Unterschied zwischen „||“ und „or“ bzw. „&&“ und „and“

Michael Kliewe — Sat, 29 Sep 2018 17:33:43 +0000

Wenn man eine if-Anweisung in PHP schreiben möchte, und dabei 2 Bedingungen mit einem „und“ verknüpfen möchte, kann man entweder „&&“ nutzen oder „and“ schreiben. Richtig?

if ($a > 0 && $b < 100) {

if ($a > 0 and $b < 100) {

Das ist das selbe, oder? Ja, ist es. Beides funktioniert, beides ist syntaktisch korrekt, und beides ist äquivalent.

Kopieren wir nun die Bedingungen in eine temporäre Variable $c:

$c = $a > 0 && $b < 100;
if ($c) {

$c = $a > 0 and $b < 100;
if ($c) {

DAS ist nun nicht mehr das selbe!

Schauen wir uns das in einer einfacheren Zuweisung an:

$a = true;
$b = false;
$bool = $a && $b;
var_dump($bool); // false, wie erwartet

$bool = $a and $b;
var_dump($bool); // true ?!?

Mir war der Unterschied nicht bekannt, bis vor einigen Wochen auf der PHP-Internals-Liste über das Thema Unifying logical operators diskutiert wurde. Ryan „Iggy“ Volz schlägt vor, diesen nicht erwarteten Unterschied zu entfernen, „and“ solle in Zukunft ein Alias für „&&“ sein, „or“ ein Alias für „||“. Einen Entwurf eines RFC hat er vorbereitet.

Doch woher kommt der Unterschied?

Schuld daran ist die Operator precedence:

&& bzw. || sind höher in der Reihenfolge als das Gleichheitszeichen „=“. „and“ bzw. „or“ sind niedriger als „=“. Das führt zur beobachteten unterschiedlichen Gruppierung der Operanden.

Hier eine schöne Übersicht:

$bool = FALSE || TRUE;
- interpreted as ($bool = (FALSE || TRUE))
- value of $bool is TRUE

$bool = FALSE OR TRUE;
- interpreted as (($bool = FALSE) OR TRUE)
- value of $bool is FALSE

$bool = TRUE && FALSE;
- interpreted as ($bool = (TRUE && FALSE))
- value of $bool is FALSE

$bool = TRUE AND FALSE;
- interpreted as (($bool = TRUE) AND FALSE)
- value of $bool is TRUE

Der Unterschied ist in der „interpreted as“ Zeile zu sehen: Einmal werden erst die beiden linken Operanden verarbeitet, dann bei Bedarf der rechte, und einmal werden erst die beiden rechten Operanden verarbeitet, und dann per Zuweisung in die Variable geschrieben.

Ich muss zugeben, sehr selten ein „or“ bzw. „and“ in PHP-Code zu sehen, aber in altem Code sieht man es ab und zu. Entweder weil es jemand schöner findet, oder weil er mit anderen Sprachen durcheinander gekommen ist, in denen „and“ bzw. „or“ genutzt werden (SQL ist ein bekanntes Beispiel). Häufig funktioniert es ohne Probleme, z.B. in if-Anweisungen, aber bei Zuweisungen ist Vorsicht angesagt.

Ich glaube nicht, dass eine Änderung des aktuellen Verhaltens angegangen wird, die Diskussion ist zum Erliegen gekommen, sie ging eher hin zu „das war noch nie ein großes Problem“, „es wird genutzt in diversen Projekten, die Änderung macht alle diese Projekte unnötigerweise kaputt“, und „ich finde es toll, dass es diese beiden Schreibweisen gibt“. Es wird also vermutlich kein Aliasing geben, und alles bleibt so wie es ist.

igphp – Interessengemeinschaft PHP e.V.

Michael Kliewe — Sat, 01 Sep 2018 20:50:46 +0000

Ich mag PHP. Ich möchte es auch in Zukunft nutzen, denn man kann sehr effektiv Software schreiben, große wie kleine Projekte umsetzen, und einfach alles machen was man will: Webseiten, Daemons, Cronjobs, Chatbots, IoT-Steuerungen, neuronale Netze, einfach alles. Dazu tragen kontinuierliche Verbesserungen und Erweiterungen der Sprache selbst, aber auch das Ökosystem (Frameworks, Tools, Bibliotheken…) bei. Seit PHP 7 ist PHP mit an der Spitze der performantesten Scriptsprachen. Es gibt eine Menge PHP-User-Groups weltweit, Dutzende Konferenzen jedes Jahr, Foren, eine Menge Möglichkeiten sich auszutauschen. Aber es fehlte noch etwas…

Anfang 2017 wurde die Interessengemeinschaft PHP e.V. (igphp) gegründet, eine gemeinnützige Organisation, ein Verein, dessen Aufgabe und Arbeit sich darum dreht, PHP weiter zu stärken, weiterzuentwickeln, die Akzeptanz zu steigern, und es in Forschung, Ausbildung und Wissenschaft zu verbreiten. Es sollen quelloffene Projekte unterstützt werden, die Vernetzung soll vorangetrieben werden in Forschung, Lehre, und Industrie. Hohe Ziele, für die es Mitstreiter braucht, Unterstüzung, Geld.

Seit Ende Juli 2018 ist igphp öffentlich, und nimmt Mitglieder auf. Seit dem 30.07.2018 bin ich Mitglied #000014, möchte helfen bei dem, was PHP weiter voran bringt, denn PHP ist zu großen Teilen mein Hobby und Beruf, und das soll auch gern so bleiben.

Da hier viele sind, die wie ich mit PHP ihre Brötchen verdienen, möchte ich dafür werben, sich die igphp anzuschauen, und sie im Idealfall tatkräftig zu unterstützen. Eine (Förder)Mitgliedschaft ist sowohl für Privatleute als auch Firmen möglich.

Ich würde mich sehr freuen, mit euch im Verein zusammenzuarbeiten.

Weitere Infos findet ihr hier:

https://igphp.de/

https://twitter.com/igphp

PHP, curl und TLS 1.2 als Minimum

Michael Kliewe — Mon, 04 Dec 2017 22:43:35 +0000

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:

Ubuntu 13.10: TLS 1.1 „Bad“
Ubuntu 14.04: TLS 1.2 „Bad“
Ubuntu 16.04: TLS 1.2 „Probably Okay“

Ein weiterer Grund, immer up2date zu bleiben. Ubuntu 13.10 erhält seit Jahren keine Security-Updates mehr, sollte also eh nirgends mehr eingesetzt werden (besonders nicht in Payment-Systemen).

===================================

Hier die ausführlichen Ausgaben der 3 untersuchten Ubuntu-Versionen:

Ausgabe Ubuntu 13.10.:

object(stdClass)#1 (10) {
  ["given_cipher_suites"]=>
  array(51) {
    [0]=>
    string(34) "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA"
    [1]=>
    string(36) "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA"
    [2]=>
    string(36) "TLS_SRP_SHA_DSS_WITH_AES_256_CBC_SHA"
    [3]=>
    string(36) "TLS_SRP_SHA_RSA_WITH_AES_256_CBC_SHA"
    [4]=>
    string(32) "TLS_DHE_RSA_WITH_AES_256_CBC_SHA"
    [5]=>
    string(32) "TLS_DHE_DSS_WITH_AES_256_CBC_SHA"
    [6]=>
    string(37) "TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA"
    [7]=>
    string(37) "TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA"
    [8]=>
    string(33) "TLS_ECDH_RSA_WITH_AES_256_CBC_SHA"
    [9]=>
    string(35) "TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA"
    [10]=>
    string(28) "TLS_RSA_WITH_AES_256_CBC_SHA"
    [11]=>
    string(33) "TLS_RSA_WITH_CAMELLIA_256_CBC_SHA"
    [12]=>
    string(35) "TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA"
    [13]=>
    string(37) "TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA"
    [14]=>
    string(37) "TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA"
    [15]=>
    string(37) "TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA"
    [16]=>
    string(33) "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA"
    [17]=>
    string(33) "TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA"
    [18]=>
    string(34) "TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA"
    [19]=>
    string(36) "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA"
    [20]=>
    string(29) "TLS_RSA_WITH_3DES_EDE_CBC_SHA"
    [21]=>
    string(34) "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"
    [22]=>
    string(36) "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA"
    [23]=>
    string(36) "TLS_SRP_SHA_DSS_WITH_AES_128_CBC_SHA"
    [24]=>
    string(36) "TLS_SRP_SHA_RSA_WITH_AES_128_CBC_SHA"
    [25]=>
    string(32) "TLS_DHE_RSA_WITH_AES_128_CBC_SHA"
    [26]=>
    string(32) "TLS_DHE_DSS_WITH_AES_128_CBC_SHA"
    [27]=>
    string(29) "TLS_DHE_RSA_WITH_SEED_CBC_SHA"
    [28]=>
    string(29) "TLS_DHE_DSS_WITH_SEED_CBC_SHA"
    [29]=>
    string(37) "TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA"
    [30]=>
    string(37) "TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA"
    [31]=>
    string(33) "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA"
    [32]=>
    string(35) "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA"
    [33]=>
    string(28) "TLS_RSA_WITH_AES_128_CBC_SHA"
    [34]=>
    string(25) "TLS_RSA_WITH_SEED_CBC_SHA"
    [35]=>
    string(33) "TLS_RSA_WITH_CAMELLIA_128_CBC_SHA"
    [36]=>
    string(30) "TLS_ECDHE_RSA_WITH_RC4_128_SHA"
    [37]=>
    string(32) "TLS_ECDHE_ECDSA_WITH_RC4_128_SHA"
    [38]=>
    string(29) "TLS_ECDH_RSA_WITH_RC4_128_SHA"
    [39]=>
    string(31) "TLS_ECDH_ECDSA_WITH_RC4_128_SHA"
    [40]=>
    string(24) "TLS_RSA_WITH_RC4_128_SHA"
    [41]=>
    string(24) "TLS_RSA_WITH_RC4_128_MD5"
    [42]=>
    string(28) "TLS_DHE_RSA_WITH_DES_CBC_SHA"
    [43]=>
    string(28) "TLS_DHE_DSS_WITH_DES_CBC_SHA"
    [44]=>
    string(24) "TLS_RSA_WITH_DES_CBC_SHA"
    [45]=>
    string(37) "TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA"
    [46]=>
    string(37) "TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA"
    [47]=>
    string(33) "TLS_RSA_EXPORT_WITH_DES40_CBC_SHA"
    [48]=>
    string(34) "TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5"
    [49]=>
    string(30) "TLS_RSA_EXPORT_WITH_RC4_40_MD5"
    [50]=>
    string(33) "TLS_EMPTY_RENEGOTIATION_INFO_SCSV"
  }
  ["ephemeral_keys_supported"]=>
  bool(true)
  ["session_ticket_supported"]=>
  bool(false)
  ["tls_compression_supported"]=>
  bool(false)
  ["unknown_cipher_suite_supported"]=>
  bool(false)
  ["beast_vuln"]=>
  bool(false)
  ["able_to_detect_n_minus_one_splitting"]=>
  bool(false)
  ["insecure_cipher_suites"]=>
  object(stdClass)#2 (23) {
    ["TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(49) "uses keys smaller than 128 bits in its encryption"
    }
    ["TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(113) "uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"
    }
    ["TLS_DHE_DSS_WITH_DES_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(49) "uses keys smaller than 128 bits in its encryption"
    }
    ["TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(49) "uses keys smaller than 128 bits in its encryption"
    }
    ["TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(113) "uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"
    }
    ["TLS_DHE_RSA_WITH_DES_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(49) "uses keys smaller than 128 bits in its encryption"
    }
    ["TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(113) "uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"
    }
    ["TLS_ECDHE_ECDSA_WITH_RC4_128_SHA"]=>
    array(1) {
      [0]=>
      string(48) "uses RC4 which has insecure biases in its output"
    }
    ["TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(113) "uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"
    }
    ["TLS_ECDHE_RSA_WITH_RC4_128_SHA"]=>
    array(1) {
      [0]=>
      string(48) "uses RC4 which has insecure biases in its output"
    }
    ["TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(113) "uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"
    }
    ["TLS_ECDH_ECDSA_WITH_RC4_128_SHA"]=>
    array(1) {
      [0]=>
      string(48) "uses RC4 which has insecure biases in its output"
    }
    ["TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(113) "uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"
    }
    ["TLS_ECDH_RSA_WITH_RC4_128_SHA"]=>
    array(1) {
      [0]=>
      string(48) "uses RC4 which has insecure biases in its output"
    }
    ["TLS_RSA_EXPORT_WITH_DES40_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(49) "uses keys smaller than 128 bits in its encryption"
    }
    ["TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5"]=>
    array(1) {
      [0]=>
      string(49) "uses keys smaller than 128 bits in its encryption"
    }
    ["TLS_RSA_EXPORT_WITH_RC4_40_MD5"]=>
    array(2) {
      [0]=>
      string(49) "uses keys smaller than 128 bits in its encryption"
      [1]=>
      string(48) "uses RC4 which has insecure biases in its output"
    }
    ["TLS_RSA_WITH_3DES_EDE_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(113) "uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"
    }
    ["TLS_RSA_WITH_DES_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(49) "uses keys smaller than 128 bits in its encryption"
    }
    ["TLS_RSA_WITH_RC4_128_MD5"]=>
    array(1) {
      [0]=>
      string(48) "uses RC4 which has insecure biases in its output"
    }
    ["TLS_RSA_WITH_RC4_128_SHA"]=>
    array(1) {
      [0]=>
      string(48) "uses RC4 which has insecure biases in its output"
    }
    ["TLS_SRP_SHA_DSS_WITH_3DES_EDE_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(113) "uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"
    }
    ["TLS_SRP_SHA_RSA_WITH_3DES_EDE_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(113) "uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"
    }
  }
  ["tls_version"]=>
  string(7) "TLS 1.1"
  ["rating"]=>
  string(3) "Bad"
}

Ausgabe Ubuntu 14.04:

object(stdClass)#1 (10) {
  ["given_cipher_suites"]=>
  array(59) {
    [0]=>
    string(37) "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
    [1]=>
    string(39) "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"
    [2]=>
    string(37) "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
    [3]=>
    string(39) "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384"
    [4]=>
    string(34) "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA"
    [5]=>
    string(36) "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA"
    [6]=>
    string(35) "TLS_DHE_DSS_WITH_AES_256_GCM_SHA384"
    [7]=>
    string(35) "TLS_DHE_RSA_WITH_AES_256_GCM_SHA384"
    [8]=>
    string(35) "TLS_DHE_RSA_WITH_AES_256_CBC_SHA256"
    [9]=>
    string(35) "TLS_DHE_DSS_WITH_AES_256_CBC_SHA256"
    [10]=>
    string(32) "TLS_DHE_RSA_WITH_AES_256_CBC_SHA"
    [11]=>
    string(32) "TLS_DHE_DSS_WITH_AES_256_CBC_SHA"
    [12]=>
    string(37) "TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA"
    [13]=>
    string(37) "TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA"
    [14]=>
    string(36) "TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384"
    [15]=>
    string(38) "TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384"
    [16]=>
    string(36) "TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384"
    [17]=>
    string(38) "TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384"
    [18]=>
    string(33) "TLS_ECDH_RSA_WITH_AES_256_CBC_SHA"
    [19]=>
    string(35) "TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA"
    [20]=>
    string(31) "TLS_RSA_WITH_AES_256_GCM_SHA384"
    [21]=>
    string(31) "TLS_RSA_WITH_AES_256_CBC_SHA256"
    [22]=>
    string(28) "TLS_RSA_WITH_AES_256_CBC_SHA"
    [23]=>
    string(33) "TLS_RSA_WITH_CAMELLIA_256_CBC_SHA"
    [24]=>
    string(35) "TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA"
    [25]=>
    string(37) "TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA"
    [26]=>
    string(33) "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA"
    [27]=>
    string(33) "TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA"
    [28]=>
    string(34) "TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA"
    [29]=>
    string(36) "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA"
    [30]=>
    string(29) "TLS_RSA_WITH_3DES_EDE_CBC_SHA"
    [31]=>
    string(37) "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
    [32]=>
    string(39) "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
    [33]=>
    string(37) "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
    [34]=>
    string(39) "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"
    [35]=>
    string(34) "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"
    [36]=>
    string(36) "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA"
    [37]=>
    string(35) "TLS_DHE_DSS_WITH_AES_128_GCM_SHA256"
    [38]=>
    string(35) "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256"
    [39]=>
    string(35) "TLS_DHE_RSA_WITH_AES_128_CBC_SHA256"
    [40]=>
    string(35) "TLS_DHE_DSS_WITH_AES_128_CBC_SHA256"
    [41]=>
    string(32) "TLS_DHE_RSA_WITH_AES_128_CBC_SHA"
    [42]=>
    string(32) "TLS_DHE_DSS_WITH_AES_128_CBC_SHA"
    [43]=>
    string(29) "TLS_DHE_RSA_WITH_SEED_CBC_SHA"
    [44]=>
    string(29) "TLS_DHE_DSS_WITH_SEED_CBC_SHA"
    [45]=>
    string(37) "TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA"
    [46]=>
    string(37) "TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA"
    [47]=>
    string(36) "TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256"
    [48]=>
    string(38) "TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256"
    [49]=>
    string(36) "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256"
    [50]=>
    string(38) "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256"
    [51]=>
    string(33) "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA"
    [52]=>
    string(35) "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA"
    [53]=>
    string(31) "TLS_RSA_WITH_AES_128_GCM_SHA256"
    [54]=>
    string(31) "TLS_RSA_WITH_AES_128_CBC_SHA256"
    [55]=>
    string(28) "TLS_RSA_WITH_AES_128_CBC_SHA"
    [56]=>
    string(25) "TLS_RSA_WITH_SEED_CBC_SHA"
    [57]=>
    string(33) "TLS_RSA_WITH_CAMELLIA_128_CBC_SHA"
    [58]=>
    string(33) "TLS_EMPTY_RENEGOTIATION_INFO_SCSV"
  }
  ["ephemeral_keys_supported"]=>
  bool(true)
  ["session_ticket_supported"]=>
  bool(false)
  ["tls_compression_supported"]=>
  bool(false)
  ["unknown_cipher_suite_supported"]=>
  bool(false)
  ["beast_vuln"]=>
  bool(false)
  ["able_to_detect_n_minus_one_splitting"]=>
  bool(false)
  ["insecure_cipher_suites"]=>
  object(stdClass)#2 (7) {
    ["TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(113) "uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"
    }
    ["TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(113) "uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"
    }
    ["TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(113) "uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"
    }
    ["TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(113) "uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"
    }
    ["TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(113) "uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"
    }
    ["TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(113) "uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"
    }
    ["TLS_RSA_WITH_3DES_EDE_CBC_SHA"]=>
    array(1) {
      [0]=>
      string(113) "uses 3DES which is vulnerable to the Sweet32 attack but was not configured as a fallback in the ciphersuite order"
    }
  }
  ["tls_version"]=>
  string(7) "TLS 1.2"
  ["rating"]=>
  string(3) "Bad"
}

Ausgabe Ubuntu 16.04:

class stdClass#1 (10) {
  public $given_cipher_suites =>
  array(79) {
    [0] =>
    string(37) "TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384"
    [1] =>
    string(39) "TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384"
    [2] =>
    string(37) "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384"
    [3] =>
    string(39) "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384"
    [4] =>
    string(34) "TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA"
    [5] =>
    string(36) "TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA"
    [6] =>
    string(34) "TLS_DH_DSS_WITH_AES_256_GCM_SHA384"
    [7] =>
    string(35) "TLS_DHE_DSS_WITH_AES_256_GCM_SHA384"
    [8] =>
    string(34) "TLS_DH_RSA_WITH_AES_256_GCM_SHA384"
    [9] =>
    string(35) "TLS_DHE_RSA_WITH_AES_256_GCM_SHA384"
    [10] =>
    string(35) "TLS_DHE_RSA_WITH_AES_256_CBC_SHA256"
    [11] =>
    string(35) "TLS_DHE_DSS_WITH_AES_256_CBC_SHA256"
    [12] =>
    string(34) "TLS_DH_RSA_WITH_AES_256_CBC_SHA256"
    [13] =>
    string(34) "TLS_DH_DSS_WITH_AES_256_CBC_SHA256"
    [14] =>
    string(32) "TLS_DHE_RSA_WITH_AES_256_CBC_SHA"
    [15] =>
    string(32) "TLS_DHE_DSS_WITH_AES_256_CBC_SHA"
    [16] =>
    string(31) "TLS_DH_RSA_WITH_AES_256_CBC_SHA"
    [17] =>
    string(31) "TLS_DH_DSS_WITH_AES_256_CBC_SHA"
    [18] =>
    string(37) "TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA"
    [19] =>
    string(37) "TLS_DHE_DSS_WITH_CAMELLIA_256_CBC_SHA"
    [20] =>
    string(36) "TLS_DH_RSA_WITH_CAMELLIA_256_CBC_SHA"
    [21] =>
    string(36) "TLS_DH_DSS_WITH_CAMELLIA_256_CBC_SHA"
    [22] =>
    string(36) "TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384"
    [23] =>
    string(38) "TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384"
    [24] =>
    string(36) "TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384"
    [25] =>
    string(38) "TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384"
    [26] =>
    string(33) "TLS_ECDH_RSA_WITH_AES_256_CBC_SHA"
    [27] =>
    string(35) "TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA"
    [28] =>
    string(31) "TLS_RSA_WITH_AES_256_GCM_SHA384"
    [29] =>
    string(31) "TLS_RSA_WITH_AES_256_CBC_SHA256"
    [30] =>
    string(28) "TLS_RSA_WITH_AES_256_CBC_SHA"
    [31] =>
    string(33) "TLS_RSA_WITH_CAMELLIA_256_CBC_SHA"
    [32] =>
    string(37) "TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256"
    [33] =>
    string(39) "TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256"
    [34] =>
    string(37) "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256"
    [35] =>
    string(39) "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256"
    [36] =>
    string(34) "TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA"
    [37] =>
    string(36) "TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA"
    [38] =>
    string(34) "TLS_DH_DSS_WITH_AES_128_GCM_SHA256"
    [39] =>
    string(35) "TLS_DHE_DSS_WITH_AES_128_GCM_SHA256"
    [40] =>
    string(34) "TLS_DH_RSA_WITH_AES_128_GCM_SHA256"
    [41] =>
    string(35) "TLS_DHE_RSA_WITH_AES_128_GCM_SHA256"
    [42] =>
    string(35) "TLS_DHE_RSA_WITH_AES_128_CBC_SHA256"
    [43] =>
    string(35) "TLS_DHE_DSS_WITH_AES_128_CBC_SHA256"
    [44] =>
    string(34) "TLS_DH_RSA_WITH_AES_128_CBC_SHA256"
    [45] =>
    string(34) "TLS_DH_DSS_WITH_AES_128_CBC_SHA256"
    [46] =>
    string(32) "TLS_DHE_RSA_WITH_AES_128_CBC_SHA"
    [47] =>
    string(32) "TLS_DHE_DSS_WITH_AES_128_CBC_SHA"
    [48] =>
    string(31) "TLS_DH_RSA_WITH_AES_128_CBC_SHA"
    [49] =>
    string(31) "TLS_DH_DSS_WITH_AES_128_CBC_SHA"
    [50] =>
    string(29) "TLS_DHE_RSA_WITH_SEED_CBC_SHA"
    [51] =>
    string(29) "TLS_DHE_DSS_WITH_SEED_CBC_SHA"
    [52] =>
    string(28) "TLS_DH_RSA_WITH_SEED_CBC_SHA"
    [53] =>
    string(28) "TLS_DH_DSS_WITH_SEED_CBC_SHA"
    [54] =>
    string(37) "TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA"
    [55] =>
    string(37) "TLS_DHE_DSS_WITH_CAMELLIA_128_CBC_SHA"
    [56] =>
    string(36) "TLS_DH_RSA_WITH_CAMELLIA_128_CBC_SHA"
    [57] =>
    string(36) "TLS_DH_DSS_WITH_CAMELLIA_128_CBC_SHA"
    [58] =>
    string(36) "TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256"
    [59] =>
    string(38) "TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256"
    [60] =>
    string(36) "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256"
    [61] =>
    string(38) "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256"
    [62] =>
    string(33) "TLS_ECDH_RSA_WITH_AES_128_CBC_SHA"
    [63] =>
    string(35) "TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA"
    [64] =>
    string(31) "TLS_RSA_WITH_AES_128_GCM_SHA256"
    [65] =>
    string(31) "TLS_RSA_WITH_AES_128_CBC_SHA256"
    [66] =>
    string(28) "TLS_RSA_WITH_AES_128_CBC_SHA"
    [67] =>
    string(25) "TLS_RSA_WITH_SEED_CBC_SHA"
    [68] =>
    string(33) "TLS_RSA_WITH_CAMELLIA_128_CBC_SHA"
    [69] =>
    string(35) "TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA"
    [70] =>
    string(37) "TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA"
    [71] =>
    string(33) "TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA"
    [72] =>
    string(33) "TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA"
    [73] =>
    string(32) "TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA"
    [74] =>
    string(32) "TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA"
    [75] =>
    string(34) "TLS_ECDH_RSA_WITH_3DES_EDE_CBC_SHA"
    [76] =>
    string(36) "TLS_ECDH_ECDSA_WITH_3DES_EDE_CBC_SHA"
    [77] =>
    string(29) "TLS_RSA_WITH_3DES_EDE_CBC_SHA"
    [78] =>
    string(33) "TLS_EMPTY_RENEGOTIATION_INFO_SCSV"
  }
  public $ephemeral_keys_supported =>
  bool(true)
  public $session_ticket_supported =>
  bool(false)
  public $tls_compression_supported =>
  bool(false)
  public $unknown_cipher_suite_supported =>
  bool(false)
  public $beast_vuln =>
  bool(false)
  public $able_to_detect_n_minus_one_splitting =>
  bool(false)
  public $insecure_cipher_suites =>
  class stdClass#2 (0) {
  }
  public $tls_version =>
  string(7) "TLS 1.2"
  public $rating =>
  string(13) "Probably Okay"
}

HTTP Range-Request Header in PHP parsen

Michael Kliewe — Tue, 16 May 2017 19:44:52 +0000

Hört sich eigentlich nach einer einfachen Aufgabe an: HTTP-Clients können beim Download nur Teile einer Datei anfragen, beispielsweise die ersten 500 Bytes eines Videos. Der Server announced die Unterstützung dieses Partial-Downloads mit dem Response-Header:

Accept-Ranges: bytes

Ein HTTP-Client, der partielle Downloads unterstützt kann nun mit dem folgenden Header die ersten 500 Bytes anfordern:

Range: bytes=0-500

Ein Webserver, der direkt die Datei ausliefert, tut wie ihm befohlen. Wird die angefragte Datei jedoch von einem PHP-Script ausgeliefert, muss im PHP-Script dieser Header geparst werden, damit man in PHP weiß wie viele Bytes man ausliefern soll.

Durchsucht man das Internet nach einer Antwort, findet man sehr häufig folgende Lösungen. Achtung, nicht dem RFC https://tools.ietf.org/html/draft-ietf-http-range-retrieval-00 entsprechend, nicht unbedingt nutzen:

http://stackoverflow.com/questions/2209204/parsing-http-range-header-in-php

function getRanges()
{
  return preg_match('/^bytes=((\d*-\d*,? ?)+)$/', @$_SERVER['HTTP_RANGE'], $matches) ? $matches[1] : array();
}

https://gist.github.com/codler/3906826

preg_match('/bytes=(d+)-(d+)/', $_SERVER['HTTP_RANGE'], $matches)

https://licson.net/post/stream-videos-php/

// Parse the range header to get the byte offset
$ranges = array_map(
  'intval', // Parse the parts into integer
  explode(
    '-', // The range separator
    substr($_SERVER['HTTP_RANGE'], 6) // Skip the `bytes=` part of the header
  )
);

// If the last range param is empty, it means the EOF (End of File)
if(!$ranges[1]){
  $ranges[1] = $size - 1;
}

http://stackoverflow.com/questions/2209204/parsing-http-range-header-in-php

if (isset($_SERVER['HTTP_RANGE'])) {
    if (!preg_match('^bytes=\d*-\d*(,\d*-\d*)*$', $_SERVER['HTTP_RANGE'])) {
        header('HTTP/1.1 416 Requested Range Not Satisfiable');
        header('Content-Range: bytes */' . filelength); // Required in 416.
        exit;
    }

    $ranges = explode(',', substr($_SERVER['HTTP_RANGE'], 6));
    foreach ($ranges as $range) {
        $parts = explode('-', $range);
        $start = $parts[0]; // If this is empty, this should be 0.
        $end = $parts[1]; // If this is empty or greater than than filelength - 1, this should be filelength - 1.

        if ($start > $end) {
            header('HTTP/1.1 416 Requested Range Not Satisfiable');
            header('Content-Range: bytes */' . filelength); // Required in 416.
            exit;
        }

        // ...
    }
}

All diese Beispiele unterstützen jedoch nicht die volle Funktionalität, die der Range-Header bietet. Folgende Header sind beispielsweise möglich:

Range: bytes=0-500                 // Die ersten 500 Bytes
Range: bytes=-500                  // Die letzten 500 Bytes (nicht 0-500!)
Range: bytes=500-                  // Ab Byte 500 bis zum Ende
Range: bytes=0-500,1000-1499,-200 // Die ersten 500 Bytes, von Byte 1000 bis 1499, und die letzten 200 Bytes

Die meisten Code-Snippets, die man im Internet findet, unterstützen nur Beispiel 1, bei dem ein StartByte und ein EndByte explizit hingeschrieben wird.
Manche unterstützen eine fehlende Angabe, wie in Beispiel 2, und setzen es dann auf 0, was aber falsch ist!
Fast kein Code-Snippet unterstützt die kommaseparierte Angabe von mehreren Ranges. Man fragt sich natürlich auch welche Clients so etwas brauchen und machen, aber theoretisch geht es, und die Applikation sollte im Idealfall damit umgehen können.

Ich will hier nur auf die Problematik hinweisen, eine vollständige Funktion zu erstellen, die alle 4 möglichen Varianten unterstützt, bleibt dem geneigten Leser überlassen 🙂

Wer sich mit dem Thema beschäftigt, sollte auch die Beobachtungen von Steve Souders lesen, iOS macht ganz komische Requests bei Videos…

Blog mittels Let’s Encrypt dauerhaft via SSL erreichbar

Michael Kliewe — Thu, 04 May 2017 08:04:43 +0000

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.

PHP 7: Migration eines Projekts

Michael Kliewe — Sat, 24 Oct 2015 16:30:59 +0000

Noch knapp einen Monat warten, dann erscheint ~~das Christkind~~ PHP7! Was gibt es also schöneres als sich damit zu beschäftigen und erste Erfahrungen zu sammeln?

Im Januar habe ich mir speziell den Arbeitsspeicherverbrauch von PHP 7 angeschaut, die ChangeLogs verinnerlicht, es kompiliert und ein paar Testzeilen ausgeführt. Das lief schon sehr gut, aber um größere Projekte laufen zu lassen mangelte es noch an einigen Extensions. Außerdem wollte ich ein Zend Framework 1 Projekt testen, und ZF1 war zu dem Zeitpunkt noch nicht PHP 7-kompatibel.

Doch das hat sich geändert. ZF1 ist seit Mai 2015 mit Version 1.12.12 PHP 7 kompatibel, und auch die von mir benötigten Extensions wurden umgebaut, sodass es nun PHP 7-kompatible Branches vieler Extensions auf Github gibt.

Die Vorgehendweise: Neueste PHP 7 Version herunterladen, kompilieren, Extensions herunterladen, kompilieren, und dann SPASS HABEN!

Also los! PHP 7 RC5 kompilieren

wget https://downloads.php.net/~ab/php-7.0.0RC5.tar.gz
tar -xzvf php-7.0.0RC5.tar.gz
cd php-7.0.0RC5/
./configure --prefix=/usr/local/php7.0.0RC5 --with-zlib --with-config-file-path=/usr/local/php7.0.0RC5/etc --enable-mbstring --with-mysql --with-mysqli --with-pdo-mysql --enable-zip --with-imap --with-kerberos --with-imap-ssl --with-openssl --with-jpeg-dir --with-gd --with-gettext --with-freetype-dir --enable-ftp --with-pspell --with-curl
make
make test
sudo make install
/usr/local/php7.0.0RC5/bin/php -v
/usr/local/php7.0.0RC5/bin/php -m
/usr/local/php7.0.0RC5/bin/php -i

Funktioniert wunderbar! Weiter gehts.

Extensions memcached, gearman und apcu

Diese 3 Extensions benötige ich für das Projekt. Laut GoPHP7 extensions Catalog sind sie für PHP 7 verfügbar, dann mal „Go“!

memcached Extension:

git clone https://github.com/php-memcached-dev/php-memcached.git --branch php7
cd php-memcached/
/usr/local/php7.0.0RC5/bin/phpize --with-php-config=/usr/local/php7.0.0RC5/bin/php-config
./configure --with-php-config=/usr/local/php7.0.0RC5/bin/php-config
make
make test
sudo cp modules/* /usr/local/php7.0.0RC5/lib/php/extensions/no-debug-non-zts-20151012/
sudo nano /usr/local/php7.0.0RC5/etc/php.ini
  extension=memcached.so
/usr/local/php7.0.0RC5/bin/php -m

gearman Extension:

git clone https://github.com/wcgallego/pecl-gearman.git
cd pecl-gearman/
/usr/local/php7.0.0RC5/bin/phpize --with-php-config=/usr/local/php7.0.0RC5/bin/php-config
./configure --with-php-config=/usr/local/php7.0.0RC5/bin/php-config
make
make test
sudo cp modules/* /usr/local/php7.0.0RC5/lib/php/extensions/no-debug-non-zts-20151012/
sudo nano /usr/local/php7.0.0RC5/etc/php.ini
  extension=gearman.so
/usr/local/php7.0.0RC5/bin/php -m

apcu Extension:

git clone https://github.com/krakjoe/apcu.git --branch seven
cd apcu
/usr/local/php7.0.0RC5/bin/phpize --with-php-config=/usr/local/php7.0.0RC5/bin/php-config
./configure --enable-apcu-bc --with-php-config=/usr/local/php7.0.0RC5/bin/php-config
make
make test
sudo cp modules/* /usr/local/php7.0.0RC5/lib/php/extensions/no-debug-non-zts-20151012/
sudo nano /usr/local/php7.0.0RC5/etc/php.ini
  extension=apcu.so
  extension=apc.so
  apc.enabled=1
  apc.shm_size=256M
  apc.ttl=7200
  apc.enable_cli=1
  apc.gc_ttl=3600
  apc.entries_hint=4096
  apc.slam_defense=1
  apc.serializer=php
/usr/local/php7.0.0RC5/bin/php -m
/usr/local/php7.0.0RC5/bin/php -r "echo apc_store('a', 'b');"

Im Unterschied zu früher gibt es nun zwei Extensions: apcu.so und apc.so. Man muss beide laden, dann funktionieren die „alten“ apc_* Funktionen (apc_fetch(), apc_store()…) wieder. Lädt man nur apcu.so, dann kann man nur apcu_fetch(), apcu_store() usw. nutzen. Abwärtskompatible Projekte brauchen die alten apc_* Funktionen. Lädt man nur die neue apc.so, dann erhält man die Fehlermeldung „Unable to load dynamic library: … undefined symbol: zif_apcu_store“. Lädt man beide funktioniert alles. An dieser Hürde bin ich etwas hängengeblieben…

Migrationsvorbereitungen

Ich hatte es mir schon vor 2 Monaten mal angeschaut, aber jetzt nochmal frisch: Mit Hilfe des PHP Migration Assistant PHP 7 Migration Assistant Report(MAR) mein Projekt analysiert und geschaut welche Probleme auftreten.

Es zeigte mir eine Menge Hinweise zu „funcGetArg“ (also Benutzungen von func_get_args()) an. In der aktuellen Version des PHP 7 Migration-Guides steht zu dem Thema nichts, aber es scheint so zu sein dass früher func_get_args() immer die Originalwerte der Funktionsparameter geliefert hat. Werden die Werte also VOR dem func_get_args() Aufruf verändert, so erhielt man die alten Werte. Seit PHP 7 erhält man die veränderten Werte. Da an den von php7mar bemängelten Stellen die Variablen nicht verändert wurden vor dem Aufruf sind es also alles False-Positives und damit kein Problem.

Danach kamen noch einige kritische Hinweise zu „variableInterpolation“, dies sind ernst zu nehmende Stellen die in PHP 7 zu Bugs führen. Es geht um die Änderungen bzgl. der Uniform Variablen Syntax.

Mit ein paar geschweiften Klammern an den richtigen Stellen waren die Probleme gelöst.

Dies ist meiner Meinung nach das gefährlichste Backwards-Compatibility-Problem in PHP 7: Es gibt keinerlei Deprecated Warnung, keinerlei Syntax Fehler oder ähnlich. Es ändert sich still und heimlich die Syntax, und Code der seit Jahren funktioniert hat funktioniert nun nicht mehr so wie früher. In den meisten Fällen sollte es in „Undefined Index“ oder „xxx is not a function“ münden und damit leicht zu finden und zu beheben sein, aber in Produktionsumgebungen kann es deshalb zu komischem Verhalten bis hin zu Datenverlust führen…

Insgesamt befanden sich 90% der gefundenen Hinweise in Fremdbibliotheken, nur 10 Hinweise betrafen „meinen“ Code. Es ging also auch etwas Zeit ins Land den anderen Entwicklern Bescheid zu geben, bei GitHub Issues zu eröffnen bzw. Pull-Requests zu erstellen.

(Nette Nebeninfo: Führe ich php7mar mit dem „alten“ PHP 5.6 aus, dann dauert die Code-Analyse 225 Sekunden. Mit PHP 7 nur noch 66 Sekunden! Yeah, das rockt!)

Unit-Tests laufen lassen

Nachdem ich die angezeigten Probleme behoben habe (auch hauptsächlich in externen Bibliotheken wie dompdf oder einer recht alten PEAR-Klasse, die noch PHP4-Konstruktoren hatte), konnte ich mich dran machen und die Unit-Tests laufen lassen. Und was soll ich sagen: KEINE FEHLER! Ich habe also das gute Gefühl dass ich keine großen Probleme bei der Umstellung haben werde.

Time: 2.52 minutes, Memory: 156.00Mb
Time: 3.32 minutes, Memory: 235.25Mb

Ihr dürft raten welcher der beiden Unit-Test-Runs PHP 5.6 und und welcher PHP 7 ist 😉

Interessant fand ich dass auch PHPUnit 4.6.6 funktionierte, ich hätte erwartet dass ich für PHP 7 auch die PHP 7 kompatible PHPUnit 5.0 hätte verwenden müssen. Dem war nicht so, ein Update liegt aber trotzdem nahe.

Die nächsten Schritte werden sein die Entwickler-Rechner und die Staging-Umgebung mit PHP 7 auszurüsten, sodass mehr Erfahrungen gesammelt werden, und Bugs durch die manuelle Benutzung der Applikation gesucht werden, die evtl. nicht von Unit-Tests abgedeckt sind, oder die nur in Verbindung mit einem echten Browser oder Webserver wie Apache oder PHP-FPM auftreten… Wer weiß…

Migrationsempfehlungen

Ich kann jedem nur empfehlen seinen Code vor der Umstellung auf PHP 7 mit Hilfe automatischer Tools analysieren zu lassen, um genau solche Probleme zu finden. Neben php7mar gibt es noch andere Migrations-Tools wie beispielsweise php7cc oder phan (findet glaube ich „nur“ die Uniform Variable Syntax Probleme?). Am besten alle durchlaufen lassen.

Und ganz wichtig: Den PHP 7 Migration-Guide komplett durchlesen. Je nach Größe des Projektes ist es außerdem keine schlechte Idee, erstmal nur einzelne Nutzer oder nur 1% des Traffics auf PHP 7 zu leiten, und bei Problemen schnell wieder umschalten zu können auf PHP 5.6… Ist zwar etwas mehr Aufwand, man hat aber nicht mehr so viel Angst vor der Umstellung eines größeren Projekts.

Gewinner der Verlosung für die code.talks 2015

Michael Kliewe — Wed, 27 May 2015 15:59:41 +0000

Die Zeit ist um, ein Gewinner für das code.talks 2015 Freiticket muss bestimmt werden. 14 gültige Teilnehmer sind im Pott. Die richtige Antwort lautete natürlich: „Developer Conference“.

Max hat leider an die Key ID 79D56D60 verschlüsselt, die Key ID an die verschlüsselt werden sollte lautete jedoch A08ED813. Leider hat Max nicht auf meine E-Mail reagiert, ich hatte ihn darauf hingewiesen, er kann leider nicht teilnehmen an der Verlosung.

Wer von euch 14 hat gewonnen? Das Freiticket für die Konferenz geht an:

Carsten (Link zum Kommentar)

Herzlichen Glückwunsch!

Für den Zufall habe ich die neue PHP7 Funktion random_int() genommen, endlich eine einfache Möglichkeit eine kryptografisch sichere Zufallszahl zu bekommen (wie man PHP 7 selbst kompiliert hatte ich vor ein paar Wochen beschrieben):

An euch alle sende ich eine E-Mail mit den Gutschein-Codes, die ihr einlösen könnt bei der Ticketbestellung. Ich hoffe dass ich die Codes morgen bekomme. Wir sehen uns dann alle in Hamburg im September!

Danke auch nochmal an Sarah für das Freiticket und die Rabatt-Codes!

code.talks 2015: Gutscheine und Freiticket!

Michael Kliewe — Wed, 13 May 2015 11:52:22 +0000

Die code.talks, die meines Wissens nach größte Webentwickler-Konferenz in Deutschland, findet auch dieses Jahr wieder statt und wird 1500 Entwickler begrüßen in Hamburg. Da sie in den letzten Jahren immer ausgebucht war und auch dieses Jahr wieder damit zu rechnen ist (nach 2,5 Monaten ist bereits über ein Drittel der Tickets verkauft), bin ich für euch an die Veranstalter herangetreten und habe um eine Aktion für meine Leser gebeten, und siehe da: Ich hatte Erfolg!

Ich habe Gutscheincodes für euch, und auch ein Freiticket zu vergeben. Wie ihr die bekommt steht weiter unten.

Ende September, genauer am 29. und 30. September, werden alle 8 Säle im Cinemaxx Hamburg-Dammtor gefüllt und 112 Sessions mit Themen rund um Webentwicklung (PHP, Javascript, DevOps, Big Data, UX/Frontend, Skalierung, Infrastruktur, Mobile, Startups uvm.) werden viel Wissen vermitteln. Als Sprecher sind bereits an Bord: GitHub, StackOverflow, Zalando, Wooga, Jimdo, InnoGames, Cloudera und viele mehr. Der Call-for-Papers läuft noch, und die Liste wir garantiert viele weitere interessante Leute und Firmen beinhalten die aus der Praxis erzählen. 2 Tage volles Programm, incl. Frühstück, Mittagessen, Afterwork-Party, riesige Leinwände, bequeme Sessel und Popcorn & Nachos bis zum Umfallen 😉

Auch ich werde dieses Jahr dabei sein und am Spektakel im Cinemaxx Hamburg-Dammtor teilnehmen, ich bin schon sehr gespannt! Ich hoffe euch dort auch zu sehen!

So, nun zum Wichtigsten: Rabatt-Codes und das Freiticket:

Rabatt-Code

Einen 10% Rabatt-Code erhält jeder der hier einen Kommentar hinterlässt, ich sende dann per E-Mail den Rabatt-Code raus. Easy-Peasy Geld gespart! Ab 99€ (-10%) für Studenten ist man dabei.

Freiticket

Für das begehrte Freiticket musst du etwas tun: PGP Verschlüsselung nutzen! Eigentlich eine Sache die jeder Entwickler kennen und nutzen sollte, von daher keine große Hürde oder? Beantwortet einfach folgende Frage, verschlüsselt die Antwort zusammen mit eurer E-Mail-Adresse an den PGP-Public-Key, und postet das Ergebnis im ASCII-Armor-Format hier als Kommentar! Die Frage lautet:

Wie lautete der Name der code.talks Konferenz, bevor sie in code.talks umbenannt wurde?

Die Antwort kann man ziemlich schnell herausfinden indem man auf der code.talks Website auf den passenden Menu-Punkt klickt 😉 Die Antwort, plus eure E-Mail-Adresse, verschlüsselt ihr an den oben genannten PGP-Public-Key. Beispielsweise „Die Antwort lautet: XXXXX XXXXX – meine E-Mail-Adresse: xxxxx@domain.de“. Kurz durch PGP gejagt und gepostet als Kommentar (im ASCII-Armor-Format), schon bist du im Lostopf! Zusätzlich könnt ihr das natürlich auch noch signieren, gibt aber keine Zusatzpunkte 😉

Die Verlosung findet am 27.05.2015 statt, ihr habt also 2 Wochen Zeit für die Aufgabe.

Wir sehen uns dann im September in Hamburg!

Danke an Sarah für die Rabatt-Codes und das Freiticket!

———

Wer Ende Juni noch Zeit hat sollte über den Trivago-Hackathon am 27./28. Juni nachdenken, dort werden 50 Hacker erwartet, die coole Dinge erstellen, es gibt Essen und Trinken, tolle Preise (1. Preis 5000€!), und das ganze kostenlos in Düsseldorf. Wer Bock drauf hat kann sich bis zum 6. Juni bewerben.

PHP 7 Feature Freeze

Michael Kliewe — Thu, 02 Apr 2015 08:58:19 +0000

PHP 7 wird großartig, ich freue mich schon sehr darauf! Ich hoffe dass der straffe Zeitplan eingehalten werden kann, und wir im Oktober/November die Version 7.0 in den Händen halten.

Vor 2 Wochen war der Feature-Freeze, und alle Abstimmungen die noch liefen sind beendet, es stehen also nun mehr oder minder alle Features fest die drin sein werden. Im großen und ganzen wissen wir nun was uns in PHP 7 alles erwarten wird.

Hier stelle ich folgende Features von PHP 7 vor:

Performance
Skalare Typehints
jsond
Coalesce-Operator
Engine-Exceptions
Kontext-sensitiver Lexer
Uniform Variable Syntax
Abstract Syntax Tree
Neue einheitliche Zufallsfunktionen
weiteres

1. Performance

Für mich an erster Stelle steht wahrscheinlich die stark gestiegene Performance. In bisherigen Versionen wurde PHP „nur“ jeweils 5-10% schneller, was kontinuierlich auch ganz gut ist, aber PHP 7 setzt einen oben drauf. Wie bereits in anderen Blogartikeln (1 2 3) aufgezeigt werden wir ein zwischen 70% und 120% schnelleres PHP bekommen gegenüber PHP 5.6. Damit wird PHP 7 ungefähr genauso schnell sein wie Facebooks HHVM. Geschenkte Performance ohne dass man seine Applikationen umbauen muss ist immer gern gesehen 😉

2. Skalare Typehints

Das nächste sehr interessante Feature werden die skalaren Typehints sein. Mit der Zeit werde ich diese sicherlich einsetzen in Projekten, in denen ich selbst die PHP-Version bestimmen kann und keine Rücksicht auf alte Systeme nehmen muss. Mit den Typehints stark verbunden sind auch die Return Types, man kann in Zukunft einer Funktion also einen Typ zuordnen die sie zurückzuliefern hat.
Die skalaren Typehints waren eine riesen Diskussion. Jeder will sie, aber man war sich nicht einige wie „stark“ sie sein sollen. Nun hat man sich auf einen Dual-Mode geeinigt, mit dem jeder hoffentlich halbwegs glücklich werden wird. Hierzu werde ich bald noch einen separaten Blogartikel verfassen, weil das ganze ein recht umfangreiches Thema ist.

3. jsond

PHP wird eine neue Implementation der JSON-Extension bekommen. Damit werden Lizenzprobleme gelöst, und die neue Variante ist in vielen Fällen (nicht allen) auch schneller, zwischen 20% und 250%. Das ganze passiert unter der Haube, der einzige Unterschied zu vorher ist, dass man json in Zukunft nicht mehr einzeln nachinstallieren muss bei den meisten Linux-Distributionen, sondern es fest eingebaut mitgeliefert wird.

4. Coalesce-Operator

Der sogenannte Coalesce-Operator könnte auch recht hilfreich sein, man wird sich sicher ein paar Wochen an das „Aussehen“ gewöhnen müssen, aber ich glaube er gefällt mir sehr gut:

// vorher:
$username = isset($_GET['user']) ? $_GET['user'] : 'nobody';
// mit PHP 7:
$username = $_GET['user'] ?? 'nobody';

5. Engine-Exceptions

Die Engine von PHP darf in Zukunft auch Exceptions werfen. Vorbei sind also die Zeiten von „Fatal errors“, zukünftig kann man diese Fehler abfangen und sie behandeln. Beispiel:

function call_method($obj) {
    $obj->method();
}
call_method(null); // oops!

Aktuell bricht der Code ab mit der Fehlermeldung:

Fatal error: Call to a member function method() on a non-object in /path/file.php on line 4

Fatale Fehler sind immer doof, denn evtl. wichtiger „Aufräumcode“ wird nicht mehr aufgerufen. Das kann böse enden.

Und so kann man in Zukunft diese Exception abfangen und darauf reagieren:

try {
    call_method(null); // oops!
} catch (EngineException $e) {
    echo "Exception: {$e->getMessage()}\n";
}

6. Kontext-sensitiver Lexer

In Zukunft wird es weniger reservierte Wörter für Funktionsnamen geben. Das ganze nennt sich kontext-sensitiver Lexer und bedeutet dass reservierte Wörter wie „for“ oder „list“ nicht mehr global verboten werden, sondern je nach Kontext des Gebrauchs erlaubt sein werden. Mit PHP 7 wird folgender Code möglich sein, der aktuell nicht erlaubt ist weil „for“, „and“, „or“, „list“ reserviert sind und nicht genutzt werden dürfen:

$projects = Finder::for('project')
        ->where('name')->like('%secret%')
        ->and('priority', '>', 9)
        ->or('code')->in(['4', '5', '7'])
        ->and()->not('created_at')->between([$time1, $time2])
        ->list($limit, $offset);

7. Uniform Variable Syntax

Durch die Uniform Variable Syntax wird man einige schöne neue Zeilen Code schreiben können, für die man bisher häufig temporäre Variablen brauchte. Einige Beispiele:

$foo()['bar']()
getStr(){0}
$foo->bar()::baz()
$foo->bar()()

8. Abstract Syntax Tree

Ein weiteres Feature unter der Haube von PHP 7 wird der Abstract Syntax Tree (AST) sein. Das Voting war mit 47:0 sehr eindeutig 😉 Bisher produziert der PHP-Parser direkt OpCodes. In Zukunft wird der Parser als Zwischenstruktur den AST generieren, der dann erstens einige schöne Optimierungen des Codes erlaubt, aber auch entkoppelt er damit den Parser vom Compiler, was die Wartung einfacher machen wird. Wenn der AST zugänglich gemacht wird für Userland/Extensions, dann wird man damit auch super Statische Analyzer bauen könne. Und nebenbei bringt er auch nochmal mehr Performance. Wir dürfen gespannt sein!

9. Neue einheitliche Zufallsfunktionen

PHP hat noch keinen einheitlichen Cryptographically secure pseudo-random number generator (CSPRNG), und wird nun einen bekommen. Kein Gehampel mehr mit openssl_random_pseudo_bytes(), mcrypt_create_iv() und /dev/urandom. Es hilft hoffentlich dabei, dass User bei kryptografischen Aufgaben nicht mehr auf rand() oder ähnliches zurückgreifen sondern die „richtige“ Funktion dafür nutzen: random_bytes() bzw. random_int().

10. weiteres

Zusätzlich zu den genannten Features gibt es noch eine Menge weiterer Änderungen: Spaceship-Operator, Generator Delegation, besserer 64bit Support, Verbieten von mehreren default-Blöcken, Gruppen-„use“-Deklarationen, und und und. Etwas aufpassen muss man bei den neuen reservierten Typen (int, float, bool, string, true, false, null), die nun nicht mehr als Klassennamen, Interfacenamen oder Namespacebezeichnungen genutzt werden würden.

Unter anderem werden auch einige alte Zöpfe abgeschnitten wie z.B. einige alte SAPIs und Extensions und die alten ASP tags (<%) und Script-Tags (<script language=php>) werden entfernt, alte PHP4-Konstruktoren werden entfernt, und noch mehr Extensions (ext/mysql, ext/ereg) und Funktionen die bereits als DEPRECATED markiert waren werden endlich rausgeschmissen. E_STRICT wird auch entfernt da es kaum genutzt wurde und wenig Sinn macht.

In PHP 7 wird man auch weiter weggehen von PEAR und Pecl, hin zu Composer und Pickle. Sich darauf vorzubereiten und daran zu gewöhnen ist sicher auch nicht verkehrt.

Fazit

In den nächsten Monaten ist Testen angesagt, je eher man sich mit den Änderungen befasst und seinen Code schonmal langsam auf PHP 7 vorbereitet, beispielsweise also von mysql_*-Funktionen befreit, umso stressfreier wird der Umstieg Ende des Jahres. Auf GitHub wird die aktuelle PHP 7 nightly Version bereits von Travis-CI unterstützt, man kann also bereits seinen Code dort testen lassen. Auch gibt es noch viel zu tun um alle benötigten PHP-Extensions für PHP 7 fertig zu machen, prüft also ob alle eure benötigen Extensions in der Liste sind, und helft im Idealfall dabei sie kompatibel zu machen!

Go, PHP 7!

Ein altes Navigationsmenu sortieren

Michael Kliewe — Wed, 11 Mar 2015 21:58:12 +0000

Ich habe eine kleine Programmieraufgabe für euch.

Ich habe ein altes Projekt, in dem ich folgende Navigationsstruktur in der Datenbank habe:

menuid	parentid	title	level	sortid
1	3	Wurm 1.1	2	10
2	6	Vogel 2.1	2	30
3	0	Tiger 1	1	10
4	6	Hund 2.2	2	40
5	3	Katze 1.2	2	11
6	0	Pferd 2	1	20
7	1	Baer 1.1.1	3	0
8	3	Schwein 1.3	2	12
9	4	Esel 2.2.1	3	0

Nun möchte ich diese Menüpunkte sortiert ausgeben, und zwar in der folgenden Reihenfolge:

Tiger 1
  Wurm 1.1
    Baer 1.1.1
  Katze 1.2
  Schwein 1.3
Pferd 2
  Vogel 2.1
  Hund 2.2
    Esel 2.2.1

Die Sortierreihenfolge muss anhand der menuid, parentid, level und sortid berechnet werden. Eine parentid verweist auf den Elternknoten, sprich er ist darunter einzusortieren. Zwei Einträge mit der selben parentid sind nach der Spalte sortid zu sortieren.

Der Wurm ist ein Kindknoten vom Tiger, der Bär ist ein Kindknoten vom Wurm. Die Katze ist auch ein Kindknoten vom Tiger, hat aber die höhere sortid, muss also nach dem Wurm einsortiert werden.

Es ist ein altes Projekt mit dieser Struktur, und die Frage ist wie man das am einfachsten und schnellsten sortiert?

Geht das ganze mit einem SQL-Query? Das wäre natürlich die beste Lösung, aber mir ist kein solcher Query eingefallen der das Problem lösen könnte.

Also muss es in PHP sortiert werden. Ich habe das ganze in ein PHP-Array gepackt und hier für euch zum Spielen bereitgestellt:

http://3v4l.org/PTuRc

Dort könnt ihr an dem Algorithmus arbeiten, sodass aus dem Ursprungs-Array das Ziel-Array wird. Nachdem ihr „eval()“ gedrückt habt könnt ihr einfach die URL hier in die Kommentare packen, nach jedem Druck auf „eval()“ wird das ganze gespeichert und versioniert.

Ich bin gespannt auf eure Lösungen!

Erstaunlich langsam beim Kopieren einer Datei auf ein NFS-Share

Michael Kliewe — Tue, 03 Mar 2015 09:46:16 +0000

Heute mal etwas skurriles. Eigentlich eine Alltagsaufgabe, die man mit einem 2-Zeiler lösen kann, aber ich bin doch erstaunt über das Problem und die Lösung. Es geht darum, eine Datei auf einem NFS-Share abzulegen, das vorher per PUT zum Webserver hochgeladen wurde. Wahrscheinlich hat man das selbe Problem auch wenn die Datei per POST-Formular hochgeladen wurde.

Folgender Aufruf lädt eine Datei via PUT auf einen Webserver:

curl -T 100mb.test http://localhost/put.php

Mein einfaches Testscript, das die Datei auf das NFS-Share legen soll, sieht so aus:

<?
$putdata = fopen("php://input", "r");
file_put_contents('/mnt/nfs/100mb.zip', $putdata);

Es dauert knapp 26 Sekunden bis das Script fertig ist bei einer 100MB Datei. Das muss doch schneller gehen! 4MB/s ist viel zu wenig für ein Gigabit-Netzwerk und einen schnellen NFS-Storage.

Nächster Versuch:

<?
$putdata = fopen("php://input", "r");
file_put_contents('/tmp/100mb.zip', $putdata);
copy('/tmp/100mb.zip', '/mnt/nfs/100mb.zip');

Hier gehe ich den Umweg über die lokale Festplatte. Ich speichere die Datei erst lokal auf dem Webserver, und kopiere sie dann auf das NFS-Share. Das file_put_contents() auf die lokale Festplatte dauert knapp 1 Sekunde, das ist kein Problem. Aber der copy()-Befehl ist wieder recht langsam, 21 Sekunden, sprich 5MB/s. Was ist denn nur los?

(Die PHP-Funktion rename(), die normalerweise dafür das ist eine Datei zu verschieben, kann ich nicht nutzen da man die Funktion nur zum Verschieben auf einer Partition nutzen kann, und ich die Datei auf ein NFS-Share ablegen möchte.)

Um mich zu vergewissern dass es nicht am Netzwerk oder am NFS-Storage liegt mache ich einen Test per SSH:

time cp 100mb.zip /mnt/nfs/100mb.zip

real    0m4.236s
user    0m0.007s
sys     0m0.144s

Aha! Es geht doch! 4 Sekunden, sprich 25MB/s, das ist doch schon viel besser.

Nächster Versuch:

<?
$putdata = fopen("php://input", "r");
file_put_contents('/tmp/100mb.zip', $putdata);
shell_exec("cp /tmp/100mb.zip /mnt/nfs/100mb.zip");

Die Laufzeit dieses Scripts ist nur 5 Sekunden! Ich muss also die Datei erstmal lokal auf die Festplatte schreiben, um sie dann mit dem System-Befehl „cp“ auf das NFS-Share zu kopieren.

Warum ist „cp“ so viel schneller als copy()? Ich hätte getippt dass PHP intern etwas ähnliches macht oder sogar das selbe? Oder ist die „cp“-Funktion deutlich im Vorteil weil sie den Filesystem-Cache oder Kernel-Cache oder ähnliches ausnutzen kann, was die copy()-Funktion nicht tut? Oder liegt es daran dass sowohl file_put_contents() als auch copy() intern immer in kleinen Häppchen vorgeht: „4KB lesen, 4KB schreiben, 4KB lesen, 4KB schreiben…“, und dass das sehr unperformant für eine NFS-Verbindung ist?

Kann mir das jemand erklären? Warum ist PHP so schlecht darin eine Datei auf ein NFS-Share zu kopieren?

Ich nutze in diesem Fall PHP 5.5.9-1ubuntu4.6

Ich bin dankbar über jeden Ratschlag.

Eine PLZ-Umkreissuche in PHP

Michael Kliewe — Sun, 22 Feb 2015 15:22:33 +0000

Ich bekam vor ein paar Tagen folgende kleine Programmieraufgabe:

Gegeben ist eine große Datenbank mit > 300.000 Kunden, worin jeder Kunde eine Postleitzahl hinterlegt hat. Firma X möchte nun diese Kunden kontaktieren, aber nur diejenigen die in 35km Umkreis um eine seiner 42 Filialen wohnen.

Tja, wie macht man das?

Die einfachste Lösung die mir in den Sinn kam war eine Geo-Datenbank zu nutzen, in der deutsche Postleitzahlen und deren Latitude+Longitude hinterlegt sind. Dann durchlaufe ich die gegebenen 42 Postleitzahlen der Filialen und berechne jeweils die Distanz zu allen 17052 Postleitzahlen die es in Deutschland gibt. Wenn die Distanz unter 35 Kilometer beträgt kommt die PLZ in ein Ergebnis-Array. Am Ende filtere ich noch die doppelten raus, fertig.

Aufgabe 1 war also eine Geo-Datenbank mit Postleitzahlen für Deutschland zu finden. Ich wurde fündig bei der OpenGeoDB.

Aufgabe 2 war doch etwas schwieriger als gedacht: Den Datenbank-Dump zu importieren in meine MySQL-Datenbank und in ein Format zu bekommen das ich benutzen kann. Um die OpenGeoDB in meine MySQL zu importieren musste ich leider nicht nur einen SQL-Dump importieren, sondern ein paar Schritte beachten, die aber nach etwas Suche im Wiki beschrieben sind. Die Schritte lauten:

Ersetzen von „TYPE=InnoDB“ durch „ENGINE=InnoDB“, da ich eine MySQL 5.6. Datenbank habe
opengeodb-begin.sql importieren
DE.sql importieren
DEhier.sql importieren
opengeod-end.sql importieren

Gerade bei den beiden großen Dumps musste ich zwischendurch abbrechen, „BEGIN;“ und „COMMIT;“ einfügen oben und unten, und dann nochmal laufen lassen, denn ohne diese Transaktion war der Import sehr sehr langsam.

Aufgabe 3: Dann hatte ich die Rohdaten in meiner Datenbank. Die OpenGeoDB ist relativ groß da sie viele Daten zu Städten, Landkreisen, Postleitzahlen usw. enthält. Ich habe anhand dieser Anleitung (die genau das zeigt was ich vorhabe) als nächstes eine Zwischentabelle „zip_coordinates“ erstellt, die nur Postleitzahlen und Latitude+Longitude enthält.

Folgendes kleines Script lieferte mir dann die Ergebnisse, die ich haben wollte:

<?php
$sourceZipCodes = array(59302,50667,38855,57271,38518,23730);
$distance = 35;
$resultingZipCodes = array();

$dbh = new PDO('mysql:host=127.0.0.1;dbname=opengeodb', 'opengeodb', 'secretpassword');
$getZcIdStmt = $dbh->prepare("SELECT zc_id
                        FROM zip_coordinates
                        WHERE zc_zip = :zip");
$getZipList = $dbh->prepare("SELECT
                              dest.zc_zip,
                              dest.zc_location_name,
                              ACOS(
                                   SIN(RADIANS(src.zc_lat)) * SIN(RADIANS(dest.zc_lat))
                                   + COS(RADIANS(src.zc_lat)) * COS(RADIANS(dest.zc_lat))
                                   * COS(RADIANS(src.zc_lon) - RADIANS(dest.zc_lon))
                              ) * 6380 AS distance
                          FROM zip_coordinates dest
                          CROSS JOIN zip_coordinates src
                          WHERE src.zc_id = :zcid
                          AND dest.zc_id <> src.zc_id
                          HAVING distance < :distance
                          ORDER BY distance;");

foreach ($sourceZipCodes as $sourceZipCode) {
    $getZcIdStmt->execute(array(':zip' => $sourceZipCode));
    $row = $getZcIdStmt->fetch();

    $getZipList->execute(array(':zcid' => $row['zc_id'], ':distance' => $distance));
    $zipList = $getZipList->fetchAll();

    foreach ($zipList as $zipResult) {
        if (!in_array($zipResult['zc_zip'], $resultingZipCodes)) {
            $resultingZipCodes[] = $zipResult['zc_zip'];
        }
    }
}

echo join(',', $resultingZipCodes);

Den etwas komplizierteren SQL-Query habe ich aus dem besagten Wiki-Artikel, den hätte ich selbst nur schwerlich erstellen können in kurzer Zeit.

Das war es eigentlich schon. Aus der Liste mit den gegebenen 42 Postleitzahlen kam eine Liste mit 3028 Postleitzahlen heraus, die ich dann gegen die Kundendatenbank habe laufen lassen, und schon wusste ich wie viele und welche Kunden im 35km Umkreis der 42 Filialen wohnen.

Bevor jemand fragt: Die OpenGeoDB enthält neben den Daten für Deutschland auch Daten aus Österreich, Belgien, Schweiz und Lichtenstein. Damit müsste das ganze äquivalent möglich sein.

Aktueller Stand von PHP 7: Deutlich geringerer Arbeitsspeicherverbrauch

Michael Kliewe — Wed, 21 Jan 2015 11:56:47 +0000

Ich möchte mir den aktuellen Stand von PHP 7 anschauen (Stand 20. Januar 2015), und habe dazu im letzten Blogartikel gezeigt wie man PHP 7 direkt aus dem Git-Repository selbst kompiliert. Ich habe nun also PHP 7 zur Verfügung:

$ sapi/cli/php -v
PHP 7.0.0-dev (cli) (built: Jan 20 2015 23:13:58)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v3.0.0-dev, Copyright (c) 1998-2015 Zend Technologies

Vergleichen werde ich mit der aktuell unter Ubuntu 14.04 LTS verfügbaren Version PHP 5.5.9:

$ php -v
PHP 5.5.9-1ubuntu4.5 (cli) (built: Oct 29 2014 11:59:10)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.5.0, Copyright (c) 1998-2014 Zend Technologies
with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies

Da die eine Version selbst kompiliert ist und die andere von Ubuntu stammt sind sie in diesem Fall nicht ideal für einen Vergleich nutzbar, aber auf ein paar Bytes oder Prozente soll es mir nicht ankommen.

PHP 7 hat in diesem Fall keinen OPcache aktiviert, aber den benötige ich für meine Tests auf der Kommandozeile (CLI) nicht. Möchte man PHP via Webserver (PHP-FPM usw.) nutzen sollte man darauf achten den OPcache per php.ini zu aktivieren, um vergleichbare Ergebnisse zu bekommen.

Folgendes kleines Testscript werde ich mit beiden Versionen laufen lassen:

<?php

$a = array();
for ($i=1; $i<2000000; $i++) {
    $a[] = rand(100000000, 999999999);
}

echo "not real: ".(memory_get_peak_usage(false)/1024/1024)." MiB\n";
echo "real: ".(memory_get_peak_usage(true)/1024/1024)." MiB\n";

Und hier sind die jeweiligen Ergebnisse:

$ time php arraytest.php
not real: 275.61262512207 MiB
real: 276 MiB

real    0m1.119s
user    0m0.763s
sys     0m0.190s

$ $ time sapi/cli/php arraytest.php
not real: 96.334381103516 MiB
real: 98 MiB

real    0m0.414s
user    0m0.290s
sys     0m0.068s

Ui ui ui! Mit PHP 7 reduziert sich der Arbeitsspeicherverbrauch bei diesem Testarray (2.000.000 Zahlen als Values) um satte 65%!

Weniger Arbeitsspeicherverbrauch heißt nicht nur dass „mehr PHP“ auf einem Server laufen kann, weniger Arbeitsspeicher heißt auch dass weniger Daten im Arbeitsspeicher abgelegt werden müssen, und weniger daraus gelesen werden muss, es impliziert also automatisch auch einen Performance-Boost. Wie man an den Laufzeiten erkennen kann ist PHP 7 auch ungefähr 3 Mal so schnell!

In richtigen Applikationen wie WordPress oder Typo3 usw. ist der Unterschied nicht ganz so groß, da spricht man von ungefähr 50% bis 110% mehr Laufzeit-Performance. Denn bei größeren Applikationen wird auch viel Zeit beim Warten auf die Datenbank verbraucht, und Warten ist genauso langsam in PHP 5.5 wie in PHP 7 😉

All diese Verbesserungen sind darauf zurückzuführen wie PHP intern Variablen und Arrays organisiert, den sogenannten ZVALs und Hashtables. Die detaillierten Informationen über die Änderungen an der Hashtable-Implementation von PHP 7 sollte man sich mal zu Gemüte führen.

Edit: Auf Wunsch habe ich auch noch PHP 5.6 getestet, hier die Ergebnisse:

wget http://de2.php.net/get/php-5.6.5.tar.gz/from/this/mirror
mv mirror php-5.6.5.tar.gz
tar -xzvf php-5.6.5.tar.gz
cd php-5.6.5/
./configure --prefix=/usr/local/php-5.6.5 --with-zlib --with-config-file-path=/usr/local/php-5.6.5/etc --enable-mbstring --with-mysql --with-mysqli --with-pdo-mysql --enable-zip --with-imap --with-kerberos --with-imap-ssl --with-openssl --with-jpeg-dir --with-gd --with-gettext --with-freetype-dir --enable-ftp --with-pspell --with-curl
make

$ sapi/cli/php -v
PHP 5.6.5 (cli) (built: Jan 23 2015 00:46:40)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2014 Zend Technologies

$ time sapi/cli/php -d memory_limit=512M arraytest.php
not real: 275.61260223389 MiB
real: 276 MiB

real    0m1.023s
user    0m0.663s
sys     0m0.170s

PHP 5.6 ist also leicht schneller als PHP 5.5, aber zu PHP 7 ist es immer noch ein richtig großer Unterschied.

Den aktuellen Stand von PHP 7 (pre-alpha) selbst kompilieren und testen

Michael Kliewe — Wed, 21 Jan 2015 11:54:59 +0000

PHP 7 wird kommen, nach aktuellem Plan wird es Mitte Oktober 2015 soweit sein. Ich persönlich bin da noch etwas skeptisch ob das zeitlich klappen kann, aber ich hoffe dass es noch 2015 sein wird.

PHP 7 wird sehr große interne Änderungen an der Zend Engine mit sich bringen, die Performance wird ungefähr verdoppelt und dann auf dem Niveau von HHVM sein. Aber auch der Arbeitsspeicherbedarf wird radikal reduziert. Genau um letzteres zu prüfen habe ich den aktuellen PHP 7-Stand selbst kompiliert, und möchte hier zeigen dass es sehr einfach geht und ihr das auch machen solltet!

Wir werden PHP 7 aka phpng direkt aus dem GIT-Repository holen und kompilieren, folgende Schritte sind dazu nötig:

cd /tmp/
git clone https://github.com/php/php-src.git
cd php-src
./buildconf
./configure --prefix=/usr/local/phpng --with-zlib --with-config-file-path=/usr/local/phpng/etc --enable-mbstring --with-mysql --with-mysqli --with-pdo-mysql --enable-zip --with-imap --with-kerberos --with-imap-ssl --with-openssl --with-jpeg-dir --with-gd --with-gettext --with-freetype-dir --enable-ftp --with-pspell --with-curl
make
make test

Falls es Fehler beim configure bzgl. re2c oder bison gibt, unter Ubuntu installiert man diese folgendermaßen:

sudo apt-get install bison
sudo apt-get install re2c

Falls pspell nicht gefunden werden kann:

configure: error: Cannot find pspell

sudo apt-get install libpspell-dev

Nach dem „make test“ ist PHP 7 auf Kommandozeilenebene nutzbar:

$ sapi/cli/php -v
PHP 7.0.0-dev (cli) (built: Jan 20 2015 23:13:58)
Copyright (c) 1997-2015 The PHP Group
Zend Engine v3.0.0-dev, Copyright (c) 1998-2015 Zend Technologies

Wer PHP danach richtig installieren möchte macht noch ein „sudo make install“, dann wird PHP im oben definierten Prefix-Verzeichnis installiert.

Ich bin mir sehr sicher dass ich Mitte des Jahres, wenn es die ersten Alpha- und Beta-Versionen gibt, ausgiebig Applikationen testen werde, damit möglichst wenige Bugs in PHP 7 drin sind, und es hoffentlich bereits Ende 2015 auf Produktionsmaschinen einsetzbar sein wird. Ich sage schonmal voraus dass ich dann breit grinsend vor den Maschinen hocken werde und die neuen schnellen Webseiten und Scripte bewundern werde 😉

Im nächsten Blogartikel geht es um meinen kleinen Vergleich des Memory-Verbrauchs.

SSLv3: Uralt, bröckelig, abschalten!

Michael Kliewe — Tue, 14 Oct 2014 22:18:42 +0000

[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.

Da nun aber die Gerüchteküche kocht und es dort wirklich etwas zu geben scheint, haben wir es kurzerhand nun deaktiviert, um der Veröffentlichung zuvorzukommen. Da es pro Tag nur knapp 20 Verbindungen gab die noch SSLv3 genutzt haben sind so wenige Kunden betroffen dass wir es verantworten können.

Auch ihr solltet darüber nachdenken SSLv3 abzuschalten, allem voraus in euren Webservern.

SSLv3 in nginx deaktivieren

Ich empfehle für nginx aktuell die folgenden SSL-Einstellungen:

ssl_protocols             TLSv1.1 TLSv1.2 TLSv1;
ssl_ciphers               ECDH+AESGCM:ECDH+AES256:ECDH+AES128:DH+3DES:RSA+3DES:!ADH:!AECDH:!MD5;
ssl_prefer_server_ciphers on;
ssl_session_cache         shared:SSL:10m;
ssl_session_timeout       10m;

SSLv3 im Apache deaktivieren

Für den Apache müsste es folgende Einstellung sein wenn ich das richtig sehe. Habe leider keinen Apache mit SSL parat zum testen:

# apache bis 2.2.22
SSLProtocol all -SSLv2 -SSLv3
 
# apache ab 2.2.23
SSLProtocol TLSv1 TLSv1.1 TLSv1.2

SSLv3 in Dovecot deaktivieren

Seit Version 2.1 lässt sich SSLv3 so deaktivieren:

ssl_protocols = !SSLv2 !SSLv3

Ältere Versionen muss man manuell patchen, aber hoffentlich verwendet keiner von euch mehr so alte Versionen.

SSLv3 in Postfix deaktivieren

smtpd_tls_protocols = !SSLv2, !SSLv3 
smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtp_tls_protocols = !SSLv2, !SSLv3

SSLv3 in HAProxy deaktivieren:

bind :443 ssl crt <crt> ciphers <ciphers> no-sslv3

SSLv3 in Firefox deaktivieren:

Einfach in der Adressleiste about:config eintippen, dann nach „tls“ suchen und die Option security.tls.version.min auf 1 stellen.

SSLv3 in Chrome deaktivieren:

In Chrome ist es ein bisschen aufwändiger, da man den Browser mit der Kommandozeilen-Option –ssl-version-min=tls1 starten muss. Am einfachsten legt man sich einen entsprechenden Shortcut an.

SSLv3 im Internet Explorer deaktivieren:

Im Internet Explorer kann man in den Internetoptionen unter Erweitert SSL 3.0 verwenden abwählen – und bei der Gelegenheit auch gleich TLS 1.1 und 1.2 aktivieren.

Wie teste ich ob SSLv3 unterstützt wird?

Webseiten kann man am einfachsten mit dem Qualys SSL-Tester online prüfen:

https://www.ssllabs.com/ssltest/index.html

So prüft man ob seine Dienste noch SSLv3 unterstützen:

openssl s_client -crlf -ssl3 -connect imap.mail.de:993
openssl s_client -starttls smtp -crlf -ssl3 -connect mx01.mail.de:25
openssl s_client -starttls smtp -crlf -ssl3 -connect smtp.mail.de:587
openssl s_client -ssl3 -connect mail.de:443

Natürlich muss dort der passende Hostname des zu testenden Servers eingegeben werden.

Wenn SSLv3 nicht unterstützt wird, dann wird die folgende Fehlermeldung angezeigt und die Verbindung kommt nicht zustande:

New, (NONE), Cipher is (NONE)
Secure Renegotiation IS NOT supported

Kommt eine Verbindung zustande sieht man folgende Informationen:

New, TLSv1/SSLv3, Cipher is ECDHE-RSA-AES256-SHA
Server public key is 2048 bit
Secure Renegotiation IS supported
Compression: NONE
Expansion: NONE
SSL-Session:
Protocol: SSLv3