Minden nagyobb gyártó beállt a Let's Encrypt mögé

Titkosítás, biztonság, privát szféra

A Microsoft közvetlen támogatásával lett teljes a kép. A támogatók közt van a Microsoft, Google, Apple, Mozilla, Oracle és Blackberry. Részletek itt.

( apostroph3 | 2018. 08. 07., k – 08:51 )

ha az m$ benne van, akkor egy v. több hátsóajtó is benne van.

( NevemTeve | 2018. 08. 07., k – 09:04 )

Szabad ezt úgy értelmeznem, hogy ma már bárkinek lehet olyan tanúsítványa, ami gyakorlatilag nem tanúsít semmit, viszont ingyenes, és nem lesz tőle piros/áthúzott lakat a felhasználó böngészőjében?

Facebook csalok pl. eloszeretettel hasznalnak let's encrypt tanusitvanyokat megteveszto boltok keszitesehez, ahol szerencsetlen felhazsnalok elkolthetik a penzt. A legtobb ilyen felhasznalo biztonsagban erzi magat ha ott a lakat es nem nez mondjuk whois recordot, hogy csak ket napja regisztraltak be az "adidas.store" webshopot, ahol minden 70%-os kiarusitassal megy.

De lehet, nem tudok semmit sem a HTTPS-rol.

DV cert. Azaz a certet kibocsátó azt nézi meg, hogy a www.mexivtad.tld-re kért cert igénylője a www.mexivtad.tld alatt el tud-e helyezni egy általa megadott információt. Csalópista el tud ott helyezni egy fájlt (merthogy az ő tárhelyére mutat a domain), úgyhogy megkapja a certet, hiszen valóban az kérte, aki a domain alatti tartalmat képes kontrollálni.
Az a felhasnzáló meg, aki a réjbenofficist0re.store oldalra ellátogat, és mindenféle kételkedés nélkül vásárol, az... Mondjuk úgy, jelentősebb edukációra szorul internet használat tekintetében.

arrol nem is beszelve, hogyha beleolt penzt, hogy csinaljon kamu weboldalt, hostolja egy serveren, stb, akkor az 50$ ssl cert sem volt nagy akadaly. most csak ebbol az 50$-bol lett "0$-os" kiadas. meg persze nagyonhasonlonevu domainhez volt nehez certet venni (pl visszadobta a a apple.shop akartal kerni), most a lse-nel nem tudom van-e valami ellenorzes ez ugyben.

--
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!

Nem a Let's encrypt, hanem a DV cert, és nem a dns-re bízza a dolgot, hanem arra, hogy az adott domainen lévő tartalom módosításának a képességét tanusítja, és a cert használatával biztosítottá válik, hogy harmadik fél (olyan, aki a kiszolgálói oldalon nem mókolhatja a tartalmat) út közben sem fogja tudni módosítani azt.
A DV cert röviden arról szól, hogy "igen, az a tartalom, amit nézel, az a tanusított domainről, módosítás nélkül érkezik a böngésződbe."

Igen. De - lásd a szál korábbi postjait - valahol a domain regisztrátor feladata, hogy megakadályozza a megtévesztő nevű domainek létrehozását. (lásd az említett "adidas.store" webshop).

Ha meg már van egy domainem (és jogosan az enyém, ha beregisztrálták), milyen alapon tagadják meg tőlem, hogy az adott DNS névre kérjek egy tanúsítványt?

"valahol a domain regisztrátor feladata, hogy megakadályozza a megtévesztő nevű domainek létrehozását"

És hol a határ a megtévesztő domain és a legális domain között? Miért pont ott van? Vagy parkoltatni legális, hátha megveszi majd valaki később? :)

--
https://iotguru.live

Ne erts felre senki sem mondta, hogy az SSL vagy a Let's encrypt rossz dolog lenne, csak arra vilagitottunk ra, hogy ez totalisan nem jelenti azt, hogy "biztonsagban vagyok", amit viszont kicsit talan allitani akar.

Sajnos megoldhatatlan problema jelenleg az, hogy valaki ne regisztraljon be kethetente *.store oldalakat, amiket egy webcrawler script dob ossze az eredetirol ollozva a tartalmat csalas miatt es ne kapjon arra tanusitvanyt.
Az egy hozadeka a let's encrypt egyszerusegenek es nagyszeruesegenek, hogy a fent emlitett csaloknak tok jol hasznalhato. Ettol meg nem rossz, ugyanug ahogy a konyhakes sem, megis jo sokan olnek vele.

Nem tudom, hogy lehetne a fenti problemat megoldani, ugyanugy ahogy a konyhakes hasnalatahoz sem gondolom, hogy jogositvany kelelene, meg erkolcsi bizonyitvany.

Amugy nekem ismerosom meselte (facebook dolgozo, support), hogy a facebook-on terjengo .store oldalak szinte mindegyike let's encrypt-es. Es hogy a szamuk iszonyatos mertekben megnott az utobbi idoben. Azt mar csak en dedukaltam ki, hogy azert mert a let's encyropt-el konnyebb nekik doglozni. De siman lehet, hogy nem igy van.
Az viszont biztos, hogy csomoan a zold lakat miatt biznak az ilyen oldalakban es nem fognak whoist nezni ha a lakat szepen zoldul.

"Sajnos megoldhatatlan problema jelenleg az, hogy valaki ne regisztraljon be kethetente *.store oldalakat, amiket egy webcrawler script dob ossze az eredetirol ollozva a tartalmat csalas miatt es ne kapjon arra tanusitvanyt."

Ez akkor is így volt, amikor csak EV tanúsítványok voltak... kicsit nehezebb volt, most alacsonyabb a küszöb, de ezt a küszöböt nem a Let's Encrypt tette alacsonyra, hanem a DV.

"Az viszont biztos, hogy csomoan a zold lakat miatt biznak az ilyen oldalakban es nem fognak whoist nezni ha a lakat szepen zoldul."

A lófaszt. Akik ezeknek bedőlnek, nem néznek semmilyen lakatot, nemhogy a színét... ha húsz vörösen villogó "vigyázz, ez egy csaló oldal" felugró ablakban kell okét nyomni, akkor húsz felugró ablakban fognak okét nyomni, hogy megvehessék az áhított szerszámkészletet 20 dollárért, aminek egyébként 2000 dollár lenne az ára. Az okosabbja előbb rákérdez egy csoportban, hogy igaz-e, a kevésbé okos ezek után a többiek intelme ellenére megpróbál rendelni, mert hátha mégis igaz, a balfasz pedig rendelni fog, mert ilyen bulit nem lehet kihagyni.

--
https://iotguru.live

"gyakorlatilag nem tanúsít semmit, viszont ingyenes" vs. "ezt a kommentet szabad úgy értelmezni, hogy nem tudsz semmit a HTTPS-ről"

Na en erre reagaltam egy peldaval, ami alatamasztja az elso hozzaszolast. Hogy a facebook-on hogy terjednek ezek a boltok es kit szivatnak meg engem meg nem erdekel. O bajuk. Edukacio hianyaval egyutt. Leszarom.

Lasd lejjebb, ahol megadtam azt a domain regisztartort is, ahol elszaporodtak az ilyen altalad is emlitett bejegyzesek. :D

+1 Cloudflare-nek van saját aláíró certje, és front-end proxyként bármilyen site-hoz generál röptében, valid ssl certet, mellesleg úgy, hogy a cloudflare és a géped között marad a plain kommunikáció.
Ennyit a "biztonságról". Placebo security.
--
"Sose a gép a hülye."

De, placebo, mert a cloudflare mindenre ad szemrebbenés nélkül valid certet, plusz a jelszavad meg a bankkártyád adatai a cloudflaretől a szerverig ugyanúgy átcsoszognak plaintextbe.

Lehet, de ez a kliens szempontjából teljesen mindegy, mert felé nem látszik, azaz az előző esetet nézve neki fogalma nincs arról, hogy a háttérbe mi megy.
--
"Sose a gép a hülye."

Mindenre? Igen, miután a domained hozzáadtad a CF-hez, és megerősítetted DNS-sel, mint bármilyen DV certet.

A jelszavad meg a bankkártyád a CF-től a szerverig akkor csorognak át, ha nem állítasz SSL-t a kettő közé, de a kettő közti kommunikációt jelentősen nehezebb MITM-elni, mint a user-CF köztit.

Az eddigiekhez képest max az ingyenességben hozott változást a let's encrypt.

Illetve abban sem, hiszen ha van valami sebezhetőség XY certtel "védett" húdehűha komoly, zöld lakatos oldalon, hekker jóska pontosan azt hostol a cert alatt, amit csak akar, ez így volt mindig is. Phishing oldallal volt is már dolgom, ami pontosan ezt csinálta. Himihumi egészségügyi cég oldalán volt sebezhetőség, amin keresztül hősünk tudott csinálni saját aloldalt, ami egy magyar weboldal bankkártya adatokat bekérő oldalának álcázta magát. Valid(nak tűnő) címről jött mailben a spam, hogy ZW kedvezményt kapsz, ha most ide kattintva megrendeled a terméket. Átlag netproli belekattint, ott a zöld lakat, örül, fizet, mindenki boldog. Egy ideig.

A cert lopásokat, kelet-ázsiai dzsunka certeket már csak így lábjegyzetben fűzném hozzá a témához.

Ennyit a nagy zöld lakat mítoszról, amit most majd jól tönkretesz a let's encrypt.

Én nem igazán értem ezt a csaló témát - nem mindegy, ki állítja ki nekik a certet?

Idézet a LetEncrypt FAQ-ból:

"Let’s Encrypt offers Domain Validation (DV) certificates. We do not offer Organization Validation (OV) or Extended Validation (EV) primarily because we cannot automate issuance for those types of certificates." (kiemelés tőlem).

Amennyire én tudom, az összes "nagy" CA a DV certet úgy adja, ahogy a LE. IMHO tök mindegy, milyen DV certet tesznek ki a csalók, ha GoDaddy cert lenne, attól még ugyanúgy csaló lenne, csak elköltött volna 20 USD-t, és 1 évig élne a cert...

Számára ez egy üzlet. Az nem nagyon szokott összejönni, hogy valaki befektetés nélkül lesz sikeres. Beleöl néhány órát/napot, hogy elkészítse a webshopját. Ehhez képest a $20 már elhanyagolható.

Nagyon sok kezdő vállalkozó (a legális is!) úgy hiszi, hogy van egy jó ötlete és minden befektetés nélkül dőlni fog hozzá a lé. Ezek a vállalkozások általában nem sokáig működnek.

Spec. nem a 20USD-ről (vagy legyen 50, tök mindegy) van szó.

Arról van szó, hogy mindegy, hogy a cert a LetsEncrypt által lett kiállítva, vagy XY más CA által. Ha Domain Validated (DV), akkor "ennyit is ér".

Tök felesleges nevesíteni az LE-t.

(Egyébként mókás az az "összefüggés", hogy "bejon neki tobb ezer dollar" vs. "Miert fizetne 20$-t egy evre" ill "Miert baszna el a hasznat". :))

( dyra | 2018. 08. 07., k – 12:50 )

Nem tudom mi volt a céljuk az SSL tolásával de sikerült csinálni egy full átláthatatlan piacot tonna SSL certifikációt áruló céggel. És még van, hogy a telepítése se sima liba. Frankó. Hogy a témához is hozzászóljak. Használom a Let’s Encrypt működik elégedett vagyok vele. De mikor a múltkor az egyik általam üzemeltetett étterem honlapjára telepítettem többször megkérdeztem magam, full statikus html az egész mi a francnak kell a https? No mind.

--
honlapom http://dyra.eu/

Annak tunik, de a rosszindulatu JS kodhoz semmi koze nincs annak, hogy http, http-n html + script tag inject vagy https az endpoint. A valosagban ez a fajta MITM talan az egyik legritkabb valoban kihasznalt malicious JS code execution tipus.

Mikozben malvertising siman atmegy https-en.

A semminel tobbet er, az teny. de kb. -221-rol -219-re emeled a biztonsagi szintet.

"full statikus html az egész mi a francnak kell a https"

Pölö például azért, hogy a szolgáltatód ne tudja újrakódolni a képeket, ne tudjon agresszíven gyorstárazni... Netflix tért át azért HTTPS-re, mert akkor a szolgáltatóék nem tudják a jó minőségű videót újrakódolni szar minőségű videóra, ami miatt aztán a Netflix-nél verték az asztalt. Meg aztán statikus oldal esetén sincs köze a szolgáltatónak ahhoz, hogy konkrétan mi a statikus tartalom.

Legálisan ez az internetszolgáltató (ha jól értem).
És ha _Franko_ hozzászólását jól értelmezem, akkor ha https-en keresztül megy a történet, akkor az internetszolgáltató (legális úton) nem tudja, hogy mit tölt le az adott oldal, így nem tud gyorstárazni se (vagy pl. butítani a videót).

/Bocs, de az ilyen irányú tudás, amire biztosan tudok alapozni, az kb. ott kezdődik, hogy a házamba bejön az internetkábel. Néhány dolgot "házon kívül" is tudok, de az igen elenyésző - legalábbis a ti tudásotokhoz képest. Érdekelne a dolog, de valahogy sose visz rá a lélek, hogy elkezdjek ilyen irányú irományból okosodni./

"Legálisan ez az internetszolgáltató (ha jól értem)."

Neked van egy szolgáltatód. A szolgáltatódnak is van szolgáltatója. Egy egész hálózat szolgáltat neked mindenféle minőségben. Általában tucatnyi szereplő van közted és a szerver között. És az a legenyhébb beavatkozás, hogy a képeket/videókat újratömörítik nagyobb veszteséggel vagy az elérendő tartalom típusa szerint priorizálnak. Vagy ugye saját cache szolgálja ki a kérést, ami esetleg jóval lassabb, mint a szerver, a weboldal fejlesztői pedig vakarják a fejüket, hogy mitől vannak bizonyos ügyfeleknek panaszaik. Egy csomó ilyen problémát megold a HTTPS protokoll és okoz más problémákat.

Hm. Gondolom, a cache-t azért csinálják, hogy a sávszélességet ne zabálja ugyanaz a kép ugyanarról az oldalról százezerszer, így az ügyfelek kéréseit (összességében) gyorsabban tudják kiszolgálni.
Lehet, hogy naív vagyok, de ha a tartalom valóban statikus, akkor ez akár még jó is lehet - a CDN-ek lényege is ilyesmi.

és okoz más problémákat
Miket? Gondolom, az átlag felhasználó számítógépe már olyan sebességgel bír, hogy az esetleges lassulást nem veszi észre (vagy eleve nagyságrendekkel több ideig tart letölteni, mint a https használata miatti időnövekedés).

"Gondolom, a cache-t azért csinálják, hogy a sávszélességet ne zabálja ugyanaz a kép ugyanarról az oldalról százezerszer, így az ügyfelek kéréseit (összességében) gyorsabban tudják kiszolgálni."

Igen. A probléma az, amikor ezt nem jól csinálják. Nehéz eldönteni, hogy egy tartalom mikor és meddig tárolható anélkül, hogy a szerver erről tudomást szerezne. Ha frissül a szerveren a tartalom, akkor inkonzisztens lehet a böngészőben a tartalom, mert ami cache-ben volt, az a régi tartalom, ami nem volt benne, az meg az új. És időnként a statikus oldalak is frissülnek, olyan statikus oldal nem igazán van, ami évek óta statikus.

A CDN is ilyen, de a CDN kontrollálható a weboldal üzemeltetői által. A böngésző kontrollálható a felhasználó által. A kettőjük közötti csövet a szolgáltatók szeretnék okosítani, a két végpont viszont azt szeretné, ha az egy cső lenne: pont az jönne ki belőle, amit a másik végén beletettek.

A HTTPS nem a lassulással okoz problémát, mert a handshake a lassú, utána már szimmetrikus kulcsok vannak, az gyors... ha nincs beállítva jó keep alive érték, akkor viszont problémák lesznek. És vannak egyéb mellékhatásai, amelyek részben abból adódnak, hogy nem látni bele a protokollba. Például ugye ilyen a cache hiánya. Az ember áttér HTTP protokollról HTTPS protokollra és hirtelen többszöröse lesz a forgalma, mert kiesnek az eddigi transzparens cache rétegek. Erre fel kell készülni, vagy bővíteni kell vagy pedig CDN-t beüzemelni.

( uid_395 v | 2018. 08. 07., k – 19:50 )

Visszaolvasgatva a hozzászólásokat, ahogy azt az előző "Chrome mostantól nem biztonságosnak jelöli a http-t topic" ban kifejtettem.

Ez az egész egy bullshit lesz. Pont azért, mert a böngészők elkezdik majd nagyban "ződ jellel" kommunikálni a siteokat, mert hát https, az egy biztonságos oldal!!! de jó !

Ez baszottul félrevezető lesz - már most is az - , de a későbbiekben ha a chrome a sima http-t így jelöli majd meg hogy "nem biztonságos" akkor bőven sokkal inkább félreérthető lesz...

nem nekünk akik tudjuk hogy mi az SSL hogy is műxik, stb... A sima usernek. ujuj http aszonta nem biztonságos. ujuj itt egy ZÖLD jel! ez biztonságos!

Ez a baj ezzel ... :/

De fixme.

ps.: félreértés ne essék nem az SSL / https ellen vagyok .. magam is használok letsencryptet szerveren, routeren, stb.

Ha nem írna ki semmit a böngésző, sőt még zöld lakat se lenne, akkor sem lenne jobb a helyzet. Így viszont azok, akik veszik a fáradtságot, hogy megnézzék mit jelentenek ezek a jelzések, azok majd tudják helyesen értelmezni.

Hogy legyen autós hasonlat is :-)
Ha valaki úgy ül be az autóba (vezetni), hogy fogalma sincs a KRESZ-ről, az valószínűleg nagyon gyorsan balesetet fok okozni. De erről nem a KRESZ tehet, nem azt kell hibáztatni.

nem jó az autós hasonlat, mert ott senki nem mondja neked hogy bizony a http (autó kresz fogalom nélkül) nem biztonságos, de ha zöld vagy és ismered a kreszt, akkor már bizony az! mert tudsz mindent.

Félrevezetést :( mmint a chromenak a szarja hogy http -> nem biztonságos | https meg kurvabiztonságos és az a jó. Egyszeri user azt nézi mi a zöld.

Nincs olyan, hogy egy hasonlat minden szempontból megfelel az alapesetnek. Csak abból a szempontból kell „jónak” lennie, amire fel szeretnénk hívni a figyelmet.

Most arra akartam utalni, hogy használatba veszel egy „eszközt”, aminek a használati szabályait, esetleg a működését sem ismered. Ilyenkor szinte borítékolható a kudarc, vagy a kár.

Ha már a hasonlatok jóságán lovagolunk: az autó létezhet kresz nélkül is, mint ahogy a kezdeti időkben így is volt. Aztán az első szabályok egyike az volt, hogy egy gyalogosnak zászlóval a kezében kellett mennie az autó előtt, ezzel felhívva a figyelmet a veszélyre. Azonban a http/https-nek semmi értelme internet nélkül. Tehát az autó és a http/https között nem húzhatunk párhuzamot. Én az autóvezetés és az internet használata közötti hasonlóságra hívtam fel a figyelmet.

( Hiena v | 2018. 08. 07., k – 21:38 )

Oh, noice!
Gondolom, ez jelzés akar lenni a különféle szakhatóságok felé, hogy náluk lehet bejelentkezni a kulcsokért...
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Neem, ez itt két külön pályás játék. Egyik oldalon felszopás a techcégek felé, hogy mindenki csakis egy és kizárólagos cert-et használjon, hogy legyen eladható infótömeg. A másik oldalon a szakhatóságok és egyéb életformák felé az üzenet, hogy megfelelő apróért "véletlenül" kikerül pár kulcs. (Természetesen n+1 napal később, minden kiderül és új kulcsok lesznek kiadva...)
--
"Maradt még 2 kB-om. Teszek bele egy TCP-IP stacket és egy bootlogót. "

Ha nem nehézpályás a target, akkor nem kell ilyenekkel bohóckodni. A "szakhatóság" valamelyik másik "saját" vagy "közeli" CA segítségével előállít egy számára megfelelő "trusted" tanúsítványt és MITM beékelődik a forgalomba. A böngészők/levelezők/alkalmazások jórésze úgyse vizsgálja, hogy korábban is ugyanaz a tanúsítványkiadó adta-e ki a certet, vagy nem, így könnyen kivitelezhető a támadás.

Természetesen ezek kiszűrésére jött létre a Certificate Pinning és mindenféle böngésző kiterjesztések, amelyek próbálják észrevenni, ha gyanús CA változás történik a domaineken a korábbiakhoz képest. A probléma viszont az, hogy a webes kiszolgálás annyira bonyolult manapság, hogy nehéz ezt kivitelezne széleskörűen. A Google néhány saját domainjére bekapcsolja az ellenőrzést a chrome böngészőjében, egy jópárra viszont már nem, amelyekre viszont szintén rengeteg hivatkozás történik mindenhonnan, így továbbra is meglehetősen sérülékeny az egész PKI koncepció.