Er der nogle der kan forklare mig hvad "Diffie-Hellman Key Exchange" går ud på og og forklare mig den tegning på siden? jeg forstår det simpelthen ikke..
Du har fat i noget af det vandskelige ved forståelsen af IPSec. jeg starter her med lidt generelt og i aften får du så noget mere når jeg kommer hjem og får adgang til mit undervisningsmateriale.
Diffie-Hellman er en algoritme hvormed man i et offentligt rum kan udveksle de oplysninger der skal til at danne samme nøgle ved begge parter, uden at andre kan danne nøglem. Sagt på en anden måde. Hvis du og jeg skulle lave en nøgle til kryptering af vores kommunikation, og vores eneste kommunikations middel er dette spørgsmål, vil vi med Diffie-Hellman kunne odveksle oplysninger som andre kan læse, men stadig ende op med en nøgle som kun du og jeg kender. (dette kan vi prøve i aften)
Asymmetrisk Encryption and decryption performed using two different keys, one of which is referred to as the public key and one of which is referred to as the private key. Also known as public-key encryption. (Stallings) www.hipaabasics.com/glossary.htm
symmetrisk Also called conventional encryption, this is any encryption system where the same key is use for both encryption and decryption. This requires that the key must be securely transmitted between the encryptor and decryptor. www.bifroest.demon.co.uk/ctc/manuals/glossary.htm
Forskellen er at med Asymmetrisk kryptering bruges forskellig nøgler til kryptering og dekryptering med symmetrisk bruges samme nøgle
DH key-exchange protokollen forloeber som foelger (mellem A og B):
Step 1) A og B vaelger i faellesskab et (stort) primtal p, og et tal g der er indbyrdes prim med p. Disse tal er offentlige, og maa gerne vaere tilgaengelig for andre - men maa selvfoelgelig ikke kun aendres af andre..
Step 2) A vaelger et tilfaeldigt heltal x ("private value") (melllem 1 og p-1), regner Xa ("public value") ved g**x (mod n), og sender dette til B. B goer det samme med et nyt tal y i stedet for x, og sender hans udregning til A. A har nu x og Yb, og B har y og Xa.
Step 3) A regner Yb**x (mod n) og B regner Xa**y (mod n), hvilket giver det samme tal, som vi betegner k.
Problematikken er at A og B skal blive enige om en faelles hemmelighed, som de evt. kan bruge som noegle til kryptering af deres beskeder til hinanden. Dette gaelder for alle public-key systemer..
DH bruger den matematiske envejs-funktion "g**x (mod n)" (** betyder oploeftet i, altsaa 2**4 = 2*2*2*2) som har den egenskab at det er "nemt" at regne den ene vej, men "svaert" at regne den anden vej - den anden vej betyder at du udfra resultatet af g**x (mod n) skal finde vaerdien af x. Denne problemstilling er kendt som Discrete Logarithm Problem, og _anses_ for at vaere ubrydelig.
Grunden til at DH kan bruges er, at (g**x)**y (mod n) = (g**y)**x (mod n) - det matematiske bevis maa du spoerge om eksplicit, hvis det er noedvendigt ;) - men at det som sagt er "svaert" at beregne hvis du kun kender g**x (mod n) og/eller g**y (mod n), og altsaa ikke kender vaerdien af x eller y.
hmm. Jeg har siddet og funderet lidt over det regneeksempel men tror jeg springer det advancerede i DH over.
Istedet, er det jeg mangler simpelthen hvilke krypteringsmedtoder det bruges i henhold til vpn. Altså hvilke protokoller der benytter hvad osv. Er det noget du ved noget om? Jeg har skrevet om den asymetriske og symestriske kryptering..
En hash-algoritme indenfor kryptologi, er en envejs-funktion der tager et input af vilkaarlig laengde (f.eks. en fil) og giver et "fingeraftryk" som output (af fast laengde). De har nogle yderligere egenskaber der anskiller dem fra traditionelle hash-funktioner (som f.eks. i en hash-tabel), bl.a.: * Hvis du kun har aftrykket, kan du ikke bestemme det oprindelige input * Givet et input (og aftrykket af dette) kan du ikke bestemme et andet input der giver samme aftryk
Jeg ved ikke helt hvad du mener med SSL til gateways, men det ligger ikke på netværkslaget (session- eller applikation-niveauet, alt efter model). Tænk f.eks. på at du bruger https i stedet for http..
Forskellen på VPN og SSL er at SSL er en Socket Layer protokol (ssl står for secure socket layer. DVS du kan f.eks lave en krypteret port 80 tunnel, eller en krypteret port 25 tunnel. MED VPN kan du lave en krypteret tunnel hvorigennem du kan kører både port 80, 25, 110, 445, osv osv osv.
En socket er kombinationen af en IP adresse og en port
Hmm så tror jeg at jeg har misforstået noget:S er det da ikke rigtigt at SSL kan bruges når vi taler VPN, til virksomheder der outsourcer deres VPN til en ISP? altså hvor udbyderen driver VPN serveren... Mener da at jeg har læst at SSL giver brugerne mulighed for at tilslutte sig en VPN server kun med en browser? er det ikke sandt?
Når du taler browser så er det rigtigt, den bruger jo også kun en port. Dette betyder at du bruger SSL til at sikre den forbindelse op til ISP'ens VPN boks, men kun den forbindelse du bruger til at administreree boksen med, dette foregår via en browser. Du kan ikke samtidig sende mails med outlook over den forbindelse.
Så skal du bruge SSH, der ofte forveksles med SSL. SSH er en fuld VPN tunnel
hmmmsådan kan du gård betragte det. SSH er en noget enklere model end IPSec og der har været en del sikkerhedsproblemer med protokollen. SSH kræver en klient og giver meget mindre funktionalitet end IPSec, hvilket kan være en fordel nogle gange.
Jeg bruger selv SSH hvis jeg har behov for enkle ting. F.eks. kommando prompt adgang til en server eller en maskine. Skal jeg lave en fukld funktionel VPN forbindelse bruger jeg IPSec. Du skal så tænke dig om, da IPSec har problemer med NAT. Dette betyder at du enten skal håndtere dette, eller bruge en proparitær IPSec løsning, f.eks. Cisco VPN der har løst nat problemerne
IPSec tilfoejer et lag imellem netvaerks- og transport-laget, og indkapsler trafik fra host til host - dvs. de kommunikerende processer er ikke klar over at de bliver afviklet over en krypteret tunnel. SSL derimod ligger paa applikationslaget, hvilket vil sige at de kommunikerende processer selv skal staa for oprettelse af en tunnel. Der er dog den undtagelse, at man, f.eks. med SSH, kan "forwarde" en lokal port til en fjern port, og paa den maade undtage processerne fra selv at blive indblandet i kryptering - men det er stadigvaek paa applikationslaget.
Kortere saa er det typisk kernen i dit styresystem eller gatewayen i dit lokalnetvaerk der soerger for IPSec, mens det er de enkelte processer der maa staa for SSL.
Det er det der menes i dokumentet fra IACR: IPSec "is an IP layer protocol that enables the sending and receiving (of cryptographically protected) packets of any kind (TCP, UDP, ICMP etc)". .. "SSL is an application layer protocol. .. SSL is compatible with applications running only over TCP.." Og fra konklusionen "If a specific service is required and is supported by SSL, it is better to select SSL. If over all services og Gateway-to-Gateway communications are needed then IPSec is a good choice.."
Ifølge de oplysninger jeg har fundet på nettet er frame relay en forgænger til VPN. Men laver frame relay også denne tunnel ligesom vpn? for så kunne man jo entlig godt benytte frame relay istedet..?
Hmm, for et par aar siden laeste jeg i Tanenbaums om frame relay men har ikke brugt det siden - saa er lidt rusten omkring det..
Men som jeg forstod det dengang, saa bruger man frame relay til kommunikation mellem to gateways (som IPSec) - men frame relay fokuserer mere paa det at faa data frem og tilbage i stedet for paa at goere det beskyttet. Dvs. frame relay ligger ikke ovenpaa TCP/IP, modsat IPSec. Men som sagt er jeg ikke sikker..
IPSec kan ikke hådtere NAT som standard. Afhængig af hvordan du tilkobler VPN tunnelen til dit net vil det give problemer i forhold til nat. VPN kan tilkobles på 4-5 fortskellige metoder der hver har deres fordele og ulemper, nogle er mere sikre end andre, nogle har nat problemer og nogle kræver at du retter i routing tabellen.
En VPN tunnel kan f.eks. tilkoblem på følgende måder
Tunnelen enden i routeren. Dette betyder at trafikken ikke er krypteret mellem routeren og firewallen. her er der nat problemer
Tunnelen slutter i firewallen og VPNgatewayen er integreret i firewallen, dette kan give kapasitetsproblemer ved meget trafik
Tunnelen er tilkoblet som en løkke på firewallen, denne løsning giver storsikkerhed, da den krypterede tunnel først skal gennem firewallen hvor den kan filtreres f.eks. på afsender IP, hvorefter den dekrypterede trafik skal tilbage ind gennem firewallen, hvor den igen kan filtreres. her er der nat problemer.
VPN tunnelen føres uden om firewallen. her bliver VPN trafikken ikke filtreret hvilket selvfølgelig giver sikkerhedsproblemer.
Jeg husker ikke helt hvordan de forskellige løsninger har det med NAT, men jeg kan slå det op hvis det har interesse
Dedikerede tunneler kan sagtens køre ip, vil faktisk ofte gøre det Dial-up kan kører forskellige former for ppp f.eks. PPPoA (atm) eller PPPoE (ethernet) men også IP
kan du ikke lige forklare dette: RSA og andre asymetriske algoritmer bør ikke anvendes til store data mængder. Kun til at kryptere en random key til en symmetrisk algoritme med.
og vil det sige at når medarbejdere skal arbejde hjemmefra vil det blive for tungt hvis der skal køres en asymetrisk algoritme..? Jeg kan bare ikke forstå det for jeg synes da at have læst at mange firmaer kører det asymestrisk?
Asymmetriske algoritmer er ikke beregnet til store data mængder og der er stor tvivl om deres sikkerhed ned store data mængder.
Så man bruger vælger en symmetrisk og en asymmetrisk algoritme, man genererer en random key til den symmetriske algoritme, man krypterer den key med den asymmetriske algoritme, man sender så den krypterede key og data krypteret med den key og den symmetriske algoritme.
[der er også en praktisk grund til at gøre det: asymmetriske algoritmer er meget langsommere end symmetriske algoritmer]
Altså jeg er lidt uforstående over for det du skriver der..
Det man gør er altså at først bliver data krypteret med den symmetriske algoritme derefter med den asymetriske også bliver den dekrypteret på samme måde eller..?
Men er det ikke langsomere end bare kryptere med den asymetriske?
ofte bruges den asymmetriske algoritme til nøgler. der jo typisk ikke er meget store, mens data kommunikationen krypteres symetrisk. Se f.eks. IPSec der kører på denne måde. Hvis den asymmetriske nøgleuydveksling sættes med for stor nøglelængde vil VPN forbindelsen gå kold med jævne mellemrum mesn nye nøgler udregnes, da den asymmetriske angoritme tager mange ressourcer.
Med andre ord bruger du den meget sikre og ressourcekrævende asymmetriske algoritme til at kryptere den nøgle som du bruger til at kryptere symetrisk med
Remote access køres ofte over VPN f.eks. IPSec eller SSH, hvilken kommer an på flere ting. SSH er en simplere protokol med begrændset funktionalitet. Bruges ofte til fjernadministration af linux boxe eller simple remote opgaver. IPSec er en meget funktionel VPN protokol, men her er også nogle ting der skal løses og overvejes da derer flere muligheder og faldgrupper
har nemli hørt at computer til applikation sammenkoblinger er vpn til web tjenester, men ved ikke om det er rigtigt, og så fald kunne jeg godt tænke mig at vide hvilke internet tjenester det kunne være?
Hvis du f.eks. har to computere med XP, kan disse forbindes direkte via VPN uden videre. XP understøtter IPSec som den er og det er ret let at sætte op
Højreklik netværkssteder (tryk på start først) vælg egenskaber under netværksopgaver (ude i venstre side) vælger du "opret en ny forbindelse" Guiden ny forbindelse kommer frem. vælg "opret forbindelse til netværk på min arbejdsplads" og tryk næste vælg virutuel privat netværksforbindelse og følg guiden.
Hvis nu jeg vil forbinde til mit arbejde via vpn og jeg har en vpn router, behøver jeg så slet ikke noget ekstra software? vpn routeren gør hele arbejdet ik? min computer skal vel ikke til at forbinde til almuligt da vpn routeren har gjort det eller hva?
Det kommer an på VPN routeren. Hvis det er en IPSec complaiant VPN router så kan du tilkoble direkte med XP via IPSEC. Hvis det f.eks. er en cisco VPN gateway, skal du have en cisco VPN client
Hvis du har en VPN router så skal du næppe gøre noget. Så vil din VPN router lave en tunnel til firmaets VPN router og det vil være transparent for Windows.
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.