Názory k článku
Vyzkoušejte si podporu nových certifikátů od Let’s Encrypt na test.vpsfree.cz

Nevím, mám Nexus 7, Android 4.4.2, prohlížeč Chrome a stránka bez odporu jede.

To je hodně zvláštní, někde bude háček. Protože jak vidíte ze screenshotu, nefunguje to správně ani na Androidu 6.

Takže buďto to není prohlížeč Chrome nebo je tam nějak ručně přidaný ten správný kořenový certifikát. Byl by nějaký obrázek?

Není to přece vázané na verzi Androidu, ale na aktualizace. Každý Android má snad 3 roky support na celý systém. Aktualizace root autorit je jen otázka balíčku FOTA. Je to Nexus, možná jeho aktualizace není zcela odbytá.

Týkat se to bude hlavně zařízení bez podpory, že má starý Android nemusí nic znamenat.

Nexus 7 je tablet o kus starší než Nexus 5, na kterém jsem to zkoušel. Na oficiálním Androidu 6 to nefunguje. Nevylujučuji, že má někdo novější neoficiální sestavení (třeba Cyanogen), kde to autor později doplnil.

Ne, mám tam normální Android od Googlu. Jedinou nestandardní věcí je, že je rootlý. Ale s certifikáty jsem nijak nemanipuloval.
Na ještě starším telefonu LG Optimus Black s Androidem 4.0.4 stránka už opravdu správně nefunguje.

Muj Chrome v Androidu 4.4.2 to taky ukazoval ok, vymazal jsem historii prohlizeni a na chvilku se odpojil od netu a nyni uz to ukazuje neplatny cert. Zkontroloval bych tedy, jaky certifikat a cim podepsany ma uzivatel aktualne pri prohlizeni, pokud mu to ukazuje, ze je cert ok. Neda se svitit - pokud nechci ztratit navstevniky (BFU), budu muset prejit na Zerossl nebo komercni alternativu. Test ve starem Androidu dopadl dobre. :-) https://zerossl.store

Oživil som Sony Xperia Active (Android 4.0.4), zabudovaný prehliadač ma na stránku vôbec nepustí (neponúka možnosť "som si vedomý rizika a chcem pokračovať") a Google Play nebeží, asi sa nedohodne starý klient so súčasným serverom, takže nič nedoinštalujem.
Ale toto je fakt starý telefón.

Na mobilu s KitKatem zmíněná stránka funguje v Chrome správně. Čili zachovejte klid.
Spíše vám možná bude chybět podpora určitých protokolů: TLS 1.3, SSL 3, SSL 2 třeba i TLS komprese.
Mám názor, že takové mobily se mají využít k jinému účelu než k surfování a nestrkat je rovnou do elektroodpadu. Existuje třeba Nintendo Kit, ale sám jsem se podivil co všechno různé apky se starým mobilem umí vytvořit.

Dobrý nápad s testovacou stránkou a vďaka za jej spustenie.

Ako jeden z kandidátov na problémy novými certifikátmi v budúcom roku sa javil aj MS Internet Explorer na Windows 7 SP1, keďže používa systémovú certificate store a v tej sa ISRG Root X1 nenachádza. Viď rfc6797 section 8.4.

Lenže: po otvorení stránky https://test.vpsfree.cz/ sa ISRG Root X1 zrazu objavil medzi Trusted Root Certification Authorities. Skúsil som na viacerých Windows 7, či ma oči neklamú.

Vie niekto, akým mechanizmom sa ISRG Root X1 dostal do certificate store?

Možno má MS nejakú službu, na ktorú sa obráti IE a dostane čerstvú informáciu o root certifikátoch. Ak IE pridal nový certifikát "svojvoľne", len na základe údajov zo stránky test.vpsfee.cz, to by bol pekný "průser".

To dělá Windows normálně. Před pár lety jsme řešili problém, že na čerstvě nainstalovaných Win7 se digitální podpis našeho .exe tváří jako nedůvěryhodný, po navštívení našeho webu je ten podpis již v pořádku. Windows si totiž stáhly nové kořeny důvěry.

Browser nic nepřidává svévolně, tady je kolem toho článek: http://www.herongyang.com/PKI/IE-10-Windows-Automatic-Root-Update-Mechanism.html

24. 11. 2020, 14:01 editováno autorem komentáře

Asi mi něco uchází, ale předpokládal bych, že řešením by bylo do telefonu kořenový certifikát doplnit. Řešení s výměnou telefonu je, jako by mi nešlo na autorádiu naladit nějakou stanici, tak bych staré auto vyhodil a koupil nové s autorádiem, kde kýžená stanice již naladit jde.

Nie na všetkých zariadeniach taká možnosť je. Napr. na tej starej Sony Xperia Active (Android 4.0.4) som takú možnosť v GUI nenašiel, dali sa iba vyhodiť certifikáty, ktorým nechcem dôverovať (dali sa odškrtnúť).

Na Androide 8.1 je v nastaveniach "Install certificates from SD card", ale trvalo mi, kým som to našiel (a to som vedel, čo hľadám).

To je šystém jak noha.

Dělal jsem to na dvou tabletech Lenovo (Android 5 a 6), měli jsme firemní CA. Problém to byl a nebyl: samotná instalace šla celkem snadno, ale podmínkou bylo, mít zaheslované zařízení. To BFU často nemají, u tabletu bez snímače otisků jsem po tom netoužil ani já, ale musel jsem to zkousnout.

A když se heslo zneaktivní, udělá to co?

Pokud si vzpomínám, jak jednou zapnete ochranu heslem/gestem, už to vypnout nejde. Ale neověřím, oba tablety už skončily v křemíkovém nebi (po záruce uhnilé eMMC a tak).

No, problém je v tom, že tohle vysvětlit BFU bude peklo. :D Navíc to nepřežije tovární nastavení systému a u některých verzí Androidu to vyvolá permanentně zobrazovanou lištu oznámení o tom, jakej je uživatel vocas, že ho vůbec napadne instalovat si vlastní certifikáty... A jak psali výše, ne každá verze a nadstavba Androidu to umí, páč výrobce občas napadne taková kravina, jako odstranit uživateli ze systému polovinu funkcí, aby ten jejich OS byl nečím výjimečnej.

Předpokládám, že spuštěním nějaké aplikace, která by certifikát doinstalovala, to nepůjde, protože se asi jedná o zápis do adresářů s omezeným přístupem, takže buďto to zvládá aplikace v systému, která ta práva má (v Lineage „nahrát z SD“), nebo nic.

No, nebo root... Na(ne)štěstí je to aspoň nějak chráněný, aby ti malware nemohl jen tak udělat MITM.

Ta analogie s autorádiem je velmi přesná: když nejde naladit Rádio DAB Praha, je třeba autorádio vyměnit za nové s podporou DAB+. Je pak otázka, jestli daný model auta podporuje výměnu pouze autorádia, nebo je autorádio integrální součástí interiéru a je tedy potřeba vyměnit celé auto, protože tenhle model už výrobce nevyrábí ani neservisuje.

Celá tahle certifikátová mašinerie mi přijde zbytečná. Proč není tlak na zavedení DNSSEC a následně DANE? Pak by na nedůležitých webech (například e-mimino.cz nebo root.cz) nebyly žádné certifikáty potřeba.

Dovolím si nesouhlasit. HTTPS by mělo být úplně všude, kde to jen trochu jde. DNSSEC sice vyřeší tu DNS část problému, ale samotné HTTP spojení může být kýmkoli na trase odposloucháváno a měněno. A taky že bude měněno. Na některých veřejných hotspotech v hotelech a restauracích vám do nešifrované komunikace automaticky (!) hodí reklamy, aby nemuseli provoz WiFi platit ze svého. Do HTTP se dá snáze vložit exploit nějaké zranitelnosti v JS nebo vykreslovacím enginu prohlížeče. Krom toho, nešifrované HTTP je snazší pro sledování, protože všichni na trase vidí veškerý provoz - HTTP GET požadavky - tedy část za lomítkem v URI; stahované skripty a obrázky, samotnou stránku, prostě všechno. Implementace HTTPS (pokud se vyvarujete nějakých základních blbých chyb, které dovolí použití triviálních útoků) tohle všechno vyřeší v podstatě automaticky.
https://web.dev/why-https-matters/
https://www.cloudflare.com/learning/ssl/why-use-https/
https://catcoent.com.au/why-https-matters-for-all-websites/
https://www.michalspacek.cz/zabezpeceni-prenosu-dat-na-webu-pianko
https://www.michalspacek.cz/potrebujete-mit-web-na-https
https://scotthelme.co.uk/still-think-you-dont-need-https/

To nerozporuji. HTTPS všude ano, ale bez certifikátové mafie, s otisky privátních klíčů v zabezpečeném DNS.

Aha, tak to se omlouvám, špatně jsem pochopil Váš komentář. V tom případě s vámi souhlasím...
Bohužel k DANE se asi jen tak nedostaneme, aby to mělo nějakou širokou podporu a implementaci mezi weby.

24. 11. 2020, 21:25 editováno autorem komentáře

"certifikatova mafie" od letsencrypt <3

Tak on měl pán asi předvším na mysli celý ten vo**r se vším okolo certifikátů - distribuce kořenových certů do softwaru koncových zařízení, nutnost důvěry v nějaké společnosti "stopro nevydáme certifikát tomu, komu nemáme", s tím spojené jejich hlídání tvůrci prohlížečů fcemi jako Certificate Transparency a CAA, hlídání platností leaf certů a u ACME nějaka občasná kontrola, že vše funguje jak má... No, je to děs. DANE je všestranně lepší, bohužel se skoro nepoužívá a tak nemá nikdo důvod upouštět od tohoto molochu jménem "řetěz důvěry" a prohlížeče se na nějaký (i podepsaný) záznam v DNS můžou vyprdnout. No, třeba se to někdy změní, kéž by.

24. 11. 2020, 22:42 editováno autorem komentáře

Ten mobilní Firefox taky nemusí být všelék. Mám tu starou čínu s Android 4.4.2, kde to funguje jenom ve Firefoxu. Problém je, že kvůli stáři telefonu je ten Firefox ve verzi 68.11.0. Novější verze už tak starý Android patrně nepodporují a Google Play mi už aktualizace Firefoxu nenabízí. Mám pocit, že s něčím podobným jsem se už setkal, když jsem starý tablet resetoval do továrního aplikaci a Google Play mi už neumožnil nainstalovat aplikaci, která v aktuální verzi už daný Android nepodporovala.

Je to tak, současná verze Firefoxu vyžaduje Android 5.0 a vyšší.

Nexus 4 android 5.1.1 a test stranka v chrome je ok. Neni problem ofiko romka.

24. 11. 2020, 21:06 editováno autorem komentáře

Nechci dělat flejm, ale proč je vůbec poslední roky takový tlak na HTTPS? Za 20+ let na síti jsem MIT útok osobně nikdy neviděl, a teď se možná pletu, ale komunikace je zašifrovaná jen v jednom směru, když se znalostí veřejného klíče můžu číst před klientem i s HTTPS, ne? Vzhledem k tomu, že díky frontend frameworkům běhá obsah často oběma směry stejný, uvidím v podstatě i značnou část opačné komunikace. Není v tom trocha paranoie, když to dekádu fungovalo i bez HTTPS? Neříkám v případě kritických systémů, ale nějaký statický web s pejskem... o mi uniká?

Tak to si mel budto stesti, nebo sis toho jen nevsiml.

Sifrovana komunikace probiha obousmerne. Prohlizec si vygeneruje vlastni klic a jeho verejnou cast posle na cilovy server behem handshake.

Tak s tím handshakem jsem to nevěděl, dík!

Jinak zarnym prikladem MitM utoku jsou ruzne captive portaly na verejnych wifi, letere te nikam nepusti, dokud jim neodkliknes pravidla nebo nedas email. S tim ses uz musel nekde setkat. Nebo jeste webshield v antivirech, ktery obcas nadela paseku v certifikatech.

24. 11. 2020, 22:42 editováno autorem komentáře

Na veřejné wifi z principu nelezu, ale ty webshieldy, to je pravda.

Pokud jste takové útoky neviděl, pak asi dostatečně nesledujete bezpečnostní oblast. Únosy BGP, otrávení DNS keší, útoky na domácí routery, únosy DNS resolverů a spousta dalších podobných. Ty všechny jsou prvním krokem k MitM útoku. Správně nasazený DNSSEC a HTTPS vás ochrání před dalšími škodami. Pokud jako uživatel neuděláte hloupost a nestřelíte se do vlastní nohy. Správné postupy musí být zažité na obou stranách.

Komunikace je chráněná samozřejmě v obou směrech, jinak by to nedávalo smysl. Veřejný klíč se jmenuje veřejný, protože nedává útočníkovi žádné výhody a rozhodně mu neumožňuje sledovat komunikaci. Takové šifrování by bylo pro kočku.

Jak už bylo mnohokrát řečeno, HTTPS by mělo být všude. Už jen proto, že brání sledování a prokazatelně pomáhá v boji s cenzurou. Proč by měl mít někdo možnost sledovat, co si já někde čtu? Nebo proč by měl mít možnost to změnit? Nebo proč by měl mít možnost mi v tom bránit?

Myslel jsem to tak, že třeba útoků ransomware jsem fyzicky zaregistroval několi, ale MIT jen v literatuře.

K cenzuře: Jak si v tomto směru stojí snahy vecpat do komunikace "černé krabičky", nebo rovnou backdoor? Mámtrochu pocit, že tady taháme kratší konec provazu.

A děkuju za informace a poučení.

Vtip je právě v tom, že ty černé krabičky už tam někde dávno můžou být. Může je tam dát kdokoliv, kamkoliv. Můžou být v podobě falešné nebo upravené Wi-Fi v kavárně, může to být váš domácí router nebo napadené zařízení na střeše u poskytovatele. Musíte počítat s tím, že vaše komunikace může jít přes jakoukoliv zemi a jakékoliv zařízení, třeba i jen chybou v routingu. Do takové sítě nechcete posílat svá data v otevřené podobě. Hlavně: proč byste je někomu posílal, když nemusíte?

No máte pravdu, to uznávám. Ale třeba zrovna tady na rootu můžeme mít příjemný pocit z HTTPS, a jak na naše data/příspěvky nikdo nemůže, zatímco černá krabička je přímo u dat na serveru a nějaký šifrování ji vůbec nezajímá :-)

K tomu, co tu zaznělo, bych přidal ještě jedu věc. Jakmile je na výběr, zda HTTP nebo HTTPS, musí se lidé rozhodovat. Správce serveru se musí rozhodovat, zda je jeho web důležitý a má tam být HTTPS, nebo zda je nedůležitý a stačí HTTP. Úplně stejně se musí rozhodovat uživatel. Jenže jakmile necháte rozhodovat lidi, kteří problematice nerozumějí, budou se rozhodovat špatně. Není to ale jejich chyba. Navíc si to musí uživatel pořád hlídat. „Jdu do elektronického bankovnictví, musí to být přes HTTPS.“ Přičemž lidé jsou mimořádně špatní v hlídání toho, co bylo stokrát správně, jestli je to správně i po sto prvé. Zkrátka největší bezpečnostní díra oslabující HTTPS v prohlížeči je to, že prohlížeč podporuje i HTTP. K čemu ale to rozhodování je? Je z něj nějaký užitek? Je to jako kdybyste se každý den při odchodu z bytu rozhodoval, zda v bytu necháváte něco cenného a máte zamykat, nebo tam nenecháváte nic cenného a zamykat je zbytečné. Mnohem jednodušší je ale zamykat pokaždé, že.

Pak je tu ještě ta věc, že je zvláštní provozovat web na HTTP, protože je nedůležitý a vlastně nevadí, když tam někdo změní obsah. Pokud je jedno, jaký je na tom webu obsah, je ten web asi zbytečný, ne? A že by se ten web nepokusil nikdo napadnout? Zobrazit tam nějakou reklamu, dát odkaz na malware, pokusit se využít bezpečnostní chybu v prohlížeči – to vše se vždy hodí.

Ta tvoja analogia nieje uplne super.

Problem nielen BFU je ten, ze jemu ani HTTPS nepomoze. To, ze niekde je HTTPS este neznamena, ze ide na to spravne el. bankovnictvo.
HTTPS je "len" o tom, ze su sifrovane data a po ceste k tebe ich "nikto" neprecita/nez­meni(ktovie, mozno ich aj precita. Neviem ako su na tom trojpismenove agentury, ci to nevedia prelomit alebo ci nemaju privatne kluce alebo maju pristup k endpointom na strane poskytovatela a potom cele HTTPS je na nic :) ). HTTPS nieje to zaruka, ze si na stranke, na korej chces byt a dostavas data, ktore chces dostavat. To by si si musel inym kanalom overovat ci si naozaj tam, kde si a to nerobia mozno ani paranoici. Overujes si v banke, ci je ten certifikat naozaj ich? A to pri kazdej zmene certifikatu? Vies kedy sa zmenil certifikat?
HTTPS lepsie zabezpecuje jednu cast z retazca.

Takze ten priklad so zamykanim domu nieje najlepsi. Lepsi priklad je posielanie listov/pohladnic. Ten obsah si moze cestou hocikto po trase kto pride s tym do kontaktu precitat, pozmenit. Presne ako pri HTTP.
Ani pri HTTP si ten obsah nemoze precitat hocitko ale len ten, kto ma pristup k trase.
Ten priklad z domom a zamykanim by bol dobry ak by sme sa bavili o endpoitoch ale my sa tu bavime o trase. HTTPS neriesi endpoity ale trasu.

Nieje zvlastne prevadzkovat web na HTTP rovnako ako nieje zvlastne posielat tie pohladnice, listy alebo aj kludne aj baliky, vlastne cokolvek postou/prepravnou spolocnostou klasickym sposobom v klasickych obalkach alebo kartonovych krabiciach.
Ak sa nepripajam na verejnu/nedove­rihodnu siet, tak riziko, ze mi niekto pozmeni data pri HTTP nieje zase tak brutalne velke, lebo pristup do trasy zase vela ludi nema.

Ten moj prispevok neznamena, ze som proti HTTPS. To nie, len to nieje vseliek

To, ze niekde je HTTPS este neznamena, ze ide na to spravne el. bankovnictvo.
To také nikdo netvrdil. Ale použití HTTP znamená, že o správné elektronické bankovnictví určitě nejde. A je to věc, kterou může snadno řešit prohlížeč.

Lepsi priklad je posielanie listov/pohladnic.
V příkladu šlo o to, jestli se mám pokaždé rozhodovat, zda použít nebezpečný postup nebo bezpečný, když náklady na to rozhodování jsou srovnatelné s použitím bezpečnějšího postupu. Jde přesně o to, co popisujete dál –řešíte, že někdy možná stačí HTTP. Příklad je o tom, že nemá smysl to řešit.

Prehliadac to jednoducho neriesi. Ako ma prehliadac ochrani pred podvodnymi strankami? HTTPS(nie prehliadac) obmeduje to, ze ztazuje moznost upravit obsah po ceste ale nevie zabezpecit to ci komunikujem s tym, co chcem a ci dostavam to, co chcem.
HTTPS ma svoje plusy a aj minusy, ktore ukazuje tato "afera", kde aj ked jeto HTTPS, tak to riesime, lebo ani to nieje dokonale.

Nie, ze niekedy mozno staci HTTP ale, ze HTTP tu ma miesto a je to regulerny protokol. To, ze niekto proti nemu broji neznamena, ze ho mame zahodit.
Tym padom to ma zmysel riesit ale nie na strane klienta ale na strane poskytovatela.
Ak ta sluzba to nepotrebuje(nieje tam ziadna pridana hodnota), tak preco by poskytovatel si nemohol vybrat HTTP?

Zkuste si někdy reálně zjistit, jaké šifry se používají v TLS 1.2/1.3. Mnohdy se používá AES, u jehož zrodu se počítalo s tím, aby v něm nebyl nějaký backdoor od třípísmenkové agentury. Na výměnu klíčů se dost často používá DH s eliptickými křivkami, u těch zatím taky nikdo neobjevil pořádný backdoor. Pokud poskytovatel nedá z ruky privátní klíč, NSA se do té komunikace fakt NEDOSTANE. To není vymyšlené tak, aby to poskytovalo falešný pocit bezpečí. Je to navržené tak, aby to bylo bezpečné. A je to bezpečné. A sice HTTPS není všelék, ale to není důvod, proč ho nepoužívat. HTTPS by mělo být všude. Tečka.

Já bych to trošinku upřesnil (i když to realitě odpovídá podstatně lépe, než oblíbené představy, jak NSA louská veškerou komunikaci). Všeobecně se má mezi odborníky za to, že NSA ví (i v kryptografii) víc, než je všeobecně známé. Ona také tajná služba, která by věděla jen to, co je veřejné, by byla trochu na houby. Takže možná znají nějaké slabiny, o kterých my ještě nevíme. Také mají k dispozici slušný výpočetní výkon. Takže reálné riziko, se kterým se počítá, je to, že by zvládli upočítat nějakou slabší šifru, která by podle našich znalostí měla být ještě bezpečná (ale už ne o moc).

Netvrdil bych tedy, že se NSA do komunikace nedostane, pokud nedá poskytovatel z ruky privátní klíč. Přidal bych k tomu ještě podmínky, že používá aktuálně doporučované šifry a protokoly a aktuální software.

Jinak s tím souhlasím – představa, že NSA rutinně louská komunikaci šifrovanou AES s rozumně dlouhými klíči, se nezakládá na žádných reálných informacích. A představa, že NSA donutí certifikační autoritu vydat falešný certifikát, vychází z neznalosti toho, je celé PKI funguje.

Malá kontroverzní nadsázka: Pokud máte nějaké staré zařízení bez updatů, prostě odklikněte neplatný certifikát a je to. Bezpečné to sice není, ale to neaktualizované zařízení asi není v bezpečí moc ani dnes…

Seriózně: Ano, samozřejmě záleží na kodeků útočníka a na způsobu používání. Ale zčásti tento problém pouze odkrývá skutečný stav věci, tedy že neaktualizované zařízení není bezpečné.

Len podotknem.

Skutocny stav je taky, ze ani aktualizovane zariadenie nieje bezpecne. Len ma osetrene uz verejne zname chyby :)

Absolutnu bezpecnost nikdy nedosiahneme, to je iluzia. Ta vzdy bude stat a padat na dovere v nieco alebo v niekoho.

To ano. Ale je rozdíl mezi tak nějak záplatovaným systémem a systémem, na který nejspíš bude za ty roky existovat hromada relativně snadno dostupných zranitelností.

Schválně jsem zkusil na prastarém neznačkovém tabletu s Androidem 4.0.4, a v obou nainstalovaných prohlížečích: Google Chrome a Opera Mini (u níž je zapnutá nějaká agresivní MITM komprese) testovací stránka jede bez problémů. Čím to je?

Ten testovací web může na některých starších Androidech být pořád ok nejspíš proto, že se ověří oproti DST Root CA X3 a ne proti ISRG Root X1. Intermediate certifikát Let's Encrypt X3 je "cross-signed", jsou to vlastně dva certifikáty se stejným veřejným klíčem a ověření je tak možné provést dvěma způsoby.

Viz např. výsledky testování pomocí SSL Labs, sekce Certification Paths a Android: jedna cesta končí (nebo začíná) u DST Root CA X3, druhá u ISRG Root X1

Proč to někomu jde a někomu ne může být třeba proto, že server neposílá ten jeden X3 intermediate certifikát (viz "extra download" v SSL Labs testu) a Chrome na Androidu si ho umí z adresy v rozšíření AIA (Authority Information Access) sám stáhnout až od verze 58. Některý browser ho ale zase může mít zapamatovaný z návštěvy jiného webu.

Pro přesnější vysvětlení by stačilo se podívat jak se snaží browser ověřovací cestu sestavit, možná by to mohlo být někde v detailech certifikátu, ale bohužel starší (a funkční) Android tu nemám po ruce.

Ta druhá cesta přestane fungovat nejpozději na konci září 2021, kdy expiruje DST Root CA X3. Aktuálně používaný X3 intermediate podepsaný DST Root CA X3 expiruje 17. března, nicméně platnost se bude "prodlužovat" vystavením nového "cross-signed" X3 s platností do 29. září 2021, den před koncem platnosti DST Root CA X3.

"Cross-signing" je ukázán např. na obrázcích na blogu Let's Encrypt o nových rootech.

Nemohl by to Google jednoduse vyresit vydanim aktualizace Google Chrome, pripade Google Play Services pro tyto stare telefony a certifikat tak pridat?
Kdyz i Microsoft parkrat opravil kriticke chyby ve Win XP i dlouho po skonceni podpory...

Prece jen nejde jen o jednotky procent Androidich zarizeni.

To Google pravděpodobně udělá. Ale není to 100% řešení, na nejstarších Androidech Chrome nejde nainstalovat, na o něco mladších se musel doinstalovávat ručně. Takže spousta uživatelů starších Androidů používá Android browser nebo ještě něco jiného.

Těch "nejstarších" androidů je co do podílu na trhu tak málo, že je dle mého názoru nemá smysl řešit. Největší problém - 30% zařízení s Androidem verze nižší než 7.1.1 - by tímto odpadl. Pokud ještě dneska někdo používá Jelly Bean nebo snad ještě starší, má už nejspíš dost často problém i s handshakem, protože řada serverů už TLS nižší než 1.2 vůbec nepodporuje (a je to IMHO dobře; odpadá tím několik problémů spojených například s downgrade útoky). Takže tam už je nějaká nedůvěra v root cert minoritní problém, páč se na něj v podstatě ani nedostane.

28. 11. 2020, 18:33 editováno autorem komentáře