ChiaroScuro Skrevet 18. februar 2016 Del Skrevet 18. februar 2016 Jeg skjønner ikke hvordan det virker. Skal noe krypteres av en og dekrypteres av en annen er begge avhengig av å ha en nøkkel. Ja, en nøkkel kan krypteres, men da må mottaker ha denne nøkkel nøkkelen. Jeg kan sitte på en router og logge trafikk. Jeg ser at den er kryptert, men jeg ser ingen nøkkel som sendes før det krypterte innhold. Https skaper en sikker kanal fra a til b som forhindrer at noen, sånn som jeg, kan sitte mellom de to endene på kanalen og se hva som utveksles. Hvordan kan Https formidle en nøkkel uten at jeg ser den? Det kan jo ikke være en "Universell nøkkel"? Jeg tror ikke at svaret er, som en venn av meg sa, at nøkkelen sendes via en annen "rute". Ikke misforstå. Det er flott at det lar seg gjøre. Jeg vil heller ikke vite hvordan det gjøres. Jeg må få vite prinsippet ellers får jeg ikke sove. Lenke til kommentar
Kikert Skrevet 18. februar 2016 Del Skrevet 18. februar 2016 Etter hva jeg forstår så kan det sammenliknes med kodebrikke man får av banken? https://en.wikipedia.org/wiki/HTTPS#Security Lenke til kommentar
Emancipate Skrevet 18. februar 2016 Del Skrevet 18. februar 2016 Det kan jo ikke være en "Universell nøkkel"?Jo, det er nettopp det det er. http://www.dailytech.com/FBI+NSA+Want+Master+Encryption+Keys+from+Internet+Companies/article32046.htm Jeg har ikke detaljene, men om du går inn på en SSL-side og får meldingen om at sertifikatet er utløpt, eller at sertifikatet ikke er signert, så kan det sitte noen i mellom. Eventuelt kan noen ha fått tak i nøkkelen til en utsteder av sertifikater. Lenke til kommentar
Sokkalf™ Skrevet 18. februar 2016 Del Skrevet 18. februar 2016 Server og klient blir enige om krypteringsnøkkel og -metode på forhånd, se https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake Lenke til kommentar
Sokkalf™ Skrevet 18. februar 2016 Del Skrevet 18. februar 2016 Det kan jo ikke være en "Universell nøkkel"?Jo, det er nettopp det det er. http://www.dailytech.com/FBI+NSA+Want+Master+Encryption+Keys+from+Internet+Companies/article32046.htm Jeg har ikke detaljene, men om du går inn på en SSL-side og får meldingen om at sertifikatet er utløpt, eller at sertifikatet ikke er signert, så kan det sitte noen i mellom. Eventuelt kan noen ha fått tak i nøkkelen til en utsteder av sertifikater. Når du setter opp et SSL-sertifikat på din egen server, er det med en nøkkel du genererer selv. Det gir mening at FBI/NSA vil ha Facebooks, Microsofts, etc nøkler, da det går SVÆRT mye trafikk som er kryptert med disse nøklene, men det finnes ingen universell nøkkel for alt. Et SSL-sertifikat er gjerne også signert av et certificate authority som er "trusted", dvs, det som gir deg "grønn status" i nettleseren, men dette gir heller ingen noen mulighet til å dekryptere trafikken siden din nøkkel er privat. Det er forskjell på signering og kryptering. Lenke til kommentar
ChiaroScuro Skrevet 18. februar 2016 Forfatter Del Skrevet 18. februar 2016 Server og klient blir enige om krypteringsnøkkel og -metode på forhånd, se https://en.wikipedia.org/wiki/Transport_Layer_Security#TLS_handshake OK, Rimer, men jeg har ikke funnet de pakkene. Jeg trodde mer på en "Management" løsning som med NX 1000 og TCE621. Lenke til kommentar
ChiaroScuro Skrevet 18. februar 2016 Forfatter Del Skrevet 18. februar 2016 Det kan jo ikke være en "Universell nøkkel"?Jo, det er nettopp det det er. http://www.dailytech.com/FBI+NSA+Want+Master+Encryption+Keys+from+Internet+Companies/article32046.htm Jeg har ikke detaljene, men om du går inn på en SSL-side og får meldingen om at sertifikatet er utløpt, eller at sertifikatet ikke er signert, så kan det sitte noen i mellom. Eventuelt kan noen ha fått tak i nøkkelen til en utsteder av sertifikater. Når du setter opp et SSL-sertifikat på din egen server, er det med en nøkkel du genererer selv. Det gir mening at FBI/NSA vil ha Facebooks, Microsofts, etc nøkler, da det går SVÆRT mye trafikk som er kryptert med disse nøklene, men det finnes ingen universell nøkkel for alt. Et SSL-sertifikat er gjerne også signert av et certificate authority som er "trusted", dvs, det som gir deg "grønn status" i nettleseren, men dette gir heller ingen noen mulighet til å dekryptere trafikken siden din nøkkel er privat. Det er forskjell på signering og kryptering. Ok, så jeg formidler en "egen nøkkel" kryptert med MS, FB eller Google etc. sin? Altså "Management" som jeg trodde. Lenke til kommentar
Emancipate Skrevet 18. februar 2016 Del Skrevet 18. februar 2016 (endret) Et SSL-sertifikat er gjerne også signert av et certificate authority som er "trusted", dvs, det som gir deg "grønn status" i nettleseren, men dette gir heller ingen noen mulighet til å dekryptere trafikken siden din nøkkel er privat. Det jeg har lest er at hvis man får tak i nøkkelen til en certificate authority så kan man foreta man-in-the-middle attack. Her har vi det: http://www.zdnet.com/article/how-the-nsa-and-your-boss-can-intercept-and-break-ssl/ If your company has set up the proxy correctly you won't know anything is off because they'll have arranged to have the proxy's internal SSL certificate registered on your machine as a valid certificate. If not, you'll receive a pop-up error message, which, if you click on to continue, will accept the "fake" digital certificate. In either case, you get a secure connection to the proxy, it gets a secure connection to the outside site -- and everything sent over the proxy can be read in plain text. Whoops. Hvis man nå har nøkkelen som brukes hos en certificate authority for å utstede signaturer så kan man lage "ekte" falske sertifikater - altså at de får grønn lås og uten spørsmål. Endret 18. februar 2016 av Emancipate Lenke til kommentar
ChiaroScuro Skrevet 18. februar 2016 Forfatter Del Skrevet 18. februar 2016 Et SSL-sertifikat er gjerne også signert av et certificate authority som er "trusted", dvs, det som gir deg "grønn status" i nettleseren, men dette gir heller ingen noen mulighet til å dekryptere trafikken siden din nøkkel er privat. Det jeg har lest er at hvis man får tak i nøkkelen til en certificate authority så kan man foreta man-in-the-middle attack. Her har vi det: http://www.zdnet.com/article/how-the-nsa-and-your-boss-can-intercept-and-break-ssl/ If your company has set up the proxy correctly you won't know anything is off because they'll have arranged to have the proxy's internal SSL certificate registered on your machine as a valid certificate. If not, you'll receive a pop-up error message, which, if you click on to continue, will accept the "fake" digital certificate. In either case, you get a secure connection to the proxy, it gets a secure connection to the outside site -- and everything sent over the proxy can be read in plain text. Whoops. Hvis man nå har nøkkelen som brukes hos en certificate authority for å utstede signaturer så kan man lage "ekte" falske sertifikater - altså at de får grønn lås og uten spørsmål. Nyttig info. Trekker tilbake spørsmålet om "Management" Dette synes å være ren client-tjener beskyttelse mot en "Man in Middle" Takk skal du ha. Lenke til kommentar
ZeRKoX Skrevet 18. februar 2016 Del Skrevet 18. februar 2016 Sorry for wall of text, men det er litt detaljer som trenger litt forklaring Ikke misforstå. Det er flott at det lar seg gjøre. Jeg vil heller ikke vite hvordan det gjøres. Jeg må få vite prinsippet ellers får jeg ikke sove. Trikset er noe som kalles asymmetrisk kryptering. Det er krypteringsalgoritmer som fungerer slik at det er to nøkler involvert, og det som er kryptert med den ene kan bare dekrypteres med den andre. Vi kaller ofte disse nøklene for offentlige (public) og private nøkler. Så det facebook f.eks da gjør er å helt åpent poste den offentlige nøkkelen sin slik at du og alle andre kan laste ned denne. Når du da bruker denne nøkkelen for å kryptere data som du sender til facebook, så vil ikke du eller noen andre som har denne nøkkelen kunne dekryptere disse dataene fordi du da trenger den private nøkkelen. Den private nøkkelen er det bare facebook som har, og det er kun de som trenger denne. Med den private nøkkelen kan de dekryptere hva enn du sender til de. Det å kryptere ting med asymmetrisk kryptering er treigere enn å bruke symmetrisk kryptering (kryptering der samme nøkkel kan kryptere og dekryptere), så det som ofte blir gjort er at du og facebook sammen kommuniserer bittelitt med asymmetrisk kryptering for å bli enig om en symmetrisk nøkkel dere skal bruke for en gitt sesjon (dette kalles typisk nøkkelutveksling på norsk), og deretter bruker dere denne. Denne krypteringsprosessen fungerer helt fint, selv om du har "ugyldige" sertifikat. Sertifikatet inneholder riktignok den offentlige nøkkelen, men den blir ikke mindre sikker om sertifikatet går ut på dato eller så. Var dette oppklarende for hvordan HTTPS krypteringen fungerer, uten at en på forhånd har blitt enige om nøkler? Nå over på noe relatert, men litt annet alikevel; sertifikatene. Problemet med krypteringsskjemaet som er nevnt over er jo at du henter en offentlig nøkkel fra facebook som du så bruker til å kryptere din info som du så sender til facebook. I det skjemaet der er det jo ingenting som hindrer f.eks meg å sette opp min egen server på vei mellom deg og facebook, og så kan jeg bestemme hvilken nøkkel du laster ned. Ett såkallt MITM angrep. For å unngå falske servere slik som dette bruker man signerte sertifikater. Dette fungerer ca slik: På pc-en din har du en rekke sertifikater som du på forhånd "stoler" på (Altså; du har en rekke sertifikater som microsoft, apple, google m.fl. (De som lager OS-et du bruker, nettleseren du bruker og så videre) annser som trygge). Disse sertifikatene inneholder blandt annet en offentlig nøkkel, på lik linje som om at sertifikatet du hentet fra facebook hadde en offentlig nøkkel, men det er ikke samme nøkkelen. Vi har massevis av slike forhåndsinstallerte sertifikater, og de hører til noe vi kaller for CA (Certificate Authority). Siden det er en offentlig nøkkel, så har noen også en privat nøkkel ett eller annet sted. Når f.eks jeg vil sette opp en side med HTTPS lager jeg meg da ett nøkkelpar (en privat nøkkel med en tilhørende offentlig nøkkel), og så sender jeg den offentlige nøkkelen samt litt ekstra informasjon som domenenavn og slikt til en CA, og dette kalles for en CSR (Certificate Signing Request). En CSR er nesten ett helt sertifikat likt som det du får fra facebook når du besøker de. Jeg må så på ett eller annet vis bevise ovenfor CA at jeg eier det domenet som jeg sier at jeg har. Når CA er overbevist om at jeg er den jeg påstår at jeg er, så vil han lage en ett sertifikat for meg, som inneholder informasjonen jeg sendte med CSR-en, samt litt informasjon om sitt eget sertifikat. Han lager så en hash (sha1, sha256 eller lign.) av dette sertifikatet, krypterer denne hashen med sin egen private nøkkel, og så legger han denne krypterte hashen inn i sertifikatet han nettopp lagde. Nå er sertifikatet signert. Dette sertifikatet sendes til meg som bestillte dette, da det nå er klart til bruk. Legg merke til at jeg ikke på noe tidspunkt har hatt behov for å sende min private nøkkel til CA. Dette er en stor fordel, fordi da kan jeg vite at selv om CA har signert mitt sertifikat, så kan ikke han lese min trafikk. Det er det nemlig bare jeg som kan gjøre. Når jeg nå setter opp nettsiden min, med dette fine sertifikatet, så er siden klar for at du skal komme på besøk. Det som skjer da er at du først laster ned sertifikatet fra meg. Sertifikatet er jo offentlig, så det trenger ingen form for kryptering. Du vil så verifisere at sertifikatet er ekte, så det du da gjør er å først kikke i sertifikatet for å se hvilken CA som har signert det. Så leter du på din egen maskin etter CA-en sitt sertifikat, og når du finner dette så henter du ut CA-ens offentlige nøkkel fra dette sertifikatet. Nå henter du ut den krypterte hashen fra mitt sertifikat (som CA tidligere har kryptert med sin private nøkkel) og prøver å dekryptere denne med CA-ens offentlige nøkkel. Da sitter du igjen med en ukryptert hash. Du lager så en hash av resten av mitt sertifikat, og sammenligner denne med hashen som du nettopp dekrypterte, og er disse like så vet du at sertifikatet du hentet fra meg er det samme sertifikatet som CA på ett tidligere tidspunkt sjekket at virkelig tilhørte meg. Siden du nå vet at du snakker med min webserver, og ikke en som later som om at han er meg, så kan du bruke den offentlige nøkkelen i mitt sertifikat for å kommunisere med meg slik jeg beskrev lengre oppe. Ble dette oppklarende? 5 Lenke til kommentar
Emancipate Skrevet 18. februar 2016 Del Skrevet 18. februar 2016 (endret) Nå henter du ut den krypterte hashen fra mitt sertifikat (som CA tidligere har kryptert med sin private nøkkel) og prøver å dekryptere denne med CA-ens offentlige nøkkel.Jeg var med helt til dette. Man får ikke dekryptert noe med en offentlig nøkkel med asymmetrisk kryptering. Endret 18. februar 2016 av Emancipate Lenke til kommentar
Imsvale Skrevet 19. februar 2016 Del Skrevet 19. februar 2016 (endret) Nå henter du ut den krypterte hashen fra mitt sertifikat (som CA tidligere har kryptert med sin private nøkkel) og prøver å dekryptere denne med CA-ens offentlige nøkkel.Jeg var med helt til dette. Man får ikke dekryptert noe med en offentlig nøkkel med asymmetrisk kryptering. Joda. Hvem som helst kan da dekryptere med den offentlige nøkkelen. Det du kan bruke dette til er å verifisere at informasjonen ble kryptert av den som sitter på den private nøkkelen – i dette tilfellet at den krypterte hashen i sertfikatet faktisk ble kryptert av den aktuelle CA-en. Da skal du trygt kunne anta at sertfikatet ble utstedt av denne CA-en, nettopp det du var interessert i å sjekke (Edit: Dvs. hvis/når du får en match med hashen du selv lagde av sertfikatet). Endret 19. februar 2016 av Imsvale Lenke til kommentar
Emancipate Skrevet 19. februar 2016 Del Skrevet 19. februar 2016 Men det kan ikke være vanlig public key-kryptografi. Lenke til kommentar
Imsvale Skrevet 19. februar 2016 Del Skrevet 19. februar 2016 Men det kan ikke være vanlig public key-kryptografi. Hva er vanlig? Lenke til kommentar
Emancipate Skrevet 19. februar 2016 Del Skrevet 19. februar 2016 At man har en public key som krypterer, og en private key som låser opp...https://en.wikipedia.org/wiki/Public-key_cryptography Public-key cryptography refers to a method of encryption (i.e. garbling a message so that unintended people cannot read it) in which for each person a pair of keys (digital codes) are involved, one called the public key, which is disseminated widely, and one called the private key, which is known only to the intended recipient. Any person can encrypt a message for a specific person, say Alice, using Alice's public key, which is known to everyone. However this message can now be decrypted only through Alice's private key. Thus a message intended for Alice can be encrypted and safely hosted in public servers without an unintended recipient being able to read it. This system of using two different paired keys is called an asymmetric key encryption Lenke til kommentar
process Skrevet 19. februar 2016 Del Skrevet 19. februar 2016 (endret) Nå henter du ut den krypterte hashen fra mitt sertifikat (som CA tidligere har kryptert med sin private nøkkel) og prøver å dekryptere denne med CA-ens offentlige nøkkel.Jeg var med helt til dette. Man får ikke dekryptert noe med en offentlig nøkkel med asymmetrisk kryptering. Det er ingen ting i veien (iaf. med RSA) for å benytte offentlig nøkkel til dekryptering, det avhenger kun av hvilken nøkkel som er benyttet til å kryptere. Det er for eksempel slik signering fungerer (som beskrevet her). Er målet derimot å holde noe hemmelig for de som ikke innehar privatnøkkelen gjør man motsatt og krypterer med privat nøkkel.* (*) I praksis gjøres ofte selve krypteringen med en symmetrisk nøkkel (gjerne AES), som igjen krypteres med den aktuelle privatnøkkelen offentlige nøkkelen. Dette er av ulike årsaker; 1. du skal ikke kryptere datamengde som overgår keysize med en asymmetrisk nøkkel, 2. hastighet og 3. du kan bytte asymmetrisk nøkkel uten å dekryptere+kryptere all data. EDIT: s/privat/offentlig/ - går litt fort i svingene. Endret 19. februar 2016 av process Lenke til kommentar
Imsvale Skrevet 19. februar 2016 Del Skrevet 19. februar 2016 (endret) At man har en public key som krypterer, og en private key som låser opp... https://en.wikipedia.org/wiki/Public-key_cryptography Public-key cryptography refers to a method of encryption (i.e. garbling a message so that unintended people cannot read it) in which for each person a pair of keys (digital codes) are involved, one called the public key, which is disseminated widely, and one called the private key, which is known only to the intended recipient. Any person can encrypt a message for a specific person, say Alice, using Alice's public key, which is known to everyone. However this message can now be decrypted only through Alice's private key. Thus a message intended for Alice can be encrypted and safely hosted in public servers without an unintended recipient being able to read it. This system of using two different paired keys is called an asymmetric key encryption At det ikke nevnes der gjør det ikke mindre vanlig i faktisk bruk, bare mindre interessant for publikum. Edit: Lenger ned i samme artikkel: Digital signatures Main article: Digital signature The goal of a digital signature scheme is to ensure that the sender of the communication that is being sent is known to the receiver and that the sender of the message cannot repudiate a message that they sent. Therefore, the purpose of digital signatures is to ensure the non-repudiation of the message being sent. This is useful in a practical setting where a sender wishes to make an electronic purchase of shares and the receiver wants to be able to prove who requested the purchase. Digital signatures do not provide confidentiality for the message being sent. The message is signed using the sender's private signing key. The digitally signed message is then sent to the receiver, who can then use the sender's public key to verify the signature. Endret 19. februar 2016 av Imsvale Lenke til kommentar
process Skrevet 19. februar 2016 Del Skrevet 19. februar 2016 At man har en public key som krypterer, og en private key som låser opp... https://en.wikipedia.org/wiki/Public-key_cryptography Public-key cryptography refers to a method of encryption (i.e. garbling a message so that unintended people cannot read it) in which for each person a pair of keys (digital codes) are involved, one called the public key, which is disseminated widely, and one called the private key, which is known only to the intended recipient. Any person can encrypt a message for a specific person, say Alice, using Alice's public key, which is known to everyone. However this message can now be decrypted only through Alice's private key. Thus a message intended for Alice can be encrypted and safely hosted in public servers without an unintended recipient being able to read it. This system of using two different paired keys is called an asymmetric key encryption Det er bare et eksempel på et vanlig bruksområde. Det er ikke en uttømmende beskrivelse av hvordan PKI fungerer. Lenke til kommentar
Emancipate Skrevet 19. februar 2016 Del Skrevet 19. februar 2016 Så det dere sier er at den private nøkkelen finnes hos den som skal verifisere signaturen, og den offentlige finnes hos den som signerer? Og av en eller annen grunn så finner dere det smart å da kalle den private offentlig og omvendt? Lenke til kommentar
Imsvale Skrevet 19. februar 2016 Del Skrevet 19. februar 2016 Så det dere sier er at den private nøkkelen finnes hos den som skal verifisere signaturen, og den offentlige finnes hos den som signerer? Og av en eller annen grunn så finner dere det smart å da kalle den private offentlig og omvendt? Nei nei. Jeg la inn et stykke om digital signatur i mitt forrige innlegg. 1 Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå