In eigener Sache: riecken.de über https verfügbar

Nach einer Über­gangs­zeit von weni­gen Wochen wird riecken.de aus­schließ­lich SSL-ver­schlüs­selt abzu­ru­fen sein. Damit ist die Daten­über­tra­gung zu und von die­ser Sei­te durch einen 2048­Bit-RSA-Key gesi­chert. Der Daten­ver­kehr zwi­schen Brow­ser riecken.de ist dann nur mit gro­ßem Auf­wand abzu­hö­ren.

Die­ses Fea­ture ist pri­mär für mich wich­tig, da ich die­se Sei­te auch von öffent­li­chen Netz­wer­ken aus pfle­ge, über die ansons­ten z.B. mei­ne Log­in­da­ten im Klar­text aus­les­bar sind (mit völ­li­gen lega­len und frei ver­füg­ba­ren Netz­werk­ana­ly­se­tools wie Wire­Shark). Mich haben im letz­ten Jahr die Ana­ly­se­er­geb­nis­se von Wire­shark in ver­schie­de­nen öffent­li­chen Netz­wer­ke gera­de­zu scho­ckiert – vie­le Anwen­der sind sich des Risi­kos unge­si­cher­ter Ver­bin­dun­gen offen­bar nicht im Ansatz bewusst – dass ein Blog in frem­de Hän­de fällt, mag nicht über­aus schlimm sein, aber es wird oft genug das iden­ti­sche Pass­wort für unter­schied­li­che Diens­te genutzt.

Für die aller­meis­ten Feed­re­ader und Brow­ser dürf­te das kei­ne Anpas­sun­gen erfor­dern. Trotz­dem emp­feh­le ich, ggf, schon jetzt das Abon­ne­ment der Feed-URL von http auf https umzu­stel­len. Ich nut­ze ein kos­ten­lo­ses Ser­ver­zer­ti­fi­kat von StartS­SL, wel­ches von den meis­ten neue­ren Brow­sern und End­ge­rä­ten ohne Zer­ti­fi­kats­war­nung akzep­tiert wird. IE6.0&7.0 und sehr frü­he Android­ver­sio­nen wer­den nicht unter­stützt und geben Feh­ler­mel­dun­gen aus, wel­che die Funk­ti­on der Sei­te aber nicht beein­flus­sen.

Die Instal­la­ti­on eines StartS­SL-Zer­ti­fi­kats erfor­dert Root­rech­te oder ein ent­spre­chend vor­kon­fi­gu­rier­tes Web­pa­ket und ist nicht per Plugin zu bewerk­stel­li­gen.

Schulserver via HTTPS

Seit dem Wochen­en­de hat auf eini­gen Web­sei­ten unse­rer Schu­le etwas ver­än­dert:

Die gesam­te Kom­mu­ni­ka­ti­on zwi­schen den Cli­ents der Schü­le­rin­nen und Schü­ler und unse­rem Web­ser­ver läuft damit über HTTPS. So flie­gen kei­ne Schul­netz­werk­pass­wor­te mehr im Klar­text durch die Gegend – als Neben­ef­fekt blei­ben auch die Logs des Netz­werk­ser­vers davon ver­schont. Die Per­for­mance lei­det etwas, da es beim Hand­shake zwi­schen Brow­ser und Web­ser­ver nun eini­ges mehr zu rech­nen gibt – über die ver­schlüs­sel­te Ver­bin­dung – so ein­mal eta­bliert – lachen sich moder­ne Pro­zes­so­ren eher sche­ckig. Man kann die­sen Effekt sehr deut­lich in z.B. Mood­le bemer­ken: Surft man zügig durch das Sys­tem, flufft es fast wie vor­her. Liest man län­ge­re Zeit auf einer Sei­te und klickt dann auf einen Link, braucht es ca. drei Gedenk­se­kun­den – zumut­bar.

Die alten URLs muss­ten nun auf HTTPS umge­bo­gen wer­den, damit die Benut­zer das Sys­tem mit ihren alten Book­marks benut­zen kön­nen – das geht mit dem von mir ver­wen­de­ten lighttpd-Web­ser­ver sehr hübsch. Ein

$SERVER[„socket“] == „:80“ {

$HTTP[„host“] =~ „alte.domain.de“ {
url.redirect = ( „^/(.*)“ => „https://alte.domain.de/$1“ )
}

}

(Über­setzt: Schrei­be http://alte.domain.de/irgendwas auf https://alte.domain.de/irgendwas um).

über­gibt die User an die SSL-Engi­ne von lighttpd, die dann die vhost-Geschich­te über­nimmt.

Die Umstel­lung hat übri­gens fast nie­mand bemerkt: Mein Ser­ver­zer­ti­fi­kat ist durch eine Aut­ho­ri­ty signiert, dann meckert auch kein Brow­ser – es wird nur blau in der Adress­zei­le. Jetzt zie­he ich als nächs­tes den Mail­ser­ver der Schu­le um und kann dann end­lich auch über mei­ne Zer­ti­fi­ka­te IMAPS und SMTPS anbie­ten. Da ich als Clas­s2-Mem­ber ein Wild­card-Zer­ti­fi­kat signie­ren las­sen kann, gibt es auch kei­nen Trou­ble mit IPs…

Class 2 Zertifizierung durch startssl

Heu­te habe ich es geschafft, von starts­sl Class 2 zer­ti­fi­ziert zu wer­den:

Das bedeu­tet, dass ich mir z.B. jetzt ein Wild­card-Sub­do­main Ser­ver­zer­ti­fi­kat für jede(!) mei­ner Domains durch starts­sl signie­ren las­sen, also Diens­te via SSL (https) anbie­ten kann. Was ich damit genau für die  Öffent­lich­keit bzw. mei­ne treu­en Leser hier vor­ha­be, wird spä­ter ver­ra­ten.

Beim bald anste­hen­den Ser­ver­wech­sel unse­rer Schu­le wer­de ich auf jeden Fall alle Diens­te auf SSL migrie­ren und so zumin­dest auf dem Kom­mu­ni­ka­ti­ons­weg zwi­schen Brow­ser und unse­rem Ser­ver ein wenig mehr Sicher­heit schaf­fen. Da wir vie­le Sub­do­mains nut­zen, hät­ten wir die immensen Kos­ten für Wild­card­zer­ti­fi­ka­te von ande­ren CAs nicht bewäl­ti­gen kön­nen. Somit flie­gen bald kei­ne Klar­text­pass­wör­ter mehr zwi­schen unse­rem Mood­le und dem Anwen­der­cli­ent hin- und her. Was nützt ansons­ten die SSHA-Ver­schlüs­se­lung der Pass­wör­ter auf unse­rem Ser­ver?

Das Tol­le an starts­sl: Deren Root­zer­ti­fi­kat ist in den meis­ten Brow­sern bereits inte­griert (beim IE ab Ver­si­on 8), sodass beim Auf­ruf der jewei­li­gen Sei­te kei­ne Warn­mel­dung, son­dern ledig­lich das Schloss­sym­bol erscheint, wel­ches dem Anwen­der die siche­re Ver­bin­dung signa­li­siert.  Das hal­te ich für einen wesent­li­chen Vor­teil gegen­über Cacert, obwohl mir deren Ansatz wesent­lich sym­pa­thi­scher erscheint. Die Tat­sa­che, dass alle wich­ti­gen Brow­ser das Root­zer­ti­kat inte­grie­ren, spricht m.E. für die Ver­trau­ens­wür­dig­keit der CA (immer­hin ver­traue ich denen mei­ne per­sön­li­chen Daten an), da gera­de das The­ma Sicher­heit für die Brow­ser­her­stel­ler inte­gral ist.

Wei­ter­le­sen