/ Forside / Teknologi / Internet / Sikkerhed / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
Sikkerhed
#NavnPoint
stl_s 37026
arlet 26827
miritdk 20260
o.v.n. 12167
als 8951
refi 8694
tedd 8272
BjarneD 7338
Klaudi 7257
10  molokyle 6481
At forstå SSL (HTTPS)
Fra : Lars Hoffmann


Dato : 06-05-03 11:11

Jeg har lige et spørgsmål angående SSL kryptering. Så vidt jeg kan
forstå virker SSL noget forsimplet som følger,:

1) Browseren beder om en sikker forbindelse.
2) Serveren sender sin public key
3) Kliente krypterer nu al data der sendes til serveren via dennes
public key, og serveren dekrypterer dette med sin private key.

Mit spørgsmål er så:
Betyder dette at det kun er data der sendes fra klienten til serveren
der krypteres, og at data der sendes den anden vej fortsat er
ukrypterede? Hvis ikke, hvilke keys bliver dette så krypteret med?

Med venlig hilsen
Lars Hoffmann




 
 
Peter Makholm (06-05-2003)
Kommentar
Fra : Peter Makholm


Dato : 06-05-03 12:00

"Lars Hoffmann" <lars@intercambiodvd.com> writes:

> Jeg har lige et spørgsmål angående SSL kryptering. Så vidt jeg kan
> forstå virker SSL noget forsimplet som følger,:

Meget forsimplet.

> 1) Browseren beder om en sikker forbindelse.

Ved HTTP over SSL (HTTPS) sker dette som sådan ikke. Browseren
begybnder bare at snakke SSL når den forbinder sig. Standardporten for
https er så en anden end for normal http.

Andre protokoller giver mulighed for at bede om SSL i en eksisterende
forbindelse.

> 2) Serveren sender sin public key

Begge parter i en SSL forbindelse kan authentificere sig, men det er
ikke nødvendigt. Man kan godt lave SSL uden at bruge
servercertifikater, så har brugeren bare ingen sikkerhed for at
serveren er den den udgiver sig for, men man har stadigvæk en
krypteret kanal.

> 3) Kliente krypterer nu al data der sendes til serveren via dennes
> public key, og serveren dekrypterer dette med sin private key.

Selve den krypteret trafik sker med en sessionsnøgle som er blevet
udvekslet i indledningen. public key-kryptering er for langsomt til at
kryptere hele sessions.

> Betyder dette at det kun er data der sendes fra klienten til serveren
> der krypteres, og at data der sendes den anden vej fortsat er
> ukrypterede? Hvis ikke, hvilke keys bliver dette så krypteret med?

Nej, der er kryptering begge veje med en nøgle lavet specielt til den
aktuelle forbindelse.

--
Peter Makholm | Ladies and gentlemen, take my advice, pull down your
peter@makholm.net | pants and slide on the ice
http://hacking.dk | -- Sidney Freedman

Lars Hoffmann (06-05-2003)
Kommentar
Fra : Lars Hoffmann


Dato : 06-05-03 12:15


"Peter Makholm" <peter@makholm.net> escribió

> Selve den krypteret trafik sker med en sessionsnøgle som er blevet
> udvekslet i indledningen. public key-kryptering er for langsomt til
at
> kryptere hele sessions.

Hvis argumentet for at bruge HTTPS er at det ikke kan aflyttes da det
er krypteret, hvorledes undgåpr man så at den sessionsnøgle du
omtaler aflyttes således at en trediepart kan bruge den til at
af-kryptere data med?
Med venlig hilsen
Lars Hoffmann



Jesper Stocholm (06-05-2003)
Kommentar
Fra : Jesper Stocholm


Dato : 06-05-03 12:33

Lars Hoffmann <lars@intercambiodvd.com> skrev:
>
>"Peter Makholm" <peter@makholm.net> escribió
>
>> Selve den krypteret trafik sker med en sessionsnøgle som er
blevet
>> udvekslet i indledningen. public key-kryptering er for langsomt
til
>at
>> kryptere hele sessions.
>
>Hvis argumentet for at bruge HTTPS er at det ikke kan aflyttes da
det
>er krypteret, hvorledes undgåpr man så at den sessionsnøgle du
>omtaler aflyttes således at en trediepart kan bruge den til at
>af-kryptere data med?

Den udveksles i begyndelsen af kommunikationen med noget public-
key kryptografi. Når sessionsnøglen er udvekslet, så bruges den
til resten af kommunikationen.



--
* Jesper Stocholm *
* http://stocholm.dk *
* Svar til gruppen og ikke til mig privat ! *
* Hvor svært kan det være ? *


Peter Makholm (06-05-2003)
Kommentar
Fra : Peter Makholm


Dato : 06-05-03 12:35

"Lars Hoffmann" <lars@intercambiodvd.com> writes:

> Hvis argumentet for at bruge HTTPS er at det ikke kan aflyttes da det
> er krypteret, hvorledes undgåpr man så at den sessionsnøgle du
> omtaler aflyttes således at en trediepart kan bruge den til at
> af-kryptere data med?

Jeg huskde lidt forkert. Serveren skal bruge et certifikat, der
indenholder en offentlig nøgle.

Selve sessionsnøglen bliver så beregnet på baggrund af nogle data som
klienten og serveren sender mellem hinanden. Hele sessionsnøglen
bliver ikke transmiteret, men nok til at begge parter kan beregne
den. Noget af denne trafik er krypteret med den offentlige nøgle fra
servercertifikatet.

--
Peter Makholm | One thing you do is prevent good software from
peter@makholm.net | being written. Who can afford to do professional
http://hacking.dk | work for nothing?
| -- Bill Gates

Peter Makholm (06-05-2003)
Kommentar
Fra : Peter Makholm


Dato : 06-05-03 12:39

Jesper Stocholm <tdcnospam@stocholm.dk> writes:

> Den udveksles i begyndelsen af kommunikationen med noget public-
> key kryptografi. Når sessionsnøglen er udvekslet, så bruges den
> til resten af kommunikationen.

Jeg har en vag hukommelse om at der findes smarte metoder som gør det
muligt at blive enige om en sessionsnøgle uden at folk der lytter med
kan komme frem til samme nøgle.

Men som jeg allerede har gjort rede for så ved nærmere undersøgelse,
så er det ikek sådan det foregår i SSL.

--
Peter Makholm | Perhaps that late-night surfing is not such a
peter@makholm.net | waste of time after all: it is just the web
http://hacking.dk | dreaming
| -- Tim Berners-Lee

Søg
Reklame
Statistik
Spørgsmål : 177548
Tips : 31968
Nyheder : 719565
Indlæg : 6408803
Brugere : 218887

Månedens bedste
Årets bedste
Sidste års bedste