prednasky - 11

první zavedl Hong Kong (1999)

od roku 2003 postupně zaváděno v Evropě

ČR - CZ.NIC provedl (opakovaně) průzkum mezi uživateli

- o zavedení IDN není zájem

Bezpečné DNS - DNSSEC

DNS odpovědi lze podvrhnout

různé formy útoků

DNSSEC umožňuje

ověřit platnost odpovědi (elektronický podpis)

ověřit neexistenci daného záznamu

definují RFC 4033, 4034, 4035

každý záznam (resp. sada záznamů stejného typu pro stejné jméno)
je podepsán, záznam RRSIG

veřejné klíče k ověření uloženy přímo v DNS, záznam DNSKEY

v nadřazené doméně je otisk klíče poddomény (záznam DS), klíč
kořenové domény má každý klient - lze vytvořit řetězec důvěry

záznam NSEC obsahuje dalsí jméno v doméně - lze ověřit neexistenci

Problémy DNSSEC

podpisem velikost domény několikanásobně naroste (podepsaný .com má
10 GB)

chybějí klienti s podporou DNSSEC

NSEC záznamy umožňují vypsat kompletní obsah domény

domény vysoko v hierarchii stále nejsou podepsány, bez nich ztrácí
smysl

již řadu let se nedaří masově nasadit

11) Aplikační protokoly

Elektronická posta

Schéma elektronické posty

Programy

User Agent (UA)

uživatelské rozhraní postovního systému

rozhodující pro uživatelský komfort

MS Outlook, Mozilla Thunderbird,...

Mail Transfer Agent (MTA)

zajisťuje přepravu dopisů

neviditelný z hlediska uživatele

sendmail, Postfix, MS Exchange,...

SMTP (Simple Mail Transfer Protocol), RFC 821

formát dopisu definuje RFC 822:

obálka: přepravní informace, interní pro MTA, uživatel se o ní
nedozví

hlavičky: kdo poslal, kudy proslo,...; využívá UA, vychází z nich
řada jeho funkcí (řazení dopisů, vyplňování adres při
odpovědi,...

tělo: vlastní nesená zpráva, pro uživatele

Příklad dopisu

From travis@xyz.cz Mon May 19 08:53:40 2006

Received: from bubo.tul.cz (147.230.16.1) by tyto.tul.cz (Mercury 1.44)

with ESMTP; 19 May 03 08:53:09 +0200

Received: from relay.xyz.cz (relay.xyz.cz [123.24.128.45]) by

bubo.tul.cz (Postfix) with ESMTP; Mon, 19 May 2006 08:53:09 +0200

Received: from xyz.cz (office.xyz.cz [123.24.132.67]) by relay.xyz.cz

(Postfix) with ESMTP; Mon, 19 May 2006 08:53:11 +0200

Date: Mon, 19 May 2006 08:53:09 +0200

From: "Vitezslav T. Se'm"

To: Petr Adamec

Cc: Pavel.Satrapa@tul.cz

Subject: Spam pres buba?

← prázdný řádek odděluje hlavičky od těla

Zde je text těla dopisu.

Příklad SMTP komunikace

relay.xyz.cz (B) předává dopis na bubo.tul.cz (A)

B naváže TCP spojení s A na port 25, po něm proběhne tento dialog:

A: 220 bubo.vslib.cz SMTP service ready

B: HELLO relay.xyz.cz

A: 250 bubo.vslib.cz says hello to relay.xyz.cz

B: MAIL FROM:

A: 250 sender ok

B: RCPT TO:

A: 250 recipient OK

B: DATA

A: 354 Enter mail, end with "." on a line by itself

B: celý dopis - hlavičky a tělo

B: .

A: 250 message sent

B: QUIT

A: 221 relay.xyz.cz closing connection

E-mail a DNS

používá DNS ke zjistění, kam posílat postu

MX záznamy (Mail eXchange)

MX priorita jméno

příklad: dopis pro pavel.satrapa@tul.cz

vyhledá v DNS MX záznamy pro tul.cz:

0 bubo.tul.cz

50 tul.cesnet.cz

pokusí se předat (po SMTP) na bubo.tul.cz

neuspěje-li, zkusí server s horsí prioritou

Vzdálený přístup ke schránce

schránka musí být stále dostupná, je umístěna na počítači s
cílovým MTA

UA často na jiném počítači (přístup z domova)

Post Office Protocol (POP)

umí stáhnout dopisy na počítač a vymazat ze schránky

jednoduchý, siroce implementovaný

Interactive Mail Access Protocol (IMAP)

vzdálená práce se schránkami, větsí možnosti, složitějsí

ideální kombinovat se SSL

MIME (Multipurpose Internet Mail Extensions), RFC 2045 a dalsí

dle RFC 822 smí tělo dopisu tvořit jen US ASCII

problém s národními znaky, přílohami,...

MIME zakóduje složitý dopis do podoby podle

RFC 822 - lze přepravovat stávajícími MTA

implementuje klient (UA) - kóduje/dekóduje

MIME hlavičky

MIME-Version

je použito MIME

identifikuje verzi, zatím stále 1.0

Content-Type

jakého typu je obsah dopisu

Content-Transfer-Encoding

jak je kódován

Quoted-Printable pro text s akcenty,

Base64 pro binární data

MIME typy

typ/podtyp

typ určuje základní charakter dat

podtyp identifikuje formát

text - textová informace; text/plain, text/html

image - obrázek; image/jpeg, image/gif

audio - zvuk; audio/basic, audio/mpeg

video - videosekvence; video/mpeg

application - data ke zpracování speciální aplikací;

application/octet-stream, application/postcript

message - obsahem je jiný dopis

multipart - obsah má několik částí

multipart/mixed - prezentovat postupně (nejčastějsí)

multipart/parallel - prezentovat současně

multipart/alternative - různé varianty téhož obsahu

multipart/digest - každou částí je elektronický dopis,

např. souhrn elektronické konference

World-Wide Web

Základní prvky

uspořádání klient-server

HyperText Transfer Protocol (HTTP)

protokol pro komunikaci mezi klientem a serverem

HyperText Markup Language (HTML)

jazyk pro definici obsahu stránky

XHTML - HTML přeformulováno do XML

vývoj koordinuje WWW konsorcium

Komunikace klient-server

HTTP - bezstavový protokol

zodpovězením dotazu transakce pro server končí,

neudržuje stavové informace o klientech

dalsí dotaz nedává do souvislosti s předchozími

stav si uchovává klient

výhody: robustní, snadnějsí implementace

nevýhody: větsí režie, některé služby vyžadují stavové informace
(nákupní kosík)

- klient musí předat serveru

HTTP zprávy

formátem připomínají elektronický dopis

dotaz:

metoda lokátor verze

Ještě nehodnoceno. Buďte první :-)

(c)2011 Edgehunt Corporation
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .