Kysymys:
Kuinka on mahdollista, että HTTPS-yhteyttä muodostavat ihmiset eivät tietäisi sen salauksen purkamista?
Joshua Carmody
2011-08-15 23:58:32 UTC
view on stackexchange narkive permalink

Olen usein kuullut sanovan, että jos kirjaudut sisään verkkosivustolle - pankkiin, Gmailiin tai mihin tahansa - HTTPS: n kautta, lähettämäsi tiedot ovat turvallisia kolmansien osapuolten harhailemasta. Olen aina ollut hieman hämmentynyt siitä, miten tämä voisi olla mahdollista.

Toki ymmärrän melko hyvin (mielestäni) salauksen ajatuksen ja että tietämättä salausavaimia ihmisillä on vaikea rikkoa salausta. Ymmärrän kuitenkin, että kun HTTPS-yhteys on muodostettu, salausavain "keskustellaan" mukana olevien tietokoneiden välillä ennen salatun yhteyden muodostamista. Salausavaimen valinnassa voi olla monia tekijöitä, ja tiedän, että se liittyy SSL-varmenteeseen, joka voi tulla joltakin muulta palvelimelta. En tiedä tarkkaa mekanismia.

Minusta tuntuu kuitenkin siltä, ​​että jos palvelimen ja asiakkaan on neuvoteltava salausavain ennen salauksen aloittamista, kaikkien hyökkääjien, joilla on pääsy verkkoon, liikenne pystyisi myös seuraamaan avainta koskevia neuvotteluja ja siksi tietämään salauksen muodostamiseen käytetyn avaimen. Tämä tekisi salauksen hyödyttömäksi, jos se olisi totta.

On selvää, että näin ei ole, koska HTTPS: llä ei olisi arvoa, jos se olisi, ja on yleisesti hyväksyttyä, että HTTPS on melko tehokas turvatoimenpide. . En kuitenkaan ymmärrä miksi se ei ole totta. Lyhyesti: miten asiakas ja palvelin voivat muodostaa salatun yhteyden HTTPS: n kautta paljastamatta salausavainta kenellekään tarkkailijalle?

Katso 1. SSL-selitys - http://www.youtube.com/watch?v=a72fHRr6MRU ja 2. Mikä on HTTPS? - http://www.youtube.com/watch?v=JCvPnwpWVUQ
Vain verkkosivuston järjestelmänvalvojalla on verkkosivuston avain. Jos ajattelet tapausta, jossa Internet-palveluntarjoaja ylläpitää verkkosivustoa, Internet-palveluntarjoaja ei ole mies keskellä, Internet-palveluntarjoaja on mies.
@Johnny Ajattelen tapausta, jossa Internet-palveluntarjoaja on jotenkin vaarantanut varmenteen. NDF1 selittää sen alla tavallaan mitä ajattelin.
Mahdollinen kopio [Kuinka SSL / TLS toimii?] (Https://security.stackexchange.com/questions/20803/how-does-ssl-tls-work)
Neljätoista vastused:
#1
+399
Thomas Pornin
2011-08-16 00:35:59 UTC
view on stackexchange narkive permalink

Se on julkisen avaimen salauksen taika. Matematiikka on mukana.

Asymmetrinen avaimenvaihtojärjestelmä, joka on helpoin ymmärtää, on asymmetrinen salaus RSA: lla. Tässä on yksinkertaistettu kuvaus:

Olkoon n iso kokonaisluku (sanotaan 300 numeroa); n on valittu siten, että se on kahden samankokoisen alkuluvun tulo (kutsumme niitä p ja q ). Laskemme sitten "modulo n ": tämä tarkoittaa, että aina kun lisätään tai kerrotaan kaksi kokonaislukua, jaamme tuloksen n : llä ja pidämme loput (mikä on 0 ja n-1 välillä, välttämättä).

Annetaan x , lasketaan x 3 modulo n on helppoa: kerrot x : n x : n kanssa ja sitten uudelleen x em: n kanssa >, ja jaat sitten luvulla n ja pidät loput. Kaikki voivat tehdä sen. Toisaalta, kun otetaan huomioon x3 moduuli n , palautus x näyttää liian vaikealta (tunnetuimmat menetelmät ovat liian kallista nykyiselle tekniikalle) - ellet tiedä p ja q , jolloin se on jälleen helppoa. Mutta p : n ja q : n laskeminen n : stä näyttää myös vaikealta (se on ongelma, joka tunnetaan nimellä kokonaislukukerroin).

Joten palvelin ja asiakas tekevät näin:

  • Palvelimella on n ja se tietää vastaavan p ja q (se loi ne). Palvelin lähettää n asiakkaalle.
  • Asiakas valitsee satunnaisen x ja laskee x 3 modulo n.
  • Asiakas lähettää x3 moduulin n palvelin.
  • Palvelin käyttää tietojaan p ja q palauttaakseen x .

Siinä vaiheessa sekä asiakas että palvelin tietävät x . Mutta salakuuntelija näki vain n ja x3 modulo n ; hän ei voi laskea p , q ja / tai x näitä tietoja uudelleen. Joten x on jaettu salaisuus asiakkaan ja palvelimen välillä. Sen jälkeen tämä on melko suoraviivaista symmetristä salausta käyttäen avainta x .

Sertifikaatti on palvelimen julkisen avaimen ( n ). Sitä käytetään estämään aktiiviset hyökkääjät, jotka haluavat esiintyä palvelimena: tällainen hyökkääjä sieppaa viestinnän ja lähettää sen arvon n palvelimen n . Sertifikaatti on allekirjoittanut varmentaja, jotta asiakas voi tietää, että annettu n on todella aito n palvelimelta, jonka hän haluaa puhua. Digitaalisissa allekirjoituksissa käytetään myös epäsymmetristä salausta, vaikkakin erillisellä tavalla (esimerkiksi digitaalisille allekirjoituksille on myös muunnelma RSA: sta).

Pidän todella tästä vastauksesta. Onko se teknisesti tarkka SSL: n suhteen? Jos on, minulla on kiusaus merkitä se "hyödyllisimmäksi". Gowenfawrin vastaus on myös erittäin hyödyllinen ja sillä on paljon enemmän ääniä, mutta koska siinä on "sekoitettu yksityiskohtia", mietin, onko tämä vastaus tarkempi.
Ohitin paljon yksityiskohtia, esim. "3" -eksponentti voi olla toinen arvo (perinteisesti 65537), jota pidetään osana julkista avainta. Lisäksi jossain vaiheessa on täyte (asiakkaan valitsema satunnainen arvo on pienempi kuin _x_; _x_ johtuu suhteellisen yksinkertaisen muunnoksen soveltamisesta). Sen lisäksi näin tapahtuu useimmissa SSL-yhteyksissä (avaimenvaihtoalgoritmi neuvotellaan alussa, mutta useimmissa käytetyissä SSL-palvelimissa ja asiakkaissa tämä päätyy RSA: han, kuten kuvailen, eikä Diffie-Hellmaniin).
Yksi pieni nipistys - SSL / TLS-muodossa - tämän selityksen X on itse asiassa "pre master secret", sitä sekä asiakas että palvelin käyttävät "master secretin" luomiseen. Sitten tehdään toinen laskenta "avainlohkon" luomiseksi, mikä on tapa tuottaa tarpeeksi lähtöä pääsalaisuuteen ja sarjaan satunnaisia ​​syötteitä valitun symmetrisen salauksen tarvitseman symmetrisen avaimen luomiseksi. Tämä on oikeastaan ​​pieni nitti, koska se on melko lineaarinen - jos hyökkääjällä olisi ennen pääsalasalaisuutta ja selkeät hello-viestit, hän voisi kuunnella.
Kuinka suoritat _x_ annettu _x_ kuutio modulo _n_ ja _p_ ja _q_?
@Justin:-lyhyt versio: lasket _d_, käänteisen arvon 3 modulo _phi (n) _ missä _phi (n) = (p-1) (q-1) _. Sitten suoritat modulaarisen eksponentin _x 3 _ modulo _n_, eksponenttina _d_. [Wikipedia-sivulla RSA: ssa] on kohtuullisen selkeät selitykset (http://fi.wikipedia.org/wiki/RSA_%28algorithm%29).
Tämä on hieno, perusteellinen vastaus!
Olisiko totta sanoa, että n: llä on vain 4 tekijää: 1, p, q ja n?
Jos _p_ ja _q_ ovat kaksi erillistä alkulukua ja _n = pq_, niin on täsmälleen neljä positiivista kokonaislukua, jotka jakavat _n_, ja ​​nämä ovat _1_, _p_, _q_ ja itse _n_. Arvojen _1_ ja _n_ sanotaan usein olevan "triviaalit jakajat", kun taas _p_ ja _q_ on vaikea laskea. Tarkkaan ottaen vain _p_ ja _q_ kutsutaan "tekijöiksi", minkä vuoksi "jakaja" olisi tässä tarkempi terminologia.
Luulen lukeneeni kaiken, mitä en ymmärrä, kuinka hyökkääjä ei voinut katsella tietokonetta, jota hän yrittää saada, luoda avain, joka lähetetään toiselle osapuolelle suojatun yhteyden muodostamiseksi.
@greg: Kuinka voit katsella, että tietokone tekee asioita, ellet ole jo saanut sitä käyttää? (Vastaus: Sydämellinen)
Jos hyökkääjä seuraa tietokonetta itseään, julkisen avaimen vaihto on hyödytöntä.Se suojaa vain siltä, että joku tarkkailee viestintää, ei joku, joka valvoo itse palvelimen sisäistä tilaa.
#2
+133
gowenfawr
2011-08-16 00:17:48 UTC
view on stackexchange narkive permalink

Tässä on todella yksinkertaistettu versio:

  1. Kun asiakas ja palvelin neuvottelevat HTTPS: n kanssa, palvelin lähettää julkisen avaimen asiakkaalle.
  2. Asiakas salaa istunnon salauksen avain, jota se haluaa käyttää palvelimen julkisella avaimella, ja lähettää salatut tiedot palvelimelle.
  3. Palvelin purkaa istunnon salausavaimen yksityisellä avaimellaan ja alkaa käyttää sitä.
  4. Istunto on nyt suojattu, koska vain asiakas ja palvelin voivat tietää istunnon salausavaimen. Sitä ei koskaan lähetetty selkeästi, tai hyökkääjä ei millään tavalla voinut purkaa salausta, joten vain he tietävät sen.

Voilà , kuka tahansa voi nähdä julkisen avaimen, mutta se ei salli heidän purkaa salausta "hei-salakaamme-käyttämällä-tätä-nyt-päällä" -pakettia, joka on salattu tällä julkisella avaimella. Vain palvelin voi purkaa sen, koska vain palvelimella on kyseinen yksityinen avain. Hyökkääjät voisivat yrittää väärentää salatun avaimen sisältävän vastauksen, mutta jos palvelin määrittää istunnon tällä, todellinen asiakas ei puhu sitä, koska se ei ole avain, jonka oikea asiakas asettaa.

Se on kaikki epäsymmetrisen avaimen salauksen taika. Kiehtovia juttuja.

P.S. "todella yksinkertaistettu" tarkoittaa "sekoitettuja yksityiskohtia helpottamaan ymmärtämistä". Wikipedia "Transport Layer Security" antaa oikeamman vastauksen teknisiin yksityiskohtiin, mutta pyrin "helppoon napata".

Tässä vaiheessa on tärkeää mainita, että luotettu viranomainen on [allekirjoittanut] julkisen avaimen (http://fi.wikipedia.org/wiki/Digital_signature), mikä tarkoittaa, että vaikka hyökkääjä on [mies keskellä] (http : //en.wikipedia.org/wiki/Man-in-the-middle_attack), hän ei voi teeskennellä olevansa palvelin yrittäessään huijata asiakasta salaamaan jaettu avain käyttämällä hyökkääjän * julkista avainta.
mitä tapahtuisi, jos emme olisi keksineet epäsymmetristä salausta?
Ilman epäsymmetristä salausta, Internet, sellaisena kuin tiedämme sitä ei olisi olemassa, ajanjakso. Et voi myydä tavaroita satunnaisille asiakasjärjestelmille, joissa on symmetrinen salaus. Internet olisi kuin televisio, jossa katsot infomainoksia, mutta sinun on soitettava puhelimella, jotta voit tehdä ostoksen. Epäsymmetrinen salaus todella, * todella * on ** kiehtovaa tavaraa **
Viola? Etkö tarkoita Voilaa? :)
Olen pahoillani, viola-voila-juttu on minulle niin heijastava vitsinsisäinen asia, käytin sitä ajattelematta, ja tietysti kenenkään täällä ei voida odottaa olevan mukana siinä vitsissä. Joten kyllä, voila oli tarkoitettu semanttinen sisältö, ja alttoviulu ei ollut kirjoitusvirhe vaan hämärä syntaktinen vitsi. Anteeksi tuosta.
gowenfawr - +1 Kiitos vastauksestasi. Olin kuullut epäsymmetrisestä salauksesta, mutta olin unohtanut sen ajatellessani tätä kysymystä. Vastauksesi oli hyvin helppo ymmärtää. Hyväksyin Thomas Porninin vastauksen, koska tunsin, että hän todella selitti mekanismin perusteellisesti.
@gowenfawr kyllä, se on yksi kiehtovimmista asioista, opin siitä https://www.coursera.org/course/crypto -kurssilta ja siitä lähtien olen kiinnostunut yhä enemmän salauksesta ja bitcoineista.
@gowenfawr Kiitos yksinkertaistetusta vastauksesta! Olen ollut varma, että näin se toimi jo jonkin aikaa, mutta koska kaikki haluavat antaa tietoja jokaisesta OSI-mallin tasosta, on mahdotonta löytää ymmärrykseni vahvistusta.
mutta jos käytämme epäsymmetristä salausta, miksi on tärkeää, että "vain asiakas ja palvelin voivat tietää istunnon (julkisen?) salausavaimen?"jos tiedonsiirtoa ei voida purkaa julkisella avaimella, vaan vain sen vastaavalla yksityisellä avaimella, miksi julkista avainta ei voida lähettää turvallisesti?
@amphibient,, koska istuntoavain on symmetrinen salausavain, jota käytetään todellisten tietojen salaamiseen.Epäsymmetriset avaimet ovat hyviä vain pienten tietomäärien salaamiseen (kuten yksinumeroinen K).Joten julkiseen avaimeen perustuvaa epäsymmetristä salausta käytetään pienen salaisen avaimen turvalliseen vaihtamiseen, jota sitten käytetään suuren määrän tietojen symmetriseen salaukseen.
kiitos, sillä on järkeä.eikö [tämä suosittu vastaus] (http://security.stackexchange.com/a/8309/20014) kuitenkaan perustu eri oletukseen, että tietojenvaihdon jälkeinen kättely noudattaa myös epäsymmetristä salausta eikä symmetristä, kuten sinäsanoa?
@amphibient Linkittämäsi vastaus näyttää jättävän huomiotta erittäin tärkeän yksityiskohdan: Ensimmäisen vaihdon jälkeen, joka toimii jaetun salaisen avaimen muodostamiseksi, palvelin ja asiakas siirtyvät symmetriseen salaukseen tällä salaisella avaimella.Tämä tapahtuu muutamista eri syistä, joista vähiten on suorituskyky: kohtuullisen turvallisuuden takaavien avainpituuksien kanssa epäsymmetrinen salaus on hyvin hidasta, joten haluat minimoida salatun liikenteen määrän.Symmetrinen salaus voi toisaalta olla erittäin nopea mutta turvallinen.
+1 Kohteelle "tavoittelin helppoa grokkia".
#3
+84
evil otto
2011-08-16 08:39:30 UTC
view on stackexchange narkive permalink

Muut vastaukset ovat hyviä, mutta tässä on fyysinen analogia, joka voi olla helpommin ymmärrettävissä:

Kuvittele lukkolaatikko, sellainen, jossa on metalliläppä, jonka kiinnität riippulukolla. Kuvittele, että silmukka, johon laitat riippulukon, on tarpeeksi suuri, jotta siihen mahtuu kaksi riippulukkoa. Jos haluat vaihtaa lähettämistä turvallisesti toiselle osapuolelle jakamatta riippulukonäppäimiä,

  1. laittaa "asia" laatikkoon ja lukita se riippulukolla.
  2. lähetä lukittu laatikko toiselle osapuolelle.
  3. he asettavat lukonsa myös silmukkaan (niin että siinä on kaksi lukkoa) ja palauttavat kaksoislukitun laatikon sinulle
  4. Sinä poista riippulukko ja palauta nyt yksittäin lukittu laatikko heille.
  5. he poistavat oman lukonsa ja avaavat laatikon.

Salaus estää lukot ja avaimet matematiikasta. , mutta yleinen käsite on epämääräisesti tällainen.

Aion myös selittää sen. Ainoa toinen asia on lisätä, että tätä kompleksia * edestakaisin * tarvitaan vain kerran, koska sen mukana kulkeva `` asia '' on * jaettu avain *. Tällä tavalla * istunnon * loppuun asti molemmat päät voivat avata lukituslaatikon ja laittaa siihen asioita. Jokaisessa istunnossa on uusi riippulukko ja avainpari, joten heität ne vain, kun istunto päättyy. * 8 ')
Kinda kuten @Mark Booth sanoi, laatikon sisällä on kolmas riippulukko, jossa on joukko avaimia, ja sitä käytetään kaikkiin tuleviin vaihtoihin istunnon aikana.
Lisäksi: Laatikko ja riippulukot on valmistettu erittäin kovasta metallista. On täysin mahdotonta murtaa ne auki. Se on myös turvallinen röntgensäteiltä. Voit höyrystää laatikon ja sisällön ydinpommilla ja se on kadonnut, mutta et voi avata sitä.
Olen aina pitänyt tästä selityksestä. Paljon helpompi ymmärtää kuin joukko matemaattisia yhtälöitä.
Yksi asia, joka puuttuu, on todennus. toisin sanoen oikean 'he' asettavat toisen lukon vaiheeseen 3, jotkut muut saattavat laittaa toisen lukon.
Pidän kuvista :) Eikö epäsymmetrinen salaus olisi enemmänkin tällaista: palvelin lähettää tyhjän laatikon ja avoimen napsautettavan riippulukon ilman avainta, asiakas asettaa lukon yhdellä avaimella (pitää toisen avaimen), napsauttaa palvelimen lukon päälle, lähettää laatikon pois?
@tanius, ei aivan.Asiakas saa palvelimen avoimen riippulukon, luo yhdistetyn lukituskoodin, jonka se kirjoittaa muistiin ja laittaa laatikkoon, ja lukitsee sitten laatikon palvelimen lukolla.Palvelin avaa oman riippulukon vastaavalla avaimella ja kirjoittaa muistiin yhdistelmäkoodin käytettäväksi istunnon aikana.Siitä lähtien he käyttävät vain yhdistelmälukkoja.(symmetrinen avain).Oikeastaan voisin sanoa samaa kuin sinä, et ole varma.
En voi ymmärtää, miten analogia edustaa julkisen avaimen salausta.Voisiko joku selittää
Tämä fyysinen analogia edustaa kolmen passin protokollaa, ja se eroaa jonkin verran muista vastauksista, joten sitä ei voida käyttää vastauksena näihin vastauksiin, se on erilainen, pyydän julistajaa lisäämään muistiinpanon.
#4
+32
NDF1
2013-10-23 03:57:52 UTC
view on stackexchange narkive permalink

Monet jo annetuista vastauksista jättävät huomiotta Internet-palveluntarjoajan tai NSA: n sieppausominaisuudet. Tutustu AT&T-datakeskuksen huoneeseen 641A. Arviolta 10-20 tällaista laitosta on asennettu kaikkialle Yhdysvaltoihin. Katsokaa myös One Wilshire -rakennusta, jossa 260 Internet-palveluntarjoajan yhteydet yhdistyvät yhdeksi rakennukseksi. Tämä sijainti on ensisijainen sieppauslaitoksen sijainti.

Tosiasia on Internet-palveluntarjoaja (tai NSA: n ISP: hen asentama laite) voi siepata ja MITM hyökätä SSL-yhteyttä ja he voivat tehdä sen melko helposti.

  • Web-selaimessasi tai käyttöjärjestelmässäsi on yli 500 luotettua varmennetta. Tämä tarkoittaa, että luotat epäsuorasti kaikkiin verkkosivustoihin, joiden varmenteen on allekirjoittanut tämä varmenne.
  • NSA: n salaisella FISA-oikeuden määräyksellä NSA voi pakottaa minkä tahansa Yhdysvalloissa toimivan varmenteen myöntäjän heille juuritodistuksensa. Tuomioistuimen määräykseen sisältyy erityinen lausumaton lauseke, joka pakottaa CA: n pitämään suunsa kiinni vankeusrangaistuksesta, jos he puhuvat siitä. He eivät ehkä edes tarvitse tehdä tätä, mutta heidän on vain vakuutettava selaimen toimittajat hyväksymään yksi NSA: n omistama varmenne luotettavaksi selaimeen.
  • Kun liikenne kulkee Internet-palveluntarjoajat vaihtavat verkkosivuston todellisen julkisen avaimen NSA: n omalla julkisella avaimella, jonka allekirjoittanut vaarantunut varmentaja on suorittanut MITM-hyökkäyksen.
  • Verkkoselaimesi hyväksyy tämän väärän varmenteen luotettavaksi ja välität symmetrisen salausavaimen vaihdettavaksi takaisin NSA: lle / Internet-palveluntarjoajalle, joka pitää siitä kopion ja välittää saman avaimen verkkosivustolle.
  • Verkkosivustosi kanssa käytävä istunto puretaan reaaliajassa vaarantuneella symmetrisellä avaimella.
  • Salauksen puretut tiedot lähetetään valokuitulinjan kautta NSA: n päämajaan ja datakeskukseen Fort Meaden kellarissa. Tämä skannaa datasta satoja tai tuhansia avainsanoja, jotka voivat viitata erityyppisiin uhkiin. Kaikki avainsanat on merkitty analyytikoille punaisiksi, jotta ne voivat tarkastella ja priorisoida mahdolliset jatkotoimet. Lopulliset tiedot lähetetään yhdelle NSA: n Yhdysvaltojen tietovarastoista. Uusi varastotila on Utahin datakeskus, joka on todennäköisesti verkossa jo, koska sen oli tarkoitus olla verkossa viime kuun lopussa.

Tässä on kaavio nsawatchista .org:

the NSA surveillance octopus

Eivätkö he vain pakottaisi verkkosivuston ylläpitäjää luovuttamaan omat varmenteensa, mikä tekisi koko asiasta täysin avoimen. Jos NSA: n on luotava uusia varmenteita jokaiselle verkkosivustolle, varmenteen sormenjälkien seuraaminen paljastaa salakuuntelun. Esimerkiksi, jos yritykseni SSL-avaimen sormenjälki eroaa, kun käytän verkkosivustoa työssäni ja kun käytän sitä kotona, tiedän, että varmenne on vaarantunut. Samoin, jos he vain napauttavat kotini internet-yhteyttä, voin etsiä sormenjälkimuutoksia, jotka eroavat kodin ja toisen verkon välillä.
@Johnny:, joka toimisi jonkin verran, mutta käyttäjien laiskuutta tarkistaa varmenteiden allekirjoitukset jokaisesta vierailemastaan ​​suojatusta sivustosta tapahtuu useimmiten. Jotkut HTTPS-sivustot vaihtavat myös sertifikaatteja aikataulun mukaan (sanotaan joka 6. kuukausi), mikä tekee vaikeaksi kertoa, onko todistuksen allekirjoituksen muutos todellakin pätevä.
@Johnny Myös suuri osa Internetistä on käyttänyt Root CA: n läpinäkyvää vaihdettavuusvirhettä * ominaisuutena *. Nykyaikaisessa Internetissä liikkuminen työkaluilla, kuten [Certificate Patrol] (https://addons.mozilla.org/en-US/firefox/addon/certificate-patrol/), on painajainen "laillisista" vaihdoista ja kytkimistä, joita vakoojavirasto vaihtaa voisi piiloutua sisälle, kuten neula heinäsuovassa. Luovuin Cert Patorlin käytöstä tästä syystä. Taustalla oleva * v3 X.509 * -standardi on rikki.
@suriv Se ei ole epäilyttävä väite, se on tosiasia. Katso [National Security Letters] (https://en.wikipedia.org/wiki/National_security_letter) tai [Foreign Intelligence Surveillance Act] (https://en.wikipedia.org/wiki/United_States_Foreign_Intelligence_Surveillance_Court#Secret_law).
@NDF1 kumpikaan näistä artikkeleista ei tue väitettänne millään tavalla. Itse asiassa ne ovat ristiriidassa sen kanssa: "Lain mukaan NSL: t voivat pyytää vain muita kuin sisältötietoja, esimerkiksi liiketapahtumia ja soitettuja puhelinnumeroita"
[Tee tutkimuksia itse] (https://nakedsecurity.sophos.com/2014/01/29/lavabit-appeals-contempt-of-court-ruling-surrounding-handover-of-ssl-keys/). Katso myös [Avainlakeja] (https://fi.wikipedia.org/wiki/Key_disclosure_law), jotka voivat pakottaa yrityksen tai yksityishenkilön luovuttamaan SSL-avaimen oikeuden määräyksellä. FISA käsittelee salaisia ​​tuomioistuinten määräyksiä, joten jos se liittyy kansalliseen turvallisuuteen, se ei koskaan näe päivänvaloa. Jos on kansallisen turvallisuuden edun mukaista pakottaa varmentaja luovuttamaan juuriallekirjoitustodistus, he tekevät sen. Tietysti kaikki amerikkalaiset CA: t ovat alttiita tälle.
#5
+24
Hendrik Brummermann
2011-08-16 00:32:12 UTC
view on stackexchange narkive permalink

Yksinkertaisilla sanoilla: Salaus tapahtuu kahdella tavalla:

  • Ensin on julkisen / yksityisen avaimen salaus . Asiakas käyttää palvelimen julkista avainta (joka sisältyy varmenteeseen) salaamaan joitain tietoja, jotka vain palvelin voi purkaa salauksen käyttämällä yksityistä avainta.

  • Näiden tietojen perusteella johdetaan istuntoavain , jonka vain palvelin ja asiakas tuntevat. Tätä istuntoavainta käytetään tietojen salaamiseen.

Tämä on hyvin karkea yhteenveto.

Erilaisten estämiseksi tapahtuu paljon enemmän. hyökkäys:

#6
+18
Jeff Ferland
2011-08-16 00:55:07 UTC
view on stackexchange narkive permalink

Ajattelen jo kuutta vastausta, gowenfawr's selittää sen parhaiten. Lue ensin, koska tämä on yksinkertaisesti lisäys.

Diffie-Hellmanista

Useissa vastauksissa mainitaan Diffie-Helman -vaihdot. Ne toteutetaan vähemmistössä vaihdoissa. Palvelimen avain allekirjoittaa DH-vaihdon MITM -hyökkäyksen estämiseksi. Koska avainta ei ole salattu julkiseksi avaimeksi, sitä ei voida palauttaa käyttämällä kaapattua yksityistä avainta avainkeskuksen kaapattua liikennettä vastaan. Tämä on ajatus täydellisestä salaperäisyydestä. OpenSSL tarjoaa sekä "tavallisen" että DH-avaimen vaihdon kokoonpanosta riippuen.

MITM / Signature-ketjuissa

Sekä julkisen avaimen että DH-vaihdot estävät ketään yhteyden havaitsemisesta ja avaimen saamisesta. Tämä perustuu kokonaisiin matematiikkaongelmiin, joiden ymmärtämistä varten voit tutkia / tarkastella Thomasin vastausta. Kummankin ongelma on MITM-hyökkäys. Julkisen avaimen salauksessa tämä korjataan joko tietämällä julkinen avain etukäteen (vaikka vaihtoa noudatettaisiin) tai varmenteketjun avulla. Esimerkkejä: Luotan Aliceen, ja Alice allekirjoitti Bobin avaimen varmistaen, että se todella on hänen. Tunnetaan myös nimellä Google on sertifioitu ... err, Google. Näyttää siltä, ​​että he ovat Firefoxissa omana varmentajana. Joten random_bank's_ssl on Verisignin allekirjoittama, ja selaimesi luottaa siihen, että Verisign antaa vain laillisia varmenteita.

Tässä mallissa on ongelmia, kun törmäät esimerkiksi varmenteen myöntäjän vaarantumiseen. Tällöin MITM-hyökkäys on mahdollista.

#7
+13
apsillers
2013-10-23 02:06:14 UTC
view on stackexchange narkive permalink

SSL perustuu julkisen avaimen salaukseen. SSL: ään osallistuvalla palvelimella on avainparit , jossa on julkisia ja yksityisiä komponentteja.

Kuvittele, että sinulla on erityinen lukituslaatikko, jossa on kaksi avainta: yksi avain voi lukita laatikko, ja toinen voi avata laatikon lukituksen. Jos ystäväsi haluaa lähettää sinulle salaisen viestin, hän tarvitsee vain lukitus avaimen, ja voit pitää lukituksen avaimen yksityisenä .

Itse asiassa voit antaa vapaasti lukitus avaimesi kaikille. Päätät jättää pois kopiot erityisistä lukituslaatikoistasi ja lukitus avaimista etukuistilla, jotta kuka tahansa voi saada kopion. Pian kaikki koko kaupungissa voivat lähettää sinulle salaisia ​​viestejä postitse. Olet tehnyt lukitus avaimesi julkiseksi .

Jos ystäväsi Alice haluaa lähettää sinulle salaisen viestin, hän asettaa viestinsä lukituslaatikkoon ja lukitsee sen kopion julkisesta lukitusavaimestasi. Kaupunkisi postimestari suhtautuu sinuun ja Aliceen erittäin epäilevästi, mutta - vaikka hänellä onkin pääsy julkiseen avaimeesi - hän ei voi avata lukkolaatikkoa. Vain sinä, yksityisen lukituksen avaimen ainoa omistaja, voit avata Alice-lukitun laatikon.

Siten Internet-palveluntarjoajallesi (täällä, postimestarille) on pääsy julkiseen avaimeen , mutta se ei auta heitä purkaa julkisella avaimellasi salattuja viestejä. Julkinen avain salaa vain, ja vain yksityinen avain purkaa salauksen. Siksi yksityinen avain ei koskaan jätä omaisuuttasi, joten kenelläkään ei ole pääsyä siihen, paitsi sinä, joten kukaan ei voi kuunnella viestejäsi.

SSL antaa sinulle hieman enemmän suojaa (esim. Oletetaan, että postimestari heittää Alicen laatikon pois ja lähettää sinulle uuden viestin, joka teeskentelee olevansa Alice), mutta tämän pitäisi selventää, miksi Internet-palveluntarjoajasi ei voi yksinkertaisesti purkaa viestejäsi.

Minulla on kysymys. salaamme tiedot käyttämällä algoritmia ja puramme ne käyttämällä toisin kuin algoritmi. Joten jos meillä on raakatiedot ja julkinen avain, miksi emme voi purkaa salattua tietoa salauksen algoritmin vastakkaisella tavalla?
@AmirrezaNasiri Julkisen avaimen järjestelmät perustuvat matemaattisiin ongelmiin, joita on erittäin vaikea suorittaa päinvastoin. Katso [erillinen logaritmiongelma] (http://fi.wikipedia.org/wiki/Discrete_logarithm) yhdestä tällaisesta ongelmasta: `a = b ^ k mod q`: n kannalta on triviaalia laskea` a`, jos tiedät ` b`, `k` ja` q`. K: n löytäminen on kuitenkin vaikeaa, vaikka tiedätkin a, b ja q. Wikipedia-artikkelissa on hyvä esimerkki ja selitys.
#8
+11
deadalnix
2011-08-16 00:24:21 UTC
view on stackexchange narkive permalink

Katsokaa Diffie Hellmania: http://fi.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

Suorituskyvyn vuoksi yhteys on salattu symmetrinen avain. Mutta symmetrinen avain syntyy yhteyden muodostamisen aikana, eikä sitä koskaan vaihdeta selkeästi, mutta epäsymmetrisen salauksen avulla.

Asymmetrinen kryptografia on tekniikka, jota tarvitaan kaksi avainta: julkinen ja yksityinen. Mikä on salattu julkisella avaimella, on purettava salaus yksityisellä avaimella ja päinvastoin. Joten molemmat tietokoneet voivat vaihtaa tietoja toistensa julkisten avainten perusteella. Mutta vain vastaavan yksityisen avaimen omistaja voi purkaa avauksen. Yksityistä avainta ei koskaan vaihdeta, joten vaikka olisit haistanut kaiken, et voi purkaa mitään. Nämä tekniikat ovat laajoja, joten niitä käytetään avaimen vaihtamiseen symmetrisen salauksen avaimeen eikä itse tietoihin.

Vaikka Diffie Hellmania voidaan käyttää ja sillä on mukava ominaisuus välittää salassapitoa, sitä ei yleensä käytetä suorituskyvyn vuoksi.
@Hederik: Mutta se on helpoin salausprotokolla, joka antaa salaisuuden viestintäkanavassa, jota hyökkääjä voi vain kuunnella.
#9
+10
scuzzy-delta
2013-10-23 01:30:12 UTC
view on stackexchange narkive permalink

Transport Layer Security (jota Secure Sockets Layer kutsutaan nyt) sisältää menetelmiä salausavainten turvalliseen vaihtamiseen epävarmalla viestintäkanavalla (kuten Internet).

Kyllä, tämä tarkoittaa, että ISP voi nähdä avaimenvaihtotiedot kulkiessaan edestakaisin, mutta silti sillä ei ole riittävästi tietoja lukemaan viestivirtaa, kun suojattu yhteys on muodostettu.

Hyvin outo käsite, ja se on aivan uusi työ. Yleisin esimerkki tästä on nimeltään Diffie-Hellman Key Exchange, ja se keksittiin vasta 1970-luvulla.

Wikipedia-artikkelissa on kaikki herkulliset matemaattiset yksityiskohdat, mutta mielestäni alla oleva kuva (Wikimediasta) kuvaa käsitteen täydellisesti. Katso sitä, ajattele sitä, kokeile jopa itse, niin huomaat, että vastustaja ei voi mitenkään johtaa yksityistä avainta julkisesti katsottavista tiedoista.

enter image description here

#10
+7
LateralFractal
2013-10-23 06:18:06 UTC
view on stackexchange narkive permalink

Jos laitan mustan hatun (ei tämän mustan hatun... itse asiassa se hattu myös toimii):

Internet-palveluntarjoaja voi yksinkertaisesti suorittaa miehen - hyökkää mihin tahansa HTTP-sovellusten tai niiden korjaustiedostojen lataukseen ja päivitä siten selaimen luottamusketju suoraan tai päivitä se epäsuorasti itsetuhoisella troijalaisella.

Microsoft edellyttää, että ohjaimet ovat vain allekirjoitettuja; digitaalisia allekirjoituksia sovelluksille ja sovelluksia vastaavia suoritettavia tietoja ei pakoteta oletusarvoisesti *. Useimmat kuluttajien käyttöjärjestelmät eivät ole parempia pelkästään siksi, että pakollinen sovelluskoodin allekirjoittaminen (ja henkilöllisyyden todentaminen) maksaisi vain tarpeeksi , jotta heidän ohjelmistoekologiansa koko pienenisi huomattavasti.

* Huomautan, että en linkitä Microsoft Answers -ohjelmaan, ellei minun tarvitse. Heidän koulutetut apinansa käyttävät ilmeisesti rikki kirjoituskoneita.

Mukava ehdotus siellä. : D
Korjausprosessin MITM-tekeminen on erinomainen asia ... mutta minusta näyttää siltä, ​​että Internet-palveluntarjoajan olisi kompromissi päivityspalvelimen yksityisestä avaimesta (mikä mielestäni häiritsee NSA / TLA-aluetta). Onko sinulla mielessäsi tapahtumia?
@scuzzy-delta Suurempien organisaatioiden päivityspalvelimet ovat todennäköisesti digitaalisesti allekirjoitettuja korjaustiedostoprosessin tarkistamalla tavalla (esimerkiksi Blizzard-pelit); mutta pääosin suurin osa ensimmäisistä latauksista ei ole rajoitettu HTTPS-pääsykanavaan, eikä päivityksiä ole allekirjoitettu eikä tarkistettu korjaustiedoston automaatiolla, jos automaatiota on olemassa. Teoriassa upouuden OEM-tietokoneemme tulee toimittaa juurivarmentajien ROM-tietoväline, jonka OEM-laitoksesta riippumattomat tarkastajat ovat tarkistaneet, ja * kaikki * ladattu jälkikäteen HTTPS: n tai allekirjoitetun vastaavan avulla.
#11
+4
Zds
2011-08-16 00:21:58 UTC
view on stackexchange narkive permalink

Tärkeintä on epäsymmetrinen tai julkisen avaimen salaus. Se tarkoittaa, että sinulla on kaksi avainta, julkinen ja yksityinen, ja matemaattinen toiminto, joka on helppo laskea yhteen suuntaan, mutta hyvin, hyvin vaikea laskea toiseen.

Joten kun palvelimet lähettävät julkisen avain, voimme käyttää julkista avainta salaamaan tavaramme helposti, mutta vain parin toisen avaimen, tässä tapauksessa yksityisen avaimen, avulla voit purkaa sen helposti.

#12
+4
goodguys_activate
2011-09-21 05:34:23 UTC
view on stackexchange narkive permalink

EcoParty-konferenssi ilmoitti BEAST-nimisestä työkalusta, joka purkaa SSL3 / TLS1.0-liikenteen ja sitä alemman tason oletettavasti tarkkailemalla sitä.

Tässä on linkki uutisraportti

Olen varma, että tulevina päivinä kuulemme lisää tästä, kiertotavoista ja rajoituksista.

Tämä alla oleva osio päivitetään, kun lisätietoja löydetään

Tämä hakkerointi olettaa, että hyökkääjä voi jotenkin nähdä verkkoliikenteen; vakoiluohjelmana tai verkon sieppauksen kautta. Huonosti hallinnoidut koneet ja Wifi-käyttäjät ovat todennäköisimmin tavallisia epäiltyjä ... mutta eivät rajoitu vain kyseiseen käyttötapaukseen.

On raportteja, joiden mukaan tätä riskiä voidaan vähentää muuttamalla SSL * / TLS 1.0 -salausluetteloa RC4: ään, eivätkä tue vanhempia yhdistelmiä. Toinen lievennys on lisätä todennustunnuksen pituutta, mikä hidastaa hyökkäystä. Siteminder- ja ASP.net-jäsenyyden todennusevästeiden määritysten muokkaamisesta voi olla apua tässä.

Juuri niin, että tiedät, että tämän haavoittuvuuden paljastavat samat henkilöt, jotka ilmoittivat viime vuonna ASP.NET: n Padding Attackista. Tämä vanha ongelma asettaa jokaisen IIS-verkkopalvelimen vaaraan pelkästään käynnistämällä, mikä näyttää olevan vakavampi kuin tämä hyökkäys.

Jaa kaikki löytämäsi linkit, jotka mainitsevat tai vahvistavat nämä haavoittuvat skenaariot tai lieventämiset täällä. Nykyisessä muodossaan osa tästä on spekulaatiota, jota salauksen asiantuntijat eivät ole tarkistaneet.

BEAST näyttää olevan hyökkäys vain HTTPS: ää vastaan, mutta tämä virhe näyttää olevan SSL3 / TLS1.0: ssa. Ovatko muut SSL / TLS 1.0 -ohjelmaa käyttävät sovellukset alttiita samanlaiselle ei-JavaScript-hyökkäykselle?
#13
+3
sahmeepee
2013-10-23 01:20:57 UTC
view on stackexchange narkive permalink

Ei, he eivät pidä avainta, koska muodostamasi yhteys on sinun ja kohdesivuston (esim. Amazon) välillä, joten Internet-palveluntarjoajalla ei olisi tietoa avaimesta.

Yleisempi kysymykseen siitä, miten SSL / TLS toimii, vastataan täällä.

#14
-1
WTH
2017-03-28 18:00:39 UTC
view on stackexchange narkive permalink

Täällä on paljon hyviä vastauksia, varsinkin ne, joissa puhutaan DH: n tai ECDH: n suorittamisen ulkopuolisista asioista (esim. asiakaspuolen korruptio / varmenteen asennus / varmenteen kaappaus jne.)

Jos sivuuttamalla itse paikallisen koneen ja yksinkertaisesti huolestunut MITM: stä - tarvitset DH / ECDH- ja SSL-kiinnityksen. SSL-kiinnitys on yleistymässä, mutta ei silti ole kaikkialla läsnä tänään. Tämä tarkoittaa, että Internet-palveluntarjoajasi voi yksinkertaisesti teeskennellä olevansa palvelimesi niin kauan kuin sillä on voimassa oleva SSL luottamusketjussa. SSL-kiinnitys varmistaa, että yhdistetyn palvelimen käyttämä SSL-varmennus on sen palvelimen sertti, johon yrität päästä.

Jälleen, jos haluat olla turvassa hallitukselta tai hakkereilta - Tämä ei riitä. Jos haluat estää Internet-palveluntarjoajaasi etsimästä tietojasi - tämä todennäköisesti riittää.

Vaikka tämä saattaa olla hyödyllistä neuvoja TLS: lle yleensä, en ole varma, että se todella vastaa tässä esitettyyn kysymykseen.
Se on parempi kuin yllä oleva, joka sanoo vain "koska" taikuus "" ... Outoa aliarvioida, koska en viitsi kopioida kaikkia muita vastauksia, vaan lisäsin niihin asioita, jotka ovat todella tärkeitä modernissa SSL / TLS: ssäliitännät.Siksi huomautin erityisesti, että monet vastauksista ovat hyviä ja kattavat joitain syitä, miksi tietoja ei voida purkaa - ja huomautan sitten, että ne ovat epätäydellisiä.Voin MITMIN sinut ECDH / DH: lla huolimatta siitä, mitä korkeimman vastauksen sanotaan - koska vastaus on puutteellinen.Ilman kiinnittämistä ja turvallista paikallista luottamusmyymälää - olet epävarma.
En sano, että antamasi tiedot ovat huonoja tai vääriä - eivät ole.Sanon, että se ei vastaa kysymykseen.Kysymys: "Kuinka on mahdollista, että HTTPS-yhteyttä muodostavat ihmiset eivät tietäisi sen salauksen purkamista?"Vastaus: "Tarvitset DH / ECDH: n ja SSL: n kiinnityksen."Se ei ole ottelu.
Varmasti sinä alensit vastausten alkuosan: "Monet jo annetuista vastauksista jättävät huomiotta Internet-palveluntarjoajan sieppausominaisuudet" "Ajattelen jo kuutta vastausta, gowenfawr selittää sen parhaiten. Lue se ensin, koska tämä on yksinkertaisesti lisäys." "Jos laitan mustan hatun (ei tämän mustan hatun ... oikeastaan myös sen hatun") "Avaintekijä on epäsymmetrinen eli julkisen avaimen salaus" "EcoParty-konferenssi ilmoitti työkalun nimeltä BEAST" sitten - koska kukaan heistä ei myöskään vastaa kysymykseen.Se ei ole iso juttu, se näyttää vain melko pikkumaiselta.DV ei ole sitä varten.


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...