Fórum Root.cz

Ostatní => O serveru Root.cz => Téma založeno: beer 17. 02. 2016, 10:49:51

Název: https://partner.root.cz
Přispěvatel: beer 17. 02. 2016, 10:49:51
(http://www.imgup.cz/images/2016/02/17/https-partner.root.cz.png)
 (https://partner.root.cz)
Citace
Při spojení s partner.root.cz nastala chyba, protože je používán neplatný bezpečnostní certifikát. Certifikát není důvěryhodný, protože jeho vydavatel je neznámý. Server patrně neposílá patřičné certifikáty zprostředkujících CA. Může být potřeba naimportovat dodatečný kořenový certifikát. Certifikát je platný pouze pro následující domény: *.affilbox.cz, affilbox.cz (Kód chyby: sec_error_unknown_issuer)

V době Let's encrypt byste mohli používat platný certifikát zabezpečení, nebo se jedná o Man In The Middle útok?
Název: Re:https://partner.root.cz
Přispěvatel: Petr Krčmář 17. 02. 2016, 11:45:09
Máme komerční certifikáty od StartSSL, tohle není problém. Potíž je, že ta subdoména běží u dodavatele toho affil systému a ten náš certifikát nemá a ani mít nemůže. Nemá to jednoduché řešení.
Název: Re:https://partner.root.cz
Přispěvatel: beer 17. 02. 2016, 12:47:32
a co přesměrovat subdoménu partner.root.cz třeba na https://partner.root.affilbox.cz?
Název: Re:https://partner.root.cz
Přispěvatel: i-PRESS 17. 02. 2016, 12:57:16
a co přesměrovat subdoménu partner.root.cz třeba na https://partner.root.affilbox.cz? (https://partner.root.affilbox.cz?)


Ano, affilbox má wildcard cert. A nebo prostě za 2 kila koupit nový certifikát, vygenerovat nový special privátní klíč a dát jej partnerovi. Nevím, takto se to řeší zcela běžně, ještě jsem se nesetkal s tím, že by měl někdo problém s umístěním obsahu jinde..


Jinak za komerční cert +1, nesmysly typu LE nechte dětem na blogísky..
Název: Re:https://partner.root.cz
Přispěvatel: Ondrej 17. 02. 2016, 14:25:36
Proc nesmysl? Naopak nesmysl je platit za certy duveryhodnosti typu overeni emailem, nebo vystavenim souboru na webu...
Jedinej problem s LE je ze oficialni ultilitka je silena, nastesti je hromada alternativ...
Název: Re:https://partner.root.cz
Přispěvatel: i-PRESS 17. 02. 2016, 14:35:38
Proč? Třeba kvůli krátké platnosti = nelze ji přidat na HSTS preload list. Cert se velmi často mění, což je problém i přišpendlení certifikátu do DNS (TLSA záznam). Kritická je také nemožnost revokace certifikátu.. Pokud mi uteče PK, bude platit po celý zbytek platnosti.. Atd..


Je to šílenost.
Název: Re:https://partner.root.cz
Přispěvatel: petr 17. 02. 2016, 18:52:49
hsts preload (https://www.chromium.org/hsts) nemá s platností certifikátu nic společného.
Název: Re:https://partner.root.cz
Přispěvatel: i-PRESS 17. 02. 2016, 19:00:38
hsts preload (https://www.chromium.org/hsts) nemá s platností certifikátu nic společného.


Čtěte pozorněji.. https://hstspreload.appspot.com/ uvádí jako jednu z podmínek:
Citace
Expiry must be at least eighteen weeks (10886400 seconds).


Tzn cert s 3 měsíční platností tam nikdy nedostanete.
Název: Re:https://partner.root.cz
Přispěvatel: Ondrej 17. 02. 2016, 21:32:42
Proč? Třeba kvůli krátké platnosti = nelze ji přidat na HSTS preload list. Cert se velmi často mění, což je problém i přišpendlení certifikátu do DNS (TLSA záznam). Kritická je také nemožnost revokace certifikátu.. Pokud mi uteče PK, bude platit po celý zbytek platnosti.. Atd..


Je to šílenost.
Proč by nešlo? Asi nemáš páru co HSTS dělá.
Revokace pochopitelně možná je.

To že se cert mění do 3 měsíců ti může bejt jedno, měl by si to mít nacronované, aby se script klidně i každej den ptal jestli na doménách xy není potřeba vyměnit cert a pokud ano, vyměnil je sám. Jistě má to svoje mouchy, ale na to běžné šifrování je to dobré a ve výsledném se ani pak nemusíš starat o prodlužování cerů, kde když máš víc domén tak je to docela oser. A pokud se něco podělá? LE upozorňuje pokud se blíží expirace certu, tak si toho všimneš v mejlu...
Název: Re:https://partner.root.cz
Přispěvatel: Ondrej 17. 02. 2016, 21:52:45
hsts preload (https://www.chromium.org/hsts) nemá s platností certifikátu nic společného.


Čtěte pozorněji.. https://hstspreload.appspot.com/ uvádí jako jednu z podmínek:
Citace
Expiry must be at least eighteen weeks (10886400 seconds).


Tzn cert s 3 měsíční platností tam nikdy nedostanete.
Pokud vím píše se tam že server musí posílat v hlavičce min Strict-Transport-Security: max-age=10886400 tj že po tuhle dobu prohlížeč bude vyžadovat  šifrovaný přenos, o minimální platnosti certu tam nic nevidím a btw poslal sem pomocí toho svůj web na schválení a jelikož to hlavičky před schválením kontroluje, pochybuji že by to prošlo kdyby tomu nevoněl cert kterej nemá tuhle platnost...
Název: Re:https://partner.root.cz
Přispěvatel: i-PRESS 17. 02. 2016, 21:57:38


Výměna certu mi jedno není, protože současně s tím musím předem změnit TTL u TLSA záznamu, pak jej nahradit a poté opět zvýšit pokud nechci nechat TTL nízké. U deníčku a interních služeb mi to je fuk, ale nechat do konfigurace produkčních serverů hrabat cizí utilitu mi přijde mimo.


Kdo si to nascriptovat chtěl, ten to má nascriptované už hromadu let sám, vždyť třeba API SSLS je primitivní a ten wget na stažení certifikátu si každý jistě už dobastlit zvládne. Takže to nic pokrokového nepřináší.


Myslím že pokud někomu nestojí jeho výtvor za 150 kaček ročně za certifikát, pak ať si používá co chce, protože moje cílovka to stejně asi nebude. Kromě ceny tedy LE nic zásadního nepřináší a přijít o možnost preloadu v Chrome a Opeře kvůli pár desetikorunám mi přijde zbytečné.
Název: Re:https://partner.root.cz
Přispěvatel: i-PRESS 17. 02. 2016, 22:13:42
Pokud vím píše se tam že server musí posílat v hlavičce min Strict-Transport-Security: max-age=10886400 tj že po tuhle dobu prohlížeč bude vyžadovat  šifrovaný přenos, o minimální platnosti certu tam nic nevidím


Cca půl roku zpátky jsem odesílal do PL i jeden ze svých webů kde cert měl platnost + 2 měsíce a skončil jsem na hlášce, že nelze přidat jestliže je platnost certifikátu chvíli před expirací. Jestli to je teď jinak nevím, neměl jsem zatím možnost zkoušet.


Každopádně stále trvá má nedůvěra k tomu, aby mi aplikace sahala do configu NGINXu. Pokud to někomu nevadí, nikomu to vymouvat nebudu, já mám ale tuto CA odstraněnu i z důvěryhodných autorit.
Název: Re:https://partner.root.cz
Přispěvatel: Petr Krčmář 17. 02. 2016, 22:34:51
Každopádně stále trvá má nedůvěra k tomu, aby mi aplikace sahala do configu NGINXu. Pokud to někomu nevadí, nikomu to vymouvat nebudu, já mám ale tuto CA odstraněnu i z důvěryhodných autorit.

Ona to samozřejmě nemusí dělat, popisoval jsem to ve svém článku (http://www.root.cz/clanky/let-s-encrypt-v-praxi-jak-jsem-presel-na-https/). Existuje celá řada klientů, většinu z nich konfigurace serveru nezajímá. Prostě jen zahájí komunikaci s autoritou, vygenerují klíče, které zatím nemají k dispozici, vystaví soubor v určeném adresáři a vysypou certifikát na disk. Jednoduché, stačí je jednou měsíčně spustit cronem.

Ani s TLSA není problém, do domény se prostě vystaví otisk veřejného klíče, který se mezi vydáváním certifikátu nemění. Takže ani tenhle argument není validní.

Jediným rozumným argumentem tedy může být: nemám tu autoritu rád a nebudu ji používat. Technicky s ní žádný problém není.
Název: Re:https://partner.root.cz
Přispěvatel: Ondrej 17. 02. 2016, 23:06:01
Tak uvidíme jestli mě web do https://hstspreload.appspot.com/ přijmou, ale řekl bych že jo, pak dám vědět.

Do konfigurace NGINXu si pochopitelně nikdo rozumnej šahat nenechá a není to ani potřeba, je jen potřeba do nějaké složky nasměrovat /.well-known kam ti nacronovanej script bude nahrávat potřebné pro ověření nadvlády nad serverem, script ti pak vyhodí cert, to je celé... Automatickej zásah do web serveru je pro BFU, ale upřímně řečeno BFU by neměl vůbec žádnej server provozovat.

Jak sem psal, oficiální script je podle mě prasárna, ale je jich naštěstí mraky, o pár řádcích například pythonu, perlu...
A za mě si tedy raději vygeneruju certifikát sám zadarmo, proč  bych měl platit někomu, je jedno kolik, za certifikáty s ověřením o proti nadvlády serveru, nebo emailu? Tohle mě přijde na hlavu postavenej byznys... Respektive zlatej důl.
Název: Re:https://partner.root.cz
Přispěvatel: Petr 18. 02. 2016, 09:03:25
Já už jsem svoje domény s certifikátem od Letsencrypt do HSTS Preload přidal. "Expiry must be at least eighteen weeks" se týká času v HSTS hlavičce. Ne času vypršení certifikátu.
Název: Re:https://partner.root.cz
Přispěvatel: Petr Krčmář 18. 02. 2016, 09:36:13
Přesně tak, s HSTS není nejmenší problém, stejně jako s TLSA nebo revokací. O Let's Encrypt mám přednášku za čtrnáct dní na InstallFestu a ještě přemýšlím, co všechno tam budu říkat. Ale tohle vlákno mi dost pomohlo nasměrovat myšlení na to, co je potřeba o LE ještě říct (kromě principu a klasických výhod/nevýhod).
Název: Re:https://partner.root.cz
Přispěvatel: Ondrej 19. 02. 2016, 08:53:19
BTW kdyby to někoho zajímalo:
Nasazovali jsem teď LE a pár lidí nám psalo že se jim stránky nezobrazují ve WinXP IE, Chrome a Opera. I tady je řešení: Ve Firefoxu LE na XP funguje!
Název: Re:https://partner.root.cz
Přispěvatel: i-PRESS 19. 02. 2016, 15:59:41

Ale tohle vlákno mi dost pomohlo nasměrovat myšlení na to, co je potřeba o LE ještě říct (kromě principu a klasických výhod/nevýhod).


Super, tak toho využiji a poprosil bych primárně zmínit 1 výhodou oproti "standardním CA". Je fajn, že již není kontrolována platnost samotného certifikátu u žádosti o zařazení na preload list, když jsem to před více než půl rokem zkoušel, ještě to tak bylo, tím tedy jedna velká nevýhoda padá. Celý princip CA je ale založen na důvěře a tu já k EV nemám, což je ale můj subjektivní názor.


Stále za mne platí "problém" s krátkou platností. Vím že to pro spoustu webů nemusí být kritické, ale když mám na VPS 6-8 mikroslužeb, každá na vlastní doméně/subdoméně a každou bych vyřešil pomocí LE, budu muset každé 2 týdny restartovat třeba webserver? A když takové servery mám 4? Nechat restart na aplikaci je nesmysl, to mi taky může reloadnout NGINX ve špičce a přijdu o stovky requestů, nemluvě o rozpadnutí WebSocket/MQTT spojení.


Já nechci LE hanit, mě nijak nevadí, mám sice partnerský účet u SSLS, ale certifikáty neprodávám, mám ho jen kvůli tomu že jich mám hodně a vyplatilo se mi si obnovování automatizovat pomocí API. Platnost komerčních certifikátů je ale až 3 roky, což mi usnadňuje i s tím spojený restart webserveru, který ani v tomto případě nenechávám dělat mojí aplikaci a pouze mi uloží do stacku požadavek na restart jakmile je cert připraven.


Netvrdím ale, že výhodu LE žádnou nemá, pouze že jsem na žádnou nenarazil. Pokud existuje něco co mne nenapadlo, rád změním názor. Zatím si stojím za tím, že na komerční služby určen není. Je tu ještě otázka nějaké garance. Standardní DV mi "ručí" do 5-10k USD, OV + EV až do cca 1.75M USD/transakci. U LE je to jak? Nikde jsem toto info nenašel..


Pokud jde o snadnou implementaci běžnými uživateli (což je dle mne také spíše na škodu), pak se jako přínos uvádí jejich aplikace. Ale to tu pro ty, kteří si těch pár řádků na API napsat nedokáží také existuje třeba v podobě https://encrypt.cz/ s ověřením emailem od SSLS.


Takže ať se na to koukám jak chci, stále nevidím žádné pozitivum (tím netvrdím že zde není), ale pouze negativa. Teď jde o to, zda by měl mít pro komerční produkt (bavím se třeba o eshopu, nikoliv službě pro vlastní potřeby) certifikát, který nic kromě úspory 90,- Kč (nejlevnější cert od SSLS) na rok nepřináší za cenu častějšího odpojování třeba mobilních apps při restartu, nemožností WildCard, atd...


Btw, když už o tom budete povídat, zajímalo by mě, jak je řešeno ad-hoc přidávání certifikátu v rámci SAN. Tedy use-case je takový, že mám sadu souvisejících služeb na různých doménách a aplikacích, před nimi stojí jako proxy nginx a chci tedy obhospadařovat tuto skupinu jedním certifikátem. Lze to nějak u LE jednoduše řešit?


Budu rád pokud na IF odpovědi padnou ;)