Dette indlæg er alene udtryk for skribentens egen holdning.

Heartbleed-fejlen, nu som tegneserie...

11. april 2014 kl. 09:459
Artiklen er ældre end 30 dage
Manglende links i teksten kan sandsynligvis findes i bunden af artiklen.

Vi har inden for kort tid set tre meget kritiske fejl i forskellige SSL-implementationer. Kan vi bortforklare det med at SSL er kompliceret og at kryptering er for svært? Desvære nej, det er tankevækkende at alle tre fejl grundlæggende set er dårlig programmering af kode der burde være ligetil at implementere.

Hvis du stadigvæk ikke har forstået hvad Heartbleed-fejlen egentlig går ud på, så læs Randall Munroes forklaring i dagens XKCD:

Artiklen fortsætter efter annoncen

Heartbleed explained

Så enkelt er det. (Tegneserien frigivet under CC-BY-NC 2.5 af Randall Munroe)

9 kommentarer.  Hop til debatten
Denne artikel er gratis...

...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.

Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.

Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.

Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.

Debatten
Log ind eller opret en bruger for at deltage i debatten.
settingsDebatindstillinger
8
11. april 2014 kl. 15:56

Good point

5
11. april 2014 kl. 15:16

Det er ikke i orden at du lægger tegneserien direkte i dit blogindlæg og det er jo alligevel ikke bredt nok til at man kan læse det. Giv dog manden den traffik han fortjener.

6
11. april 2014 kl. 15:41

Det er ikke i orden at du lægger tegneserien direkte i dit blogindlæg

Jo det er det: https://xkcd.com/license.html

Man kan lidt diskuterer om version2.dk opfylder NonComercial-delen af licensen, men med Randall Munroes uddybning mener jeg at det er i orden med ham. Trafik tror jeg også han får masser af.

Jeg er enig i at den tekniske kvalitet ikke er helt den bedste. Det er desvære ikke mit CMS, men jeg ville med glæde bruge det 'embeddable' link som Randall selv anbefaler man bruger.

1
11. april 2014 kl. 13:35

Man kan undre sig lidt over at forfatterne til RFC6520 har følt det nødvendigt at inkludere endnu en "length" angivelse i protokollen. RFC6066 angiver i forvejen længden af beskeden. Forfatteren er vist i øvrigt den samme som har comittet koden til OpenSSL.

Næe... der var engang hvor protokoller var til at overskue :)https://tools.ietf.org/rfc/rfc862.txt

3
11. april 2014 kl. 14:37

Jeg er stadigvæk ikke helt opdateret på hvad det smarte ved konstruktionen er ud over at det er noget med forskellige pakkestørrelser, men en Heartbeat forespørgsel har en prædefineret længde som opnås ved hjælp af padding, i svaret udelades denne padding. Derfor indeholder en Heartbeat forespørgsel naturligvis en længde så man kan kende besked fra padding.

2
11. april 2014 kl. 13:52

Hmm... øjensynligt har en af hensigterne været at give noget fleksibilitet, så det kunne bruges til path MTU discovery. Det første Internet-Draft havde ikke denne længde. Og hele problematikken ang. den har været diskuteret i denne tråd:https://www.ietf.org/mail-archive/web/tls/current/msg06453.html

Hvor det også tydeligt er blevet nævnt at det skal checkes at den er korrekt. Og udmøntede sig da også i at draft-01 indholdet teksten:

If payload_length is either shorter than expected and thus indicates
padding in a HeartbeatResponse or exceeds the actual message length
in any message type, an illegal parameter alert MUST be sent in
response.

... som i RFC6520 blev til:

If the payload_length of a received HeartbeatMessage is too large,
the received HeartbeatMessage MUST be discarded silently.

Så der er vist ikke andet at sige til det end at det at den fejl fik lov til at snige sig ind i OpenSSL er resultatet af en eklatant gang sjusk - og mangel på code review.