OpenLDAP ab 2.4 installieren und einrichten

Vorweg

Mir ist kei­ne Quel­le im Netz bekannt, die die Ein­rich­tung von OpenLDAP wirk­lich umfas­send dar­stellt — schon gar nicht auf Deutsch. Die­se Infor­ma­tio­nen hier sind aus allen mög­li­chen Ecken zusam­men­ge­klaubt — selbst die meis­ten Bücher zu OpenLDAP emp­fin­de ich als sehr wenig hilf­reich.

Grundinstallation

Hin­weis: domain.tld muss man natür­lich immer an den eige­nen openLDAP anpas­sen.

Zuerst instal­lie­ren wir die Bina­ries, in Debi­an und sei­nen Abkömm­lin­gen (Ubun­tu, Mint etc.) z.B. so:

1
apt-get install slapd ldap-utils

Die Instal­la­ti­ons­rou­ti­ne von Debi­an legt dabei nur eine sehr rudi­men­tä­re Kon­fi­gu­ra­ti­on an, sodass etwas Nach­ar­beit von­nö­ten ist. Bei ande­ren Dis­tri­bu­tio­nen ken­ne ich mich nicht so gut aus. Ein

1
dpkg-reconfigure slapd

ermög­licht uns hier die Ein­ga­be einer kor­rek­ten Basis-DN (auf die muss unser SSL-Zer­ti­fi­kat aus­ge­stellt sein), meist sowas wie

  • dc=domain, dc=tld

und zusätz­lich defi­nie­ren wir dabei ein Root­pass­wort für den LDAP-User

  • cn=admin,dc=domain,dc=de

.

Handling von OpenLDAP

Ab Debi­an Squee­ze spei­chert der OpenLDAP-Ser­ver sei­ne Kon­fi­gu­ra­ti­on in einem inter­nen LDAP-Baum und nicht mehr in einem Kon­fi­gu­ra­ti­ons­file. Das macht die Pfle­ge auf den ers­ten Blick erheb­lich auf­wän­di­ger, weil man an die­sen Baum in der Stan­dard­kon­fi­gu­ra­ti­on nur umständ­lich über Kon­so­len­tools her­an­kommt. Zudem kann eine feh­ler­haf­te Daten­bank dazu füh­ren, dass der OpenLDAP nach einer Kon­fi­gu­ra­ti­ons­än­de­rung gar nicht mehr hoch­kommt.
Nur der Root­be­nut­zer des Sys­tems kommt immer auch direkt an die Daten. Man kann sich die bestehen­den Inhalt nur als root anzei­gen las­sen mit:

1
ldapsearch -Y EXTERNAL -H ldapi:/// -b "cn=config"

Neue Ein­trä­ge kön­nen über *.ldif-Files hin­zu­ge­fügt wer­den:

1
ldapmodify/ldapadd -Y EXTERNAL -H ldapi:/// -f
Hinweis zu Ubuntu 14.04 LTS

Der Instal­ler setzt den Account­na­men für den Benut­zer mit Zugriff auf den cn=config-Baum stan­dard­mä­ßig auf: cn=admin,dc=domain,dc=tld. Dann macht man Befol­gen die­ser Anlei­tung ein lan­ges Gesicht. Um das auf den Stan­dard zu ändern, benö­tigt man nur für Ubun­tu 14.04 LTS noch eine klei­ne Ände­rung (change_admin.ldif):

1
2
3
4
dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=admin,cn=config

Obli­ga­to­risch:

1
ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f change_admin.ldif

Sicherheit

OpenLDAP-Verbindungen per TLS absichern

Vor­weg: Hier kann ganz viel schief­ge­hen, obwohl ich die­ses Kapi­tel mit am wich­tigs­ten fin­de. Wenn OpenLDAP aus irgend­wel­chen Grün­den die Zer­ti­fi­kat­files nicht frisst, kann man mit der Kon­fi­gu­ra­ti­on von vor­ne begin­nen oder man hat vor­her ein Back­up der alten Daten­bank gemacht. Des­we­gen über­sprin­ge ich die­sen Schritt ger­ne und bin­de den OpenLDAP ein­fach nicht an öffent­lich erreich­ba­re Netz­werk­de­vices. Wenn man das machen muss, führt aus Daten­schutz­grün­den aber kein Weg an die­ser Pro­ze­dur hier vor­bei. LDAP ist genau wie FTP ein Klar­text­pro­to­koll, dass ohne Trans­port­ver­schlüs­se­lung auf dem gesam­ten Daten­weg offen­liegt und gera­de in WLAN-Umge­bun­gen sehr leicht belauscht wer­den kann.
Gene­rell gibt es zwei Mög­lich­kei­ten, wie man an kos­ten­lo­se Zer­ti­fi­ka­te kom­men kann. Wosign oder StartS­SL. Es gibt diver­se Tuto­ri­als im Netz zur Nut­zung die­ser Diens­te. Von Let­sen­crypt wür­de ich im Kon­text von OpenLDAP eher abra­ten. StartS­SL und WoSign sind mitt­ler­wei­le Geschich­te. Wenn es kos­ten­los sein soll, führt kein Weg an let­sen­crypt vor­bei. Man muss dann dafür sor­gen, dass OpenLDAP nach jedem Cert­up­date neu gestar­tet wird, also alle drei Mona­te min­des­tens.

Man hat am Ende des Zer­ti­fi­zie­rungs­pro­zes­ses in der Regel drei Datei­en vor­lie­gen:

  1. domain.tld-crt.pem (ent­hält das Zer­ti­fi­kat)
  2. domain.tld-key.pem (ent­hält den pri­va­ten Schlüs­sel)
  3. ca_chain.pem (ent­hält die Zer­ti­fi­zie­rungs­chain der CA)

domain.tld ist dabei der Wur­zel­baum des openLDAP. Ich habe die Datei­en nach /etc/ldap/ssl gelegt. Bes­ser auf­ho­ben sind sie in /etc/ssl/cert — dann muss slapd Lese­rech­te dort bekom­men.

Fol­gen­de Datei (tls_ldap.ldif) anle­gen:

1
2
3
4
5
6
7
8
9
dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ldap/ssl/domain.tld-crt.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ssl/domain.tld-key.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ssl/ca_chain.pem

… und über die Kon­so­le ein­spie­len:

1
ldapadd -Y EXTERNAL -H ldapi:/// -f tls_ldap.ldif

oder auch

1
ldapmodify -Y EXTERNAL -H ldapi:/// -f tls_ldap.ldif

Ich bin zusätz­lich ein Freund davon, siche­re Ver­bin­dun­gen zu erzwin­gen. Cli­ents, die das nicht wol­len oder kön­nen, sol­len bit­te drau­ßen­blei­ben.

Fol­gen­de Datei (force_tls.ldif) anle­gen:

1
2
3
4
dn: olcDatabase={1}hdb,cn=config
changetype:  modify
add: olcSecurity
olcSecurity: tls=1

Und wie­der ein­spie­len:

1
ldapadd -Y EXTERNAL -H ldapi:/// -f force_tls.ldif

oder auch

1
ldapmodify -Y EXTERNAL -H ldapi:/// -f force_tls.ldif

Jetzt noch in /etc/default/slapd nach­schau­en, ob die Ser­vices stim­men (ldaps über Port 639 gilt als ver­al­tet und soll­te nicht mehr ver­wen­det wer­den). In der Regel steht da so etwas:

1
SLAPD_SERVICES="ldap://0.0.0.0:389/ ldapi:///"

Wenn man meh­re­re NICs besitzt, kann man natür­lich statt 0.0.0.0 auch die IP einer spe­zi­fi­schen Netz­werk­kar­te ange­ben oder den OpenLDAP nur an local­host (127.0.0.1) bin­den.

Ein

1
service slapd restart

bringt Auf­klä­rung, ob das Gan­ze funk­tio­niert hat. Theo­re­tisch ist das nicht not­wen­dig, da OpenLDAP durch das neue Ver­fah­ren ohne Kon­fi­gu­ra­ti­ons­da­tei qua­si live im Betrieb gepatcht wird. Jetzt soll­te der OpenLDAP Ver­bin­dun­gen von außen nur noch ver­schlüs­selt akzep­tie­ren. Von der Kon­so­le aus ( ldapi:/// ) klappt das nach wie vor auch nor­mal. Wir ver­trau­en uns ja schon selbst.

Bruteforce erschweren

Ein offe­ner LDAP-Ser­ver ist anfäl­lig für bru­te-force Atta­cken — zumal gera­de im Schul­be­reich vie­le unsi­che­re Pass­wör­ter im Umlauf sein dürf­ten. Durch das ppolicy.schema kann man z.B. nach eini­gen fehl­ge­schla­ge­nen Log­ins den Account für eine Wei­le auto­ma­tisch sper­ren. openLDAP bringt das dafür not­wen­di­ge Sche­ma in /etc/ldap/schema/ppolicy.ldif schon mit.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
dn: cn=ppolicy,cn=schema,cn=config
objectClass: olcSchemaConfig
cn: ppolicy
olcAttributeTypes: {0}( 1.3.6.1.4.1.42.2.27.8.1.1 NAME 'pwdAttribute' EQUALITY
  objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 )
olcAttributeTypes: {1}( 1.3.6.1.4.1.42.2.27.8.1.2 NAME 'pwdMinAge' EQUALITY in
 tegerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {2}( 1.3.6.1.4.1.42.2.27.8.1.3 NAME 'pwdMaxAge' EQUALITY in
 tegerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {3}( 1.3.6.1.4.1.42.2.27.8.1.4 NAME 'pwdInHistory' EQUALITY
  integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {4}( 1.3.6.1.4.1.42.2.27.8.1.5 NAME 'pwdCheckQuality' EQUAL
 ITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {5}( 1.3.6.1.4.1.42.2.27.8.1.6 NAME 'pwdMinLength' EQUALITY
  integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {6}( 1.3.6.1.4.1.42.2.27.8.1.7 NAME 'pwdExpireWarning' EQUA
 LITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {7}( 1.3.6.1.4.1.42.2.27.8.1.8 NAME 'pwdGraceAuthNLimit' EQ
 UALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {8}( 1.3.6.1.4.1.42.2.27.8.1.9 NAME 'pwdLockout' EQUALITY b
 ooleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
olcAttributeTypes: {9}( 1.3.6.1.4.1.42.2.27.8.1.10 NAME 'pwdLockoutDuration' E
 QUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {10}( 1.3.6.1.4.1.42.2.27.8.1.11 NAME 'pwdMaxFailure' EQUAL
 ITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE )
olcAttributeTypes: {11}( 1.3.6.1.4.1.42.2.27.8.1.12 NAME 'pwdFailureCountInter
 val' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE
 )
olcAttributeTypes: {12}( 1.3.6.1.4.1.42.2.27.8.1.13 NAME 'pwdMustChange' EQUAL
 ITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
olcAttributeTypes: {13}( 1.3.6.1.4.1.42.2.27.8.1.14 NAME 'pwdAllowUserChange'
 EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
olcAttributeTypes: {14}( 1.3.6.1.4.1.42.2.27.8.1.15 NAME 'pwdSafeModify' EQUAL
 ITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE )
olcAttributeTypes: {15}( 1.3.6.1.4.1.4754.1.99.1 NAME 'pwdCheckModule' DESC 'L
 oadable module that instantiates "check_password() function' EQUALITY caseExa
 ctIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 SINGLE-VALUE )
olcObjectClasses: {0}( 1.3.6.1.4.1.4754.2.99.1 NAME 'pwdPolicyChecker' SUP top
  AUXILIARY MAY pwdCheckModule )
olcObjectClasses: {1}( 1.3.6.1.4.1.42.2.27.8.2.1 NAME 'pwdPolicy' SUP top AUXI
 LIARY MUST pwdAttribute MAY ( pwdMinAge $ pwdMaxAge $ pwdInHistory $ pwdCheck
 Quality $ pwdMinLength $ pwdExpireWarning $ pwdGraceAuthNLimit $ pwdLockout $
  pwdLockoutDuration $ pwdMaxFailure $ pwdFailureCountInterval $ pwdMustChange
  $ pwdAllowUserChange $ pwdSafeModify ) )

Ein­ge­spielt wird das Sche­ma mit:

1
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f ppolicy.ldif

Das Sche­ma ppolicy.ldif selbst defi­niert nur Objek­te für das ent­spre­chen­de Modul, was jetzt noch gela­den wer­den muss, wofür wir eine Datei policy_module.ldif mit fol­gen­dem Inhalt anle­gen:

1
2
3
4
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: ppolicy.la

Und das alte Spiel:

1
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f policy_module.ldif

Jetzt brau­chen wir noch eine Abla­ge (policy_context.ldif) für die ver­schie­de­nen Regel­sät­ze:

1
2
3
4
dn: ou=policies,dc=domain,dc=tld
objectClass: organizationalUnit
objectClass: top
ou: policies
1
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f policy_context.ldif

Und als nächs­tes eine Default-Poli­cy (default_policy.ldif):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
dn: cn=default,ou=policies,dc=domain,dc=tld
objectClass: top
objectClass: device
objectClass: pwdPolicy
cn: default
pwdAttribute: 2.5.4.35
pwdMaxAge: 15552000
pwdInHistory: 3
pwdMinLength: 6
pwdMaxFailure: 3
pwdLockout: TRUE
pwdLockoutDuration: 1800
pwdGraceAuthNLimit: 3
pwdMustChange: TRUE
pwdAllowUserChange: TRUE
pwdSafeModify: TRUE

In die­sen Bei­spiel wird nach drei fehl­ge­schla­ge­nen Log­in­ver­su­chen ( pwd­Max­Fail­u­re: 3 ) das Log­in für 1800 Sekun­den ( pwd­Lock­out­Du­ra­ti­on: 1800 ) gesperrt. Das soll­te kleb­rig genug sein.

Muss ich es noch schrei­ben?

1
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f default_policy.ldif

Da OpenLDAP ja so fluffig und intui­tiv ist, brau­chen wir jetzt noch ein Over­lay (policy_overlay.ldif), dass dem OpenLDAP sagt, dass statt des nor­ma­len Log­in­hand­lings jetzt immer auch die Default-Poli­cy gel­ten soll:

1
2
3
4
5
6
7
dn: olcOverlay=ppolicy,olcDatabase={1}hdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcPPolicyConfig
olcOverlay: ppolicy
olcPPolicyDefault: cn=default,ou=policies,dc=domain,dc=tld
olcPPolicyHashCleartext: TRUE
olcPPolicyUseLockout: TRUE

Ihr wisst, was jetzt kommt:

1
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f policy_overlay.ldif

Damit hät­ten wir grund­sätz­lich ver­schlüs­sel­te Ver­bin­dun­gen erzwun­gen und zusätz­lich Bru­teforce-Angrif­fe erschwert. Bleibt noch eines zu tun:

Anonymous-Bind verbieten

Stan­dard­mä­ßig erlaubt openLDAP einen soge­nann­te anony­mous bind, d.h. man erhält lesend Zugriff auch ohne die Ein­ga­be eines Pass­wor­tes. Die­se lesen­de Zugriff ist sehr ein­ge­schränkt, z.B. gibt es kei­nen Zugriff auf bestimm­te Objekt­klas­sen oder gar Pass­wort­hash­es. Mir ist die Vor­stel­lung trotz­dem nicht geheu­er, dass sich u.a. Nut­zer­na­men auf die­sem Weg aus­le­sen las­sen. Daher ver­wen­de ich für den lesen­den Zugriff einen sepa­ra­ten User, der sich mit Pass­wort authen­ti­fi­zie­ren muss, ansons­ten aber nicht mehr Rech­te als beim anony­mous bind hat. Des­we­gen unter­bin­den wir das mit einer neu­en Datei noanonymous.ldif:

1
2
3
4
5
6
7
dn: olcDatabase={1}hdb,cn=config
add: olcRequires
olcRequires: authc
 
dn: olcDatabase={-1}frontend,cn=config
add: olcRequires
olcRequires: authc

Und jetzt kommt etwas ande­res, weil wir einen bereits bestehen­den Daten­bank­ein­trag aktua­li­sie­ren:

1
ldapmodify -Y EXTERNAL -H ldapi:/// -f noanonymous.ldif

Nach dem Ein­spie­len der letz­ten Ände­rung hat man ohne Authen­ti­fi­zie­rung auch über die Kon­so­le kei­nen Zugriff mehr auf den Haupt­baum des OpenLDAP (dc=domain, dc=tld) — die war bis­her auch sowas wie „anonym” aus Sicht des LDAP. Man muss dann aus­wei­chen auf eine ande­re Befehls­zei­le (cn=config ist davon nicht betrof­fen):

1
ldapadd -x -D cn=admin,dc=domain,dc=tld -W -f

Danach wird man zur Ein­ga­be des Admin­pass­wor­tes auf­ge­for­dert und kann so den Haupt­baum beschrei­ben und ver­än­dern.

Optionale Arbeiten

Performancetuning

Die­se Datei ( index.ldif )

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
dn: olcDatabase={1}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: cn pres,sub,eq
-
add: olcDbIndex
olcDbIndex: sn pres,sub,eq
-
add: olcDbIndex
olcDbIndex: uid pres,sub,eq
-
add: olcDbIndex
olcDbIndex: displayName pres,sub,eq
-
add: olcDbIndex
olcDbIndex: default sub
-
add: olcDbIndex
olcDbIndex: uidNumber eq
-
add: olcDbIndex
olcDbIndex: gidNumber eq
-
add: olcDbIndex
olcDbIndex: mail,givenName eq,subinitial
-
add: olcDbIndex
olcDbIndex: dc eq

ein­spie­len mit

1
ldapadd -Q -Y EXTERNAL -H ldapi:/// -f index.ldif
Benutzer für die Administration von cn=config einrichten

Wenn man sauch den cn=config-Baum auch über kom­for­ta­ble­re Front­ends wie phplda­p­ad­min oder LAM ver­wal­ten möch­te, muss man das Objekt cn=admin, cn=config noch um wei­te­re Ein­trä­ge ergän­zen. Zunächst erzeu­gen wir uns über die Kon­so­le ein Pass­wort:

1
slappasswd -h {SSHA}

Wir erhal­ten einen Hash zurück, den wir in die Zwi­schen­ab­la­ge kopie­ren. Jetzt erstell­ten wir ein ldif-File (manager.ldif):

1
2
3
4
5
6
7
8
9
10
11
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootPW
olcRootPW: {SSHA}
 
# auskommentieren, wenn wir den Zugriff von root  auf cn=config 
# ohne Passwort sperren wollen. Sollte als Fallback besser erhalten bleiben
 
#dn: olcDatabase={0}config,cn=config
#changetype: modify
#delete: olcAccess
1
ldapmodify -Q -Y EXTERNAL -H ldapi:/// -f manager.ldif

Wenn wir jetzt in phplda­p­ad­min (ab Ver­si­on 1.2.2) oder lam als Base-DN cn=config ver­wen­den und als Log­in cn=admin, cn=config, kön­nen wir cn=config auch gra­fisch ver­wal­ten.

Quel­le: https://wiki.debian.org/PhpLdapAdmin

War doch ganz einfach oder?

OpenLDAP ist extrem sper­rig, aber eine her­vor­ra­gen­de Authen­ti­fi­zie­rungs­mög­lich­keit, da im Gegen­satz zu Daten­bank­sys­te­men die Struk­tur hoch­gra­dig stan­dar­di­siert sowie mus­ter­gül­tig objekt­ori­en­tiert ist und sich OpenLDAP so recht schnell in belie­bi­ge Anwen­dun­gen inte­grie­ren lässt — fast alle ernst­zu­neh­men­den Online­tools unter­stüt­zen die Authen­ti­fi­zie­rung über LDAP. OpenLDAP dien­te nicht umsonst nicht als Vor­la­ge für die LDAP-Funk­tio­nen von Samba4 — weil es eben so sper­rig ist.

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.