abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 16:11 | Komunita

Byly zveřejněny videozáznamy přednášek a workshopů z letošní konference OpenAlt konané 4. a 5. listopadu v Brně. K videozáznamům lze přistupovat ze stránky na SuperLectures nebo přes program konference, detaily o vybrané přednášce nebo workshopu a dále kliknutím na ikonku filmového pásu.

Ladislav Hagara | Komentářů: 0
včera 14:11 | Komunita

Některým uživatelům Firefoxu se tento týden do Firefoxu nainstalovalo neznámé rozšíření Looking Glass 1.0.3 (png). Ve fórů Mozilly se řešilo, zda se nejedná o malware. Mozilla později informovala, že se jednalo o reklamu na seriál Mr. Robot. Řadě uživatelů Firefoxu se jednání Mozilly vůbec nelíbilo. Mozilla proto automatickou instalaci doplňku ukončila [Hacker News, reddit].

Ladislav Hagara | Komentářů: 15
16.12. 12:00 | Nová verze

Po cca 3 týdnech od vydání Linux Mintu 18.3 s kódovým jménem Sylvia a prostředími MATE a Cinnamon byla oznámena také vydání s prostředími KDE a Xfce. Podrobnosti v poznámkách k vydání (KDE, Xfce) a v přehledech novinek s náhledy (KDE, Xfce). Linux Mint 18.3 je podporován do roku 2021.

Ladislav Hagara | Komentářů: 6
15.12. 12:55 | Nová verze

Byla vydána verze 17.12.0 KDE Aplikací (KDE Applications). Přehled novinek v kompletním seznamu změn a na stránce s dalšími informacemi. Aplikace, které nebyly dosud portovány na KDE Frameworks 5, byly z KDE Aplikací odstraněny.

Ladislav Hagara | Komentářů: 54
15.12. 03:00 | Komunita

Na Humble Bundle lze získat počítačovou hru Company of Heroes 2 (Wikipedie, YouTube) běžící také v Linuxu zdarma. Speciální akce končí v sobotu v 19:00.

Ladislav Hagara | Komentářů: 0
15.12. 02:00 | Zajímavý software

Christian Kellner představil na svém blogu projekt Bolt řešící bezpečnost rozhraní Thunderbolt 3 na Linuxu. Pomocí příkazu boltctl nebo rozšíření GNOME Shellu lze komunikovat s démonem boltd a například zakázat neznámá zařízení a předejít tak útokům typu Thunderstrike nebo DMA.

Ladislav Hagara | Komentářů: 10
15.12. 01:00 | Nová verze

Po půl roce vývoje od vydání verze 11.0 byla vydána verze 11.1 svobodného softwaru pro vytváření datových úložišť na síti FreeNAS (Wikipedie). Nejnovější FreeNAS je postaven na FreeBSD 11.1. Přehled novinek v příspěvku na blogu. Zdůraznit lze zvýšení výkonu OpenZFS, počáteční podporu Dockeru nebo synchronizaci s cloudovými službami Amazon S3 (Simple Storage Services), Backblaze B2 Cloud, Google Cloud a Microsoft Azure

Ladislav Hagara | Komentářů: 0
14.12. 23:55 | Nová verze

Po dvou měsících vývoje od vydání verze 235 oznámil Lennart Poettering vydání verze 236 správce systému a služeb systemd (GitHub, NEWS).

Ladislav Hagara | Komentářů: 10
14.12. 20:00 | Nová verze Ladislav Hagara | Komentářů: 0
14.12. 19:33 | Pozvánky

Pražská Fedora 27 Release Party, oslava nedávného vydání Fedory 27, se uskuteční 19. prosince od 19:00 v prostorách společnosti Etnetera (Jankovcova 1037/49). Na programu budou přednášky o novinkách, diskuse, neřízený networking atd.

Ladislav Hagara | Komentářů: 0
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (0%)
 (1%)
 (1%)
 (76%)
 (14%)
Celkem 1011 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    Konfigurace programů Postfix a Dovecot

    25. 1. 2010 | Lukáš Jelínek | Sítě | 13810×

    Konfigurace programu Postfix

    link

    Poslední nezbytnou podmínkou pro fungování TLS je samozřejmě správné nakonfigurování jednotlivých programů. Vždy je potřeba TLS zapnout (ať už jako explicitní, nebo implicitní), nastavit cesty k souborům a v neposlední řadě také definovat chování technologie.

    Definicí chování se rozumí například míra povinnosti používat TLS, zapnutí/vypnutí ověřování klientů, volba šifrovacích algoritmů apod. Toto všechno se bude řídit účelem, za kterým se technologie nastavuje. Například lze povolit pouze silné šifry, čímž se však zabrání některým starším programům komunikovat. Ověřování klientů může mít zase smysl jako náhrada (nebo doplněk) autentizace při odesílání pošty z počítačů kdekoliv na světě.

    Konfiguraci TLS je třeba rozdělit na dvě části – jednu pro Postfix v roli serveru (tedy pro komunikaci s klienty, příjem zpráv), druhou v roli klienta (tedy pro předávání zpráv jinam). Konfigurace může vypadat tak, že v jedné roli se TLS používat bude, kdežto v druhé nikoliv. V některých situacích to může mít smysl.

    Následující kus souboru main.cf ukazuje obě části pohromadě. Nastavuje explicitní režim TLS s nepovinným používáním:

    smtp_tls_security_level = may
    smtp_tls_session_cache_database = btree:/var/lib/postfix/smtp_tls_session_cache
    smtp_tls_loglevel = 1
    
    smtpd_tls_security_level = may
    smtpd_tls_cert_file = /etc/ssl/certs/moje.domena.crt
    smtpd_tls_key_file = /etc/ssl/private/moje.domena.key
    smtpd_tls_received_header = yes
    smtpd_tls_session_cache_database = btree:/var/lib/postfix/smtpd_tls_session_cache
    smtpd_tls_loglevel = 1
    

    Parametr smtp_tls_security_level říká, jak se bude přistupovat k používání TLS. Výchozí hodnota je none (vypnuto), may znamená dobrovolné používání TLS. Lze použít také povinné (encrypt), kdy je vyloučena nešifrovaná komunikace, případně ještě vyšší verze povinného šifrování, například verify (kontrola platnosti certifikátu, jeho důvěryhodnosti a názvu). Toto se zde týká klientské části, tedy předávání zpráv na jiný server. Podobný smysl má u serverové části parametr smtpd_tls_security_level.

    smtp_tls_session_cache_database, resp. smtpd_tls_session_cache_database, je umístění a způsob uložení cache TLS relací. O ně se stará služba tlsmgr, která je ukládá nastaveným způsobem. Vhodné je uložení do stromu, vzhledem k poměrně velkému objemu dat. Využití cache není povinné, zvyšuje však výkon. Standardní životnost objektů je 1 hodina (lze změnit pomocí smtp_tls_session_cache_timeoutsmtpd_tls_session_cache_timeout).

    smtp_tls_loglevelsmtpd_tls_loglevel určují úroveň záznamu souvisejícího s TLS. Běžně je vhodná úroveň 1, při které se zaznamenávají informace o sestavování relací a o certifikátech. Vyšší úrovně se hodí při ladění, úplné vypnutí (úroveň 0, je výchozí) je obvykle zbytečné.

    V serverové části ještě zbývají dva okruhy parametrů. Jednak jsou to cesty k certifikátu a klíči (smtpd_tls_cert_filesmtpd_tls_key_file), které se nastaví samozřejmě podle umístění těchto souborů. Poslední je smtpd_tls_received_header, který při aktivaci způsobí, že se do každé zprávy vloží hlavička s informací o použití TLS, včetně údajů o verzi a použitých algoritmech.

    Vyšší úroveň bezpečnosti

    link

    Uvedená konfigurace zajišťuje použití šifrování vždy, když je to možné. Pro příjem zpráv záleží na nastavení klienta, pro předávání jinam zase na možnostech cílového serveru. Toto nastavení nekontroluje totožnost protistran (proto nezaručuje, že se zprávy předávají správnému serveru nebo že se přebírají od správného klienta) ani nevynucuje použití šifrování.

    Tyto nedostatky lze odstranit zvýšením úrovně bezpečnosti. Je však třeba si uvědomit, že toto zvýšení je na úkor kompatibility, protože odřízne část komunikujících protistran. Úplně nejjednodušší věc je nastavení přístupu ke kořenovým certifikátům certifikačních autorit. Tyto certifikáty je však potřeba mít nejdřív nainstalované; mohou být v samostatném balíčku, nezávisle na technologii TLS i na programech, které TLS používají.

    smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt
    

    Toto se použije, pokud jsou certifikáty v jednom společném souboru. Pokud by se používaly samostatné soubory, definoval by se adresář pomocí smtp_tls_CApath (toto řešení má různá úskalí, například nutnost umístit certifikáty dovnitř prostředí chroot, pokud se toto prostředí používá). Nadefinuje-li se takto přístup ke kořenovým certifikátům, lze kontrolovat certifikáty serverů, na něž se konfigurovaný server připojuje. Samotná kontrola ovšem zatím nic neznamená, protože se její výsledky nevyužívají – pouze se zapisují do logu.

    Skutečný smysl kontrola získává až s volbou přísnějšího režimu. Nestačí jen vynutit šifrování pomocí encrypt, nýbrž je potřeba zapnout i ověřování totožnosti:

    smtp_tls_security_level = verify
    

    Tím se dosáhne toho, že se při předávání zpráv bude ověřovat platnost certifikátu (časová, nepřítomnost na revokačním seznamu), jeho důvěryhodnost (musí být podepsán certifikační autoritou, jejíž kořenový certifikát je ve výše popsaném úložišti) a také shodu názvu serveru v certifikátu se skutečným názvem. Shoda se ve výchozím stavu testuje podle doménového názvu serveru, chování lze ale změnit pomocí smtp_tls_verify_cert_match (například nastavením na konkrétní názvy).

    Úroveň verify není stále ještě dostatečně bezpečná. Právě proto, že se může název serveru zjišťovat z DNS nešifrovaným kanálem, hrozí podvržení odpovědi. Proto existuje ještě úroveň secure, která využívá pouze informací dostupných přímo z konfigurace pro servery, kam se pošta předává (tzv. next hop).

    Pro funkci běžného internetového poštovního serveru nejsou vyšší úrovně než may vhodné (dokonce to RFC 2487 zakazuje), protože odříznou mnoho serverů nepodporujících šifrování nebo nepoužívajících důvěryhodné certifikáty.

    Další možností zvýšení bezpečnosti – tentokrát v trochu jiném stylu – je zákaz autentizace bez použití TLS. O co jde? Pokud si vzpomenete na díl věnovaný autentizaci klientů, tak jedním ze zásadních problémů je uložení a přenos hesla. Pokud je heslo uloženo zašifrované, výrazně to omezuje použitelnost různých autentizačních metod – a naopak, pro plnou škálu je potřeba mít heslo uloženo nezašifrované. Pokud se používá TLS, lze posílat heslo klidně v otevřeném tvaru (plain), protože jde po šifrovaném kanálu. Čili může být uloženo nezašifrované bez negativních dopadů na bezpečnost ověřování.

    smtpd_tls_auth_only = yes
    

    Takto se zajistí, že ověřování uživatele bude fungovat jen v případě, že se komunikuje přes TLS. Při nešifrované komunikaci nelze uživatele ověřit, navíc server takovou možnost ani nebude nabízet.

    Klientské certifikáty

    link

    Klientské certifikáty nejsou běžnou záležitostí, nicméně v některých případech je lze s výhodou použít. Jde v zásadě o to, že kromě obvyklého prokázání totožnosti ze strany serveru se totéž provádí i ze strany klienta. Může to být výhodné například v případě, že se pro odesílání zpráv využívá SMTP server nedisponující databází uživatelů a současně je potřeba odesílat zprávy z různých internetových adres. Pak je klientský certifikát zajímavou možností, jak snadno zajistit ověřování a současně neotevřít server spammerům.

    smtpd_tls_ask_ccert = yes
    smtpd_tls_req_ccert = yes
    
    relay_clientcerts = hash:/etc/postfix/relay_clientcerts
    
    smtpd_client_restrictions =
        permit_mynetworks,
        permit_tls_clientcerts,
        reject
    

    Tato konfigurace způsobí, že bude server vyžadovat klientské certifikáty (smtpd_tls_ask_ccert je samotné zapnutí požadavku, smtpd_tls_req_ccert vynucení použití certifikátu) a povolí pouze připojení klientů z definované vlastní sítě (obvykle jen místního stroje) anebo klientů s certifikátem uvedeným v seznamu oprávněných certifikátů. Ten je definován přes parametr relay_clientcerts, v tomto případě se jedná o hešovou mapu obsahující dvojice fingerprintů certifikátů a jejich názvů (název se zde nekontroluje, má pouze procesní význam a může také sloužit pro informativní účely).

    Jistě každého napadne, že lze klientské certifikáty kombinovat s ověřováním uživatelů, a to jak ve smyslu splnění obou podmínek (tj. certifikát + jméno a heslo), tak i kterékoli z nich. Použití výše uvedené definice smtpd_client_restrictions společně s smtpd_recipient_restrictions obsahujícím ověření uživatele je první varianta; pokud se permit_tls_clientcerts přesune do smtpd_recipient_restrictions před nebo za permit_sasl_authenticated, jde o variantu druhou.

    Má-li naopak server klientský certifikát někam posílat (což je ještě méně běžný případ než ten předchozí), je potřeba nadefinovat patřičné parametry smtp_tls_cert_filesmtp_tls_key_file, kde budou uvedeny cesty k souborům s certifikátem a klíčem.

    Implicitní TLS

    link

    Přestože běžně není důvod konfigurovat na poštovním serveru SMTP komunikaci pomocí implicitního TLS (na samostatném portu), protože i velmi staré programy (např. Outlook Express) zvládají TLS explicitní, někdy takový důvod nastat může – typicky u nějakých jednoduchých jednoúčelových „odesílátek“, kde se TLS řeší přes stunnel.

    Řešení implicitního TLS spočívá v úpravě souboru master.cf, protože je potřeba přidat novou službu:

    smtps      inet  n       –       n       –       –       smtpd
      -o smtpd_tls_wrappermode=yes
    

    Tím se spustí nová instance služby smtpd na portu 465, která poběží ve „wrapperovém“ režimu a bude umožňovat implicitní TLS. V případě potřeby změnit číslo portu se smtps nahradí potřebným číslem (třeba 10465).

    Konfigurace programu Dovecot

    link

    V případě programu Dovecot je konfigurace výrazně jednodušší než u Postfixu. Je jen jedna strana komunikace a také zde není tolik konfiguračních možností. Základní podoba může být například takováto:

    ssl = yes
    ssl_cert_file = /etc/ssl/certs/moje.domena.crt
    ssl_key_file = /etc/ssl/private/moje.domena.key
    

    První řádek je dokonce jen pro úplnost, protože je to výchozí volba (naopak ssl = no šifrování explicitně vypne). Další parametry pouze nastavují cestu k certifikátu a klíči. Nic dalšího už není potřeba. Na rozdíl od Postfixu zde lze použít zašifrovaný klíč a heslo poskytnout přes konfigurační parametr:

    ssl_key_password = !include_try /etc/dovecot/moje.domena.kpass
    

    Napsat heslo přímo do konfigurace není bezpečné, protože konfigurační soubor bývá přístupný všem uživatelům. Lepší je dát ho do samostatného souboru, ke kterému má přístup jen root – do parametru ho vloží direktiva !include_try. Další možnost je spouštět Dovecot s parametrem -p a vložit heslo v příkazové řádce. To je ale dost nepohodlné a hodí se to spíš pro testování než pro běžný provoz.

    Implicitní TLS se u Dovecotu nastavuje velmi jednoduše – prostě se rozšíří seznam protokolů:

    protocols = imap imaps pop3 pop3s
    

    Toto zapne implicitní TLS pro oba komunikační protokoly. Běží na svých standardních portech (993, resp. 995), to lze případně změnit v sekci protokolu takto:

    protocol imap {
        ssl_listen = *:10993
    }
    

    V případě potřeby používat klientské certifikáty se tato funkcionalita zapne a nastaví se také soubor s certifikáty certifikačních autorit (který bude obsahovat certifikáty těch autorit, jimiž podepsané certifikáty budou považovány za platné; součástí souboru může být revokační seznam):

    ssl_verify_client_cert = yes
    ssl_ca_file = /etc/ssl/certs/ca-certificates.crt
    

    Tím se ale jen zapne ověřování, nicméně není vyžadováno. Pro povinné použití se musí ještě přidat další parametr, a to do sekce auth:

    auth default {
        ssl_require_client_cert = yes
    }
    

    Záznam událostí okolo TLS má pouze dvě úrovně. Výchozí je stručná, v případě potřeby něco zkoušet a ladit lze použít verbose_ssl = yes pro zapnutí „ukecaného“ režimu. Další zajímavou věcí v souvislosti s TLS je možnost vypnout posílání hesel v otevřeném tvaru po nešifrovaných kanálech:

    disable_plaintext_auth = yes
    

    Možnost využívat taková hesla přes TLS kanál nebo z místní adresy zůstává zachována.

    U obou programů lze pro TLS nastavovat ještě další vlastnosti – konkrétně například množinu povolených šifer. To je ale poměrně složitá problematika, která by si zasloužila samostatný článek (obecný, nesouvisející jen s poštou), proto zájemce odkazuji na informační zdroje zaměřené přímo na tuto problematiku.

    Doručovací agent

    link

    Dovecot kromě komponent pro přístup k poště a pro autentizaci obsahuje ještě jednu velmi výkonnou součást, která se zatím v akci vůbec neobjevila. Je to tzv. doručovací agent, který vstoupí do hry jako poslední článek v řetězci při doručování pošty. Škála toho, co dokáže, je velmi široká – ale o tom až příště.

           

    Hodnocení: 100 %

            špatnédobré        

    Nástroje: Tisk bez diskuse

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    Komentáře

    Vložit další komentář

    25.1.2010 01:06 dracul
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 12 (TLS)
    mala reklamka: na cartifikat pro server doporucuju toto http://www.startssl.com/?app=1 je to zadarmo;)
    25.1.2010 09:17 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Postfix jako implicitní TLS klient
    Zajímalo by mě, jestli Postfix umí vystupovat jako implicitní TLS klient. Například Exim to neumí a next-hop relaye se musí honit přes stunnel. (Ano, odchozí servery Telecomu neumí explicitní TLS.)
    Luk avatar 25.1.2010 18:30 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Postfix jako implicitní TLS klient
    Zajímalo by mě, jestli Postfix umí vystupovat jako implicitní TLS klient.
    Pokud vím, tak neumí.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    26.1.2010 07:16 Lampa
    Rozbalit Rozbalit vše Re: Postfix jako implicitní TLS klient
    Co to je implicitni klient ?

    STARTLS ?
    Luk avatar 26.1.2010 17:31 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Postfix jako implicitní TLS klient
    Právě naopak. Jak píšu v článku, STARTTLS je naopak explicitní. Implicitní je, pokud se od začátku komunikuje pomocí TLS (tj. začíná se hned sestavením TLS relace). Implitní TLS klient je takový klient, který se připojí k serveru hned pomocí TLS, obvykle na speciálním portu (u SMTP je to 465).
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    27.1.2010 07:32 Lampa
    Rozbalit Rozbalit vše Re: Postfix jako implicitní TLS klient
    smtpd_tls_wrappermode=yes neni to co potrebujete ?
    Luk avatar 27.1.2010 14:57 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Postfix jako implicitní TLS klient
    To řeší serverovou stranu, nikoli klientskou.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    28.1.2010 08:44 Lampa
    Rozbalit Rozbalit vše Re: Postfix jako implicitní TLS klient
    sorry omlouvam se, http://www.postfix.org/postconf.5.html#smtp_tls_security_level
    1.2.2010 22:30 juras
    Rozbalit Rozbalit vše Re: Postfix jako implicitní TLS klient
    Co exim a "tls_on_connect_ports = 465"?

    viz. http://www.exim.org/exim-html-4.69/doc/html/spec_html/ch39.html#SECID284
    2.2.2010 11:48 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Postfix jako implicitní TLS klient

    Exim teď používám, takže vím, co neumí:

    Exim supports these clients by means of the tls_on_connect_ports global option.
    25.1.2010 09:35 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Autorizace klienta Dovecotu certifikátem

    Vzhledem k tomu, že legislativa donutila úřady pořídit šifrovací zařízení, chtěl bych, aby je naši úředníci mohli použít pro přístup do poštovních schránek přes IMAP.

    Díval jsem se do dokumentace Dovecotu, a nikde jsem nenašel, jak spárovat klientský certifikát a přihlašovací jméno uživatele. Vzpomínám si na hádání loginu z položek DN nebo SAN certifikátu, ale to obecně nefunguje.

    I z toho, co jste napsal, mi vyšlo, že sice dokážu ověřit, že klient disponuje certifikátem vydaným autorizovaným vydavatelem (v našem státě to znamená, že byl vydán existující a správné osobě), ale už nezjistím, kdo se mi to přihlašuje.

    Tudíž potřebuji namapovat otisk certifikátu na konkrétního uživatele.

    Protože mám fyzické (nevirtuální) uživatele a používám PAM, napadlo mě použít některý z pokusných modulů, které autentizaci řeší porovnáním certifikátu (respektive ověřením podpisu nesmyslu) s certifikátem uloženým v domovském adresáři uživatele.

    Jenže jsem nezjistil, jak a jestli umí Dovecot poskytnout certifikát klienta z TLS relace PAMu. Navíc dotyčné moduly často operují lokálním šifrovacím zařízením, nikoliv s certifikátem ze sítě. (Je celkem možné, že PAM na tohle nemá standardizované rozhraní.)

    Zkoušel někdo něco takového?

    25.1.2010 12:19 Lampa
    Rozbalit Rozbalit vše Re: Autorizace klienta Dovecotu certifikátem
    # Which field from certificate to use for username. commonName and # x500UniqueIdentifier are the usual choices. You'll also need to set # ssl_username_from_cert=yes. #ssl_cert_username_field = commonName

    http://wiki.dovecot.org/SSL/DovecotConfiguration (na konci stranky)
    25.1.2010 15:22 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Autorizace klienta Dovecotu certifikátem
    Jenže v kanonickém jméně takového certifikátu nebývá novakf, ale František Novák.
    25.1.2010 22:25 Honza Jaroš | skóre: 6 | blog: moje_strana_plotu | Bohnice
    Rozbalit Rozbalit vše Re: Autorizace klienta Dovecotu certifikátem
    No od toho se snad nechá měnit ta hodnota "ssl_cert_username_field", ne? Tak to prostě nenasměrujete na kanonické jméno, ale na jiné pole v certifikátu.

    Školy nemám a v praxi to nepoužívám, ale přijde mi to logické... :-)
    25.1.2010 23:00 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Autorizace klienta Dovecotu certifikátem

    Jenže stejně nepoužitelné mohou být i ostatní hodnoty. Proto rozumné systémy se orientují podle otisku certifikátu. Navíc, když si certifikáty nevydáváte sám, tak se může stát, že přijde někdo, kdo bude mít zrovna v položce, kterou jsem si vybral kolizní hodnotu.

    26.1.2010 07:16 Lampa
    Rozbalit Rozbalit vše Re: Autorizace klienta Dovecotu certifikátem
    http://wiki.dovecot.org/SSL/DovecotConfiguration

    With v1.1.alpha5 and later you can change the field with ssl_cert_username_field = name setting (parsed using OpenSSL's OBJ_txt2nid() function). x500UniqueIdentifier is a common choice.

    ssl_cert_username_field = subjectKeyIdentifier

    resp se podivejte do souboru obj_mac.h z knihovny libssl a vyberte si udaje LN_XXXX ktery se vam hodi

    to jsou pouze teoreticke poznatky na zaklade dostupnych informaci, neovereno v praxi
    Luk avatar 25.1.2010 23:15 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Autorizace klienta Dovecotu certifikátem
    To má ale dva problémy - jednak těch polí ve standardním zaručeném certifikátu moc není, hlavně ale je potřeba vytvořit vazbu mezí tím uživatelským jménem a tím polem (které s používaným uživatelským jménem není shodné). Nenapadá mě žádné čisté řešení.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    26.1.2010 11:03 petr_p | skóre: 59 | blog: pb
    Rozbalit Rozbalit vše Re: Autorizace klienta Dovecotu certifikátem

    Ještě mám jeden nápad:

    Klient použije certifikát v TLS a do přihlašovacího dialogu vyplní uživatelské jméno.

    PAM by vzal název účtu z přihlašovacího jména a nejprve jako heslo by použil certifikát. Vzor certifikátu by byl v domovském adresáři nebo v LDAPu. Teprve v druhém kole by jako heslo použil heslo z přihlašovacího dialogu.

    Ale nevím, jak moc to znásilňuje PAM a otravuje uživatele.

    oryctolagus avatar 26.1.2010 09:05 oryctolagus | skóre: 29 | blog: Untitled
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 12 (TLS)
    Je to jen můj dojem, nebo článek omylem nebyl zařazen do seriálu Stavíme poštovní server?
    There are two hard things in computer science: cache invalidation, naming things, and off-by-one errors.
    Luk avatar 26.1.2010 17:34 Luk | skóre: 47 | blog: Kacířské myšlenky | Kutná Hora
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 12 (TLS)
    Stalo se to asi nedopatřením - už jsem napsal Robertovi.
    LinuxMarket - linuxový e-shop | LinuxEXPRES - linuxový magazín | OpenOffice.cz - portál uživatelů OpenOffice/LibreOffice
    26.1.2010 17:42 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 12 (TLS)
    Opraveno.
    27.1.2010 14:29 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 12 (TLS)
    U šestého dílu se nezobrazuje rozcestník první/poslední/předchozí/další
    Quando omni flunkus moritati
    27.1.2010 15:42 Robert Krátký | skóre: 94 | blog: Robertův bloček
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 12 (TLS)
    Mně ano. Jaký máš prohlížeč?
    27.1.2010 23:33 trekker.dk | skóre: 71
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 12 (TLS)
    Opera 10.1. Akorát teda doma (stejný prohlížeč) se u šestého dílu zobrazuje. Tady se prozměnu nezobrazuje u pátého dílu poté, co jsem ze šestého přelezl na pátý kliknutím na ten rozcestník. (Totéž platí při přechodu ze čtvrtého na pátý)
    Quando omni flunkus moritati
    24.2.2010 20:07 travel21
    Rozbalit Rozbalit vše Re: Stavíme poštovní server – 12 (TLS)
    Dobrý den, při používání TLS se mi na klientských stanicích zobrazuje po i instalaci certifikátu tato hláška:

    Server, ke kterému jste připojeni, používá zabezpečovací certifikát, který nelze ověřit. Certifikát, který lze používat jako koncovou entity, je používán jako CA, nebo naopak. Chcete dále používat tento server?

    Chápu, že nejde ověřit, když vystupuju jako vlastní CA - to mi je jasné ale nechápu tu entitu. Tedy nevím jaký vliv to má na funkci ale ta hlaška mě každou chvíli vyjede v outlooku když chci odeslat email přes svuj server z místa mimo mysubnet a docela mě to otravuje.

    Můžete mi někdo říci zda je to chyba nebo vlastnost woken. V logu vidím že TLS spojení při přnosu funguje.

    Založit nové vláknoNahoru

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.