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í
×

dnes 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
dnes 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ářů: 0
dnes 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
včera 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ářů: 0
včera 20:00 | Nová verze Ladislav Hagara | Komentářů: 0
včera 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
včera 18:11 | Nová verze

Byla vydána verze 2.11.0 QEMU (Wikipedie). Přispělo 165 vývojářů. Provedeno bylo více než 2 000 commitů. Přehled úprav a nových vlastností v seznamu změn.

Ladislav Hagara | Komentářů: 0
včera 17:44 | Komunita

Canonical oznámil dostupnost kryptografických balíčků s certifikací FIPS 140-2 úrovně 1 pro Ubuntu 16.04 LTS pro předplatitele podpory Ubuntu Advantage Advanced. Certifikace FIPS (Federal Information Processing Standards) jsou vyžadovány (nejenom) vládními institucemi USA.

Ladislav Hagara | Komentářů: 2
včera 16:11 | Zajímavý software

Společnost Avast uvolnila zdrojové kódy svého dekompilátoru RetDec (Retargetable Decompiler) založeného na LLVM. Vyzkoušet lze RetDec jako webovou službu nebo plugin pro interaktivní disassembler IDA. Zdrojové kódy RetDec jsou k dispozici na GitHubu pod open source licencí MIT.

Ladislav Hagara | Komentářů: 3
13.12. 11:00 | Zajímavý software
Na Good Old Games je v rámci aktuálních zimních slev zdarma k dispozici remasterovaná verze klasické point&click adventury Grim Fandango, a to bez DRM a pro mainstreamové OS včetně GNU/Linuxu. Akce trvá do 14. prosince, 15:00 SEČ.
Fluttershy, yay! | Komentářů: 6
Jak se vás potenciálně dotkne trend odstraňování analogového audio konektoru typu 3,5mm jack z „chytrých telefonů“?
 (8%)
 (1%)
 (1%)
 (1%)
 (75%)
 (14%)
Celkem 988 hlasů
 Komentářů: 45, poslední 1.12. 19:00
    Rozcestník

    SSL - 1 (certifikáty)

    24. 2. 2006 | Rastislav Stanik | Bezpečnost | 19536×

    Co je SSL, jak se liší od GPG? Představení certifikačních autorit a vytvoření vlastní CA pomocí OpenSSL.

    Úvod

    Tento článok je jemným úvodom do problematiky bezpečnej elektronickej komunikácie. Ten, kto chce komunikovať v prostredí internetu bezpečným spôsobom, má na výber dve technológie. Jednou je použitie systému PGP resp. jeho implementácie GPG. Jeho charakteristikou je to, že dôveryhodnosť komunikácie je založená len na vzťahu odosielateľa a príjemcu. V istých situáciách však tento spôsob nie je vyhovujúci. Ak chceme komunikovať so štátnymi inštitúciami alebo servermi, ktoré sú prakticky mimo náš dosah, otvára sa priestor pre systém bezpečnostných certifikátov. Z technického hľadiska je tento systém označovaný skratkou SSL - Secure Socket Layer - ak ho chceme používať, tak najlacnejšou cestou je použitie balíka OpenSSL.

    V systéme SSL nie je nutné, aby sa príjemca a odosielateľ navzájom osobne poznali. Overenie ich totožnosti zabezpečuje certifikačná autorita - CA. Je to organizácia, ktorá vydáva bezpečnostné certifikáty. Sú to dátové konštrukcie umožňujúce používanie elektronického podpisu. Ak dostanem správu od používateľa XY a tá správa je podpísaná jeho certifikátom, ktorý vydala CA, tak CA ručí za to, že ten certifikát bol vydaný práve používateľovi XY a nikto okrem neho nemohol vytvoriť príslušný podpis. Certifikáty tiež obsahujú kryptografické údaje, ktoré je možné použiť na šifrovanie dát pri elektronickej komunikácii.

    Vo svete existuje mnoho certifikačných autorít. Sú to organizácie, ktoré na požiadanie vydajú certifikát, ktorý potom možno použiť na bezpečnú elektronickú komunikáciu. Medzi najznámejšie patrí RSA Security Inc. či VeriSign Inc. Ich certifikáty často používajú banky a medzinárodné internetové obchody. Certifikačná autorita ako organizácia musí dodržiavať prísne bezpečnostné pravidlá - počnúc fyzickým zabezpečením priestorov, kde sa činnosť CA vykonáva, cez off-site zálohy, až po bezpečnostné previerky pracovníkov a podobne. S tým sú prirodzene spojené náklady, ktoré CA často prenáša na svojich klientov. Vydanie certifikátu je preto spravidla platená služba. Existujú ale aj CA, ktoré vydávajú certifikáty za nízku cenu resp. zadarmo. Medzi najznámejšie CA tejto triedy patrí Thawte. Na Slovensku aj v Čechách platí už niekoľko rokov Zákon o elektronickom podpise, ktorý pre účely právne záväzného elektronického podpisu vyžaduje použitie štátom uznanej certifikačnej autority. Povolenie na činnosť CA vydáva Národný bezpečnostný úrad. Ten takisto vydáva bezpečnostné predpisy pre činnosť CA, vykonáva ich kontrolu a funguje ako "koreňová CA" - podpisuje certifikáty komerčných certifikačných autorít. Na Slovensku medzi akreditované CA patrí napr. CA EVPÚ v Novej Dubnici. (V Čechách certifikáty vydáva napr. aj Česká pošta, ale nie som si istý či tieto certifikáty spĺňajú všetky náležitosti vyžadované českou legislatívou.)

    Certifikačná autorita

    V niektorých situáciách nám postačí CA, ktorú si vytvoríme sami. Jediným problémom je, že musíme všetkých ľudí, s ktorými chceme komunikovať pomocou certifikátov vydaných našou CA, presvedčiť o dôveryhodnosti tejto CA. Certifikačné autority ako VeriSign, Thawte a pod., si svoju dôveryhodnosť získali mnohoročným pôsobením na trhu. Našťastie urobiť si vlastnú certifikačnú autoritu technicky nie je nijako zložité. Použijeme program OpenSSL. Pravdepodobne tak nesplníme podmienky, ktoré stanovuje Zákon o elektronickom podpise, ale pre účely nahliadnutia do problematiky to stačí. S použitím programu OpenSSL vytvoríme CA nasledovne:

    V prvom rade vytvoríme súbor s parametrami pre vytvorenie DSA kľúča

    openssl dsaparam -outform PEM -out CAdsaparamfile -genkey 1024
    Generating DSA parameters, 1024 bit long prime
    This could take some time
    ...+++++++++++++++++++++++++++++++++++++++++++++++++++*
    .......+.....+.+..........+....+............+.+......................+..........
    ...+...........+...............+.........+.......+..........+...................
    +..+.....+.+...........+....+.+.......+..............+....+................+....
    .......+............+.............+..+......+.+...+.+....+.+....................
    ....+.......+.+................+............+.....+.....+..+....++++++++++++++++
    +++++++++++++++++++++++++++++++++++*
    

    Prvý parameter hovorí, že vytvárame DSA parametrický súbor. Ďalšie parametre hovoria, že výstup je vo formáte PEM, výstupný súbor bude mať meno CAdsaparamfile a generovaný kľúč bude mať dĺžku 1024 bitov. Balík OpenSSL používa konfiguračný súbor. Ten by mal byť spravidla umiestnený v /etc/ssl/openssl.cnf. Tam môžu byť preddefinované rôzne štandardné nastavenia. V tomto článku sa ho budem snažiť používať čo najmenej a pokiaľ možno, všetky požadované nastavenia definovať cez prepínače na príkazovom riadku.

    Ďalším krokom je vytvorenie DSA kľúča:

    openssl gendsa CAdsaparamfile -out CAdsaprivtekey
    Generating DSA key, 1024 bits

    Parametre tentoraz hovoria, že generujeme DSA kľúč s parametrami uvedenými v CAdsaparamfile a výstupný súbor sa bude volať CAdsaprivtekey.

    Nasleduje predposledný krok - vytvorenie požiadavky na certifikát samotnej CA:

    openssl req -new -x509 -key CAdsaprivtekey -out CAcertificate
    You are about to be asked to enter information that will be
    incorporated into your certificate request.
    What you are about to enter is what is called a Distinguished
    Name or a DN. There are quite a few fields but you can leave
    some blank. For some fields there will be a default value,
    If you enter '.', the field will be left blank.
    -----
    Country Name (2 letter code) [AU]:SK
    State or Province Name (full name) [Some-State]:Slovakia
    Locality Name (eg, city) []:Trencin
    Organization Name (eg, company) [Internet Widgits Pty Ltd]:Rastos
    Certificate
    Authority
    Organizational Unit Name (eg, section) []:
    Common Name (eg, YOUR name) []:rastos CA
    Email Address []:

    V parametroch vidíme, že vyrábame požiadavku (request) pre vytvorenie nového certifikátu typu X509 s použitím DSA kľúča v súbore CAdsaprivtekey. Výsledný certifikát bude uložený do súboru s názvom CAcertificate. Tento certifikát budeme používať pre vytváranie certifikátov jednotlivých používateľov. Súbor s certifikátom je zakódovaný base64 kódovaním. Vyzerá takto:

    -----BEGIN CERTIFICATE-----
    MIIDuTCCA3mgAwIBAgIJANc8qEjrcbHnMAkGByqGSM44BAMwXjELMAkGA1UEBhMC
    ...
    LAIUWMK6QHBbzNzOG4VznLxaXubHsKcCFDEXLLUV8REDXxLwTdQajeDWeerI
    -----END CERTIFICATE-----

    Ak chceme vidieť jeho obsah v zrozumiteľnej forme, pomôže nám tento príkaz:

    openssl x509 -text -in CAcertificate -noout
    Certificate:
        Data:
            Version: 3 (0x2)
            Serial Number:
                d7:3c:a8:48:eb:71:b1:e7
    ...

    Pre fungovanie CA je potrebné urobiť ešte jeden krok - vytvoriť súbor, v ktorom bude OpenSSL udržiavať aktuálny zoznam vydaných a aj neplatných certifikátov a ich počet:

    mkdir demoCA
    touch demoCA/index.txt
    echo 01 > demoCA/serial

    Umiestnenie týchto súborov definuje konfiguračný súbor:

    [ CA_default ]
    dir             = ./demoCA              # Where everything is kept
    database        = $dir/index.txt        # database index file.
    serial          = $dir/serial           # The current serial number
    

    Certifikát

    Ak chce používateľ dostať certifikát od našej CA, musí nám najprv poslať požiadavku (request):

    openssl req -new -out RScertrequest -keyout RSprivatekey
    Generating a 1024 bit RSA private key
    ......................................++++++
    .++++++
    writing new private key to 'RSprivatekey'
    Enter PEM pass phrase:
    Verifying - Enter PEM pass phrase:
    -----
    You are about to be asked to enter information that will
    be incorporated into your certificate request.
    ...

    Všimnite si, že program si vypýtal "PEM pass phrase" - to je heslo, ktoré budeme používať pri vytváraní elektronického podpisu. Jeho bezpečnosť je dôležitým prvkom bezpečnosti celého systému.

    Certifikačná autorita by si mala teraz overiť, že požiadavka skutočne patrí osobe, ktorá ju doručila a potom môže vytvoriť samotný certifikát:

    openssl ca -in RScertrequest -out RScertificate.pem \
     -policy policy_anything -outdir . -cert CAcertificate \
     -keyfile CAdsaprivtekey -verbose -days 365
    Using configuration from /etc/ssl/openssl.cnf
    0 entries loaded from the database
    ...
    Certificate is to be certified until Feb 11 21:22:57 2007 GMT (365 days)
    Sign the certificate? [y/n]:y
    
    1 out of 1 certificate requests certified, commit? [y/n]y
    Write out database with 1 new entries
    writing new certificates
    writing ./01.pem
    Data Base Updated

    V tomto príkaze sú použité parametre, ktoré hovoria, že CA použije požiadavku RScertrequest na vytvorenie certifikátu podpísaného certifikačnou autoritou. Tento certifikát bude spôsobilý na všetky úkony (šifrovanie/podpisovanie/...) a bude vytvorený s použitím certifikátu CAcertificate a súkromného kľúča v CAdsaprivtekey a bude platný 365 dní. Súbor RScertificate.pem teda CA vráti žiadateľovi a ten ho môže odteraz používať pre komunikáciu pomocou SSL. Certifikačná autorita si ponecháva jednu kópiu z podpísaného certifikátu v súbore 01.pem. Z overeného certifikátu si môžeme vytiahnuť verejný kľúč, ktorý budeme potrebovať pri overovaní podpisu.

    openssl x509 -noout -pubkey -in RScertificate.pem > RSpublickey
           

    Hodnocení: 86 %

            š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ář

    24.2.2006 00:28 Sinuhet | skóre: 31
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    BTW, uz se doporucuje delat 2048 bitove klice.
    24.2.2006 08:27 Xerces
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    Ahojda, já ten rozdíl stále nechápu :-( Jaká je principiálně výhoda SSL oproti GNUPG? V článku se píše, že tím hlavním rozdílem, je to, že u SSL stačí znát CA aby si oba důvěřovali, ale u GNUPG přesi stačí si osobně vynměnit klíče a je to ještě bezpečnější. A když si mohu zajistit certifikát od CA, tak proč bych si nemohl zajistit GPG klíč od protistrany? Navíc GPG klíč mohu dále podepisovat a distribuovat, takže to funguje tak nějak přirozeně samo. To mě totiž vytáčí, že úřady začínají požadovat certifikáty, za které by bylo nutné platit CA a odmítají si vyměnit klíče osobně. Jaký je problém aby patřičný úřad byl defakto takovou CA?
    24.2.2006 09:19 Pavel F.
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    No protože každý úřad nebude mít lidi, kteří budou mít na starosti výměnu klíčů, ověřování, atd. Je to prostě něco jako outsourcing. Externí CA vydává certifikáty a úřady v dobré víře důvěřují těmto certifikátů, aniž by museli mít vlastní mechanismy pro ověřování pravosti, atd. Je to asi podobná námitka, jako kdybyste prohlásil, že občanské průkazy jsou nesmysl, že by stačilo, kdybyste se každému úřadu prokázal jinak, že se jedná zrovna o Vás. Také úřady v dobré víře důvěřují OP, že je vydala jiná autorita (stát) a nemusí Vás jinak ověřovat (pokud bezpečnostní prvky na OP souhlasí)
    24.2.2006 12:10 Marian K.
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    Přesně tak. Například naše firma vydává podepsaný software, přičemž podpis se dělá pomocí certifikátu od Verisignu. Kdyby si každý uživatel tohoto SW měl napsat k nám o klíč a nejlíp si pro něj dojít osobně (aby měl jistotu, že někde uprostřed není někdo "zašitý"), asi bychom celý den nedělali nic jiného.
    24.2.2006 12:26 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    že občanské průkazy jsou nesmysl, že by stačilo, kdybyste se každému úřadu prokázal jinak, že se jedná zrovna o Vás
    Dovede-li se tato představa důsledně do analogie s PGP, musel byste s sebou přivést někoho (A), kdo vás zná. Ten (A) by s sebou přivedl někoho (B), kdo zná jeho (A). (B) by s sebou přivedl někoho... až někonec by byl někdo (X), koho zná úředník :-) Podle 6 stupňu odloučení by vám měli stačit 4 lidi :-)
    Petr Tomášek avatar 25.2.2006 12:18 Petr Tomášek | skóre: 37 | blog: Vejšplechty
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    a jak myslite, ze to fungovalo predtim, nez byly obcanske prukazy? ;-))
    1.3.2006 12:06 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    To by mě taky hodně zajímalo. Jak to např. bylo ve středověku nebo v Římě, Řecku, Egyptě, Číně.
    1.3.2006 23:44 Dan Ohnesorg | skóre: 29 | blog: Danuv patentovy blog | Rudná u Prahy
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    Jak to fungovalo v Rime nevim, ale v Anglii nemeli do doby, nez zacali bojovat s terorizmem, zadne obcanske prukazy. Na jedne akci FFII jsme sedeli s anglicany a povidali si o tom, protoze "me to hlava nebrala". Oni zastavali nazor, ze jediny pripad, kdy potrebuji byt identifiovani jsou volby a tam se to resi tak, ze se volebni listky poslou kazdemu domu na adresu a kdyby na ne volil nekdo jiny, tak se na to prijde, protoze prece kdyz oni k tem volbam prijdou, tak zjisti, ze nekdo volil jejich jmenem.

    Nicmene oni zalozni identitu maji, jen ne tak viditelnou. Nikdo se s nima nebavi bez platebni karty. Takze chcete elektromer = ukazte platebni kartu, chcete dostat podporu na dite, ukazte kartu a urad na ni posle penize. A ziskani karty funguje na principu znamosti, dite dostava kartu tak, ze s nim zajdou rodice do banky, kde je po mnoho let znaji a reknou, hele to je nase dite. Stejne tak na mistnich uradech, oni se proste vzajemne znaji a vsechno resi na jednom miste, takze maji jednu urednici co je zna na vsechno, od kolibky do hrobu.

    Myslim ze pro nas je to ale stejne nepochopitelne. Dokazu si to prestavit na vesnicich, ale v Praze ne.
    I'm an Igor, thur. We don't athk quethtionth. Really? Why not? I don't know, thur. I didn't athk. TP -- Making Money
    3.3.2006 14:17 GeBu | skóre: 27 | blog: zápisky
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    To vypadá fakt zajímavě až neuvěřitelně. Zkusím ověřit.
    18.3.2006 07:29 petr
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    to jsou nesmysly ... vsichni meli v anglii do doby obcanek průkaz pojištění a měli sociální čísla s nějako kartou ... takže identifikaci měli ...
    24.2.2006 12:19 Filip Jirsák | skóre: 67 | blog: Fa & Bi
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    Zatímco u PGP si musím vyměnit klíč s každou protistranou, u certifikátů SSL si zajistím jednou certifikát CA a pak už vím, že všechny certifikáty vydané touto CA mají ověřené údaje (dle politiky CA). Pokud třeba budu potřebovat komunikovat jen v ČR s certifikáty uznávanými zákonem, stačí mi 3 certifikáty současných CA a nemusím shánět 10 milionů GPG klíčů :-) Druhá výhoda CA je ta, že ručí za certifikát přímo. U GPG víte, že Franta podepsal klíč Pepovi, Frantovi ho podepsala Jitka, Jitce Blanka, a s Blankou jste si klíš vyměnil. Budete všem těm lidem mezi opravdu věřit? Úřad jim samozřejmě věřit nemůže, a nelze se na tento řetězec spolehnout ani v žádném případě, který má mít nějakou právní váhu - všechny ty články řetězu by se totiž stali spoluručiteli, a to předem, aniž by věděli, za co vlastně ručí. Úřad si s vámi nemůže vyměňovat klíče a být "takovou" CA, protože úřad si nemůže dělat, co se mu zlíbí - vynakládat "jen tak" peníze na vytvoření důvěryhodné CA, zaškolovat lidi apod.
    27.2.2006 13:37 Xerces
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    Děkuji, s těma OP jsem to pochopil a máte pravdu, jistá výhoda v tom bude. Pak bych ale měl jedno velké přání, aby stejně jako existuje jeden průkaz totožnosti, existoval jeden certifikát na veškerý kontakt s úřady. Prostě aby stačilo jednou za 10 let dojít pro certifikát a hotovo.
    24.2.2006 09:59 lovec
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    No .. mal by som niekolko nevela (desiatok) pripomienok: - To nie je specifickou vlastnostou SSL, ze prijemca a odosielatel sa nemusia poznat. To je vlastnost PKI. - Co ste napisali: "Ak dostanem správu od používateľa XY a tá správa je podpísaná jeho certifikátom," je upl na haluz .. sprava (presnejsie jej hash) sa podpisuje sukromnym klucom a v certifikate je ulozeny len k nemu zodpovedajuci verejny kluc. - CA nepotrebuju na svoju cinnost "povolenie na cinnost", ale akreditaciu od Narodneho bezpecnostneho uradu. - Garantom el. podpisu (podla ceskeho zanoka digitalneho) v ceskej republike nie je NBU, ale ministerstvo in formatiky. - NBU nevydava "bezpecnostne predpisy pre CA". Hlavnym predpisom CAcky je jej bezpecnostna politika. TU si v ydava sama. NBU moze na CA posobit len bez vyhlasky, alebo (ne)udelenim akreditacie. - CA EVPU nesidli v Dubnici nad Vahom, ale v Novej Dubnici. - Nie je pravda, ze konfiguracny subor "by mal byť spravidla umiestnený v /etc/ssl/openssl.cnf". Napriklad j a ho mam na linuxe v /usr/lib/ssl/openssl.cnf, na solarise bol defaultne ulozeny /usr/local/ssl/openssl.cnf. - paSinuhet: - 2048 bitove kluce sa vytvaraju prevazne pri sifrovani pomocou RSA. Ale velkost zatial nie je az tak kritic ka. Vacsina kvalifikovanych certifikatov je 1024 bitova (vzdy RSA, vyhlaska NBU ine algoritmy nepovoluje).

    Xerces: S PGP skusenosti nemam, aj ked s el. podpisom robim uz 2 roky(robim = je to hlavna napln mojej prace). Jedna k na komunikaciu medzi serverom a klientom mozes pouzit len SSL. To je hlavnou naplnou tohto protokolu.

    SSL nema vela spolocneho s el. podpisom. Ten sa robi podla standardu PKCS#7 (alebo doplnenie v norme ETSI). I na vec je, ze projekt OpenSSL si dal za jednu z uloh okrem vzniku open-source implementacie SSL protokolu aj podporu vzniku komplexnej kniznice zaoberajucej sa sifrovanim, podpisovanim a vsetkym co s tym suvisi. A teda umoznuje aj vytvarat a overovat aj podpis.Pass phrase nie je "heslo, ktoré budeme používať pri vytváraní elektronického podpisu". Je to o tom, ze privatny kluc je ulozeny v zasifrovanej pomocou symetrickej sifry. Kluc, ktorym je zasifrovany sa ziskal z tohto hesla. - Registracna a nie certifikacna autorita overuje, totoznost osoby, ktora ziada o vydanie certifikatu. - Certifikat sa nevytvara "pomocou CA certifikatu", ale pomocou sukromneho kluca CA. Certifikat CA je dobry len na to, aby v certifikate bolo mozne spravne uviest vydavatela. Tu si uz trosku PKI a PGP zacinaju "liezt" do kapusty. PKI je oficialny standard, pokryty strasnou haldou noriem o formate podpisu, certifikatov, CRL, casovych peciatok a co ja viem coho este. Je zalozeny na tom, ze existuje zopar certifikacnych autorit, ktore (cez nejake registracne autority, ale to nas teraz nezaujima) overia totoznost osoby a vydaju jej certifikat. CAcky nesu zodpovednost (aj hmotnu) za to, ze certifikat vydali komu mali a nie niekomu inemu.

    Projekt PGP je ovela volnejsi. Phil Zimmermann ho pojal tak, ze certifikaty nevydava nejaka neohrozena CA, ale kazdy si ho vyda sam. Na to, aby bolo mozne "verit" takto vydanemu certifikatu je vsak potrebne, aby sme ho ziskali z doveryhodneho zdroja. CO znamena, napriklad, ze nam ho da niekto fyzicky.

    Ina moznost ako ziskat certifikat je ziskat ho od osoby, ktorej doverujete a jej kluc uz mate. Co je vsak skoro nemozne, ak sa chcete vybavovat s niekym, s kym ste sa este nestretli.
    24.2.2006 17:25 rastos | skóre: 60 | blog: rastos
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    No .. mal by som niekolko nevela (desiatok) pripomienok:

    Od toho tu tá diskusia je ;-) Nikde netvrdím, že som miestny expert na SSL. Je pravda, že článok je miestami nepresný. Ale cieľom je vysvetliť princípy. A neunudiť pritom čitateľa na smrť.

    - To nie je specifickou vlastnostou SSL, ze prijemca a odosielatel sa nemusia poznat. To je vlastnost PKI.

    To tiež nie je celkom presné. V článku poukazujem na to, že fyzické overenie toho, že certifikát C patrí osobe O robí certifikačná autorita a nie ten, kto skúma konkrétny elektronický podpis nejakého dokumentu.

    - Co ste napisali: "Ak dostanem správu od používateľa XY a tá správa je podpísaná jeho certifikátom," je upl na haluz .. sprava (presnejsie jej hash) sa podpisuje sukromnym klucom a v certifikate je ulozeny len k nemu zodpovedajuci verejny kluc.

    Správne.

    - CA nepotrebuju na svoju cinnost "povolenie na cinnost", ale akreditaciu od Narodneho bezpecnostneho uradu.

    Slovník vraví akreditácia == "úradné oprávnenie vykonávať istú činnosť"

    - Garantom el. podpisu (podla ceskeho zanoka digitalneho) v ceskej republike nie je NBU, ale ministerstvo in formatiky.

    Dobre vedieť. To som nevedel a o právnom pozadí v ČR som sa vyjadroval v článku dosť opatrne ;-)

    - NBU nevydava "bezpecnostne predpisy pre CA". Hlavnym predpisom CAcky je jej bezpecnostna politika. TU si v ydava sama. NBU moze na CA posobit len bez vyhlasky, alebo (ne)udelenim akreditacie.

    Tak dobre. Ja neprevádzkujem verejnú CA a ten, kto ju chce prevádzkovať musí vedieť viac, ako to čo je v tomto článku. NBÚ SR publikuje na svojich stránkach "metodika auditu SW aplikácií pre ZEP","vzor protokolu o kompilácii", "Schválené formáty" a niekoľko vyhlášok a predpisov popisujúcich najrôznejšie aspekty od technického zabezpečenia budov CA, cez off-site backup-y, disaster recovery a podobne. Ak sa cítiš dostatočne fundovaný, tak o tom napíš článok. Čitatelia budú vďační.

    - CA EVPU nesidli v Dubnici nad Vahom, ale v Novej Dubnici.

    Pravda je. Vzhľadom na to, že sme na českom serveri a väčšina čitateľov by mala problém nájsť to na mape - dúfam, že mi odpustia. ;-)

    - Nie je pravda, ze konfiguracny subor "by mal byť spravidla umiestnený v /etc/ssl/openssl.cnf". Napriklad j a ho mam na linuxe v /usr/lib/ssl/openssl.cnf, na solarise bol defaultne ulozeny /usr/local/ssl/openssl.cnf.

    Ok. Podla zdrojákov, je default /usr/local/ssl - ale do hry vstupuje LSB, ktoré hovorí, že system-wide konfigurácia má byť pod /etc.

    Xerces: S PGP skusenosti nemam, aj ked s el. podpisom robim uz 2 roky(robim = je to hlavna napln mojej prace). Jedna k na komunikaciu medzi serverom a klientom mozes pouzit len SSL. To je hlavnou naplnou tohto protokolu.

    To bude vysvetľovať, prečo mám pocit, že Ťa ten článok zdvihol zo stoličky.;-)

    Pass phrase nie je "heslo, ktoré budeme používať pri vytváraní elektronického podpisu". Je to o tom, ze privatny kluc je ulozeny v zasifrovanej pomocou symetrickej sifry. Kluc, ktorym je zasifrovany sa ziskal z tohto hesla.

    Správne. Uff. Je piatok vecer a ja mam dost. Bol by si ochotný urobiť reviziu druheho dielu članku?

    24.2.2006 22:44 Robert Kupka | skóre: 15
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    - CA EVPU nesidli v Dubnici nad Vahom, ale v Novej Dubnici.

    Pravda je. Vzhľadom na to, že sme na českom serveri a väčšina čitateľov by mala problém nájsť to na mape - dúfam, že mi odpustia. ;-)

    Nie, my Novodubničania ti neodpustíme :) A Novú Dubnicu vôbec nie je ťažké na mape nájsť. Nájdeš ju aj na Google Earth.

    Ak sa cítiš dostatočne fundovaný, tak o tom napíš článok.

    Ty ho píšeš a vzhladom na množstvo nepresností, na ktoré ťa lovec upozornil, by si na svojej fundovanosti mal poriadne zapracovať.

    Inak, dobrá téma.
    27.2.2006 09:29 Vlastimil Ott | skóre: 66 | blog: Plastique | Opava
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    Opraveno na "v Novej Dubnici", díky.
    Práce: Liberix, o.p.s. | Blog: OpensourceBlog.cz | Online kurz Zlatý WordPress
    25.2.2006 11:36 Kumar
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    Diky obema :) mam rad diskuzi dvou lidi kteri VI ze neco vi :) TOHLE je diskuze a ne blaboly o nesmyslnostech BRAVO :)))
    15.11.2006 13:35 zorokuncak
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    prosim vas, kdo je certifikacni autorita pro el. podpisy v CR? diki
    24.1.2008 20:01 Karlik
    Rozbalit Rozbalit vše Re: SSL - 1 (certifikáty)
    Dobry den, snazim se pochopit certifikaty a digitalni podpisy. Chtel bych totiz sve ucetni nechat vystavit digitalni podpis od CA PostSignum Ceske posty, aby mohla posilat oficialni maily na urady. Jsem z toho ale zmatenej a proto procitam vsechny navody, abych pochopil, jak to vlastne vsechno funguje. Nejde mi o to, abych do toho videl na 100 procent, ale spis nevim, na co ji mam upozornit, aby si hlidala jako oko v hlave atd. Vim, hlidejte si soukromy klic (ctu vsude), ale rarazi me uz jen import do mailovych klientu. Bojim se, aby se ji soukromej klic nevalel, kde nema a mela o nem absolutni prehled. Proto jsem si procital napriklad tento clanek X krat, i jsem si klice vygeneroval a vse funguje bez problemu. Muzete mi ale prosim rici (kdyz pominu me dotazy ohledne funkcnosti celeho mechanizmu overovani) co jsou tyto sobory:

    RSpublickey (logicky z nazvu - verejny klic) musi ho mit i prijemce,ze? RSprivatekey (logicky z nazvu je to prave to oko v hlave - privatni klic) RScertificate.pem (co je ale toto? To je snad privatni klic vcetne verejneho klice? Tomu prave nejak nerozumim).

    A soubor p12 je nejaky balik privatniho a verejneho klice, co akceptuji mailovy klienti?

    Snad pochopite o co mi jde a pripadne mi poradite. Budu Vam moc vdecny. Karlik

    Založit nové vláknoNahoru

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