Wir waren letzte Woche Mittwoch und Donnerstag auf dem CloudFest und haben tolle Leute getroffen und einen regen Austausch gepflegt. Im Folgenden stelle ich ein tolles Projekt bzw. einen tollen Verein vor und skizziere, was sich bei lima-city in den nächsten Wochen und Monaten tun wird.

Der CMS Garden e.V. ist ein Verein, der sich um die „Förderung von Bildung, Wissenschaft und Forschung, insbesondere auf den Gebieten Content-Management und Open-Source-Software“ kümmert. Das bedeutet im Wesentlichen, dass sie auf Veranstaltungen und Messen über CMS‘ informieren und ein Netzwerk von CMS-Interessierten aufbauen. CMS Garden hatte einen Stand mit einem sehr freundlichen Team und wir haben uns toll ausgetauscht. Wir unterstützen diese engagierten Menschen nun finanziell mit einem kleinen monatlichen Dauerauftrag. Der CMS Garden ist auf diversen Veranstaltungen vertreten, gibt die Gartenfibel heraus und hat auch Software-Projekte, also schaut mal rein! Viele Grüße an das Team!

Als nächste größere Veränderung werden wir nach Abschluss unserer Testphase endlich SSH für den Webspace anbieten. SSH ist wird für alle bezahlten Webhosting-Pakete verfügbar sein. Die SSH-Zugänge sind für die Verwaltung des Webspace konzipiert und bringen selbstverständlich Unterstützung für Composer und git mit. Mit SSH wird die Verwaltung moderner CMS für Profis wesentlich einfacher und typische Administrationsaufgaben, vom Installieren von Software mit wget & tar bis hin zum Einspielen von Updates oder Bedienen von „Konsolen“-Binaries für Shops wie z.B. Magento lassen sich schneller und bequemer durchführen. Und wem das durch den Kopf schießt: nein, wir machen keinen chroot-Unsinn, die Zauberwörter heißen AppArmor und seccomp. Wir haben schon eine ganze Reihe an Kunden, welche die SSH-Zugänge testen, aber wenn auch Du daran interessiert bist, schicke uns bitte eine kurze Mail an den Support.

Zudem werden wir unser Partnerprogramm (derzeit nur in der Verwaltung über „Kunden werben“ zu finden) mit mehr Informationen auf der Webseite präsentieren und auf der Webseite auch über die neu kommenden Partner- & Reseller-Lösungen informieren. Im Partnerprogramm können unsere Kunden ihre Freunde, Bekannte oder Geschäftspartner werben und erhalten 10% Umsatzbeteiligung auf alle Umsätze des geworbenen Kunden. Unsere Partner- & Reseller-Lösungen gehen einen Schritt weiter und haben für verschiedene Hosting-Anwendungsfälle Lösungen. Das reicht von Bildungsträgern, die Webspace für Schulungen und Kurse benötigen, bis hin zu Agenturen, die ihre Kunden einfacher hosten wollen. Unsere Lösung für Bildungsträger ist schon im Einsatz und die Agenturlösung wird in den nächsten Wochen mit den ersten Kunden ausprobiert.

Beispiel: EV-Zertifikat für lima-city

Beim Thema SSL wird es etwas bunter: neben dem kostenlosen Let’s Encrypt werden wir weitere Optionen für SSL anbieten. Die zunehmende Verbreitung von SSL hat dafür gesorgt, dass das „sicher“ bzw. Schloss-Symbol in der Adresszeile nicht mehr den selben Stellenwert besitzt wie vor der großen Verbreitung von SSL. Wer sich also hervorheben möchte muss dies mit einem Extended Validated Zertifikat tun, das den Firmennamen in der Adresszeile anzeigt. Da der Prozess, ein solches Zertifikat zu beantragen, deutlich komplexer und aufwändiger ist als für normale SSL-Zertifkate (die Firma muss z.B. im Handelsregister registriert sein, die Existenz der Firma wird geprüft, es wird häufig zur Verifizierung ein Test-Anruf durchgeführt, ggf. müssen von einem Anwalt, Notar oder Steuerberater eine Bestätigung erstellt werden etc.) muss man hier zwar Geld und Zeit investieren, kann dafür aber auch mit mehr Vertrauen rechnen.

Als kleines Nebenprojekt haben wir zudem noch die Multi-Faktor-Authentifizierung mit YubiKeys auf der Liste. Kunden, die unsere Partner- und Reseller-Lösungen benutzen,  bekommen sogar den ersten YubiKey von uns gratis – denn wenn wir zusammenarbeiten, dann am Besten auf einer sicheren Grundlage.

So weit zu unserem groben Fahrplan für die kommenden Wochen und Monate. Für Fragen und Anregungen stehe ich gerne zur Verfügung – einfach eine Mail an den Support senden und wir reden darüber :-).

Webseiten-Betreiber, die unser Webhosting nutzen, müssen sich nicht um SSL kümmern. Unser System stellt alle Zertifikate, die für verschlüsselte Verbindungen nötig sind, automatisch und kostenlos über das großartige Let’s Encrypt aus, wenn die Webseite das erste Mal per SSL aufgerufen wird. Nur diese erste Verbindung zeigt einen Zertifikatsfehler an, doch sobald das Zertifikat vorhanden ist, wird es automatisch verlängert. Diese Technik hat den Aufwand, den unsere Kunden für SSL betreiben müssen, fast auf Null reduziert.

Eine Webseite per SSL erreichbar zu machen ist allerdings nur ein Teil-Lösung. Die Webseite darf nämlich – und das ist der springende Punkt – auch nicht mehr per HTTP (also unverschlüsselt) aufrufbar sein. Ist die Seite auch über HTTP erreichbar sind Downgrade-Attacken (ein Angreifer erzwingt eine unverschlüsselte Verbindung) möglich. Der Angreifer kann dann weiterhin Daten der Verbindung auslesen und verändern. Ein sicheres Setup erfordert also, dass die Webseite ausschließlich per SSL erreichbar ist.

Derzeit hosten wir 318.653 Webseiten auf unseren Webhosting-Infrastruktur. Von diesen haben nur 35.844 (11,2 %) Webseiten „SSL erzwingen“ aktiviert. Obwohl bereits ca. 34% der Requests per HTTPS geladen werden ist diese Zahl deutlich zu gering. Grundsätzlich gibt es nur einen Grund, weshalb „SSL erzwingen“ nicht aktiv sein sollte: wenn unsichere Ressourcen (z.B. Bilder, Javascript, CSS etc) geladen werden müssen, und der Server, auf dem diese Ressourcen liegen, kein HTTPS unterstützt. Das ist aber immer seltener der Fall. Zudem wird spätestens mit der EU-DSGVO eine unverschlüsselte Übertragung personenbezogener Daten (und dazu reicht schon ein Kontakt- oder Anmeldeformular) extrem problematisch. Google Chrome wird auch in naher Zukunft bei Webseiten, die nicht per SSL geladen werden, ein „nicht sicher“ in der Adresszeile zeigen. Es ist höchste Zeit, SSL zu nutzen!

Wir aktivieren daher schrittweise zwischen dem 19.3. und dem 23.3. für alle bei uns gehosteten Webseiten „SSL erzwingen“. In 99,9% aller Fälle ist kein weiteres Handeln erforderlich. Wir setzen die Option und die Webseite leitet beim Aufruf per HTTP auf HTTPS um, zusätzlich wird ein „Content-Security-Policy“-Header mit „upgrade-insecure-requests“ ausgeliefert. Der Browser schreibt aufgrund des gesetzten Headers alle HTTP-URLs auf HTTPS um.

Sollten nach der Aktivierung von „SSL erzwingen“ CSS, Javascript oder andere Ressourcen nicht mehr geladen werden findest Du mehr Informationen zur Fehlerbehebung in unserem Hilfe-Artikel zu „Mixed Content„. Den Status von „SSL erzwingen“ kannst Du unter „Websites & Domains“ einsehen: ist „SSL erzwingen“ aktiv, dann ist das Schloss oben rechts geschlossen. Ein Klick auf das Schloss schaltet „SSL erzwingen“ ein oder aus.

Es gibt keinen Grund zu warten: wir empfehlen, „SSL erzwingen“ schon jetzt zu aktivieren.

Die Änderungen, die wir in der Nacht von Montag auf Dienstag an unserer Webseite vorgenommen haben, sind wohl offensichtlich. Die gesamte Webseite inklusive unserer Angebote wurde überarbeitet und in einen neuen Look transformiert. Zusätzlich wird unsere Cloud ein halbes Jahr nach ihrer Einführung erstmals öffentlich beworben.

Die größte Änderung – neben dem Facelift –  ist sicher die Umstrukturierung der Webhosting-Pakete, die zu einigen Nachfragen geführt hat. Seit der Einführung des Premium-Pakets ist unser Kundenstamm stetig gewachsen. Wir haben viele neue Kunden und ihre Bedürfnisse kennengelernt und ein besonderes Problem mit dem Premium-Paket festgestellt. Die Einschätzung der Ressourcen, die eine Webseite benötigt, und die Realität liegen häufig weit auseinander. Dass Kunden schätzen, sie würden mehr Traffic erzeugen, als sie wirklich tun, ist weniger das Problem. Schwieriger sind die Power-User, die z.B. auf einem 12-Core-Server durchgehend 6 Cores mit PHP-Prozessen belegen und von denen auffallend viele nur den Mindestbetrag von 2 € zahlen. Das ist einerseits eine nachvollziehbare Ansicht – wir haben das Angebot so gestaltet – andererseits nutzt es die anderen Kunden aus, die wenig Leistung benötigen und den „fremden Leistungshunger“ zahlen müssen.

Dabei handelt es sich auch nicht um ein Problem, dass sich alleine technisch lösen lässt. Wir haben begonnen, die – für alle Kunden extrem hoch eingestellten – Limits des Premium-Pakets aufgrund dieser Power-User etwas zu drosseln, um die Qualität des Webhosting für andere Kunden zu verbessern. Das wurde wiederum von den Power-Usern nicht besonders gut angenommen. Wir mussten uns einiges dafür anhören.

Schlussendlich haben wir uns dann zu entschieden, die Angebot anders zu strukturieren, weil das Problem nicht der Ressourcenverbrauch der Kunden ist, sondern das Angebot. Das Premium-Paket hat zwar einen schönen idealistischen Anspruch, funktioniert in der Praxis aber nicht, weil die Power-User ihren Leistungsbedarf nicht abschätzen können oder vielleicht sogar bewusst unser Angebot wählen, da sie das Preis-Leistungsverhältnis sonst nirgendwo auf dem Webhosting-Markt bekommen. Unsere neuen Pakete sind hingegen viel besser auf die verschiedenen Kundenprofile abgestimmt. Wir haben sogar noch eine Schippe daraufgelegt und kräftig am Spitzen-Paket „Excellence“ gearbeitet. In diesem Paket haben wir mit PHP-FPM, Apache 2.4 auf Event-Basis und Hosting in unserer Cloud eine unschlagbare Performance erreicht, die von den Kunden, die dorthin gewechselt sind, kräftig gelobt wird.

Das wirft natürlich die Frage auf, was mit den bestehenden Premium-Paketen passiert und ob wir weiterhin Prepaid-Webhosting anbieten. Die Antworten sind einfach: an bestehenden Verträgen ändert sich nichts. Premium-Verträge laufen ganz normal weiter und können weiterhin geändert werden. An laufenden Verträgen ändert sich also nichts, außer Du als Kunde wirst aktiv und wechselst auf ein neues Paket. Zudem bieten wir weiterhin Prepaid-Hosting an. Bei den Webhosting-Paketen kann zwischen 12 Monaten und 1 Monat Laufzeit gewählt werden, beide Laufzeiten enthalten auch Inklusiv-Domains. Die Pakete für 1 Monat sind speziell für Prepaid-Hosting gedacht und können jederzeit gekündigt werden.

In den nächsten Tagen werden wir wieder den kostenlosen Testzeitraum für Webhosting-Pakete anbieten, damit man sich unverbindlich ein Bild von der neuen Produktpalette machen kann. Bevor dieser Blog-Post noch länger wird: ich beantworte gerne Fragen zu unserer Änderung hier in den Kommentaren oder per Support-Ticket (support@lima-city.de oder per Ticket-System).

Vielen Dank an Lennart für die Konzeption, die Geduld und Liebe zum Detail und alles, was zum neuen Corporate Design gehört, an Alex für das Coden der Templates, an Simon für das Abwickeln des Tagesgeschäfts während ich in die finale Relaunch-Phase abgetaucht bin, an alle Kunden die uns gut zugeredet und kritisiert haben, an alle Probe-Leser, Tester und Fragen-Steller, Testimonial-Schreiber und Open-Source-Coder. Ihr seid die Besten!

In letzter Zeit haben wir häufig Anfragen zu Whois Privacy bzw. Whois Proxies bekommen. Diese Dienste verstecken den Domain-Inhaber im WHOIS und schützen so vor allem vor Spam und Werbung.

Heute haben wir im Warenkorb die Option zur Buchung von Whois Privacy bei der Neubestellung von .com- und .net-Domains hinzugefügt. Aufgrund organisatorischer Schwierigkeiten ist es leider nicht (so einfach) möglich, für bestehende Domains Whois Privacy hinzuzubuchen.

Wir beobachten, wie sich das Feld von Whois Privacy weiter verhält. Grundsätzlich dürfte diese Option spätestens mit Beginn der EU-DSGVO (EU-Datenschutz-Grundverordnung) erledigen. Nach der EU-DSGVO dürfen die Registries die Daten der Domain-Inhaber theoretisch nicht mehr verarbeiten, damit wäre das WHOIS faktisch tot. Die EU-DSGVO ist ab dem 25. Mai 2018 anwendbar

Wie so gut wie jeder andere IT-Dienstleister sind auch wir gezwungen, in Kürze umfangreiche Sicherheitsupdates an quasi allen von uns betriebenen IT-Systemen einzuspielen. Wir erwarten derzeit noch die Veröffentlichung der nötigen Patches ab.

Auf unserer Status-Seite haben wir bereits Wartungsarbeiten angekündigt: http://www.lima-status.de/incidents/kjmf016v5nvj – wir werden den Zeitraum anpassen, sobald weitere Informationen zur Verfügung stehen.

Informationen zu den Sicherheitslücken:

Spectre

Meltdown

Ich hätte gerne die bereits am 21. November erwähnten Neuigkeiten verkündet, aber wie so häufig verzögert sich das. Die Weihnachtszeit ist hektisch und Projekte gehen selten so schnell voran wie man es sich wünscht.

Daher verschieben wir zwei größere Neuerungen, an unserem Webhosting-Angebot und an unserer Webseite, auf Anfang Januar. Den Rest diesen Jahres werden wir dann mit Bugfixes und Verbesserungen verbringen. Bis dahin gibt es nur als Sneak Preview einen Blick durch die Wolken auf die Bremer Skyline…

Gestern wurde das neue PHP 7.2 veröffentlicht. Die neue Version steht unseren Premium-Kunden seit einigen Stunden unter „PHP-Versionen“ in der Verwaltung bereit.

Das Changelog mit allen Änderungen für PHP 7.2 ist auf der Seite von php.net zu finden.

Hinweis: Derzeit gibt es noch keinen ionCube Loader für PHP 7.2, aus diesem Grund ist diese Extension nicht installiert.

PHP 7.0 und 7.1 sind bereits seit längerem freigegeben, wir haben allerdings aus technischen Gründen beide Versionen noch nicht im produktiven Einsatz. Die Einführung von PHP 7.0 und 7.1 haben wir zum Anlass genommen, unser PHP-Setup deutlich zu verbessern und die Vorteile der moderneren Architektur von PHP-FPM (fast process manager) zu nutzen.

Neben der  Möglichkeit, flexibel die PHP-Versionen zu ändern (ab Freitag sind 5.6, 7.0 und 7.1 wählbar) verbessert PHP-FPM auch die Ladezeiten, in dem der Opcode (der kompilierte PHP-Code) zwischen den Seitenaufrufen im RAM gehalten wird. Bei komplexeren Anwendungen wie WordPress, Joomla, Magento oder Typo sind hier ganz erhebliche Verbesserungen der Ladezeiten messbar. Wir werden PHP-FPM aus technischen Gründen nur für den Premium-Webspace anbieten.

Um das Update einzuspielen werden Wartungsarbeiten in der Nacht von Donnerstag, 23.11., auf Freitag, den 24.11., durchgeführt (siehe Status-Seite). Im Laufe des Freitags werden wir dann nach abschließenden Tests die Auswahl der PHP-Versionen über die Verwaltung freigeben. Änderungen auf Kundenseite sind nicht notwendig, alle nötigen Änderungen werden von lima-city vorgenommen!

Zwei Detail-Änderungen ergeben sich durch den Wechsel der PHP-Architektur:

• es ist nicht mehr möglich, PHP-Einstellungen per .htaccess-Datei vorzunehmen. Stattdessen wird eine INI-Datei dafür bereitgestellt (.user.ini), in der diese Konfiguration vorgenommen wird. Alle Einstellungen, die in .htaccess-Dateien existieren, werden von uns automatisch in das neue Format übertragen.
• das Ein- und Ausschalten von Fehlermeldungen über die Verwaltung ist nicht mehr möglich, die Einstellung muss dann ebenfalls über eine .user.ini gesetzt werden

Beide Einstellungen werden wir über Verbesserungen in der Verwaltung steuerbar machen, so dass ein manuelles Ändern von Dateien auf dem Webspace nicht mehr nötig ist.

Diese technischen Änderungen sind übrigens Grundlage für weitere spannende Änderungen, die wir in den nächsten 14 Tagen veröffentlichen, also: stay tuned 🙂

Update: Den Switcher für PHP-Versionen in der Verwaltung werden wir erst am Montag freischalten.

Die heute bekannte gewordene Sicherheitslücke Optionsbleed ist auf unserem Webhosting übrigens bereits gefixt. Da wir schon länger auf Basis des Ubuntu-Pakets einen Apache mit eigenen Patches kompilieren war es kein Problem, den Patch einzuspielen, noch bevor Ubuntu oder Debian das Sicherheitsupdate veröffentlicht…

Ende letzten Jahres hat die Certificate Authority (CA) StartCom für einiges an Furore gesorgt, als diverse Verstöße gegen die Richtlinien bekannt wurden, nach denen eine CA Zertifikate ausstellen darf. Diverse Browser-Hersteller (Chrome, Firefox) und Betriebssysteme (iOS, Mac-Plattform) haben daraufhin StartCom und WoSign das Vertrauen entzogen. Von Startcom ausgestellte Zertifikate wurden teilweise nicht mehr akzeptiert oder nur noch mit bestimmten Bedingungen (z.B. nur, wenn sie vor einem bestimmten Datum ausgestellt wurden).

Auch wir haben Zertifikate von StartCom eingesetzt, um unsere kostenlosen Subdomains wie meinbenutzername.lima-city.de mit SSL-Zertifikaten zu versorgen.  Nun wurde immer deutlicher, dass die absolute Deadline, an dem die Zertifikate auch in den bisherigen Sonderfällen nicht mehr akzeptiert werden, bald erreicht wird und demnächst immer mehr Browser diese Verbindungen als „nicht sicher“ einstufen würden. Der erste Gedanke geht in dem Fall natürlich in Richtung von Let’s Encrypt, denn immerhin werden auch schon alle Kunden-Domains und aufgeschaltete Domains inklusive aller Subdomains vollautomatisch via Let’s Encrypt mit SSL-Zertifikaten ausgestattet. Wir können also unsere bisherige Infrastruktur zum Ausstellen von Zertifikaten mit Let’s Encrypt weiter nutzen und haben keine Kosten durch teuer gekaufte Wildcard-Zertifikate-

Es stellte sich aber schon im letzten Jahr schnell heraus, dass Let’s Encrypt ohne weiteres nicht die Lösung sein kann. Das Problem dabei, alle Subdomains unter lima-city.de und den anderen Domains (12hp.de, 12hp.at,  usw.) mit SSL-Zertifikaten auszustatten, liegt in den Limits von Let’s Encrypt, die es gleich auf mehrere Arten verbieten, viele Subdomains unter einer Domain anzulegen:

• es lassen sich nur 20 Zertifikate pro Woche für eine Domain ausstellen. Das heißt, wir hätten maximal 20x pro Woche neue Zertifikate ausstellen können. Rein rechnerisch könnten wir alle 8,5 Stunden ein neues Zertifikat ausstellen, neue Registrierungen müssten so lange auf ein Zertifikat warten. Das alleine ist schon sehr unangenehm.
• es sind maximal 100 Subdomains pro Zertifikat erlaubt. Rein rechnerisch lassen sich also 2.000 Subdomains einer Domain mit einem Zertifikat schützen. Das ist eindeutig zu wenig, wir liegen in einer Größenordnung von hunderttausenden Subdomains für lima-city.de.

Unglücklicherweise stellt Let’s Encrypt (bisher) keine Wildcard-Zertifikate aus, so dass es nur noch die Lösung gibt, die Rate Limits irgendwie zu umgehen. Let’s Encrypt stellt genau für solche „Anträge“ ein Formular zur Verfügung, was aber leider gänzlich im Sande verlief. Aber es gab noch eine weitere Lösung: die Public Suffix List.

Die Public Suffix List ist eine Liste von Domains, die von diversen Programmen, Firmen und Prozessen dazu genutzt wird, zu bestimmen auf welchem „Level“ eine Domain sich befindet, also was der „öffentliche“ Teil einer Domain ist. Beispielsweise bei .de-Domains ist klar, dass a.de und b.de nicht zusammen gehören – „de“ ist ein „öffentliches Suffix“. Bei a.co.uk und b.co.uk ist der öffentliche Teil analog „co.uk“. Es gibt auch „private“ Suffixe, wie z.B. dyndns.org, denn unter dyndns.org kann jeder eine eigene Subdomain registrieren.

Es stellte sich also heraus, dass auch Let’s Encrypt die Public Suffix List verwendet, um die Limits zu prüfen. Wenn also lima-city.de ein Public Suffix ist, dann gilt das Limit mit 2.000 Subdomains nicht für lima-city.de, sondern für jede einzelne Subdomain wie mustermann.lima-city.de – und da wir nur mustermann.lima-city.de und vielleicht noch www.mustermann.lima-city.de schützen wollen, reicht das Limit von 2.000 Subdomains gut aus. Gesagt, getan: wir haben unsere Domains in die Public Suffix List aufnehmen lassen (das dauerte einige Wochen), Let’s Encrypt hat nach ein paar weiteren Wochen die Änderungen der Public Suffix List übernommen und siehe da, unser System stellt nun fleißig neue Zertifikate für die Subdomains aus, so dass der Großteil der Subdomains nun mit Zertifikaten von Let’s Encrypt geschützt sind. Das StartCom-Zertifikat ist nur noch ein Fallback, falls bisher kein Zertifikat von Let’s Encrypt ausgestellt wurde. Wir sagen also derzeit für hunderttausende Adressen „Bye, Bye, StartCom!“ und „Hallo Let’s Encrypt“.

Es ist übrigens wahrscheinlich, dass wir die Verwaltung von Let’s Encrypt-Zertifikaten demnächst ganz aus der Verwaltung entfernen. Inzwischen werden alle Adressen, die auf unseren Systemen gehostet sind, automatisch mit Zertifikaten versorgt. Es ist schlicht nicht mehr nötig, selbst Zertifikate zu verwalten, da unser System diese ganze Arbeit vollständig und transparent übernimmt. SSL und der verschlüsselte Transport von Daten sollte nämlich Standard sein und keine Arbeit und Mühe erfordern.