Computerbeveiliging
- Hoe je bad guys buiten de deur houdt
misschien kan de security config van www.security.nl ietsje beter ???
Lijkt mij dat SSL3 support (windows XP met IE6....) niet echt meer nodig is voor de bezoekers van *deze* site ?
zie de links hieronder. btw, ze geven uitstekende suggesties om je webserver beter in te richten qua SSL.......
https://www.ssllabs.com/ssltest/analyze.html?d=www.security.nl&s=213.156.0.246
https://www.ssllabs.com/ssltest/analyze.html?d=www.security.nl&s=213.156.0.236
zie de links hieronder. btw, ze geven uitstekende suggesties om je webserver beter in te richten qua SSL.......
https://www.ssllabs.com/ssltest/analyze.html?d=www.security.nl&s=213.156.0.246
https://www.ssllabs.com/ssltest/analyze.html?d=www.security.nl&s=213.156.0.236
Reacties (24)
Voor maximale veiligheid en privacy is het doorgaans het beste om "the latest and the greatest" encryptietechnieken te gebruiken die je systeem aankan. Maar wel met de kanttekening dat betere encryptietechnieken meestal ook meer processortijd kosten. (ook aan de serverkant kan dit van belang zijn: zwaar belaste systemen worden extra traag als ze ook nog eens de zwaarste encrypties moeten uitrekenen over al die verbindingen...)
Ik denk dat je de keuze van het encryptieprotocol hier aan de users moet overlaten (men kan SSL3 in IE6 uitzetten door het vinkje weg te halen. Ook andere browsers hebben mogelijkheden om SSL3 uit te zetten).
Alleen als het 100% zou vaststaan dat SSL3 beslist te onveilig zou zijn om daarmee een website zoals security.nl te bezoeken, zou aan de serverkant het initiatief moeten worden genomen. (en aangezien zelfs banken nog SSL3 accepteren...)
Aan de serverkant spelen naast veiligheid ook backwards compatibility en toegankelijkheid een rol, en je wilt als beheerder (denk ik) niet onnodig hoge encryptie-eisen stellen indien dit ten koste zou gaan van de toegankelijkheid van je website door bijv. alle SSL3 gebruikers te elimineren. (ook al zijn dat er in dit geval misschien niet zoveel)
Mvg, cluc-cluc
Ik denk dat je de keuze van het encryptieprotocol hier aan de users moet overlaten (men kan SSL3 in IE6 uitzetten door het vinkje weg te halen. Ook andere browsers hebben mogelijkheden om SSL3 uit te zetten).
Alleen als het 100% zou vaststaan dat SSL3 beslist te onveilig zou zijn om daarmee een website zoals security.nl te bezoeken, zou aan de serverkant het initiatief moeten worden genomen. (en aangezien zelfs banken nog SSL3 accepteren...)
Aan de serverkant spelen naast veiligheid ook backwards compatibility en toegankelijkheid een rol, en je wilt als beheerder (denk ik) niet onnodig hoge encryptie-eisen stellen indien dit ten koste zou gaan van de toegankelijkheid van je website door bijv. alle SSL3 gebruikers te elimineren. (ook al zijn dat er in dit geval misschien niet zoveel)
Mvg, cluc-cluc
27-09-2014, 15:40 door
Eric-Jan H te D
Door Anoniem: Voor maximale veiligheid en privacy is het doorgaans het beste om "the latest and the greatest" encryptietechnieken te gebruiken die je systeem aankan
Ik waag dat te betwijfelen. Het bedrijf waar ik werkte liep meestal één major release achter bij "the Latest". En dat bedrijf liep vooraan in het gebruik van nieuwe technologie. Zozeer zelfs dat het wereldwijd één van de weinige bedrijven was die een proeftuin vormde voor IBM. De filosofie hier achter was gebaseerd op continuïteit. Kijk alleen al maar naar Aplle's iOS8 dat deze week schielijk is terug getrokken.
Natuurlijk zijn er uitzonderingen denkbaar. Wanneer een veiligheidslek in de voorlaatste release niet gepatched (kan) worden en de berekende impact is groter dan een falende "latest and greatest" release, dan heb je weinig andere keus.
Het bedrijf waar ik werkte liep meestal één major release achter bij "the Latest".
Het maakt wel verschil waar je het hier precies over hebt: major release van wat? Van het O.S.? Release van bepaalde (experimentele) software? Dan kan ik er waarschijnlijk wel mee instemmen om zoiets ook aan te bevelen.Maar als we uitsluitend over encryptietechnieken spreken, dan is elke officiële nieuwere encryptietechniek vrijwel altijd beter dan de vorige. Iedere nieuwe encryptietechniek komt namelijk voort uit imperfecties die men heeft geconstateerd bij de oudere techniek. De nieuwere versies bevatten die imperfecties dus niet meer.
Wat soms nog wel kan gebeuren, is dat men onopgemerkt een nieuwe kwetsbaarheid (of "kinderziekte")
heeft geïntroduceerd in een nieuwe encryptietechniek. Maar dit zijn uitzonderingen.
Wat ook kan gebeuren, is dat een systeem de allernieuwste encryptietechniek niet ondersteunt.
Vandaar de zinsnede: ..."the latest and the greatest" encryptietechnieken te gebruiken die je systeem aankan.
Bijvoorbeeld TLSv1.0 is de hoogste protocolversie ("latest and greatest") die een IE6 -browser nog aankan.
Maar je loopt dan wel enig risico voor kwetsbaarheden waar TLSv1.2 geen last meer van heeft.
Wil je dit niet, omdat het om uiterst vertrouwelijke informatie gaat die absoluut niet mag worden afgeluisterd, dan zul je om alle risico's zoveel mogelijk uit te sluiten een browser moeten gebruiken die TLSv1.2 ondersteunt. Je dient er ook voor te zorgen dat TLSv1.2 (momenteel de laatste officiële protocolversie) enabled is. En de server waar je contact mee maakt,
moet uiteraard ook TLSv1.2 ondersteunen. (kun je controleren in de ssllabs.com servertest)
Mvg, cluc-cluc
patchen moet inderdaad met verstand gebeuren. maar we hebben het hier niet over Apple. DIe hebben daar n gewoonte van gemaakt, en dat weet elke apple enthousiast inmiddels ook wel.......
We hebben het over linux ( in mijn geval dan over opensuse)
Ik heb wel eens patches gezien die toch nog wat te wensen over lieten. Maar je systeem onbruikbaar maken of slechter beveligd heb ik nog niet meegemaakt, sinds 1991..... Arch linux heeft dat n keer gehad, maar dat is ook de enige die ik me kan herinneren......
En waarom iemand XP met IE 6 zou willen supporten, kan ik echt niet bedenken ?
Dat maakt het namelijk wel onmogelijk om forward secrecy te implementeren... Voor private cloud toepassing is dat toch wel n mooie feature die je dan mist....
Banken hebben 100-duizenden of millioenen klanten, dat kan je niet vergelijken met www.security.nl. Overigens krijg je van sommige banken n hele duidelijke, niet mis te verstane waarschuwing als je daar met IE6 komt aanzetten.......
Ik vind het curieus dat exact *deze* site niet optimaliseert. t is nou niet echt the latest and greatest, waar we het nu over hebben...... Gewoon de laatste patches van de stable branch, en die loopt toch al gauw 6 maanden achter op "the latest and greatest"
mr U
We hebben het over linux ( in mijn geval dan over opensuse)
Ik heb wel eens patches gezien die toch nog wat te wensen over lieten. Maar je systeem onbruikbaar maken of slechter beveligd heb ik nog niet meegemaakt, sinds 1991..... Arch linux heeft dat n keer gehad, maar dat is ook de enige die ik me kan herinneren......
En waarom iemand XP met IE 6 zou willen supporten, kan ik echt niet bedenken ?
Dat maakt het namelijk wel onmogelijk om forward secrecy te implementeren... Voor private cloud toepassing is dat toch wel n mooie feature die je dan mist....
Banken hebben 100-duizenden of millioenen klanten, dat kan je niet vergelijken met www.security.nl. Overigens krijg je van sommige banken n hele duidelijke, niet mis te verstane waarschuwing als je daar met IE6 komt aanzetten.......
Ik vind het curieus dat exact *deze* site niet optimaliseert. t is nou niet echt the latest and greatest, waar we het nu over hebben...... Gewoon de laatste patches van de stable branch, en die loopt toch al gauw 6 maanden achter op "the latest and greatest"
mr U
patchen moet inderdaad met verstand gebeuren. maar we hebben het hier niet over Apple. DIe hebben daar n gewoonte van gemaakt, en dat weet elke apple enthousiast inmiddels ook wel.......
Wat we de laatste week inmiddels ook wel weten ...
is dat vriendelijke onderbouwde verzoeken om het hier in de reactiekolommen en op het forum leuk en constructief te houden bij een aantal niet binnen komen.
Gaan we het nou ook vanuit de Linux hoek beleven ?!! Kom nu toch.
Het gaat rap de andere kant op.
Welnu, de ouderwetse grote blokschaaf dan met bijbehorende aanzet over de versplinterende bijdragen gehaald en een bak met verlichte krulletjes te vullen.
Opdat het dan een keer overkomt, als voorbeeld van hoe het beter niet moet :
[Eikenhouten blokschaaf / mattenklopper mode]
'Jan Rat en zijn Maten' in een uitdijend moeras..
Helaas kruipt er een ineens een overvloed aan reaGuurder organismen de laatste tijd van onvermoed donkere plekken vandaan, met ruim mede nemen van de slijkbagger waar ze zich dagelijks gewend zijn in te wentelnestelen.
Die onfrisse nieuwe input maakt het er in de kolommen niet hygiënischer op, laat staan dat het ook maar enig zinnig en constructief effect heeft op de sfeer en informatieve verhelderende inhoudelijke bijdragen hier.
Begin eens met de handen te wassen, dan pas een poging wagen de lagen vette dirt uit de ogen te wrijven, mond en oren grondig doorspoelen.
In die andere volgorde heeft het niet gewerkt, mogen we wel constateren.
Een flinke wasbeurt dus, in de hoop dat het meervoudig persoonlijke 'jullie' dan voldoende daadwerkelijk zicht levert op informatieve media voor het kennis nemen van de benodigde relevante inhoudelijke informatie.
Informatie en kennis van zaken die goed van pas komt bij het geven van onderbouwde bijdragen.
Mocht inmiddels de blubber al ruim klotsend en als lava schurend tussen de hersenkwabben zijn aanbeland. Ja, dan heeft het verwerken van die informatie 'inderdaad' vermoedelijk geen enkel effect meer op nuttig beroep doen van enig beetje overgebleven verstandelijke capaciteit.
Meeste celletjes aangetast en weggeschuurd gespoeld, weg herinneringen, weg inlevend vermogen.
We leven in zekere zin desondanks met 'jullie' mee. Wat een tragiek.
Wees daarom zeer zuinig op die paar celletjes die nog over zijn, belast ze niet teveel, keer daarom direct, zonder omhaal, onverrichter zake weer in stilte terug naar dat donkere dirt hol waar 'jullie' vandaan kwamen.
Veilig beschut en donker, niemand die je lastig valt.
Heel graag, opdat 'we' hier op security.nl weer een beetje verschoond blijven van die achterlijke Os flamewar bengeljengelidiotie.
Want echt niet,..
geen gebruiker op Windows, OS X of Linux die met minder plezier achter zijn systeem zal zitten werken door dit soort oeverloos gemekker.
Geen gebruiker die 'jullie' met dit soort halvehersenstamstinkzwammerij overtuigen om met enig enthousiasme over te stappen op een ander systeem.
Gaat niet gebeuren, elke club zijn eigen rij, doen jullie niets tegen, laat het voor wat het is.
Volkomen zinloos dus, tenzij het 'jullie' te doen is om reactie kolommen te vervuilen met inaccurate informatie, suggestieve uitspraken om zo hard mogelijk de sfeer te lopen verzieken. Wat niet lukt want 'jullie' blijven een miereminderheid.
Wat kan natuurlijk is dat je nog steeds niet door hebt, daarom aangehaald, dat je de reeds lang vergane glorie van oude aardig bedachte en leuk bedoelde plagerige Os marketing campagnes al herkauwend aan het doorleven bent. Security van hak in een bruin glazen potje, SecuritYkeaKolder, somberburgermanstriesttuttigst!
Aan 'Jullie' allemaal;
Plak, schuif, schuur, slijm, glij en glibberrest terug naar waar je vandaan kwam of zoek een andere donkere zwammenplek om met veel genot in je eigen gal te verder te ruften. Hup! hup!
Kssssjjjt! Weg met die stinkende braakhalsblaat.
Opgehouden met dat OS gesodemieter
Want hey, er zijn immers meer dan voldoende voldoende interessante onderwerpen op deze site waar je ook in kan duiken, je je in kan verdiepen, je op kan studeren, je over kan discussiëren en waar je als je slim bent ook nog werkende oplossingen voor kan verzinnen. Challenges genoeg!
Alleen lezen mag zelfs ook nog, mocht je inderdaad verder niets te melden hebben.
Beter dan afgeven en gesmeer met kolomvuiligheid. Laat iemand lekker met zijn Xp'tje 'al voorbereidend' benodigde 'secure' content lezen hier.
Hou jij des te meer de nodige energie over om wat bash probleempjes op te lossen.
[/Eikenhouten blokschaaf / mattenklopper mode]
Heerlijk glad, schoon en helder nu?
Afdeling leuke bijdragen?
Nee, niet echt toch?
Samen op naar een ietsje betere reactie- en posting-config op security.nl :
Inhoudelijk, scherp, met een dolletjelolletje en voor de leuke uitzondering af en toe dan ook een trolletje.
Security handen uit de mouwen, zet 'm' op joh!
:) (:
En waarom iemand XP met IE 6 zou willen supporten, kan ik echt niet bedenken ?
Probeer eerst eens te bedenken waarom het door TS zo geprezen http://www.ssllabs.com zelf ook nog SSL3 ondersteunt... ;-) Mvg, cluc-cluc
28-09-2014, 20:32 door
Eric-Jan H te D
Door Anoniem:Maar als we uitsluitend over encryptietechnieken spreken, dan is elke officiële nieuwere encryptietechniek vrijwel altijd beter dan de vorige.
Zoals ik al ze. Indien patchen van de vorige release niet kan, zit er niets anders op. Maar als de vorige versie nog niet gekraakt is zou ik als groot bedrijf toch even de kat uit de boom kijken. En profiteren van de fouten die anderen in de nieuwe release vinden.
Door Eric-Jan H te A:
Zoals ik al ze. Indien patchen van de vorige release niet kan, zit er niets anders op. Maar als de vorige versie nog niet gekraakt is zou ik als groot bedrijf toch even de kat uit de boom kijken. En profiteren van de fouten die anderen in de nieuwe release vinden.
Voor de meeste softwareaangelegenheden vind ik dit ook geen slechte policy. Zoals ik al ze. Indien patchen van de vorige release niet kan, zit er niets anders op. Maar als de vorige versie nog niet gekraakt is zou ik als groot bedrijf toch even de kat uit de boom kijken. En profiteren van de fouten die anderen in de nieuwe release vinden.
Maar encryptieprotocollen worden niet gepatcht. Tenminste: in die zin heb ik de term "nieuwe versie" niet bedoeld.
De werking van dit soort protocollen wordt voor iedere versie in een zgn. rfc-document exact voorgeschreven.
De huidige gangbare versies zijn: SSL3, TLSv1.0, TLSv1.1 en TLSv1.2.
Imho is het daarom het beste om voor het nieuwste encryptieprotocol te kiezen dat het systeem dat je gebruikt aan kan.
Daarnaast kan de keuze van een sterke ("FIPS-approved") ciphersuite van belang zijn als het om bijzonder vertrouwelijke communicatie gaat.
En tot slot: aangezien het oude protocol niet direct obsolete wordt met de komst van een nieuw encryptieprotocol, is er geen sprake van een continuïteitsprobleem. Immers indien nodig kan men gemakkelijk terugvallen op het oude protocol,
dat naast het nieuwe protocol blijft bestaan om een (flinke) overgangstijd te gunnen voor de "worldwide rollover".
(zoals zich ook bewijst op "www.security.nl" die je dus zowel met SSL3, TLSv1.0, TLSv1.1 als TLSv1.2 kunt benaderen)
Mvg, cluc-cluc
Ik weet dat dit een security fora is .. maar het blijft toch gewoon een fora?
Het type zonder gevoelige informatie, openbare toegankelijkheid (en dus ook geen noodzaak tot hoge veiligheid)
Ik reageer anoniem, dus zelfs als dit forum geen enkel SSL-certificaat had; I wouldn't give a rats ass.
Maar als ik nou een hele oude bak had die enkel XP nog support en waarop ik dagelijks patience speel. Mag ik dan straks niet meer op security.nl omdat ik niet secure genoeg ben? :(
aan TS, beveiliging blijft een afweging tussen risico en opbrengsten. Wat is het risico hier?
Het type zonder gevoelige informatie, openbare toegankelijkheid (en dus ook geen noodzaak tot hoge veiligheid)
Ik reageer anoniem, dus zelfs als dit forum geen enkel SSL-certificaat had; I wouldn't give a rats ass.
Maar als ik nou een hele oude bak had die enkel XP nog support en waarop ik dagelijks patience speel. Mag ik dan straks niet meer op security.nl omdat ik niet secure genoeg ben? :(
aan TS, beveiliging blijft een afweging tussen risico en opbrengsten. Wat is het risico hier?
"Lijkt mij dat SSL3 support (windows XP met IE6....) niet echt meer nodig is voor de bezoekers van *deze* site ?"
Waar maakt je je druk om ?
Indien dit forum HTTP zou bieden i.p.v. HTTPS dan zou ik dat ook geen probleem vinden. Er is immers geen sprake van enige privacy gevoelige informatie (buiten de login als je een account gebruikt, die kan je achter HTTPS zetten).
Zelfs je login hier zou niet erg relevant moeten zijn - tenzij je *zelf* onveilig bezig bent, en je je credentials elders hergebruikt.
Alvorens je kritiek hebt op de vraag of een website HTTPS gebruikt (en welke versie SSL), is het altijd goed om even stil te staan bij de vraag hoe gevoelig de informatie is die over de verbinding gaat, en welke risico's je loopt.
Sommige mensen lijken te verwachten dat je bij een nieuws website dezelfde beveiliging nodig hebt als bij DigiD of Internetbankieren ;)
Waar maakt je je druk om ?
Indien dit forum HTTP zou bieden i.p.v. HTTPS dan zou ik dat ook geen probleem vinden. Er is immers geen sprake van enige privacy gevoelige informatie (buiten de login als je een account gebruikt, die kan je achter HTTPS zetten).
Zelfs je login hier zou niet erg relevant moeten zijn - tenzij je *zelf* onveilig bezig bent, en je je credentials elders hergebruikt.
Alvorens je kritiek hebt op de vraag of een website HTTPS gebruikt (en welke versie SSL), is het altijd goed om even stil te staan bij de vraag hoe gevoelig de informatie is die over de verbinding gaat, en welke risico's je loopt.
Sommige mensen lijken te verwachten dat je bij een nieuws website dezelfde beveiliging nodig hebt als bij DigiD of Internetbankieren ;)
Door Anoniem 29-09-2014 13;50 uur: "Lijkt mij dat SSL3 support (windows XP met IE6....) niet echt meer nodig is voor de bezoekers van *deze* site ?"
Waar maakt je je druk om ?
Indien dit forum HTTP zou bieden i.p.v. HTTPS dan zou ik dat ook geen probleem vinden. Er is immers geen sprake van enige privacy gevoelige informatie (buiten de login als je een account gebruikt, die kan je achter HTTPS zetten).
Zelfs je login hier zou niet erg relevant moeten zijn - tenzij je *zelf* onveilig bezig bent, en je je credentials elders hergebruikt.
Alvorens je kritiek hebt op de vraag of een website HTTPS gebruikt (en welke versie SSL), is het altijd goed om even stil te staan bij de vraag hoe gevoelig de informatie is die over de verbinding gaat, en welke risico's je loopt.
Sommige mensen lijken te verwachten dat je bij een nieuws website dezelfde beveiliging nodig hebt als bij DigiD of Internetbankieren ;)
Waar maakt je je druk om ?
Indien dit forum HTTP zou bieden i.p.v. HTTPS dan zou ik dat ook geen probleem vinden. Er is immers geen sprake van enige privacy gevoelige informatie (buiten de login als je een account gebruikt, die kan je achter HTTPS zetten).
Zelfs je login hier zou niet erg relevant moeten zijn - tenzij je *zelf* onveilig bezig bent, en je je credentials elders hergebruikt.
Alvorens je kritiek hebt op de vraag of een website HTTPS gebruikt (en welke versie SSL), is het altijd goed om even stil te staan bij de vraag hoe gevoelig de informatie is die over de verbinding gaat, en welke risico's je loopt.
Sommige mensen lijken te verwachten dat je bij een nieuws website dezelfde beveiliging nodig hebt als bij DigiD of Internetbankieren ;)
De login lijkt me wel degelijk relevant aangezien hierbij ook het e-mail adres wordt ingevuld en het lijkt mij vervelen wanneer dit onderschept wordt en zeker als de site geen HTTPS gebruikt aangezien er dan geen encryptie-algoritme hoef te worden gekraakt om de eventuele onderschepte gegevens uit te lezen.
Het hergebruiken van een wachtwoord is natuurlijk niet erg handig, maar een e-mail adres lijkt mij een ander verhaal. (Het lijkt mij namelijk erg omslachtig namelijk om voor elk account ook een nieuw e-mail adres aan te maken).
Verder lijkt het mij altijd vervelend als je account gekaapt wordt, ook dat van een nieuws website.
Goeie reactie van je Kraai! Mensen die hier geen account hebben, denken daar meestal niet zo snel aan.
Maar hoe dan ook (als het al niet duidelijk was): persoonlijk lijkt het me prima dat security.nl nog altijd SSL3 ondersteunt.
Want immers het feit dat security.nl o.a. SSL3 ondersteunt, betekent niet dat men verplicht is om het ook te gebruiken:
bezoekers kunnen het SSL3-protocol gewoon uitzetten in hun browser, en dan wordt dit protocol met geen enkele website
meer gebruikt. (en dus ook niet met www.security.nl, ook al wordt SSL3 op deze website in principe getolereerd)
Verder is voor zover bekend SSL3 in de praktijk voor veel toepassingen (nog) altijd een acceptabele bescherming, ook al bestaan er inmiddels sterkere encryptieprotocollen die overigens óók allemaal door security.nl worden ondersteund.
Het staat een ieder vrij om van die sterkere protocollen gebruik te maken (als je systeem het aankan).
En als er meerdere encryptieprotocollen in browser en server worden ondersteund, dan zullen moderne browsers
in de negotiation-fase volgens mij automatisch het sterkste protocol kiezen die browser en server allebei actief ondersteunen (correct me if I'm wrong). En dan heb je er dus helemaal geen omkijken naar.
Kortom: het lijkt me vooralsnog onnodig dat security.nl het SSL3 protocol op zijn website verbiedt, en het is inderdaad niet iets om je heel erg druk over te maken. Maar voor sommigen misschien best interessant en leerzaam.
Mvg, cluc-cluc
Maar hoe dan ook (als het al niet duidelijk was): persoonlijk lijkt het me prima dat security.nl nog altijd SSL3 ondersteunt.
Want immers het feit dat security.nl o.a. SSL3 ondersteunt, betekent niet dat men verplicht is om het ook te gebruiken:
bezoekers kunnen het SSL3-protocol gewoon uitzetten in hun browser, en dan wordt dit protocol met geen enkele website
meer gebruikt. (en dus ook niet met www.security.nl, ook al wordt SSL3 op deze website in principe getolereerd)
Verder is voor zover bekend SSL3 in de praktijk voor veel toepassingen (nog) altijd een acceptabele bescherming, ook al bestaan er inmiddels sterkere encryptieprotocollen die overigens óók allemaal door security.nl worden ondersteund.
Het staat een ieder vrij om van die sterkere protocollen gebruik te maken (als je systeem het aankan).
En als er meerdere encryptieprotocollen in browser en server worden ondersteund, dan zullen moderne browsers
in de negotiation-fase volgens mij automatisch het sterkste protocol kiezen die browser en server allebei actief ondersteunen (correct me if I'm wrong). En dan heb je er dus helemaal geen omkijken naar.
Kortom: het lijkt me vooralsnog onnodig dat security.nl het SSL3 protocol op zijn website verbiedt, en het is inderdaad niet iets om je heel erg druk over te maken. Maar voor sommigen misschien best interessant en leerzaam.
Mvg, cluc-cluc
01-10-2014, 01:36 door
Eric-Jan H te D
Door Anoniem: Maar encryptieprotocollen worden niet gepatcht.
Nieuw protocol -> nieuwe programmatuur -> nieuwe bugs (bv Heartbleed)
Dat de bug dan pas na meer dan een jaar wordt gevonden, zou ook in mijn strategie roet in het eten gooien. ;-)
Door Eric-Jan H te A:
Nieuw protocol -> nieuwe programmatuur -> nieuwe bugs (bv Heartbleed)
Dat de bug dan pas na meer dan een jaar wordt gevonden, zou ook in mijn strategie roet in het eten gooien. ;-)
Kijk, dat gaat de goeie kant op! Ieder voordeel heeft zijn nadeel zullen we maar zeggen.Nieuw protocol -> nieuwe programmatuur -> nieuwe bugs (bv Heartbleed)
Dat de bug dan pas na meer dan een jaar wordt gevonden, zou ook in mijn strategie roet in het eten gooien. ;-)
Uiteindelijk is het maar net wat je het belangrijkste vindt, en waar de grootste risico's zitten.
Het eerste is heel persoonlijk. Het tweede vaak moeilijk in te schatten.
Niet accepteren van het laatste officiële encryptieprotocol (TLSv1.2) betekent overigens het niet accepteren van de volgende security upgrades ten opzichte van TLSv1.1:
* The MD5-SHA-1 combination in the pseudorandom function (PRF) was replaced with SHA-256, with an option to use cipher suite specified PRFs.
* The MD5-SHA-1 combination in the Finished message hash was replaced with SHA-256, with an option to use cipher suite specific hash algorithms. However the size of the hash in the finished message is still truncated to 96 bits.
* The MD5-SHA-1 combination in the digitally signed element was replaced with a single hash negotiated during handshake, which defaults to SHA-1.
* Enhancement in the client's and server's ability to specify which hash and signature algorithms they will accept.
* Expansion of support for authenticated encryption ciphers, used mainly for Galois/Counter Mode (GCM) and CCM mode of Advanced Encryption Standard encryption.
* TLS Extensions definition and Advanced Encryption Standard cipher suites were added.
Nu kun je meestal nog wel een tijdje vertrouwen op vorige encryptieprotocollen,
(vooral als je geen bijzonder grote geheimen communiceert). Maar optimaal veilig is dat imho niet.
Een nieuw encryptieprotocol is immers in wezen een soort security upgrade.
En wanneer alle major browsers inmiddels het nieuwste encryptieprotocol ondersteunen,
dan begint langzaam maar zeker het niet accepteren van dit laatste officiële encryptieprotocol toch wel
"zóóó je naaktfoto's op internet laten lekken" te worden...
(bovendien verschaf je jezelf extra werk om dat nieuwste protocol te disablen in je browser)
Een "slow motion emergency" om eens wat vaker TLSv1.2 te gaan gebruiken zullen we maar zeggen? ;-)
(net zoiets als de overstap van sha1 naar sha2)
Mvg, cluc-cluc
Door Anoniem, cluc-cluc 30-09-2014 15:48:
En als er meerdere encryptieprotocollen in browser en server worden ondersteund, dan zullen moderne browsers
in de negotiation-fase volgens mij automatisch het sterkste protocol kiezen die browser en server allebei actief ondersteunen (correct me if I'm wrong). En dan heb je er dus helemaal geen omkijken naar.
Kortom: het lijkt me vooralsnog onnodig dat security.nl het SSL3 protocol op zijn website verbiedt, en het is inderdaad niet iets om je heel erg druk over te maken. Maar voor sommigen misschien best interessant en leerzaam.
En als er meerdere encryptieprotocollen in browser en server worden ondersteund, dan zullen moderne browsers
in de negotiation-fase volgens mij automatisch het sterkste protocol kiezen die browser en server allebei actief ondersteunen (correct me if I'm wrong). En dan heb je er dus helemaal geen omkijken naar.
Kortom: het lijkt me vooralsnog onnodig dat security.nl het SSL3 protocol op zijn website verbiedt, en het is inderdaad niet iets om je heel erg druk over te maken. Maar voor sommigen misschien best interessant en leerzaam.
Ik weet niet zeker of automatisch het sterkste protocol wordt gekozen dat door de browser en de server allebei actief wordt ondersteund, maar het zou me onhandig lijken als dit niet automatisch gebeurd, als je het sterkste protocol wilt gebruiken dat door de browser en server actief ondersteund wordt.
Door _kraai__: De login lijkt me wel degelijk relevant aangezien hierbij ook het e-mail adres wordt ingevuld en het lijkt mij vervelen wanneer dit onderschept wordt en zeker als de site geen HTTPS gebruikt aangezien er dan geen encryptie-algoritme hoef te worden gekraakt om de eventuele onderschepte gegevens uit te lezen.
Het hergebruiken van een wachtwoord is natuurlijk niet erg handig, maar een e-mail adres lijkt mij een ander verhaal. (Het lijkt mij namelijk erg omslachtig namelijk om voor elk account ook een nieuw e-mail adres aan te maken).
Verder lijkt het mij altijd vervelend als je account gekaapt wordt, ook dat van een nieuws website.
In feite wil je dus zeggen dat een openbare website gebruikers (schijn)veiligheid moet opdringen?Het hergebruiken van een wachtwoord is natuurlijk niet erg handig, maar een e-mail adres lijkt mij een ander verhaal. (Het lijkt mij namelijk erg omslachtig namelijk om voor elk account ook een nieuw e-mail adres aan te maken).
Verder lijkt het mij altijd vervelend als je account gekaapt wordt, ook dat van een nieuws website.
Daarbij vergeet je dat waarschijnlijk veruit de meeste mensen alleen lezen, en nooit reageren.
En als er iemand is die baat zou kunnen hebben bij een bezoekje aan deze site, zijn het wel gebruikers met een verouderd systeem. En dan heb je nog van die randfiguren als ikzelf, die hun header spoofen of gewoon voor de fun XP in een VM draaien. Zijn die ook niet meer welkom? (Bedankt...)
Accounts kapen? Er zijn maar héél weinig gebruikers die hun identiteit prijsgeven hier, dus dat lijkt me ook totaal irrelevant, zowel voor de hakselaar als het slachtoffer. Kosten + risico's wegen no-way-never-nooit-niet op tegen de baten.
Zeg, er werd wat gezegd hierboven over hoe nieuwere encryptie ook meteen zwaarder is voor CPU enz. Dit is natuurlijk niet per definitie het geval. Modernere processors hebben o.a. AES-NI voor hardware cryptoacelleratie, en daarnaast zijn er mooie ontwikkelingen zichtbaar via algoritmes zoals ED25519, die net zoals ECDSA juist veel minder zwaar zijn dan bijv. RSA4096. Groetjes Vocis.
Door Anoniem 02-10-2014 00:39 uur:
In feite wil je dus zeggen dat een openbare website gebruikers (schijn)veiligheid moet opdringen?
In feite wil je dus zeggen dat een openbare website gebruikers (schijn)veiligheid moet opdringen?
Hoezo? In mijn reactie schrijf ik dat ik de login wel degelijk relevant vindt omdat hierbij onder andere het e-mail adres moet worden ingevuld, en het daarom nodig vindt dat deze website HTTPS gebruikt. dus ik begrijp je opmerking niet bepaald over schijn(veiligheid) opdringen. Overigens richt deze website zich op beveiliging en dan staat het toch naar mijn mening ook goed dat de mogelijkheid er is om via HTTPS te kunnen inloggen.
Door Anoniem 02-10-2014 00:39 uur:
Daarbij vergeet je dat waarschijnlijk veruit de meeste mensen alleen lezen, en nooit reageren.
Dat kan toch ook gewoon? Als je alleen deze website wilt lezen en hier na eigen believen wel of niet op te reageren kan toch gewoon? Naar mijn menig is iedereen hier vrij in. Maar dat betekent nog niet dat er niet aan gebruikers hoef te worden gedacht die hier een account hebben en hier graag via HTTPS op willen kunnen inloggen. Ik kan me overigens niet voorstellen dat iemand die deze website alleen leest, er last van zou hebben dat deze website via HTTPS wordt aangeboden.Daarbij vergeet je dat waarschijnlijk veruit de meeste mensen alleen lezen, en nooit reageren.
Door Anoniem 02-10-2014 00:39 uur:
En als er iemand is die baat zou kunnen hebben bij een bezoekje aan deze site, zijn het wel gebruikers met een verouderd systeem.
En als er iemand is die baat zou kunnen hebben bij een bezoekje aan deze site, zijn het wel gebruikers met een verouderd systeem.
Dat kan toch ook gewoon? ik zou niet weten waarom het fijt dat deze website via HTTPS wordt aangeboden hen hierbij zou hinderen.
Door Anoniem 02-10-2014 00:39 uur:
En dan heb je nog van die randfiguren als ikzelf, die hun header spoofen of gewoon voor de fun XP in een VM draaien. Zijn die ook niet meer welkom? (Bedankt...)
En dan heb je nog van die randfiguren als ikzelf, die hun header spoofen of gewoon voor de fun XP in een VM draaien. Zijn die ook niet meer welkom? (Bedankt...)
Ik heb nergens in dit topic gezegd dat iemand hier niet welkom is dus ik vraag me af waar je dat vandaan haalt.
Door Anoniem 02-10-2014 00:39 uur:
Accounts kapen? Er zijn maar héél weinig gebruikers die hun identiteit prijsgeven hier, dus dat lijkt me ook totaal irrelevant, zowel voor de hakselaar als het slachtoffer. Kosten + risico's wegen no-way-never-nooit-niet op tegen de baten.
Accounts kapen? Er zijn maar héél weinig gebruikers die hun identiteit prijsgeven hier, dus dat lijkt me ook totaal irrelevant, zowel voor de hakselaar als het slachtoffer. Kosten + risico's wegen no-way-never-nooit-niet op tegen de baten.
Zoals ik al eerder heb gezegd het e-mail adres wordt ingevuld. en zoals ik al eerder aangaf:
Door _kraai__ 02-10-2014 22:32 uur:
Het hergebruiken van een wachtwoord is natuurlijk niet erg handig, maar een e-mail adres lijkt mij een ander verhaal. (Het lijkt mij namelijk erg omslachtig namelijk om voor elk account ook een nieuw e-mail adres aan te maken).
Het hergebruiken van een wachtwoord is natuurlijk niet erg handig, maar een e-mail adres lijkt mij een ander verhaal. (Het lijkt mij namelijk erg omslachtig namelijk om voor elk account ook een nieuw e-mail adres aan te maken).
Door Anoniem 02-10-2014 12:07 uur: Zeg, er werd wat gezegd hierboven over hoe nieuwere encryptie ook meteen zwaarder is voor CPU enz. Dit is natuurlijk niet per definitie het geval. Modernere processors hebben o.a. AES-NI voor hardware cryptoacelleratie,
Maar dat is toch juist het probleem? dat niet iedereen een moderne processor heeft.
@_kraai_:
Ik dacht dat jij ook de TS was -> heb de verkeerde indruk gekregen.
Dat neemt niet weg dat ik een MitM extreem vergezocht acht.
Een email-adres is geen privacy-gevoelige informatie, ook zijn er verder geen persoonlijke gegevens aan de aanwezige accounts gekoppeld. Dus een aanvaller loopt alleen maar risico, zonder winst-potentieel.
Dat diezelfde aanvaller ook eerder tegen de lamp loopt dan bij een MitM tegen bijv. geen-stijl-leden, is ook niet geheel onwaarschijnlijk.
Plus, de enige 100%-oplossing zou het verwijderen van alle accounts zijn en het onmogelijk maken om op artikelen te kunnen reageren. Want alleen dan kan security.nl voorkomen dat gebruikers geen (domme) fouten maken...
Kortom: Je kunt security.nl niet verantwoordelijk houden voor het gebruiken van een (minder sterke, maar nog wel) wereldwijd geaccepteerde standaard.
Ik dacht dat jij ook de TS was -> heb de verkeerde indruk gekregen.
Dat neemt niet weg dat ik een MitM extreem vergezocht acht.
Een email-adres is geen privacy-gevoelige informatie, ook zijn er verder geen persoonlijke gegevens aan de aanwezige accounts gekoppeld. Dus een aanvaller loopt alleen maar risico, zonder winst-potentieel.
Dat diezelfde aanvaller ook eerder tegen de lamp loopt dan bij een MitM tegen bijv. geen-stijl-leden, is ook niet geheel onwaarschijnlijk.
Plus, de enige 100%-oplossing zou het verwijderen van alle accounts zijn en het onmogelijk maken om op artikelen te kunnen reageren. Want alleen dan kan security.nl voorkomen dat gebruikers geen (domme) fouten maken...
Kortom: Je kunt security.nl niet verantwoordelijk houden voor het gebruiken van een (minder sterke, maar nog wel) wereldwijd geaccepteerde standaard.
Ter info: een gedegen artikel over de stand van zaken m.b.t. TLS, ciphersuites, TLS-fallback en bugs op 27 feb. 2014
(en wat daaraan vooraf ging) vind je op https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html
Hieruit blijkt o.a.:
- "automatische TLS-fallback" schijnt wel de gewoonte te zijn, maar soms gebeurde het onbedoeld. (bug of attack)
(hoewel de aanvaller natuurlijk wél bedoelde om naar een lager (en kwetsbaarder) protocol over te schakelen...)
Er is trouwens ook een bijzonder geval bekend met IE10 waarbij de communicatie helemaal werd gestaakt. Zie:
http://blogs.technet.com/b/askpfeplat/archive/2014/07/07/troubleshooting-tls1-2-and-certificate-issue-with-microsoft-message-analyzer-a-real-world-example.aspx
- Bepaalde nieuwe processoren bezitten weliswaar dankzij nieuwe instructies extra rekenkracht om efficiënt één bepaald soort encrypties uit te voeren. Maar de meeste processoren van de huidige "internet installed base" (incl. smartphones) hebben deze (tamelijk eenzijdige) feature niet aan boord. Dit zal naar men verwacht voorlopig ook nog wel even voortduren.
Het klopte dus wel dat
Want het is in feite een oorzaak die implementatie van TLSv1.2 in een stroomversnelling heeft gebracht,
omdat encryptie die van het snelle AESNI gebruik maakt (AES-GCM) pas in TLSv1.2 wordt ondersteund.
Een meer universeel alternatief voor de symmetrische encryptie is een sterke (256 bits), maar toch nog redelijk snelle AEAD-cipher als ChaCha20-Poly1305 (die eveneens vanaf TLSv1.2 wordt ondersteund)
Maar of dit alternatief sneller is dan alle eerdere gebruikelijke (zwakkere) symmetrische encrypties, waag ik te betwijfelen.
Wel is ChaCha20-Poly1305 sneller dan AES128-GCM (en waarschijnlijk ook AES256-GCM) in geval hierbij geen AESNI wordt gebruikt. Voor meer info over deze ciphers zie: https://www.imperialviolet.org/2013/10/07/chacha20.html
Voor wat betreft ED25519 en ECDSA (en RSA): deze technieken behoren imho tot de familie van a-symmetrische encryptie, hetgeen maar een beperkt deel van je https communicatie is. Dit enigszins tijdrovende deel wordt volgens mij voornamelijk gebruikt in de onderhandelings/authenticatiefase van de verbinding.
Maar minstens zo belangrijk is de encryptie van de eigenlijke data (bestanden etc.) die over de lijn gaat.
En dit gebeurt naar mijn weten met een zgn. "block cipher", en is een ander soort encryptie. ("symmetrische encryptie")
Laten we bij deze discussie dus wel opletten dat we geen appels met peren vergelijken. ;-)
Mvg, cluc-cluc
(en wat daaraan vooraf ging) vind je op https://www.imperialviolet.org/2014/02/27/tlssymmetriccrypto.html
Hieruit blijkt o.a.:
- "automatische TLS-fallback" schijnt wel de gewoonte te zijn, maar soms gebeurde het onbedoeld. (bug of attack)
(hoewel de aanvaller natuurlijk wél bedoelde om naar een lager (en kwetsbaarder) protocol over te schakelen...)
Er is trouwens ook een bijzonder geval bekend met IE10 waarbij de communicatie helemaal werd gestaakt. Zie:
http://blogs.technet.com/b/askpfeplat/archive/2014/07/07/troubleshooting-tls1-2-and-certificate-issue-with-microsoft-message-analyzer-a-real-world-example.aspx
- Bepaalde nieuwe processoren bezitten weliswaar dankzij nieuwe instructies extra rekenkracht om efficiënt één bepaald soort encrypties uit te voeren. Maar de meeste processoren van de huidige "internet installed base" (incl. smartphones) hebben deze (tamelijk eenzijdige) feature niet aan boord. Dit zal naar men verwacht voorlopig ook nog wel even voortduren.
Het klopte dus wel dat
"...betere encryptietechnieken meestal(!) ook meer processortijd kosten.
Maar wel goed dat je dit onderwerp nog even onder de aandacht bracht. (waarvoor mijn dank, Vocis).Want het is in feite een oorzaak die implementatie van TLSv1.2 in een stroomversnelling heeft gebracht,
omdat encryptie die van het snelle AESNI gebruik maakt (AES-GCM) pas in TLSv1.2 wordt ondersteund.
Een meer universeel alternatief voor de symmetrische encryptie is een sterke (256 bits), maar toch nog redelijk snelle AEAD-cipher als ChaCha20-Poly1305 (die eveneens vanaf TLSv1.2 wordt ondersteund)
Maar of dit alternatief sneller is dan alle eerdere gebruikelijke (zwakkere) symmetrische encrypties, waag ik te betwijfelen.
Wel is ChaCha20-Poly1305 sneller dan AES128-GCM (en waarschijnlijk ook AES256-GCM) in geval hierbij geen AESNI wordt gebruikt. Voor meer info over deze ciphers zie: https://www.imperialviolet.org/2013/10/07/chacha20.html
Voor wat betreft ED25519 en ECDSA (en RSA): deze technieken behoren imho tot de familie van a-symmetrische encryptie, hetgeen maar een beperkt deel van je https communicatie is. Dit enigszins tijdrovende deel wordt volgens mij voornamelijk gebruikt in de onderhandelings/authenticatiefase van de verbinding.
Maar minstens zo belangrijk is de encryptie van de eigenlijke data (bestanden etc.) die over de lijn gaat.
En dit gebeurt naar mijn weten met een zgn. "block cipher", en is een ander soort encryptie. ("symmetrische encryptie")
Laten we bij deze discussie dus wel opletten dat we geen appels met peren vergelijken. ;-)
Mvg, cluc-cluc
Door Anoniem 03-10-2014 09:56 uur: @_kraai_:
Ik dacht dat jij ook de TS was -> heb de verkeerde indruk gekregen.
Ik dacht dat jij ook de TS was -> heb de verkeerde indruk gekregen.
Is niet erg. Foutje kan gebeuren
Door Anoniem 03-10-2014 09:56 uur:
Dat neemt niet weg dat ik een MitM extreem vergezocht acht.
Een email-adres is geen privacy-gevoelige informatie, ook zijn er verder geen persoonlijke gegevens aan de aanwezige accounts gekoppeld. Dus een aanvaller loopt alleen maar risico, zonder winst-potentieel.
Dat diezelfde aanvaller ook eerder tegen de lamp loopt dan bij een MitM tegen bijv. geen-stijl-leden, is ook niet geheel onwaarschijnlijk.
Dat neemt niet weg dat ik een MitM extreem vergezocht acht.
Een email-adres is geen privacy-gevoelige informatie, ook zijn er verder geen persoonlijke gegevens aan de aanwezige accounts gekoppeld. Dus een aanvaller loopt alleen maar risico, zonder winst-potentieel.
Dat diezelfde aanvaller ook eerder tegen de lamp loopt dan bij een MitM tegen bijv. geen-stijl-leden, is ook niet geheel onwaarschijnlijk.
Is misschien inderdaad een beetje overdreven. Het gene wat ik vooral duidelijk wil maken is dat ik het toch belangrijk vind dat inloggen op security.nl via https kan. En het kan dat onze meningen daar over verschillen. Als iedereen het hier altijd maar met elkaar eens is/ de zelfde mening zou hebben, zou het denk ik hier ook maar een saaie boel worden ;-)
Door Anoniem 03-10-2014 09:56 uur:
Plus, de enige 100%-oplossing zou het verwijderen van alle accounts zijn en het onmogelijk maken om op artikelen te kunnen reageren. Want alleen dan kan security.nl voorkomen dat gebruikers geen (domme) fouten maken...
Plus, de enige 100%-oplossing zou het verwijderen van alle accounts zijn en het onmogelijk maken om op artikelen te kunnen reageren. Want alleen dan kan security.nl voorkomen dat gebruikers geen (domme) fouten maken...
Dat zou ik alleen toch wel erg jammer vinden aangezien hier naar mijn mening toch vaak ook nuttige/ interessante informatie wordt uitgewisseld. En die mogelijkheid vindt ik toch ook wel belangrijk.
Door Anoniem 03-10-2014 09:56 uur:
Kortom: Je kunt security.nl niet verantwoordelijk houden voor het gebruiken van een (minder sterke, maar nog wel) wereldwijd geaccepteerde standaard.
Kortom: Je kunt security.nl niet verantwoordelijk houden voor het gebruiken van een (minder sterke, maar nog wel) wereldwijd geaccepteerde standaard.
Daarover ben ik het met je eens (en dat mag vind ik, ook wel gezegd worden :-)
https://www.security.nl/posting/405340/Ernstig+beveiligingslek+in+SSL+3_0+ontdekt
Ehm... oke...
Gaat security.nl nu wel binnenkort sslv3-ondersteuning verwijderen? ;-)
Ehm... oke...
Gaat security.nl nu wel binnenkort sslv3-ondersteuning verwijderen? ;-)
https://www.security.nl/posting/405340/Ernstig+beveiligingslek+in+SSL+3_0+ontdekt
Ehm... oke... Gaat security.nl nu wel sslv3-ondersteuning verwijderen?
Ho wacht! Ik zie dat het al gebeurd is! :-))Ehm... oke... Gaat security.nl nu wel sslv3-ondersteuning verwijderen?
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.
