Thema: Sicherheit 1

Größe: px
Ab Seite anzeigen:

Download "Thema: E-Mail Sicherheit 1"

Transkript

1 Grundpraktikum Netz- und Datensicherheit Thema: Sicherheit 1 Lehrstuhl für Netz- und Datensicherheit Ruhr-Universität Bochum Versuchdurchführung: Raum ID 2/168 Zusammengestellt von: Pavol Sovis, Florian Bache, Patrick Meier Stand: 25. September 2013 Version: Dieses Dokument basiert auf die Versuchsbeschreibung von Jörg Schwenk: S/MIME zur Verschlüsselung und zum Signieren von s., Version 0.6, 15 Nov. 2007

2 1 Organisation 1 Organisation 1.1 Erforderliche Vorkenntnisse zur Teilnahme an diesem Versuch Vorlesung Kryptographie und Datensicherheit, Prof. Paar. Struktur von Zertikaten nach X.509. Auszug Sichere aus Jörg Schwenk: Sicherheit und Kryptographie im Internet, Vieweg- Verlag 2002 (in Abschnitt 2 auszugsweise abgedruckt). Abschnitt Using Mail/Signing & Encrypting Messages aus Mozilla Help lesen Internet Draft Header Protection for S/MIME, Lijun Liao und Jörg Schwenk. ietf.org/html/draft-liao-smimeheaderprotect Kontrollfragen Sie sollten folgende Fragen beantworten können (bevor der Versuch beginnt): Aus welchen Teilen besteht eine nach RFC822? Welche Vorbereitungen müssen Sie treen, um eine signieren zu können? Was ist der Unterschied zwischen opaque-signed und clear-signed? Welche Information in Header von signierten S/MIME s ohne Header-Protection-Erweiterung sind geschützt, und unter welchen Voraussetzungen? Wie werden Header-Felder in signierten S/MIME s mit Header-Protection-Erweiterung geschützt? Was ist POP, SMTP, IMAP? Wie kommt eine vom Absender zum Empfänger? 1.3 Schriftliche Versuchsauswertung Jedes Team fertigt eine schriftliche Auswertung an. Beantworten Sie darin die Fragen, die zu den jeweiligen Teilversuchen gestellt wurden. Bitte geben Sie auch Feedback, ob Sie den Praktikumsversuch als interessant empfunden haben und ob dieses Dokument für Sie bei der Versuchsdurchführung hilfreich war. Verbesserungsvorschläge sind willkommen! Die Versuchsauswertung ist schriftlich beim nächsten Termin mitzubringen! Grundpraktikum NDS - Sicherheit September 2013

3 2 Sichere 2 Sichere S/MIME hat sich in der Microsoft-Welt als Standard für sichere weitgehend durchgesetzt; seit er auch vom Mozilla-Projekt unterstützt wird (Mozilla 1.7.3) ist er wieder für fast alle Plattformen verfügbar. Er soll hier schrittweise anhand seiner Herkunft erläutert werden. Dazu müssen wir das ursprüngliche -Format, wie es in RFC 822 beschrieben ist, und seine Beschränkungen betrachten. Diese Beschränkungen wurden durch den MIME-Standard aufgehoben, indem neue Datentypen und Codierungen eingeführt wurden. Auf dieser Basis ist es möglich, spezielle Datentypen für die sichere -Kommunikation zu denieren nach RFC 822 Im August 1982 wurden zwei Standards verabschiedet, die die Grundlage für den -Dienst im Internet legten: In RFC 821 wurde ein einfaches, ASCII-basiertes Protokoll deniert, das den Austausch von s zwischen zwei Mailservern beschreibt. In RFC 822 wird der Aufbau einer beschrieben. Date: Mon, 5 Mai :25:37 (GMT) From: Subject: RFC 822 To: Hallo. Dieser Abschnitt ist der Inhalt der Nachricht der durch eine Leerzeile vom Header getrennt ist. Abbildung 1: Eine einfache nach RFC 822 Eine nach RFC 822 besteht aus folgenden Teilen (vgl. Abb. 1): Envelope (Umschlag): Er wird vom Mailsystem während des Transports der mit Hilfe der Header-Information erzeugt und verändert. Header (Kopf): Er enthält Informationen zu Absender und Empfänger, zum Datum, zum Betre, usw. Jede Zeile besteht aus Schlüsselwort, Doppelpunkt, und Argumenten. Body (Text): Hier wird ein reiner ASCII-Text erwartet, der vom Header durch eine Leerzeile getrennt ist. Diese einfache Datenstruktur wird mit einem einfachen, ASCII-basierten Protokoll übertragen, dem Simple Mail Transfer Protocol (SMTP) (RFC 821). Abb. 2 gibt den Ablauf eines SMTP-Protokolls für den Fall wieder, dass eine auf dem Mailserver uni.de zwischengespeicherte des Nutzers an die Mailadresse weitergeleitet werden soll. Dieses Protokoll funktioniert nur zwischen Rechnern, die ständig online sind, und auf denen ein SMTP-Dämon läuft. Um der zunehmenden Zahl von PCs Rechnung zu tragen, wurden zum Abruf der Nachrichten noch das Post Oce Protocol (POP) (RFC 1725) und das Internet Message Access Protocol (IMAP) (RFC 1730) deniert, mit denen man auf dem Mailserver zwischengespeicherte s entweder insgesamt oder selektiv laden kann. Eine zunehmend wichtigere Rolle spielt auch der Web-basierte Ansatz, bei dem s über das http-protokoll gelesen und versendet werden. Grundpraktikum NDS - Sicherheit September 2013

4 2 Sichere uni.de Mailserver: uni.de Mailserver: rub.de rub.de SMTP POP IMAP SMTP SMTP POP IMAP HELO rub.de --> MAIL FROM: --> RCPT TO: --> DATA --> From: --> To: --> Subject: Hello --> --> Hello World! -->. --> < rub.de SMTP server ready < rub.de says hello < sender OK < recipient OK < send mail including header lines and blank line between header and body; end with. -line < message accepted QUIT --> < rub.de closing connection Abbildung 2: Die Schritte im SMTP-Protokoll Diese einfachen, ganz auf einfache englischsprachige Textnachrichten zugeschnittenen -Standards RFC 821 und 822 stieÿen schnell an ihre Grenzen: Binärdaten müssen vor dem Versenden in ASCII umgewandelt werden (z.b. auf UNIX-Systemen mit Programmen wie uuencode). Ein einheitlicher Standard für diese Umwandlung fehlte, und so war das Versenden von Nicht-ASCII-Dateien z.b. von einem UNIX-Rechner auf einen PC eine komplizierte Angelegenheit. Umlaute aus anderen Sprachen und fremde Schriftarten (z.b. Kyrillisch) konnten nicht dargestellt werden. Jedes -Gateway interpretierte die zu übertragende als Folge von ASCII-Zeichen. Fehlerhafte Implementierungen von Gateways hatten zur Folge, dass Carriage Return oder Linefeed-Zeichen gelöscht, Zeilen mit einer Länge von mehr als 76 Zeichen abgeschnitten oder umgebrochen, mehrfache Leerzeichen entfernt und Tabulatoren in mehrfache Leerzeichen umgewandelt wurden. Es war bald an der Zeit für eine Erweiterung des Standards, um der weiten Verbreitung des - Dienstes Rechnung zu tragen. Grundpraktikum NDS - Sicherheit September 2013

5 2 Sichere 2.2 Multipurpose Internet Mail Extensions (MIME) Diese Erweiterung des -Standards wird in RFC 2045 bis 2049 beschrieben. Die wesentlichen Neuerungen sind: Einführung von fünf neuen Header-Feldern, um den transportierten Content besser beschreiben zu können. Festlegung von standardisierten Inhaltsformaten, um ihre Darstellung auf MIME-konformen Clients zu ermöglichen. Standardisierung von Übertragungscodierungen, die robust gegen Fehler der Mailgateways sind. Da es längst gängige Praxis war, in s nicht nur ASCII-Text, sondern alle möglichen Daten zu versenden, brauchte man eine Möglichkeit, diesen Mail-Inhalt mit Hilfe von Metadaten zu beschreiben. Zu diesem Zweck wurden die folgenden fünf Headerfelder neu eingeführt: MIME-Version: 1.0. Die Versionsnummer muss bei jedem Standard mit angegeben werden, um spätere Änderungen zu ermöglichen. Dies ist also keine Besonderheit von MIME, sondern taucht bei allen Standards auf. Der aktuelle Wert 1.0 verweist auf RFC 2045 und RFC Content-Type: Dies ist das wichtigste neue Header-Feld. Es beschreibt den angefügten Inhaltstyp (Content) und ermöglicht es einem MIME-Client so, das passende Anzeigemodul zu starten. Z.B. bewirkt die Angabe des Mime-Typs text/html, dass nicht das HTML-File in seiner Textform wiedergegeben wird, sondern von einem HTML-Interpreter dargestellt wird. Die standardisierten Content-Typen sind in Abb. 2.3 wiedergegeben, die Liste ist aber beliebig erweiterbar. Content-Transfer-Encoding: Da der Inhalt einer weiterhin als Folge von ASCII-Zeilen, die nicht mehr als 76 Zeichen enthalten, übertragen werden muss (RFC 822 bleibt ja weiterhin gültig), stellt MIME eine Auswahl von Standard-Codierungsverfahren bereit, die den Content in diese Form umwandeln. Diese Transportcodierungen können jeweils passend zum Content gewählt werden und sind weiter unten beschrieben. Content-ID: Dies ist ein eindeutiger Bezeichner des Content. Content-Description: Beschreibung des Content. Dies ist hilfreich bei der Fehlersuche, falls der Content nicht (korrekt) wiedergegeben werden kann. Als Übertragungscodierungen wurden folgende Algorithmen festgelegt, die je nach den Fähigkeiten der -Gateways und den Eigenschaften des Content ausgewählt werden: 7 Bit: Der Text der Nachricht enthält nur ASCII-Zeichen. Es wurde keine Codierung vorgenommen. 8 Bit: Der Text der Nachricht enthält nur kurze Zeilen (höchstens 76 Zeichen). Es können aber Nicht-ASCII-Zeichen auftreten. Es wurde keine Codierung vorgenommen. (Hier besteht die Gefahr, dass Mailgateways diese Nicht-ASCII-Zeichen falsch übertragen.) Binary: Lange Zeilen mit Nicht-ASCII-Zeichen treten auf. Es wurde keine Codierung vorgenommen. (Lange Zeilen können hier von alten Mailgateways nach dem 76. Zeichen abgeschnitten werden.) Quoted-printable: Nicht-ASCII-Zeichen wurden durch eine Folge von ASCII-Zeichen ersetzt. Falls der codierte Inhalt viel ASCII-Text enthält, bleibt er so lesbar. Diese Codierung eignet sich z.b. für deutschsprachigen Text, in dem die Umlaute dann durch ASCII-Zeichenfolgen ersetzt werden. Base64: Je 3*8 Bit werden als 4*6 Bit-ASCII-Zeichen übertragen. Diese Codierung wird auf Binärdaten angewendet. Die Beispielnachricht aus Abb. 3 besteht aus drei Teilen: Dem Header mit den neuen MIME-Feldern und einer Warnmeldung für nicht MIME-fähige -Clients, einer deutschsprachigen Textnachricht Grundpraktikum NDS - Sicherheit September 2013

6 2 Sichere Typ Subtyp Beschreibung text plain Unformatierter Text, z.b. ASCII enriched Mit bestimmten Formatierungen mixed Unabhängige Teile, die zusammen übertragen und in der übertragenen Ordnung dargestellt werden sollen multipart parallel Unterschied zu Mixed: Hier ist keine Ordnung deniert qlternative Alternative Versionen derselben Information digest Wie Mixed, aber als Default-Typ/Subtyp wird Message/rfc822 angenommen rfc822 Der Body der Nachricht ist selbst eine message partial Zeigt eine Fragmentierte an external-body Pointer auf ein Objekt, das woanders liegt image jpeg JPEG-Format, JFIF-Encodierung gif GIF-Format video mpeg Video im MPEG-Format audio basic Einkanal 8 Bit ISDN, 8kHz application postscript Adobe Postscript octet-stream Binärdaten aus 8-bit-Bytes Tabelle 1: Standardisierte MIME-Datentypen mit Umlauten in quoted-printable-codierung, und einer MS-Word-Datei als binärem Anhang in Base64-Codierung. Die einzelnen Teile werden durch einen eindeutigen Separator, der hinter boundary= angegeben ist, voneinander getrennt. Eine MIME-Nachricht ist ein verschachtelter Datentyp. Sie kann daher als Baumstruktur dargestellt werden, mit den eigentlichen Inhalten als Blätter. So hat z.b. die MIME-Nachricht aus Abb. 3 die Wurzel multipart/mixed, und unter dieser Wurzel hängen die beiden Blätter text/plain (der - Text) und application/msword (das angefügte Word-Dokument). Eine MIME-Nachricht wird in drei Schritten erzeugt: 1. Die Reihenfolge der einzelnen Objekte, und die Baumstruktur selbst wird vom Sender-Client gemäÿ seiner Konventionen festgelegt. 2. Die Nachrichten-Inhalte (die Blätter) werden kanonisiert (s.u.). 3. Auf die kanonisierten Nachrichten-Inhalte wird eine passende Transport-Codierung angewendet. Für die sich anschlieÿenden kryptographischen S/MIME-Operationen sind die Schritte 2 und 3 wichtig. Mit der Darstellung der Daten in einer kanonischen Form wird im MIME-Standard sichergestellt, dass die Daten im Sende- und Zielsystem dieselbe Bedeutung haben. Das ist am einfachsten am Typ text zu erläutern: Der verwendete Zeichensatz muss mit angegeben werden (z.b. in Abb. 3 charset=iso ), und das Ende einer Zeile muss durch die Zeichenfolge <CR><LF> beschrieben werden. Dadurch kann ein Text, der auf einem UNIX-System erstellt wurde, auch auf einem PC in genau der gleichen Form wiedergegeben werden. Der signierte Text hat also auf beiden Systemen die gleiche Bedeutung. An das jeweilige Transportsystem angepasst werden müssen die Transportcodierungen. Im - Bereich muss hier darauf geachtet werden, dass das resultierende MIME-Objekt alle Forderungen aus RFC 822 erfüllt, also z.b. nur aus ASCII-Zeichen besteht. Wird ein MIME-Objekt dagegen über HTTP übertragen, so sind beliebige Bytes erlaubt. Grundpraktikum NDS - Sicherheit September 2013

7 2 Sichere Date: Mon, 5 Mai :25:37 (GMT) From: PC113 Subject: MIME To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_nextpart_000_01bdcc1e.a4d02412" Content-Length: Hier kann eine Fehler- oder Warnmeldung stehen, die nur von nicht-mimefaehigen Clients dargestellt wird _=_NextPart_000_01BDCC1E.A4D02412 Content-Type: text/plain; charset="iso " Content-Transfer-Encoding: quoted-printable Ein deutschsprachiger Text wurde hier als quoted-printable codiert, um m=f6glichst viel Text f=fcr nicht-mime-clients lesbar zu halten. Mit freundlichen Gr=FC=DFen pc _=_NextPart_000_01BDCC1E.A4D02412 Content-Type: application/msword; name="sicherheitskonzept.doc" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="sicherheitskonzept.doc" Content-Location: ATT-0-B028877FBC37D211B3CD00A0C981DBBA-ANGEBO%7E1.DOC 0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAABAAAAAAAAAAA EAAAFAAAAAEAAAD+////AAAAAAUAAAD///////////////////////////////////////////// ////////////////////////////////////////////////////////////////////////////... dgv3yxkglsbtexn0zw1ldq1ezwzpbml0aw9uihzvbibty2h1dhptyd9uywhtzw4gzvxyog1dbgll bnqglsbtb2z0d2fyzq1xaw5kb3dzifzlcnnpb24gwa1nywnpbnrvc2gnu2vydmvyc3lzdgvtzq1o _=_NextPart_000_01BDCC1E.A4D Abbildung 3: MIME- , bestehend aus MIME-Header, ASCII-Fehlertext, dem eigentliche Text in quoted-printable-codierung, und einem (gekürzten) base64-attachment einer Binärdatei 2.3 Secure/MIME Der Standard Secure/MIME erweitert die MIME-Datentypen um Konstrukte für signierte und verschlüsselte Nachrichten (siehe Tabelle 3). Er ist im Wesentlichen in den RFCs (Version 2), 2630, 2632 und 2633 (Version 3) beschrieben [SMIME]. Der Wechsel von Version 2 zu Version 3 ist weniger durch technische Notwendigkeiten begründet, als vielmehr mit der Geschäftspolitik rund um das RSA-Patent. In S/MIME Version 2, der unter maÿgeblicher Beteiligung der Firma RSA Inc. entstand, spielt der RSA-Algorithmus, als einziger zwingend vorgeschriebener Public-Key-Algorithmus, eine Schlüsselrolle, und die Public Key Cryptography Standards PKCS#1, PKCS#7 und PKCS#10 dieser Firma werden in den RFCs namentlich erwähnt. Warum dies von der IETF nicht weiter unterstützt wurde, ist unbekannt. Jedenfalls wurde in Version 3 der RSA-Algorithmus zur Option degradiert, und die PKCS-Standards zu einem Cryptographic Message Syntax (CMS)-Dokument (RFC 2630) zusammengefasst. Die wesentlichen Unterschiede zwischen den beiden Versionen betreen die verwendeten kryptographi- Grundpraktikum NDS - Sicherheit September 2013

8 2 Sichere schen Algorithmen und sind in der Tabelle 2 zusammengefasst. Abgesehen von diesen Unterschieden basieren Version 2 und 3 auf der gleichen Technologie. Da die PKCS-Standards auch auÿerhalb der S/MIME-Welt bedeutsam sind, gehen wir in einem eigenen Abschnitt anhand von RFC 2630 näher auf sie ein. Eine Beschreibung neuer Sicherheitsfunktionalitäten, die mit Hilfe des S/MIME-Standards implementiert werden können, ndet man im Dokument Enhanced Security Services for S/MIME (RFC 2634). Dort ist beschrieben, wie man signierte Empfangsbestätigungen und Sicherheitslabel erzeugen kann, wie die Verschlüsselung einer Nachricht an eine groÿe Mailingliste in sicherer Art und Weise einem Mail Agent überlassen werden kann, und wie Informationen zum Zertikat in die Signatur mit eingebunden werden können. Algorithmus S/MIME Version 2 S/MIME Version 3 vorgeschrieben optional vorgeschrieben optional Hash MD5, SHA-1 SHA-1 MD5 Signatur RSA DSA RSA Public-Key-Verschlüsselung RSA Die-Hellman (RFC 2631) RSA Tabelle 2: Die unterschiedliche Verwendung von kryptographischen Algorithmen in den S/MIME Versionen 2 und Einleitung Der groÿe Vorteil der Verwendung des MIME-Standards für Sicherheitsfunktionen liegt darin, dass Verschlüsselung und Signatur genauso einfach zu bedienen sind, wie z.b. die HTML-Formatierung einer oder das Anfügen eines Attachments. Dass dies in den vorliegenden Clients noch nicht so reibungslos funktioniert, liegt an der Art der Implementierung, nicht am S/MIME-Konzept. Abb. 4 gibt ein Beispiel für die komfortable Auswertung und Signalisierung von Sicherheitseigenschaften, bei sehr komplexem Quelltext (Abb. 5). Abbildung 4: Darstellung einer nach S/MIME signierten im Mozilla Thunderbird Da der S/MIME-Standard überwiegend von der Firma RSA Security Inc. vorangetrieben wurde, stützen sich die vorgeschlagenen Datentypen auch weitgehend auf die von RSA publizierten Public Key Cryptography Standards (PKCS). Die drei wichtigsten Standards aus dieser Reihe sind PKCS#7: Festlegung eines Datenformats für verschlüsselte und/oder signierte Datensätze PKCS#10: Festlegung eines Datenformats zur Beantragung eines X.509-Zertikats. PKCS#12: Format zur sicheren Speicherung kryptographischer Schlüssel. Die besondere Komplexität von S/MIME liegt im Wechselspiel zwischen 7-Bit ASCII-Code und 8-Bit Binärcode. Während der Generierung oder Auswertung einer S/MIME-Nachricht kann es erforderlich sein, mehrmals zwischen 7-Bit- und 8-Bit-Darstellung umzurechnen Verschlüsselung Abb. 6 gibt eine S/MIME-verschlüsselte Nachricht wieder. Sie hat den MIME-Typ application/pkcs7-mime. Der Text der Nachricht ist Base64-codiert. Nach Entfernen dieser Codierung sieht man im rechten Fenster den (gekürzten) PKCS#7-Vorspann, der alle zur Entschlüsselung Grundpraktikum NDS - Sicherheit September 2013

9 2 Sichere Message-ID: Date: Fri, 21 Nov :43: From: pc113 Content-Type: multipart/signed; protocol=``application/x-pkcs7-signature``; micalg=sha1; boundary=``=_server `` To: pc115 Subject: test mit einer digitalen Unterschrift This is a MIME-formatted message. If you see this text it means that your software does not support MIME-formatted messages. --=_server Content-Type: text/plain; charset=iso ; format=flowed Content-Transfer-Encoding: 7bit...Inhalt... --=_server Content-Type: application/x-pkcs7-signature; name=``smime.p7s`` Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=``smime.p7s`` Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACA...GrHGMKS1MujSelBAAAAAAAAA= --=_server Abbildung 5: Gekürzter Quelltext zu Abb. 4 der Nachricht benötigten Informationen enthält, und den Beginn der verschlüsselten Nachricht in Hexadezimalnotation. Das PKCS#7-Objekt enthält folgende Informationen: Content-Type: Hier wird angegeben, dass es sich um verschlüsselte Daten handelt. RecipientInfo/Serial-Number und RecipientInfo/Issuer: Hier wird angegeben, dass zur Verschlüsselung des symmetrischen Schlüssels der öentliche Schlüssel aus dem Zertikat Nummer 716 des angeführten Herausgebers verwendet wurde. Key-Encryption-Algorithm: Der Sitzungsschlüssel wurde mit dem RSA-Algorithmus verschlüsselt. Encrypted-Key: Hier steht der mit dem RSA-Algorithmus und dem angegebenen öentlichen Schlüssel verschlüsselte symmetrische Schlüssel. Encryption-Algorithm: Hier steht der verwendete symmetrische Algorithmus (TripelDES im CBC- Modus) und der Initialisierungsvektor. Encrypted-Data: Hier steht die eigentliche verschlüsselte Nachricht. Beim Sender wurde diese Nachricht wie folgt generiert: Der Absender teilte seinem S/MIME-fähigen E- Mail-Client mit, dass die Nachricht an den im To Feld angegebenen Empfänger verschlüsselt werden soll. Der Client durchsuchte daraufhin seine interne Zertikatsdatenbank, ob ihm ein X.509-Zertikat vorliegt, das die angegebene -Adresse enthält. Fand er keines, so musste er sich erst ein solches Zertikat beschaen... und den Absender mit einer Warnmeldung darüber informieren, dass eine Verschlüsselung nicht möglich ist. War hingegen ein Zertikat vorhanden, so wendete er das in Kapitel 1 beschriebene hybride Verschlüsselungsverfahren an, und zwar mit dem öentlichen Schlüssel, der in dem passenden Zertikat enthalten ist. Zum Schutz gegen eine unbeabsichtigte Veränderung der Daten durch einen Mailserver, die eine Entschlüsselung unmöglich machen würde, wurde die Nachricht noch base64-codiert. Grundpraktikum NDS - Sicherheit September 2013

10 2 Sichere Typ Subtyp S/MIME Parameter File Beschreibung multipart signed Eine signierte Nachricht in zwei Teilen: Der erste Teil ist die unveränderte Originalnachricht, der zweite die Signatur (clear-signed) pkcs7-mime signed-data.p7m Ein signierter S/MIME-Datensatz pkcs7-mime enveloped-data.p7m Ein verschlüsselter S/MIME- Datensatz pkcs7-mime certs-only.p7c Der Datensatz enthält nur X.509- application Zertikate pkcs7- signature -.p7s Der Content-Typ des Signaturteils der multipart/signed-nachricht pkcs10- mime -.p10 Ein Request zur Generierung eines Zertikats nach PKCS#10 Tabelle 3: S/MIME-Datentypen Der S/MIME-Client auf Empfängerseite entfernt zunächst die base64-codierung. Er kann eine solche Nachricht entschlüsseln, indem er zunächst prüft, ob er das unter RecipientInfo angegebene Zertikat und den dazu gehörenden privaten Schlüssel (noch) besitzt. In der Regel wird dies der Fall sein. Er entschlüsselt dann mit seinem privaten Schlüssel den hinter Encrypted-Key angegebenen Datensatz, entnimmt daraus den symmetrischen Schlüssel und entschlüsselt mit diesem und dem angegebenen Encryption-Algorithm die eigentliche Nachricht Signatur Zur Signatur einer Nachricht stehen in S/MIME zwei verschiedene Datentypen zur Verfügung: application/pkcs-mime, smime-type=signeddata. Der Body der besteht aus einem einzigen Objekt, und zwar einem PKCS#7-Objekt vom Typ signeddata. Dieses Objekt enthält die signierten Daten, die Signatur und alle Zusatzinformationen, die zur Überprüfung der Signatur notwendig sind (verwendete Algorithmen, Zertikate). Da auch die signierten Daten im PKCS#7-Binärformat codiert sind, können sie nur von einem S/MIME-fähigen Client, der ein entsprechendes PKCS#7-Modul enthält, dargestellt werden. Auf jedem anderen Client ist die Nachricht überhaupt nicht darstellbar. Nachrichten dieser Art werden auch als opaque-signed bezeichnet. multipart/signed. Der Body dieses Typs besteht aus zwei Teilen: Der erste Teil, die signierten Daten, sind als (ggf. in sich geschachteltes) MIME-Objekt codiert. Sie können also von jedem MIME-fähigen Client angezeigt werden. Der zweite Teil ist die dazu gehörende digitale Signatur, die als PKCS#7-Objekt codiert ist. Sie kann nur von S/MIME-fähigen Clients ausgewertet werden (clear-signed). Die Entscheidung zwischen den beiden Formaten hängt davon ab, welche Clients die Empfänger verwenden, und welche Prioritäten gesetzt werden: Sollen alle Empfänger (auch die mit nicht S/MIME-fähigen Clients) die Nachricht lesen können, so muss multipart/signed verwendet werden. Nachteil dieses Formats ist es, dass durch Veränderungen an der ggf. recht komplexen MIME-Struktur der durch ein Mail-Gateway die Signatur ungültig gemacht werden kann. Dies kommt in der Praxis häug vor. Steht vor allen die Integrität und Authentizität der Nachricht im Vordergrund, so muss Grundpraktikum NDS - Sicherheit September 2013

11 2 Sichere ... Date: Mon, 5 May :15: From: PC 113 MIME-Version: 1.0 To: Subject: S/MIME Content-Type: application/x-pkcs7- mime; name="smime.p7m" Content-Transfer-Encoding: base64 Content-Description: S/MIME Encrypted Message MIAGCSqGSIb3DQEHA6CAMIACAQAxgcwwgckCAQ AwczBtMQswCQYDVQQGEwJERTEcMBoGA1UE ChMTRGV1dHNjaGUgVGVsZWtvbSBBRzEdMBsGA1 UECxMUVGVsZVNlYyBUcnVzdCBDZW50ZXIx... ITAfBgNVBAMTGERldXRzY2hlIFRlbGVrb20gVG VzdCBDQQICAswwDQYJKoZIhvcNAQEBBQAE QJtWSHPh+l2D+3UqW0itsjOKE1oyAkAz+wtmH/ u42stjeeyhxkjinthw0rrkhtf07fq7pus5 Message-Body:... Envelope: PKCS7: Content-Type: pkcs7-envelopeddata Version: 0 RecipientInfos: RecipientInfo: Version: 0 Serial-Number: 716 Issuer:... Key-Encryption-Algorithm: Algorithm: rsaencryption Parameter: Encrypted-Key: Length: 64 Bytes 9B:56:48:73:E1:FA:5D:83:... Encrypted-Content: Content-Type: pkcs7-data Encryption-Algorithm: Algorithm: des-ede3-cbc Parameter: Octet-String: Length: 8 Bytes C4:FB:D7:05:A9:84:83:75 Encrypted-Data: Length: 3608 Bytes 3A:DB:98:08:1C:2E:C0:6B:41:... Abbildung 6: Aufbau einer verschlüsselten S/MIME-Nachricht application/pkcs-mime, smime-type=signeddata verwendet werden. Die Mailgateways sehen nur einen groÿen MIME-Block, den sie nicht verändern können, da die interne MIME-Struktur der Nachricht in PKCS#7 gekapselt ist. Nicht S/MIME-fähige Clients können mit dieser Darstellung nichts anfangen. Die Generierung einer opaque_signed-nachricht ist ähnlich wie die einer verschlüsselten Nachricht. Die verschiedenen Kapselungen sind in Abb. 7 dargestellt. In Abb. 8 ist eine multipart/signed Nachricht dargestellt. Entfernt man die Transport- und PKCS#7-Codierung, so kann man die Informationen sehen, die zu Verikation der digitalen Signatur erforderlich sind: Digest-Algorithm: Hier steht, welcher Hash-Algorithmus zur Bildung des Hashwerts der vorangegangenen Teile benutzt wurde. Certicates: Hier beginnt eine Kette von Zertikaten, die zur Verikation benötigt werden: Das Client-Zertikat wird benötigt, um die Echtheit der Signatur zu verizieren. Das CA-Zertikat wird benötigt, um die Echtheit des Client-Zertikats zu überprüfen, usw. SignerInfo: Hier steht, aus welchem Zertikat der öentliche Schlüssel zur Überprüfung der Signatur verwendet werden muss. (Hier das Zertikat mit der Seriennummer 549.) Signature: Hier steht die Signatur der vorangegangenen Teile. Der empfangende Client kann mit Hilfe des micalg-algorithmus den Hashwert über den ersten Teil der multipart/signed-nachricht bilden. Dieser Wert wird dann verwendet, um zunächst die Gültigkeit der Signatur zu überprüfen, der dann noch die Überprüfung der Gültigkeit der Zertikatskette folgen muss. Grundpraktikum NDS - Sicherheit September 2013

12 3 Header Protection in signierten S/MIME-Nachrichten Mime-Version: 1.0 Content-Type: application/pkcs-mime, smimetype=signeddata PKCS#7-Version: 1.0 PKCS#7-Header: Algorithms: Certificates: Signature: Content: Mime-Version: 1.0 multipart/mixed text/plain application/msword ASCII Abbildung 7: Struktur einer opaque-signed Nachricht 3 Header Protection in signierten S/MIME-Nachrichten 3.1 S/MIME Einschränkung In den älteren S/MIME-Spezikationen(bis zu der 3.0 Version inklusive) gab es keinen Header-Schutz. Der Header-Schutz wurde also erst in der S/MIME 3.1 Spezikation eingeführt. In der bestehenden S/MIME 3.1 Spezikation wird der Header-Schutz dadurch erreicht, dass man die ganze Nachricht als ein message/rfc822-mime-objekt betrachtet. Die Header-Felder, die im RFC822 deniert wurden, beinhalten sicherheitskritische Informationen, die nicht kryptographisch geschützt werden. Die einzigen Ausnahmen sind From und Sender Header- Felder, denn diese müssen von einem Mail-Agent überprüft werden, solange in dem Sender-Zertikat eine Adresse vorhanden ist. Wenn dieser Vergleich fehlschlägt, ist eine andere Verarbeitung der für den Client vorgesehen (z.b. Anzeige einer ungültigen Signatur). Alle anderen Header-Felder, wie z.b. To, Date, Reply-To oder Subject können nicht überprüft werden. Die bestehende S/MIME 3.1 Version erzielt den Schutz von Header-Feldern indem sie alle Header- Felder, generiert von einem Sender-Mail Client, zusammen mit dem Inhalt der Nachricht in einem message/rfc822 Objekt einschlieÿt,welches dann durch S/MIME geschützt werden kann. Es hängt von dem empfangenden Client ab, wie eine solche Nachricht dem Benutzer präsentiert wird. Dieses Verfahren hat folgende Nachteile: Alle Header-Felder, die in der inneren Nachricht vorhanden sind, müssen auch in der äuÿeren Nachricht vorhanden sein (d.h. diese Felder müssen doppelt vorhanden sein), damit die Nachricht RFC2822 konform ist und damit der Mail-Server und die betroenen Systeme die Nachricht weiterleiten können. Nur die inneren Header-Felder werden geschützt, nicht die äuÿeren. Wie in (RFC3851) erwähnt, hängt es von dem empfangenden Client ab. Es ist ihm überlassen, wie die inneren Header-Felder zusammen mit den ungeschützten äuÿeren Header-Feldern dargestellt werden. Normalerweise werden folgende, wenn vorhanden, Header-Felder in den Clients angezeigt: From, Sender, To, CC, Date, und Subject. Falls ein Header-Feld in beiden Headern vorhanden ist, wird das Grundpraktikum NDS - Sicherheit September 2013

13 3 Header Protection in signierten S/MIME-Nachrichten... From: To: Subject: Date:... MIME-Version: 1.0 Content-Type: multipart/signed; protocol= application/x-pkcs7- signature ; micalg=sha-1; boundary= boundary --boundary Eigentliche MIME- (ggf. mit Attachments) --boundary Content-Type: application/ x-pks7-signature; name= smime.p7s ; Content-Transfer-Encoding: Base64 PKCS#7: Content-Type: pkcs7-signeddata Version: 1 Digest-Algorithms: Digest-Algorithm: Algorithm: sha1 (2B:0E:03:02:1A) Parameter: Content: PKCS7: Content-Type: pkcs7-data Certificates: Certificate: CA-Certificat Certificate: Client-Certificat (549) SignerInfos: SignerInfo: Serial-Number: Signature: 0F:9B:46:5B:...:99:BC:44... MIAGCSqGSIb3DQEH...Jx9cS 9WPmbxEkAAAA== --boundary-- Abbildung 8: Aufbau einer clear-signed S/MIME-Nachricht innere Header-Feld angezeigt. Falls ein Header-Feld nur in dem äuÿeren Header vorhanden ist, dann wird dieses angezeigt. Viele Nachrichten beihnaltet keine Sender und CC Header-Felder, demzufolge könnte man diese Header-Felder nachträglich in den äuÿeren Header hinzufügen, um die Empfänger zu verwirren. 3.2 Header Protection nach dem vom Lehrstuhl NDS entwickelten Mechanismus Um einen ezienteren Header-Schutz zu erreichen, wurde von dem Lehrstuhl für Netz- und Datensicherheit ein neues Verfahren vorgeschlagen - Header Protection for S/MIME. Diese Methode wird als Internet Draft in IETF veröentlicht. Im Folgenden nden Sie nur einen Auszug. Für detailierte Information bitte wenden Sie sich an die IETF-Seite https://datatracker.ietf.org/drafts/ draft-liao-smimeheaderprotect/. 2. S/MIME Header Protection Entity A smime header protection entity contains names of header fields to be protected, the canonicalization algorithm, the digest algorithm and the corresponding digest value Fieldname List The fieldname-list is a colon-separated list of header field names that identify the header fields presented to the digest algorithm; it Grundpraktikum NDS - Sicherheit September 2013

14 3 Header Protection in signierten S/MIME-Nachrichten is defined as follows: fieldname-list = lowercase-field-name *(":" lowercase-field-name) lowercase-field-name = field-name in lowercase The fieldname-list MUST contain the complete list of header fields in the order presented to the digest algorithm. The field name MUST be lowercase. The field MAY contain names of header fields that do not exist when digested; nonexistent header fields do not contribute to the digest value computation (that is, they are treated as the null input, including the header field name, the separating colon, the header field value, and any CRLF terminator). The fieldname-list is compared against actual header field names in a case insensitive manner. Signers choosing to protect an existing header field that occurs more than once in the message (such as "Resent-From") MUST protect the physically last instance of that header field in the header block. Signers wishing to protect multiple instances of such a header field MUST include the header field name multiple times and MUST protect such header fields in order from the bottom of the header field block to the top. The signer MAY include more instances of a header field name than there are actual corresponding header fields to indicate that additional header fields of that name SHOULD NOT be added SMIME Header Protection The smime-header-protection attribute type specifies the S/MIME header protection entity. It MUST be a signed attribute or an authenticated attribute; it MUST NOT be an unsigned attribute, unauthenticated attribute, or unprotected attribute in CMS signature.... The attrvalues of the smime-header-protection attribute contains only one value that has ASN.1 type SMIMEHeaderProtectionEntity: SMIMEHeaderProtectionEntity ::= SEQUENCE { canonalgorithm CanonAlgorithmIdentifier, digestalgorithm DigestAlgorithmIdentifier, headerfieldnames PrintableString, digest Digest } The canonalgorithm field specifies the canonicalization algorithm. The digestalgorithm field specifies the digest algorithm. The format Grundpraktikum NDS - Sicherheit September 2013

15 3 Header Protection in signierten S/MIME-Nachrichten of an headerfieldnames is a "headername-list" field specified in Section 2.1. The headerfieldnames field specifies the list of header field names. The digest field carries the the digest value. 4. Creating Signed S/MIME Messages with Header Protection The signed S/MIME messages with header protection are created same as in [RFC3851] except the followings: o o Before computing the digest value over the signedattrs, the smime-header-protection attribute MUST be prepared (see Section 4.1) and added to the signedattrs. All header fields that are protected MUST be prepared before the preparing the smime-header-protection Preparing an SMIME-Header-Protection Attribute An smime-header-protection attribute is prepared as follows: Step 1. Choose the canonicalization algorithm, the digest algorithm, and the list of names of message header fields to be digested. The digest algorithm SHOULD be the same as the digest algorithm in the SignerInfo which the smime-header-protection attribute should be added to. Step 2. Retrieve the message header fields from the message according to the protected header fields from Step 1. Step 3. Canonicalize the retrieved header fields from Step 2 according to the canonicalization algorithm. Step 4. Compute the digest value over the canonicalization result in Step 3 according to the digest algorithm. Step 5. Create an smime-header-protection attribute. Store the chosen canonicalization algorithm, the digest algorithm, and the list of names from Step 1 in ASN.1 fields canonalgorithm, digestalgorithm, and headerfieldnames, respectively. Store the digest value from Step 4 in the ASN.1 field digest. 5. Verifying Signed S/MIME Message with Header Protection The signed S/MIME message with header protection are verified first same as in [RFC3851], then the smime-header-protection attribute is verified as stated in Section Verifying an SMIME-Header-Protection Attribute Grundpraktikum NDS - Sicherheit September 2013

16 4 Programme An smime-header-protection attribute is verified as follows: Step 1. Retrieve the canonicalization algorithm, the digest algorithm, and the list of names of message header fields, and the digest value from the smime-header-protection attribute. Step 2. Retrieve the message header fields from the message according to the protected header fields from Step 1. Step 3. Canonicalize the retrieved header fields from Step 2 according to the canonicalization algorithm. Step 4. Compute the digest value over the canonicalization result in Step 3 according to the digest algorithm. Step 5. Compares the computed digest value from Step 4 and the stored one from Step 1. If both digest values are different, then the verification fails; otherwise the verification successes. 4 Programme In diesem Versuch werden SeaMonkey (Browser, Mail & Newgroups), Thunderbird mit Header-Protect- Erweiterung (siehe Kapitel 4.2), und MITM-Programm (siehe Kapitel 4.3) benutzt. 4.1 SeaMonkey Durch Start-Menü Internet -> Seamonkey (bin) wird das Programm SeaMonkey Browser gestartet. Sie können den SeaMonkey Mail-Client durch das Menü Window -> Mail & Newsgroups starten. 4.2 Thunderbird mit Header-Protect-Erweiterung Das Programm Thunderbird mit Header-Protection-Erweiterung 2 wurde im Lehrstuhl NDS entwickelt. Es bendet sich unter dem Verzeichnis /home/praktikum/ sicherheit/thunderbird und kann durch die durchführbare Datei thunderbird gestartet werden. Bitte beachten Sie, dass durch Start- Menü Internet -> Mozilla Thunderbird (bin) das andere Thunderbird gestartet wird. Das Thunderbird (HPE) kann s mit Header-Protection signieren und verzieren. Die Header- Protection-Erweiterung für das Senden signierter s können Sie aktivieren bzw. deaktivieren und einstellen: Menü Edit > Preferences > HeaderProtect (Siehe die Screenshots in Abb. 9). 4.3 MITM-Programm Für diesen Versuch wurde ein MITM-Programm im Lehrstuhl NDS entwickelt. Dieses MITM-Programm bendet sich unter dem Verzeichnis /home/praktikum/ sicherheit/mitm und kann durch die durchführbare Datei mitm gestartet werden. Es hat folgende Syntax: 2 zur Vereinfachung wird Thunderbird mit Header-Protection-Erweiterung im Rest dieser Beschreibung durch Thunderbird (HPE) bezeichnet. Grundpraktikum NDS - Sicherheit September 2013

17 4 Programme Abbildung 9: Konguration von Header-Protection in Thunderbird (HPE) This program is only for use in the NDS Netlab! Usage: mitm [OPTION VALUE] OPTION VALUE-TYPE (Options with * are required) -i/-i Ethernet Device (DEFAULT: eth0) -s/-s Source IP Address (IPv4) * -d/-d Destination IP Address (IPv4) * -p/-p Transport Protocol (DEFAULT: tcp) -n/-n Destination Port Number (DEFAULT: 80) -l/-l Delay between ARP-Packets in Seconds (DEFAULT: 10) -r/-r Modification: Direction {BOTH/FORTH/BACK} (DEFAULT: BOTH) -f/-f Modification: Search String (REGEXP) * -t/-t Modification: Replace String * -? This Help Ein Beispiel: mitm -s d n 25 -f "Subject: test" -t "Subject: TEST" Das MITM-Programm mit den oben gegebenen Parametern ersetzt die Zeichenkette Subject: test durch Subject: TEST in allen s, die von (Mail Client) nach (Mail Server) mit dem Protokoll SMTP gesendet werden. Damit wird der Betre einer von test nach TEST geändert. Die gesuchte Zeichenkette kann auch eine reguläre Darstellung (RegExp) sein. Die folgende RegExp- Darstellung ist für die Date-Zeile: Date:[ Und das folgende Kommando ändert das Absendedatum einer . mitm -s d n 25 -r f Grundpraktikum NDS - Sicherheit September 2013

18 5 Versuche -f "Date:[ -t "Date: Fri, 14 Nov :14: " Hinweise: Falls das geänderte Paket die maximal erlaubte Länge überschreitet, funktioniert das vorhandene MITM-Programm leider nicht mehr. Falls sich der Versand einer verzögert, bitte korrigieren Sie die Ersatzzeichenkette, so dass sie nicht länger als die gesuchte Zeichenkette ist. 5 Versuche 5.1 Netzwerkkomponenten Alle Mail Server sind als SMTP- und IMAP-Server konguriert. Gruppe 0 (in Subnetz 0): Mailserver: server0.netz0.test Clients: pc012, pc013, pc014, pc015. Konto: pcxxx (wobei xxx ein Platzhalter ist) -Adresse: Passwort: pcxxx Gruppe 1 (in Subnetz 1: Rechner pc112, pc113, pc114): Mailserver: server1.netz1.test Clients: pc112, pc113, pc114. Konto: pcxxx (wobei xxx ein Platzhalter ist) -Adresse: Passwort: pcxxx Gruppe 2 (in Subnetz 2): Mailserver: server2.netz2.test Clients: pc212, pc213, pc214, pc215. Konto: pcxxx (wobei xxx ein Platzhalter ist) -Adresse: Passwort: pcxxx 5.2 Ohne MITM-Angrie Aufgabe 1: Kongurieren Sie Ihren -Client SeaMonkey Kongurieren Sie Ihren Mozilla SeaMonkey -Client mit der -Adresse nach der im Kapitel 5.1 denierten Struktur. Önen Sie mit dem SeaMonkey-Browser und importieren Sie zunächst das Zertikat Ihrer CA. Beantragen Sie dann ein Zertikat für Ihre -Adresse. Kongurieren Sie dieses Zertikat in Mozilla SeaMonkey Mail. Versuchsauswertung: Screenshot der Detailansicht des geladenen Zertikats. Screenshot der Sea- Monkey Mail-Konguration. Grundpraktikum NDS - Sicherheit September 2013

19 5 Versuche Hinweis: Um die Zertikate anderer Personen identizieren zu können, müssen die entsprechende Vertrauenseinstellungen in dem Zertikat-Manager angekreuzt werden (Zertikat-Manager -> Zertizierungsstellen -> Ihre CA auswählen -> bearbeiten) Aufgabe 2: Senden einer signierten an Mailadressen in ihrer Gruppe Senden Sie eine signierte an alle Mailadressen in ihrer Gruppe. Ist diese Clear-Signed oder Opaque-Signed? Versuchsauswertung: Relevante Ausschnitte der PKCS#7-Struktur der Mails, jeweils mit Erläuterungen. Anmerkung: Zur Darstellung der PKCS#7-Struktur einer Mail gehen Sie wie folgt vor: Speichern Sie die als Datei (File (bzw. Datei)->Save As->File). Starten Sie eine Konsole und führen Sie folgendes Kommando aus: xmail < -Datei> <Ziel Verzeichnis>. Analysieren Sie die resultierende XMaiL. Versehen Sie den gekürzten XMaiL-Quelltext mit Anmerkungen (gern auch handschriftlich). Der gekürzte Quelltext sollte dabei nicht mehr als 2 Din A4-Seiten umfassen. Bestimmen Sie einige ausgewählte Object Identier unter näher. Hinweis: Object Identier (OID) ist ein weltweit eindeutiger Bezeichner, der benutzt wird, um ein Informationsobjekt zu benennen. Zum Beispiel: XMail-Quelltext: <DigestAlgorithm Algorithm= /> Bedeutung: Hash algorithm identier SHA-1 (Secure Hash Algorithm, Revision 1) Aufgabe 3: Senden einer verschlüsselten Nachricht Senden Sie eine verschlüsselte an eine Mailadresse in ihrer Gruppe. Ist das ohne Probleme möglich? Versuchsauswertung: Relevante Ausschnitte der PKCS#7-Struktur der Mails, jeweils mit Erläuterungen. 5.3 Mit MITM-Angrien Ab jetzt müssen alle Teams in einer Gruppe zusammen arbeiten. Zu Beginn wird jedem Team eine der Rollen (Empfänger, Sender oder MITM-Angreifer) zugeordnet. Jedes Team muss anschlieÿend alle der Rolle zugeordneten Aufgaben abarbeiten. Anschlieÿend werden die Rollen unter den Teams rotieren, bis schlieÿlich jedes Team einmal jede Rolle gespielt hat Aufgabe 5: Kongurieren Sie Ihren -Client Thunderbird (HPE) Kongurieren Sie ihren -Client Thunderbird (HPE) wie SeaMonkey in Aufgabe 1. Versuchsauswertung: nicht nötig in dieser Aufgabe. Grundpraktikum NDS - Sicherheit September 2013

20 5 Versuche Aufgabe 6: Senden einer signierten Nachricht mit SeaMonkey Der Sender sendet mehrere signierte s an den Emfänger. Der Angreifer soll das Header-Feld Subject während des Absendens ändern. Der Empänger soll dann die Signatur verizieren (einmal in SeaMonkey und einmal in Thunderbird (HPE)). Versuchsauswertung (Zum Ansehen des Quelltextes einer Nachricht: Menü View > Message Source): Für den Sender: Message-ID und Titel (Subject) der Nachricht. Für den MITM-Angreifer: Gesuchte Zeichenkette (RegExp) und Ersetzte Zeichenkette. Für den Empfänger: Message-ID und Titel (Subject) der Nachricht. Die Gültigkeit der Signatur in SeaMonkey und in Thunderbird (HPE) Aufgabe 7: Senden einer signierten Nachricht mit Thunderbird (HPE) Wie in Aufgabe 6, aber der Absender soll signierte s mit Thunderbird (HPE) abschicken. Der Sender soll sicherstellen, dass die Header-Protection-Funktion aktiviert ist und die vordenierte (Default) Fieldname List benutzt wird. Hinweis: Sie können Aufgabe 6 und 7 auch kombiniert durchführen. Dazu muss der Sender jeweils eine signierte Mail mit Seamonkey und eine mit Thunderbird HPE versenden. Der Angreifer muss beide Mails verändern und der Empfänger muss beide Mails jeweils mit beiden Clients verizieren. Grundpraktikum NDS - Sicherheit September 2013

Basisdienste I: Email/Listserver, NewsGroups

Basisdienste I: Email/Listserver, NewsGroups Basis-, Mehrwert-und Metainformationsdienste Kurs 7.6.2001 (Konstanz) / 23.6.2001 (Berlin) Dozent: Dr. Bernard Bekavac 1 Basisdienste I: Email/Listserver, NewsGroups TCP / IP Aufteilung im TCP/IP-Protokoll

Mehr

E-Mail. Nachrichtenübertragung. Internetkommunikation Christof Fox. Wie werden Nachrichten Übertragen?

E-Mail. Nachrichtenübertragung. Internetkommunikation Christof Fox. Wie werden Nachrichten Übertragen? E-Mail Nachrichtenübertragung 1 Wie werden Nachrichten Übertragen? Über Protokolle: SMTP (Simple Mail Transfer Protocol) POP3 (Post Office Protocol Version 3) IMAP (Internet Message Access Protocol) 2

Mehr

SMTP Simple Mail Transfer Protocol

SMTP Simple Mail Transfer Protocol SMTP Simple Mail Transfer Protocol von Christoph Weitkamp Michael Johannfunke cweitkam@techfak.uni-bielefeld.de mjohannf@techfak.uni-bielefeld.de Gliederung Beispiel: E-Mail Geschichte Aufbau Header Brief

Mehr

Technische Richtlinie BSI TR-03109-1 Anlage I: CMS-Datenformat für die Inhaltsdatenverschlüsselung und -signatur

Technische Richtlinie BSI TR-03109-1 Anlage I: CMS-Datenformat für die Inhaltsdatenverschlüsselung und -signatur Technische Richtlinie BSI TR-03109-1 Anlage I: CMS-Datenformat für die Inhaltsdatenverschlüsselung und -signatur Version 1.0 Datum: 18.03.2013 Bundesamt für Sicherheit in der Informationstechnik Postfach

Mehr

Netzsicherheit II, SS 2011 Übung 4

Netzsicherheit II, SS 2011 Übung 4 Netzsicherheit II, SS 2011 Übung 4 Prof Dr Jörg Schwenk Betreuer: Florian Feldmann, Christopher Meyer Abgabe bis Montag, 09 Mai 2011, 10:00h in ID 2/415, im Briefkasten vor ID 2/467 oder zum Übungstermin

Mehr

Rechnernetze Übung 12

Rechnernetze Übung 12 Rechnernetze Übung 12 Frank Weinhold Professur VSR Fakultät für Informatik TU Chemnitz Juli 2011 Sie kennen sicherlich sogenannte Web-Mailer, also WWW-Oberflächen über die Sie Emails lesen und vielleicht

Mehr

Systemsicherheit 10: S/MIME

Systemsicherheit 10: S/MIME Systemsicherheit 10: S/MIME Gliederung 1. E-Mail-Format RFC 822 2. Multipurpose Internet Mail Extensions (MIME) 3. S/MIME 4. XMaiL 5. POP3 6. IMAP 1. E-Mail-Format RFC 822 RFC (2)821: Simple Mail Transfer

Mehr

Denn es geht um ihr Geld:

Denn es geht um ihr Geld: Denn es geht um ihr Geld: [A]symmetrische Verschlüsselung, Hashing, Zertifikate, SSL/TLS Warum Verschlüsselung? Austausch sensibler Daten über das Netz: Adressen, Passwörter, Bankdaten, PINs,... Gefahr

Mehr

Systemsicherheit 10: S/MIME

Systemsicherheit 10: S/MIME Gliederung 1. E-Mail-Format RFC 822 Systemsicherheit 10: S/MIME 2. Multipurpose Internet Mail Extensions (MIME) 3. S/MIME 1. E-Mail-Format RFC 822 RFC 821: SMTP RFC (2)821: Simple Mail Transfer Protocol

Mehr

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6

Internetprotokolle: POP3. Peter Karsten Klasse: IT7a. Seite 1 von 6 Internetprotokolle: POP3 Peter Karsten Klasse: IT7a Seite 1 von 6 Alle Nachrichten, die auf elektronischem Weg über lokale oder auch globale Netze wie das Internet verschickt werden, bezeichnet man als

Mehr

Aspekte der Digitalen Signatur

Aspekte der Digitalen Signatur 1 Martin Alt Völklingen... Einrichtungen die den digitalen Weg eröffnet haben, müssen digital signierte Nachrichten empfangen können... Die Veröffentlichung von email Adressen gilt dabei als Eröffnung......

Mehr

Ich hab doch nichts zu verbergen... Der gläserne Bürger: Wieviel Daten braucht der Staat?

Ich hab doch nichts zu verbergen... Der gläserne Bürger: Wieviel Daten braucht der Staat? 1 / 32 Veranstaltungsreihe Ich hab doch nichts zu verbergen... Der gläserne Bürger: Wieviel Daten braucht der Staat? Veranstalter sind: 15. Mai bis 3. Juli 2008 der Arbeitskreis Vorratsdatenspeicherung

Mehr

PKI (public key infrastructure)

PKI (public key infrastructure) PKI (public key infrastructure) am Fritz-Haber-Institut 11. Mai 2015, Bilder: Mehr Sicherheit durch PKI-Technologie, Network Training and Consulting Verschlüsselung allgemein Bei einer Übertragung von

Mehr

E-Mails versenden auf sicherem Weg! Sichere E-Mail Kundenleitfaden

E-Mails versenden auf sicherem Weg! Sichere E-Mail Kundenleitfaden E-Mails versenden auf sicherem Weg! Sichere E-Mail Kundenleitfaden Vorwort In unserem elektronischen Zeitalter erfolgt der Austausch von Informationen mehr und mehr über elektronische Medien wie zum Beispiel

Mehr

Protokolle. Konrad Rosenbaum, 2006/7 protected under the GNU GPL & FDL

Protokolle. Konrad Rosenbaum, 2006/7 protected under the GNU GPL & FDL TCP/IP: Standard Protokolle Konrad Rosenbaum, 2006/7 DNS - Domain Name System hierarchische, global verteilte Datenbank löst Namen in IP-Adressen auf Host hat einen primären Nameserver, der Fragen selbst

Mehr

E-Mails versenden aber sicher! Secure E-Mail

E-Mails versenden aber sicher! Secure E-Mail E-Mails versenden aber sicher! Secure E-Mail Leitfaden S Kreisparkasse Verden 1 Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische

Mehr

Dokumentation Mail-Test

Dokumentation Mail-Test Dokumentation Mail-Test 1. Verschicken vordefinierter E-Mails... 1 Zweck des Testmailservice... 1 Fingerprint... 2 Explizit/Implizit Signed Mails... 2 Attachment... 3 "A mail with a signed attachment -

Mehr

Verschlüsselung, email-verschlüsselung

Verschlüsselung, email-verschlüsselung Verschlüsselung, email-verschlüsselung ADV Tagung IT-Sicherheit für Fortgeschrittene Wien, 17. September 2008 Herbert.Leitold@a-sit.at Zentrum für sichere Inofrmationstechnologie - Austria Motivation:

Mehr

Sichere E-Mail-Verteiler: Ein praxisorientierter Ansatz

Sichere E-Mail-Verteiler: Ein praxisorientierter Ansatz Sichere E-Mail-Verteiler: Ein praxisorientierter Ansatz Jens Hasselbach Fraunhofer AEMT Security for Virtual Goods Langewiesener Str. 22 98693 Ilmenau hasseljs@emt.iis.fhg.de Abstract: Der Nachrichtenverkehr

Mehr

S/MIME Version 3.1 Message Specification

S/MIME Version 3.1 Message Specification S/MIME Version 3.1 Message Specification - Ausarbeitung - Name: Thomas Richter Studienrichtung: Informatik Semester: 6 Matrikelnummer: 730 450 email: thomas.richter1@student.fh-nuernberg.de Studienfach:

Mehr

Email Protokolle. Thomas Starzacher Christian Prähauser. 29. Jänner 2003

Email Protokolle. Thomas Starzacher Christian Prähauser. 29. Jänner 2003 Thomas Starzacher Christian Prähauser 29. Jänner 2003 Übersicht 1. Email Grundlagen 2. SMTP Protokoll 3. POP3 Protokoll 4. IMAP Protokoll Email Grundlagen Email Grundlagen Email System besteht aus Mail

Mehr

E-Mail Protokolle. IT02a 18.05.2004 Marina Maugeri

E-Mail Protokolle. IT02a 18.05.2004 Marina Maugeri E-Mail Protokolle IT02a 18.05.2004 Marina Maugeri 1. Geschichte der E-Mail...Seite 2 2. Aufbau einer E-Mail...Seite 2 3. SMTP Simple Mail Transfer Protocol...Seite 2 3.1. Kommandos...Seite 3 3.2. Antwortcodes...Seite

Mehr

Anhang A - Weitere Bibliotheken. Die Bibliothek Mail_02.lib ermöglicht das Versenden von Emails mit dem Ethernet-Controller 750-842.

Anhang A - Weitere Bibliotheken. Die Bibliothek Mail_02.lib ermöglicht das Versenden von Emails mit dem Ethernet-Controller 750-842. Anhang A - Weitere Bibliotheken WAGO-I/O-PRO 32 Bibliothek Mail_02.lib Die Bibliothek Mail_02.lib ermöglicht das Versenden von Emails mit dem Ethernet-Controller 750-842. Inhalt Mail_02.lib 3 MAIL_SmtpClient...

Mehr

Grundlagen. Traditionelle Dienste

Grundlagen. Traditionelle Dienste Grundlagen Traditionelle Dienste 24.04.2007 E-Mail (Electronic Mail) 24.04.07 Techniken und Dienste des Internets 2 Electronic Mail (E-Mail) Anforderungen zuverlässiges Verschicken von Text und Daten entkoppelte,

Mehr

Mail Protokolle. ESMTP: Extented SMTP Server gibt Infos über seine Fähigkeiten aus, zb für Verschlüsselung verwendet

Mail Protokolle. ESMTP: Extented SMTP Server gibt Infos über seine Fähigkeiten aus, zb für Verschlüsselung verwendet LINUX II MAIL Mail Protokolle SMTP: Simple Mail Transport Protocol Transport von Emails, Port: 25 ESMTP: Extented SMTP Server gibt Infos über seine Fähigkeiten aus, zb für Verschlüsselung verwendet POP3:

Mehr

FTP (File Transfer Protocol) RFC 959 (1985), but goes back to 1971

FTP (File Transfer Protocol) RFC 959 (1985), but goes back to 1971 4 Dateitransfer FTP (File Transfer Protocol) RFC 959 (1985), but goes back to 1971 objectives (from RFC 959): 1. to promote sharing of files (computer programs and/or data), 2. to encourage indirect or

Mehr

Whitepaper. Schnittstellenbeschreibung (SMTP) *@gateway.any-sms.biz

Whitepaper. Schnittstellenbeschreibung (SMTP) *@gateway.any-sms.biz Whitepaper Schnittstellenbeschreibung (SMTP) *@gateway.any-sms.biz Stand 03.03.201 3.03.2014 1. Klassisch (Betreff)... Seite 2 2. From (Absender)... Seite 6 Seite 1 1. Mail2SMS Klassisch (Betreff) SMTP-Schnittstelle

Mehr

Emailverschlüsselung mit Thunderbird

Emailverschlüsselung mit Thunderbird Emailverschlüsselung mit Thunderbird mit einer kurzen Einführung zu PGP und S/MIME Helmut Schweinzer 3.11.12 6. Erlanger Linuxtag Übersicht Warum Signieren/Verschlüsseln Email-Transport Verschlüsselung

Mehr

Allgemeine Erläuterungen zu

Allgemeine Erläuterungen zu en zu persönliche Zertifikate Wurzelzertifikate Zertifikatssperrliste/Widerrufsliste (CRL) Public Key Infrastructure (PKI) Signierung und Verschlüsselung mit S/MIME 1. zum Thema Zertifikate Zertifikate

Mehr

Kundenleitfaden Secure E-Mail

Kundenleitfaden Secure E-Mail Vorwort Wir leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie das Versenden von E-Mails. Neben den großen Vorteilen, die uns elektronische

Mehr

Internet Security: Verfahren & Protokolle

Internet Security: Verfahren & Protokolle Internet Security: Verfahren & Protokolle 39 20 13 Vorlesung im Grundstudium NWI (auch MGS) im Sommersemester 2003 2 SWS, Freitag 10-12, H10 Peter Koch pk@techfak.uni-bielefeld.de 30.05.2003 Internet Security:

Mehr

E-Mails versenden aber sicher! Secure E-Mail. Kundenleitfaden. Sparkasse Landshut

E-Mails versenden aber sicher! Secure E-Mail. Kundenleitfaden. Sparkasse Landshut E-Mails versenden aber sicher! Secure E-Mail Kundenleitfaden S Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie

Mehr

Unified Mail Archiv Schulungsteil 1. Jan-Peter Petersen

Unified Mail Archiv Schulungsteil 1. Jan-Peter Petersen Unified Mail Archiv Schulungsteil 1 Jan-Peter Petersen 1 1 Referenzmodelle OSI-Referenzmodell TCP/IP-Referenzmodell 7 Anwendungsschicht SMTP, SSH, IMAP, POP3, HTTP 6 Darstellungsschicht ASCII 5 Sitzungsschicht

Mehr

Sichere Abwicklung von Geschäftsvorgängen im Internet

Sichere Abwicklung von Geschäftsvorgängen im Internet Sichere Abwicklung von Geschäftsvorgängen im Internet Diplomarbeit von Peter Hild Theoretische Grundlagen der Kryptologie Vorhandene Sicherheitskonzepte für das WWW Bewertung dieser Konzepte Simulation

Mehr

IT-Sicherheit Kapitel 3 Public Key Kryptographie

IT-Sicherheit Kapitel 3 Public Key Kryptographie IT-Sicherheit Kapitel 3 Public Key Kryptographie Dr. Christian Rathgeb Sommersemester 2013 1 Einführung In der symmetrischen Kryptographie verwenden Sender und Empfänger den selben Schlüssel die Teilnehmer

Mehr

Lernziele. Electronic!Mail!!E-Mail. Client!-!Server. Merkmale. ! Sie!können!je!mindestens!2!Aufgaben!des!Mailservers!und des!mailclients!aufzählen.

Lernziele. Electronic!Mail!!E-Mail. Client!-!Server. Merkmale. ! Sie!können!je!mindestens!2!Aufgaben!des!Mailservers!und des!mailclients!aufzählen. Lernziele!2002 2007!Modul!Informationssysteme! Sie!können!je!mindestens!2!Aufgaben!des!Mailservers!und des!mailclients!aufzählen. Electronic!Mail!!E-Mail! Sie!können!mindestens!3!wichtige!Schritte!einer

Mehr

Anleitung E-Mail Konfiguration sowie Übersicht Mailprogramm roundcube Inhaltsverzeichnis

Anleitung E-Mail Konfiguration sowie Übersicht Mailprogramm roundcube Inhaltsverzeichnis Anleitung E-Mail Konfiguration sowie Übersicht Mailprogramm roundcube Inhaltsverzeichnis Einführung... 2-3 Servereinstellungen für die Einrichtung auf dem E-Mail Client... 4 E-Mail Adresse / Postfach einrichten...

Mehr

Risiko Datensicherheit End-to-End-Verschlüsselung von Anwendungsdaten. Peter Kirchner Microsoft Deutschland GmbH

Risiko Datensicherheit End-to-End-Verschlüsselung von Anwendungsdaten. Peter Kirchner Microsoft Deutschland GmbH Risiko Datensicherheit End-to-End-Verschlüsselung von Anwendungsdaten Peter Kirchner Microsoft Deutschland GmbH RISIKO Datensicherheit NSBNKPDA kennt alle ihre Geheimnisse! Unterschleißheim Jüngste Studien

Mehr

Schritt 1: Auswahl Schritt 3 Extras > Konten Schritt 2: Konto erstellen Konto hinzufügen klicken

Schritt 1: Auswahl Schritt 3 Extras > Konten Schritt 2: Konto erstellen Konto hinzufügen klicken In diesem Tutorial zeigen wir Ihnen, wie Sie im Mozilla Thunderbird E-Mailclient ein POP3-Konto einrichten. Wir haben bei der Erstellung des Tutorials die Version 2.0.0.6 verwendet. Schritt 1: Auswahl

Mehr

1 Überblick. A-Z SiteReader Benachrichtigung.doc Seite 1 von 9

1 Überblick. A-Z SiteReader Benachrichtigung.doc Seite 1 von 9 1 Überblick In A-Z SiteReader ist das Feature Benachrichtigung enthalten. Dieses Feature ermöglicht einer Installation, beim Auftreten von Ereignissen eine automatische Benachrichtigung für verschiedene

Mehr

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL

TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL 1 TLS ALS BEISPIEL FÜR EIN SICHERHEITSPROTOKOLL Kleine Auswahl bekannter Sicherheitsprotokolle X.509 Zertifikate / PKIX Standardisierte, häufig verwendete Datenstruktur zur Bindung von kryptographischen

Mehr

FAQ IMAP (Internet Message Access Protocol)

FAQ IMAP (Internet Message Access Protocol) FAQ IMAP (Internet Message Access Protocol) Version 1.0 Ausgabe vom 04. Juli 2013 Inhaltsverzeichnis 1 Was ist IMAP?... 2 2 Wieso lohnt sich die Umstellung von POP3 zu IMAP?... 2 3 Wie richte ich IMAP

Mehr

Digitale Signatur. Digitale Signatur. Anwendungen der Kryptographie. Secret Sharing / Splitting. Ziele SSL / TLS

Digitale Signatur. Digitale Signatur. Anwendungen der Kryptographie. Secret Sharing / Splitting. Ziele SSL / TLS Digitale Signatur Digitale Signatur kombiniert Hash Funktion und Signatur M, SIGK(HASH(M)) wichtige Frage: Wie wird der Bithaufen M interpretiert Struktur von M muss klar definiert sein Wie weiss ich,

Mehr

E-Mails versenden aber sicher!

E-Mails versenden aber sicher! E-Mails versenden aber sicher! Sichere E-Mail mit Secure E-Mail - Kundenleitfaden - S Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische

Mehr

POP3 und SMTP live und schwarzweiß

POP3 und SMTP live und schwarzweiß POP3 und SMTP live und schwarzweiß Informatik S2 In diesem Arbeitsauftrag empfangen und senden Sie E-Mails so, wie es auch ein E-Mail- Programm machen würde. Das heißt, Sie benutzen die Protokolle auf

Mehr

OL2000: Auswirkung des Nachrichtenformats auf Internet Mail

OL2000: Auswirkung des Nachrichtenformats auf Internet Mail Artikel-ID: 241538 - Geändert am: Mittwoch, 10. März 2004 - Version: 1.0 OL2000: Auswirkung des Nachrichtenformats auf Internet Mail Dieser Artikel wurde zuvor veröffentlicht unter D41809 Dieser Artikel

Mehr

E-Mail für Anfänger. David Mika. david@ping.de. Donnerstag, den 12. April 2012. Verein zur Förderung der privaten Internet Nutzung e.v.

E-Mail für Anfänger. David Mika. david@ping.de. Donnerstag, den 12. April 2012. Verein zur Förderung der privaten Internet Nutzung e.v. E-Mail für Anfänger David Mika david@ping.de Verein zur Förderung der privaten Internet Nutzung e.v. Donnerstag, den 12. April 2012 E-Mail? Electronic Mail Brief- bzw. Postkartenähnliche Nachricht im Internet

Mehr

Instruktionen Mozilla Thunderbird Seite 1

Instruktionen Mozilla Thunderbird Seite 1 Instruktionen Mozilla Thunderbird Seite 1 Instruktionen Mozilla Thunderbird Dieses Handbuch wird für Benutzer geschrieben, die bereits ein E-Mail-Konto zusammenbauen lassen im Mozilla Thunderbird und wird

Mehr

Programmiertechnik II

Programmiertechnik II X.509: Eine Einführung X.509 ITU-T-Standard: Information Technology Open Systems Interconnection The Directory: Public Key and attribute certificate frameworks Teil des OSI Directory Service (X.500) parallel

Mehr

Einführung in X.509 + S/MIME

Einführung in X.509 + S/MIME Einführung in X.509 + S/MIME Peter Steiert 24.10.2010 Agenda Was ist X.509 X.509 Zertifikate Kurzbeschreibung OpenSSL Elemente einer X.509 PKI Wie komme ich an ein Zertifikat? Import in die Anwendung S/MIME

Mehr

Einführung in OpenSSL und X.509-Zertifikate. Martin Kaiser http://www.kaiser.cx/

Einführung in OpenSSL und X.509-Zertifikate. Martin Kaiser http://www.kaiser.cx/ Einführung in OpenSSL und X.509-Zertifikate Martin Kaiser http://www.kaiser.cx/ Über mich Elektrotechnik-Studium Uni Karlsruhe System-Ingenieur UNIX und IP-Netze (2001-2003) Embedded Software-Entwicklung

Mehr

Steganos Secure E-Mail Schritt für Schritt-Anleitung EINLEITUNG SCHRITT 1: INSTALLATION

Steganos Secure E-Mail Schritt für Schritt-Anleitung EINLEITUNG SCHRITT 1: INSTALLATION Steganos Secure E-Mail Schritt für Schritt-Anleitung EINLEITUNG Obwohl inzwischen immer mehr PC-Nutzer wissen, dass eine E-Mail so leicht mitzulesen ist wie eine Postkarte, wird die elektronische Post

Mehr

Vorwort. Sichere E-Mail bietet. Kundenleitfaden Sichere E-Mail

Vorwort. Sichere E-Mail bietet. Kundenleitfaden Sichere E-Mail Vorwort Wir alle leben in einem elektronischen Zeitalter. Der Austausch von Informationen erfolgt zunehmend über elektronische Medien wie das Versenden von E-Mails. Neben den großen Vorteilen, die uns

Mehr

SMTP-Verfahren POP-Verfahren IMAP-Verfahren

SMTP-Verfahren POP-Verfahren IMAP-Verfahren IT Zertifikat Mailserver 01 Server Mailserver Protokolle Teil des Client-Server-Modells bietet Dienste für lokale Programme/ Computer (Clients) an -> Back-End-Computer Ausbau zu Gruppe von Servern/ Diensten

Mehr

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com

Merkblatt: HSM. Version 1.01. Systemvoraussetzungen, Setup und Trouble Shooting. pdfsupport@pdf-tools.com Merkblatt: HSM Version 1.01 Systemvoraussetzungen, Setup und Trouble Shooting Kontakt: pdfsupport@pdf-tools.com Besitzer: PDF Tools AG Kasernenstrasse 1 8184 Bachenbülach Schweiz www.pdf-tools.com Copyright

Mehr

Dateien und EMails verschlüsseln mit GPG

Dateien und EMails verschlüsseln mit GPG Dateien und EMails verschlüsseln mit GPG Linuxwochen Linz 2013 Mario Koppensteiner June 16, 2013 Table of contents Theorie Software was man braucht Schlüssel erstellen Schlüsselserver Beispiele Fragen

Mehr

12. Kieler OpenSource und Linux Tage. Wie funktioniert eigentlich Mail? 20.09.2014, Frank Agerholm, Linux User Group Flensburg e.v.

12. Kieler OpenSource und Linux Tage. Wie funktioniert eigentlich Mail? 20.09.2014, Frank Agerholm, Linux User Group Flensburg e.v. 12. Kieler OpenSource und Linux Tage Wie funktioniert eigentlich? 20.09.2014, Frank Agerholm, Linux User Group Flensburg e.v. Frank Agerholm Vorstellung Linux System Engineer RZ-Administration Konzeptionierung

Mehr

Digital Signature and Public Key Infrastructure

Digital Signature and Public Key Infrastructure E-Governement-Seminar am Institut für Informatik an der Universität Freiburg (CH) Unter der Leitung von Prof. Dr. Andreas Meier Digital Signature and Public Key Infrastructure Von Düdingen, im Januar 2004

Mehr

USB-Tokens. Technik und Einsatzgebiete

USB-Tokens. Technik und Einsatzgebiete USB-Tokens Technik und Einsatzgebiete Vortrag im Rahmen der Lehrveranstaltung Chipkartensysteme und E-Payment im SS05 an der Fachhochschule Bonn-Rhein-Sieg Outline Passwortmanager PKI Smartcards USB-Tokens

Mehr

p^db=`oj===pìééçêíáåñçêã~íáçå=

p^db=`oj===pìééçêíáåñçêã~íáçå= p^db=`oj===pìééçêíáåñçêã~íáçå= Error: "Could not connect to the SQL Server Instance" or "Failed to open a connection to the database." When you attempt to launch ACT! by Sage or ACT by Sage Premium for

Mehr

SSL-Protokoll und Internet-Sicherheit

SSL-Protokoll und Internet-Sicherheit SSL-Protokoll und Internet-Sicherheit Christina Bräutigam Universität Dortmund 5. Dezember 2005 Übersicht 1 Einleitung 2 Allgemeines zu SSL 3 Einbindung in TCP/IP 4 SSL 3.0-Sicherheitsschicht über TCP

Mehr

Effizienz im Vor-Ort-Service

Effizienz im Vor-Ort-Service Installation: Anleitung SatWork Integrierte Auftragsabwicklung & -Disposition Februar 2012 Disposition & Auftragsabwicklung Effizienz im Vor-Ort-Service Disclaimer Vertraulichkeit Der Inhalt dieses Dokuments

Mehr

Signieren und Verschlüsseln mit Outlook 2013

Signieren und Verschlüsseln mit Outlook 2013 Anleitung: Von Tobias Neumayer (support@thi.de) MAIL-VERSCHLÜSSELUNG / SIGNIERUNG Einführung Die meisten Mailprogramme unterstützen den Umgang mit S/MIME-Zertifikaten zur Verschlüsselung bzw. Signierung

Mehr

Webmail. V1.4-14.09.2011 - Christof Rimle 2010 - www.rimle.ch

Webmail. V1.4-14.09.2011 - Christof Rimle 2010 - www.rimle.ch Christof Rimle IT Services, Säntisstrasse 16, CH-9240 Uzwil Webmail V1.4-14.09.2011 - Christof Rimle 2010 - www.rimle.ch Dieses Dokument ist urheberrechtlich geschützt. Es darf von Kunden der Firma Christof

Mehr

Man liest sich: POP3/IMAP

Man liest sich: POP3/IMAP Man liest sich: POP3/IMAP Gliederung 1. Einführung 1.1 Allgemeiner Nachrichtenfluss beim Versenden von E-Mails 1.2 Client und Server 1.2.1 Client 1.2.2 Server 2. POP3 2.1 Definition 2.2 Geschichte und

Mehr

Domain Name System (DNS)

Domain Name System (DNS) Domain Name System (DNS) Motivation: E-mail-Infrastruktur des Internet Absender Empfänger SMTP server DNS server Adressabfrage E-mail client Mail-exchangeabfrage Internet SMTP E-mail client POP DNS server

Mehr

CrypTool im Überblick

CrypTool im Überblick CrypTool im Überblick Martin Schütte 3. Juni 2012 Inhaltsverzeichnis I. Erste Schritte 2 1. Programm-Aufbau 2 2. Symmetrische Verschlüsselungen 2 3. Asymmetrische Verfahren 3 4. Hashfunktionen 3 5. Tools

Mehr

Merak: Email einrichten und verwalten (Merak)

Merak: Email einrichten und verwalten (Merak) Welche Vorteile hat der neue Mailserver? Der Merak Mailserver läuft schneller und wesentlich stabiler als der bisher verwendete Mailserver. Zudem wird nun ein integrierter Spamschutz mit angegeben, der

Mehr

!"# $ % Internet Protokolle: HTTP 1/38

!# $ % Internet Protokolle: HTTP 1/38 !"# $ % Internet Protokolle: HTTP 1/38 1 Themenübersicht Schichtenmodell Gopher /FTP Statistik URL Einleitung Anwendungsablauf Beispiel mit Telnet Request, Response Anfragemethoden header Negotiation Proxyserver

Mehr

Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure)

Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure) Unterrichtseinheit 5: Konfigurieren der Netzwerksicherheit mit Hilfe von PKI (Public Key Infrastructure) Verschlüsselung mit öffentlichen Schlüsseln ist eine bedeutende Technologie für E- Commerce, Intranets,

Mehr

Mail und Mailserver. Mail - Protokolle. Wichtige RFCs. Alexander Piskernik & Adi Kriegisch. 3. Mai 2007

Mail und Mailserver. Mail - Protokolle. Wichtige RFCs. Alexander Piskernik & Adi Kriegisch. 3. Mai 2007 1 Grundlagen Mail und Mailserver Alexander Piskernik & Adi Kriegisch 3. Mai 2007 2 SMTP & Email 3 Probleme & Lösungen 4 Mailserver 5 Mailserver konfigurieren Wichtige Software 6 Q & A Internet & Kommunikation

Mehr

Rechnernetze I SS 2012. Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 23.

Rechnernetze I SS 2012. Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404. Stand: 23. echnernetze I SS 2012 Universität Siegen rolanda.dwismuellera@duni-siegena.de Tel.: 0271/740-4050, Büro: H-B 8404 Stand: 23. März 2012 Betriebssysteme / verteilte Systeme echnernetze I (1/12) i echnernetze

Mehr

Sichere E-Mail-Kommunikation zur datenschutz nord GmbH Merkblatt

Sichere E-Mail-Kommunikation zur datenschutz nord GmbH Merkblatt April 2011 Sichere E-Mail-Kommunikation zur datenschutz nord GmbH Merkblatt 1. Einleitung E-Mails lassen sich mit geringen Kenntnissen auf dem Weg durch die elektronischen Netze leicht mitlesen oder verändern.

Mehr

MySQL Queries on "Nmap Results"

MySQL Queries on Nmap Results MySQL Queries on "Nmap Results" SQL Abfragen auf Nmap Ergebnisse Ivan Bütler 31. August 2009 Wer den Portscanner "NMAP" häufig benutzt weiss, dass die Auswertung von grossen Scans mit vielen C- oder sogar

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Geschäftspartner) Datum: 15.07.2013 Dokumentenart: Anwenderbeschreibung Version: 3.2 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...

Mehr

Seminar Internet-Technologie. Maildienste SMTP / POP3 / IMAP. Pierre Schwalm FB 16 Universität Kassel

Seminar Internet-Technologie. Maildienste SMTP / POP3 / IMAP. Pierre Schwalm FB 16 Universität Kassel Maildienste SMTP / POP3 / IMAP Pierre Schwalm FB 16 Universität Kassel 1 Ablauf Einleitung SMTP Geschichte Verfahren Modell Protokoll Codes POP3 Geschichte Verfahren Befehle Sitzung's Beispiel 2 Ablauf

Mehr

Abteilung Internationales CampusCenter

Abteilung Internationales CampusCenter Abteilung Internationales CampusCenter Instructions for the STiNE Online Enrollment Application for Exchange Students 1. Please go to www.uni-hamburg.de/online-bewerbung and click on Bewerberaccount anlegen

Mehr

emailen - jetzt aber richtig

emailen - jetzt aber richtig emailen - jetzt aber richtig Computerlabor im KuZeB computerlabor.kire.ch 14.12.2009 Kire www.kire.ch Layout-Template von Chih-Hao Tsai chtsai.org Creative Commons License (by-nc-sa) creativecommons.org/licenses/by-nc-sa/2.5/ch/deed.de

Mehr

FAQs zur Nutzung des E-Mail Zertifikats zur sicheren E-Mail-Kommunikation. Das E-Mail Zertifikat von S-TRUST

FAQs zur Nutzung des E-Mail Zertifikats zur sicheren E-Mail-Kommunikation. Das E-Mail Zertifikat von S-TRUST FAQs zur Nutzung des E-Mail Zertifikats zur sicheren E-Mail-Kommunikation. Das E-Mail Zertifikat von S-TRUST S - t r u s t Z e r t i f i z i e r u n g s d i e n s t l e i s t u n g e n d e s D e u t s

Mehr

AS2 (Applicability Statement 2):

AS2 (Applicability Statement 2): AS2 (Applicability Statement 2): Beschreibung und Parameter AS2: Beschreibung und Parameter Ausgabe vom: 10.10.2004 Seite:1 von 8 Einleitung In diesem Dokument werden zum Thema AS2 folgende Fragen erläutert:

Mehr

E-Mail-Verschlüsselung mit Geschäftspartnern

E-Mail-Verschlüsselung mit Geschäftspartnern E-Mail-Verschlüsselung mit (Anleitung für Geschäftspartner) Datum: 13.07.2011 Dokumentenart: Anwenderbeschreibung Version: 3.0 : Redaktionsteam PKI cio.siemens.com Inhaltsverzeichnis 1. Zweck des Dokumentes:...3

Mehr

Top Tipp. Ref. 08.05.23 DE. Verwenden externer Dateiinhalte in Disclaimern. (sowie: Verwenden von Images in RTF Disclaimern)

Top Tipp. Ref. 08.05.23 DE. Verwenden externer Dateiinhalte in Disclaimern. (sowie: Verwenden von Images in RTF Disclaimern) in Disclaimern (sowie: Verwenden von Images in RTF Disclaimern) Ref. 08.05.23 DE Exclaimer UK +44 (0) 845 050 2300 DE +49 2421 5919572 sales@exclaimer.de Das Problem Wir möchten in unseren Emails Werbung

Mehr

Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware

Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware Sichere Kommunikation mit Outlook 98 ohne Zusatzsoftware Das E-Mail-Programm Outlook 98 von Microsoft bietet Ihnen durch die Standard- Integration des E-Mail-Protokolls S/MIME (Secure/MIME) die Möglichkeit,

Mehr

Wie organisiert ihr Euer menschliches «Netzwerk» für folgende Aufgaben? an alle an ein bestimmtes an ein bestimmtes an alle an ein bestimmtes

Wie organisiert ihr Euer menschliches «Netzwerk» für folgende Aufgaben? an alle an ein bestimmtes an ein bestimmtes an alle an ein bestimmtes Computernetzwerke Praxis - Welche Geräte braucht man für ein Computernetzwerk und wie funktionieren sie? - Protokolle? - Wie baue/organisiere ich ein eigenes Netzwerk? - Hacking und rechtliche Aspekte.

Mehr

S/MIME - Secure Email

S/MIME - Secure Email S/MIME - Secure Email Dirk Hörig (dhoerig@gmx.net) Hauptseminar: Sicherheit in Kommunikationsnetzen Technische Universität München WS 2002 (Version 20. Januar 2003) Zusammenfassung Dieses Papier behandelt

Mehr

Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird.

Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird. Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch von Informationen verwendet wird. Auch die Unternehmensgruppe ALDI Nord steht mit einer Vielzahl

Mehr

Astaro Mail Archiving Getting Started Guide

Astaro Mail Archiving Getting Started Guide Connect With Confidence Astaro Mail Archiving Getting Started Guide Über diesen Getting Started Guide Der Astaro Mail Archiving Service stellt eine Archivierungsplattform dar, die komplett als Hosted Service

Mehr

Kundeninformation zu Secure Email. Secure Email Notwendigkeit?

Kundeninformation zu Secure Email. Secure Email Notwendigkeit? Kundeninformation zu Secure Email Digitale Raubzüge und Spionageangriffe gehören aktuell zu den Wachstumsbranchen der organisierten Kriminalität. Selbst modernste Sicherheitstechnologie bietet dagegen

Mehr

EgoSecure Mail Encryption Quick Setup Guide

EgoSecure Mail Encryption Quick Setup Guide EgoSecure Mail Encryption Quick Setup Guide Inhalt 1 Einleitung... 2 2 Vorbereitung... 3 2.1 Firewall... 3 3 Inbetriebnahme... 3 3.1 Einschalten und anschließen... 3 3.2 Erstes Login... 3 3.3 Admin-Passwort

Mehr

Rechenzentrum. E-Mail Services Hinweise für die Nutzung (Änderungen/ Ergänzungen vorbehalten) Inhalt. Stand: 23. Oktober 2014

Rechenzentrum. E-Mail Services Hinweise für die Nutzung (Änderungen/ Ergänzungen vorbehalten) Inhalt. Stand: 23. Oktober 2014 Rechenzentrum E-Mail Services Hinweise für die Nutzung (Änderungen/ Ergänzungen vorbehalten) Stand: 23. Oktober 2014 Inhalt 1. E-Mail... 2 1.1 E-Mailgruppe beantragen... 3 1.2 Einstellungen im E-Mail-Client...

Mehr

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. "For your eyes only" Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo.

Karlsruher IT-Sicherheitsinitiative - 26. April 2001. For your eyes only Sichere E-Mail in Unternehmen. Dr. Dörte Neundorf neundorf@secorvo. Karlsruher IT-Sicherheitsinitiative - 26. April 2001 "For your eyes only" Sichere E-Mail in Unternehmen Dr. Dörte Neundorf neundorf@secorvo.de Secorvo Security Consulting GmbH Albert-Nestler-Straße 9 D-76131

Mehr

Informationen zur sicheren E-Mail-Kommunikation. Unternehmensgruppe ALDI SÜD

Informationen zur sicheren E-Mail-Kommunikation. Unternehmensgruppe ALDI SÜD Informationen zur sicheren E-Mail-Kommunikation Unternehmensgruppe ALDI SÜD Sichere E-Mail-Kommunikation Vorwort E-Mail ist heute für Unternehmen ein häufig eingesetztes Kommunikationsmittel, das zum Austausch

Mehr

Spam/Viren. Ein Statusbericht. Roland Dietlicher ID/Basisdienste 12. Mai 2004

Spam/Viren. Ein Statusbericht. Roland Dietlicher ID/Basisdienste 12. Mai 2004 Spam/Viren Ein Statusbericht Roland Dietlicher ID/Basisdienste 12. Mai 2004 Guten Tag Herr Dietlicher, Ich nehme nicht an, dass Sie es waren der mir rund 20 Spams gesendet hat - aber evtl müsste ihr Computer

Mehr

Secure E-Mail Sicherheit in der E-Mail Kommunikation

Secure E-Mail Sicherheit in der E-Mail Kommunikation Secure E-Mail Sicherheit in der E-Mail Kommunikation Kundenleitfaden Vorwort Digitale Raubzüge und Spionageangriffe gehören aktuell zu den Wachstumsbranchen der organisierten Kriminalität. Das Ausspähen

Mehr

19. September 2006. Protokolle

19. September 2006. Protokolle Protokolle D. Jonietz, Prof. Dr. P. Müller Technische Universität Kaiserslautern, AG Integrated Communication Systems Staatl. Studienseminar für das Lehramt an Gymnasien Kaiserslautern Burggymnasium Kaiserslautern

Mehr

Postausgang SMTP-Protokoll securesmtp.t-online.de (TLS) 587 evtl. SSL = 465

Postausgang SMTP-Protokoll securesmtp.t-online.de (TLS) 587 evtl. SSL = 465 SSL-Konfiguration 1&1 SSL-Konfiguration. Aktivieren Sie "SSL" und tragen Sie, falls erforderlich, den entsprechenden Port ein. Wählen Sie entsprechend den Port für IMAP oder POP3 aus. In den meisten Programmen

Mehr

Import des persönlichen Zertifikats in Outlook2007

Import des persönlichen Zertifikats in Outlook2007 Import des persönlichen Zertifikats in Outlook2007 1. Installation des persönlichen Zertifikats 1.1 Voraussetzungen Damit Sie das persönliche Zertifikat auf Ihren PC installieren können, benötigen Sie:

Mehr

Technische Dokumentation SEPPmail Outlook Add-In v1.5.3

Technische Dokumentation SEPPmail Outlook Add-In v1.5.3 Technische Dokumentation SEPPmail Outlook Add-In v1.5.3 In diesem Dokument wird dargelegt, wie das SEPPmail Outlook Add-in funktioniert, und welche Einstellungen vorgenommen werden können. Seite 2 Inhalt

Mehr

ESecuremail Die einfache Email verschlüsselung

ESecuremail Die einfache Email verschlüsselung Wie Sie derzeit den Medien entnehmen können, erfassen und speichern die Geheimdienste aller Länder Emails ab, egal ob Sie verdächtig sind oder nicht. Die Inhalte von EMails werden dabei an Knotenpunkten

Mehr