Vlákno názorů k článku Velká část e-mailů putuje internetem nešifrovaně. Kdo to změní? od Petr M - Ne, správný stav by měl vypadat jinak. 1) komunikační...

  • Článek je starý, nové názory již nelze přidávat.
  • 19. 2. 2018 9:19

    Petr M (neregistrovaný)

    Ne, správný stav by měl vypadat jinak.

    1) komunikační systém musí mít dva levely. D2D (domain to domain) a D2U (domain to user) a komunikace dvou uživatelů po řetězci D2U-D2D-D2U.
    2) Uživatel má sadu klíčů, navázanou na doménu (UK). S její pomocí se autorizuje na doménový mail server a pokud není klíč validní, má uživatel smůlu.
    3) Odesílatel vytvoří zprávu, podepsanou UK, a doručí na server svojí domény na úrovni D2U. Šifrovaně. Ta ověří podpis proti vlastnímu seznamu a co nevyhovuje, to zahodí a informuje uživatele o chybě.
    4) Mail se doručí příjemci do schránky (stejná doména), nebo se předá mail serveru v jiné doméně (komunikace D2D). Šifrovaně, použije se certifikát z DNS. D2D komunikace funguje jako další, šifrovaná obálka pro zprávy.
    5) Mail server příjemce zahodí poškozený maily, zprávy s neplatným podpisem a další binec. Informuje odesílatele o chybě. Na téhle úrovni neřeší existenci příjemce.
    6) Validní zpráva se vybalí a ověří se existence příjemce. Neexistující příjemce -> notifikace odesílateli, zahození zprávy. Validní jde do inboxu.
    7) Klient se přihlásí pomocí UK2 k doménovýmu severu, v inboxu má zprávu. Klient ověří validitu UK1 dotazem na doménu odesílatele (ochrana proti pozměnění a podvržení) a podpis. Pokud je OK, vidí ho v inboxu, jinak do spamu.
    8) Klient si pořeší antispam podle vlastních pravidel (tady je volnost implementace podle klienta a použité metody, DB,...) Systém doručení nemá co mluvit do validních zpráv (ale smí omezit jejich množství v čase). Pak má klient zprávu k dispozici.
    9) Přílohy jsou uloženy na serveru (vždy dostupné) odesílatele (aby zodpovídal za velikost toho, co se doručuje a nedělaly se zbytečně kopie). Každá příloha má čítač referencí, inicializovaný na počet příjemců mailu a zahozením mailu nebo stažením zprávy se čítač dekrementuje. Když je na nule, soubor přílohy je smazán. Kopie přílohy se uloží na server u příjemce v okamžiku, kdy spadne do inboxu (aby měl příjemce přílohu k dispozici na několika zařízeních). Kopie na serveru příjemce je odstraněna při smazání zprávy.
    10) Pokud si obě strany komunikace vymění certifikáty (SK), zpráva i soubory příloh jsou šifrovány pomocí těchto certifikátů, komunikační kanál vidí jenom hlavičky s adresama.
    11) Pokud odesílatel ztratí SK příjemce, pošle se zpráva bez E2E šifrování. Příjemce je na to upozorněn. Protože v takoví situaci nemá příjemce k dispozici dešifrovací klíč, posílají se maily bez E2E šifrování na danou adresu do chvíle, než dostane šifrovaný mail od původního odesílatele (našel SK, nebo dostal nový) s informací pro oba, že je komunikace nešifrovaná.

  • 19. 2. 2018 9:26

    j (neregistrovaný)

    Mno ... a pak uzivatel prijde o svuj klic, a maily muze smazat ;D.

    Jinak vymena klicu v hlavickach mailu + jejich pouziti pro odchozi postu danymu kontaktu nechapu proc davno zcela bezne nefunguje, Asi neni cas to implementovat, je treba zahazovat XUL a menit loga ...

  • 19. 2. 2018 16:28

    Petr M (neregistrovaný)

    Pokud přijdu o svůj klíč, tak si nechám od správce domény vytvořit nový, nahraje ho do serveru a jede se dál.

  • 19. 2. 2018 16:30

    Miroslav Šilhavý

    Pokud přijdu o svůj klíč, tak si nechám od správce domény vytvořit nový, nahraje ho do serveru a jede se dál.

    Cože? Pokud jsou data šifrována a přijdete o svůj klíč, můžete se jít klouzat, už je nerozšifrujete.

  • 20. 2. 2018 7:06

    Petr M (neregistrovaný)

    Klíč pro přenos, na serveru je to uloženo nešifrovaně...