Názory k článku SSL autentizácia s webovým serverom Apache

Co se tyka omezeni klientu, tak je lepsi k tomu vyuzit nejaky auth modul, nez to davat natvrdo do konfigurace apache – obzvaste pokud jich mame vice. Napr. takto http://www.modssl.org/…l_howto.html#ToC9

Taky je fajn trosku poladit protokol a sifry, kterymy se da standardne prihlasit. Default je vsechnhy, tj: SSlv2, SSlv3 a TLSv1. V dnesni dobe pouzivat SSLv2 uz neni zrovna to ono, kdyz vsichni moderni klineti zvladaji bez potizi TLSv1. Takze ostatni se daji vypnout: SSLProtocol -all +TLSv1 A rovnez nastavit akceptovani pouze nejsilenjsiho sifrovani: SSLCipherSuite HIGH

Paranoici si pochopitelne muzou nastavit jednotlive sifry a minimalni velikost klice: SSLRequire %{SSL_CIPHER_U­SEKEYSIZE} >= 256 Ktere sifry mate k dispozici na strane serveru mozno zjistit takto: ./openssl ciphers -v

P.S.: k uspesnemu provozovani klientskych certifikatu je potreba mit apache 1.3 nebo 2.2. Verze apache 2.0 ma neopravenou chybu (dnes uz spis ficuru) pri prijimani POST pozadavku, ktera se projevi odmitnutim/spad­nutim ssl spojeni – a tudiz na nejakou vaznejsi palikaci nejde pouzit (aspon to tak bylo, pokud uz ten patch dali konecne i do 2.0 tak me opravte).

„Ak je privátny kľúč chránený heslom, je potrebné ho zadávať iba pri štarte resp. reštarte daemona.“

Apache si take umi heslo zjistit sam pustenim externiho programu, kde jako parametr mu posila servername:port a pak na stdout ocekava heslo ke klici. Viz: SSLPassPhraseDialog

taky by stálo za to říci, že do common name se dává FQDN stroje. ne pouze hostname. POkud má server více jmen nebo aliasů, používá se také atribut subjectAltName, kde se jako DNS:name, nebo IP:x.x.x.x zadají další záznamy.

pokud totiž při autentizaci nesedí jméno serveru na který se obracíte s tím co je napsáno v certifikátu, zobrazí prohlížeč varování. Také myslím, že dataEncipherment v keyUsage není pro autentizaci třeba.

V současnosti se vůbec FQDN nedoporučuje dávat do CN a místo něj se dává textový popis určený člověku („Webový server společnosti První omezená“). Mnohé autority ani jiné certifikáty už nevydávají. Je to proto, že člověku je v podstatě jedno, jaké URL má daná služba.

Ano, pak ale je dobré uvést fqdn stroje do subjectAltName. Jinak to bude „řvát“. Uživatele to možná nezajímá, browser, nebo aplikaci při ssl handshake však ano. To jméno tam není kvůli uživateli.

Presne tak. Reverze IPcka se kontroluje.

Chválím, výbornej článek v češtině na SSL/TLS.

Zrovna nedavno jsem si s tim hral a docela uzitecne informace jsou treba i v tomto serialu: http://www.root.cz/…-na-openssl/

Tohle by me taky docela zajimalo, hlavne jestli Apache (nebo nejaky jeho modul) umi ziskavat CRL automaticky z CDP, ktere(a) je(jsou) v certifikatu. Aby se nemuseli stahovat nejakym externim skriptem.

odvolání platnosti certifikátu není věcí apache. to je věc certifikační autority. mod_ssl je možné nastavit, aby kontroloval certifikáty dle revokačního seznamu (to znamená odmítal pokusy o autentizaci zneplatněným certifikátem).

direktivou SSLCARevocationPath modulu řeknete kde najde seznam zneplatněných certifikátů. ten musíte pravidelně aktualizovat např. skriptem v cronu.

týká se to samozřejmě pouze certifkátů, které byly zneplatněny např. z důvodu kompromitace klíče. certifikáty, kterým vypršela časová platnost v revokačním seznamu nejsou. ty jsou modulem odmítány automaticky v rámci základní kontroly platnosti ( kontrola platnosti notBefore & notAfter, kontrola podpisu CA …).

ale to je snad jasné. :)

Copak v tý SSLCARevocationPath neni možný použít rovnou URL adresu CRL?

Víš jak by to dlouho trvalo, kdyby se při každým dotazu na server stahoval CLR?

Umí Apache vybírat k virtuálním HTTPS serverům serverový certifikát podle rozšířeného TLS požadavku klienta (RFC 3546)? Nechce autor napsat pokračování na toto téma?

V podstatě jde o to, že při masivním HTTPS hostingu je nesmyslné vydávat certifikát rozšířený o nové subjectAltName. Navíc zákazník by mohl chtít vlastní certifikát.

HTTPS klient si pak při sestavování TLS řekne, se kterým FQDN chce mluvit a server vybere správný certifikát. Takže je možné mít více HTTPS serverů na stejné TCP adrese každý s jiným certifikátem.

http://en.gentoo-wiki.com/…irtual_Hosts

dat do subjectAltName všechny jména pod kterými je možné na server dosáhnout, tedy fqdn všech virtuálů. To ale není vhodné, pokud poskytuješ hosting. Dá se to použít pokud těch virtuál máš pár. Být tebou, vydám každému virtuálu vlastní certifikát.

Ahoj,

S vidanim certifikatov nie je problem, ale je mozne v apache pouzivat viac certifikavot naraz?

Pokial viem, tak so SSLv3 nemozes na jednom sockete (IP:PORT) prevadzkovat viac virtualhostov kvoli tomu, ze SSL sa nachadza medzi transportnou a aplikacnou vrstvou. Kym server nenadviaze s klientom SSL spojenie nemoze zistit z klientskeho dotazu (aplikacna vrstva) na aku URL pristupuje. Rieseni tohto obmedzenia je viacero: mozes napriklad pridavat dalsie IP adresy a pustat virtualhost s inym certifikatom na kazdej z nich, mozes vyuzit dalsie porty na jednej IP adrese (pouzivatel ale bude musiet v URL tento port uviest) alebo ako uz bolo uvedene vyssie da sa vydat jeden certifikat, ktory bude obsahovat v rozsireni subjectAlterna­tiveName FQDN vsetkych obsluhovanych webov.

Pozri sa vsak aj na link uvedeny vyssie v diskusii – http://en.gentoo-wiki.com/…irtual_Hosts – kde sa pise, ze TLS 1.0 uz podporuje aj stav, ked klient pri nadvazovani SSL spojenia zasle serveru informaciu na aky hostname pristupuje a web server podla toho moze zvolit virtualhost (a certifikat), ktorym klienta obsluzi. Na uvedenej adrese mas aj priklad konfiguracie pre Apache s mod_ssl. Viem si vsak predstavit, ze spolocnosti poskytujuce hosting toto riesenie nebudu chciet pouzit kedze napriklad (bohuzial stale pouzivany) IE6 TLS 1.0 nepodporuje.

da sa vyuzit protocol upgrade v ramci nesifrovaneho HTTP (http://www.ietf.orgrfc/rfc2817.txt), ale v praxi som sa s tym nestretol. ide prakticky o nieco podobne ako STARTTLS v ramci SMTP…

pre uri schemu https sa da vyuzit Server Name Indication.