Eindelijk, vond het al lang duren voor hier bericht aan werd gegeven.

Nu ga ik er vanuit dat banken e.d. geen gebruik maken van OpenSSL, maar vooralsnog beschouw ik alles als onveilig.

Hopelijk schudt dit mensen (met name ontwikkelaars) om te stoppen met het gebruik van OpenSSL. Bekijk de OpenSSL's code, de API, de documentatie (of het ontbreken ervan) en vergelijk dat eens met bijvoorbeeld PolarSSL. Dan wil je toch serieus geen OpenSSL meer...

Webwereld maakte er al eerder melding van.
Vond het al opmerkelijk dat Webwereld gisteren overdag eruit lag voor onderhoud en Security.nl gisteravond.
Of was dat toeval?

- Helpt dit dan voor Firefox?

Firefox about:config settings voor security TLS version


http://kb.mozillazine.org/Security.tls.version.*

- Anderen ook al opgevallen dat browserspy al dagen niet meer bereikbaar is?
Geen idee wat er met deze site aan de hand is. Jammer want daar kon je veel feedback informatie krijgen over de browser die je gebruikt.

www.browserspy.dk

Dat is leuk als je GPL-software kunt (mag) gebruiken van je werkgevers of klanten. Tot nog toe is voor zover ik weet OpenSSL de enige fatsoenlijke TLS/SSL-software onder een liberale licentie.

Betekent dit nu dat je in principe alle wachtwoorden van alle sites die je via https benaderd ook moet vervangen?
De secret keys zijn immers in principe gecompromitteerd en daardoor ook de gebruikte wachtwoorden.

Wie krijgt hier met welke browser(versie) een 100% resultaat?
https://www.howsmyssl.com/
Wat heb je daarvoor eventueel extra aangepast om dat te bereiken?

Lang niet alle OpenSSL versies hebben er last van omdat het blijkbaar een nieuw ingevoerde bug is. Op de OpenSSL homepage staat vermeld:


In elk geval is OpenSSL aanwezig op alle Macs. En omdat Apple dit ook regelmatig update, ga ik ervan uit dat het intern ook gebruikt wordt. Het opvragen van de versie op OSX 10.6 en 10.9 geeft: "OpenSSL 0.9.8y 5 Feb 2013". Dus geen versie waar de bug in zit, dus ga ik ervan uit dat Apple bij de vertrouwde versie blijft en niet gaat updaten.

Een test website, kan handig zijn: http://filippo.io/

Dat is inderdaad een goed idee..

100% met Windows 8.1 Enterprise en IE11. Wel met een aangepaste set cyphersuites:

•TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
•TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA
•TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384
•TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
•TLS_DHE_DSS_WITH_AES_256_CBC_SHA256
•TLS_DHE_DSS_WITH_AES_256_CBC_SHA
•TLS_RSA_WITH_AES_256_CBC_SHA256
•TLS_RSA_WITH_AES_256_CBC_SHA
•TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
•TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
•TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256
•TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256
•TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
•TLS_RSA_WITH_AES_128_CBC_SHA256
•TLS_RSA_WITH_AES_128_CBC_SHA
•TLS_DHE_DSS_WITH_AES_128_CBC_SHA256
•TLS_DHE_DSS_WITH_AES_128_CBC_SHA
•TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA

Het grappige is dat CloudFlare en Akamai dit gat al dicht hadden gemaakt afgelopen weekend. Ik heb het zelf getest om het systeem waar ik aan werk (voor een grote wereldbank..;)) en daar kreeg ik geen geheime data te zien. Wel kon ik de logfile benaderen in stappen van 64 Kb. Gat is overigens ook al hier gedicht, zo moeilijk was het niet..

http://git.openssl.org/gitweb/?p=openssl.git;a=commitdiff;h=96db9023b881d7cd9f379b0c154650d6c108e9a3

@ 10:45 Anon

www.browserspy.dk geeft al een tijdje een fout melding aan.
Er zijn nog andere die hetzelfde bieden.

http://www.check-and-secure.com/browsercheck/_en/
https://browsercheck.qualys.com/
https://panopticlick.eff.org/

Browser SSL test:
https://www.howsmyssl.com/
https://cc.dcsec.uni-hannover.de/

DNS leak test:
https://www.dnsleaktest.com/

100% met Linux mint 16 standaard installatie (volledig up-to-date)
-edit- en firefox als browser.

Bedankt, qualys tip sla ik over, was er niet ook een app van qualys?
al eens naar gekeken nav push van banken, kwam niet door de beoordeling
iets met privacy.

Dan lag het aan de zeer op leeftijd zijnde testmachine met navenant op leeftijd zijnd Os (X), net geen partij tegen een up to date Windows
:-) .
Was benieuwd of 100% een realistisch idee was, het kan dus (in ieder geval onder Windows en Linux).
Eén OS X browser kwam er het best vanaf (mozilla variant) met slechts 1x "bad" voor één cipher.
Eens kijken hoe die eruit gesloopt kan worden en of die specifiek ook bij andere nieuwe versies van OS X een 'probleem' vormt.

@ Ramon.C

https://www.dnsleaktest.com/ geeft bij mij deze foutmelding:

Suspected attack:
Perspectives was unable to verify the security of your connection to this website

www.dnsleaktest.com uses an invalid security certificate

The certificate is not trusted because no issuer chain was provided

(Error code: sec_error_unknown_issuer)

Quote: "Hoe de bug ongeveer werkt:

OpenSSL ondersteunt een "heartbeat" functie waarbij je wat loze data kan sturen en de server stuurt deze dan terug, om de verbinding open te houden. Je geeft daarbij aan hoeveel data je opstuurt. Dit wordt/werd echter niet gecontroleerd tegen hoeveel data je daadwerkelijk opstuurt.

Je kunt dus tegen de server zeggen "ik ga 64k aan data sturen", vervolgens slechts 1 byte sturen, en de server stuurt je vervolgens wel 64k aan data terug: die ene byte, plus de 64k (min 1 byte) die erachteraan kwamen in het geheugen. Dit is dus willekeurige data in het geheugen van de server!

Omdat OpenSSL zijn eigen data meestal bij elkaar heeft staan is er dus ook een hoge kans dat bij de willekeurige data private keys zitten, maar het kunnen net zo goed email adressen en wachtwoorden zijn. Een flink serieuze bug dus."

100% Ubuntu 12.04 FF
100% Mavericks FF
100% Mavericks Chrome g
Improvable Mavericks Safari "Session Ticket Support"
Ongepatchte Centos 6.5 "BAD", na patchen van OpenSSL: "BAD"
Na aanpassing van about:config TLS max ver. naar 3.0
Alleen nog "Unsecure Ciphers"

Zojuist ook nog even geprobeerd op een machine met Windows 8.1. pro met IE11.

Ook 100%. Maar ook met een aangepast set cypher suites.

Ik doe niets met de home versie omdat daar geen local group policies op zijn te configureren. Ik steek mijn hand daar niet voor in het vuur. Maar ik hoor het graag.

Overigens ondersteunt FF pas sinds een maand of drie TLS 1.2 Windows doet dat al jaaaaren.

Alleen openssl is nog lek: http://filippo.io/Heartbleed/#openssl.org

Sinds vanmorgen 10 uur zijn alle security repo's van zowel Ubuntu, Debian en CentOS geupdate. Alleen een apt-get update en dist-upgrade of yum upgrade is voldoende. Ik adviceer alleen wel lopende proicessen met oude openssl nog te killen.
Hier een commando met hoe je oude processen kan opsporen nadat je geupdate bent:

grep -l 'libssl.*deleted' /proc/*/maps | tr -cd 0-9\\n | xargs -r ps u

Je kan ook je server herstarten, maar als dat niet een optie is, dan kan je bovenstaande regel gebruiken om de processen te vinden.

Alleen patchen is niet genoeg! Keys/certs moeten ingetrokken en vernieuwd worden. Bovendien is het netjes je gebruikers in te lichten en aan te raden wachtwoorden te veranderen.

Nee, er is aan de client kant niets wat je kunt doen, behalve je wachtwoorden veranderen nadat de respectievelijke servers zijn gepatched en keys/certs zijn ingetrokken en vernieuwd.

Weet iemand hier al meer over ? Ik zie Peter V wel meer staan, dus neem aan dat dit wel klopt ? Ik hoorde alleen op de Radio, dat Nederlandse Banken veilig zouden zijn.....? Houd EMET hiervan ook niets tegen ? Is het verstandig om wachtwoorden te veranderen bij ING ? ABN en Rabo werken anders, maar ABN stond er niet bij ?
Vind het maar erg vreemd als dit al twee jaar bekend is, en nu vandaag bekend word !
Voorlopig maar niet Internet Bankieren ?

Mooi zo, mijn dank PeterV ! Ik heb net de site bezocht https://www.howsmyssl.com/

Deze geeft dit aan ;
Version - TLS Compression - Ephemeral Key Support - Beast Vulnerability daaronder komt dan Given Cipher Suites

Met Chrome stond alles op Good.
Met Firefox stond ook alles Good.

Session Ticket Support, geeft met Internet Exploxer 11, aan dat deze Improvable is.
Als ik vandaag/vanmiddag met Exploxer 11 met Inprivate bankzaken heb gedaan was dat dan gevaarlijk ?

Zegt het iets over IEX 11, dat die Session Ticket Support. Op die site van Howsmyssl.com
Daar niet als Good stond ? Wat is de veiligste browser om bankzaken mee te doen ?

Vanmiddag om 16 uur zijn er bankzaken gedaan bij ING

Hoe kom ik er nu achter dat dit toen onveilig was ?
Ik lees dat dit lek de laatse twee jaar bekend was, de laatse twee jaar zijn er steeds met
IEX 11 bankzaken gedaan, dus als er wat geweest was !

Voortaan dus met Chrome of Firefox, hoewel ik nooit was lees over hoe veilig Firefox is ?

https://www.howsmyssl.com/

OS X Mountain Lion 10.8.5 met Safari Version 6.1.3 (8537.75.14) pas geupdated, geeft BAD
Bad on Version and BEAST Vulnerability, nou gebruik ik Safari toch al niet, maar wellicht in iTunes en Appstore ?!?

Zelfde OS X 10.8.5 met firefox 28.0 geeft 'Probably Okay', maar geeft op alle tests Good.

Overigens denk ook aan routers en firewalls. Ik las dat PFsense bezig is met nieuwe versie 2.1.2
en dat 2.1 en 2.1.1 de openssl bug bevatten.

Extra info for OSX 10.8.5.

Openssl versie op Mountion lion geeft: OpenSSL 0.9.8y 5 Feb, en schijnt niet kwetsbaar te zijn voor Heartbleed, maar TLS1.0 wat en oude versie is en kwetsbaar voor BEAST attack.

Het lek was geen twee jaar bekend. De fout in de code is twee jaar geleden geïntroduceerd, vanaf dat moment kon iemand het ontdekken en misbruiken. Wanneer iemand het daadwerkelijk voor het eerst ontdekt en misbruikt heeft weet niemand. Het enige dat we nu weten is dat sinds 7 april iedereen het weet.

De kans dat iemand net een aanval uitvoert op een website op het moment dat jij daar inlogt en jouw wachtwoord dus in het geheugen staat is natuurlijk niet gigantisch groot. Het wordt al gevaarlijker als iemand de private key van die website heeft weten op te vissen waarmee een man in the middle aanval kan worden uitgevoerd of onderschept verkeer kan worden ontsleuteld.

En dan is er natuurlijk nog het risico dat je op een kwaadaardige site bent beland die het geheugen van jouw PC (of in elk geval een deel daarvan) kan uitlezen, terwijl je op dat moment ook net had ingelogd op een bank site of zo.

OS X, OpenSSL en Safari .....


-> Waarom brengt Apple security TLS support onderscheid aan bij Safari versies met eenzelfde OpenSSL versie? #

Interesse test gedaan op ook oudere OS X systemen, vanwege de marketshare en de bloeiende prijzige tweedehandsmarkt van werkende (licht antieke) Mac's ;-)
Voor de drie beschikbare laatste Safari versie's voor genoemde OS X range zijn de resultaten erg verschillend.

Andere resultaten zijn al uiteen gesplitst hier, alleen 2 ontbrekende Safari tests erbij :

* Apple Safari 5.0.6 (July 20, 2011) voor OS X 10.5 Leopard geeft 3x bad, 1x improvable en 8 onveilige cipher suites
* Apple Safari 5.1.10 ((September 12, 2013) voor OS X 10.6 Snow Leopard geeft exact hetzelfde resultaat 3x bad, 1x improvable en 8 onveilige cipher suites ('Hoezo' OpenSSL update 5 Feb 2013?)

Klap op de vuurpijl, ter vergelijking: een up to date Mozilla browser variant onder het oude OS X 10.5 presteert beter op howsmyssl.com dan een Safari 5.0.6 voor OS X 10.5 en Safari 5.1.10 voor OS X 10.6 (!)
Beter is ; "met slechts 1x "bad" voor één cipher" (de rest "Good").

Retorisch (inmiddels !) : Toch maar geen Safari meer gebruiken onder Snow Leopard 10.6.8 ?

* Geen security support voor Safari, geen nieuwe versies meer uitgebracht naast nieuwe versies voor OS X 10.7 - 10.9.
* Groot verschil in SSL resultaten met andere nieuwere Safari versies (ondanks dezelfde OpenSSL versie).
* Groot verschil in SSL resultaten met ( bijvoorbeeld mozilla) browser(s) die beter scoren onder OS X, zelfs een mozilla browser onder OS X 10.5 met een ouder OpenSSL versie (die er niet toe doet) doet het stukken beter dan Safari 5.1.10 voor Snow Leopard (1x bad; 1 insecure cipher).
* Geen algemene security support meer voor OS X 10.6 lijkt het.

Mac OS X Snow Leopard 10.6 is Apple's XP?

Nee hoor, wat mij betreft niet, alleen qua end-of-life-'support'.
Met Mac OS X Snow Leopard 10.6 kan je m.i. nog steeds prima veilig uit de voeten als je oog hebt voor wat extra aanpassingen aangaande je security config en gebruik maakt van een andere, nog wel supported, browser dan Safari (die vermoedelijk ook stukken beter presteert dan IE8).
Een browser bijvoorbeeld met eigen ssl/tls implementatie, bijvoorbeeld Firefox 28 geeft alles Good en geen onveilige ciphers.

# Apple support community linkje als extra :
Safari en TLS, Zie : HT1677 Does Safari support TLS 1.2
https://discussions.apple.com/message/22331752#22331752
Bewering door een van de posters daar is dat alleen de Mavericks versie van Safari TLS 1.2 ondersteunt zoals ook hier gebleken.


Dan doet het er niet toe?
Dan is het winst om te weten dat er nogal verschillen zitten tussen de diverse Safari versies onder Mac OS X.

Geen Safari support meer? Overweeg dan om Safari niet meer te gebruiken. Jammer maar helaas, er zijn andere goede alternatieven.
Helaas #2, 'no matter' hoe oud het OS X is, heel veel gebruikers gebruiken toch Safari, tenzij het er nog niet op zit, dan wordt IE5 for Mac gebruikt of Firefox 3,
sniff…

@ 08-04-2014 17:42 Anon

Leg eens uit, waarom vermijd je Qualys liever? Ik weet niet of er een app is van qualys, tenminste er is wel een webapp aanwezig.



Bij mij absoluut geen issues met de certificaat, noch dat ik enige andere foutmeldingen krijg. Getest met Firefox en Chrome

Hoe zit het eigenlijk met mailservers? Is iemand dat aan het testen?

--hzlz

Laat de webapp opmerking even zitten, het ging om een Qualys plugin.
Zie hier :
https://www.security.nl/posting/365091/Tool+waarschuwt+Mac-gebruiker+voor+onveilige+plug-ins

Lees op Qualys site maar verder door op mogelijke haken en ogen
https://community.qualys.com/docs/DOC-1542#s2_q8

Met een aangepaste UserAgent (of een deels gedeactiveerd javascript, activeren helpt niet met een aangepaste useragent) stort de Qanalysezaak overigens direct helemaal inelkaar.
https://browsercheck.qualys.com/unsupported.php
Not Supported Qualys BrowserCheck is not supported with your current browser, operating system or both.

Een site als browserspy.dk gaf simpel en direct informatie die je browser doorspeelde. Je kon de verschillen met en zonder geactiveerd javascript goed inzichtelijk met elkaar vergelijken.
Zeer leerzaam.
Tevens geen gehussle en gehassle met inlogs en accounts, ellenlange privacy policies en safe harbor verhalen, hoezo dagelijks scannen?.
http://www.qualys.com/company/privacy/
http://www.qualys.com/company/privacy/statement/

Maar Browserspy doet het niet meer :
Forbidden
You don't have permission to access / on this server.
Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request.
Apache Server at www.browserspy.dk Port 80

Hopelijk komt deze site weer een keer in de lucht.

Toch nog even zitten nadenken over dit lek. Je mag er van uit gaan dat alle servers van Google, Apple, Firefox en al het andere dat op unix/Linux is gebaseerd twee jaar lang zo lek als een mantje zijn geweest en/of nog zijn. Je hebt dus geen enkele zekerheid m.b.t. software die je hebt gedownload of ander zaken die je hebt gedaan. Het beste is om al die zooi maar te deleten en wachten tot je zeker bent dat er geen problemen (meer) zijn voor je weer nieuwe software gaat downloaden.

Gelukkig zijn Microsoft servers niet kwetsbaar voor dit lek.:)

Op Debian bevat het pakket debian-goodies het commando checkrestart. Dat kan je na een upgrade uitvoeren om processen op te sporen die oude versies van bestanden gebruiken. Het geeft ook een lijst van init-scripts die voor herstarten gebruikt kunnen worden.

Goede vraag! Je zou zeggen dat imapS en smtpS eventueel kwetsbaar zijn, maar geen idee
in hoeverre de verschillende implementaties openssl gebruiken. Of dat het uberhaupt kan om
een heartb(l)eat te sturen.

IEMAND?

Hoe kan ik op mijn Mac met Maverics 10.9.2 zien welke versie van openssl ik gebruik?.
Het zit toch standaard in OSX,deze mogelijkheid?
Ik bedoel hoe nieuw zijn de openssl bibliotheken binnen OSX?.
Als die kwetsbaar mochten zijn,dan zal Apple toch ook wel met een patch komen?.

Het volgende heb ik van een Apple forum:
Let's try a different approach. When you visit a website sometimes a secure, encrypted connection is established called SSL (Secure Sockets Layer). The website uses the OpenSSL software to create a certificate to do this, not your computer. The OpenSSL software on the website server, not your computer, has a bug in it that allows hackers to steal small chunks of memory from the server. This memory may contain user information. Here's the important part to understand. It's the website server that is vulnerable, not your computer. You are in danger because the server has your information that this bug can expose. So it doesn't matter which computer or operating system YOU are using on your computer, only the webiste you visited. That's why this is such a nasty bug.

Talk about whether OS X 10.9.2 or 10.8.5 or any other version of OS X is vulnerable is meaningless. Everybody who uses the Internet is vulnerable because the problem is not on your computer, it's on the websites you visit with your computer. Until every website that uses the affected version of OpenSSL is updated the data on those websites is vulnerable to hackers.

So don't worry about whether OS X is vulnerable. It isn't. Your data that exists on website servers IS vulnerable.

Daar mag je pas van uitgaan als je weet hoe zij omgaan met SSL...
Google doet aan SSL terminatie op de loadbalancers zoals veel grote bedrijven en niet alle Loadbalancers zijn hier kwetsbaar voor.
Dus ja je gedachte is op niks gebaseerd tenzij je het kan onderbouwen?

"Dus ja je gedachte is op niks gebaseerd tenzij je het kan onderbouwen?"

Het gaat helemaal niet om gedachten. MS servers waren niet kwetsbaar en google Servers wel. Google maar :)

Ja ja, ik weet het. Het doet ZEER.

Beste Peter V.,

https://www.howsmyssl.com/ geeft bij mij met de nieuwste versie van Chrome (Versie 34.0.1847.116 m):

– Your SSL client is bad
– Version is Bad
– BEAST vulnerability is bad
– Insecure Cipher Suites are bad

Vraag 1: Moet ik zelf TLS 1.2 in Chrome instellen?
Vraag 2: Zo ja, hoe kan ik dat doen?
Vraag 3: Of moet ik iets anders doen, en zo ja, wat moet ik dan doen?

Bij voorbaat veel dank voor de hulp.

Harry

Aardig uitgelegd, waar heb je het vandaan?
Zet svp bij zo'n uitgebreide quote paste ook de bronlink.

Eén en ander heeft evengoed tot nieuwe (Safari, browser) inzichten geleid, dat is nooit weg.

Already published!

https://community.openvpn.net/openvpn/wiki/heartbleed

Your OpenVPN is affected when your OpenVPN is linked against OpenSSL, versions 1.0.1 through 1.0.1f.

Okay, er stond ook wel dat the session ticket key soms uitgeschakeld is in de browser. Ik weet niet of dat het geval is bij IEX 11, Session Ticket Support, geeft met Internet Exploxer 11, aan dat deze Improvable is, betekent Improvable uitgeschakeld ?
Ik neem nu eerst Chrome, Firefox, en dan IEX.

Hm. wat een hoop informatie, en hier en daar klopt het nog ook.

volgens mij is dit wat er aan de hand is: De lekke openSSL zorgt ervoor dat een beetje slimme hacker de SSL informatie uit een server kan trekken, en daarmee https verkeer KON decrypten in een livestream. Dit kan alleen als die hacker het verkeer kan afluisteren, zoals een mede netwerkgebruiker met traffic sniffer, je ISP met de bandrecorder aan, of de NSA, ervanuitgaande dat die ergens een tap op internetlijnen hebben ingegraven of geplaatst on internet exchanges.

Reeds onderschept en opgeslagen verkeer kan met deze key-informatie redelijk eenvoudig ge-replayed worden, waardoor alle wachtwoorden op je Hotmail en wat al niet meer ineens uit die voorheen geencrypte datablob vallen.

Zaak is dus om preventief al je wachtwoorden overal te veranderen (ok, op 66% van alle webservices), zodat de NSA en consorten niet meer MORGEN kunnen inloggen, met je wachtwoorden van DE AFGELOPEN 2 jaar.

En ja, systeembeheerders moeten alle certificaten intrekken en opnieuw uitgeven als je server op de lijst stond.
maar nog steeds, een vals SSL certificaat is alleen nuttig in combinatie met een valse DNS aanpassing op een DNS server, of op je lokale pc. Wel erg vervelend voor landen waar de overheid de DNS kan aanpassen om opstandelingen uit te roken.

Bankzaken waren en zijn veilig, uitgaande van een authenticatie met een randomreader of TAN code die niet via een appje of sms verstuurd wordt (dat is onveilig losstaand van dit issue.)

En wachtwoorden? Keepass, met de datafile op een altijd offline tablet, en print af en toe je wachtwoordenlijst uit en backup deze in een verzegelde envelop bij je notaris. of je moeder.

@iedereen, mis ik ergens wat?

tik in de shell

openssl version<Enter>

> @iedereen, mis ik ergens wat?

Ja, ook cleartext request & response data kon uit het SSL proces worden gelezen. Er was dus geen noodzaak voor een tap of MITM.

Daarnaast kon uit dergelijke processen ook andere informatie worden gelezen. Als bv de PHP interpreter in hetzelfde proces draait (mod_php met apache als ssl terminator) konden interne geheimen zoals HMAC sleutels of database pwds worden gelekt.

Het is wel waar wat je zegt over Qualys, mee eens. Natuurlijk zullen zij wellicht ook data doorspelen aan derden. Net als speedtest.net dat deed en ghostery (in het begin) Ook heb ik meerdere malen met diverse fake user-agents getest en kreeg ook meldingen dat de browser niet is ondersteund. Ik gebruik ook liever browserspy.dk, nog geen succes met de site. Nog steeds offline.

Ja: valse certificaten vormen met al die publieke wifinetwerken van tegenwoordig een groter risico dan jij hier nu schetst. Fake een hotspot en je bent in de perfecte positie om een MitM aanval uit te voeren. En als je het certificaat en de private key hebt, dan kan je dat op zo'n manier doen dat het niet van echt te onderscheiden is.

Uiteraard gebruikt iedereen hier braaf een VPN verbinding en stuurt niemand gevoelige gegevens over zo'n publiek netwerk ;)

Tijd voor MONSTER patches voor iedereen behalve Microsoft. De Linux fanboys moeten hard slikken en aan het werk.

http://www.zdnet.com/google-aws-rackspace-affected-by-heartbleed-openssl-flaw-but-azure-escapes-7000028281/

Synology is druk bezig geweest en in de loop van vandaag zijn er patches voor all hun nassen beschikbaar geworden. Ik heb direct ook het certificaat vernieuwd.

http://filippo.io/Heartblee

Volgens VirusTotal is deze site clean maar ook veilig?

LastPass Heartbleed checker


WARNING: www.google.com was confirmed as vulnerable either publicly via statement or on 4/8/2014 LINK

Site: www.google.com
Server software: Not reported
Vulnerable: Possibly (might use OpenSSL)
SSL Certificate: Unsafe (created 4 weeks ago at Mar 12 09:38:30 2014 GMT)
Assessment: Wait for the site to update before changing your password

LastPass Heartbleed checker


Site: lastpass.com
Server software: LastPass
Vulnerable: Possibly (might use OpenSSL)
SSL Certificate: Now Safe (created 3 days ago at Apr 8 00:00:00 2014 GMT)
Assessment: Change your password on this site if your last password change was more than 3 days ago


Check another site?
https://lastpass.com/heartbleed/

:( wachtwoord veranderen dus! Maar wacht tot google zijn site clean heeft! zonder yubikey komen ze toch mijn account niet in!

Gemiste vraag hier, ook wel 'de hamvraag' (voor vegetariërs 'de broccoli vraag') voor diegenen die een account hebben hier : Hoe Certified Secure is security.nl, was security nl ook kwetsbaar voor HeartBleed?
Dient iedereen hier zijn of haar passwords beter te veranderen?

Veel discussie en vragen over Heartbleed, OpenSSL, certificaten en passwords, maar niet deze.
Opmerkelijk eigenlijk.

die lastpass check is heel erg slecht, checkt alleen response header en als daar dan een openssl versienummer in staat, geeft ie aan de hand daarvan een resultaat. en die check op versienummer is ook nog eens stuk.

correcte test hier: http://filippo.io/Heartbleed/

Hele mooie assumptie website:

- je gebruikt ssl
- je gebruikt apache
- jer certificaat is niet onlangs revoken

Definitely kwetsbaar!

Ze gaan dus er niet van uit dat mensen load balancers gebruiken die SSL offloading doen (waar het dus om gaat) en dat die NIET kwetsbaar zijn.
Thanks but not thanks Lastpass!

Mooi staaltje bedrijven in een zwart daglicht stellen.

+1 lastpass verpreidt FUD

Niet dat ik voor Lastpass wil opkomen, maar er zijn nogal wat loadbalancers wel kwestsbaar. Bijvoorbeeld van Amazon, en dat hebben ze ook toegegeven.

Ja je mist iets,je wachtwoordenlijst printen is volgens mij nl. ook niet bepaald veilig.Je kunt dat beter zelf met de hand doen,m.b.v. een ballpoint.In een notitieboekje o.i.d.

Ja je mist wel wal.

Je hoeft geen verkeer te sniffen of the replayen; je kunt op afstand een stuk geheugen van de server uitlezen. Dit stuk geheugen bevat gedecrypte data. Welke data dat precies is kun je niet sturen, maar we hebben het zelf uitgeprobeerd, en we zagen wachtwoorden langs komen, en mail, en kalender entries. We hebben niet gekeken of er ook private keys bij zaten maar dat zou goed kunnen. Kortom: je hoeft geen directe aanval te doen, je hoeft geen mitm te spelen, en het is niet moeilijk om deze exploit te misbruiken.

Wat ingewikkeld allemaal.Wat loop ik als gewone computer/internetgebruiker voor gevaar bij dit SSL lek? Ik heb zelf geen servers,netwerken,alleen een modem,een router,een desktop een laptop (beiden windows 32 bits),ik gebruik upcmail,g-mail,hotmail/outlook,yahoo mail,facebook,twitter,skype ik heb top beveiliging op de ene pc heb ik Norton 360 en op de andere Kaspersky Pure 3.0. Internetbankieren en I-deal doe ik niet aan ,al bestel ik weleens wat online.Dus..wat loop ik hier bij voor gevaar??
Wat kan ik aan doen m.b.t. dit SSL-lek?

Je kunt als gebruiker niet veel.. Diverse leveranciers patchen de lekken, afwachten maar..

Een hele fijne lowtech uitleg hier :

http://xkcd.com/1354/

Clients kunnen dus zonder boundery check gegevens uitvragen over SSL verkeer. Deze boundary check moet gepatched worden (McAfee heeft bv al hun software al gepatched).

Als gebruiker zijn er drie dingen die je moet doen:
- je eigen software updaten (maar dat moet je toch al)
- van de diensten die je gebruikt, achterhalen of ze getroffen zijn, en of ze al gepatcht zijn (zo niet: GEEN gebruik van maken)
- zodra ze gepatcht zijn er je wachtwoord veranderen

Waar ik volgens mij nog niemand over gehoord heb is de enorme bijwerking die dit lek zal hebben. Er zal een enorme phishing aanval worden opgezet om je te verleiden je wachtwoord van weet-ik-veel te wijzigen.

Misschien is het aantal gecompromiteerde accounts/wachtwoorden daardoor straks veel hoger dan nu door het heartbleed lek.

Kortom: alleen ww wijzigen vanuit je bladwijzers/favorieten en niet via de links in de mail. Zegt 't voort. :)

Achteraf kan iederéén net zo lullen tot reciproce laterale inhibitie, dus eigen-lijk disfunctioneel binnen het geheel.