'Google Chrome heeft beste controle SSL-certificaten'
De manier waarop browsers zoals Internet Explorer, Mozilla Firefox en Safari SSL-certificaten controleren werkt niet, aldus Google-ingenieur Adam Langley. Langley reageerde naar aanleiding van adviezen die vanwege de Heartbleed-bug in OpenSSL werden gegeven.
Vanwege de Heartbleed-bug kunnen aanvallers de privésleutel van SSL-certificaten stelen. Veel websites besloten hierop hun SSL-certificaat opnieuw uit te geven of in z'n geheel te vervangen en het oude certificaat in te laten trekken. SSL-certificaten spelen een belangrijke rol op internet, omdat ze de verbinding tussen bezoeker en website versleutelen en gebruikers de identiteit van de website laten controleren.
Certificaatcontrole
Internetbrowsers kunnen ingetrokken SSL-certificaten herkennen dankzij het Online Certificate Status Protocol (OCSP). Als OCSP niet werkt kunnen browsers terugvallen op de certificate revocation list (CRL), een lijst met ingetrokken SSL-certificaten. Google Chrome gebruikt geen van beide methodes en dat kwam de browser op kritiek van internetbedrijf Netcraft te staan. Chrome-gebruikers werden vervolgens opgeroepen om de optie 'Controleren op intrekking van servercertificaten' in te schakelen, maar Langley waarschuwt nu dat gebruikers dit niet moeten doen.
De manier waarop Google namelijk op ingetrokken SSL-certificaten controleert zou namelijk veel beter zijn. Chrome gebruikt een eigen mechanisme genaamd CRLSets, een verzamelde lijst van ingetrokken certificaten die door Google wordt samengesteld en via updates naar de browser wordt gestuurd. Aanvallers die zich tussen de gebruiker en het internet bevinden kunnen namelijk de OCSP-verzoeken van de browser blokkeren, waardoor een gebruiker niet doorkrijgt dat een certificaat is ingetrokken.
Zinloos
"Daarom stel ik dat online controles op ingetrokken certificaten zinloos zijn, omdat het aanvallen niet voorkomt", laat Langley weten. Het enige dat deze controles volgens de ingenieur doen is dingen vertragen. "Je kunt vertellen wanneer iets securitytheater is omdat je in een absurd specifieke situatie moet zitten voordat het zinnig is." Chrome voert deze "zinloze controles" dan ook niet uit.
Dagelijks stelt Google lijsten van belangrijke ingetrokken certificaten samen die via de automatische update functie naar Chrome-gebruikers worden gestuurd. Het is vooral bedoeld om op belangrijke situaties te reageren, zoals met DigiNotar het geval was. "Het is zeker niet perfect, maar beter dan wat andere browsers doen", merkt Langley op.
Hij stelt dat een aanvaller kan voorkomen dat een gebruiker Chrome-updates ontvangt, maar dan zou die het verkeer van die gebruiker gedurende een lange tijd moeten blokkeren. "Maar dat is een fundamentele grens, we kunnen alleen op Chrome-problemen reageren, waaronder beveiligingslekken, door updates uit te geven."
Reacties (21)
22-04-2014, 10:26 door
fransdb
VRaag me af hoe groot dan deze lijst zelf is alsmede een gemiddelde update? Immers, OCSP wordt gebruikt omdat alle CRL's te groot zijn geworden voor small memory devices.
Als deze lijst net zo goed onderhouden wordt als hun malware lijst, hou ik mijn hart vast...
Laatst nog een driver gedownload van internet voor een zender van me (Kenwood).
Die is al bijna 10 jaar oud, is ook al 10 jaar door virustotal heen gehaald en net toen ik op mijn XP machine Security Essentials verwijderd had vanwege de nag-meldingen begon Chrome te miepen "ik blokkeer dit bestand want dit is een virus".
Waar Google het vandaan haalde dat er een virus in zou moeten zitten is mij een raadsel. Wellicht omdat het dubbel ingepakt is maar dan nog...
Laatst nog een driver gedownload van internet voor een zender van me (Kenwood).
Die is al bijna 10 jaar oud, is ook al 10 jaar door virustotal heen gehaald en net toen ik op mijn XP machine Security Essentials verwijderd had vanwege de nag-meldingen begon Chrome te miepen "ik blokkeer dit bestand want dit is een virus".
Waar Google het vandaan haalde dat er een virus in zou moeten zitten is mij een raadsel. Wellicht omdat het dubbel ingepakt is maar dan nog...
'Google Chrome heeft beste controle SSL-certificaten'
De manier waarop browsers zoals Internet Explorer, Mozilla Firefox en Safari SSL-certificaten controleren werkt niet
De manier waarop browsers zoals Internet Explorer, Mozilla Firefox en Safari SSL-certificaten controleren werkt niet
Dat de controle via het automatisch bijwerken van een revocation list goed werkt geloof ik wel.
Dat andere maatregelen helemaal niet werken lijkt er niet op.
Firefox Voorkeuren
1) Firefox > Preferences > Advanced > Certificates > Validation >
X : "Use the Online Certificate Status Protocol (OCSP) to confirm the current validity of certificates"
X : "When an OCSP server connection fails, treat the certificate as invalid"
Aanvallers die zich tussen de gebruiker en het internet bevinden kunnen namelijk de OCSP-verzoeken van de browser blokkeren, waardoor een gebruiker niet doorkrijgt dat een certificaat is ingetrokken.
Wanneer beide opties zijn aangevinkt lijkt het erop dat wanneer een OCSP verzoek wordt geblokkeerd (door kwaadwillenden) er ook geen website-verbinding plaatsheeft, dan 'Treat' Firefox "the certificate as invalid".
Geblokkeerd in dat geval.
Dat is op zijn minst de suggestie van de voorkeurinstelling.
2) Firefox > Preferences > Advanced > Certificates > View Certificates > Servers >
Lijst met ingetrokken certificaten
Certificate Name > "…" > View > General > "Could not verify this certificate because it is not trusted"
Helaas wordt deze lijst alleen ververst bij een nieuwe Firefox release of tussentijdse fixes.
3) Je systeem heeft ook nog een eigen certificaat beheer waarbij bepaalde certificaten kunnen worden geblokkeerd.
De lijst daarvan zal weer bijgewerkt worden met tussentijdse updates van het Os (?).
Firefox zou dus kunnen verbeteren door een automatische update functie in te bouwen voor de revocation list in plaats van deze alleen te vernieuwen bij elke nieuwe release?
Er zijn overigens meer browsers die automatisch updaten (continue naar browser updates zoeken), zou Google Chrome echt de enige browser zijn die dit heeft geïmplementeerd?
Er zijn nogal wat browsers namelijk.
OCSP gaat niet werken inderdaad. En CRLs zijn te traag en administratief een redelijke uitdaging.
Waarom zou je geen kortlevende server certificaten gebruiken?
Een keer per dag een certificaat welke automatisch wordt geïnstalleerd.
Je hebt dan geen CRL's nodig want je update binnen het tijdbestek van de 24-uurs CRL.
Waarom zou je geen kortlevende server certificaten gebruiken?
Een keer per dag een certificaat welke automatisch wordt geïnstalleerd.
Je hebt dan geen CRL's nodig want je update binnen het tijdbestek van de 24-uurs CRL.
22-04-2014, 12:56 door
Briolet
Aanvallers die zich tussen de gebruiker en het internet bevinden kunnen namelijk de OCSP-verzoeken van de browser blokkeren, waardoor een gebruiker niet doorkrijgt dat een certificaat is ingetrokken.
Dat snap ik niet helemaal. Als je geen verbinding met de OCSP server kunt krijgen, dan kun je dat certificaat toch bij voorbaat als ongeldig verklaren? Op de mac heb je 4 instellingen voor controle. Uit/Beste poging/Vereist als certificaat dat aangeeft/Altijd controleren. De laatste 2 opties worden alleen aangeraden voor een sterk beveiligde omgeving. Standaard zijn ze ook niet selecteerbaar, maar moet je de optie-toets erbij gebruiken om ze te kunnen selecteren.
Ik vraag me overigens af in hoeverre bovenstaande artikel ook voor de mac versie van Chrome geldt. Op de mac wordt het hele certificaatbeheer van Chrome aan het systeem overgelaten. Als je de optie "certificaten beheren" in Chrome kiest, opent hij ook het Sleutelhanger programma op de mac. Ze hadden blijkbaar geen zin een eigen interface te schrijven. Ook de controle op ingetrokken certificaten staat in Chrome standaard uit, maar omdat hij de systeemprocedures gebruikt voor de certificaten, lijkt mij dat het systeem deze controle al uitvoert, mist het daar ingesteld is.
22-04-2014, 13:20 door
Briolet
In het stukje van Langley lees ik net:
Dat is dus onzin dat iedereen een "soft-fail" doet. Op de Mac kun je instellen om een certificaat af te weizen als er geen controle plaats kan vinden. Het is een systeem instelling, dus denk ik dat dit bij Chrome zal gebeuren. Het is dus een heel gekleurd stukje wat Langley daar schrijft.
Overigens nog iets leuks voor de Mac gebruikers van Chrome. Heeft iemand zich wel eens afgevraagd waarom Chrome na elke update weer groter is? Dat komt omdat alle oude versies in de applicatie blijven staan. Selecteer de applicatie maar eens met een option-klik en kies "open pakketinhoud". Daar zul je een folder "Versions" vinden. In deze folder staan subfolders met chrome-versies die elk zo'n 150 MB groot zijn. Alleen de laatste versie wordt gebruikt, de rest kun je veilig weggooien. Ik ruim het ook af en toe op, maar zag dat er sinds 17 sept 2013 alweer 14 oude versies in staan. Dat is dus inmiddels al weer 14 x 150 MB = 2 GB aan zinloze opslag.
Weet iemand of er een instelling is om dit te voorkomen?
Everyone does soft-fail for a number of reasons on top of the general principle that single points of failure should be avoided. Firstly, the Internet is a noisy place and sometimes you can't get through to OCSP servers for some reason. If you fail in those cases then the level of random errors increases.
Dat is dus onzin dat iedereen een "soft-fail" doet. Op de Mac kun je instellen om een certificaat af te weizen als er geen controle plaats kan vinden. Het is een systeem instelling, dus denk ik dat dit bij Chrome zal gebeuren. Het is dus een heel gekleurd stukje wat Langley daar schrijft.
Overigens nog iets leuks voor de Mac gebruikers van Chrome. Heeft iemand zich wel eens afgevraagd waarom Chrome na elke update weer groter is? Dat komt omdat alle oude versies in de applicatie blijven staan. Selecteer de applicatie maar eens met een option-klik en kies "open pakketinhoud". Daar zul je een folder "Versions" vinden. In deze folder staan subfolders met chrome-versies die elk zo'n 150 MB groot zijn. Alleen de laatste versie wordt gebruikt, de rest kun je veilig weggooien. Ik ruim het ook af en toe op, maar zag dat er sinds 17 sept 2013 alweer 14 oude versies in staan. Dat is dus inmiddels al weer 14 x 150 MB = 2 GB aan zinloze opslag.
Weet iemand of er een instelling is om dit te voorkomen?
22-04-2014, 13:35 door
Mozes.Kriebel
WC-eend...
OS X : Keychain certificaat beheer extra nalopen / instellen (check het voor de eigen OS X versie)
Algemene OS X Keychain (Sleutelhanger) voorkeuren
Keychain Access.app > Preferences > Certificates >
Online Certificate Status Protocol (OCSP) : "Best Attempt"
Certification Revocation List : "Best Attempt"
Priority : "Require Both" (OCSP & CRL)
Andere settings zijn ook mogelijk natuurlijk, het beargumenteerde waarom van het eventueel beter mag een ander dan uitleggen.
OS X manual certificate check
Apple OS X handmatige intrekking / certificate check
(mocht je OS X versie wat ouder zijn of mocht je twijfelen aan de actuele stand van zaken)
Het helpt een beetje, een handmatige check op certificaten / handmatige intrekking
(sommige browsers gebruiken de systeem keychain defaults, Safari, diverse Chromium browsers, bijvoorbeeld Opera.
Bij andere kan je weer kiezen door het weglaten van een aangevinkte optie om de browser zelf op certificaten te laten cheken via OCSP *)
- Apple menu > Go > Utilities > Keychain Access.app > Keychains: System Roots / Category : Certificates
- Klik op de "Expires" kolom
- Dubbelklik op een certificate waarvan de verloopdatum is verstreken (als je die ziet)
- Unlock "System Roots Keychain" met je admin password
- Klik op uitklap-driehoekje voor "Trust"
- "When using this certificate" (bovenaan in het veld), verander "Use System Defaults" in "Never Trust"
- Sluit het veld
Mocht je een extra uitgaande Firewall hebben geïnstalleerd is het raadzaam verbinding van "ocspd" , www.apple.com.edgekey.net over poort 80 toe te staan.
What is “ocspd”? — Process safety information
http://www.macinside.info/process.php?name=ocspd
"Description:
"ocspd" is a daemon that is used by the system framework to perform security certificate verifications. This daemon caches or fetches from the network Certificate Revocation Lists (CRL) and deals with the Online Certification Status Protocol (OCSP)."
( Handig voor opzoeken : Macinside - Browse all Mac Processes
http://www.macinside.info/browse.php )
* Chromium browsers met HTTPS/SSL aan/afvink optie (niet compleet)
https://www.security.nl/posting/384944#posting385104
Algemene OS X Keychain (Sleutelhanger) voorkeuren
Keychain Access.app > Preferences > Certificates >
Online Certificate Status Protocol (OCSP) : "Best Attempt"
Certification Revocation List : "Best Attempt"
Priority : "Require Both" (OCSP & CRL)
Andere settings zijn ook mogelijk natuurlijk, het beargumenteerde waarom van het eventueel beter mag een ander dan uitleggen.
OS X manual certificate check
Apple OS X handmatige intrekking / certificate check
(mocht je OS X versie wat ouder zijn of mocht je twijfelen aan de actuele stand van zaken)
Het helpt een beetje, een handmatige check op certificaten / handmatige intrekking
(sommige browsers gebruiken de systeem keychain defaults, Safari, diverse Chromium browsers, bijvoorbeeld Opera.
Bij andere kan je weer kiezen door het weglaten van een aangevinkte optie om de browser zelf op certificaten te laten cheken via OCSP *)
- Apple menu > Go > Utilities > Keychain Access.app > Keychains: System Roots / Category : Certificates
- Klik op de "Expires" kolom
- Dubbelklik op een certificate waarvan de verloopdatum is verstreken (als je die ziet)
- Unlock "System Roots Keychain" met je admin password
- Klik op uitklap-driehoekje voor "Trust"
- "When using this certificate" (bovenaan in het veld), verander "Use System Defaults" in "Never Trust"
- Sluit het veld
Mocht je een extra uitgaande Firewall hebben geïnstalleerd is het raadzaam verbinding van "ocspd" , www.apple.com.edgekey.net over poort 80 toe te staan.
What is “ocspd”? — Process safety information
http://www.macinside.info/process.php?name=ocspd
"Description:
"ocspd" is a daemon that is used by the system framework to perform security certificate verifications. This daemon caches or fetches from the network Certificate Revocation Lists (CRL) and deals with the Online Certification Status Protocol (OCSP)."
( Handig voor opzoeken : Macinside - Browse all Mac Processes
http://www.macinside.info/browse.php )
* Chromium browsers met HTTPS/SSL aan/afvink optie (niet compleet)
https://www.security.nl/posting/384944#posting385104
22-04-2014, 14:08 door
[Account Verwijderd]
-
Bijgewerkt: 22-04-2014, 14:08
[Verwijderd]
Door Briolet:
Overigens nog iets leuks voor de Mac gebruikers van Chrome.
...
Selecteer de applicatie maar eens met een option-klik en kies "open pakketinhoud". Daar zul je een folder "Versions" vinden.
...
Overigens nog iets leuks voor de Mac gebruikers van Chrome.
...
Selecteer de applicatie maar eens met een option-klik en kies "open pakketinhoud". Daar zul je een folder "Versions" vinden.
...
Kijk eens aan een Mac-Google-Chrome gebruiker,..
Nu je daar toch aan het rond struinen bent.
(in het kader van de Chrome controle)
Klik eens door tot je hier uit komt :
Chrome.app/Contents/Versions/34.0.1847.116/Google\ Chrome\ Framework.framework/Internet\ Plug-Ins/PepperFlash/PepperFlashPlayer.plugin
CMD i op de PepperFlashPlayer.plugin geeft welke versie informatie?
Ga nu eens in chrome naar (browser url paste) : chrome://plugins/
Kijk eens bij Flash player versie(s), klik details aan.
Welke Flashplayer plugin versies staan daar vermeld?
Komt die (of één daarvan) exact overeen met de versie-informatie die je zag bij het struinen in de package contents, specifiek de PepperFlashPlayer.plugin?
Mocht je specifiekere info over de exacte plugin versie informatie willen hebben kan je ook nog in de package contents van de PepperFlashPlayer.plugin kijken en in de contents map het info en of het version file openen.
Komt die overeen met de opgave in het plugin voorkeur venster van Chrome?
En? Wat is de bevinding ..?
Door Briolet:
Overigens nog iets leuks voor de Mac gebruikers van Chrome. Heeft iemand zich wel eens afgevraagd waarom Chrome na elke update weer groter is? Dat komt omdat alle oude versies in de applicatie blijven staan.
..
Dat is dus inmiddels al weer 14 x 150 MB = 2 GB aan zinloze opslag.
Weet iemand of er een instelling is om dit te voorkomen?
Overigens nog iets leuks voor de Mac gebruikers van Chrome. Heeft iemand zich wel eens afgevraagd waarom Chrome na elke update weer groter is? Dat komt omdat alle oude versies in de applicatie blijven staan.
..
Dat is dus inmiddels al weer 14 x 150 MB = 2 GB aan zinloze opslag.
Weet iemand of er een instelling is om dit te voorkomen?
:-) It's not a bug, it's a feature! (?)
Gevolg van een hele sterke Sandbox ? :-(
Probleem bestaat al jaren en het kan nog erger.
"Google Chrome takes 6 GB of my hard disk"
(11/10/13) https://groups.google.com/d/topic/comp.sys.mac.system/bgFgjO4jWLk
"Chrome App Size "
http://forums.macrumors.com/showthread.php?t=1411803
"Reduce the size of Google Chrome"
http://hints.macworld.com/article.php?story=20120426095831578
"If you want to turn off this automatic updating, see this hint from 2010."
Een halve oplossing
(! Oplossing niet zelf getest!)
"Prevent Google Chrome's updater from running"
http://hints.macworld.com/article.php?story=20100406184528139
Af en toe handmatig een frisse schone "googlechrome.dmg" downloaden en installeren dan maar?
Kan je ook geen 'fouten' maken met gerommel in de package contents.
Wij van WC-eend kramen maar eens weer onwaarheden uit omdat steeds meer meer mensen privacy bewust worden en de spionerende WC-eend links laten liggen, zoals we op deze site hebben kunnen lezen.
"Aanvallers kunnen de OCSP-verzoeken van de browser blokkeren, waardoor een gebruiker niet doorkrijgt dat een certificaat is ingetrokken."
Dat is pertinent NIET waar! Als een OCSP verzoek, om wat voor reden dan ook, niet gehonoreerd wordt, dan wordt (in ieder geval in Firefox) ten eerste de site geblokkeerd en ten tweede krijg je een bijna schermvullende waarschuwing dat Firefox de "security" van de site in kwestie niet kan garanderen. Je kunt nu stoppen of op eigen risico verder gaan.
Verder zegt hij zelf dat een aanvaller hetzelfde kan doen bij Chrome, die dan geen waarschuwing geeft!
Vreemd is ook het advies om de optie 'Controleren op intrekking van servercertificaten' NIET in te schakelen.
Ik kraak andere browsers niet af. Gebruik zelf Firefox vanwege de privacy; de meest uitgebreide mogelijkheden in de browser zelf en de paar duizend extensies waarvoor andere browser slechts een paar slappe aftreksels bieden.
"Aanvallers kunnen de OCSP-verzoeken van de browser blokkeren, waardoor een gebruiker niet doorkrijgt dat een certificaat is ingetrokken."
Dat is pertinent NIET waar! Als een OCSP verzoek, om wat voor reden dan ook, niet gehonoreerd wordt, dan wordt (in ieder geval in Firefox) ten eerste de site geblokkeerd en ten tweede krijg je een bijna schermvullende waarschuwing dat Firefox de "security" van de site in kwestie niet kan garanderen. Je kunt nu stoppen of op eigen risico verder gaan.
Verder zegt hij zelf dat een aanvaller hetzelfde kan doen bij Chrome, die dan geen waarschuwing geeft!
Vreemd is ook het advies om de optie 'Controleren op intrekking van servercertificaten' NIET in te schakelen.
Ik kraak andere browsers niet af. Gebruik zelf Firefox vanwege de privacy; de meest uitgebreide mogelijkheden in de browser zelf en de paar duizend extensies waarvoor andere browser slechts een paar slappe aftreksels bieden.
Door Briolet:
Dat snap ik niet helemaal. Als je geen verbinding met de OCSP server kunt krijgen, dan kun je dat certificaat toch bij voorbaat als ongeldig verklaren?
Aanvallers die zich tussen de gebruiker en het internet bevinden kunnen namelijk de OCSP-verzoeken van de browser blokkeren, waardoor een gebruiker niet doorkrijgt dat een certificaat is ingetrokken.
Dat snap ik niet helemaal. Als je geen verbinding met de OCSP server kunt krijgen, dan kun je dat certificaat toch bij voorbaat als ongeldig verklaren?
Dat biedt kwaadwillenden de mogelijkheid om grote delen van het internet plat te leggen door een paar OCSP servers uit de lucht te DDoSsen.
Naast de hierboven al genoemde settings van Firefox kan een registry setting er ook voorzorgen dat IE aangeeft dat hij de revocation niet kan controleren. Daarna is 't de keuze van de gebruiker die bepaalt of je doorgaat.
Door Anoniem: Dat is pertinent NIET waar! Als een OCSP verzoek, om wat voor reden dan ook, niet gehonoreerd wordt, dan wordt (in ieder geval in Firefox) ten eerste de site geblokkeerd en ten tweede krijg je een bijna schermvullende waarschuwing dat Firefox de "security" van de site in kwestie niet kan garanderen. Je kunt nu stoppen of op eigen risico verder gaan.
Dit dus, als je dan nog steeds wil inloggen, tsja.Maar is het echt zo dat als je de certificaat controle aanvinkt in Chrome, deze juist niet gaat werken? HUH?
22-04-2014, 18:23 door
[Account Verwijderd]
-
Bijgewerkt: 22-04-2014, 18:25
[Verwijderd]
22-04-2014, 18:48 door
Briolet
Door Anoniem:Kijk eens aan een Mac-Google-Chrome gebruiker,..
Nu je daar toch aan het rond struinen bent.
(in het kader van de Chrome controle)
Klik eens door tot je hier uit komt :
Chrome.app/Contents/Versions/34.0.1847.116/Google\ Chrome\ Framework.framework/Internet\ Plug-Ins/PepperFlash/PepperFlashPlayer.plugin......
Nu je daar toch aan het rond struinen bent.
(in het kader van de Chrome controle)
Klik eens door tot je hier uit komt :
Chrome.app/Contents/Versions/34.0.1847.116/Google\ Chrome\ Framework.framework/Internet\ Plug-Ins/PepperFlash/PepperFlashPlayer.plugin......
Normaal ben ik ook een Safari gebruiker, maar op mijn laatste OSX 10.6 moet ik toch van Safari af... (Chrome of Firefox, that is the question)
Maar een interessant punt dat je daar aanstipt. Op mijn OSX 10.6 systeem staat de flashplayer 13.0.0.201 geïnstalleerd. (De nieuwste.)
De plugin lijst in Chrome beweerd dat hij versie 13.0.0.182 gebruikt. Dat is dus i.d.d. niet de laatste versie die op mijn systeem staat.
De infobox van de PepperFlashPlayer die in Chrome zelf zit geeft aan: Adobe Flash Player 11.8 d800 Copyright (c) 1996-2010. De aanmaakdatum is wel van 2 april 2014. Het lijkt er gewoon op dat ze niet de moeite genomen hebben om die string bij elke compile mee te updaten, dus dat is niet verontrustend maar alleen erg slordig. Waarschijnlijk is het wel de versie 13.0.0.182
Verontrustender is dat hun flashplayer niet op basis van de laatste flashplayer gemaakt is en achterloopt in de laatste Chrome versie.
Dat is pertinent NIET waar! Als een OCSP verzoek, om wat voor reden dan ook, niet gehonoreerd wordt, dan wordt (in ieder geval in Firefox) ten eerste de site geblokkeerd en ten tweede krijg je een bijna schermvullende waarschuwing dat Firefox de "security" van de site in kwestie niet kan garanderen. Je kunt nu stoppen of op eigen risico verder gaan.
Gezien de belangstelling wil ik mijn reactie nog aanvullen met het volgende.
In Firefox zit ook een optie om, als een OCSP request niet gehonoreerd wordt, het certificaat ongeldig te verklaren.
Advanced -> Certificates ->Validation. -> Optie: "When an OCSP server connection fails, treat the certificate as invalid."
Onder "View Certificates" kun je niet alleen alle certificaten bekijken maar ook zelf verwijderen of wijzigen.
Zelf gebruik ik de extensie "Certificate Patrol" voor Firefox. Iets dergelijks, maar minder uitgebreid, bestaat ook voor Chrome.
Door Briolet:
Normaal ben ik ook een Safari gebruiker, maar op mijn laatste OSX 10.6 moet ik toch van Safari af... (Chrome of Firefox, that is the question)
Maar een interessant punt dat je daar aanstipt.
Normaal ben ik ook een Safari gebruiker, maar op mijn laatste OSX 10.6 moet ik toch van Safari af... (Chrome of Firefox, that is the question)
Maar een interessant punt dat je daar aanstipt.
* Komt voor uit deze post
(met waaier aan Flash gerelateerde onderwerpen, komen na de ergernis over de npo, gewoon stug doorlezen of skippen)
https://www.security.nl/posting/384173#posting385120
https://www.security.nl/posting/384173#posting385254
( https://www.security.nl/posting/384173/Adobe+Flash+Player+%2813%29+Problemen )
* Er zijn overigens meer Chromium gebaseerde browsers voor OS X
https://www.security.nl/posting/384944#posting385104
- Opera 20.0.1387.91
- Chromium 34.0.1847.116
- SRWare Iron - Version 31.0.1700.0 (238485)
- Epic 34.0.1771.0
Minder favoriet (ben het nog aan het onderzoeken en testen)
- Maxthon-4.1.3.4000
Nog minder favoriet
- Google Chrome Version 34.0.1847.116
- Aviator 28.0.1500.71
- Yandex 33.0.1750.13412 / 33.0.1750.154
* Wat betreft Opera en config , aanmoedigende overweging eens naar Opera (+ wat addons) te kijken.
https://www.security.nl/posting/385065#posting385291
https://www.security.nl/posting/385065#posting385310
Je hoeft niet per se als alternatief voor Safari te kiezen voor Firefox of Google Chrome : vele alternatieven beschikbaar.
De meeste Chrome/Chromium varianten zijn erg vergelijkbaar, met hier en daar wat (push of deleted) aanpassingen van de 'brand'-editor, soms te dwingend of nadelig voor de gebruiker (privacy).
Beschikbare addons kunnen heel bepalend zijn voor de acceptatie van een browser.
Miliseconden browser speedtests zou ik niet teveel aan hangen, configmogelijkheden en vrije keuze aan de gebruiker des te meer.
Een browser is tenslotte één van de meest gebruikte apps die je dagelijks voor je neus hebt, niet onbelangrijk dus.
Ik vind het grappig dat op dit artikel zo uitgebreid gereageerd wordt. Het is toch wel duidelijk dat deze meneer van Google "hun" browser aan het aanprijzen is? De "Wij van WC-eend" reacties zijn hier toch wel degelijk van toepassing. Zo doorzichtig allemaal.
Google begint steeds meer op Microsoft in hun hoogtijdagen te lijken.
Google begint steeds meer op Microsoft in hun hoogtijdagen te lijken.
Door Anoniem:
* Er zijn overigens meer Chromium gebaseerde browsers voor OS X
..
- Opera 20.0.1387.91
- Chromium 34.0.1847.116
- SRWare Iron - Version 31.0.1700.0 (238485)
- Epic 34.0.1771.0
Minder favoriet (ben het nog aan het onderzoeken en testen)
- Maxthon-4.1.3.4000
Nog minder favoriet
- Google Chrome Version 34.0.1847.116
- Aviator 28.0.1500.71
- Yandex 33.0.1750.13412 / 33.0.1750.154
* Er zijn overigens meer Chromium gebaseerde browsers voor OS X
..
- Opera 20.0.1387.91
- Chromium 34.0.1847.116
- SRWare Iron - Version 31.0.1700.0 (238485)
- Epic 34.0.1771.0
Minder favoriet (ben het nog aan het onderzoeken en testen)
- Maxthon-4.1.3.4000
Nog minder favoriet
- Google Chrome Version 34.0.1847.116
- Aviator 28.0.1500.71
- Yandex 33.0.1750.13412 / 33.0.1750.154
Chrome en Iron browser
Extra info SRWare Iron - Version 31.0.1700.0 (238485)
* Wat twijfelachtige reputatie / motivatie-track-record
Voor wat online kritieken waard zijn, het geeft een indicatie
https://www.macupdate.com/app/mac/33434/srware-iron
http://neugierig.org/software/chromium/notes/2009/12/iron.html
* 'Geen' overtuigend update 'beleid', lopen 'vaak' diverse kwetsbaardere chromium versies achter, 31.0.1700 is van medio oktober 2013
http://en.wikipedia.org/wiki/Chromium_%28web_browser%29
Huidige up to date versie is april versie 34.0.1847.116
Dat hebben (weer back on topic) zowel Google Chrome als Chromium.
Iron browser en Google Chrome dan maar verwisselen van plaats in eerder genoemde rijtjes?
Iron boven Aviator, Google Chrome tussen Epic en Maxthon browser?
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
