Googles Macht (prevalence)

Goog­le hat etwas ange­kün­digt: Die Tat­sa­che, dass eine Sei­te Inhal­te auch ver­schlüs­selt per TLS ereich­bar ist, wird sich zukünf­tig posi­tiv auf das Ran­king aus­wir­ken. Auch die­ses Blog ist durch­gän­gig über https erreich­bar. Tes­ten lässt sich das für die eige­ne Home­page hier. riecken.de bekommt heu­te, am 31. Dezem­ber 2014 ein „A-”-Rating (vor­wie­gend, weil kei­ne älte­ren Refe­renz­brow­ser unter­stützt wer­den).

ssllab_2014-12-31

Die Reak­tio­nen auf Goo­g­les Vor­stoß sind unter­schied­lich.

Welche Vorteile ergeben sich dadurch?

  • ver­schlüs­sel­ter Inter­net­ver­kehr kann nicht ohne Wei­te­res mit­ge­le­sen wer­den, d.h. ein Admin wie ich hät­te — selbst wenn er es woll­te — kei­nen Zugriff auf die Inhal­te, die bei einer Inter­net­sit­zung über­tra­gen wer­den — ledig­lich die auf­ge­ru­fe­nen Sei­ten sehe ich im Log. In Fir­men- und Schul­netz­wer­ken kann man aber durch­aus trick­sen, wenn man die Kon­trol­le über die Cli­ents hat.
  • Orga­ni­sa­tio­nen, die im gro­ßen Stil Inter­net­ver­kehr mit­schnei­den wol­len, bekom­men über kurz oder lang das Pro­blem, dass immer mehr Rechen­ka­pa­zi­tät zur Ent­schlüs­se­lung not­wen­dig wird. Mas­sen­über­wa­chung wird damit also teu­rer - wenn die Ver­bin­dung durch geeig­ne­te Ein­stel­lun­gen ent­spre­chend gesi­chert ist.
  • Man erzwingt, dass Log­in- und Anmel­de­da­ten — z.B. wenn ich mich hier ein­log­ge, um einen Arti­kel zu schrei­ben — auch ver­schlüs­selt über­ge­ben wer­den. Das ist ein Sicher­heits­ge­winn.

Warum macht man das also nicht schon lange?

Das ist eine span­nen­de und gar nicht so leicht zu beant­wor­ten­de Fra­ge. Es gibt eini­ge Fall­stri­cke dabei.

1. Identität

Durch ver­schlüs­sel­te Ver­bin­dun­gen kann man ledig­lich sicher­stel­len, dass die Ver­bin­dung eben ver­schlüs­selt ist. Man weiß bei den aller­meis­ten Ver­bin­dun­gen nicht, ob man wirk­lich mit der im Zer­ti­fi­kat hin­ter­leg­ten Stel­le kom­mu­ni­ziert. Man bekommt heu­te pro­blem­los Zer­ti­fi­ka­te für Domains ohne Whois-Ein­trag — meist wird nur rudi­men­tär geprüft, ob Zugriff auf eine bestimm­te Sys­tem-E-Mail­adres­se besteht. Ledig­lich bei EV-Zer­ti­fi­ka­ten (grü­ne Adress­zei­le) kann man sich recht sicher sein, z.B. wirk­lich mit der eige­nen Bank zu spre­chen.

2. Entschlüsselung

Ich als Geheim­dienst wür­de ver­schlüs­sel­te Ver­bin­dun­gen auf­zeich­nen und dar­auf hof­fen, dass irgend­wann mei­ne Rechen­ka­pa­zi­tä­ten für eine Ent­schlüs­se­lung aus­rei­chen. Dem kann man nur ent­ge­gen­wir­ken, indem man ser­ver­sei­tig bestimm­te Ver­schlüs­se­lungs­ver­fah­ren erzwingt, z.B. Dif­fie-Hell­mann. Das geht wie­der­um oft zu Las­ten der Unter­stüt­zung älte­ren Brow­ser und Betriebs­sys­te­me. Der Kom­pro­miss bei den Ein­stel­lun­gen — gera­de bei Ban­ken — ist eben ein Kom­pro­miss.

3. Eingebettete Inhalte

Mein Brow­ser wird meckern, wenn auch einer ver­schlüs­sel­ten Web­sei­te unver­schlüs­sel­te Inhal­te nach­ge­la­den wer­den, also z.B. ein ein­ge­bet­te­tes Video von einer unver­schlüs­sel­ten Quel­le. Die­se War­nung sieht für den uner­fah­re­nen Nut­zer ziem­lich bedroh­lich aus. Er wird im Zwei­fel die­se Sei­te nicht besu­chen.

Gleich­zei­tig erschwert es genau die­ser Mecha­nis­mus z.B. Schad­pro­gram­men unent­deckt zu blei­ben — wenn sich der jewei­li­ge Ser­ver­be­trei­ber nicht die Mühe macht, ein Zer­ti­fi­kat zu besor­gen. Das Glei­che gilt aber auch für Wer­be­netz­wer­ke, die sehr oft mit ein­ge­bet­te­ten Inhal­ten arbei­ten.

Des­we­gen wird man heu­te kaum bekann­te Inter­net­por­ta­le fin­den, die über https erreich­bar sind.

4. Performance

Ver­schlüs­se­lung erfor­dert etwas mehr CPU-Power auf Sei­ten des Cli­ents und des Ser­vers. Groß­ar­ti­ge Unter­schie­de mer­ke ich bei mei­nen Last­mes­sun­gen aber nicht. Die Aus­sa­gen zum Caching­ver­hal­ten bei ver­schlüs­sel­ten Ver­bin­dun­gen sind wider­sprüch­lich. Alles in allem den­ke ich, dass die­ser Punkt ver­nach­läs­sig­bar ist.

Das sehen Fir­men, die Ange­bo­te für Bil­dungs­in­sti­tu­tio­nen machen, natur­ge­mäß oft anders. Da wird ger­ne noch die Mär von „über­flüs­sig außer beim Log­in” (immer­hin) erzählt — weil oft genug ein CDN (Con­tent-Deli­very-Net­work) im Hin­ter­grund wer­kelt und sta­ti­sche Inhal­te cached oder gar Wer­be­ban­ner nach­lädt. Das umzu­stel­len ist dann schon Auf­wand, wenn man es nach­träg­lich ange­hen muss.

5. Aufwand und Kosten

Bei Zer­ti­fi­ka­ten muss jemand bestä­ti­gen, dass mei­ne Iden­ti­tät stimmt. Das machen Zer­ti­fi­zie­rungs­stel­len, die das nach bestimm­ten Kri­te­ri­en prü­fen. Zer­ti­fi­ka­te, die jähr­lich erneu­ert wer­den müs­sen, gibt es kos­ten­los bei StartS­SL.

Die­ses Geschäfts­mo­dell ist vie­len ande­ren Händ­lern von Zer­ti­fi­ka­ten natür­lich ein Dorn im Auge — für eine pri­va­te Web­sei­te reicht ein sol­ches Zer­ti­fi­kat jedoch voll­kom­men aus. Güns­ti­ge Ein­stei­gerzer­ti­fi­ka­te gibt es ab ca. 5,- Euro pro Jahr — und die­se Zer­ti­fi­zie­rungs­stel­len prü­fen dabei nach mei­nen Erfah­run­gen auch nicht bes­ser als StartS­SL. Als Hos­ting­kun­de wird man etwas mehr anle­gen müs­sen. Gese­hen habe ich Ange­bo­te ab 15,- Euro pro Jahr — dafür hat man nichts mit Ser­ver­kon­fi­gu­ra­tio­nen zu tun.

Für Online­shops oder gar öffent­li­che Lern­platt­for­men soll­te man etwas mehr anle­gen — unter 300,- Euro pro Jahr ist da kaum etwas zu machen. Wenn mir da ein Anbie­ter ohne EV-Zer­ti­fi­kat kommt, ist das eigent­lich schon ein Aus­schluss­grund.

Ein ein­fa­ches Zer­ti­fi­kat über StartS­SL oder Como­do habe ich nach ca. fünf Minu­ten in den Hän­den und auf dem Ser­ver instal­liert. Eine EV-Vali­die­rung ist deut­lich auf­wän­di­ger. Dafür wird man einen Mit­ar­bei­ter wohl 1–2 Stun­den beschäf­ti­gen müs­sen.

Google

Goog­le nutzt eige­ne Wer­be­netz­wer­ke und kann für die­se recht pro­blem­los eine voll­stän­di­ge Ver­schlüs­se­lung ein­rich­ten. Goog­le zwingt ande­re Wer­be­netz­wer­ke jetzt qua­si dazu, es ihnen gleich­zu­tun. Wenn sich zudem höhe­re Stan­dards bei der Iden­ti­täts­va­li­die­rung durch­set­zen, wird es für Wer­be­trei­ben­de, die im Netz uner­kannt blei­ben wol­len, immer schwie­ri­ger, auch pro­mi­nent in Erschei­nung zu tre­ten — z.B. durch ein­ge­bet­te­te Ban­ner­wer­bung.

Wofür nutzt Goog­le also sei­ne Markt­macht? War­um lau­fen Ver­mark­ter gera­de Sturm gegen die­sen Vor­stoß Goo­g­les? Wie wer­den Info­por­ta­le damit umge­hen, dass sie nun Gefahr lau­fen, im Ran­king von Goog­le zu sin­ken? Han­delt Goog­le auch aus Eigen­in­ter­es­se? Oder setzt sich Goog­le hier für unse­re Sicher­heit ein?

Es ist sehr inter­es­sant, wie Goog­le hier sei­nen Ein­fluss ein­mal mehr nutzt.

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.

Moodle, MNET, SSL

Mood­le kann mit ande­ren Sys­te­men so gekop­pelt wer­den, dass Benut­zer naht­los zwi­schen ihnen wech­seln kön­nen, ohne dass sie es mer­ken. Kon­zep­tio­nell ist Mood­le damit Pro­jek­ten wie Dia­spo­ra von der Idee schon längst vor­aus gewe­sen. In „Mood­le-Sprech” heißt die­ses Fea­ture MNET, nutzt aber im Grun­de genom­men einen stan­dar­di­sier­ten SSO-Mecha­nis­mus auf Basis von XMLRPC dazu. Meh­re­re Mood­le­sys­te­me las­sen sich so zu einer gro­ßen Fami­lie zusam­men­fas­sen: So kann z.B. die Klas­se XY von mei­ner Schu­le direkt den Kurs von Leh­rer Lem­pel auf dem Sys­tem von Leh­rer Lem­pels Schu­le nut­zen — d.h. man kann schul-, bun­des­land- bzw. euro­pa- oder sogar kon­ti­nent­über­grei­fend zusam­men­ar­bei­ten, ohne die Kon­trol­le über die eige­nen Daten zu ver­lie­ren. Zusätz­lich sind Sprün­ge über Appli­ka­tio­nen hin­weg mög­lich: Auch Maha­ra oder Elgg — Sys­te­me, die kon­zep­tio­nel­le Nach­tei­le von Mood­le aus­glei­chen, z.B. die feh­len­de Schü­ler­zen­trie­rung — las­sen sich über MNET-Funk­tio­nen anbin­den. Selbst für die Goo­g­le­Apps-Fami­lie ist ein ent­spre­chen­des Plugin ent­wi­ckelt — ich bin bei letz­te­rem noch vor­sich­tig, obwohl es immer ver­lo­cken­der wird.

Ich war lan­ge Zeit sehr miss­trau­isch MNET gegen­über — ich hat­te vor allem Sor­ge um die Art der Daten­über­tra­gung bzw. deren Sicher­heit. Das ist aber unnö­tig, da MNET ein asym­me­tri­sches Ver­schlüs­se­lungs­ver­fah­ren nutzt — hier am Bei­spiel der Kopp­lung zwi­schen Maha­ra und Mood­le:

Wei­ter­le­sen

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…