hup.hu HTTPS-en keresztül?

Címkék

Légyszi legyen!
41% (122 szavazat)
Nem!
13% (40 szavazat)
MÁR KÉSZ VAAAAANNNNNN!!!!
46% (139 szavazat)
Összes szavazat: 301

Hozzászólások

Nyilvánvaló volt, hogy "nesze parasztok zabáljátok a hígat amiért sírtatok" stílusban lesz tálalva :)

--
gg

Nincs "Csak az eredmény érdekel" választási lehetőség, így nem érvényes a szavazás...

Egy "mit bánom én" opció még elfért volna. :)

csak az eredmény érdekel, nem tudom, mi az a HTTPS és főleg hogy minek kell. Ubuntu alatt is futni fog a HUP azzal? Mert anélkül nem jó

Köszi. Mennyi ennek az átfutási ideje?

Addig is, amíg bekerül az adatbázisba:

cd ~/.mozilla/firefox/xxxx.yyyy/HTTPSEverywhereUserRules
vi hup.xml

Bele:


<ruleset name="HUP">
        <target host="hup.hu" />
        <target host="www.hup.hu" />

        <rule from="^http:"
                to="https:" />
</ruleset>

:wq

Örül.

(xxxx.yyyy nyilvánvalóan a Firefox profil neve)

--
trey @ gépház

Úgy látom bejön a https://hup.hu is, de akkor mért nem dob át rögtön ide http-ről? Gyönyörű Let's Encrypt certje van :)

Örülnék neki, ha alapértelmezett lenne, mert jórészt nyilvános hot-spotokról internetezek szerte az országban, legalább 3 különböző eszközről. Gondolom más is van hasonló cipőben.

Már működik, de telhjesen értelmetlen.

Most is ott a sárga warning: "part of the site is not secure"
bármilyen külső (clear http) hivatkozással könnyedén bárki el tudja törni a lakatot.

Különben sem értem miért az a perverziója valakinek hogy a publikus híreket is https-en keresztül akarja olvasni.

--
zrubi.hu

a hozzászólásba beágyazott http tartalmakkal persze jól meg lehet törni a https-t (ha ez engedélyezve van/lesz),
de én a motor forrásában lévő linkekről beszéltem. pl. google-analytics, feedburner, pingvinbolt linkek.
ezeket kéne sztem https-re javítani (már csak azért is, mert ezek amúgy is már https-ek 301-gyel).

így az oldal tökéletes https lesz, kivéve persze azokat az eseteket, ha vki http-t ágyaz be hozzászólásban.
ez nyilván előfordulhat, de pl. ezen az oldalon, ahol mondjuk van már pár hozzászólás, nem fordul elő.

én megpróbáltam építő jelleggel hozzászólni egyébként, nem hiszem, hogy egyből szemtelenkedni kellene.

jah, erről van is itt egy másik hozzászólás vhol, pl. a github ezt csinálja:
https://github.com/blog/743-sidejack-prevention-phase-3-ssl-proxied-ass…

de pl. a facebook (ha jól tudom, de nem biztos, mert jelenleg nem használom :) )
meg nem ágyazza be a sima http tartalmakat, csak a https-t.

(egyébként pont ezért (is) kellett vhol pár éve https-re áttérni,
hogy működjenek rendesen a facebookba beágyazott videók.)

"Különben sem értem miért az a perverziója valakinek hogy a publikus híreket is https-en keresztül akarja olvasni."

Hat eloszor is tobben loginolnak, mag hozzaszolnak (ahogy te is) es akkor mar indokolt. De inkabb azt mond meg, hogy nekem mint egyszeri usernek mi hatranyom van abbol ha (jol mukodo!) https van egy oldalon.

A "jól működő https oldallal" nem lenne probléma, csak a gyakorlatban olyan sajnos nincs - de legalábbis igen ritka. Amiket Te mint "egyszerű user" látogatsz, azok szinte kivétel nélkül hamis biztosnágérzetben ringatnak, ami bizony neked rossz. Még akkor is, ha nem tudsz róla.

1.
A HTTPS oldalakhoz egy 3rd party (profitorientált) cégtől kell megvásárolni a tanúsítványt. Ebben a cégben Te mint olvasó is feltétel nélkül meg kell hogy bízz. És meg is bízol, mert a Mozilla/Microsoft/Apple megmondta (előre telepítette) neked a cégek root certificate-jeit.

Ilyen cégből viszont elég sok van, nézd csak meg (firefox esetén): Preferences -> Advanced -> Certificates -> View Certificates -> Authorities

Amennyiben Te nem bízol meg az itt felsorolt cégek MINDEGYIKÉBEN, akkor már eleve veszett fejsze nyele ez az egés HTTPS mizéria. Ugyanis ezek BÁRMELYIKE ki tud állítani olyan (pl hup.hu-ra szóló) tanúsítványt amire a böngésződ szép szemkápráztató zöld lakat megjelenítésével reagál.
(Nagyon leegszerűsítve elég csak ezen cégek közül csak egyet komprommitálni/lefizetni/feltörni és az egész világ a Te kezeidben lehet ;)

2.
a bejelentkezési adatok biztonságos(abb) elküldését már jópár évvel ezelőtt kitalálták, nem csak a clear text auth létezik ;)

3.
A legtöbb accountot NEM a https hiánya miatt szerzik meg a gyakorlatban, hanem a ratyi webalkalmazások, rosz tervezés, frissítések hiánya miatt.

4.
a HTTPS nem véd a gonosz/támadó jellegű tartalom ellen. Esetünkben pedig a tartalom (külső linkek) a userektől jönnek, így megbízhatatlan(nak kellene tekinteni) mind. Ezzel szemben a legtöbb user vakon klikkel bármire, "mert hát ott a zöld lakat, mi baj lehetne???"
(Ha nem így lenne, akkor az pl FB sem jelezné ezt külön egy felugróablakban, hogy biztosan elhagyni akarod az adott oldalt, és a vad interneten szörfözni készülsz?)

5.
A titkosítás "miatt" még csak megvédeni sem lehet a szerencsétlen usereket, mert sem proxy, sem tűzfal nem tudja (értelmesen) elemezni a "zöldlakatos" forgalmakat.

6.
Keress csak rá arra, hogy az elmúlt egy évben hányszor vérzett el az összel SSL/TLS implementáció;)

Ezekkel szemben ha nincs HTTPS, csak sima HTTP elérés, akkor az oldal üzemeltetője nem is sugall semmit olyat, amit esetleg az egyszerű userek (hibásan) feltételeznek egy HTTPS oldalról.
Te mint user sem (de legalábbis kisebb eséllyel) esel abba a hibába, hogy máshol is használt jelszót adj meg, olyan önynugtató mantrával, hogy hát ez it biztonságban van, mert ződ a lakat.

szerintem.

--
zrubi.hu

mindegyik felvetés érdekes, és sztem megfontolandó.

sztem egyébként azok a userek, akik megkülönböztetik a http és https protokollokat, esetleg még a lakat színére is figyelnek,
és zöld lakat láttán egyfajta hamis biztonságtudat alakul ki bennük, szerintem ők viszonylag kevesen vannak. pláne azok, akik
ezek közül mondjuk zöld lakat esetén béna jelszót használnak (esetleg máshol is használtat), de mondjuk nem zöld, vagy sima
http esetén meg jó bonyolult egyedit, na ők aztán sztem baromi kevesen. jó, ezt csak érzésre mondom, nincs semmilyen felmérés
a birokomban.

éppen ezért sztem bármilyen módszer, ami megnehezíti az esetleges támadók dolgát, az üdvözlendő.

én azt gondolom (elfogadva zrubi által leírtakat), hogy még egy béna https és jelentősen megnehezíti a mitm
támadások alkalmazását. olyannyira, hogy nem is inkább a kommunikációs csatornát fogják támadni, hanem pont
a webalkalmazás / infrastruktúra egyéb elemeit, ahogy egyébként zrubi írta. egy jobban összerakott https-t
meg mondjuk tényleg elég nehéz szétszedni.

ugyanakkor véleményem szerint a https rohamos terjedésével kialakul az a helyzet, hogy az elsöprő
többség (nagy általánosságban) képtelen lesz hagyományos mitm támadásokra, nyilván lesznek azok (nagyon kevesen),
akik mindenféle egyéb sebezhetőségeket (rosszul kialakított https-t, hibás implementációkat, összevásárolt / kikutatott 0dayeket)
kihasználva tudnak majd mitm támadásokat (jó nehezen) végrehajtani, illetve lesznek (vannak) azok, akik bizonyos
tanúsítvány kiállítók / egyéb szervezetek felett állva, velük együttműködve, esetleg őket irányítva,
könnyedén lehallgathatnak mindent (NSA).

na ez már itt talán a Crypto Wars téma, nem bizos, hogy ide tartozik, hogy a HUP-on jó-e ha van https vagy nem jó.

én mindenesetre a pro/kontra érveket figyelembe véve egyértelműen https párti vagyok. :)

Az, hogy nem lehet proxy-zni a https-t, az minden oldalnál fenn áll üzemeltetés szempontjából. Dehát pont ez lenne a lényege. Amúgy a phishing és támadó linkek elleni védelmet segítheti a böngészőbe épített megoldás. Ott van frissülő adatbázis. Ennek minden hátrányával. Nyilván nem lehet rátolni céges vírusellenőrzést reptében.

A weboldal kiszolgáló oldalán tudnék elképzelni egy szűrést a feltöltött tartalomra és linkekre, ami még olyan szempontból is jó lenne, hogy egyszeri folyamat lenne szerver oldalon, az helyett hogy kliens oldalon kellene mindenkinek külön megtennie. Ezt persze nem feature kérésnek írom, csak válaszként neked. :)

Ezt a https-t nem lehet ellenorizni mantrat, legy szives mellozzetek mar!

Szinte biztos vagyok benne, hogy nem csak egy termek letezik a dologra, en tapasztalatbol csak egyet ismerek:
SCB.
Aztan persze meg ott van a motorja a Zorp.
Azt 100%-ra nem tudom, de valszeg 6-os Zorp GPL is tud ilyen feature-oket, csak neked kell bekonfiguralnod.

+ extra elony, hogy onnantol kezdve, hogy van egy ilyened; a bongeszodbol kiirthatod az osszes CA-t, es csak egyet kell felvegyel amiben megbizol: a sajat magad altal generalt CA-t, amiver ropteben alairsz a zorp-al minden ssl forgalmat, az eredeti ssl-t kivaltando, es oda konfiguralod be azon CA-k listajat, amiben megbizol, es celszeru alairnia.

Akkor beszeljunk pls. ssl/tls-rol, ha mar legalabb az alapokkal tisztaban vagyunk!

Ohh :)

Az általad említett megoldások kizárólag SAJÁT szerver védelmére, és saját alkalmazottak auditálására valók.

Mivel gyakorlatilag ez egy MITM támadás, általános célú használata jogi szempontból minimum aggályos, de sok esetben akár törvénybe is ütköző tevékenység.

--
zrubi.hu

Szerintem ha egy cég beleírja a szerződésbe, hogy az infrastruktúra csak céges felhasználásra való, minden magántermészetű dolgot kizárnak, és odaírják, hogy a forgalmat szúrópróba szerűen megfigyelhetik, akkor nem nagyon lehet ágálni ellene, ha nem csak a titkosítatlan, hanem a titkosított forgalmat is ellenőrzik.

Persze tudom, erről sokan másképp gondolkoznak, pl. a céges leveleket elolvashatja-e a cég témáról is elég nagy vita zajlott. Ez pedig szerintem ugyanaz a kérdés pepitában.

Szerintem ha egy cég beleírja a szerződésbe, hogy az infrastruktúra csak céges felhasználásra való, minden magántermészetű dolgot kizárnak, és odaírják, hogy a forgalmat szúrópróba szerűen megfigyelhetik, akkor nem nagyon lehet ágálni ellene, ha nem csak a titkosítatlan, hanem a titkosított forgalmat is ellenőrzik.

Egy cég azt irat alá amit akar, de attől még az simán lehet éppen hatájos törvényekbe ütköző dolog.

Ilyen módon "feltört" SSL kapcsolat nem csak a felhasználó szemszögéből nagyon gázos dolog, hanem a célszerver is simán beperelhetne hogy Te (mint alkalmazó cég) az ő domainjére állítáasz ki HAMIS tanúsítványokat, és belenézel olyan forgalomba amihez az ég világon semmi közöd.

A "magántermészetű" dolgok teljes kizárása pedig szerintem durván életszerűtlen, és feltételezem jogilag is nehezen védhető tevékenység.

Pl a fizetésedet is egy bankszámlára utalják, amit ugye céges juttatás, tehát a munkádhoz szorosan kapcsolódó dolog. Ahhoz hogy ennek dolgait megnézd/intézd be kell lépj egy bank weboldálára. Viszont ez már durván nem céges, és a cégednek az ég világon semmi köze nincs a bankszámládhoz, azon kívül hogy oda utal. Ilyen internetes forgalom feltörése, és "ellenőrzése" szerintem bármilyen aláírt fecni mellett is törvénybe ütköző cselekedet.

Ennyi erővel a WC-be is tehetnének kamerát, hiszen azt is munkaidőben csinálod ;)
(Sőt a "szerzői jogok" esetleges átruházódása miatt lehet hogy a végtermék is a cég tulajdona ;)

szerintem.

--
zrubi.hu

Nézzük picit másfelől:

* A céges forgalmat védhetem / auditálhatom vele, és meglesz a vírus / reklám / whatever védelem, amit egy sima squid vagy más tartalomszűrő proxy tudna neked adni.
* Hogy ugyanezt valaki az otthoni routerére tegye fel, és ugyanígy / ugyanerre használja (ismerek ilyet, cövek pl. szokott néha irogatni is ida, sőt asszem neki vannak is zorp gpl buildjei ubiquity rspro - openwrt csomagformátumban)

Mi maradt ki, amit szerinted még védeni kellene, és nincs felsorolva?

Igen, vannak pontok, ahol ezeket a mitm-jellegű beavatkozásokat már nem lehetne ilyen simán megtenni. Pl. egy isp szintjén. És ez pont jól is van így: csak olyan tud legálisan evvel belehalgatni az ssl/tls forgalomban, aki arra valóban jogosult is.

Probléma egy szál se!

Átmeneti megoldásként amíg Ajnasz nem követi a nagy változásokat, azt nem lehetne megoldani, hogy ha http-n nézem az oldalt, akkor a HUP logó is oda menjen vissza, míg ha https-en akkor oda?
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

^^ 40%-nak fogalma nincs mire szavazott

--
trey @ gépház

nem igaz, én pl. megnéztem, hogy már elérhető a https, és utána szavaztam arra az opcióra, hogy "legyen".
ugyanis még nincs _teljesen_, mivel vannak http hivatkozások az oldalban, aminek nem kéne lennie.

megoldás baromi egyszerű: az összes sima http igazából már eleve 301 a megfelelő https oldalra (ha jól
néztem végig gyorsan), szóval egy mozdulattal át kéne írni, és akkor tökéletes https lenne az oldal. :)

Miert, lehetett szavazni ? En csak ranyomtam egy radiogombra, senki nem mondta, hogy ezzel szavazok.
(Egyebkent en is az elsore nyomtam, de csak mert nincs "nem erdekel" gomb. Marmint ugy ertem, a szavazas temaja erdekel, mert fejlesztes temaban nem is szavazok, de itt az nem erdekel, hoyg lesz vagy nem lesz https, de ha ilyet nem tudok mondnaio, akkor megis inkabb a "legyen" gombra nyomok, holott ott a harmadik gomb figyelmeztetesnek, hogy mar valoszinuleg van)
--
http://www.micros~1
Rekurzió: lásd rekurzió.

Ahogy nezem developer consoleba azer volna mit ganezni :) google-ads, embed-player.js, stb.
Egyebkent ha mar Drupal az alap akkor csak at kell allitani hogy milyen html kodot lehet beagyazni, illetve ha lehet is akkor is forced legyen a https, vagy atirni hogy ha http cimet ir be az ipse, akkor linkroviditovel atformalja szepen https-re.

ja es en nem 301 redirectel csinalnam hanem rewrite-al.. mert akkor az rss feed tovabbra is muxeni fog amit IRC-n hasznalok :D

csoda hogy az ipv6ot nem hozta fel valaki .... :D amúgy +1 https-re

Hibajelentés (avagy feature request): vegyétek fel a certbe a wiki.hup.hu címet is!

*Legyen, csak akkor valami 21. századi, pl. QUIC protokollt támogató hoszton mert pont azért szeretem a HUP-ot, mert azonnal megnyílik amint rábökök még lassan HSPA kapcsolaton is.