Security - oder auch nicht. Das schwächste Glied der Kette. Ein Probevortrag eines Vortrags für den Linuxday 2008

Transkript

1 Security - oder auch nicht. Das schwächste Glied der Kette. Ein Probevortrag eines Vortrags für den Linuxday 2008 Wolfgang Dautermann FH JOANNEUM FH Joanneum,

2 1 Netzwerkprotokolle 2 Verschlüsselung mit SSL 3 Gegenseitige Authentifizierung 4 Arten von Zertifikaten 4 Zusammenfassung

3 Netzwerkprotokolle Übliche und bekannte Netzwerkprotokolle HTTP - Hypertext Transfer Protocol - (RFC 1945, Mai ) POP3 - Post Office Protocol Version 3 - (RFC 918, Oktober ) IMAP - Interactive Mail Access Protocol - (RFC 1064, Juli ,3 ) FTP - File Transfer Protocol - (RFC 765, Juni ) (telnet - Teletype Networking - (RFC 137, April ))......sind relativ ALTE Netzwerkprotokolle. 1 RFC von 1996, entwickelt RFC, inzwischen öfters erweitert und weiterentwickelt 3 Heute: Internet Message Access Protocol

4 Netzwerkprotokolle II Sind definiert als ASCII-Klartextprotokolle + Einfach zu definieren + Einfach zu verstehen + Einfach zu implementieren. - Daten gehen unverschlüsselt durch die Weltgeschichte Das ist in den 70ern und 80ern nicht so wichtig, die Kriminellen sind noch nicht online, im Internet sind nur die Guten + Wenig Rechenleistung erforderlich (und wenig Rechenleistung vorhanden!)

5 Beispiel: Mailabfrage mit POP3 >> $ telnet pop3 Trying Connected to localhost ( ). Escape character is ^]. +OK example.com POP3-Server ready >> USER dauti +OK Password required for dauti. >> PASS strenggeheim +OK dauti has 2 visible messages (0 hidden) in 1220 octets. >> RETR 2 +OK 662 octets Date: Sat, 28 Oct :29: From: Wolfgang Dautermann <dauti@example.com> To: dauti@example.net Subject: testsubject testbody. >> quit +OK Pop server at example.com signing off. Connection closed by foreign host.

6 Passwort-Sniffing - ettercap, dsniff & Co.

7 Passwort-Sniffing - ettercap, dsniff & Co. ettercap, dsniff 4 liefern: Protokoll IP-Adresse Portnummer Username Passwort...alles was man haben will... 4 wird leider seit 2000 nicht mehr weiterentwickelt

8 Lösung des Sicherheitsproblems: Verschlüsselung üblicherweise SSL - Secure Socket Layer entwickelt von Netscape Communications 1994 oberhalb der Transportschicht (z. B. TCP) und unter Anwendungsprotokollen wie HTTP oder IMAP existierende Protokolle können verschlüsselt werden.

9 ENDE? Zwischen dem Sender und dem Empfänger kann nichts mehr mitgesnifft werden. Ende des Vortrags?...oder gibts da doch noch ein paar Kleinigkeiten, die man beachten sollte?

10 Real-World-Beispiel: Bankomatbehebung Sicherheit durch Karte und Pincode (bzw. am Mailserver: Username/Passwort)

11 Real-World-Beispiel: Bankomatbehebung II Das ist EINE Authentifizierung...und die Gegenstelle ist wer?

12 Authentifizierung der Gegenstelle Routing im Internet geht über nicht vertrauenswürdige Knoten (Rechner/Router/Provider (ev. von Behörden/Gesetzgebern verpflichtet, Daten weiterzugeben)/...) Keine Ahnung, mit wem ich wirklich kommuniziere. Wie authentifiziert sich der Server mir gegenüber? (Im Real-Life: Bankomat sieht bankomatmässig aus, ist bei einer Bank (die ich kenne?), ich kenne die Adresse des Standorts). Im Internet: Keine Ahnung, mit wem ich verschlüsselt kommuniziere! Mit dem Server meiner Bank? Mit dem Webserver eines Betrügers? Im Internet bin ich blind...

13 Authentifizierung der Gegenstelle II...Bankomat ist bei einer Bank?

14 Authentifizierung der Gegenstelle III...Bankomat ist bei einer Bank?

15 Authentifizierung der Gegenstelle IV...Bankomat(kasse) ist vertrauenswürdig? Euro Schaden: Bankomatkarten-Betrüger gefasst Kasse mit Speicherchip manipuliert Laut Polizei war das Vorgehen immer gleich: Ein oder zwei Bandenmitglieder brachen in Geschäfte ein und manipulierten die Kassen, in dem sie einen Speicherchip einbauten; darauf wurden die Daten der Kunden, die mit Bankomatkarte gezahlt haben, kopiert. Bei einem zweiten Einbruch wurde der Speicher wieder entfernt. Mit den gestohlenen Daten wurden schließlich neue Bankomatkarten hergestellt, mit denen die Betrüger dann in Italien, Frankreich und Spanien Geld behoben. Siehe:

16 Authentifizierung der Gegenstelle Die Gegenstelle (der Server) muss sich mir gegenüber ausweisen, damit ich sicher bin, mit dem richtigen Server zu kommunizieren. Nicht mit Username/Passwort, sondern mit Zertifkaten (SSL) bzw. Hostkeys (SSH).

17 Zertifikats-Bestandteile Issued to: An wen wurde das Zertifikat ausgestellt. Common Name: Domainname. Name des Servers, mit dem ich zu kommunizieren glaube. Issued from: VON WEM wurde das Zertifikat ausgestellt. Validity: Gültigkeitsdatum von-bis Fingerprints: SHA1 und MD5 Prüfsummen.

18 Zertifikate kosten (üblicherweise) Geld Die Stelle, die im Issued from genannt ist - die ausstellende Behörde muss prüfen, ob der Antragsteller tatsächlich der ist, der er vorgibt zu sein 5. Wirkliche (durch Gesetze ermächtigte) Behörden (im Real-Life: Passamt, KFZ-Zulassungsstelle,... ) gibt es im Internet nicht. Zertifikate werden von privaten Firmen ausgestellt. Einige Firmen sind in den Browsern vorinstalliert und werden von den Browsern daher als vertrauenswürdig eingestuft. 5 was Verisign bei einem Microsoft-Zertifikat 2001 nicht wirklich gemacht hat...

19 Vorinstallierte Certificate Authorities

20 Arten von Zertifkaten Zertifikate von vorinstallierten (kommerziellen) Authorities + Authority in den Browsern vorinstalliert, User werden nicht durch Fehlermeldungen verunsichert. + Identität des Zertifikats-Empfängers wird beim Ausstellen vom Aussteller geprüft! -...kosten Geld - Verisign erfindet Verisign Extended Verification Certificates noch teurer, soll in der Browser-Adressleiste mit anderer Farbe (weiß für unverschlüsselt, gelb für SSL (ist nicht einheitlich) und jetzt neu: grün für extrateuer) angezeigt werden kostet noch mehr Geld

21 Arten von Zertifikaten Selbst signiertes Zertifikat, Screenshot von Firefox 2 (2006)

22 Selbst signierte Zertifikate Bitte NICHT einfach wegklicken! Mit wem kommuniziere ich? Bankserver oder Betrügerserver? Wenn mir das egal ist, kann ich mir die Verschlüsselung gleich schenken... Viele Zertifikats-Warnung lassen die User abstumpfen - die Bedeutung der Warnung wird vernachlässigt. Browser kennt die Authority nicht Server-Fehlkonfiguration Ich kommuniziere mit einem anderen!

23 Selbst signierte Zertifikate II Screenshot Firefox 3 war bei der Google Suche nach selbst signiertes Zertifikat auf Platz 2...

24 Selbst signierte Zertifikate III Screenshot Firefox 3

25 Selbst signierte Zertifikate IV

26 Selbst signierte Zertifikate V Selbst signiertes Zertifikat. Ausgestellt von der Polizei Sachsen Anhalt für die Polizei Sachsen Anhalt Genauso gut wie ein selbst erstellter Personalausweis oder ein selbst erfundenes KFZ-Kennzeichen....

27 Selbst signierte Zertifikate VI Zitat von Bietet ein selbst signiertes Zertifikat auch Sicherheit? Klares Nein!! Bei der Benutzung eines selbst signiertes Zertifikates erhällt der Besucher eine Warnmeldung, das das Zertifikat nicht geprüft werden kann, da es nicht von einer Zertifizierungsstelle signiert ist. Für den Besucher ist nicht erkennbar ob die Kommunikation tatsächlich mit dem gewünschten Ziel erfolgt oder nicht. Wenn der Besucher das Zertifikat manuell aktzeptiert, erfolgt die Kommunikation zwar verschlüsselt, allerdings zu einem unbekannten Ziel. Das Ziel kann auch ein Server eines Angreifers sein. Daher ist ein selbst signiertes Zertifikat für den professionellen Einsatz ungeeignet. Intern (in der eigenen Firma, Schule, Hochschule, Verein) kann man selbst signierte Zertifikate oder die eigene Authority in den verwendeten Browsern vorinstallieren.

28 Zertifikate von cacert.org Community-Lösung Wer: CAcert Inc., a non-profit Association of Members incorporated in New South Wales, Australia. Im Real-Life wird meine Identität überprüft (amtlicher Ausweis). Zuordnung: Reale Person -Adresse Account auf Eigene Domain auf eintragen und Zertifikate signieren lassen das signierte Zertifikat kommt per Mail an einen Admin-Account der Domain (z.b. postmaster@example.com). Wenn ich die Mail an den Admin-Account bekomme, bekomme ich auch das signierte Zertifikat. - (Noch) ist cacert.org nicht standardmässig in den Browsern als Authority eingetragen. Wenn man CAcert vertraut, ev. das CAcert-Root-Zertifikat selbst in den Browsern vorinstallieren.

29 Zertifikate von cacert.org II CAcert Assurrer überprüfen die Identitität von neuen Mitgliedern. Früher hat das schon gereicht, um neuer Assurer zu werden. (So soll sich ein Web-of-trust bilden. Neu: Assurer müssen zusätzlich eine Prüfung ablegen. Ebenso bisherige Assurer, wenn sie neue Mitglieder assuren wollen (Ziel: Aufnahme von CAcert in Mozilla-Browsern, erforderlich durch Mozilla-Policies) Links: CAcert Community Agreement: https: // Introduction to the CAcert Assurance Program: Introduction to the CAcert Assurance Program: CAcert-Infotisch neben LUGV-Tisch.

30 Weitere Anwendungen von Zertifikaten Signierung von Software Kein Server, keine Internetverbindung muss gehackt werden! Problematik fehlerhaftes Verisign Zertifikat besonders akut - fremde Software konnte als von Microsoft zertifiziert (für MS-User vertrauenswürdig ) auf den Rechner kommen!

31 SSH-Hostkeys $ ssh The authenticity of host ( ) can t be established. RSA key fingerprint is 80:aa:ef:bc:22:11:ab:f4:64:56:54:7d:6b:89:4b:f3. Are you sure you want to continue connecting (yes/no)? no Host key verification failed. Keine Zertifizierungsstellen, nur selbst erstellte Hostkeys keine vorinstallierten Hostkeys Trotzdem die einzige Authentifizierung des Servers gegenüber mir. (ggf. Fingerprint beim ersten connect vergleichen!)

32 SSH-Hostkeys II Viel grösser kann man ja die Warnung nicht hinschreiben... $ WARNING: REMOTE HOST IDENTIFICATION IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 80:aa:ef:bc:22:11:ab:f4:64:56:54:7d:6b:89:4b:f3. Please contact your system administrator. Add correct host key in /home/daute/.ssh/known_hosts to get rid of this message. Offending key in /home/daute/.ssh/known_hosts:364 RSA host key for has changed and you have requested strict checking. Host key verification failed. Bei einer Neuinstallation (bekannte) SSH-Hostkeys übernehmen. User von einer ev. Änderung der Hostkeys (vorher) informieren.

33 SSH-Hostkeys im DNS (RFC4255) Interessante Idee, aber ohne DNSsec noch nicht sicher... $ ssh-keygen -r hostname -f /etc/ssh/ssh_host_rsa_key.pub hostname IN SSHFP 1 1 f52b34ef558f52dc4887d0338bfeedf6671c4a92 $ ssh-keygen -r hostname -f /etc/ssh/ssh_host_dsa_key.pub hostname IN SSHFP 2 1 ce5f6d5ad1ac4ace7016bf397c3a0df06e649ff1 Diese Records in den Nameserver übernehmen (BIND Nameserver >= 9.3.0, OpenSSH >= 3.4 erforderlich). Dann kann man mit $ ssh -o "VerifyHostKeyDNS ask" host.example.com bzw. $ ssh -o "VerifyHostKeyDNS yes" host.example.com zum Server connecten, der Hostkey wird via DNS überprüft. Statt -o "VerifyHostKeyDNS yes" kann man die Option auch fix in die Datei /etc/ssh/ssh_config bzw. ~/.ssh/config eintragen.

34 Zusammenfassung Security besteht aus (mindestens ) 3 Punkten Einer verschlüsselten sicheren Verbindung zwischen User und Server Authentifizierung des Users gegenüber dem Server Authentifizierung des Servers gegenüber dem User Browser (Mailclient,...) Fehlermeldungen sind nicht nur zum User ärgern und Wegklicken da. Wenn eine Meldung angezeigt wird, soll man sich vor dem Wegklicken darüber im Klaren sein, was die Meldung bedeutet (bzw. bedeuten könnte) und was für Konsequenzen das Ignorieren der Meldung haben könnte.

35 Fragen? Feedback? Vielen Dank für Ihre Aufmerksamkeit Wolfgang Dautermann