Hitch, der TLS Doktor

Ein Einblick tief in den Maschinenraum unserer Webserver – Obacht es wird technisch:

Bis heute wurden fast alle Webseiten der Bergischen Universität über das nicht verschlüsselte Protokoll HTTP ausgeliefert. Nur bei Seiten, welche sensible Daten erheben und von denen wir darüber hinaus Kenntnis hatten, wurden verschlüsselt per HTTPS an die Anwender gebracht. Das ist nun anders – alle Webseiten, welche durch das zentrale CMS TYPO3 ausgeliefert werden und auf eine Domain mit der Endung .uni-wuppertal.de hören, werden standardmäßig verschlüsselt. Siehe hierzu unsere Meldung von Heute.

Damit das funktioniert, haben wir eine neue Software im Einsatz, welche die notwendigen Zertifikate verwaltet und gleichzeitig unseren Webbeschleuniger varnish beliefert: Hitch!

Nicht der Date-Doktor, sondern eher der TLS Doktor. Hitch ist ein sogenannter terminierender SSL-Proxy. Das bedeutet, er nimmt SSL-Verbindungen entgegen, entschlüsselt diese, reicht das ganze weiter an unseren Webproxy varnish, wartet auf Antwort, verschlüsselt diese wieder und liefert die Webseite an den Kunden aus. Hitch ist ein sogenannter „dummer“ Proxy, kann also im Gegensatz zu HAProxy keinerlei Manipulationen vornehmen oder gar regelbasiert Unterscheidungen treffen, sondern nur „auspacken-weiterleiten-einpacken-ausliefern“ betreiben 😉

Nachfolgend unsere Config dazu, da ist nahezu Standard und nix besonderes:

frontend = {
  host = "*"
  port = "443"
}
backend = "[127.0.0.1]:6086"    # 6086 is the default Varnish PROXY port.
workers = 2                    # number of CPU cores

daemon = on
user = "nobody"
group = "nogroup"
syslog-facility = "daemon"

# Enable to let clients negotiate HTTP/2 with ALPN. (default off)
#alpn-protos = "http/2, http/1.1"

# run Varnish as backend over PROXY; varnishd -a :80 -a localhost:6086,PROXY ..
write-proxy-v2 = on             # Write PROXY header

# List of PEM files, each with key, certificates and dhparams
pem-file = "/path/to/pemfile.pem"

# Which ciphers do we support:
ciphers = "EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH"

Hitch lauscht auf 443, leitet intern alles an varnish auf Port 6086 weiter. Dazu verwendet er das PROXY V2 Protokoll. Damit nun alle Seiten der Universität aus TYPO3 verschlüsselt werden, weisen wir varnish an, alle auf Port 80 einkommenden Verbindungen für die Domains, welche auf uni-wuppertal.de enden, auf HTTPS, also Port 443, weiterzuleiten:

import std;

sub vcl_recv {
    if (std.port(local.ip) == 80 && req.http.host ~ "(?i)uni-wuppertal.de$" ) {
        if (req.http.host !~ "^(www.)?(ausnahmen|kommen|hierhin).uni-wuppertal.de$" ) {
            set req.http.x-redir = "https://" + req.http.host + req.url;
            return(synth(301));
        }
    }
}

Hier gibt es allerdings im zweiten if-Statement einen Ausnahmeblock, da wir für einige Domains im Namensraum uni-wuppertal.de derzeit keine Umleitung vornehmen. Diese lassen sich aber an zwei Händen abzählen.
Die eigentliche Umleitung wird dann in sub vcl_synth vorgenommen:

sub vcl_synth {
    if (resp.status == 301) {
        set resp.http.Location = req.http.x-redir;
        return (deliver);
    }
}

Wer also einen leistungsfähigen SSL Proxy benötigt, dem sei der leichtgewichtige Hitch durchaus an’s Herz gelegt. Das er aus dem selben Hause wie varnish kommt, ist für uns natürlich noch ein weiterer Vorteil.


t-shirt of the day

 

Bei der Einrichtung einer Diashow mit Bildern in einer TYPO3-Umgebung fiel auf, dass es auf der einen Seite funktioiniert, auf der anderen nicht.

Das Problem bestand darin, dass die Datenquelle der einen Seite im Dateipfad der eingebundenen Bilder einen Umlaut enthielt. Daraufhin stieg rgsmoothgallery von 2011 aus. Zeit für’n Update …


Wenn Web-Leute Hardware bestellen …

Verpackung einer SSD Festplatte

Verpackung einer SSD Festplatte

Verpackung eines Festplattengehäuses einer SSD M.2 NGFF

Verpackung eines Festplattengehäuses einer SSD M.2 NGFF

 

Der Mitarbeiter, der grade mit Hilfe von Vagrant die Inhalte des Webserver auf seinem lokalen System testweise updatet und überprüft, litt sehr darunter, dass die Virtuelle Maschine mit MySQL-Datenbank und sämtlichen Dateien nicht mehr in den Arbeitsspeicher passten. Eigentlich passten die Dateien gar nicht mehr auf das lokale System.

Eine Erweiterung des 32GB-Arbeitsspeicher ging jetzt aufgrund von voll besetzten RAM-Slots nicht mehr, aber an den lokalen Festplatten läßt sich ja noch was drehen …

Also – neue Platte muss her: 500 GB SSD – soll ja zeitgemäß schnell sein.

Ich mach den Webshop des Vertragspartners auf, Festplatten – SSD – intern – oh, das Angebot erscheint mir günstig: Kaufen!

Die 7 Gramm Datenspeicher kamen in einem recht großen Karton, den ich natürlich nach Quittierung des Empfang begierig aufriss!

Was ist denn das? Wo passt den so etwas???

Zu dem M.2 NGFFsteht bei Wikipedia jetzt irgendwas mit PCIe – also: Adapter im nächsten Computerladen für PCIe gekauft, denn natürlich war auf dem Mainboard des Desktop-Rechners kein M.2-Slot vorhanden. Eingesteckt – das BIOS meldet: nichts gefunden. Das V-NAND SSD 850 EVO M.2 hat ja auch 2 Kerben! M.2 mit 2 Kerben werden wie eine Festplatte angesprochen und nicht mit kürzeren Latenzzeiten über PCI. Die mit einer Kerbe sind auch mal schlanke 100€ teurer.

Achja, eine seit 4 Jahren auf 1,3 GB gewachsene Datenbank-Datei ist nach der Bereinigung alter Log-Einträge, Verwerfen alter Content-Elementen, und Löschen als gelöscht geflaggter Datensätze nur noch 170 MB groß. Und die TYPO3-Instanz ist nachher TemplaVoila-frei, auf Fluid umgestellt und fast schon bereit für das Update auf 7.6 mit allen eingepflegten Inhalten.

Zu diesem Prozedere veröffentliche ich wieder etwas, wenn alle Instanzen erfolgreich automatisiert migriert und überprüft worden sind.

Und bei der nächsten „SATA SSD“-Bestellung frage ich jemanden, der sich damit auskennt.


Twitter Cards für tt_news

Lösung einer Twitter Cards Implementation für TYPO3 und tt_news.

Einzubinden beispielsweise als Extension Template auf der Single-View-Seite von tt_news.

### Twitter Card:
page.headerData.500 = TEXT
page.headerData.500.value (
<meta name="twitter:card" content="summary" />
<meta name="twitter:site" content="@" />
)
 
 
temp.twitterTitel = COA
temp.twitterTitel {
 10=CONTENT
 10.table= tt_news
 10.select {    
   selectFields = title
   pidInList = {$news_pid.value} # set constant or insert PID
   andWhere {
     # grab the querystring vars and assign it to uid
     data = GP:tx_ttnews|tt_news
     wrap = uid = |
     intval = 1
   }
 }
 #10.orderBy = sorting
 10.renderObj =COA
 10.renderObj {
   10=TEXT
   10 {
     field = title     
     stripHtml = 1
     crop = 70 | ...    
   }
 }
  wrap = <meta name="twitter:title" content="|" />
}
 
page.headerData.505 < temp.twitterTitel 
 
temp.twitterDescription = COA
temp.twitterDescription {
 10=CONTENT
 10.table= tt_news
 10.select {    
   selectFields = bodytext
   pidInList = {$news_pid.value} # set constant or insert PID
   max = 1
   andWhere {
     # grab the querystring vars and assign it to uid
     data = GP:tx_ttnews|tt_news
     wrap = uid = |
     intval = 1
   }
 }
 10.renderObj =COA
 10.renderObj {
   10=TEXT
   10 {
     field = bodytext     
     stripHtml = 1
     crop = 200 | ...    
   }
 }
  wrap = <meta name="twitter:description" content="|" />
}
 
page.headerData.510 < temp.twitterDescription

Wichtig ist, dass <meta name="twitter:site" content="@" /> noch mit einem Twitteraccount gefüllt werden kann, der als Ansprechpartner dient. Dies ist jedoch nicht mehr zwingend erforderlich. Daher kann die Zeile 5 auch einfach entfernt werden, so denn kein Account angegeben werden soll.

Eine Erweiterung um die Bilder, die in der News benutzt werden, wäre relativ einfach nach o.a. Schema umzusetzen. Das META-Tag, welches hier von Twitter erwartet wird, ist <meta name="twitter:image" content="" />.