Secure Sockets Layer (doslova vrstva bezpe?nych socket? ), zkracen? SSL , je protokol , resp. vrstva vlo?ena mezi vrstvu transportni (nap?. TCP/IP ) a aplika?ni (nap?. HTTP ), ktera poskytuje zabezpe?eni komunikace ?ifrovanim a autentizaci komunikujicich stran. Nasledovnikem SSL je protokol Transport Layer Security (TLS).

Vyu?iti [ editovat | editovat zdroj ]

Protokol SSL se nej?ast?ji vyu?iva pro bezpe?nou komunikaci s webovymi servery pomoci HTTPS , co? je zabezpe?ena verze protokolu HTTP . Po vytvo?eni SSL spojeni ( session ) je komunikace mezi serverem a klientem ?ifrovana, a tedy zabezpe?ena.

Obvykla vyu?iti SSL certifikat? :

• on-line obchody, ktere p?ijimaji objednavky a udaje platebnich karet
• www portaly a projekty s administraci pro zabezpe?eni hesel a dat
• komunikace s obchodnim partnerem (vym?na d?v?rnych informaci)
• zabezpe?eni p?istupu k po?t? mimo firemni si? (Exchange, ...)
• zpracovani citlivych osobnich udaj?
• dodr?eni regula?nich ustanoveni (legislativa), ktera vy?aduji zabezpe?ene p?enosy

Princip [ editovat | editovat zdroj ]

Ustaveni SSL spojeni funguje na principu asymetricke ?ifry , kdy ka?da z komunikujicich stran ma dvojici ?ifrovacich kli?? ? ve?ejny a soukromy. Ve?ejny kli? je mo?ne zve?ejnit a pokud timto kli?em kdokoliv za?ifruje n?jakou zpravu, je zaji?t?no, ?e ji bude moci roz?ifrovat jen majitel pou?iteho ve?ejneho kli?e svym soukromym kli?em.

Ustaveni SSL spojeni ( SSL handshake , tedy ?pot?asani rukou“) pak probiha nasledovn?:

1. Klient po?le serveru po?adavek na SSL spojeni, spolu s r?znymi dopl?ujicimi informacemi (verze SSL, nastaveni ?ifrovani atd.).
2. Server po?le klientovi odpov?? na jeho po?adavek, ktera obsahuje stejny typ informaci a hlavn? certifikat serveru.
3. Podle p?ijateho certifikatu si klient ov??i autenti?nost serveru. Certifikat take obsahuje ve?ejny kli? serveru.
4. Na zaklad? dosud obdr?enych informaci vygeneruje klient zaklad ?ifrovaciho kli?e, kterym se bude ?ifrovat nasledna komunikace. Ten za?ifruje ve?ejnym kli?em serveru a po?le mu ho.
5. Server pou?ije sv?j soukromy kli? k roz?ifrovani zakladu ?ifrovaciho kli?e. Z tohoto zakladu vygeneruji jak server, tak klient hlavni ?ifrovaci kli?.
6. Klient a server si navzajem potvrdi, ?e od te? bude jejich komunikace ?ifrovana timto kli?em. Faze handshake timto kon?i.
7. Je ustaveno zabezpe?ene spojeni ?ifrovane vygenerovanym ?ifrovacim kli?em.
8. Aplikace od te? dal komunikuji p?es ?ifrovane spojeni. Nap?iklad POST po?adavek na server se do teto doby neode?le.

B?hem prvni faze ustanoveni bezpe?neho spojeni si klient a server dohodnou kryptograficke algoritmy, ktere budou pou?ity. V dne?ni implementaci jsou nasledujici volby:

• pro vym?nu kli??: RSA , Diffie-Hellman , DSA nebo Fortezza ;
• pro symetrickou ?ifru: RC2 , RC4 , IDEA , DES , 3DES nebo AES ;
• pro jednocestne ha?ovaci funkce: MD5 nebo SHA .

Chyby v pou?ivani [ editovat | editovat zdroj ]

D?v?ra k mnoha CA

V PC je p?edinstalovano n?kolik CA (Certificate authority - Certifika?ni autorita). T?mto se p?i prohli?eni stranek https:// automaticky d?v??uje a u?ivatel si to ani nemusi uv?domit. Chyba je v tom, ?e v ulo?i?ti pro CA m??e byt i n?jaka testovaci CA. Ta samoz?ejm? d?v?ryhodna neni!

Podepsany certifikat je dobry certifikat

Dal?i ?asta chyba je, ?e u?ivatele p?edpokladaji, ?e podepsany certifikat je spravny certifikat. To je samoz?ejm? ?patn?, nebo? certifikat mohl byt podepsan uto?nikovou CA. Je d?le?ite kontrolovat, kdo certifikat vydal.

Navrat k TCP

U?ivatel ma vepsat URL adresu, ktera ma na za?atku https:// , ale p?ipojeni se nezda?i (nap?. prohli?e? napi?e, ?e vypr?ela doba na p?ipojeni). U?ivatel si ?ekne, ?e n?kde nastala chyba (t?eba ?e se p?eklepl) a vepi?e adresu znova bez ?s“. Tedy z?stane mu jen http:// a SSL se nepou?ije.

Povoleni nebezpe?nych ?ifer

Existuje n?kolik ?ifrovacich algoritm?. N?ktere jsou bezpe?ne a jine nikoli. Chyba je v tom, ?e n?kde m??e byt povoleno pou?it ji? p?ekonane ?ifrovaci algoritmy. U?ivatel by si m?l tedy zkontrolovat, ?e pou?iva ty (v sou?asne dob?) bezpe?ne.

Certifika?ni autority [ editovat | editovat zdroj ]

CA jsou nej?ast?ji komer?ni spole?nosti, ktere certifikuji klientske ?adosti a potvrzuji identitu ?adatele. Ziskane informace pak p?ipojuji k vydanemu certifikatu. V dne?ni dob? se pou?ivaji r?zne urovn? ov??eni majitele domeny. Od jednoducheho potvrzeni odkazu v zaslanem e-mailu (tzv. ov??eni domeny) a? po detailn?j?i autorizaci v?etn? telefonickeho ov??eni.

Nejznam?j?i komer?ni certifika?ni autority: Thawte, Symantec (d?ive VeriSign), GeoTrust, Comodo, Trustwave, DigiCert.

Dopl?ujici informace [ editovat | editovat zdroj ]

• Adresy stranek zabezpe?enych pomoci SSL za?inaji https://. Prohli?e? take zabezpe?ene stranky ozna?uje ikonkou zamku ve stavove li?t?. Moderni prohli?e?e zobrazuji ikonku zamku rovn?? v ?adku adresy a podbarvuji tuto ?adku r?znymi barvami (zelena pro pln? vyhovujici, ?luta nebo oran?ova pro ?aste?n? vyhovujici (nap?. vyhovujici certifikat, ale vydany pro jinou domenu), ?ervena pro nevyhovujici certifikat).
• Standardni port pro komunikaci p?es HTTPS/SSL je 443, standardni port HTTP je 80.
• HTTPS/SSL doka?e zajistit d?v?rnost dat jen na cest? od klienta k serveru (a naopak). Je na provozovateli serveru, jak potom s d?v?rnymi daty po roz?ifrovani nalo?i. Vyjimkou neni ulo?eni v ne?ifrovane podob? do nechran?ne databaze .

V roce 2005 se zjistilo, ?e neni jednoduchy zp?sob jak upgradovat SSL v2 na TLS ^[1] , proto internetove stranky musely aktualizovat sv?j software. Mozilla oznamila kompletni ukon?eni podpory SSL v2 ^[2] v nove verzi Firefoxu . Spole?nost Firefox potom p?esv?d?ila majitele zbylych 2000 stranek, aby aktualizovaly jejich servery na SSL v3 nebo TLS v1.

Reference [ editovat | editovat zdroj ]

Souvisejici ?lanky [ editovat | editovat zdroj ]

• Transport Layer Security
• HTTPS
• Server Name Indication
• OpenSSL

Externi odkazy [ editovat | editovat zdroj ]

• Serial Jak na OpenSSL