Kérdés:
Miért nem működik a DNS-hamisítás a HTTPS-webhelyek ellen?
Gray
2015-07-18 23:51:47 UTC
view on stackexchange narkive permalink

Hogyan véd az SSL használata a DNS-hamisítás ellen? mivel a DNS alacsonyabb szinten van, és mindig ugyanúgy működik, függetlenül attól, hogy a felhasználó HTTP vagy HTTPS webhelyet látogat-e.

Kettő válaszokat:
limbenjamin
2015-07-19 00:25:05 UTC
view on stackexchange narkive permalink

Tegyük fel, hogy sikerült megmérgeznie a securesite.com DNS-gyorsítótárát egy Ön által irányított IP-vel. Most, amikor az ügyfél meglátogatja a https://securesite.com webhelyet, az IP-címére változik. Az SSL kézfogási folyamat részeként a szervernek érvényes tanúsítványt kell küldenie a securesite.com webhelyhez, amely tartalmazza a nyilvános kulcsot.

Ezen a ponton 2 lehetőség áll rendelkezésre.

1) Küldje el a jogos tanúsítványt. Ezt ellenőrizni fogjuk, mivel a tanúsítványt megbízható CA írja alá. Ezután az ügyfél a nyilvános kulcs segítségével titkosítja a fő titkot. Ezen a ponton meghibásodik, mert a privát kulcs nélkül nem lehet visszafejteni a fő titkot, és így nem lehet befejezni a kapcsolat beállítását.

2) Küldjön saját aláírású tanúsítványt. Mivel azonban nem egy megbízható hitelesítésszolgáltató írja alá, egy figyelmeztetés jelenik meg az ügyfél böngészőjében. Ha az ügyfél mégis úgy dönt, hogy folytatja, akkor sikeresen végrehajtotta a támadást.

A DNS-hamisítás általában nem fog működni a HTTPS-webhelyeken, kivéve, ha az ügyfél úgy dönt, hogy figyelmen kívül hagyja a figyelmeztető jeleket, vagy ha sikerül megszereznie a webhely privát kulcsát.

Egy dolog ezzel kapcsolatban: hazámban gyakori, hogy az emberek figyelmen kívül hagyják ezeket a figyelmeztetéseket, mert a kormányzati CA-t alapértelmezés szerint nem telepítettük a böngészőkbe. Itt biztonsági lyuk van, más országokról nem tudok. Másrészt: a HSTS segítségével tiltsa le a figyelmeztetés figyelmen kívül hagyásának lehetőségét, jobb, ha előre be van töltve.
@GustavoRodrigues Csak véletlenszerűen mentem el az amerikai kormányzati oldalakra, és úgy tűnik, hogy az IRS.gov rossz tanúsítvánnyal rendelkezik. Nem ugyanaz a probléma, de ugyanahhoz a rossz felhasználói magatartáshoz vezet.
@Namfuak - ez azért van, mert kiszervezik az Akamai számára, és otthagyják a régi tanúsítványokat. Ugyanez az FDA-nál.
Csak hozzá akartam adni ehhez valamit, ami számomra nem volt azonnal nyilvánvaló: Ön (azaz a támadó) nem is kaphat SSL tanúsítványt a Let Encrypt-től vagy bárhonnan, mert ehhez a domain tulajdonosának kell lennie, lásd: "Domainellenőrzés "[itt] (https://letsencrypt.org/how-it-works/).
Az 1. opcióval kapcsolatban: Az ügyfél úgy gondolja, hogy én vagyok az eredeti szerver.Tehát mi van, ha csak a következő műveletek egyikét hajtom végre: 1) Módosítsa az oldal tartalmát úgy, hogy az ügyfél érzékeny adatokat küldjön nem biztonságos URL-re?2) Átirányítja az ügyfelet egy nem biztonságos http protokollra?
@TSR "Ezután az ügyfél a nyilvános kulcs segítségével titkosítja a fő titkot. Ezen a ponton meghibásodik, mert a privát kulcs nélkül nem lehet visszafejteni a fő titkot, és így nem lehet befejezni a kapcsolat beállítását." A kézfogás végül meghiúsul, mielőtt el tudna küldeni egy oldalt, vagy akár átirányítaná a választ.A 4. lépésben [itt] nem sikerül (https://cdn.ssl.com/app/uploads/2015/07/SSLTLS_handshake.png)
@BenHoyt ez épp ellenkezőleg: ha te irányítod a webhely DNS-jét vagy végső IP-jét, akkor elenyésző és szinte azonnali egy DV-tanúsítvány beszerzése bármely CA-tól, például a Let's Encrypt-től.Ellenőrizniük kellene, hogy támadóként ellenőrizték-e a webhelyet (amelyet te irányítasz) vagy DNS-rekordjaidat (amelyeket te irányítasz), így nem okoz gondot.A legutóbbi támadások ezt bizonyították.
Ez a válasz manapság már nem annyira érvényes, mivel nagyon könnyű megszerezni a DV tanúsítványokat DNS vagy HTTP érvényesítés alapján, amelyek akár egyek, akár mindkettők lehetnek egy támadó ellenőrzése alatt, ha sikerül megváltoztatni a névszervereket vagy a webhely IP címét..A DNSSEC képes védeni egy kicsit, de nem elég.Szüksége lenne CAA-rekordokra is (de a DNSSEC nélkül haszontalanok), ha a CA-kkal korlátozhatja, bizonyítványt adhat le, és olyan dolgok, mint a HTTP Key Pining, amelyek már nem a trendek.
stanko
2015-07-19 00:12:38 UTC
view on stackexchange narkive permalink

Tegyük fel, hogy DNS-t hamisít egy webhelyen, és átirányítja a felhasználókat egy általad irányított szerverre. Ez lehetséges, de valószínűleg nincs haszna, ha a felhasználók meglátogatják a webhely https verzióját, mivel Ön nem rendelkezik az általa hamisított webhely privát ssl kulcsával, és áldozata nem fog tudni létrehozni ssl kapcsolatot az Ön hamis webhelyével. / p>

Valami hasonló lehetőség alternatívája az sslstrip és a dns2proxy használata, de ez egy másik téma.

Nem számít, hogy van-e saját titkos kulcsa.Ha új DV tanúsítványt tud létrehozni, akkor a weboldalt bármely böngésző legitimnek ismeri el.A HTTP Key Pining védelmet jelenthet, de a böngészők már nem szeretik.


Ezt a kérdést és választ automatikusan lefordították angol nyelvről.Az eredeti tartalom elérhető a stackexchange oldalon, amelyet köszönünk az cc by-sa 3.0 licencért, amely alatt terjesztik.
Loading...