Kysymys:
Onko URL-osoitteet, joita tarkastellaan HTTPS-tapahtumien aikana yhdelle tai useammalle verkkosivustolle yhdestä IP-osoitteesta, erotettavissa?
blunders
2011-06-06 17:22:54 UTC
view on stackexchange narkive permalink

Oletetaan esimerkiksi, että HTTPS-URL-osoitteet kahdelle verkkosivustolle yhdellä IP-osoitteella 5 minuutin aikana: "A.com/1", "A.com/2", "A.com/3", "B.com / 1 "," B.com/2 ".

Paljastaisiko pakettien seuranta:

  • Mikään ,
  • paljastaisi vain IP, jossa käynyt "A.com" ja "B.com" (tarkoittavat vain DNS: ää),
  • paljastavat, että vain IP on käynyt sivustoissa "A.com/1" ja "B.com/1" (ensimmäinen HTTPS kutsu jokaiselle sivustolle),
  • paljastaa täydellinen luettelo kaikista käydyistä HTTPS-URL-osoitteista,
  • paljastaa vain "A.com" ja "B.com" IP-osoitteet,
  • vai jotain muuta?

Liittyvä kysymys: voiko yritykseni nähdä, missä HTTPS-sivustoissa kävin?

Vaikka tällä kysymyksellä on lisätietoa, niin pitkälle kuin voin kertoa, se ei koske nimenomaisesti skenaariota "paljastaa vain IP käynyt" A.com/1 "ja" B.com/1 " (ensimmäinen HTTPS-pyyntö kullekin sivustolle) "- vaikka väärä mahdollisuus tässä onkin suuri, poistamme mielellämme kysymyksen, jos se on kaksoiskappale.


HUOMAUTUS: Tämä on jatkokysymys vastaukselle, joka lähetettiin osoitteeseen: Miksi HTTPS ei ole oletusprotokolla?

Kolme vastused:
#1
+82
D.W.
2011-06-08 00:02:40 UTC
view on stackexchange narkive permalink

TLS paljastaa salakuuntelijalle seuraavat tiedot:

  • sivusto, johon otat yhteyttä
  • muun URL-osoitteen (mahdollisesti likimääräinen) pituus
  • vierailemasi sivun HTML-koodin (mahdollisesti likimääräinen) pituus (olettaen, ettei sitä ole välimuistissa)
  • muiden resurssien (mahdollisesti likimääräinen) määrä (esim. kuvat, iframe-kehykset, CSS-tyylitaulukot) jne.) vierailemallasi sivulla (olettaen, että niitä ei ole välimuistissa)
  • aika, jolloin kukin paketti lähetetään ja kukin yhteys muodostetaan. (@nealmcb huomauttaa, että salakuuntelija oppii paljon ajoituksesta: kunkin yhteyden muodostamisen tarkka aika, yhteyden kesto, kukin paketti lähetettiin ja vastaus lähetettiin, aika, jolloin palvelimen on vastattava kuhunkin pakettiin jne.)

Jos olet vuorovaikutuksessa verkkosivuston kanssa napsauttamalla linkkejä sarjaan, salakuuntelija näkee nämä kaikki jokaisesta verkon napsautuksesta. sivu. Nämä tiedot voidaan yhdistää ja yrittää päätellä, millä sivuilla olet käymässä.

Siksi TLS paljastaa esimerkissäsi vain A.com vs. B.com, koska esimerkissäsi loput URL-osoitteet ovat kaikissa tapauksissa sama pituus. Esimerkkisi valittiin kuitenkin huonosti: se ei edusta tyypillistä verkkokäytäntöä. Yleensä tietyn sivuston URL-pituudet vaihtelevat ja paljastavat siten tietoja käyttämästäsi URL-osoitteesta. Lisäksi sivun pituudet ja resurssien määrä vaihtelevat, mikä paljastaa vielä enemmän tietoa.

On tehty tutkimuksia, jotka viittaavat siihen, että nämä vuodot voivat paljastaa salakuuntelijoille merkittäviä tietoja vierailemillasi sivuilla. Siksi ei pidä olettaa, että TLS peittää salakuuntelijalta vierailemasi sivut. (Ymmärrän, että tämä on haitallista.)


Lisätty: Tässä on lainauksia HTTPS: n liikenneanalyysejä koskevasta kirjallisuudesta:

+1 @D.W .: Valitsi viestisi vastaukseksi. Minulle n-gramman lohko-hyökkäys AJAX-pohjaisiin HTTPS-tapahtumiin ei ole yllättävää, jos yleistät esitetyt uhkat, vaikka olette samaa mieltä siitä, että se selvästi korostaa kuinka vakava asia saattaa olla joissakin tapauksissa. Kiitos linkkien lähettämisestä, mielestäni todella parantanut vastauksesi laatua. Kippis!
Mahtava vastaus! Mielestäni sinun tulisi sisällyttää se, että hyökkääjä tietää paljon ajastuksesta: yhteyksien tarkka aika, yhteyden kesto, jokaisen paketin edestakaisin aika, palvelimen aika vastata jokaiseen pakettiin jne. On selvää yhdessä suhteessa, mutta se voidaan myös hankkia tiedoksi monin tavoin, koska oletan, että viitteet selittävät yksityiskohtaisesti.
@D.W. Vuotoako HTTPS vielä neljän vuoden kuluttua tällaisia ​​pituustietoja?
AiliqbrvjoCMT kyllä.
Joten vahvistaakseni - SSL-sivustolle lähetettyä kyselymerkkijonoa - ei voi nähdä evesdroper?
@niico, on oikea, kyselymerkkijono on salattu eikä sitä voi tarkastella suoraan (mutta muita asioita voi olla, ja jos salakuuntelija voi päätellä jotain kyselymerkkijonosta näiden muiden asioiden perusteella, se olisi yhtä huono).
Muuttaako HTTPS / 2: n saapuminen vakoiluominaisuuksia?
#2
+21
Thomas Pornin
2011-06-06 18:11:03 UTC
view on stackexchange narkive permalink

Toinen valinta. Enimmäkseen.

Kun selain vierailee HTTPS-verkkosivustolla, se perustaa TLS -tunnelin, johon liittyy epäsymmetrinen avaintenvaihto (asiakas ja palvelin sopivat jaetusta salaisuudesta). Tuo avaimenvaihtomekanismi käyttää palvelimen julkista avainta, jonka palvelin näyttää osana varmenteitaan. Palvelinvarmenteessa on palvelimen nimi (esim. A.com ) ja asiakas tarkistaa, että nimi vastaa odotettua nimeä (eli palvelimen nimi URL-osoitteessa). Palvelinsertifikaatti lähetetään kohtalokkaasti ennen avainvaihtoa, siis tavallisessa näkymässä.

Loput URL-osoite lähetetään osana HTTP-pyyntöä, joka tapahtuu salatussa muodossa. tunneli, joten näkymätön kolmansille osapuolille. Annettua tunnelia voidaan käyttää uudelleen useille muille HTTP-pyynnöille, mutta (rakenteeltaan) ne kaikki ovat samalle palvelimelle (sama verkkotunnus).

Varmenteen on sisällettävä aiheen nimi (tarvittaessa CN- tai SAN-muodossa), joka on joko isäntänimi URL-osoitteesta _tai_ on jokerimerkki, joka vastaa isäntänimeä, mutta vain vasemmanpuoleisin / alin DNS-tunniste voi olla villi, joten jos ei todellinen isäntänimi, tämäon ainakin hierarkkisesti lähellä sitä.
#3
-3
marshal craft
2018-01-13 10:21:20 UTC
view on stackexchange narkive permalink

Tämä on itse asiassa epämääräinen kysymys. Tämän vuoksi. Kun käytät https-palvelinta, http (täällä on ilmoitettu, että https on vain http TLS: n kautta) on korkeampi kerros kuin alla oleva TLS. Ensimmäinen asia, joka on tehty, on neuvotella TLS-asetukset, kuten salauspaketti, avaimet, kättely jne. Tämä tehdään https-portissa, mutta vielä ei ole http-tietoja. Sitten asiakas tai palvelin vaihtuu salaustilaan, jossa kaikki on salattu.

Tämän neuvottelun päätyttyä se siirtyy sovellustietoihin, jotka ovat pelkästään vanhaa http-protokollaa hyötykuormana.

Mutta nämä tiedot on salattu, joten URL-osoitteita ei näytetä. Kuitenkin, kuten yleisesti tiedetään, palvelimen ja asiakkaan IP-osoitetta EI salata, koska sitä ei käytetä TLS-kerroksessa vaan IPS-kerroksessa, joka on TLS: n alapuolella ja tämä alemmalla tasolla. TLS on IP-paketin hyötykuorma, joka sisältää otsikoina IP-osoitteen, porttinumeron, IP-protokollan, kuten TCP jne. Siksi koska vain TLS on salattu, näitä kohteita ei salata.

Lisäksi salakuuntelu ei ole ongelma, jos palvelimen ja / tai asiakkaan varmenne voidaan "linkittää" pääkäyttäjään tai sillä on kelvollinen varmenne.

Lopuksi haluaisin sanoa, että TLS ja siten HTTPS ovat itse asiassa kehys ja algoritmi korkeimman suojaustason neuvottelemiseen, joka perustuu asiakas- ja palvelinasetuksiin sekä vähimmäistukikehyksiin. Pohjimmiltaan TLS ei määritä todellista salausta. Nämä ovat salauspaketteja, joita säännellään tyypillisesti erillisellä RFC-tyyppisellä asetuksella kuin TLS-protokolla. Pelkästään HTTPS: n perusteella ei siis riitä sanomaan turvallisuuden laatua sen tarjoamilla alueilla. Vain vähäinen turvallisuus ja vaikeus voidaan olettaa. Salauspakettien todellinen laatu on monimutkainen ja kullekin tyypille ominainen kysymys, koska monet luottavat täysin erilaisiin mekanismeihin.

Muokkaa Myös huomioni on saanut, että TLS: n Server Name Indicator (käytetään useille IP-osoitetta jakaville palvelimille) TLS-laajennus kertoo helposti kenelle tahansa palvelimen verkkotunnuksen. Vain ensimmäisissä palvelimelle lähetetyissä viesteissä kenttä sisältää verkkotunnuksen ASCII-tekstin, kuten "google.com". Joten kuka tahansa, joka seuraa ensimmäistä pakettia, näkee nämä tiedot helposti. Tämä on valinta, joka on yleinen monien verkkosivustojen isäntien keskuudessa nykyään. Mikään URL-osoite ei saa olla suojaamaton.

Lopuksi se riippuu tosiasiallisesti salauspuvuista, ne eivät ole kaikki tasa-arvoisia, kuten oletus salauspaketti, joka ei ole salausta. Sitten kukaan näkisi tavallisen http: n, jos selaimesi ja verkkosivustosi on määritetty tukemaan näitä puvuja. Joten verkkoselaimestasi ja palvelimestasi riippuen missä tahansa vain IP-osoitteesta IP-osoitteeseen sekä verkkotunnukseen (TLS SNI-laajennuksella voidaan joskus myös muulla tavoin selvittää, mikä on vähemmän helppoa), kaikki joissakin muissa tapauksissa salauspukujen vahvuuksista riippuen.



Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 3.0-lisenssistä, jolla sitä jaetaan.
Loading...