Emlékeztető: mostantól a Chrome a HTTP oldalakat nem biztonságosként jelöli

Hozzászólások

Szerintem meg dugják oda, ahova nem süt a nap. Vagy mostantól ingyé adja a google az SSL certet ? Költői kérdés, meg puffogás...

--
openSUSE 42.2 x86_64

Certbot-al kb percek alatt megvan.
Némely tárhely szolgáltatónál van kemény meló vele.
Pl van egy ismerős a mediatemple-nél, neki szoktam segíteni ezt azt. Pl legutóbb belőttem nekik oda a free ssl-t, hát minimum 20-30 perc volt. És 3 havonta valszeg így fog menni. De még az se annyira megerőltető, certbottal pedig lófax.

Oké, ez a Let's encrypt. Ha jól értettem (régebben) egy IP-hez, egy domain-hez egy kulcsot adtak. Most pedig azt látom, hogy "2 perc alatt" a python-certbot-apache csomaggal és barátaival egy IP-n több domainhez is lehet tanúsítványt szerezni. Nem félő, hogy a piszok drága tanúsítványokat áruló cégek csesztetni fogják a Let's encryptet?

A "Server Name Indication" (SNI) teszi lehetővé, hogy egy IP cím/port pároshoz több (tetszőleges számú) TLS/SSL tanúsítványt lehessen használni. Ez teljesen független a Let's Encrypt-től. Bármilyen CA-tól igényelhetsz tetszőleges számú tanúsítványt.

A Let's Encrypt a többi CA korábban is létező, domain-validált tanúsítványaival versenyzik. A dolog szabadáras, más CA is adhatja ingyen, és van is néhány CA, aki ad ingyenesen.

Mert akkor már vehetsz EV certet is akár és meg fog jelenni a cégneved is és az már aztán olyan húdebiztonságos (leszámítva, hogy az átlag usernek fogalma sincs, hogy mitől függ, hogy kinn van a cégnév és az mit jelent és hogy figyelnie kell fontosabb helyeken, hogy kinn legyen a cégnév... arról meg végképp nincs, hogy egyébként a "Fiktív Bank Ltd." feliratú ződ lakat meg a felirat nélküli ződ lakat közt technikai szinten nincs különbség, a "Fiktív Bank Ltd." felirathoz kicsit utánanéztek, hogy tényleg ők kérték-e a certet...)

A supporton felül egyébként valami biztosítás is jár a fizetős certekhez akár millió dolláros nagyságrendig is... (amit gondolom ki is fizetne a kiállító [haha], bár elképzelésem sincs, hogy hogy tudnád igazolni, hogy az ő hibájából történt valami)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Na jó, de ezt a felhasználók tudják is? És tudják, hogy ki által aláírt, milyen tartalmú certnek kéne a randomxyz.tldn lennie? Mert ha nem, akkor semmi értelme a plusz ellenőrzésnek.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Kérdés, hogy minden egyes esetben tényleg szükség van-e titkosításra! Hiszen egy névjegy oldalon, ahol se bejelentkezés, se feliratkozás, se semmi paripafax nincs, csak publikus információ, oda mi a brének legyen kötelező?!

--
Where do you want to go today?
[nobody@salcay:~]$_

Privacy témában általánosan mondják "legyen minden titok rólam", ez legyen az alapeset. Az egy dolog, hogy így sem minden titok, majd kifejti valaki ha akarja (hogy egész konkrétan mi látszik a netes forgalmamból https esetén IS).

Másik, hogy hajbazer témáiban merült fel a felesleges https esetek által pazarolt energia kapcsán, hogy processzor szintű támogatás van már ezekre a számításokra, nagyon kis többletmunkáról van szó elvileg (fixme).

> hogy egész konkrétan mi látszik a netes forgalmamból https esetén IS

Egy tipikus HTTPS kérés során egyedül az IP cím látszik, amire csatlakozol (ha nagyon titok, elérakod a CloudFlare-t). Esetleg a DNS query előtte, de arra is van megoldás (DNSCrypt). Minden más titkosítva utazik.

Igazság szerint itt jön képbe az, hogy mit kell védeni, és ahhoz milyen komoly hitelesítés szükséges. Ha csak azért kell cert, hogy a nyomi Chrome ne picsogjon, akkor bőven jó a LE. De egy pénzügyi vagy állami szervezet, mittomén, cryptoexchange az jobb, ha nem effélét használ.

Azért ezen felül Salcay-nak igaza van, hogy maga a PKI van elbaszva, mert nem tudod egy-egy CA hatalmát korlátozni pl. megmondani, hogy melyik TLD-kre adhat ki certet. Ha alá van írva és az aláíró cert benne van a trusted store-ban, akkor biztos stimmel.

És persze ezt mindig az ingyenesek ellen hozzák fel, pedig ugyanúgy probléma bármelyik másik szolgáltatónál. Valószínűleg lehetne találni olyan nagy múltú, megbízható és az összes böngésző által megbízott CA-t, amelyik annyira felületesen ellenőriz, hogy kis ügyességgel ki tudj tőlük kérni egy EV certet...

Persze ott van erre az értelmes megoldás (DNSsec + DANE TLS, ami ráadásul több rétegben védene... pl. többek közt pont a DNS poisoning ellen), amit senki nem használ, mert a G nem szereti a decentralizált dolgokat; de nagyon jó, mert a fél világot körbe lehet helyette taknyolni, hogy látszat megoldásokkal (HPKP, CAA record, certificate transparency stb.) egy bizonyos use case (Béla beírja a böngészőbe az oldal címét és megnyitja) néhány attack vector ellen védett legyen.

--

És egyébként Salcay eredeti kérdésére válaszolva: az égvilágon semmi, kivéve, ha a célpontod DNSsec aláírt zónát használ [buktad a DNS poisoningot] és publikál CAA rekordot a saját CA-jával [buktad a "magamhoz irányítom a forgalmukat és a LE kéréseit én szolgálom ki" megoldást, mert az LE már kérni sem fog]. Egyébként pedig az LE (feltehetően szemben több "nagy múltú, megbízható és biztonságos blablabla" CA-val, amelyik DV certet ad, direkt úgy intézi, hogy egy-egy ellenőrzés akárhonnan jöhessen, világ szinten kéne forgalmat elterelned, mert nem tudhatod, hogy honnan várjad)

--

Szép hosszú rejtett subscribe voltam.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

jó összefoglaló.
illetve tegyem még hozzá azt, hogy amíg egy cert-et csak egy CA tud aláírni, addig az egész infrastruktúra egy vicc.
elvileg semmi nem akadályozná hogy az SSL rétegben ne az egyeduralkodó x509 tanusítványok legyenek, hanem mondjuk PGP. csak avval kezdték implementálni (aztán latjuk h mennyire sikerült v. mennyire nem). és akkor PGP-vel már aláirathatom több CA-val is a saját certemet.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

"amíg egy cert-et csak egy CA tud aláírni, addig az egész infrastruktúra egy vicc."
Létezik cross-signed cert, a LetsEncrypt is így ad ki certet, hogy elfogadott legyen, az ő CA certjük keresztaláírt:
https://letsencrypt.org/certificates/

Az IdenTrust keresztaláírta a CA certjüket, így az elfogadott minden elterjedt helyen. Amíg ez nem volt, addig fel kellett venni kézzel a LetsEncrypt CA certet az elfogadott root certek közé.

jogos. rosszul fogalmaztam.
arra gondolok, h legjobb tudomásom szerint azt nem lehet hogy olyan certet tegyek egy site-ra, hogy azoknál is átmenjen a verification akiknél fel van telepítve "A" CA és nincs feltelepítve "B" CA, valamint azoknál is akiknél épp ellentétesen fenn van "B" CA és nincs fenn "A" CA; és "B" nem írja alá "A"-t és "A" sem írja alé "B"-t.

~~~~~~~~
deb http://deb.uucp.hu/ wheezy yazzy repack

Igen, ilyet nem lehet.
Az X.509 tanúsítványok formátuma egy darab issuer-t támogat.
Ugyanígy, sem a PKIX sem a CABR tanúsítványláncok nem engednek meg ilyet a folyamtukban.
Szóval nem csak formátum, hanem folyamatprobléma is van.

Olyat tudsz csak csinálni, hogy ugyanarra az entitásra (weboldalra, cname-re) több tanúsítványt is készítesz, több kibocsátóval.

Azért van néhány ötletem, amivel kárt tudnék okozni az oldal tulajdonosának / megtekintőinek, vagy hasznot magamnak, ha csak úgy belenyúlhatnék a statikus névjegyoldalakba...

- Reklámokat tehetek minden oldalba
- Kicserélhetem az oldal tulajdonosának a reklámait olyan reklámokra, amik nekem hoznak pénzt, nem neki (még csak fel sem tűnik senkinek)
- Hozzáadhatok egy háttérben bitcoint bányászó szkriptet
- Kicserélhetem az oldalon a támogatóknak szóló bankszámlaszámot a sajátomra
- Egy vízszerelő oldalán a telefonszámot kicserélem a szomszéd vízszerelőjére, aki cserébe az így szerzett üzletekből 10%-ot visszacsurgat.
- Vagy mondjuk egy ügyvéd esetén lehallgatom és rögzítem a bizalmas hívásokat azzal, hogy kicserélem a telefonszámot a sajátomra, az szoftveresen automatikusan továbbirányít az eredetire, így senki nem vesz észre semmit, de közben rögzít is mindent. (Ezzel kapcsolatban egy érdekes előadás: https://www.youtube.com/watch?v=5c6AADI7Pb4 6:40-től)

De ezt csak akkor tudod megcsinálni, ha a böngésző és/vagy az OS kulcsai közé felveszed a sajátodat is, amivel újracsomagolod. Ezt csak úgy nem tudod betenni egy random böngésző és egy random szerver közé, mert nem fogod tudni lebontani és újraépíteni a titkosítást.

Ez így van. Viszont, ahogy írtam is, szándékosan van ott az eszköz ahol van, de nem a user teszi oda, hanem pl munkáltató, aki viszont megoldja, hogy ott legyen a megfelelő cert a megfelelő helyen. Zöld lesz minden, és mégis be lesz folyásolva a tartalom.

--
Where do you want to go today?
[nobody@salcay:~]$_

De ezt pont nem a HTTPS ill. az SSL/TLS hibája, hanem a retek PKI-é (gyk.: bárki bármit aláírhat, ha az aláíró "megbízható", akkor ződ; lásd fenn). A fentebb említett DNSSec/DANE TLS-nél ugyanehhez az IANA root kulcsait kéne hamisítanod, akár minden alkalmazásban (mert simán szállíthat bele lehet égetni az alkalmazásba, nem kell nyócszáz standard a "trust store" fogalomra, mert nincs rá szükség - egy trust anchor van, oszt jónap).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Na ja. Remek dolog ez, hogy nem biztonságos a http mosantól. Szépen ki is van írva. Aztán nagyon biztonságos lesz a 3 hónapos letsencrypt-es SSL-es történet.

Végülis :) A user meg majd nézi hogy úúú de szép zőőd, ez tuti biztonságos. :)

félreértés ne essék, nem az SSL ellen vagyok, még csak nem is a letsencrypt ellen. Csak hogy így a chrome kijelenti hogy "nem biztonságos" jelzőt elé rak egy sima http oldal elé, az nem kicsit lehet félrevezető, ugyanígy a "szép zőőd https SSL certes" oldal is lehet félrevezető, mert hát az meg "Biztonságos"nak van jelölve.

Szóval 'nyjuk meg salakmotoros :)

Meg attól, hogy nem biztonságosnak jelöli, még semmilyen probléma nem fog megoldódni, ugyanúgy maradnak a http oldalak, a felhasználó pedig pár nap után ugyanúgy hozzaszokik és leszarja. Látszat cselekvés.

--
"Nem akkor van baj amikor nincs baj, hanem amikor van!"
Népi bölcsesség

Mérleg egyik nyelvében a http-ssl-nélkül, másik nyelvében a "mindenhova ugyan azt a jelszavam használom még olyan webshopba is ahol simán nem titkosítva tárolják a jelszavam ezért fel tudják ők is használni máshol a nevemben való cselekvésre".

Melyik a nagyobb súlyú probléma szerinted? :)

nyilván a második a nagyobb probléma :) Sőt, kontra, lehet hogy az egy olyan webshop aminél még vásárolt SSL CERT van! De azért plaintextben tárolják a jelszavadat :) Milyen jó biztonságos. Míg adott esetben egy http -s oldalon regelsz, ott meg pont hogy nem plaintextben van a jelszavad tárolva. De az nem biztonságos.

brr. ez ilyen se egyik se másik. Mind 2 oldalon félrevezető, http és https -nél is.

"lehet ... olyan ... aminél még vásárolt SSL CERT van!"

Nem ÉS, hanem VAGY. Melyik hibát orvosolnád előbb? Ha a kettő együtt fennáll akkor is, de ha csak egyik helyen ez, másik helyen az, akkor is. Tippre a http oldalak többsége is hash-elt, mert valami keretrendszert használ, míg a https oldalak mögé könnyen elbújik egy phishing oldal bárány bőrben farkasként.

Jelenleg sokkal többet tudunk arról, hogy hogy kell technikai problémákat megoldani, mint emberieket.

Mégis az egész világ beszél az egyikről, és senki a másikról. Arról beszélnek, hogy jaj, ha feltörik a pinterest-et ÉS voltak olyan sügérek, hogy nem használtak semmi titkosítást, AKKOR baj ha nincs per site jelszavad, közben elfelejtik, hogy mint a huzat úgy rendelnek Kínából okosórát az emberek bizonytalan tulajdonosi hátterű webshopokban a gmail-es email címükkel és gmail-es jelszavukkal. Ami amúgy a facebook-os is. De remélem a paypal-os is.

Kérdés: megoldható-e, hogy a chrome ellenőrizze megadott jelszavam, hogy használtam-e már máshol is, és javasolja, hogy talán ne...?

### Más téma:

Oké, hogy próbál az ember mindenhova vagy legalább weblap csoportonként (banking, shopping, tech, stb - ki mt preferál) eltérő jelszavakat használni.
De minden jelszót nem jegyezhetsz meg... ------> Keepassban tárolod az összes jelszavad VAGY Google Password manager-ben/Firefox Cloudban? (Komoly kérdés)

Sajnos pont a nagyobb problémát nem oldja meg ez, sőt. A user nyugodtan használja a cleartextstore.com-on a gmailje jelszavát, mert hiszen ott a felirat, hogy a cleartextstore.com az biztonságos. Letsencrypt sem válogat (meg igazából egyik tanúsítvány kiszolgáló sem), a scammer/spammer/haxor ugyanúgy https-t fog használni mint a bankod. Tehát valójában ez semmit nem old meg, a drótón utazó biteket lesz nehezebb lehallgatni, ezért nem a dróton fogják elkapni ezeket hanem az adatközpontban, az adatbázisokból úgyis könnyebb dolgozni, mert szépen strukturáltan vannak tárolva az adatok :)
--
openSUSE - KDE user

Hát ha még azt is hozzá vesszük, hogy - mivel már szinte minden https alapú - háromszor felfejtik a kommunikációt és lecserélik rajta a certet, pont a lényegét veszti el. Ma már az összes security szoftver megteszi ezt, bele értve a hálózati eszközöket is. Szóval pont ugyan úgy a fél világ látja a kommunikáció tartalmát, akár változtathat is rajta. De legalább a paraszt örül neki, hogy van zöld lakatja (ami ma már e miatt pont semmit nem jelent).

Szerintem valójában az egész https mizéria csak egy főpróba volt a Google részéről, hogy mennyire tudja kézben tartani, módosítani az internet felépítését. A súlya miatt látjuk, hogy egész jól.

Zavard össze a világot: mosolyogj hétfőn.

kúl dolog lesz embedded device-okon használni, ahol nincs ssl support...

meg a cert revocation amúgy is sucks, chrome meg nem is használ OCSP-t. javítsatok ki.

Van aki böngészőt használ, és van aki Chromeot.

...és a kék sarokban felkészül dgeorge az Oil and Gas International rendszergazdája és webfejlesztője.

leszakadhatnatok szegenyrol, mar reg frissitett .NET 4.0.30319 -re:)

Es mostmar minden ssl ami szamit:
https://www.oilandgasinternational.com/SSL_Subscribe/subscribe_us.aspx

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

intraneten az ssl cert is meger egy kulon miset, amikor van 4-5 belso ip cim, kivulrol meg egynek latszik.

Ugyanitt webdav/caldav/carddav protokollt betenni reverse proxy moge se olyan feludules.
Meg nem szantam ra magam nginx-et patchelni...

---
Saying a programming language is good because it works on all platforms is like saying anal sex is good because it works on all genders....

Emlékeztető: Az összes kiállított ssl cert listája publikus. Tehát ha belső/nem publikus használatra szánt subdomainre kérsz ssl certet, akkor számolj azzal, hogy a botok/scannerek/etc. is meg fogja találni. Ha ez problémát okoz, akkor wildcard ssl cert használata ajánlott.

Ennek egyszerű oka van: az https://otpbank.hu -nak nincs ssl cert-je: (NET::ERR_CERT_COMMON_NAME_INVALID)

Na igen és erről beszéltem, az "include all subdomains"-t bepipálva lehet ilyen érdekességre bukkanni:

- https://piwikpro.otpbank.hu/ - Piwik 3.0.4 statisztikai rendszer !telepítőfelülete!, módosítható config fájlokkal (valószínű RCE egy olyan gépen ami hozzáfér legalább a szerver logokhoz)
- https://vpn.otpbank.hu/+CSCOE+/logon.html#form_title_text - Cisco belépési felület
- https://remote.otpbank.hu/ - Windows Server 2012 remote desktop logon
- Meg még egy csomó random, régi IIS-t futtató gép 404 errorokat dobva

Vicces lesz, az összes router, switch, kütyű, belső IP-s eszközhöz... Nembaj, majd váltanak a rendszergazdák róla.
Mondjuk én eddig se használtam, ezután se fogom.
--
"Sose a gép a hülye."

A nem túl ősküvületek eddig is leginkább self-signed certtel működtek, meg a szerverek BMC-i is, sose láttam céget, aki foglalkozott volna ezzel. Igazából engem se izgat túlságosan, legfeljebb ha a hülye Javás konzolhoz 15 helyre be kell írni, hogy biztosan használni akarom.