Så kom der endnu en SSL fejl, denne gang i OpenSSL. Se straks http://heartbleed.com/ og specielt
What versions of the OpenSSL are affected?
Status of different versions:
OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
OpenSSL 1.0.1g is NOT vulnerable
OpenSSL 1.0.0 branch is NOT vulnerable
OpenSSL 0.9.8 branch is NOT vulnerable
Bug was introduced to OpenSSL in December 2011 and has been out in the wild since OpenSSL release 1.0.1 on 14th of March 2012. OpenSSL 1.0.1g released on 7th of April 2014 fixes the bug.
Har du en af de sårbare versioner, så gå igang med at opdatere nu - stop med at læse, smut!
Det er en alvorlig sårbarhed som gør at man kan læse hukommelsen, og derved bliver mange andre ting i hukommelsen potentielt opsnappet. Det betyder at du udover at opdatere skal skifte nøgler og det bliver en ordentligt omgang!
SSH er ikke sårbar, iflg. Theo de Raadt, se https://twitter.com/openbsdjournal/status/453425522425733120 "Noting also that OpenSSH is not affected"
Der er også binære patches til OpenBSD, hvis man bruger det https://twitter.com/mtierltd/status/453437410035388416
Dit favoritoperativsystem bør have opdateringer, ellers er de ved at blive kompileret.
Jakob Schlyter som er specialist på blandt andet DNSSEC og DANE gør opmærksom på at man lige skal passe på:
"Don't forget to update your TLSA records (at wait for TTL to expire) before you rekey #heartbleed"
https://twitter.com/jschlyter/status/453438431184834560
Så vær opmærksom og skift nøgler kontrolleret, noter gerne at du skal implementere mere automatik til næste gang.
Hvornår har du sidst efterset dine SSL indstillinger?
Det er en udmærket årsag til lige at se på dine indstillinger for SSL/TLS. Du BØR idag i 2014 bruge PFS Perfect Forward Secrecy - det betyder blandt andet at hvis folk HAR fået fat på dine private nøgler er tidligere kommunikation stadig sikker. Jeg anbefaler at du tester dine web servere jævnligt med https://www.ssllabs.com/ssltest/
Jeg vil måske opdatere lidt i løbet af dagen, men har også selv en udfordring med at lokalisere sårbare maskiner og gå det hele efter :-( Hvis du er utålmodig så søg på Twitter eller se hvad jeg har retweetet hidtil.
Der er allerede flere testsider og værktøjer ude til at teste for dette - udover at du kan logge ind på serveren og checke OpenSSL versionen.
NB: check selv hvad du stoler på! Jeg har ikke prøvet dem allesammen, ej heller læst dem nøje!
Gætter på at sites som https://www.ssllabs.com/ssltest/ også hurtigt får inkluderet en test af det - de tilføjede igår aftes.
Det er helt tydeligt at Open Software ikke på magisk vis er sikkert, og det er ikke alle der har evnerne til at finde softwarefejl. Hvis du ligesom mig bruger kritiske værktøjer som OpenSSL, OpenSSH, OpenBSD, Linux mv. så synes jeg du skal finde lidt mønter og smide efter projekterne.
Linux folk, kom gerne med PaX og andre teknologier og links som I synes er relevante her.
På Twitter siges det at heartbleed har resulteret i $15k donation til @freedomofpress, wauw!
This is amazing, @neelmehta, the Google engineer who discovered #heartbleed gave his $15k bounty to @FreedomOfPress. Hats off.
https://twitter.com/fredericjacobs/status/453676701973630976
Opdateret: 9. april 08:34
Hvornår har du sidst efterset dine SSL indstillinger?
Kære Henrik - kan du ikke lokkes til at stille dette spørgsmål til folkene bag borger.dk (foretrækker RC4-"kryptering", understøtter usikker genforhandling, understøtter ikke forward secrecy, understøtter kun TLS 1.0), Danske Bank (foretrækker RC4-"kryptering", understøtter kun TLS 1.0, understøtter ikke forward secrecy) og e-boks (foretrækker RC4-"kryptering", understøtter ikke forward secrecy)?
Du har helt ret, det er som om folk ikke tager det alvorligt. Jeg tror dog det vil virke bedre hvis journalisterne fra Version2.dk giver dem spørgsmålet - så det vil jeg lige prikke til dem.
$ sudo apt-get update; sudo apt-get upgrade
Læser tilstandsoplysninger... Færdig
Følgende pakker vil blive opgraderet:
file gir1.2-gudev-1.0 icedtea-6-jre-cacao icedtea-6-jre-jamvm libgudev-1.0-0 libmagic1 libpam-systemd libssl1.0.0
libssl1.0.0:i386 libsystemd-daemon0 libsystemd-journal0 libsystemd-login0 libudev1 libudev1:i386 libvirt0
...
Så min desktop-Ubuntu (sat til ugentlige opdateringer) var vist sårbar (?).
Hvad er - konkret - risikoen for en desktop-Ubuntu-PC ?
Så vidt jeg kan se, bruger hverken version2.dk eller ing.dk SSL på deres forum login.
Jeg bruger Facebook connect metoden til at logge ind begge steder. Hvor godt er jeg så beskyttet? Det værste der kan ske, er vel et session hi-jack, hvor andre kan skrive som 'mig' her i kommentarfeltet.
Hvordan logger bloggerne ind? Er HLK og PHK's passwords ude og svømme i cyberspace?
Kære Henrik - kan du ikke lokkes til at stille dette spørgsmål til folkene bag borger.dk (foretrækker RC4-"kryptering", understøtter usikker genforhandling, understøtter ikke
Ja det ser en anelse skrabet ud ssllabs.com/borger.dk overall rating: F
jvfr. http://www.debian.org/security/2014/dsa-2896
"The oldstable distribution (squeeze) is not affected by this vulnerability."
Alligevel fik jeg at vise fra filippo.io at en af mine Debian Squeeze kasser (fuldt opdateret iht. apt) var sårbar ... 10 minutter efter (uden at have ændret noget) får jeg at vide at samme maskine IKKE er sårbar, jeg tror måske ikke Filippo.io er den mest troværdige test-metrics at bruge :)
Når man opdaterer openssl / libssl så husk også at genstarte services som benytter dette library. F.eks. Apache.
Jeg får samme mærkelige opførsel på en Debian 7 ... men når jeg så patcher hullet på Debian 7 skifter den over til at sige "All good" hver gang ... men jeg skal tilsyneladende teste en 2-3 gange for at være sikker.
Tak Henrik!
Alle råber at vi skal opgradere OpenSSL nu, men hvor meget mere skal vi efterse?
Sårbarheden har tilladt angribere at læse hukommelsen af hvor meget? Den service der har kørt med OpenSSL? Altså webserveren, mailserveren mm.?
Så de SSL-specifikke ting som certifikater bør fornyes, ikke?
Autentifikationsoplysninger der har strømmet gennem SSL-linjen, som web logins, mail credentials og lign.?
Og så en generel bevidsthed om, at al data, der har været transmitteret via SSL-linjen, kan være opsnappet.
Men ikke mere end det? - Ikke SSH-nøgler, root-passwords osv. vel?
Tak Henrik!
Alle råber at vi skal opgradere OpenSSL nu, men hvor meget mere skal vi efterse?
Sårbarheden har tilladt angribere at læse hukommelsen af hvor meget? Den service der har kørt med OpenSSL? Altså webserveren, mailserveren mm.?
Så de SSL-specifikke ting som certifikater bør fornyes, ikke?
Autentifikationsoplysninger der har strømmet gennem SSL-linjen, som web logins, mail credentials og lign.?
Og så en generel bevidsthed om, at al data, der har været transmitteret via SSL-linjen, kan være opsnappet.
Men ikke mere end det? - Ikke SSH-nøgler, root-passwords osv. vel?
Mange tak for linket til POC også.. Har sat et script til at høste data fra en intern egen server, der ikke er patched endnu. Skal lige se hvor meget eller hvor nemt man får noget relevant ud.
Alle råber at vi skal opgradere OpenSSL nu, men hvor meget mere skal vi efterse?
Sårbarheden har tilladt angribere at læse hukommelsen af hvor meget? Den service der har kørt med OpenSSL? Altså webserveren, mailserveren mm.?
Så de SSL-specifikke ting som certifikater bør fornyes, ikke?
Autentifikationsoplysninger der har strømmet gennem SSL-linjen, som web logins, mail credentials og lign.?Og så en generel bevidsthed om, at al data, der har været transmitteret via SSL-linjen, kan være opsnappet.
Men ikke mere end det? - Ikke SSH-nøgler, root-passwords osv. vel?
Alt for mange spørgsmål på en gang, men du skal være passende paranoid.
Er det let, så gør det - nye keys+cert til dine services er nemme at lave, men kan koste lidt. Samme med SSH host keys, slet og lav nye. osv.
Mht. data sendt via SSL, hvis du bruger Perfect Forward Secrecy http://en.wikipedia.org/wiki/Perfect_forward_secrecy så er tidligere sessioner stadig sikre - derfor det STRAKS anbefales at slå det til. Det er også noget man bør slå til på IPsec VPN og andre VPNS, hvis de understøtter.
Så hvis du har en formodning om at din SSL trafik (uden PFS) er opsnappet og afkodet, så vil dine logins også kræve reset.
Din private SSH nøgle bør være sikker, hvis den er på en enhed som ikke kører eksempelvis en web server - den bør ligge på din laptop uden ekstra services/med en god firewall. Håber det gav lidt input.
NB: der er ikke så mange der snakker om hvor og hvordan man laver gode nøgler. Jeg vil anbefale OpenBSD som operativsystem og man kunne sagtens dedikere en ældre laptop til at være DER man laver keys, og så evt. bruge HSM http://en.wikipedia.org/wiki/Hardware_security_module - de findes i forskellige udgaver og vil gøre det svært at opsnappe nøgler på samme måde.
og et link jeg burde have sat ind er også https://bettercrypto.org/
Mht. data sendt via SSL, hvis du bruger Perfect Forward Secrecy http://en.wikipedia.org/wiki/Perfect_forward_secrecy så er tidligere sessioner stadig sikre - derfor det STRAKS anbefales at slå det til. Det er også noget man bør slå til på IPsec VPN og andre VPNS, hvis de understøtter.
Er det rigtigt forstået at SSHv2 automatisk bruger PFS?
Er det rigtigt forstået at SSHv2 automatisk bruger PFS?
Tak for det spørgsmål, det måtte straks undersøges.
Jeg fandt et mere eller mindre tilfældigt link, http://utcc.utoronto.ca/~cks/space/blog/tech/SshForwardSecrecy
In version 1 of the SSH protocol, PFS is achieved by using the second, ephemeral set of host keys.
men F det, for vi bruger ikke SSHv1 mere - VEL!
So how does SSH v2 achieve (perfect) forward security?
It turns out that the answer is in RFC 4251's section 9.3.7: SSH v2 normally uses Diffie-Hellman key exchange to set up the session keys, which inherently provides perfect forward security without needing a second set of host keys or anything like that.
Jeg kiggede lidt i RFC'en - http://www.ietf.org/rfc/rfc4251.txt - og der står lidt mere, men også brugen af ordet "may" deri gør mig lidt usikker, jeg tror dog vi er på sikker grund. Linket fra Theo de Raadt ovenfor i indlægget peger også i den retning.
"It should be noted that the Diffie-Hellman key exchanges may provide perfect forward secrecy (PFS)."
Min Chromebook beta-kanal køre Chrome/34.0.1847.118 openssl 1.0.1f
Bare for god ordens skyld: jeg plejer at bestille SSL certs (og domæner) via GratisDNS siden - det er stadig Larsen data, men er min måde at støtte GratisDNS på og vise at det giver mening at fastholde servicen.
Hej Henrik.
Som en ikke specielt sikkerhedskyndig person er dette umiddelbart bekymrende at læse citater som "I have come to the conclusion that OpenSSL is equivalent to monkeys throwing feces at the wall" om OpenSSL:
https://www.peereboom.us/assl/assl/html/openssl.html
Har han ret?
Jeg vil ikke prale af at besidde de store krypto-kundskaber, så tilgiv mig hvis svaret burde være indlysende.
Men givet at masser af browsere vist bruger OpenSSL på diverse platforme, kunne jeg forestille mig at en HTTPS-webserver indrettet på (u)passende vis, kunne anvendes til at hive private data ud af klienter (browsere). Det forudsætter dog, at det er begge sider af en SSL-forbindelse, der kan sende heartbeat requests. Jeg har kigget på RFC 6520, og kan ikke umiddelbart se at dette ikke skulle være muligt, selv om det nok er en mere hypotetisk angrebsvinkel...
Kvaliteten har været diskuteret vidt og bredt.
Jeg tror et basalt problem er at OpenSSL skal understøtte ALLES behov for ALTING. Det betyder mange kodelinier, gamle algoritmer der burde være fjernet, kompleksitet for at imødegå alle trusler osv.
Det betyder at man starter med simple kodestumper, som så skal væves sammen til et tæppe der kan bruges på stranden og i Tibet! Så ja, OpenSSL er formentlig ikke smukt eller nemt at forstå. Til gengæld, vil du stole på et mindre brugt cryptobibliotek udviklet af nogle andre (amatører), som ikke bruges til så mange produkter?
Det kunne være dejligt hvis OpenSSL fik en "updated paranoia core" version, med KUN stærke algoritmer, minimal kode, få muligheder og færre options. ahf gav mig forøvrigt link til noget smukt, som jeg bliver nødt til at dele:
http://golang.org/src/pkg/crypto/subtle/constant_time.go
altså funktioner som altid kører i konstant tid, og dermed ikke lækker nøgler/bits fra nøgler. Det er bare een af måderne cryptokode kan angribes på, som kræver omhyggelig programmering.
$ sudo apt-get update; sudo apt-get upgrade
Apropos web-sikkerhed så vil jeg lige påpege at det er farligt bare at copy-paste html (når man ikke stoler på forfatteren) direkte ind på kommandolinjen:
http://thejh.net/misc/website-terminal-copy-paste
Istedet kopierer jeg først teksten ind i en editor, og når jeg så kan se at den er uskadelig, så kopierer jeg den ind på kommandolinjen.
Mange tak for svar!
$ sudo apt-get update; sudo apt-get upgrade
Læser tilstandsoplysninger... Færdig
Følgende pakker vil blive opgraderet:
file gir1.2-gudev-1.0 icedtea-6-jre-cacao icedtea-6-jre-jamvm libgudev-1.0-0 libmagic1 libpam-systemd libssl1.0.0
libssl1.0.0:i386 libsystemd-daemon0 libsystemd-journal0 libsystemd-login0 libudev1 libudev1:i386 libvirt0
...Så min desktop-Ubuntu (sat til ugentlige opdateringer) var vist sårbar (?).
Hvad er - konkret - risikoen for en desktop-Ubuntu-PC ?
Der er jo så en fejl i din opsætning, den bør være sat til daglige opdateringer.
Jeg tog selv lige et tjek i changeloggen for openssl via synaptic, det fremgår:
openssl (1.0.1e-3ubuntu1.2) saucy-security; urgency=medium
- SECURITY UPDATE: side-channel attack on Montgomery ladder implementation
- debian/patches/CVE-2014-0076.patch: add and use constant time swap in
crypto/bn/bn.h, crypto/bn/bn_lib.c, crypto/ec/ec2_mult.c,
util/libeay.num.- CVE-2014-0076
SECURITY UPDATE: memory disclosure in TLS heartbeat extension
- debian/patches/CVE-2014-0160.patch: use correct lengths in
ssl/d1_both.c, ssl/t1_lib.c.- CVE-2014-0160
-- Marc Deslauriers <marc.deslauriers@ubuntu.com> Mon, 07 Apr 2014 15:43:47 -0400
Så en linux maskine ( i dette tilfælde en *buntu ) der er sat op med daglige opdateringer vil som jeg læser det være beskyttet på nuværende tidspunkt.
Det ser ud til at også klienter er sårbare. Så det er en god ide at opdatere klienter også. Det nævnes her:
https://www.openssl.org/news/secadv_20140407.txt
Og uddybes her:
http://security.stackexchange.com/questions/55249/what-clients-are-prove...
Som alternative til SSLlabs test side er det også muligt at teste server på
http://www.qualityssl.com/dk/support/ssl-server-test.lasso
Mvh
Pascal Geuns
http://www.qualityssl.com/dk/
