Security Professionals
- ipfw add deny all from eindgebruikers to any
https lekjes: DigiD, KPN, ABP, SNS, Triodos, ASN
Tijdens het opzetten van een https verbinding kan een server een voorkeurvolgorde van "cipher suites" aan de browser kenbaar maken, bijvoorbeeld (3 stuks): SSL_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_3DES_EDE_CBC_SHA en TLS_RSA_WITH_AES_128_CBC_SHA.
Een belangrijk onderdeel van zo'n cipher suite is het encryptiealgoritme dat uiteindelijk voor het versleutelen van de verbinding wordt gebruikt (voorbeelden: RC4, AES, 3DES). Als de serverbeheerder een voorkeurvolgorde heeft geconfigureerd, kiest de server de eerste cipher suite uit die lijst die ook door die browser wordt ondersteund, en die wordt vervolgens gebruikt.
Waarom weet ik niet (mogelijk server performance, en dus kosten): veel https server eigenaren zetten zwakke of zelfs gekraakte cipher suites vooraan in die lijst! Omdat er veel verouderde servers op internet zijn, ondersteunen de meeste webbrowsers ook nog die verouderde en onveilige cipher suites (om vergelijkbare reden was Poodle een probleem - het SSLv3 protocol had al jaren dood moeten zijn). Gevolg: ook als zowel de server, als de browser, veel veiliger verbindingen ondersteunen, maar de server een zwakke cipher suite als voorkeur opgeeft, zal die worden gebruik!
Server eigenaren die zwakke/gekraakte cipher suites als voorkeur aanprijzen, brengen daarmee alle doorsnee gebruikers, die redelijk actuele software inzetten (nog ondersteund door de producent) maar niet zelf instellingen tweaken, onnodig in gevaar. En voor henzelf is het nog eens onverstandig ook, want op die manier krijgen zij geen betrouwbaar beeld van hoeveel clients met uitsluitend support voor oudere/zwakke cipher suites hun site bezoeken.
Nb. ik was eigenlijk nog niet zover om dit artikel te publiceren (ik was er wel mee bezig, zie 2e comment onder https://isc.sans.edu/forums/diary/Apple+Updates+not+just+Yosemite/18851). Echter, Anoniem in https://www.security.nl/posting/406070/Veilig+internetbankieren%3A+huidige+status+bankservers heeft eerder gisteren iets vergelijkbaars gepubliceerd, waarvoor alle respect. Hij of zij vergelijkt meer sites op meer aspecten, maar lijkt daarbij de essentie te missen wat mij betreft, namelijk de volgende issue.
Probleem
Terwijl RC4 cryptografisch gekraakt is (1,5 jaar geleden) krijg je een cipher suite met RC4 als voorkeur van de volgende sites, met als gevolg bij de meeste webbrowsers een RC4-encrypted verbinding (dit was de situatie op 2014-10-22 toen ik dit artikel plaatste):
(1) https://digid.nl/inloggen
(2) https://www.kpn.com/prive/mijnkpn.htm
(3) https://mijn.abp.nl/
(4) https://www.snsbank.nl/particulier/home.html
(5) https://bankieren.triodos.nl/ib-seam/login.seam?lcid=337182
(6) https://www.asnbank.nl/particulier/home.html
Hoe erg lek is RC4?
Zeker is dat een aanvaller, die een zeer landurige aanval kan uitvoeren, versleutelde gegevens kan ontcijferen. De ontdekkers van het lek (maart 2013) hebben ervoor gewaarschuwd dat hun aanval vermoedelijk valt te verbeteren. Er zijn geruchten dat de NSA live RC4 kan kraken. Nu is de kans dat de NSA misbruik maakt van jouw DigiD of jouw bankrekening plundert niet zo groot, maar we weten allemaal dat de NSA niet al haar geheimen geheim weet te houden. Wie weet welke informatie cybercriminelen in hun bezit hebben. Een IETF "internet draft" om RC4 te verbieden staat op de nominatie om te worden aangenomen. Zie "Recente geschiedenis van RC4" verderop voor meer details.
Hoe zie je of de verbinding tussen jouw browser en DigiD/bank/pensioenboer RC4 gebruikt?
Firefox: open zo'n link, rechtsklik in de pagina op wit en kies "View page info". Onderaan zie je, achter "Connection Encrypted", een abracadabra reeks (nl. de gebruikte cipher suite). Als daar _RC4_ in voorkomt is dat het type versleuteling dat op dat moment wordt gebruikt.
MSIE t/m Windows 7 (als ik me niet vergis ondersteunt Windows 8.1 en hoger geen RC4 meer): open zo'n link, rechtsklik in de pagina op wit en kies Properties (Eigenschappen). Als "RC4 voorkomt achter "Connection" wordt dat als encryptiealgoritme gebruikt.
Ook kun je een domainname (zoals digid.nl) laten checken door SSLLabs. Omdat digid.nl op een ander IP-adres draait dan www.digid.nl moet je op een gegeven moment een IP-adres kiezen. De directe link voor www.digid.nl ziet er als volgt uit: https://www.ssllabs.com/ssltest/analyze.html?d=digid.nl&s=144.43.254.212&hideResults=on&ignoreMismatch=on (bij het scannen van https://www.ssllabs.com/ssltest/analyze.html?d=digid.nl&s=144.43.254.202 geeft de ssllabs site momenteel een foutmelding).
Serverbeheerders: kies ALSJEBLIEFT voor een andere voorkeur suite dan een met RC4!
Bied in elk geval AES aan, en als je oudere clients wilt ondersteunen, geef dan de voorkeur aan 3DES boven RC4. Blokkeer SSLv3 helemaal, of als dat niet mogelijk is, blokkeer dan in elk geval alle CBC cipher suites onder SSLv3 (anders ben je lek voor Poodle). Ondersteun zomogelijk ook Forward Secrecy cipher suites - en geef daar de voorkeur aan!
Nb. AES-128 wordt door cryptografen nog steeds als zeer veilig beschouwd. Bijv. CloudFlare heeft, denk ik, een prima compromis aan ciphersuites: zie https://github.com/cloudflare/sslconfig. AES-256 kost meer performance, ook op portable devices natuurlijk. Als je echt op safe wilt gaan, kun je daar toch de voorkeur aan geven, zoals Ivan Ristic hier beschrijft: http://sourceforge.net/p/ssllabs/mailman/message/32446486/.
Gegeven het feit dat sites als https://mijn.ing.nl/ veiliger ciphers ondersteunen (helaas nog geen forward secrecy), begrijp ik niet waarom sites als DigiD nog RC4 zou moeten aanbieden - laat staan als voorkeur.
RC4 disablen is het veiligst, maar daarmee blokkeer je mogelijk wel een aantal (verouderde) clients. Een ander argument voor RC4 boven 3DES is dat het minder CPU perfomance kost (belangrijk als je weinig geld wilt uitgeven voor je server(s) of load balancer, maar ook van belang in portable devices vanwege snelheid en energiegebruik). Maar... als het om vertrouwelijke gegevens gaat zoals inloggen op DigiD of internetbankieren, dan vind ik dat RC4 nu, of evt. zeer binnenkort, niet meer ondersteund zou moeten worden.
Als (na testen) de "SSL 3.0 Fallback protection" patch (TLS_FALLBACK_SCSV) betrouwbaar blijkt, installeer die dan. Daarmee worden klanten die wel actuele browsers gebruiken -maar SSLv3 nog niet hebben uitgeschakeld- beter beschermd tegen protocol downgrade attack (ook van TLS v1.2 naar een lagere TLS versie).
Server config tips: https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations.
De vertaling van standaard namen van cipher suites naar OpenSSL identifiers vind je in https://www.openssl.org/docs/apps/ciphers.html#CIPHER_SUITE_NAMES.
Check je server via https://www.ssllabs.com/ssltest/!
Als je echt oude clients wilt of moet blijven ondersteunen, is het een veilige optie om een landing site met matige beveiliging te maken (je huidige site), en van daaruit, "clickable":
- Een andere site (of een reverse proxy) speciaal voor clients die wel up-to-dat zijn, d.w.z. een site die uitsluitend veilige protocollen aanbiedt en aanvullende beveiligingsmaatregelen als HSTS ondersteunt. URL voorbeeld: https://secure.kpn.com/. Op basis van browser headers zou je gebruikers automatisch naar die veiliger site kunnen redirecten;
- Een site geschikt voor oudere clients (dat kunnen pagina's op dezelfde site zijn als de landing site).
@DigiD: de HSTS tijdspanne is nu 365 dagen, verhoog dat svp. Ik bezoek jullie 1x per jaar om mijn belasting in te dienen en daar zou best een keer 370 dagen tussen kunnen zitten...
Special case: ABP
Met de Firefox instelling (in about:config) "security.ssl3.rsa_rc4_128_md5 = false" kon ik https://mijn.abp.nl/ niet eens openen. Wat blijkt, ABP ondersteunt slechts één cipher suite:
In https://www.security.nl/posting/405457#posting405835 beschrijft cluc-cluc hoe je RC4 support in je webbrowser kunt uitzetten (maar dan kun je bovenstaande ABP site niet meer bezoeken).
Recente geschiedenis van RC4
Na publicatie op 23 september 2011 van het BEAST lek in in clients (o.a. webbrowsers, zie https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack), werd serverbeheerders aangeraden om RC4 als voorkeur op te nemen. Dat was echt een noodgreep, maar het alternatief op dat moment, gekraakte verbindinden door dat webbrowsers niet goed met CBC-ciphers omgingen, was nog erger.
Nadat Apple, als laatste grote partij, dat client-lek na ruim 1 jaar eindelijk ook gepatcht had (https://community.qualys.com/blogs/securitylabs/2013/10/31/apple-enabled-beast-mitigations-in-os-x-109-mavericks), volgde snel daarna het advies om RC4 op servers te disablen. En, indien het blokkeren van RC4 teveel bezoekers zou kosten, om dan in elk geval RC4 niet als voorkeur aan te bieden. Reden: al sinds 1995 zijn er in toenemende mate zorgen over de veiligheid van RC4 (zie http://en.wikipedia.org/wiki/RC4#Roos.27_biases_and_key_reconstruction_from_permutation).
2013-03-13 Er wordt een concrete aanval op RC4 werd gepubliceerd: zie http://www.isg.rhul.ac.uk/tls/. Later zijn o.a. een video en slides gepubliceerd op https://www.usenix.org/conference/usenixsecurity13/security-rc4-tls. Wel een opmerking hierbij: het gepubliceerde RC4 lek is lastig te misbruiken, maar niet onmogelijk. Een aanval zorgt voor vertraging, vooral bij langzame netwerkverbindingen. Bij interactieve sessies zal dit waarschijnlijk opvallen, bij machine-to-machine sessies mogelijk niet. Netwerkverbindingen worden echter steeds sneller, waardoor het gevaar voor onopgemerkte aanvallen op interactieve sessies toeneemt.
2013-03-19 Ivan Ristic geeft zijn advies n.a.v. bovenstaande publicatie, zie https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what.
Op 2013-04-01 waarschuwde het NCSC voor het gebruik van RC4, zie https://www.security.nl/posting/40577/NCSC+waarschuwt+voor+RC4+encryptiealgoritme.
Op 2013-08-21 heeft Microsoft een RFC draft ingediend om RC4 te verbannen (zie https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-00, klik bovenaan op 02 voor de laatste versie).
Op 2013-11-06 schreef Jacob Appelbaum (https://twitter.com/ioerror/status/398059565947699200):
Op 2013-11-12 heeft Heise bekend gemaakt (http://www.heise.de/security/meldung/Web-Seiten-von-Bund-und-BSI-mit-gefaehrlicher-Verschluesselung-2043681.html) dat de websites van de Duitse federale overheidssite (bund.de) en het Bundesamt für Sicherheit in der Informationstechnik (bsi.bund.de), uitsluitend RC4 ondersteunden. Na een kleine rel zijn beide sites beter beveiligd zodanig dat RC4 uitsluitend wordt gebruikt door clients die niets beters ondersteunen (zie updates onderaan http://www.heise.de/security/meldung/Webseiten-Verschluesselung-Viel-Nachbesserung-notwendig-2044161.html) .
Op diezelfde dag (2013-11-12) blogde Microsoft:
Vorige week schreef Ivan Ristic het volgende over RC4 in https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack (onderstrepen door mij):
P.S. volgens ssllabs biedt www.digid.nl momenteel de volgende cipher suites aan, met de eerste/bovenste als voorkeur:
Edits 2014-10-22 10:16: links naar vinders van het lek (maart 2013 en latere Usenix presentatie) toegevoegd en enkele typfoutjes gefixt; forward security moet zijn forward secrecy
Edits 2014-11-02 14:00: zie sectie "Status 2014-11-02 14:00" met de actuele status van betreffende sites.
Edit 2014-11-04 23:55: De 2e alinea, 2e zin was: "Als de server een voorkeurvolgorde heeft aangegeven, kiest de browser de eerste cipher suite uit die lijst die door die browser wordt ondersteund, en die wordt vervolgens gebruikt": ik heb nu verduidelijkt dat de [i[beheerder[/i] wel of niet een voorkeurvolgorde opgeeft, en uiteindelijk is het de server die een cipher suite kiest (linksom of rechtsom is de instelling van de server bepalend, dit heeft dus geen effect voor mijn verdere betoog). Sorry voor de mogelijke onduidelijkheid!
Een belangrijk onderdeel van zo'n cipher suite is het encryptiealgoritme dat uiteindelijk voor het versleutelen van de verbinding wordt gebruikt (voorbeelden: RC4, AES, 3DES). Als de serverbeheerder een voorkeurvolgorde heeft geconfigureerd, kiest de server de eerste cipher suite uit die lijst die ook door die browser wordt ondersteund, en die wordt vervolgens gebruikt.
Waarom weet ik niet (mogelijk server performance, en dus kosten): veel https server eigenaren zetten zwakke of zelfs gekraakte cipher suites vooraan in die lijst! Omdat er veel verouderde servers op internet zijn, ondersteunen de meeste webbrowsers ook nog die verouderde en onveilige cipher suites (om vergelijkbare reden was Poodle een probleem - het SSLv3 protocol had al jaren dood moeten zijn). Gevolg: ook als zowel de server, als de browser, veel veiliger verbindingen ondersteunen, maar de server een zwakke cipher suite als voorkeur opgeeft, zal die worden gebruik!
Server eigenaren die zwakke/gekraakte cipher suites als voorkeur aanprijzen, brengen daarmee alle doorsnee gebruikers, die redelijk actuele software inzetten (nog ondersteund door de producent) maar niet zelf instellingen tweaken, onnodig in gevaar. En voor henzelf is het nog eens onverstandig ook, want op die manier krijgen zij geen betrouwbaar beeld van hoeveel clients met uitsluitend support voor oudere/zwakke cipher suites hun site bezoeken.
Nb. ik was eigenlijk nog niet zover om dit artikel te publiceren (ik was er wel mee bezig, zie 2e comment onder https://isc.sans.edu/forums/diary/Apple+Updates+not+just+Yosemite/18851). Echter, Anoniem in https://www.security.nl/posting/406070/Veilig+internetbankieren%3A+huidige+status+bankservers heeft eerder gisteren iets vergelijkbaars gepubliceerd, waarvoor alle respect. Hij of zij vergelijkt meer sites op meer aspecten, maar lijkt daarbij de essentie te missen wat mij betreft, namelijk de volgende issue.
Probleem
Terwijl RC4 cryptografisch gekraakt is (1,5 jaar geleden) krijg je een cipher suite met RC4 als voorkeur van de volgende sites, met als gevolg bij de meeste webbrowsers een RC4-encrypted verbinding (dit was de situatie op 2014-10-22 toen ik dit artikel plaatste):
(1) https://digid.nl/inloggen
(2) https://www.kpn.com/prive/mijnkpn.htm
(3) https://mijn.abp.nl/
(4) https://www.snsbank.nl/particulier/home.html
(5) https://bankieren.triodos.nl/ib-seam/login.seam?lcid=337182
(6) https://www.asnbank.nl/particulier/home.html
Status 2014-11-02 14:00
(1) https://digid.nl/: ongewijzigd (onveilig): voorkeur: RC4
(2) https://www.kpn.com/: verbeterd: geen RC4 meer, 3 stuks TLS v1.0 ciphers, score: B
(3) https://mijn.abp.nl/: onveilig, wel gewijzigd: nu ook support voor 3DES en AES; voorkeur: RC4
(4) https://www.snsbank.nl/: onveilig; slechts RC4 en 3DES ondersteund, voorkeur: RC4
(5) https://bankieren.triodos.nl/: was veilig, weer onveilig: voorkeur: RC4
(6) https://www.asnbank.nl/: onveilig, nagenoeg identiek aan www.snsbank.nl; voorkeur: RC4
IP adres www.snsbank.nl = 194.53.208.72
IP adres www.asnbank.nl = 194.53.208.80
(1) https://digid.nl/: ongewijzigd (onveilig): voorkeur: RC4
(2) https://www.kpn.com/: verbeterd: geen RC4 meer, 3 stuks TLS v1.0 ciphers, score: B
(3) https://mijn.abp.nl/: onveilig, wel gewijzigd: nu ook support voor 3DES en AES; voorkeur: RC4
(4) https://www.snsbank.nl/: onveilig; slechts RC4 en 3DES ondersteund, voorkeur: RC4
(5) https://bankieren.triodos.nl/: was veilig, weer onveilig: voorkeur: RC4
(6) https://www.asnbank.nl/: onveilig, nagenoeg identiek aan www.snsbank.nl; voorkeur: RC4
IP adres www.snsbank.nl = 194.53.208.72
IP adres www.asnbank.nl = 194.53.208.80
Hoe erg lek is RC4?
Zeker is dat een aanvaller, die een zeer landurige aanval kan uitvoeren, versleutelde gegevens kan ontcijferen. De ontdekkers van het lek (maart 2013) hebben ervoor gewaarschuwd dat hun aanval vermoedelijk valt te verbeteren. Er zijn geruchten dat de NSA live RC4 kan kraken. Nu is de kans dat de NSA misbruik maakt van jouw DigiD of jouw bankrekening plundert niet zo groot, maar we weten allemaal dat de NSA niet al haar geheimen geheim weet te houden. Wie weet welke informatie cybercriminelen in hun bezit hebben. Een IETF "internet draft" om RC4 te verbieden staat op de nominatie om te worden aangenomen. Zie "Recente geschiedenis van RC4" verderop voor meer details.
Hoe zie je of de verbinding tussen jouw browser en DigiD/bank/pensioenboer RC4 gebruikt?
Firefox: open zo'n link, rechtsklik in de pagina op wit en kies "View page info". Onderaan zie je, achter "Connection Encrypted", een abracadabra reeks (nl. de gebruikte cipher suite). Als daar _RC4_ in voorkomt is dat het type versleuteling dat op dat moment wordt gebruikt.
MSIE t/m Windows 7 (als ik me niet vergis ondersteunt Windows 8.1 en hoger geen RC4 meer): open zo'n link, rechtsklik in de pagina op wit en kies Properties (Eigenschappen). Als "RC4 voorkomt achter "Connection" wordt dat als encryptiealgoritme gebruikt.
Ook kun je een domainname (zoals digid.nl) laten checken door SSLLabs. Omdat digid.nl op een ander IP-adres draait dan www.digid.nl moet je op een gegeven moment een IP-adres kiezen. De directe link voor www.digid.nl ziet er als volgt uit: https://www.ssllabs.com/ssltest/analyze.html?d=digid.nl&s=144.43.254.212&hideResults=on&ignoreMismatch=on (bij het scannen van https://www.ssllabs.com/ssltest/analyze.html?d=digid.nl&s=144.43.254.202 geeft de ssllabs site momenteel een foutmelding).
Serverbeheerders: kies ALSJEBLIEFT voor een andere voorkeur suite dan een met RC4!
Bied in elk geval AES aan, en als je oudere clients wilt ondersteunen, geef dan de voorkeur aan 3DES boven RC4. Blokkeer SSLv3 helemaal, of als dat niet mogelijk is, blokkeer dan in elk geval alle CBC cipher suites onder SSLv3 (anders ben je lek voor Poodle). Ondersteun zomogelijk ook Forward Secrecy cipher suites - en geef daar de voorkeur aan!
Nb. AES-128 wordt door cryptografen nog steeds als zeer veilig beschouwd. Bijv. CloudFlare heeft, denk ik, een prima compromis aan ciphersuites: zie https://github.com/cloudflare/sslconfig. AES-256 kost meer performance, ook op portable devices natuurlijk. Als je echt op safe wilt gaan, kun je daar toch de voorkeur aan geven, zoals Ivan Ristic hier beschrijft: http://sourceforge.net/p/ssllabs/mailman/message/32446486/.
Gegeven het feit dat sites als https://mijn.ing.nl/ veiliger ciphers ondersteunen (helaas nog geen forward secrecy), begrijp ik niet waarom sites als DigiD nog RC4 zou moeten aanbieden - laat staan als voorkeur.
RC4 disablen is het veiligst, maar daarmee blokkeer je mogelijk wel een aantal (verouderde) clients. Een ander argument voor RC4 boven 3DES is dat het minder CPU perfomance kost (belangrijk als je weinig geld wilt uitgeven voor je server(s) of load balancer, maar ook van belang in portable devices vanwege snelheid en energiegebruik). Maar... als het om vertrouwelijke gegevens gaat zoals inloggen op DigiD of internetbankieren, dan vind ik dat RC4 nu, of evt. zeer binnenkort, niet meer ondersteund zou moeten worden.
Als (na testen) de "SSL 3.0 Fallback protection" patch (TLS_FALLBACK_SCSV) betrouwbaar blijkt, installeer die dan. Daarmee worden klanten die wel actuele browsers gebruiken -maar SSLv3 nog niet hebben uitgeschakeld- beter beschermd tegen protocol downgrade attack (ook van TLS v1.2 naar een lagere TLS versie).
Server config tips: https://wiki.mozilla.org/Security/Server_Side_TLS#Recommended_Server_Configurations.
De vertaling van standaard namen van cipher suites naar OpenSSL identifiers vind je in https://www.openssl.org/docs/apps/ciphers.html#CIPHER_SUITE_NAMES.
Check je server via https://www.ssllabs.com/ssltest/!
Als je echt oude clients wilt of moet blijven ondersteunen, is het een veilige optie om een landing site met matige beveiliging te maken (je huidige site), en van daaruit, "clickable":
- Een andere site (of een reverse proxy) speciaal voor clients die wel up-to-dat zijn, d.w.z. een site die uitsluitend veilige protocollen aanbiedt en aanvullende beveiligingsmaatregelen als HSTS ondersteunt. URL voorbeeld: https://secure.kpn.com/. Op basis van browser headers zou je gebruikers automatisch naar die veiliger site kunnen redirecten;
- Een site geschikt voor oudere clients (dat kunnen pagina's op dezelfde site zijn als de landing site).
@DigiD: de HSTS tijdspanne is nu 365 dagen, verhoog dat svp. Ik bezoek jullie 1x per jaar om mijn belasting in te dienen en daar zou best een keer 370 dagen tussen kunnen zitten...
Special case: ABP
Met de Firefox instelling (in about:config) "security.ssl3.rsa_rc4_128_md5 = false" kon ik https://mijn.abp.nl/ niet eens openen. Wat blijkt, ABP ondersteunt slechts één cipher suite:
TLS_RSA_WITH_RC4_128_MD5
In https://www.security.nl/posting/405457#posting405835 beschrijft cluc-cluc hoe je RC4 support in je webbrowser kunt uitzetten (maar dan kun je bovenstaande ABP site niet meer bezoeken).
Recente geschiedenis van RC4
Na publicatie op 23 september 2011 van het BEAST lek in in clients (o.a. webbrowsers, zie https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack), werd serverbeheerders aangeraden om RC4 als voorkeur op te nemen. Dat was echt een noodgreep, maar het alternatief op dat moment, gekraakte verbindinden door dat webbrowsers niet goed met CBC-ciphers omgingen, was nog erger.
Nadat Apple, als laatste grote partij, dat client-lek na ruim 1 jaar eindelijk ook gepatcht had (https://community.qualys.com/blogs/securitylabs/2013/10/31/apple-enabled-beast-mitigations-in-os-x-109-mavericks), volgde snel daarna het advies om RC4 op servers te disablen. En, indien het blokkeren van RC4 teveel bezoekers zou kosten, om dan in elk geval RC4 niet als voorkeur aan te bieden. Reden: al sinds 1995 zijn er in toenemende mate zorgen over de veiligheid van RC4 (zie http://en.wikipedia.org/wiki/RC4#Roos.27_biases_and_key_reconstruction_from_permutation).
2013-03-13 Er wordt een concrete aanval op RC4 werd gepubliceerd: zie http://www.isg.rhul.ac.uk/tls/. Later zijn o.a. een video en slides gepubliceerd op https://www.usenix.org/conference/usenixsecurity13/security-rc4-tls. Wel een opmerking hierbij: het gepubliceerde RC4 lek is lastig te misbruiken, maar niet onmogelijk. Een aanval zorgt voor vertraging, vooral bij langzame netwerkverbindingen. Bij interactieve sessies zal dit waarschijnlijk opvallen, bij machine-to-machine sessies mogelijk niet. Netwerkverbindingen worden echter steeds sneller, waardoor het gevaar voor onopgemerkte aanvallen op interactieve sessies toeneemt.
2013-03-19 Ivan Ristic geeft zijn advies n.a.v. bovenstaande publicatie, zie https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what.
Op 2013-04-01 waarschuwde het NCSC voor het gebruik van RC4, zie https://www.security.nl/posting/40577/NCSC+waarschuwt+voor+RC4+encryptiealgoritme.
Op 2013-08-21 heeft Microsoft een RFC draft ingediend om RC4 te verbannen (zie https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-00, klik bovenaan op 02 voor de laatste versie).
Op 2013-11-06 schreef Jacob Appelbaum (https://twitter.com/ioerror/status/398059565947699200):
RC4 is broken in real time by the NSA - stop using it.
Je kunt je sschouders ophalen over de NSA, maar vast staat dat de NSA niet alle geheimen binnenskamers weet te houden; cybercriminelen zouden zich dergelijke technieken ook eigen kunnen maken.Op 2013-11-12 heeft Heise bekend gemaakt (http://www.heise.de/security/meldung/Web-Seiten-von-Bund-und-BSI-mit-gefaehrlicher-Verschluesselung-2043681.html) dat de websites van de Duitse federale overheidssite (bund.de) en het Bundesamt für Sicherheit in der Informationstechnik (bsi.bund.de), uitsluitend RC4 ondersteunden. Na een kleine rel zijn beide sites beter beveiligd zodanig dat RC4 uitsluitend wordt gebruikt door clients die niets beters ondersteunen (zie updates onderaan http://www.heise.de/security/meldung/Webseiten-Verschluesselung-Viel-Nachbesserung-notwendig-2044161.html) .
Op diezelfde dag (2013-11-12) blogde Microsoft:
IE11 Reduces Use of Vulnerable RC4 Cipher Suite
maar dat klopt niet in Windows 7. Want als ik met MSIE11 op dat OS naar https://digid.nl/inloggen ga, krijg ik gewoon een RC4-versleutelde verbinding. In die blog noemen ze overigens dat, volgens hun metingen, op dat moment nog 3.9% van alle servers uitsluitend RC4 ondersteunde. Zie http://blogs.msdn.com/b/ie/archive/2013/11/12/ie11-automatically-makes-over-40-of-the-web-more-secure-while-making-sure-sites-continue-to-work.aspxVorige week schreef Ivan Ristic het volgende over RC4 in https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack (onderstrepen door mij):
Door Ivan Ristic op 2014-10-15: In the short term, it's possible to mitigate POODLE by avoiding using CBC suites with SSL 3, but that involves relying on a certain insecure stream ciher whose name no one wants to mention. I don't recommend this approach.
En dat is precies wat Apple gedaan heeft, zie https://isc.sans.edu/forums/diary/Apple+Updates+not+just+Yosemite/18851.P.S. volgens ssllabs biedt www.digid.nl momenteel de volgende cipher suites aan, met de eerste/bovenste als voorkeur:
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
Edits 2014-10-22 10:16: links naar vinders van het lek (maart 2013 en latere Usenix presentatie) toegevoegd en enkele typfoutjes gefixt; forward security moet zijn forward secrecy
Edits 2014-11-02 14:00: zie sectie "Status 2014-11-02 14:00" met de actuele status van betreffende sites.
Edit 2014-11-04 23:55: De 2e alinea, 2e zin was: "Als de server een voorkeurvolgorde heeft aangegeven, kiest de browser de eerste cipher suite uit die lijst die door die browser wordt ondersteund, en die wordt vervolgens gebruikt": ik heb nu verduidelijkt dat de [i[beheerder[/i] wel of niet een voorkeurvolgorde opgeeft, en uiteindelijk is het de server die een cipher suite kiest (linksom of rechtsom is de instelling van de server bepalend, dit heeft dus geen effect voor mijn verdere betoog). Sorry voor de mogelijke onduidelijkheid!
Reacties (52)
Zo fout vind ik de titel overigens niet. Bewust inmiddels gekraakte of slechte encryptie-methodes prefereren boven de betere cq. veiligere methodes (om eventueel de kosten te drukken) mag gerust precies zo aangekaart worden. Zeker banken zouden toch veel beter moeten weten maar het gaat blijkbaar alleen om het besparen cq. binnenhalen van centjes en zeker niet (meer) om de veiligheid van kun klanten en het geld wat diezelfde klant tegen betaling bij de gratie Gods mag stallen bij diezelfde banken.
Artikel/post is verder goed en zeer leerzaam. Heb het in ieder geval met grote aandacht gelezen.
Artikel/post is verder goed en zeer leerzaam. Heb het in ieder geval met grote aandacht gelezen.
22-10-2014, 09:47 door
Erik van Straten
Door Anoniem: jammer van je sensationele titel.
Ik heb hier een tijd over gepiekerd. Ja, sensationeel. Maar kennelijk hebben niet-sensationele meldingen hierover (zoals van NCSC) in Nederland nog niet tot "nieuwe inzichten" geleid.Daarnaast, vergelijkbaar inhoudelijk goede stukken (zoals https://www.security.nl/posting/406070/Veilig+internetbankieren%3A+huidige+status+bankservers) zakken snel uit beeld als de boodschap -kennelijk- niet wordt overgebracht. Helaas kan de titel dan al een verschil maken, en die moet kort op deze site.
Mijn advies: check dat artikel, want er staat informatie in over veel meer sites dan ik onderzocht heb!
Erg goed stuk verder!
Thanks. Ik hoop hiermee deze broeiende issue bijtijds begrijpelijk te maken voor beheerders en (hopelijk) hun managers, zodat fixes ingepland kunnen worden. D.w.z. voordat een malloot een exploit hiervoor publiceert en het weer nachtwerk wordt.P.S. volgens ssllabs biedt www.digid.nl momenteel de volgende cipher suites aan, met de eerste/bovenste als voorkeur:
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
Hieruit maak ik op dat ze het rijtje in de verkeerde volgorde hebben geïmplementeerd. Dit heb ik wel eerder bij IIS services meegemaakt, zou me niks verbazen als het hier ook het geval is. (alhoewel 3des nou ook niet zo veilig is...)
22-10-2014, 10:01 door
Profeet
Forward Security cipher suites? Bedoelen we http://en.wikipedia.org/wiki/Forward_secrecy?
Verder top!
Verder top!
Door Anoniem: [...]
Hieruit maak ik op dat ze het rijtje in de verkeerde volgorde hebben geïmplementeerd. Dit heb ik wel eerder bij IIS services meegemaakt, zou me niks verbazen als het hier ook het geval is. (alhoewel 3des nou ook niet zo veilig is...)
Volgorde IIS: wellicht! 3DES: hoewel oud, zijn er (voor zover ik weet) nog geen kwetsbaarheden over gepubliceerd vergelijkbaar met die in RC4. Wel geldt het volgende, uit https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices_1.3.pdf: Hieruit maak ik op dat ze het rijtje in de verkeerde volgorde hebben geïmplementeerd. Dit heb ik wel eerder bij IIS services meegemaakt, zou me niks verbazen als het hier ook het geval is. (alhoewel 3des nou ook niet zo veilig is...)
3DES provides only 108 bits of security (or 112, depending on the source), which is below the recommended minimum of 128 bits.
Gangbaar advies is om 3DES (met laagste voorkeur) te blijven aanbieden als je XP+IE6 wilt blijven ondersteunen. Vermoedelijk om die reden ondersteunt mijn.ing.nl nog TLS_RSA_WITH_3DES_EDE_CBC_SHA met, inderdaad, de minste voorkeur.Door Profeet: Forward Security cipher suites? Bedoelen we http://en.wikipedia.org/wiki/Forward_secrecy?
Jazeker, thanks, gecorrigeerd!Prima en uiterst verhelderend stuk, Erik! Veel dank voor deze bijdrage.
Hopelijk doen de betreffende instanties hier nu heel snel hun voordeel mee (hetgeen zeer velen in Nederland ten goede zou komen).
Harry
Hopelijk doen de betreffende instanties hier nu heel snel hun voordeel mee (hetgeen zeer velen in Nederland ten goede zou komen).
Harry
Het ABP heb ik een jaar geleden al gewaarschuwd voor het gebruik van RC4. Blijkbaar was dat tegen dovemans oren.
Door Anoniem:
Hieruit maak ik op dat ze het rijtje in de verkeerde volgorde hebben geïmplementeerd. Dit heb ik wel eerder bij IIS services meegemaakt, zou me niks verbazen als het hier ook het geval is. (alhoewel 3des nou ook niet zo veilig is...)
P.S. volgens ssllabs biedt www.digid.nl momenteel de volgende cipher suites aan, met de eerste/bovenste als voorkeur:
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
Hieruit maak ik op dat ze het rijtje in de verkeerde volgorde hebben geïmplementeerd. Dit heb ik wel eerder bij IIS services meegemaakt, zou me niks verbazen als het hier ook het geval is. (alhoewel 3des nou ook niet zo veilig is...)
Meeste bedrijven doen aan SSL offloading en ik vermoed dat dit gewoon op de loadbalancer plaats vindt en NIET op de webservers zelf (denk aan het onderhoud en het gevaar dat er sneller een private key rond slingert etc.).
22-10-2014, 14:37 door
dutchfish
https://www.ssllabs.com/ssltest/analyze.html?d=www.accessonline.abnamro.com&s=167.202.220.50&hideResults=on
Goed stuk Erik van Straten.
Ik begrijp dat je dus:
Zou kunnen wachten tot webbrowsers RC4 niet meer ondersteunen of servers RC4 niet meer ondersteunen. (alleen is het de vraag hoelang dat nog gaat duren).
of
Het heft in eigen hand nemen en ervoor zorgen dat RC4 'aan je eigen kant/ client zijde', niet meer wordt ondersteund.
Ik begrijp dat je dus:
Zou kunnen wachten tot webbrowsers RC4 niet meer ondersteunen of servers RC4 niet meer ondersteunen. (alleen is het de vraag hoelang dat nog gaat duren).
of
Het heft in eigen hand nemen en ervoor zorgen dat RC4 'aan je eigen kant/ client zijde', niet meer wordt ondersteund.
Goeie actie van je Erik, om dit zo onder de aandacht te brengen!
Hoe erg lek is RC4?
en dat men de wetenschap over bepaalde zwakten van RC4 niet domweg zou moeten verwaarlozen.
Appelbaum verduidelijkte zichzelf in dezelfde twitterdiscussie ten slotte met:
Maar op zijn minst is wel duidelijk dat theoretisch RC4 lang niet zo sterk is dan zij pretendeerde te zijn.
Zie ook https://www.security.nl/posting/40401/Onderzoekers+kraken+RC4-encryptie
Dit zijn de feiten die we in elk geval 100% zeker weten.
En dan is het nogal dom als men toch RC4 blijft inzetten, terwijl er betere alternatieven zijn. (ongeacht of het nu wel of niet waar is dat sommigen inmiddels al "real time" encryptie met RC4 zouden kunnen afluisteren en decoderen)
Het is voor mij nog altijd wat duister hoe ernstig die RC4-kwetsbaarheid nu werkelijk is.
Termen als "lek" en "gekraakt" kunnen de indruk wekken dat iedereen zomaar alle versleutelde communicatie kan ontcijferen. Maar voor zover bekend is dit nog niet zo gemakkelijk.
Ten eerste moet er ergens op het netwerk iemand zijn die toegang heeft tot jouw communicatie.
Ten tweede zal men waarschijnlijk duizenden tot miljoenen keren je browser moeten dwingen om de communicatie te herhalen. Slides over dit onderwerp laten zien dat er na ca. 2^24 (16.777.216) keer herverzenden,
de data in de eerste bytes van je communicatie langzamerhand bloot komen te liggen.
Na 2^32 (4.294.967.295) keer herverzenden liggen de eerste 256 bytes nagenoeg helemaal bloot.
Dit geldt wanneer er geen enkele voorkennis is over de verzonden data. Maar als men weet hoe een sessiecookie (die vaak in de eerste bytes wordt meegestuurd) er ongeveer uit moet zien, dan helpt dit om het nóg sneller te ontcijferen.
Toch is het te verwachten dat men hiervoor nog altijd duizenden tot miljoenen keren de communicatie moet herhalen.
Je zou kunnen zeggen: in plaats van 128 bit die RC4 lijkt te beloven, is je encryptiekwaliteit ten hoogste 24 tot 32 bit.
En wellicht nog (veel) minder als er iets bekend is over de structuur van de verzonden data (bijv. een session cookie).
In elk geval geldt zoiets voor de eerste 256 bytes die je met RC4-encryptie verstuurt.
Verder is het goed om er rekening mee te houden dat er nog geavanceerdere aanvallen op RC4 kunnen bestaan,
of rap zullen komen. Hoe dan ook: het is sterk aan te bevelen om RC4 niet meer te gebruiken voor gevoelige data.
Dat beschermt je dan inderdaad tegen een onbehoorlijke terugval naar een lagere TLS-versie.
Alleen volgens mij zal in de "actuele browsers" waar je aan refereert, SSL 3.0 bij default al zijn uitgeschakeld.
Zie: https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0
In FF34 zal SSLv3 default al uitgeschakeld zijn.
In FF35 zal TLS_FALLBACK_SCSV worden toegevoegd.
Maar ik mag aannemen dat SSLv3 in FF35 en nieuwer "by default" nog steeds uitgeschakeld is?
"klanten die wel actuele browsers gebruiken -maar SSLv3 nog niet hebben uitgeschakeld-" klinkt dan wat onzinnig.
Het lijkt me logisch om de HSTS tijdspanne daarop aan te passen,
dus bijvoorbeeld 1096 dagen, d.w.z. een waarde van 94.694.400 seconden.
Mvg, cluc-cluc
Hoe erg lek is RC4?
RC4 is broken in real time by the NSA - stop using it.
Dit is een uitdrukking van Appelbaum om mensen wakker te schudden dat er een gevaar dreigt,en dat men de wetenschap over bepaalde zwakten van RC4 niet domweg zou moeten verwaarlozen.
Appelbaum verduidelijkte zichzelf in dezelfde twitterdiscussie ten slotte met:
Or to put it another way - academics have said RC4 is broken for years. Listen to them.
Ga je vervolgens na wat deze academici ons voorrekenen, dan komen we er achter dat "broken" niet meteen hoeft te betekenen dat iedereen zondermeer "on-the-fly" onmiddellijk al je communicatie kan ontcijferen.Maar op zijn minst is wel duidelijk dat theoretisch RC4 lang niet zo sterk is dan zij pretendeerde te zijn.
Zie ook https://www.security.nl/posting/40401/Onderzoekers+kraken+RC4-encryptie
Dit zijn de feiten die we in elk geval 100% zeker weten.
En dan is het nogal dom als men toch RC4 blijft inzetten, terwijl er betere alternatieven zijn. (ongeacht of het nu wel of niet waar is dat sommigen inmiddels al "real time" encryptie met RC4 zouden kunnen afluisteren en decoderen)
Het is voor mij nog altijd wat duister hoe ernstig die RC4-kwetsbaarheid nu werkelijk is.
Termen als "lek" en "gekraakt" kunnen de indruk wekken dat iedereen zomaar alle versleutelde communicatie kan ontcijferen. Maar voor zover bekend is dit nog niet zo gemakkelijk.
Ten eerste moet er ergens op het netwerk iemand zijn die toegang heeft tot jouw communicatie.
Ten tweede zal men waarschijnlijk duizenden tot miljoenen keren je browser moeten dwingen om de communicatie te herhalen. Slides over dit onderwerp laten zien dat er na ca. 2^24 (16.777.216) keer herverzenden,
de data in de eerste bytes van je communicatie langzamerhand bloot komen te liggen.
Na 2^32 (4.294.967.295) keer herverzenden liggen de eerste 256 bytes nagenoeg helemaal bloot.
Dit geldt wanneer er geen enkele voorkennis is over de verzonden data. Maar als men weet hoe een sessiecookie (die vaak in de eerste bytes wordt meegestuurd) er ongeveer uit moet zien, dan helpt dit om het nóg sneller te ontcijferen.
Toch is het te verwachten dat men hiervoor nog altijd duizenden tot miljoenen keren de communicatie moet herhalen.
Je zou kunnen zeggen: in plaats van 128 bit die RC4 lijkt te beloven, is je encryptiekwaliteit ten hoogste 24 tot 32 bit.
En wellicht nog (veel) minder als er iets bekend is over de structuur van de verzonden data (bijv. een session cookie).
In elk geval geldt zoiets voor de eerste 256 bytes die je met RC4-encryptie verstuurt.
Verder is het goed om er rekening mee te houden dat er nog geavanceerdere aanvallen op RC4 kunnen bestaan,
of rap zullen komen. Hoe dan ook: het is sterk aan te bevelen om RC4 niet meer te gebruiken voor gevoelige data.
Als (na testen) de "SSL 3.0 Fallback protection" patch (TLS_FALLBACK_SCSV) betrouwbaar blijkt, installeer die dan. Daarmee worden klanten die wel actuele browsers gebruiken -maar SSLv3 nog niet hebben uitgeschakeld- beter beschermd tegen protocol downgrade attack (ook van TLS v1.2 naar een lagere TLS versie).
Zeker waard om bij bewezen betrouwbaarheid TLS_FALLBACK_SCSV te installeren.Dat beschermt je dan inderdaad tegen een onbehoorlijke terugval naar een lagere TLS-versie.
Alleen volgens mij zal in de "actuele browsers" waar je aan refereert, SSL 3.0 bij default al zijn uitgeschakeld.
Zie: https://blog.mozilla.org/security/2014/10/14/the-poodle-attack-and-the-end-of-ssl-3-0
In FF34 zal SSLv3 default al uitgeschakeld zijn.
In FF35 zal TLS_FALLBACK_SCSV worden toegevoegd.
Maar ik mag aannemen dat SSLv3 in FF35 en nieuwer "by default" nog steeds uitgeschakeld is?
"klanten die wel actuele browsers gebruiken -maar SSLv3 nog niet hebben uitgeschakeld-" klinkt dan wat onzinnig.
@DigiD: de HSTS tijdspanne is nu 365 dagen, verhoog dat svp. Ik bezoek jullie 1x per jaar om mijn belasting in te dienen en daar zou best een keer 370 dagen tussen kunnen zitten...
Een Digid verloopt na 3 jaar als je hem niet gebruikt. (zie: https://www.digid.nl/over-digid/)Het lijkt me logisch om de HSTS tijdspanne daarop aan te passen,
dus bijvoorbeeld 1096 dagen, d.w.z. een waarde van 94.694.400 seconden.
Mvg, cluc-cluc
Wat ik nog veel erger vind dan bovenstaande bevindingen is dat er geen enkele bank is die PFS ondersteunt...
Door Anoniem: Wat ik nog veel erger vind dan bovenstaande bevindingen is dat er geen enkele bank is die PFS ondersteunt...
PFS = "FS" in de tabel.https://en.wikipedia.org/wiki/Perfect_forward_secrecy
Of... bedoel je misschien dat het aan "Professional Financial Services" ontbreekt? :)
Beste erik,
Bedankt voor je fijne artikel.
Goed hier aandacht te schenken. Het zoveelste beveiligingsrisico van het SSL protocol. Goed om servers eens te scannen via https://www.ssllabs.com/ssltest/ bijvoorbeeld. Hou de scandata dan voor jezelf, want Qualys houdt je verantwoordelijk bij misbruik en in de States is dat misbruik nogal makkelijk breed uit te leggen. Alles waarvoor niet expliciete voorafgaande schriftelijke toestemming is gegeven/verkregen of door derden kan worden misbruikt, kan je al flink in de problemen brengen. Ook Dazzlepod IP nmap scan gegevens vallen onder gelijkaardige condities. Oppassen dus. Feiten zijn dat er nog een heleboel op tal van servers misgaat door verkeerd patch-beleid, door het niet voldoende juist configureren en afharden van servers (info proliferatie). Zo is al het laaghangende fruit direct voer voor de defacers, de pioneers van het kwaadaardige net met hun autorooters en backdoors die het landschap afschuimen en omploegen voor de volgende zwerm malcreanten-vogels neerstrijken. Arrogantie van admins en hosters van de linux comunity tegenover de gebruikers van het windows platform doet de rest en de lekjes rijgen zichvervolgens aaneen als bellen in een gatenkaasbrei.
Er zijn nog veel artikelen als deze nodig aleer men wat veiliger leert te denken en de eindgebruiker minder risico's gaat lopen. Er is nog veel educatie nodig. Tijd dat het in de tekstboeken en het curriculum verschijnt op IT opleidingen!
luntrus
Bedankt voor je fijne artikel.
Goed hier aandacht te schenken. Het zoveelste beveiligingsrisico van het SSL protocol. Goed om servers eens te scannen via https://www.ssllabs.com/ssltest/ bijvoorbeeld. Hou de scandata dan voor jezelf, want Qualys houdt je verantwoordelijk bij misbruik en in de States is dat misbruik nogal makkelijk breed uit te leggen. Alles waarvoor niet expliciete voorafgaande schriftelijke toestemming is gegeven/verkregen of door derden kan worden misbruikt, kan je al flink in de problemen brengen. Ook Dazzlepod IP nmap scan gegevens vallen onder gelijkaardige condities. Oppassen dus. Feiten zijn dat er nog een heleboel op tal van servers misgaat door verkeerd patch-beleid, door het niet voldoende juist configureren en afharden van servers (info proliferatie). Zo is al het laaghangende fruit direct voer voor de defacers, de pioneers van het kwaadaardige net met hun autorooters en backdoors die het landschap afschuimen en omploegen voor de volgende zwerm malcreanten-vogels neerstrijken. Arrogantie van admins en hosters van de linux comunity tegenover de gebruikers van het windows platform doet de rest en de lekjes rijgen zichvervolgens aaneen als bellen in een gatenkaasbrei.
Er zijn nog veel artikelen als deze nodig aleer men wat veiliger leert te denken en de eindgebruiker minder risico's gaat lopen. Er is nog veel educatie nodig. Tijd dat het in de tekstboeken en het curriculum verschijnt op IT opleidingen!
luntrus
Naast HSTS zijn er wel meer handige headers die ook interessant zijn om te bekijken.
https://www.owasp.org/index.php/List_of_useful_HTTP_headers
https://www.owasp.org/index.php/List_of_useful_HTTP_headers
23-10-2014, 00:29 door
Erik van Straten
Door dutchfish: https://www.ssllabs.com/ssltest/analyze.html?d=www.accessonline.abnamro.com&s=167.202.220.50&hideResults=on
Hmm, interessant, exact hetzelfde lijstje als DigiD, en in dezelfde volgorde (zie opmerking Anoniem op 2014-10-22 om 10:00 - zelfde type load balancer met default configuratie wellicht?):TLS_RSA_WITH_RC4_128_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA256
Maar wel verschil in ondersteunde protocollen:
DigiD www.accessonline.abnamro.com
TLS 1.2 Yes Yes
TLS 1.1 No Yes
TLS 1.0 Yes Yes
SSL 3 No Yes (rood gedrukt in de ssllabs pagina)
SSL 2 No No
Echter, als ik het goed begrijp, zegt dit niet zoveel: geen van de genoemde cipher suites werkt onder SSLv3 of onder TLS v1.1 (zoek maar naar genoemde cipher suites in https://www.openssl.org/docs/apps/ciphers.html), waarmee www.accessonline.abnamro.com effectief ook slechts TLS v1.0 en 1.2 ondersteunt.TLS 1.2 Yes Yes
TLS 1.1 No Yes
TLS 1.0 Yes Yes
SSL 3 No Yes (rood gedrukt in de ssllabs pagina)
SSL 2 No No
Door _kraai__: Zou kunnen wachten tot webbrowsers RC4 niet meer ondersteunen
Als je ziet dat Apple er in de laatste Yosemite update voor gekozen heeft om de combinatie van SSLv3 en RC4 nog te ondersteunen, dan gaat dat nog vele jaren duren. En, zoals ik bovenin schreef, zolang er servers zijn (waarmee meer of minder vertrouwelijke gegevens worden uitgeiwsseld) die alleen RC4 ondersteunen, horen m.i. eigenaren van servers waar gebruikers zeker vertrouwelijke gegevens mee uitwisselen, hun verantwoordelijkheid te nemen.Door _kraai__: Het heft in eigen hand nemen en ervoor zorgen dat RC4 'aan je eigen kant/ client zijde', niet meer wordt ondersteund.
Er zullen vast wel een paar security.nl lezers zijn die hun browser settings tweaken, maar van alle mensen die genoemde sites bezoeken hebben we het vermoedelijk over een verwaarloosbare fractie.Door cluc-cluc: Appelbaum verduidelijkte zichzelf in dezelfde twitterdiscussie ten slotte met:
[...]
Het is voor mij nog altijd wat duister hoe ernstig die RC4-kwetsbaarheid nu werkelijk is.
[...]
Toch is het te verwachten dat men hiervoor nog altijd duizenden tot miljoenen keren de communicatie moet herhalen.
[...]
Hoe dan ook: het is sterk aan te bevelen om RC4 niet meer te gebruiken voor gevoelige data.
Soms heb ik het gevoel dat je advocaat van de duivel speelt, en dan weer niet? Vakmensen (cryptografen) zeggen dat je RC4 niet meer moet gebruiken, en er zijn veiliger alternatieven. Lijkt mij een simpele keuze.Or to put it another way - academics have said RC4 is broken for years. Listen to them.
Ga je vervolgens na wat deze academici ons voorrekenen, dan komen we er achter dat "broken" niet meteen hoeft te betekenen dat iedereen zondermeer "on-the-fly" onmiddellijk al je communicatie kan ontcijferen.[...]
Het is voor mij nog altijd wat duister hoe ernstig die RC4-kwetsbaarheid nu werkelijk is.
[...]
Toch is het te verwachten dat men hiervoor nog altijd duizenden tot miljoenen keren de communicatie moet herhalen.
[...]
Hoe dan ook: het is sterk aan te bevelen om RC4 niet meer te gebruiken voor gevoelige data.
Door cluc-cluc: Alleen volgens mij zal in de "actuele browsers" waar je aan refereert, SSL 3.0 bij default al zijn uitgeschakeld.
Sorry, ik was niet erg duidelijk: met "actuele" bedoelde ik hier de status van vandaag. Ik vermoed verreweg de meeste webbrowsers vandaag de dag nog SSLv3 ondersteunen.Door cluc-cluc: In FF35 zal TLS_FALLBACK_SCSV worden toegevoegd.
In https://community.qualys.com/blogs/securitylabs/2014/10/15/ssl-3-is-dead-killed-by-the-poodle-attack staat: Door Ivan Ristic: There's a solution to this problem, via the TLS_FALLBACK_SCSV indicator that must be supported by clients and servers in order to be effective.
Ik moet me nog inlezen hoe SCSV precies werkt, maar uit het bovenstaande maak ik op dat zowel de client als de server SCSV moet ondersteunen voordat dit werkt.Door Anoniem: Wat ik nog veel erger vind dan bovenstaande bevindingen is dat er geen enkele bank is die PFS ondersteunt...
In https://www.security.nl/posting/406070/Veilig+internetbankieren%3A+huidige+status+bankservers kun je zien dat een enkele bank dat wel doet. Hoewel interessant is het misschien beter om de (P)FS discussie in die pagina te voeren, en ons hier tot RC4 en alternatieve ciphers te beperken.Mooi stuk Erik, dank voor de eenvoudige toelichting. Dit helpt vooral ook in de awareness er rondom. Zag inmiddels dat Triodos bank het zelfs via Twitter opgepakt heeft en ermee aan de slag gaat. Het is dus zeker niet voor niets!
Beste groet,
Beste groet,
Door Anoniem: Mooi stuk Erik, dank voor de eenvoudige toelichting. Dit helpt vooral ook in de awareness er rondom. Zag inmiddels dat Triodos bank het zelfs via Twitter opgepakt heeft en ermee aan de slag gaat. Het is dus zeker niet voor niets!
Beste groet,
Dank voor de melding, en Triodos heeft het inderdaad gefixt! Dit doet mij zeker goed, want ik heb heel lang getwijfeld of het wel verantwoord was om bovenstaand artikel te posten.Beste groet,
Uit https://www.ssllabs.com/ssltest/analyze.html?d=bankieren.triodos.nl&s=212.123.231.24&hideResults=on, de volgende cipher suites worden aangeboden (met voorkeur voor de bovenste, dus dat gebruiken de meeste browsers):
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Bovendien ondersteunt https://bankieren.triodos.nl/ HSTS (Strict-Transport-Security) met een lifetime van 31536000 seconden (na ieder bezoek) = 365 dagen. Ook het certificaat is in orde (SHA256). Prima!
Er zijn nog drie verbeterpuntjes: ondersteunen van TLS v1.2, forward secrecy en TLS_FALLBACK_SCSV.
M.b.t. TLS v1.2 (aanvulling 16:23): deze verzorgt de beste beveiliging doordat van de meest moderne technioeken gebruik gemaakt wordt. Uit https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what:
Start recommending the use of GCM suites. Browsers will no doubt provide better support for TLS 1.2 and GCM suites at an accelerated schedule, and site operators should be ready to take advantage of that.
Dat artikel is van ruim 1 jaar geleden, de meeste browsers ondersteunen CGM suites tegenwoordig.M.b.t. forward secrecy: dit is van belang mocht een cybercrimineel of een "veiligheids-" dienst versleuteld verkeer opslaan. Dat zou kunnen bij een (gecompromitteerde) ISP of door DNS manipulatie (zie bijv. https://www.security.nl/posting/406209/Advertenties+wijzigen+DNS-instellingen+routers). Daar kan die geïnteresseerde nu nog niets mee, maar mogelijk wel in de toekomst, nl. als de private key van Triodos (complementair aan de public key in hun certificaat) ooit gelekt wordt. Maar die kans acht ik niet zo groot bij een bank.
M.b.t. TLS_FALLBACK_SCSV: dit is nog zo nieuw dat ik me goed kan voorstellen dat ze dit eerst willen testen. Bovendien zijn er (voor zover ik weet) nog geen browsers op de markt die dit ondersteunen, en, zoals ik eerder schreef, voor zover ik het begrijp moeten zowel server als browsers SCSV ondersteunen.
Kortom: voortaan beter security nieuws in de gaten houden (zoals van NCSC), maar desalniettemin, goed gedaan Triodos!
23-10-2014, 16:48 door
Erik van Straten
Door Anoniem (luntrus) 2014-10-22 23:36: Bedankt voor je fijne artikel.
Voor deze en alle andere positieve reacties: graag gedaan!Door Anoniem 2014-10-23 00:10: Naast HSTS zijn er wel meer handige headers die ook interessant zijn om te bekijken.
https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Dank!https://www.owasp.org/index.php/List_of_useful_HTTP_headers
Triodos gebruikt "Strict-Transport-Security" (zie boven) en "X-Frame-Options: deny", maar nog geen CSP (noch Content-Security-Policy, noch Content-Security-Policy-Report-Only).
M.b.t. CSP, een stukje uit de conclusie in https://blog.hboeck.de/archives/853-Some-experience-with-Content-Security-Policy.html (italics in de tekst door mij):
Door Hanno Böck op 2014-09-19: If you start a web project use CSP. If you have a web page that needs extra security use CSP (my bank doesn't - does yours?). CSP reporting is neat, but it's usefulness is limited due to too many false positives.
Soms heb ik het gevoel dat je advocaat van de duivel speelt, en dan weer niet?
Een gezonde argwaan is niet verkeerd. Dat is wat er achter zit.Vakmensen (cryptografen) zeggen dat je RC4 niet meer moet gebruiken
Daar twijfel ik niet zozeer aan, maar ik wil nu eenmaal liefst zo nauwkeurig mogelijk weten wat er precies mis mee is,Ik hou niet zo van dat ongenuanceerde, of van boute speculaties.
en er zijn veiliger alternatieven.
Ja, meestal wel. Behalve bij niet te patchen "TLSv1.0 only" browsers met beperkt aantal ciphers. (BEAST?)
Lijkt mij een simpele keuze.
Ja hoor, als je het ongenuanceerd bekijkt en niet teveel op bijzondere gevallen let, dan is het simpel.Alleen wees er ook weer niet té zeker van dat een "nieuwe technologie" altijd per definitie zoveel veiliger is.
http://www.theregister.co.uk/2013/09/06/nsa_cryptobreaking_bullrun_analysis/ (pagina 1 én 2...)
M.a.w.: altijd blijven relativeren! ;-)
Mvg, cluc-cluc
Door Erik van Straten:
Uit https://www.ssllabs.com/ssltest/analyze.html?d=bankieren.triodos.nl&s=212.123.231.24&hideResults=on, de volgende cipher suites worden aangeboden (met voorkeur voor de bovenste, dus dat gebruiken de meeste browsers):
Bovendien ondersteunt https://bankieren.triodos.nl/ HSTS (Strict-Transport-Security) met een lifetime van 31536000 seconden (na ieder bezoek) = 365 dagen. Ook het certificaat is in orde (SHA256). Prima!
Er zijn nog drie verbeterpuntjes: ondersteunen van TLS v1.2, forward secrecy en TLS_FALLBACK_SCSV.
M.b.t. TLS v1.2 (aanvulling 16:23): deze verzorgt de beste beveiliging doordat van de meest moderne technioeken gebruik gemaakt wordt. Uit https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what:
M.b.t. forward secrecy: dit is van belang mocht een cybercrimineel of een "veiligheids-" dienst versleuteld verkeer opslaan. Dat zou kunnen bij een (gecompromitteerde) ISP of door DNS manipulatie (zie bijv. https://www.security.nl/posting/406209/Advertenties+wijzigen+DNS-instellingen+routers). Daar kan die geïnteresseerde nu nog niets mee, maar mogelijk wel in de toekomst, nl. als de private key van Triodos (complementair aan de public key in hun certificaat) ooit gelekt wordt. Maar die kans acht ik niet zo groot bij een bank.
M.b.t. TLS_FALLBACK_SCSV: dit is nog zo nieuw dat ik me goed kan voorstellen dat ze dit eerst willen testen. Bovendien zijn er (voor zover ik weet) nog geen browsers op de markt die dit ondersteunen, en, zoals ik eerder schreef, voor zover ik het begrijp moeten zowel server als browsers SCSV ondersteunen.
Kortom: voortaan beter security nieuws in de gaten houden (zoals van NCSC), maar desalniettemin, goed gedaan Triodos!
Ik ben zelf klant van Triodos en heb ook al een hele tijd geleden een uitgebreide melding naar ze verstuurd over hun SSL/TLS configuratie, die toen naar de IT afdeling is doorgestuurd. Helaas niets meer van gehoord, maar gelukkig is er nu verbetering door deze publiciteit. Jammer dat ze dit niet gelijk aangepakt hebben om ook Forward Secrecy te ondersteunen, maar ze hebben in ieder geval RC4 en SSLv3 gedumpt.TLS 1.2 ondersteunen ze trouwens wel(en deden ze ook al langer), dat is trouwens ook nodig voor de AES ciphersuites met SHA256.Door Anoniem: Mooi stuk Erik, dank voor de eenvoudige toelichting. Dit helpt vooral ook in de awareness er rondom. Zag inmiddels dat Triodos bank het zelfs via Twitter opgepakt heeft en ermee aan de slag gaat. Het is dus zeker niet voor niets!
Beste groet,
Dank voor de melding, en Triodos heeft het inderdaad gefixt! Dit doet mij zeker goed, want ik heb heel lang getwijfeld of het wel verantwoord was om bovenstaand artikel te posten.Beste groet,
Uit https://www.ssllabs.com/ssltest/analyze.html?d=bankieren.triodos.nl&s=212.123.231.24&hideResults=on, de volgende cipher suites worden aangeboden (met voorkeur voor de bovenste, dus dat gebruiken de meeste browsers):
TLS_RSA_WITH_AES_256_CBC_SHA256
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA256
TLS_RSA_WITH_AES_256_CBC_SHA
TLS_RSA_WITH_AES_128_CBC_SHA
TLS_RSA_WITH_3DES_EDE_CBC_SHA
Bovendien ondersteunt https://bankieren.triodos.nl/ HSTS (Strict-Transport-Security) met een lifetime van 31536000 seconden (na ieder bezoek) = 365 dagen. Ook het certificaat is in orde (SHA256). Prima!
Er zijn nog drie verbeterpuntjes: ondersteunen van TLS v1.2, forward secrecy en TLS_FALLBACK_SCSV.
M.b.t. TLS v1.2 (aanvulling 16:23): deze verzorgt de beste beveiliging doordat van de meest moderne technioeken gebruik gemaakt wordt. Uit https://community.qualys.com/blogs/securitylabs/2013/03/19/rc4-in-tls-is-broken-now-what:
Start recommending the use of GCM suites. Browsers will no doubt provide better support for TLS 1.2 and GCM suites at an accelerated schedule, and site operators should be ready to take advantage of that.
Dat artikel is van ruim 1 jaar geleden, de meeste browsers ondersteunen CGM suites tegenwoordig.M.b.t. forward secrecy: dit is van belang mocht een cybercrimineel of een "veiligheids-" dienst versleuteld verkeer opslaan. Dat zou kunnen bij een (gecompromitteerde) ISP of door DNS manipulatie (zie bijv. https://www.security.nl/posting/406209/Advertenties+wijzigen+DNS-instellingen+routers). Daar kan die geïnteresseerde nu nog niets mee, maar mogelijk wel in de toekomst, nl. als de private key van Triodos (complementair aan de public key in hun certificaat) ooit gelekt wordt. Maar die kans acht ik niet zo groot bij een bank.
M.b.t. TLS_FALLBACK_SCSV: dit is nog zo nieuw dat ik me goed kan voorstellen dat ze dit eerst willen testen. Bovendien zijn er (voor zover ik weet) nog geen browsers op de markt die dit ondersteunen, en, zoals ik eerder schreef, voor zover ik het begrijp moeten zowel server als browsers SCSV ondersteunen.
Kortom: voortaan beter security nieuws in de gaten houden (zoals van NCSC), maar desalniettemin, goed gedaan Triodos!
Overigens kunnen van de grote (desktop)browsers alleen IE en Safari hier hun voordeel mee doen. De anderen ondersteunen alleen AES-GCM met SHA256, niet AES-CBC.
Door Anoniem:
Ja, meestal wel.
Behalve bij niet te patchen "TLSv1.0 only" browsers met beperkt aantal ciphers. (BEAST?)
Je kan voor voor TLS 1.1+ en TLS 1.0 een andere ciphersuite lijst opgeven. Dus dan gebruikt een browser met TLS 1.2 geen RC4 en browsers met TLS 1.0 wel. Daarnaast is al een hele tijd geleden door veel browsers de 1/n-1 migitation tegen BEAST geïmplementeerd. Ik weet niet of die server-side ook ondersteund moet worden, maar als dat niet zo zou zijn is BEAST gelijk een veel kleiner issue.Ja, meestal wel.
Behalve bij niet te patchen "TLSv1.0 only" browsers met beperkt aantal ciphers. (BEAST?)
24-10-2014, 01:13 door
Erik van Straten
Door Anoniem: TLS 1.2 ondersteunen ze trouwens wel(en deden ze ook al langer), dat is trouwens ook nodig voor de AES ciphersuites met SHA256.
Je hebt gelijk, mijn fout! Ook suf dat ik van CGM sprak terwijl de server geen cipher suites met CGM aanbiedt.Overigens kunnen van de grote (desktop)browsers alleen IE en Safari hier hun voordeel mee doen. De anderen ondersteunen alleen AES-GCM met SHA256, niet AES-CBC.
In Firefox 31.2.0 ESR zie ik TLS_RSA_WITH_AES_256_CBC_SHA zoals jij zegt, en dat is inderdaard een "AES ciphersuite from RFC3268, extending TLS v1.0" (bron: https://www.openssl.org/docs/apps/ciphers.html).In MSIE 11 (Win 7) zie ik: "Connection: TLS 1.0, AES with 256 bit encryption (High), RSA with 2048 bit exchange." Da's vreemd, want volgens de SSLLabs analyse ondersteunt IE11 zowel onder W7 als W8.x TLS 1.2 met bijv. de TLS_RSA_WITH_AES_256_CBC_SHA256 cipher suite.
Toch kan de "Properties" (Eigenschappen) dialoogbox van MSIE 11 wel TLS v1.2 van TLS v1.0 onderscheiden, want als ik https://colabora.greenpeace.es/ open (een site waarvan ik laatst op ssllabs.com toevallig had gezien dat deze A+ kreeg), zie ik wel TLS v1.2 in de properties dialogbox.
Dus wil ik weten wat er aan de hand is. Met Wireshark zie ik aanvankelijk TLS v1.2 verkeer, en er komen inderdaad meerdere TLS v1.2 verbindingen met IP-adres 212.123.231.24 tot stand, gebruik makend van cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256.
Echter, er worden ook verbindingen gemaakt met de IP-adressen 85.158.166.238 en 85.158.166.235: die blijken van resp. projects.triodos.com en van www.triodos.nl te zijn.
De reden daarvoor is, uit de source van https://bankieren.triodos.nl/ib-seam/login.seam?lcid=<nummer>:
<img <knip> src="https://www.triodos.nl/media/sitewide/185596/ib-hangslotje" <knip>
<img <knip> src="https://www.triodos.nl/media/183763/productbox-maandbeleggen-2014-ib-footer" <knip>
<img src="https://projects.triodos.com/projects/nl/development_cooperation/5984<knip>
<img <knip> src="https://www.triodos.nl/media/183763/productbox-maandbeleggen-2014-ib-footer" <knip>
<img src="https://projects.triodos.com/projects/nl/development_cooperation/5984<knip>
Uit https://www.ssllabs.com/ssltest/analyze.html?d=triodos.nl&hideResults=on (beetje herschreven voor de leesbaarheid):
SSL Report: triodos.nl (85.158.166.235)
Assessed on: Thu Oct 23 14:36:39 PDT 2014
Protocols
TLS 1.2: Yes
TLS 1.1: Yes
TLS 1.0: Yes
SSL 3: INSECURE Yes
SSL 2: Yes (Protocol is supported, but with all cipher suites disabled)
Cipher Suites (sorted by strength; the server has no preference)
Downgrade attack prevention: No, TLS_FALLBACK_SCSV not supported
RC4: Yes (with TLS 1.1 and newer) WEAK
Forward Secrecy: No WEAK
Strict Transport Security (HSTS): No
SSL 2 handshake compatibility: Yes
HTTP status code: 301
HTTP forwarding: http://www.triodos.nl
HTTP server signature: Apache
Assessed on: Thu Oct 23 14:36:39 PDT 2014
Protocols
TLS 1.2: Yes
TLS 1.1: Yes
TLS 1.0: Yes
SSL 3: INSECURE Yes
SSL 2: Yes (Protocol is supported, but with all cipher suites disabled)
Cipher Suites (sorted by strength; the server has no preference)
TLS_RSA_WITH_RC4_128_MD5 (0x4) 128
TLS_RSA_WITH_RC4_128_SHA (0x5) 128
TLS_RSA_WITH_RC4_128_SHA (0x5) 128
Downgrade attack prevention: No, TLS_FALLBACK_SCSV not supported
RC4: Yes (with TLS 1.1 and newer) WEAK
Forward Secrecy: No WEAK
Strict Transport Security (HSTS): No
SSL 2 handshake compatibility: Yes
HTTP status code: 301
HTTP forwarding: http://www.triodos.nl
HTTP server signature: Apache
https://www.ssllabs.com/ssltest/analyze.html?d=projects.triodos.com&hideResults=on geeft identieke resultaten, alleen een ander certificaat, status code 200 en de server signature is "-". Geen van de certificate chains bevat nog SHA1 certificaten.
Net voor of na inloggen zijn er een aantal verbindingen met bankieren.triodos.nl (212.123.231.24), nog TLS v1.2 met cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256. Om mij onduidelijke opent MSIE daarna, naar datzelfde IP-adres, een TLS v1.0 verbinding, met als gevolg cipher suite TLS_RSA_WITH_AES_256_CBC_SHA. Zowel voor als na inloggen zie ik in de MSIE11 "Properties" dialoggbox "TLS 1.0" aangegeven worden.
Wat betekent dit, voor zover ik de consequenties allemaal overzie?
De SSL/TLS configuraties van www.triodos.nl en projects.triodos.com kunnen absoluut beter, maar met die servers worden, voor zover ik zie, geen vertrouwelijke gegevens uitgewisseld.
Gebruikersnaam en wachtwoord worden nu wel via een veilige (niet RC4) verbinding verzonden, maar daarbij wordt in een deel van de gevallen, ook als zowel de browser (MSIE11; Safari heb ik niet getest) als de server TLS v1.2 ondersteunen, een TLS v1.0 verbinding gebruikt met TLS_RSA_WITH_AES_256_CBC_SHA.
Voor een up-to-date browser die ongevoelig is voor de BEAST attack is dat prima, maar gebruikers van oudere browsers zouden zo wel risico kunnen lopen. Niet doen dus, zorg dat je een recente en qua patches up-to-date webbrowser gebruikt voor internetbankieren!
@20:49 door Anoniem:
Dit is de afgelopen jaren ook in veel servers gedaan. Zo is de client zondermeer beschermd tegen BEAST.
BEAST werkt namelijk alleen bij CBC-ciphers. (en RC4 is geen CBC cipher. Vandaar)
Maar als RC4 verdwijnt, dan is men alleen nog tegen BEAST beschermd als op het cliëntsysteem de 1/n-1 patch is geïnstalleerd, want de alternatieve ciphers zijn CBC.
Dus een niet-gepatchte "TLSv1.0 -only" browser die voorheen nog vanaf de serverzijde was beschermd tegen BEAST (door RC4 te gebruiken) is hiertegen niet langer beschermd als RC4 te riskant wordt geacht om nog langer te gebruiken. Kleinigheid misschien, maar lijkt me toch iets voor banken om rekening mee te houden.
Mvg, cluc-cluc.
Dus dan gebruikt een browser met TLS 1.2 geen RC4 en browsers met TLS 1.0 wel.
Maar dan laat je die browsers met TLS1.0 dus RC4 gebruiken, en RC4 was nu juist onveilig gebleken... ;-)Daarnaast is al een hele tijd geleden door veel browsers de 1/n-1 migitation tegen BEAST geïmplementeerd.
Op enkele uitzonderingen na. Over die uitzonderingen heb ik het.Ik weet niet of die server-side ook ondersteund moet worden, maar als dat niet zo zou zijn is BEAST gelijk een veel kleiner issue.
BEAST hoeft niet per sé aan de serverzijde gemitigeerd geworden, maar het kán wel: namelijk door RC4 te forceren.Dit is de afgelopen jaren ook in veel servers gedaan. Zo is de client zondermeer beschermd tegen BEAST.
BEAST werkt namelijk alleen bij CBC-ciphers. (en RC4 is geen CBC cipher. Vandaar)
Maar als RC4 verdwijnt, dan is men alleen nog tegen BEAST beschermd als op het cliëntsysteem de 1/n-1 patch is geïnstalleerd, want de alternatieve ciphers zijn CBC.
Dus een niet-gepatchte "TLSv1.0 -only" browser die voorheen nog vanaf de serverzijde was beschermd tegen BEAST (door RC4 te gebruiken) is hiertegen niet langer beschermd als RC4 te riskant wordt geacht om nog langer te gebruiken. Kleinigheid misschien, maar lijkt me toch iets voor banken om rekening mee te houden.
Mvg, cluc-cluc.
Goed nieuws, ik zie net dat op de Dev versie van SSL Labs dat de beoordeling gecapped wordt naar maximaal een B als RC4 aangeboden wordt:
https://dev.ssllabs.com/ssltest/analyze.html?d=colabora.greenpeace.es
Helaas geeft Firefox niet de TLS/SSL versie weer, dat bemoeilijkt het vergelijken van de resultaten.
Met IE11 op Windows 7 met TLS 1.2 enabled, staat bankieren.triodos.nl inderdaad bij mij ook TLS 1.0:
(AES with 256 bit encryption (High); RSA with 2048 bit exchange)
en bij https://colabora.greenpeace.es/ TLS 1.2:
(AES with 256 bit encryption (High); ECDH_P256 with 256 bit exchange)
Wanneer ik alleen TLS 1.2 of alleen TLS 1.1 en 1.2 aanzet in IE, mislukt de verbinding.
Als ik dit ook met Firefox 33 probeer krijg ik dezelfde resultaten.
https://dev.ssllabs.com/ssltest/analyze.html?d=colabora.greenpeace.es
Door Erik van Straten:
In MSIE 11 (Win 7) zie ik: "Connection: TLS 1.0, AES with 256 bit encryption (High), RSA with 2048 bit exchange." Da's vreemd, want volgens de SSLLabs analyse ondersteunt IE11 zowel onder W7 als W8.x TLS 1.2 met bijv. de TLS_RSA_WITH_AES_256_CBC_SHA256 cipher suite.
Toch kan de "Properties" (Eigenschappen) dialoogbox van MSIE 11 wel TLS v1.2 van TLS v1.0 onderscheiden, want als ik https://colabora.greenpeace.es/ open (een site waarvan ik laatst op ssllabs.com toevallig had gezien dat deze A+ kreeg), zie ik wel TLS v1.2 in de properties dialogbox.
Dus wil ik weten wat er aan de hand is. Met Wireshark zie ik aanvankelijk TLS v1.2 verkeer, en er komen inderdaad meerdere TLS v1.2 verbindingen met IP-adres 212.123.231.24 tot stand, gebruik makend van cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256.
Echter, er worden ook verbindingen gemaakt met de IP-adressen 85.158.166.238 en 85.158.166.235: die blijken van resp. projects.triodos.com en van www.triodos.nl te zijn.
De reden daarvoor is, uit de source van https://bankieren.triodos.nl/ib-seam/login.seam?lcid=<nummer>:
Uit https://www.ssllabs.com/ssltest/analyze.html?d=triodos.nl&hideResults=on (beetje herschreven voor de leesbaarheid):
https://www.ssllabs.com/ssltest/analyze.html?d=projects.triodos.com&hideResults=on geeft identieke resultaten, alleen een ander certificaat, status code 200 en de server signature is "-". Geen van de certificate chains bevat nog SHA1 certificaten.
Net voor of na inloggen zijn er een aantal verbindingen met bankieren.triodos.nl (212.123.231.24), nog TLS v1.2 met cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256. Om mij onduidelijke opent MSIE daarna, naar datzelfde IP-adres, een TLS v1.0 verbinding, met als gevolg cipher suite TLS_RSA_WITH_AES_256_CBC_SHA. Zowel voor als na inloggen zie ik in de MSIE11 "Properties" dialoggbox "TLS 1.0" aangegeven worden.
Wat betekent dit, voor zover ik de consequenties allemaal overzie?
De SSL/TLS configuraties van www.triodos.nl en projects.triodos.com kunnen absoluut beter, maar met die servers worden, voor zover ik zie, geen vertrouwelijke gegevens uitgewisseld.
Gebruikersnaam en wachtwoord worden nu wel via een veilige (niet RC4) verbinding verzonden, maar daarbij wordt in een deel van de gevallen, ook als zowel de browser (MSIE11; Safari heb ik niet getest) als de server TLS v1.2 ondersteunen, een TLS v1.0 verbinding gebruikt met TLS_RSA_WITH_AES_256_CBC_SHA.
Voor een up-to-date browser die ongevoelig is voor de BEAST attack is dat prima, maar gebruikers van oudere browsers zouden zo wel risico kunnen lopen. Niet doen dus, zorg dat je een recente en qua patches up-to-date webbrowser gebruikt voor internetbankieren!
Vreemd. Het zou kunnen dat IE bij de encryptiedetails bij meerdere, verschillende verbindingen de details van de sterkste aangeeft of van het hoofddomein.Door Anoniem: TLS 1.2 ondersteunen ze trouwens wel(en deden ze ook al langer), dat is trouwens ook nodig voor de AES ciphersuites met SHA256.
Je hebt gelijk, mijn fout! Ook suf dat ik van CGM sprak terwijl de server geen cipher suites met CGM aanbiedt.Overigens kunnen van de grote (desktop)browsers alleen IE en Safari hier hun voordeel mee doen. De anderen ondersteunen alleen AES-GCM met SHA256, niet AES-CBC.
In Firefox 31.2.0 ESR zie ik TLS_RSA_WITH_AES_256_CBC_SHA zoals jij zegt, en dat is inderdaard een "AES ciphersuite from RFC3268, extending TLS v1.0" (bron: https://www.openssl.org/docs/apps/ciphers.html).In MSIE 11 (Win 7) zie ik: "Connection: TLS 1.0, AES with 256 bit encryption (High), RSA with 2048 bit exchange." Da's vreemd, want volgens de SSLLabs analyse ondersteunt IE11 zowel onder W7 als W8.x TLS 1.2 met bijv. de TLS_RSA_WITH_AES_256_CBC_SHA256 cipher suite.
Toch kan de "Properties" (Eigenschappen) dialoogbox van MSIE 11 wel TLS v1.2 van TLS v1.0 onderscheiden, want als ik https://colabora.greenpeace.es/ open (een site waarvan ik laatst op ssllabs.com toevallig had gezien dat deze A+ kreeg), zie ik wel TLS v1.2 in de properties dialogbox.
Dus wil ik weten wat er aan de hand is. Met Wireshark zie ik aanvankelijk TLS v1.2 verkeer, en er komen inderdaad meerdere TLS v1.2 verbindingen met IP-adres 212.123.231.24 tot stand, gebruik makend van cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256.
Echter, er worden ook verbindingen gemaakt met de IP-adressen 85.158.166.238 en 85.158.166.235: die blijken van resp. projects.triodos.com en van www.triodos.nl te zijn.
De reden daarvoor is, uit de source van https://bankieren.triodos.nl/ib-seam/login.seam?lcid=<nummer>:
<img <knip> src="https://www.triodos.nl/media/sitewide/185596/ib-hangslotje" <knip>
<img <knip> src="https://www.triodos.nl/media/183763/productbox-maandbeleggen-2014-ib-footer" <knip>
<img src="https://projects.triodos.com/projects/nl/development_cooperation/5984<knip>
<img <knip> src="https://www.triodos.nl/media/183763/productbox-maandbeleggen-2014-ib-footer" <knip>
<img src="https://projects.triodos.com/projects/nl/development_cooperation/5984<knip>
Uit https://www.ssllabs.com/ssltest/analyze.html?d=triodos.nl&hideResults=on (beetje herschreven voor de leesbaarheid):
SSL Report: triodos.nl (85.158.166.235)
Assessed on: Thu Oct 23 14:36:39 PDT 2014
Protocols
TLS 1.2: Yes
TLS 1.1: Yes
TLS 1.0: Yes
SSL 3: INSECURE Yes
SSL 2: Yes (Protocol is supported, but with all cipher suites disabled)
Cipher Suites (sorted by strength; the server has no preference)
Downgrade attack prevention: No, TLS_FALLBACK_SCSV not supported
RC4: Yes (with TLS 1.1 and newer) WEAK
Forward Secrecy: No WEAK
Strict Transport Security (HSTS): No
SSL 2 handshake compatibility: Yes
HTTP status code: 301
HTTP forwarding: http://www.triodos.nl
HTTP server signature: Apache
Assessed on: Thu Oct 23 14:36:39 PDT 2014
Protocols
TLS 1.2: Yes
TLS 1.1: Yes
TLS 1.0: Yes
SSL 3: INSECURE Yes
SSL 2: Yes (Protocol is supported, but with all cipher suites disabled)
Cipher Suites (sorted by strength; the server has no preference)
TLS_RSA_WITH_RC4_128_MD5 (0x4) 128
TLS_RSA_WITH_RC4_128_SHA (0x5) 128
TLS_RSA_WITH_RC4_128_SHA (0x5) 128
Downgrade attack prevention: No, TLS_FALLBACK_SCSV not supported
RC4: Yes (with TLS 1.1 and newer) WEAK
Forward Secrecy: No WEAK
Strict Transport Security (HSTS): No
SSL 2 handshake compatibility: Yes
HTTP status code: 301
HTTP forwarding: http://www.triodos.nl
HTTP server signature: Apache
https://www.ssllabs.com/ssltest/analyze.html?d=projects.triodos.com&hideResults=on geeft identieke resultaten, alleen een ander certificaat, status code 200 en de server signature is "-". Geen van de certificate chains bevat nog SHA1 certificaten.
Net voor of na inloggen zijn er een aantal verbindingen met bankieren.triodos.nl (212.123.231.24), nog TLS v1.2 met cipher suite TLS_RSA_WITH_AES_256_CBC_SHA256. Om mij onduidelijke opent MSIE daarna, naar datzelfde IP-adres, een TLS v1.0 verbinding, met als gevolg cipher suite TLS_RSA_WITH_AES_256_CBC_SHA. Zowel voor als na inloggen zie ik in de MSIE11 "Properties" dialoggbox "TLS 1.0" aangegeven worden.
Wat betekent dit, voor zover ik de consequenties allemaal overzie?
De SSL/TLS configuraties van www.triodos.nl en projects.triodos.com kunnen absoluut beter, maar met die servers worden, voor zover ik zie, geen vertrouwelijke gegevens uitgewisseld.
Gebruikersnaam en wachtwoord worden nu wel via een veilige (niet RC4) verbinding verzonden, maar daarbij wordt in een deel van de gevallen, ook als zowel de browser (MSIE11; Safari heb ik niet getest) als de server TLS v1.2 ondersteunen, een TLS v1.0 verbinding gebruikt met TLS_RSA_WITH_AES_256_CBC_SHA.
Voor een up-to-date browser die ongevoelig is voor de BEAST attack is dat prima, maar gebruikers van oudere browsers zouden zo wel risico kunnen lopen. Niet doen dus, zorg dat je een recente en qua patches up-to-date webbrowser gebruikt voor internetbankieren!
Helaas geeft Firefox niet de TLS/SSL versie weer, dat bemoeilijkt het vergelijken van de resultaten.
Met IE11 op Windows 7 met TLS 1.2 enabled, staat bankieren.triodos.nl inderdaad bij mij ook TLS 1.0:
(AES with 256 bit encryption (High); RSA with 2048 bit exchange)
en bij https://colabora.greenpeace.es/ TLS 1.2:
(AES with 256 bit encryption (High); ECDH_P256 with 256 bit exchange)
Wanneer ik alleen TLS 1.2 of alleen TLS 1.1 en 1.2 aanzet in IE, mislukt de verbinding.
Als ik dit ook met Firefox 33 probeer krijg ik dezelfde resultaten.
Ter verduidelijking van mijn reactie van 12:07; de pogingen om te verbinden met TLS 1.1 en 1.2 gingen over bankieren.triodos.nl
25-10-2014, 01:06 door
Erik van Straten
Door cluc-cluc: Dus een niet-gepatchte "TLSv1.0 -only" browser die voorheen nog vanaf de serverzijde was beschermd tegen BEAST (door RC4 te gebruiken) is hiertegen niet langer beschermd als RC4 te riskant wordt geacht om nog langer te gebruiken.
Over welke browser(s) heb je het precies?
25-10-2014, 13:48 door
bollie
Ik zie mezelf als een redelijke leek op dit gebied, maar dankzij de heldere uitleg van je, Erik, kan ik min of meer begrijpen waar het over gaat. Hulde voor dit begrijpelijke en volgens mij broodnodige artikel. Goede informatie op een heldere manier uitleggen zodat de pijnpunten duidelijk naar voren komen, kan bepaald niet iedereen in deze tijd, waar veel schrijverij geregeerd wordt door slogans en oppervlakkige kreten.
01:06 door Erik van Straten:
en niet iedere internetter heeft de middelen of de behoefte om zichzelf te voorzien van de nieuwste technologieën.
Tegelijk denk ik ook nog steeds aan systemen die om één of andere reden simpelweg niet gepatcht zijn (hoewel er een patch bestaat) of waar de patch om één of andere reden niet is geactiveerd. (iOS? (iPad/iPhone) en Safari?)
Er blijkt namelijk uit https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat:
But one platform held back - Apple's.
We know little about their intentions, because there hasn't been any official communication on this topic.
My understanding is that the 1/n-1 split was incorporated in the Mountain Lion release, but that it is disabled by default. Also, as far as I am aware, the split is not in use on iOS either.
Dit zijn systemen die nog niet erg oud zijn.
In essentie laat men hier dan een kwetsbaarheid bestaan die iemand morgen op één of andere manier weet uit te buiten.
Eventueel kunnen er nog andere kwetsbare situaties zijn, waar we op dit moment niet zo snel aan denken.
Waar het om gaat is, dat alle twijfels t.a.v. dit soort gevallen nu niet meer kunnen worden weggenomen met het simpel opdringen van RC4 vanaf de serverkant, zoals men de laatste jaren gewend was.
Als een client nu "in gebreke blijft" t.a.v. bescherming tegen BEAST, dan kan de bank hen daartegen niet meer eenvoudig beschermen door middel van het opdringen van RC4-ciphers.
Mvg, cluc-cluc
P.S.:
Het zou misschien handig zijn om te kunnen testen of men wel of niet een voor BEAST kwetsbare browser heeft. (een website als "https://www.howsmyssl.com/" controleert volgens mij helaas alleen op TLS-versie, en niet op 1/n-1 patch???)
Over welke browser(s) heb je het precies?
Hierbij denk ik niet direct aan hele specifieke browsers, maar ik verwacht dat ik waarschijnlijk onvoldoende weet van wat er in de praktijk in het veld allemaal rondspookt aan apparaten en configuraties. Want niet iedere internetter is IT-expert,en niet iedere internetter heeft de middelen of de behoefte om zichzelf te voorzien van de nieuwste technologieën.
Tegelijk denk ik ook nog steeds aan systemen die om één of andere reden simpelweg niet gepatcht zijn (hoewel er een patch bestaat) of waar de patch om één of andere reden niet is geactiveerd. (iOS? (iPad/iPhone) en Safari?)
Er blijkt namelijk uit https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat:
But one platform held back - Apple's.
We know little about their intentions, because there hasn't been any official communication on this topic.
My understanding is that the 1/n-1 split was incorporated in the Mountain Lion release, but that it is disabled by default. Also, as far as I am aware, the split is not in use on iOS either.
Dit zijn systemen die nog niet erg oud zijn.
In essentie laat men hier dan een kwetsbaarheid bestaan die iemand morgen op één of andere manier weet uit te buiten.
Eventueel kunnen er nog andere kwetsbare situaties zijn, waar we op dit moment niet zo snel aan denken.
Waar het om gaat is, dat alle twijfels t.a.v. dit soort gevallen nu niet meer kunnen worden weggenomen met het simpel opdringen van RC4 vanaf de serverkant, zoals men de laatste jaren gewend was.
Als een client nu "in gebreke blijft" t.a.v. bescherming tegen BEAST, dan kan de bank hen daartegen niet meer eenvoudig beschermen door middel van het opdringen van RC4-ciphers.
Mvg, cluc-cluc
P.S.:
Het zou misschien handig zijn om te kunnen testen of men wel of niet een voor BEAST kwetsbare browser heeft. (een website als "https://www.howsmyssl.com/" controleert volgens mij helaas alleen op TLS-versie, en niet op 1/n-1 patch???)
25-10-2014, 19:59 door
Erik van Straten
Door cluc-cluc: Er blijkt namelijk uit https://community.qualys.com/blogs/securitylabs/2013/09/10/is-beast-still-a-threat:
But one platform held back - Apple's.
We know little about their intentions, because there hasn't been any official communication on this topic.
My understanding is that the 1/n-1 split was incorporated in the Mountain Lion release, but that it is disabled by default. Also, as far as I am aware, the split is not in use on iOS either.
In mijn artikel verwijs ik naar een follow-up post van Ivan Ristic, namelijk https://community.qualys.com/blogs/securitylabs/2013/10/31/apple-enabled-beast-mitigations-in-os-x-109-mavericks. Daaruit: But one platform held back - Apple's.
We know little about their intentions, because there hasn't been any official communication on this topic.
My understanding is that the 1/n-1 split was incorporated in the Mountain Lion release, but that it is disabled by default. Also, as far as I am aware, the split is not in use on iOS either.
Door Ivan Ristic op Oct 31, 2013 9:26:43 AM: Today, I was delighted to see that the code had been changed, and that the default setting had been changed from disabled to enabled, meaning that the SSL stack that ships with OS X 10.9 uses BEAST mitigations by default. To see for yourself, look for the first mention of defaultSplitDefaultValue in the source code. It's near the top of the file.
Just to be completely sure, I subsequently observed the 1/n-1 split in action using Safari 7 and Wireshark, against a server running TLS 1.0 with only a single CBC suite configured.
Vervolgens geeft Ivan Ristic instructies voor diegenen die oudere versies willen blijven draaien.Just to be completely sure, I subsequently observed the 1/n-1 split in action using Safari 7 and Wireshark, against a server running TLS 1.0 with only a single CBC suite configured.
Jammer dat je geen concreet voorbeeld hebt, want dan zou je een concreet argument hebben om RC4 (als least preferred cipher) te blijven ondersteunen.
@ Erik van Straten
Alleen dit lijkt mij nog geen garantie dat iedereen in Nederland voor internetbankieren nu alleen systemen gebruikt die niet meer kwetsbaar zijn voor BEAST?... (incl. alle smartphones, tablets etc. van allerhande merken en leeftijden)
En hoe moet JmdP bijv. weten dat men de patch in Mountain Lion zou moeten aanzetten?
Of zoals Ivan Ristic daar ook antwoordt op een vraag over de policy om niet direct naar nieuwere versies te migreren:
"Yes, those who are using older browsers and/or unpatched systems might still be vulnerable...
(trouwens wel een idee om die n/n-1 patch te controleren met Wireshark als je niet weet of iets wel of niet is gepatcht)
Mvg, cluc-cluc.
Door Ivan Ristic op Oct 31, 2013 9:26:43 AM: Today, I was delighted to see that the code had been changed etc.
O ja. Dat is waar ook. Dank je. ;-)Alleen dit lijkt mij nog geen garantie dat iedereen in Nederland voor internetbankieren nu alleen systemen gebruikt die niet meer kwetsbaar zijn voor BEAST?... (incl. alle smartphones, tablets etc. van allerhande merken en leeftijden)
En hoe moet JmdP bijv. weten dat men de patch in Mountain Lion zou moeten aanzetten?
Of zoals Ivan Ristic daar ook antwoordt op een vraag over de policy om niet direct naar nieuwere versies te migreren:
"Yes, those who are using older browsers and/or unpatched systems might still be vulnerable...
(trouwens wel een idee om die n/n-1 patch te controleren met Wireshark als je niet weet of iets wel of niet is gepatcht)
Mvg, cluc-cluc.
27-10-2014, 12:53 door
dutchfish
Beste Eric,
Erg goed bezig! Dank je.
Erg goed bezig! Dank je.
Wat mij hier vooral tegen de borst stuit is dat wanneer je compliant wil zijn met DigiD je als aanbieder geen RC4 mag gebruiken (bron: NCSC ICT-beveiligingsrichtlijnen voor webapplicaties).
Hetzelfde met banken; wil je compliant zijn met PCI-DSS (Payment Card Industry) dan is RC4 ook een mooie showstopper mocht dit tijdens een audit boven komen.
Als zowel overheid als de bancaire wereld zulke harde eisen heeft, waarom streven zij deze dan niet na?
Er zijn genoeg documenten waaruit blijkt dat je een groot risico loopt wanneer je deze ouwe meuk (want dat is het) niet heel snel met pensioen stuurt wat vaak niet eens zoveel impact geeft om uit te voeren.
Ik zie toevallig zojuist bij de ING een nieuwsbericht: https://www.ing.nl/de-ing/veilig-bankieren/belangrijke-mededelingen/oude-besturingssystemen-om-veiligheidsredenen-niet-langer-ondersteund.html
Hetzelfde met banken; wil je compliant zijn met PCI-DSS (Payment Card Industry) dan is RC4 ook een mooie showstopper mocht dit tijdens een audit boven komen.
Als zowel overheid als de bancaire wereld zulke harde eisen heeft, waarom streven zij deze dan niet na?
Er zijn genoeg documenten waaruit blijkt dat je een groot risico loopt wanneer je deze ouwe meuk (want dat is het) niet heel snel met pensioen stuurt wat vaak niet eens zoveel impact geeft om uit te voeren.
Ik zie toevallig zojuist bij de ING een nieuwsbericht: https://www.ing.nl/de-ing/veilig-bankieren/belangrijke-mededelingen/oude-besturingssystemen-om-veiligheidsredenen-niet-langer-ondersteund.html
01-11-2014, 10:50 door
ChrisH
[Verwijderd]
Ik zie toevallig zojuist bij de ING een nieuwsbericht: https://www.ing.nl/de-ing/veilig-bankieren/belangrijke-mededelingen/oude-besturingssystemen-om-veiligheidsredenen-niet-langer-ondersteund.html
Ik zie in dit bericht van ing nog wel deze onnozele zin staan:"Voor PC-gebruikers op Windows op Windows 7, of Windows 8:" etc.
(mis ik achter het eerste "Windows" misschien het woordje "Vista"? Of bedoelt men iets anders?)
Hopelijk zijn hun banking-apps zorgvuldiger geprogrammeerd.
Ik heb mijn oorspronkelijke artikel aangevuld met een status-update.
Triodos: helaas heeft zij RC4 weer "in ere" hersteld en deze ook weer als voorkeurscipher geconfigureerd. Slechte zaak.
KPN heeft haar leven gebeterd, maar ondersteunt nog slechts TLS v1.0. Jammer dat een belangrijke huisleverancier van de overheid (o.a. PKI Overheid certificaten) nog zo achterloopt op haar eigen main site.
Verder zijn er bij enkele andere sites wijzigingen doorgevoerd, maar bij allen (op KPN na) wordt RC4 als voorkeur gegeven, waardoor verreweg de meeste verbindingen van RC4 gebruik zullen maken (check maar met je eigen webbrowser, het kost meestal maar 2 klikken).
De documenten bevatten wel zinvolle informatie (hoewel er altijd zaken zijn waarover je van mening kunt verschillen).
Triodos: helaas heeft zij RC4 weer "in ere" hersteld en deze ook weer als voorkeurscipher geconfigureerd. Slechte zaak.
KPN heeft haar leven gebeterd, maar ondersteunt nog slechts TLS v1.0. Jammer dat een belangrijke huisleverancier van de overheid (o.a. PKI Overheid certificaten) nog zo achterloopt op haar eigen main site.
Verder zijn er bij enkele andere sites wijzigingen doorgevoerd, maar bij allen (op KPN na) wordt RC4 als voorkeur gegeven, waardoor verreweg de meeste verbindingen van RC4 gebruik zullen maken (check maar met je eigen webbrowser, het kost meestal maar 2 klikken).
Door ChrisH: Wat mij hier vooral tegen de borst stuit is dat wanneer je compliant wil zijn met DigiD je als aanbieder geen RC4 mag gebruiken (bron: NCSC ICT-beveiligingsrichtlijnen voor webapplicaties).
In geen van de 4 PDF's te downloaden uit https://www.ncsc.nl/dienstverlening/expertise-advies/kennisdeling/whitepapers/ict-beveiligingsrichtlijnen-voor-webapplicaties.html kan ik concrete aanwijzingen vinden over wel en niet te gebruiken ciphers (termen als "AES" en "RC4" komen er niet in voor, wel "SSL" en "TLS"). Overigens snap ik niet waarom NCSC zowel "leesversies" als "printversies" publiceert, erg verwarrend (ik zou d eprintversies gebruiken).De documenten bevatten wel zinvolle informatie (hoewel er altijd zaken zijn waarover je van mening kunt verschillen).
02-11-2014, 18:50 door
Erik van Straten
Op de voorpagina van https://www.alertonline.nl/ vond ik:
Ook op de voorpagina van https://www.ncsc.nl/ staat een verwijzing naar:
2) Ik ben benieuwd! We blijven de ontwikkelingen volgen...
3): Zoals ik in mijn vorige bijdrage schreef, hier staat niets in over ciphers (zoals RC4 e.d.). De documenten zijn overigens van 2012-01-30, dus dat kan ook haast niet (toen werd RC4 nog als redelijk veilig verondersteld).
Overigens, in http://www.cip-overheid.nl/wp-content/uploads/2014/10/Grip-op-SSD-Beveiligingseisen-v2_0.pdf van 2014-10-05 gepubliceerd door CIP (Centrum Informatiebeveiliging en Privacybescherming, opgezet door de Belastingdienst, DUO, SVB en UWV en komt voort uit het programma Compacte Rijksdienst) staat onder meer:
NCSC publiceert factsheet HTTPS
De link verwijst naar https://www.alertonline.nl/nieuws/nieuws/ncsc-publiceert-factsheet-https.aspx?cp=135&cs=68020 met een verwijzing naar een lokale PDF, identiek aan de huidige bij NCSC (risico: NCSC update dat document, op alertonline blijft dan mogelijk een oude versie staan. Waarom nou niet verwijzen naar de NCSC pagina?)Ook op de voorpagina van https://www.ncsc.nl/ staat een verwijzing naar:
Nieuw factsheet: HTTPS kan een stuk veiliger
met link: https://www.ncsc.nl/actueel/nieuwsberichten/nieuw-factsheet-https-kan-een-stuk-veiliger.html. In die pagina staat de onderste regel in een klein, grijs, lettertype. Het woord "factsheet" heeft een iets afwijkende kleur (geen ondersterping o.i.d.). Het lijkt wel of NCSC niet wil dat je verder zoekt, maar onder dat woord "factsheet" zit een clickable naar https://www.ncsc.nl/dienstverlening/expertise-advies/factsheets/factsheet-https-kan-een-stuk-veiliger.html. Uit die pagina (herschreven door mij): 2014-10-30 door NCSC:
[...]
1) Factsheet HTTPS kan een stuk veiliger
[...]
In deze factsheet worden drie HTTPS-opties uitgelicht die een belangrijke bijdrage kunnen leveren aan het beveiligen van webverkeer. Deze opties zijn aanvullingen op bestaande adviezen over het veilig configureren van HTTPS. Het NCSC adviseert om deze opties toe te passen in al uw HTTPS-configuraties.
[...]
Wilt u een website beveiligen met HTTPS, dan vindt u configuratieadvies in de ICT-beveiligingsrichtlijnen voor Transport Layer Security en de ICT-beveiligingsrichtlijnen voor webapplicaties van het NCSC.
2) De richtlijnen voor Transport Layer Security zullen volgende week worden gepubliceerd.
3) Web Application Security
De richtlijnen voor webapplicaties zijn te vinden op onze website (https://www.ncsc.nl/dienstverlening/expertise-advies/kennisdeling/whitepapers/ict-beveiligingsrichtlijnen-voor-webapplicaties.html).
1) Download
Factsheet HTTPS kan een stuk veiliger
PDF, klik op de titel om te openen | 282,62 kB
(https://www.ncsc.nl/binaries/content/documents/ncsc-nl/dienstverlening/expertise-advies/kennisdeling/factsheets/factsheet-https-kan-een-stuk-veiliger/1/Factsheet%2BHTTPS%2Bkan%2Been%2Bstuk%2Bveiliger.pdf)
1): Dit document pleit voor het inzetten van HSTS, Forward Secrecy (door sommigen aangeduid met PFS) en certificaten die van SHA-2 hashes gebruik maken (geen SHA-1 meer). Goed dat dit document er is, maar ik ben vooral benieuwd naar het aangekondigde document![...]
1) Factsheet HTTPS kan een stuk veiliger
[...]
In deze factsheet worden drie HTTPS-opties uitgelicht die een belangrijke bijdrage kunnen leveren aan het beveiligen van webverkeer. Deze opties zijn aanvullingen op bestaande adviezen over het veilig configureren van HTTPS. Het NCSC adviseert om deze opties toe te passen in al uw HTTPS-configuraties.
[...]
Wilt u een website beveiligen met HTTPS, dan vindt u configuratieadvies in de ICT-beveiligingsrichtlijnen voor Transport Layer Security en de ICT-beveiligingsrichtlijnen voor webapplicaties van het NCSC.
2) De richtlijnen voor Transport Layer Security zullen volgende week worden gepubliceerd.
3) Web Application Security
De richtlijnen voor webapplicaties zijn te vinden op onze website (https://www.ncsc.nl/dienstverlening/expertise-advies/kennisdeling/whitepapers/ict-beveiligingsrichtlijnen-voor-webapplicaties.html).
1) Download
Factsheet HTTPS kan een stuk veiliger
PDF, klik op de titel om te openen | 282,62 kB
(https://www.ncsc.nl/binaries/content/documents/ncsc-nl/dienstverlening/expertise-advies/kennisdeling/factsheets/factsheet-https-kan-een-stuk-veiliger/1/Factsheet%2BHTTPS%2Bkan%2Been%2Bstuk%2Bveiliger.pdf)
2) Ik ben benieuwd! We blijven de ontwikkelingen volgen...
3): Zoals ik in mijn vorige bijdrage schreef, hier staat niets in over ciphers (zoals RC4 e.d.). De documenten zijn overigens van 2012-01-30, dus dat kan ook haast niet (toen werd RC4 nog als redelijk veilig verondersteld).
Overigens, in http://www.cip-overheid.nl/wp-content/uploads/2014/10/Grip-op-SSD-Beveiligingseisen-v2_0.pdf van 2014-10-05 gepubliceerd door CIP (Centrum Informatiebeveiliging en Privacybescherming, opgezet door de Belastingdienst, DUO, SVB en UWV en komt voort uit het programma Compacte Rijksdienst) staat onder meer:
Schakel cipher suites uit met de volgende elementen: ADH (Anonymous Diffie-Hellman), NULL (biedt geen versleuteling), EXPORT (biedt onvoldoende veilig-heid), RC4 en DES.
Dit document en een aantal andere vind je in http://www.cip-overheid.nl/downloads/grip-op-ssd/ (SSD = Secure Software Development).18:50 door Erik van Straten:
is 168-bits 3DES (vaak aangeduid met 112 bits) nog steeds veilig genoeg in systemen die gepatcht zijn voor BEAST.
Het gaat daar dus volgens mij alleen over DES-ciphers die als "enkele DES" door het leven gingen,
zoals EDH-RSA-DES-CBC-SHA, EDH-DSS-DES-CBC-SHA, DES-CBC-SHA en DES-CBC-MD5 e.d.
Maar het betreft volgens mij niet de ciphers waar 3DES (soms aangeduid met DES in combinatie met CBC3) in voorkomt.
Mvg, cluc-cluc
P.S.: lees omtrent één van de oorzaken van de huidige hardnekkige populariteit van RC4 ook eens:
http://op-co.de/blog/posts/android_ssl_downgrade/
"Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010"
Als je leest waar die RC4 voorkeur oorspronkelijk vandaan lijkt te komen, dan wil niemand "never ever" RC4 meer! ;-)
(om van je stoel te vallen...)
2014-10-05 gepubliceerd door CIP (Centrum Informatiebeveiliging en Privacybescherming:
Schakel cipher suites uit met de volgende elementen: ADH (Anonymous Diffie-Hellman), NULL (biedt geen versleuteling), EXPORT (biedt onvoldoende veilig-heid), RC4 en DES.
Even voor de duidelijkheid: hierbij aangenomen dat "3DES" (3-voudig DES) niet onder "DES" valt. Voor zover ik weet, Schakel cipher suites uit met de volgende elementen: ADH (Anonymous Diffie-Hellman), NULL (biedt geen versleuteling), EXPORT (biedt onvoldoende veilig-heid), RC4 en DES.
is 168-bits 3DES (vaak aangeduid met 112 bits) nog steeds veilig genoeg in systemen die gepatcht zijn voor BEAST.
Het gaat daar dus volgens mij alleen over DES-ciphers die als "enkele DES" door het leven gingen,
zoals EDH-RSA-DES-CBC-SHA, EDH-DSS-DES-CBC-SHA, DES-CBC-SHA en DES-CBC-MD5 e.d.
Maar het betreft volgens mij niet de ciphers waar 3DES (soms aangeduid met DES in combinatie met CBC3) in voorkomt.
Mvg, cluc-cluc
P.S.: lees omtrent één van de oorzaken van de huidige hardnekkige populariteit van RC4 ook eens:
http://op-co.de/blog/posts/android_ssl_downgrade/
"Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010"
Als je leest waar die RC4 voorkeur oorspronkelijk vandaan lijkt te komen, dan wil niemand "never ever" RC4 meer! ;-)
(om van je stoel te vallen...)
Door cluc-cluc: Voor zover ik weet, is 168-bits 3DES (vaak aangeduid met 112 bits) nog steeds veilig genoeg in systemen die gepatcht zijn voor BEAST.
Nee, niet "veilig genoeg", hooguit "acceptabel indien niets anders ondersteund wordt" (mag dus geen voorkeur cipher suite zijn). Bijv. ENISA onderscheidt (stand oktober 2013) 3 categoriën "crypto" (zie https://www.security.nl/posting/368445/):1) Legacy [X] Attack exists or security considered not sufficient. Should be replaced [...] as a matter of urgency.
2) Legacy [V] No known weaknesses at present. Better alternatives exist. Lack of security proof or limited key size.
3) Future [V] Mechanism is well studied (often with security proof). Expected to remain secure in 10-50 years.
RC4 is categorie 1, 3DES is categorie 2 (omdat de effectieve sleutellengte maximaal 112 bits is, aldus ENISA).
Uit PDF http://www.enisa.europa.eu/activities/identity-and-trust/library/deliverables/algorithms-key-sizes-and-parameters-report/at_download/fullReport, onder bovenstaand tabelletje (onderstrepen heb ik gedaan):
Door ENISA, Oktober 2013: As a general rule of thumb we consider symmetric 80-bit security levels to be sufficient for legacy applications for the coming years, but consider 128-bit security levels to be the minimum requirement for new systems being deployed. Thus the key recommendation is that decision makers now make plans and preparations for the phasing out of what we term legacy mechanisms over a period of say 5-10 years. In selecting key sizes for future applications we consider 128-bit to be sufficient for all but the most sensitive applications. Thus we make no distinction between high-grade security and low-grade security, since 128-bit encryption is probably secure enough in the near term.
However, one needs to also take into account the length of time data needs to be kept secure for. For example it may well be appropriate to use 80-bit encryption into the near future for transactional data, i.e. data which only needs to be kept secret for a very short space of time; but to insist on 128-bit encryption for long lived data. All recommendations in this document need to be read with this in mind.
Aangezien ik niet verwacht dat mensen wachtwoorden voor sites zoals digid.nl vaak zullen wijzigen, lijkt mij 128bits voor dat soort sites het minimum; 3DES toestaan is dan een noodgreep. Waarbij ik persoonlijk vind dat je mensen tegen zichzelf zou moeten beschermen door ze niet toe te staan op digid.nl in te loggen met verouderde software.However, one needs to also take into account the length of time data needs to be kept secure for. For example it may well be appropriate to use 80-bit encryption into the near future for transactional data, i.e. data which only needs to be kept secret for a very short space of time; but to insist on 128-bit encryption for long lived data. All recommendations in this document need to be read with this in mind.
Vanuit jouw perspectief wellicht interessant: NIST stelt 112 bits crypto als minimum (vanwege 3DES?), en stelt 3DES zelfs verplicht, maar beroept zich daarbij op een statement in RFC4346 uit 2006. Uit http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-52r1.pdf:
NIST Guidelines for TLS Implementations, April 2014:
[...]
These guidelines focus on the common use where clients and servers must interoperate with a wide variety of implementations, and authentication is performed using public key certificates. To promote interoperability, these guidelines (and the RFCs that define the TLS protocol) establish mandatory features and cipher suites that conforming implementations must support. There are, however, much more constrained implementations of TLS servers, where security is needed, but broad interoperability is not required and the cost of implementing unused features may be prohibitive.
[...]
In order to maximize interoperability, TLS server implementations shall support the following cipher suites:
• TLS_RSA_WITH_3DES_EDE_CBC_SHA [13]
• TLS_RSA_WITH_AES_128_CBC_SHA
In addition, TLS server implementations should support the following cipher suites:
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
[13] Support of this cipher suite is mandatory for TLS 1.1 [RFC4346]
[...]
RC4 is not an Approved algorithm.
[...]
Echter, RFC4346 is daar helemaal niet zo stellig over als NIST suggereert, uit http://tools.ietf.org/html/rfc4346#section-9: [...]
These guidelines focus on the common use where clients and servers must interoperate with a wide variety of implementations, and authentication is performed using public key certificates. To promote interoperability, these guidelines (and the RFCs that define the TLS protocol) establish mandatory features and cipher suites that conforming implementations must support. There are, however, much more constrained implementations of TLS servers, where security is needed, but broad interoperability is not required and the cost of implementing unused features may be prohibitive.
[...]
In order to maximize interoperability, TLS server implementations shall support the following cipher suites:
• TLS_RSA_WITH_3DES_EDE_CBC_SHA [13]
• TLS_RSA_WITH_AES_128_CBC_SHA
In addition, TLS server implementations should support the following cipher suites:
• TLS_RSA_WITH_AES_256_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA
• TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA
• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
[13] Support of this cipher suite is mandatory for TLS 1.1 [RFC4346]
[...]
RC4 is not an Approved algorithm.
[...]
Door IETF, April 2006:
9. Mandatory Cipher Suites
In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
Hoewel er verschillende updated RFC's bestaan (bijv. RFC6176 verbiedt SSLv2), is er, voor zover ik weet, (nog) geen RFC die iets over het uitfaseren van 3DES vermeldt. Anderen zijn daar weer duidelijker over, zie bijv. http://www.cisco.com/web/about/security/intelligence/nextgen_crypto.html (eveneens uit april 2014). En de Duitse BSI gaat nog een stuk verder (RC4 is taboe; overheidsprojecten mogen 3DES niet meer gebruiken en support voor TLS v1.2 is verplicht).9. Mandatory Cipher Suites
In the absence of an application profile standard specifying otherwise, a TLS compliant application MUST implement the cipher suite TLS_RSA_WITH_3DES_EDE_CBC_SHA.
Door cluc-cluc: P.S.: lees omtrent één van de oorzaken van de huidige hardnekkige populariteit van RC4 ook eens:
http://op-co.de/blog/posts/android_ssl_downgrade/
"Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010"
Als je leest waar die RC4 voorkeur oorspronkelijk vandaan lijkt te komen, dan wil niemand "never ever" RC4 meer! ;-)
(om van je stoel te vallen...)
Dank! In mei dit jaar heb ik veel gegoogled naar RC4 en vond toen ook die pagina, maar het was goed om deze weer even te bekijken.http://op-co.de/blog/posts/android_ssl_downgrade/
"Why Android SSL was downgraded from AES256-SHA to RC4-MD5 in late 2010"
Als je leest waar die RC4 voorkeur oorspronkelijk vandaan lijkt te komen, dan wil niemand "never ever" RC4 meer! ;-)
(om van je stoel te vallen...)
Interessant is dat die pagina verwijst naar https://news.ycombinator.com/item?id=6548545 waarin Thomas Ptacek (Matasano Security) uitlegt dat MD5 in TLS cipher suites (zoals TLS_RSA_WITH_RC4_128_MD5) minder risicovol is dan mensen denken, omdat binnen TLS van HMAC-MD5 gebruik gemaakt wordt: "Nobody would recommend HMAC-MD5 for use in a new system, but it has not been broken." Ik wist dat ik dat ergens gelezen had, maar kon dat niet meer vinden. Zie ook https://en.wikipedia.org/wiki/Transport_Layer_Security#Data_integrity.
Door Erik van Straten:
Interessant is dat die pagina verwijst naar https://news.ycombinator.com/item?id=6548545 waarin Thomas Ptacek (Matasano Security) uitlegt dat MD5 in TLS cipher suites (zoals TLS_RSA_WITH_RC4_128_MD5) minder risicovol is dan mensen denken, omdat binnen TLS van HMAC-MD5 gebruik gemaakt wordt: "Nobody would recommend HMAC-MD5 for use in a new system, but it has not been broken." Ik wist dat ik dat ergens gelezen had, maar kon dat niet meer vinden. Zie ook https://en.wikipedia.org/wiki/Transport_Layer_Security#Data_integrity.
Toevallig heb ik dat laatst ook ergens gelezen over HMAC hashes, maar dat ging over het risico HMAC-SHA1 tegenover HMAC-SHA256/384, en dat dat dus daarom wel meevalt en nog te gebruiken is.Interessant is dat die pagina verwijst naar https://news.ycombinator.com/item?id=6548545 waarin Thomas Ptacek (Matasano Security) uitlegt dat MD5 in TLS cipher suites (zoals TLS_RSA_WITH_RC4_128_MD5) minder risicovol is dan mensen denken, omdat binnen TLS van HMAC-MD5 gebruik gemaakt wordt: "Nobody would recommend HMAC-MD5 for use in a new system, but it has not been broken." Ik wist dat ik dat ergens gelezen had, maar kon dat niet meer vinden. Zie ook https://en.wikipedia.org/wiki/Transport_Layer_Security#Data_integrity.
HMAC-MD5 mag dan wel veiliger zijn dan MD5, maar wat mij betreft kan het het beste zo snel mogelijk uitgefaseerd worden.
Kortom: het hangt er maar net vanaf wat je precies verstaat onder "veilig genoeg". ;-)
Volgens wikipedia zou 3DES standhouden tot aan het jaar 2030. (een inschatting natuurlijk)
Trouwens SSLLABS heeft kort geleden eens het volgende rijtje ciphers van een website aan mij gedemonstreerd:
Cipher Suites (sorted by strength; the server has no preference)
TLS_RSA_WITH_RC4_128_MD5 (0x4) 128
TLS_RSA_WITH_RC4_128_SHA (0x5) 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits (p: 128, g: 1, Ys: 128) FS 128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41) 128
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45) DH 1024 bits (p: 128, g: 1, Ys: 128) FS 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 1024 bits (p: 128, g: 1, Ys: 128) FS 112
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits (p: 128, g: 1, Ys: 128) FS 256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) 256
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88) DH 1024 bits (p: 128, g: 1, Ys: 128) FS 256
Wat je in deze "sorted by strength" cipher suite lijst ziet (met de zwakste cipher bovenaan en de sterkste onderaan),
is dat het 112 bits TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) kennelijk sterker is dan
128 bits TLS_RSA_WITH_AES_128_CBC_SHA (0x2f).
Leg mij dat eens uit, en waarom zou je hier die sterkere 112 bits 3DES uit deze lijst gooien en die 128 bits AES niet? ;-)
(helaas heeft die betreffende website nu niet meer "sorted by strength" maar "server preferred" ciphers,
en ik heb even geen tijd om een soortgelijk bestaand concreet voorbeeld "sorted by strength" te vinden.
Maar die zal er ongetwijfeld zijn!)
Mvg,cluc-cluc
Volgens wikipedia zou 3DES standhouden tot aan het jaar 2030. (een inschatting natuurlijk)
Trouwens SSLLABS heeft kort geleden eens het volgende rijtje ciphers van een website aan mij gedemonstreerd:
Cipher Suites (sorted by strength; the server has no preference)
TLS_RSA_WITH_RC4_128_MD5 (0x4) 128
TLS_RSA_WITH_RC4_128_SHA (0x5) 128
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 1024 bits (p: 128, g: 1, Ys: 128) FS 128
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA (0x41) 128
TLS_DHE_RSA_WITH_CAMELLIA_128_CBC_SHA (0x45) DH 1024 bits (p: 128, g: 1, Ys: 128) FS 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x16) DH 1024 bits (p: 128, g: 1, Ys: 128) FS 112
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 1024 bits (p: 128, g: 1, Ys: 128) FS 256
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA (0x84) 256
TLS_DHE_RSA_WITH_CAMELLIA_256_CBC_SHA (0x88) DH 1024 bits (p: 128, g: 1, Ys: 128) FS 256
Wat je in deze "sorted by strength" cipher suite lijst ziet (met de zwakste cipher bovenaan en de sterkste onderaan),
is dat het 112 bits TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) kennelijk sterker is dan
128 bits TLS_RSA_WITH_AES_128_CBC_SHA (0x2f).
Leg mij dat eens uit, en waarom zou je hier die sterkere 112 bits 3DES uit deze lijst gooien en die 128 bits AES niet? ;-)
(helaas heeft die betreffende website nu niet meer "sorted by strength" maar "server preferred" ciphers,
en ik heb even geen tijd om een soortgelijk bestaand concreet voorbeeld "sorted by strength" te vinden.
Maar die zal er ongetwijfeld zijn!)
Mvg,cluc-cluc
03-11-2014, 12:11 door
Erik van Straten
Door Anoniem: HMAC-MD5 mag dan wel veiliger zijn dan MD5, maar wat mij betreft kan het het beste zo snel mogelijk uitgefaseerd worden.
Eens, maar ik probeer zo zuiver mogelijk te waarschuwen voor kwetsbaarheden (een risico daarbij is dat ik ook niet alles weet, alleen al cryptografie is een vakgebied apart en ik ben geen cryptograaf).Als je, zoals Erik Westhovens tijdens een recente uitzending van het TV programma "opgelicht" deels onwaarheden vertelt (zie https://www.security.nl/posting/407089/PvdA+stelt+Kamervragen+over+DigiD-lek+bij+gemeenten#posting407103), is de kans groot dat niets van wat je zegt nog serieus genomen wordt. Vooral partijen die zich door jou aangevallen voelen, zijn er dan als de kippen bij om jouw hele verhaal als "stemmingmakerij" af te doen.
Eventuele gevolschade is dat volksvertegenwoordigers en journalisten, die meestal zelf nauwelijks tot niets van de materie begrijpen, een volgende keer wel drie keer nadenken voordat ze naar een "roepende in de woestijn" luisteren.
Ik besef mij dat ik daar met mijn artikel wellicht ook aan bijdraag, want (voor zover ik weet) is er nog geen eenvoudige en snelle exploit voor RC4 gepubliceerd. Ik vond het toch nodig om mijn artikel te posten, omdat veel specialisten op de risico's van RC4 wijzen en we, m.i., in onvoldoende mate verouderde cryptografie afschrijven. Pas op het moment dat een concrete exploit gepubliceerd wordt, gaan een deel van ons rennen - en de rest van de servers op internet blijft lange tijd ongepatcht, met alle risico's van dien voor nietsvermoedende gebruikers (voorbeeld: http://un1c0rn.net/search?q=heartbleed).
Door Erik van Straten: "roepende in de woestijn"
Ik volg dit topic nu al een tijdje met veel interesse, waarbij ik e.e.a. heb opgestoken van jouw commentaar, de gegeven links en het WWW zelf, waarvoor mijn oprechte dank.Dus in ieder geval één iemand heeft je gehoord en dit omgezet in actie op de werkvloer; zowel de cyphers van browser en server zijn aangepast en worden voortaan regelmatig (4x per jaar) manueel bijgewerkt.
Tot nu toe geen klachten, hooguit een iets hogere latency her en der -> work in progress...
Maar.., ik kan me voorstellen dat het bij grote netwerken allemaal een stuk minder evident is.
Niet enkel vanwege het kosten-baten plaatje, MitM is (al-dan-niet-terecht) nu eenmaal niet het eerste waar beheerders zich druk om maken, zeker ook omdat dat niet direct onder de verantwoordelijkheid (aansprakelijkheid) van de host valt.
Je uitspraak "roepende in de woestijn," dekt dan ook het best de lading, wat mij betreft.
Nogmaals, complimenten, dank en ga zo door!
03-11-2014, 15:20 door
Erik van Straten
Door Anonieme cluc-cluc: Trouwens SSLLABS heeft kort geleden eens het volgende rijtje ciphers van een website aan mij gedemonstreerd:
Cipher Suites (sorted by strength; the server has no preference)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
Wat je in deze "sorted by strength" cipher suite lijst ziet (met de zwakste cipher bovenaan en de sterkste onderaan),
is dat het 112 bits TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) kennelijk sterker is dan
128 bits TLS_RSA_WITH_AES_128_CBC_SHA (0x2f).
Leg mij dat eens uit, en waarom zou je hier die sterkere 112 bits 3DES uit deze lijst gooien en die 128 bits AES niet? ;-)
Als de server geen voorkeur geeft, sorteert SSLLabs op de "Soll" strength (3DES: 168), niet de "Ist" strength (er bestaan verschillende meningen over wat deze is, bijv. 108 of 112 bits, de meesten lijken het op 112 bits te houden).Cipher Suites (sorted by strength; the server has no preference)
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
Wat je in deze "sorted by strength" cipher suite lijst ziet (met de zwakste cipher bovenaan en de sterkste onderaan),
is dat het 112 bits TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) kennelijk sterker is dan
128 bits TLS_RSA_WITH_AES_128_CBC_SHA (0x2f).
Leg mij dat eens uit, en waarom zou je hier die sterkere 112 bits 3DES uit deze lijst gooien en die 128 bits AES niet? ;-)
Overig is "geen voorkeur" van de server vaak veiliger dan de voorkeur voor een brakke cipher zoals RC4 (mits de server daarnaast veiliger ciphers ondersteunt). Als de server geen voorkeur heeft, kiest de webbrowser, en de keuze daarvan is meestal een veilige (helaas niet altijd, zie http://op-co.de/blog/posts/android_ssl_downgrade/ waar jij eerder naar verwees).
Een voorbeeld van zo'n server (d.w.z. zonder preference) is https://www.ssllabs.com/ssltest/analyze.html?d=wisseljewachtwoord.nl (de 40 bit ciphers komen vóór de 56 bit ciphers - wisseljebeheerder was een betere naam geweest ;)
Door Anoniem 13:15: Nogmaals, complimenten, dank en ga zo door!
Graag gedaan!Door Erik van Straten:
Als je, zoals Erik Westhovens tijdens een recente uitzending van het TV programma "opgelicht" deels onwaarheden vertelt (zie https://www.security.nl/posting/407089/PvdA+stelt+Kamervragen+over+DigiD-lek+bij+gemeenten#posting407103), is de kans groot dat niets van wat je zegt nog serieus genomen wordt. Vooral partijen die zich door jou aangevallen voelen, zijn er dan als de kippen bij om jouw hele verhaal als "stemmingmakerij" af te doen.
Eventuele gevolschade is dat volksvertegenwoordigers en journalisten, die meestal zelf nauwelijks tot niets van de materie begrijpen, een volgende keer wel drie keer nadenken voordat ze naar een "roepende in de woestijn" luisteren.
Ik besef mij dat ik daar met mijn artikel wellicht ook aan bijdraag, want (voor zover ik weet) is er nog geen eenvoudige en snelle exploit voor RC4 gepubliceerd. Ik vond het toch nodig om mijn artikel te posten, omdat veel specialisten op de risico's van RC4 wijzen en we, m.i., in onvoldoende mate verouderde cryptografie afschrijven. Pas op het moment dat een concrete exploit gepubliceerd wordt, gaan een deel van ons rennen - en de rest van de servers op internet blijft lange tijd ongepatcht, met alle risico's van dien voor nietsvermoedende gebruikers (voorbeeld: http://un1c0rn.net/search?q=heartbleed).
Goed punt dat men moet blijven proberen om zo zuiver mogelijk te blijven. Ik ben het wel zeker met je laatste alinea eens. TLS 1.2 bestaat ook al weer 6 jaar, en nu pas begint het wijdverbreid ondersteund te worden. Met RC4 kunnen we beter niet nog 6 jaar wachten ;)Door Anoniem: HMAC-MD5 mag dan wel veiliger zijn dan MD5, maar wat mij betreft kan het het beste zo snel mogelijk uitgefaseerd worden.
Eens, maar ik probeer zo zuiver mogelijk te waarschuwen voor kwetsbaarheden (een risico daarbij is dat ik ook niet alles weet, alleen al cryptografie is een vakgebied apart en ik ben geen cryptograaf).Als je, zoals Erik Westhovens tijdens een recente uitzending van het TV programma "opgelicht" deels onwaarheden vertelt (zie https://www.security.nl/posting/407089/PvdA+stelt+Kamervragen+over+DigiD-lek+bij+gemeenten#posting407103), is de kans groot dat niets van wat je zegt nog serieus genomen wordt. Vooral partijen die zich door jou aangevallen voelen, zijn er dan als de kippen bij om jouw hele verhaal als "stemmingmakerij" af te doen.
Eventuele gevolschade is dat volksvertegenwoordigers en journalisten, die meestal zelf nauwelijks tot niets van de materie begrijpen, een volgende keer wel drie keer nadenken voordat ze naar een "roepende in de woestijn" luisteren.
Ik besef mij dat ik daar met mijn artikel wellicht ook aan bijdraag, want (voor zover ik weet) is er nog geen eenvoudige en snelle exploit voor RC4 gepubliceerd. Ik vond het toch nodig om mijn artikel te posten, omdat veel specialisten op de risico's van RC4 wijzen en we, m.i., in onvoldoende mate verouderde cryptografie afschrijven. Pas op het moment dat een concrete exploit gepubliceerd wordt, gaan een deel van ons rennen - en de rest van de servers op internet blijft lange tijd ongepatcht, met alle risico's van dien voor nietsvermoedende gebruikers (voorbeeld: http://un1c0rn.net/search?q=heartbleed).
Heren,
Leuk dit soort theoretische hacks, maar al deze websites zijn vulnerable for MITM attacks, op basis van sslstrip+.
Implementeer HTST HTTP Strict Transport Security en maak geen gebruik van Internet explorer dan ben je stukken veiliger.
OK RC4 is niet veilig maar, Internet Explorer 11 ook niet voor MITM attacks.
Pam
Leuk dit soort theoretische hacks, maar al deze websites zijn vulnerable for MITM attacks, op basis van sslstrip+.
Implementeer HTST HTTP Strict Transport Security en maak geen gebruik van Internet explorer dan ben je stukken veiliger.
OK RC4 is niet veilig maar, Internet Explorer 11 ook niet voor MITM attacks.
Pam
2014-11-03 17:05 door Anoniem: Heren,
Leuk dit soort theoretische hacks, maar al deze websites zijn vulnerable for MITM attacks, op basis van sslstrip+.
Implementeer HTST HTTP Strict Transport Security en maak geen gebruik van Internet explorer dan ben je stukken veiliger.
OK RC4 is niet veilig maar, Internet Explorer 11 ook niet voor MITM attacks.
Pam
De RC4 hack was anderhalf jaar geleden al niet theoretisch meer, alleen -voor zover bekend- lastig uit te voeren.Leuk dit soort theoretische hacks, maar al deze websites zijn vulnerable for MITM attacks, op basis van sslstrip+.
Implementeer HTST HTTP Strict Transport Security en maak geen gebruik van Internet explorer dan ben je stukken veiliger.
OK RC4 is niet veilig maar, Internet Explorer 11 ook niet voor MITM attacks.
Pam
Wetenschappers besteden sindsdien geen tijd meer aan RC4 (het is gebroken, geen eer meer aan te behalen), maar anderen mogelijk wel, en dat type publiceert niet. Ervan uitgaan dat cybercriminelen de aanval ondertussen niet hebben versneld is een gok. Als er geen alternatieven voor RC4 zouden zijn, had je wellicht een punt, en was die gok acceptabel.
M.b.t. sslstrip en andere social engineering aanvallen: inderdaad kun je vermoedelijk veel mensen voor de gek houden (zie http://i.imgur.com/IALiSn7.png). Echter:
1) Twee (DigiD en Triodos) van de 6 sites ondersteunen wel HSTS, en hoewel geen meerderheid, er zijn mensen die veiliger browsers gebruiken dan MSIE;
2) Voor de overige sites en MSIE gebruikers: er zijn mensen die wel goed opletten dat de URL begint met https://bedoeldesite, en er zijn er zelfs die het certificaat controleren.
Met name als aan de onderste voorwaarde wordt voldaan, werken social engineering attacks niet. Dan mag je, als zo'n gebruiker, verwachten dat de sites die ik noem hun zaken voor elkaar hebben - d.w.z. zonder dat je zelf aan (vaak verstopte) instellingen van een moderne webbrowser moet sleutelen om genoemde sites veilig te kunnen bezoeken.
Edit 2014-10-04 09:31: weken->werken
02:47 door Erik van Straten - Bijgewerkt: Gisteren, 03:00
Door cluc-cluc: Voor zover ik weet, is 168-bits 3DES (vaak aangeduid met 112 bits) nog steeds veilig genoeg in systemen die gepatcht zijn voor BEAST.
Nee, niet "veilig genoeg", hooguit "acceptabel indien niets anders ondersteund wordt" (mag dus geen voorkeur cipher suite zijn). Voor de duidelijkheid/zekerheid moet ik eerst even kwijt dat het niet mijn bedoeling is om 3DES gelijk te stellen aan de betere, modernere ciphers. Maar ik laat uitsluitend en alleen weten dat naar mijn informatie de veiligheid van 3DES op zich nog niet werkelijk in het geding is. Dit houdt in, dat als iemand de mogelijkheid heeft om andere (betere en snellere) ciphers te gebruiken, hij/zij 3DES dan natuurlijk links moet laten liggen. Maar mocht bijv. een oud systeem nieuwere ciphers niet aankunnen, dan mag men zich nog een poosje "veilig genoeg" weten bij 3DES, want deze "oude spartaan" is na vele jaren van aanvallen nog steeds niet serieus gebroken. Aldus heeft het zich voldoende bewezen dat het hoogst waarschijnlijk nog wel een paar jaar mee kan, totdat alle "oude meuk" met 3DES is vervangen, en de techniek zover is gevorderd dat een 112 bits sleutel in de praktijk echt te weinig is.
Vergeet hierbij niet dat het "brute force" raden van een sleutel van 112 bits nog altijd betekent dat men gemiddeld bijna
2.600.000.000.000.000.000.000.000.000.000.000 mogelijkheden zal moeten testen om de sleutel te achterhalen.
Volgens de geleerden is ons universum slechts ca. 430.000.000.000.000.000.000.000.000 nanoseconden (13,7 miljard jaar) oud. Dus als je elke nanoseconde één poging doet, dan ben je gemiddeld na ruim 12 miljoen keer de leeftijd van ons universum wel eens een keertje klaar... (maximaal ca. 24 miljoen keer de leeftijd van ons universum als je pech hebt).
En zelfs als de hele wereldbevolking elke nanoseconde een poging zou doen, dan nog duurt het gemiddeld meer dan 20 miljoen jaar om de sleutel te bemachtigen. (alleen of men dan nog weet wie jij was???) ;-)
15:20 door Erik van Straten:
Als de server geen voorkeur geeft, sorteert SSLLabs op de "Soll" strength (3DES: 168), niet de "Ist" strength (er bestaan verschillende meningen over wat deze is, bijv. 108 of 112 bits, de meesten lijken het op 112 bits te houden).
Als dit waar is, Erik, dan geeft SSLLABS dus niet werkelijk een tabel "sorted by strength" aan (zoals ze op het beeldscherm zeggen), maar slechts een tabel "sorted by basic key-length".Als de server geen voorkeur geeft, sorteert SSLLabs op de "Soll" strength (3DES: 168), niet de "Ist" strength (er bestaan verschillende meningen over wat deze is, bijv. 108 of 112 bits, de meesten lijken het op 112 bits te houden).
Nu is de "strength" van een cipher wel afhankelijk van die keylength (en dan vooral van de "effective keylength"
om het zo maar eens te noemen i.v.m. 3DES) maar deze keylength zegt nog niet alles over de "strength".
Want de "strength" is immers de weerstand die een cipher biedt tegen een aanval om plaintext uit de ciphertext
bloot te leggen, of om de sleutel te achterhalen!
Bij bepaling van de "strength" van een cipher spelen daarom naast sleutellengte ook zaken als encryptie-algoritme een rol. Een goed verhaal hierover vond ik hier: http://cromwell-intl.com/security/crypto/cipher-strength.html
Daar staat bovendien eenvoudig uitgelegd waarom 168-bits 3DES in de praktijk slechts 112-bit is.
Bijvoorbeeld het geplaagde 128-bits RC4 cipher heeft nog altijd een 128-bits keylength, maar haalt effectief in de praktijk beslist geen "128-bits kwaliteit" meer. (in wezen komt dit vanwege een gebleken inferieur encryptie-algoritme!)
De vraag is nu eigenlijk alleen nog maar hoe erg het in de praktijk feitelijk is.
Er valt iets voor te zeggen dat de onderzoekers die misschien in onze ogen nog slechts "relatief kleine kwetsbaarheden" in RC4 hebben aangetoond, daarmee alleen nog maar het topje van de ijsberg hebben laten zien.
Tegelijk is het moeilijk om feiten en speculaties uit elkaar te houden. Maar toch:
op zich al een reden om zoveel mogelijk uit te wijken naar andere >=128-bits ciphers die niet zo discutabel zijn!
Afijn, kortom: men zou niet zomaar de "cipher strength" moeten afmeten aan de hand van puur en alleen de key-length!.
En als jij gelijk hebt, Erik, en SSLLABS dit dus wél zou doen, dan riekt dat naar een kwalijke misleiding op dit punt van SSLLABS! En dat mag imho best wel even gezegd worden. En ik vind dat SSLLABS dit dan ook a.s.a.p. behoort aan te passen aan de waarheid. Wat jij?
15:20 door Erik van Straten:
Overig is "geen voorkeur" van de server vaak veiliger dan de voorkeur voor een brakke cipher zoals RC4 (mits de server daarnaast veiliger ciphers ondersteunt). Als de server geen voorkeur heeft, kiest de webbrowser, en de keuze daarvan is meestal een veilige (helaas niet altijd, zie http://op-co.de/blog/posts/android_ssl_downgrade/ waar jij eerder naar verwees).
Hier zet ik toch ook even ernstig wat vraagtekens bij: Overig is "geen voorkeur" van de server vaak veiliger dan de voorkeur voor een brakke cipher zoals RC4 (mits de server daarnaast veiliger ciphers ondersteunt). Als de server geen voorkeur heeft, kiest de webbrowser, en de keuze daarvan is meestal een veilige (helaas niet altijd, zie http://op-co.de/blog/posts/android_ssl_downgrade/ waar jij eerder naar verwees).
Als een server met "geen voorkeur" naast goede ciphers ook nog hele zwakke ciphers ondersteunt, dan loop je namelijk het risico bij een MITM aanval dat de aanvaller de browserdata zodanig manipuleert dat die brakke cipher wordt aangevraagd bij de server.
Vervolgens kan de aanvaller met macht over die brakke cipher alles "live" decoderen en heeft hij vrij spel.
Terwijl dus alles voor de gebruiker "normaal lijkt te werken". (slotje met https en juiste certificaat lijkt mij mogelijk).
Alleen als de client webbrowser die brakke ciphersuites niet ondersteunt, zal het zo "bijna-perfect" niet lukken.
(dat is dan weer een beschermend gelukje: recentere browsers ondersteunen die brakke zooi standaard niet meer)
Maar dit is denk ik ook hoofdzakelijk de reden dat het ondersteunen van "brakke ciphers" (40-bit, 56-bit) bij SSLLABS in de ranking wordt bestraft, zelfs ook al heeft de server "geen voorkeur" voor een bepaalde cipher, en ondersteunt hij naast de brakke ciphers ook nog sterke ciphers.
Oke, je mag in jouw stelling misschien nog net van "vaak veiliger" spreken, maar niet zonder deze kanttekening te noemen. Anders denken mensen misschien dat er geen enkel probleem is met zulke servers.
Maar er bestaat in deze situatie dus nog steeds een relevant risico van de MitM die dan dus de cipher-aanvraag van je browser aan de server kan manipuleren om een gebroken cipher te kiezen.
Ciphers die als volledig gekraakt kunnen worden beschouwd, zoals 40-bit en 56-bit ciphers, moet men daarom imho absoluut niet meer ondersteunen, tenzij het beslist niet anders kan en het weloverwogen de risico's heus waard zou zijn.
15:20 door Erik van Straten:
Een voorbeeld van zo'n server (d.w.z. zonder preference) is https://www.ssllabs.com/ssltest/analyze.html?d=wisseljewachtwoord.nl (de 40 bit ciphers komen vóór de 56 bit ciphers - wisseljebeheerder was een betere naam geweest ;)
ehm... he???... Wat bedoel je precies?Een voorbeeld van zo'n server (d.w.z. zonder preference) is https://www.ssllabs.com/ssltest/analyze.html?d=wisseljewachtwoord.nl (de 40 bit ciphers komen vóór de 56 bit ciphers - wisseljebeheerder was een betere naam geweest ;)
Servers zonder preference beginnen toch altijd met de zwakste ciphers bovenaan in SSLLABS?
Omdat SSLLABS de ondersteunde ciphers juist rangschikt op "strength" loopt het altijd van zwakste naar sterkste. ;-)
Dit wil dus niet zeggen dat zo'n server zonder preference die zwakste cipher ook als eerste aanbiedt, maar zoals je zelf al aangaf: de (cipher instellingen van de) browser van de cliënt is in zo'n geval bepalend. (-; of eventueel een MitM... ;-)
Mvg, cluc-cluc
Door Anoniem: Vergeet hierbij niet dat het "brute force" raden van een sleutel van 112 bits nog altijd betekent dat men gemiddeld bijna 2.600.000.000.000.000.000.000.000.000.000.000 ...
Dat vergeet ik wel. Je bevestigt impliciet dat ciphers nooit door slechts brute force worden gekraakt. Er is altijd (in meer of mindere mate) sprake van implementatie- en/of ontwerpfouten. Daardoor kan bijv. WEP, gebruik makend van RC4 (128 bits cipher), in enkele seconden worden gekraakt. Goochelen met astronomische getallen suggereert mogelijk onbreekbaarheid bij een deel van de lezers (daarbij misbruik makend van hun onwetendheid).Door Anoniem: Afijn, kortom: men zou niet zomaar de "cipher strength" moeten afmeten aan de hand van puur en alleen de key-length!.
En als jij gelijk hebt, Erik, en SSLLABS dit dus wél zou doen, dan riekt dat naar een kwalijke misleiding op dit punt van SSLLABS! En dat mag imho best wel even gezegd worden. En ik vind dat SSLLABS dit dan ook a.s.a.p. behoort aan te passen aan de waarheid. Wat jij?
De volgorde in de webpagina is totaal irrelevant als de serverbeheerder geen voorkeurvolgorde heeft geconfigureerd. Het lijstje had net zo goed op alfabet gesorteerd kunnen zijn, of op geboorteddaum van de uitvinder van de cipher. Toevallig kiest SSLlabs ervoor om te sorteren op de geadverteerde sleutellengte.En als jij gelijk hebt, Erik, en SSLLABS dit dus wél zou doen, dan riekt dat naar een kwalijke misleiding op dit punt van SSLLABS! En dat mag imho best wel even gezegd worden. En ik vind dat SSLLABS dit dan ook a.s.a.p. behoort aan te passen aan de waarheid. Wat jij?
Jij probeert er iets uit te lezen. Doe dat niet: daar bestaat betere informatie voor. Bijv. https://wiki.mozilla.org/Security/Server_Side_TLS of het maandag gepubliceerde NCSC document.
Door Anoniem:
Als een server met "geen voorkeur" naast goede ciphers ook nog hele zwakke ciphers ondersteunt, dan loop je namelijk het risico bij een MITM aanval dat de aanvaller de browserdata zodanig manipuleert dat die brakke cipher wordt aangevraagd bij de server.
15:20 door Erik van Straten:
Overig is "geen voorkeur" van de server vaak veiliger dan de voorkeur voor een brakke cipher zoals RC4 (mits de server daarnaast veiliger ciphers ondersteunt). Als de server geen voorkeur heeft, kiest de webbrowser, en de keuze daarvan is meestal een veilige (helaas niet altijd, zie http://op-co.de/blog/posts/android_ssl_downgrade/ waar jij eerder naar verwees).
Hier zet ik toch ook even ernstig wat vraagtekens bij: Overig is "geen voorkeur" van de server vaak veiliger dan de voorkeur voor een brakke cipher zoals RC4 (mits de server daarnaast veiliger ciphers ondersteunt). Als de server geen voorkeur heeft, kiest de webbrowser, en de keuze daarvan is meestal een veilige (helaas niet altijd, zie http://op-co.de/blog/posts/android_ssl_downgrade/ waar jij eerder naar verwees).
Als een server met "geen voorkeur" naast goede ciphers ook nog hele zwakke ciphers ondersteunt, dan loop je namelijk het risico bij een MITM aanval dat de aanvaller de browserdata zodanig manipuleert dat die brakke cipher wordt aangevraagd bij de server.
1) Sowieso moet je onderscheid maken tussen actieve en passieve aanvallen. Actieve aanvallen zijn lastiger en vaak eenvoudiger te ontdekken. Bij een passieve aanval slaat de aanvaller het netwerkverkeer op en probeert de versleuteling later te kraken (of krijgt later de private key in handen, bijv. middels een huiszoekingsbevel, server-hack of heartbleed-achtig lek, en kan de informatie dan alsnog ontcijferen). Bij een passieve aanval is het al winst als de (meestal veilige) voorkeur van de browser wordt overgenomen door de server.
2) Ik weet niet exact hoe gevoelig browsers en servers daadwerkelijk nog zijn voor downgrade attacks. In principe bevatte SSLv3 al maatregelen om deze te voorkomen, alleen werden deze aanvankelijk uitgeschakeld door browserproducenten om compatibiliteitsproblemen met brakke servers te voorkomen (zie met name de antwoorden in http://crypto.stackexchange.com/questions/10493/why-is-tls-susceptible-to-protocol-downgrade-attacks). Het idee is ruwweg dat de server en client, na aanvankelijk informatie over cipher suites plain text te hebben uitgewisseld, wat later (voordat inhoudelijke informatie wordt uitgewisseld via https), informatie over ondersteunde suites nogmaals uitwisselen, echter voorzien van "digitale handtekening". De tegenpartij kan die lijst dan vergelijken met de eerder, mogelijk door een MitM gemanipuleerde lijst. De bedoeling is natuurlijk dat de verbinding wordt verbroken als er verschillen (t.g.v. manipulatie) worden gedetecteerd.
3) Zodra SCSV algemeen is ingevoerd (zowel client als server moeten dit ondersteunden), worden downgrade attacks (als het goed is) onmogelijk gemaakt.
Door Anoniem:
Een server stuurt geen lijst van ondersteunde ciphers naar de webbrowser (noch naar https://www.ssllabs.com/ssltest/). Als er op de server geen voorkeursvolgorde ingesteld is, kan ssllabs de volgorde van de cipher suites in het configuratiebestand van de server niet achterhalen. Om vast te stellen welke cipher suites de server ondersteunt, doet ssllabs telkens opnieuw een browser na die steeds een andere lijst met cipher suites (of slechts 1) ondersteunt, om zo de server "uit te horen". Nogmaals, als de server geen voorkeur heeft, is de sortering, van de in de webpagina getoonde cipher suites, feitelijk arbitrair.15:20 door Erik van Straten:
Een voorbeeld van zo'n server (d.w.z. zonder preference) is https://www.ssllabs.com/ssltest/analyze.html?d=wisseljewachtwoord.nl (de 40 bit ciphers komen vóór de 56 bit ciphers - wisseljebeheerder was een betere naam geweest ;)
ehm... he???... Wat bedoel je precies?Een voorbeeld van zo'n server (d.w.z. zonder preference) is https://www.ssllabs.com/ssltest/analyze.html?d=wisseljewachtwoord.nl (de 40 bit ciphers komen vóór de 56 bit ciphers - wisseljebeheerder was een betere naam geweest ;)
In reactie op: Vandaag, 00:56 door Erik van Straten - Bijgewerkt: Vandaag, 00:58
Beste Erik, voor mij lijkt het alsof je soms wel eens dingen uit zijn context haalt, en ze vervolgens plaatst
in een hele andere context die niet van toepassing is. Dat is niet zo'n eerlijke methode.
Graag wil ik dat recht zetten.
Om te beginnen haal je het voorbeeld aan van "WEP", dat serieus is gekraakt. Maar wij hadden het over 3DES,
dat dus al tientallen jaren juist niet echt serieus is gekraakt. Zoiets is druiven met appels vergelijken.
Juist deze lange periode wijst er op, dat 3DES kennelijk niet zo gemakkelijk echt serieus te kraken is.
Waar het mij om ging, is dat sommigen een 112 bits cipher maar "bitter weinig" vinden,
en dat men veiligheid alleen maar afmeet aan die sleutellengte.
Maar ik rekende jullie voor, dat in het ideale geval 112 bits niet per sé te weinig hoeft te zijn.
In ieder geval hoef je niet zo bang te zijn voor een snelle succesvolle "brute force attack".
Dat de zaken in werkelijkheid vaak niet 100% ideaal zijn (ook bij 3DES niet helemaal), moge duidelijk zijn.
Uit mijn tekst die daarna kwam over "cipherstrength" en "keylength" mocht dit ook wel blijken.
Wil je de veiligheid van ciphers goed beoordelen, dan zou het niet alleen over sleutellengte moeten gaan,
maar ook over de kwaliteit van het algoritme.
Zet je een cipher suite A met een sterk algoritme en een wat kortere sleutel eens af tegen een cipher suite B
met een zwak (kwetsbaar) algoritme maar met een langere sleutel, dan kún je beter af zijn met cipher suite A,
ook al heeft deze een kortere sleutel.
Probleem is alleen wel: hoe bepaal je nu de mate van kwetsbaarheid van een algoritme?
Want kwetsbaarheden tekenen zich meestal pas later af in de praktijk,
en/of pas als vele geleerden zich er jarenlang over hebben gebogen... Dat is dus het grootste probleem bij de beoordeling.
En daarom hebben we toch de neiging om maar naar de sleutellengte te kijken, want dat weten we tenminste zeker.
Maar eigenlijk kunnen we elkaar daar dus gemakkelijk mee voor de gek houden.
M.a.w.: een cipher met een 256 bits sleutel maar met een nogal beroerd (kwetsbaar) algoritme,
hoeft niet beslist beter te zijn dan een cipher met een 128 bits sleutel en een veel sterker algoritme.
Men moet zich dus niet teveel blind staren op de feitelijke lengte van de sleutel, want dit zegt lang niet alles.
Het is hooguit een indicatie, een indruk. Maar wel met de nodige "slagen om de arm".
Er bestaan ook goede algoritmen waarvan aan de oppervlakte liggende zwakheden al bekend zijn, en die worden soms meteen ingecalculeerd. Bij 3DES is dit het geval. Want 3DES is feitelijk 168 bits (3 x 56 bits), maar wordt meestal als 112 bits gepresenteerd. Het NCSC noemt dit met een mooi woord 112 bits "security-equivalent".
Natuurlijk is het prima dat jij, Erik, er nog eens op wees dat er meestal geen sprake van een ideale situatie is,
en dat ook via een andere weg dan "brute force" (bijv. door kwetsbaarheden/lekken van het algoritme uit te buiten)
op één of andere manier (iets van) de ciphertext (=je versleutelde data die over de lijn gaat) kan worden blootgelegd.
Maar je had het wat mij betreft wat beter (eerlijker) kunnen brengen.
Ten tweede reageer je op mijn "men zou niet zomaar de "cipher strength" moeten afmeten aan de hand van puur en alleen de key-length!" als volgt:
Ik citeer: "Cipher Suites (sorted by strength; the server has no preference).
Ik herhaal: sorted by strength!.
Er staat niet "sorted by advertized keysize" of iets dergelijks.
Hadden ze dat maar gedaan, dan had jij mij hier niet over gehoord. Maar nu zaaien ze in zulke
"sorted by strength" -cipherlijsten dus de verwarring dat 3DES (112) sterker zou zijn dan AES (128).
Bekijk het nog maar eens heel nauwkeurig zou ik zeggen. Het is gewoon niet correct.
Ten derde waarschuwde ik voor een MitM attack in geval van ondersteuning van brakke ciphers.
Zelfs ook als de server zo is geconfigureerd, dat deze "geen voorkeur" voor een cipher heeft,
en zelfs ook als de server naast die brakke ciphers ook nog gewoon sterke ciphers ondersteunt.
En dan reageer jij hierop door er op zijsporen van alles omheen te vertellen over zaken die misschien op zichzelf genomen en onder bepaalde omstandigheden helemaal niet onwaar zijn, maar ze doen volgens mij niet zo ter zake.
Zo ontstaat er obfuscatie t.a.v. het punt waar het daar feitelijk om draaide, namelijk:
"denk nu alsjeblieft niet te snel dat je geen extra risico's loopt bij servers die "geen voorkeur"
voor een cipher hebben, en die naast sterke ciphers ook nog hele brakke ciphers ondersteunen."
(En dat servers om die reden liefst totaal geen brakke cipher suites zouden moeten ondersteunen)
Concreet moet je hierbij denken aan een zogenaamde "Cipher suite rollback".
Deze aanval richt zich op het limiteren van de verstrekte cipher-suite lijst tot uitsluitend zwakkere of NULL-ciphers.
Een Man-in-the-middle (MitM) aanvaller zou bijvoorbeeld de initiële ClientHello message kunnen wijzigen
en alle sterke cipher-suites van die ClientHello message afstrippen, zodat er alleen nog maar hele zwakke ciphers op de lijst staan. Desnoods probeert de aanvaller zelf zwakke ciphers toe te voegen.
Deze aldus gemanipuleerde ClientHello wordt vervolgens doorgestuurd naar zo'n server die "zonder voorkeur"
ondermeer die zwakkere cipher suites ondersteunt, et voilá...
Wie als leek dan nog een browser heeft die eveneens dit soort zwakke ciphers nog ondersteunt, krijgt er dan mee te maken dat de hele sessie dus over een zwak versleutelde (afluisterbare) verbinding wordt gecommuniceerd, met alle risico's van dien. Dus nogmaals: servers moeten daarom liefst helemaal geen brakke cipher suites ondersteunen,
want dit is niet altijd geheel zonder risico's. Oók niet als de server "geen voorkeur" voor een cipher heeft.
Voor wat het laatste onderwerp betreft: wat ik dus niet helemaal begreep was deze zinsnede:
"wisseljebeheerder was een betere naam geweest"???
Het is toch niet de schuld van de beheerder dat SSLLABS bij een server "ZONDER VOORKEUR"
een 40-bits cipher vóór een 56-bits cipher plaatst?
Wat mij betreft doet het hier weinig ter zake dat het 40-bits cipher vóór de 56 bits in de lijst staat.
Maar het feit dat deze twee brakke ciphers überhaupt in de lijst staan (ongeacht de volgorde),
ja, dat wekt inderdaad bij mij wel vragen op, ja, of die systeembeheerder daar wel op zijn plaats is.
En o ja (-; toegift ;-) je had het ook nog even over die richtlijnen van NCSC. Daarbij moest ik weer denken aan 3DES
dat ik een poosje geleden had betiteld met "veilig genoeg". Maar jij leek het daar toen niet mee eens te zijn.
Zojuist nog even in de onlangs uitgekomen "ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS)"
van het Nationaal Cyber Security Centrum gelezen wat het NCSC zegt over DES, 3DES en RC4:
1. DES en 3DES
Op blz. 15 is na te lezen dat 3DES cipher suites in de categorie "voldoende" vallen.
De categorie "voldoende" is bedoeld om de nodige compatibliteit met oudere apparaten te behouden.
Een "voldoende" algoritme biedt minstens 112 bits "security-equivalent".
"Security-equivalent" is een term die NCSC gebruikt als indicatie voor de sterkte van een cipher.
Bijvoorbeeld: ECDSA met een sleutellengte van 256 bits en AES met een sleutellengte van 128 bits
hebben allebei een security-equivalent van 128 bits.
De 3DES ciphers voldoen aan de vereiste 112 bits, maar enkelvoudige of tweevoudige DES ciphers niet.
De zogenaamde "triple-DES" (3DES) cipher suites zijn dus "veilig genoeg" (=voldoende veilig) bevonden.
Maar enkelvoudige DES ciphers (56 bits) worden nergens meer aangeraden, en als "verouderd" beschouwd.
2. RC4
Het NCSC schrijft op blz.5 onder "BEAST-aanvalstechniek" betreffend RC4 het volgende voor:
"RC4 kent echter zijn eigen kwetsbaarheden en dient niet gekozen te worden."
Op blz.16 is de waardering voor het RC4-algoritme dan ook een "onvoldoende".
Elders wordt RC4 als "verouderd" beschouwd, samen met DES. (enkelvoudig, 56 bits).
(zie blz. 33 bij "Bulkversleuteling")
In de "ciphersuite richtlijnen" op blz.15 komen RC4 en (enkelvoudig, 56 bits) DES dan ook niet voor.
Kortom: De richtlijn van het NCSC (Nationaal Cyber Security Centrum) is: gebruik geen RC4 en geen (56 bits) DES!
Maar 3DES (bijv. TLS_RSA_WITH_3DES_EDE_CBC_SHA) mag (vooralsnog) als het nodig is nog even blijven.
Lijkt me duidelijk, en "veilig genoeg" om een punt te zetten achter de discussie over DES, 3DES en RC4. :-))
(dat o.a. Triodos daar nog lering uit mag trekken) ;-)
Mvg, cluc-cluc
Beste Erik, voor mij lijkt het alsof je soms wel eens dingen uit zijn context haalt, en ze vervolgens plaatst
in een hele andere context die niet van toepassing is. Dat is niet zo'n eerlijke methode.
Graag wil ik dat recht zetten.
Om te beginnen haal je het voorbeeld aan van "WEP", dat serieus is gekraakt. Maar wij hadden het over 3DES,
dat dus al tientallen jaren juist niet echt serieus is gekraakt. Zoiets is druiven met appels vergelijken.
Juist deze lange periode wijst er op, dat 3DES kennelijk niet zo gemakkelijk echt serieus te kraken is.
Waar het mij om ging, is dat sommigen een 112 bits cipher maar "bitter weinig" vinden,
en dat men veiligheid alleen maar afmeet aan die sleutellengte.
Maar ik rekende jullie voor, dat in het ideale geval 112 bits niet per sé te weinig hoeft te zijn.
In ieder geval hoef je niet zo bang te zijn voor een snelle succesvolle "brute force attack".
Dat de zaken in werkelijkheid vaak niet 100% ideaal zijn (ook bij 3DES niet helemaal), moge duidelijk zijn.
Uit mijn tekst die daarna kwam over "cipherstrength" en "keylength" mocht dit ook wel blijken.
Wil je de veiligheid van ciphers goed beoordelen, dan zou het niet alleen over sleutellengte moeten gaan,
maar ook over de kwaliteit van het algoritme.
Zet je een cipher suite A met een sterk algoritme en een wat kortere sleutel eens af tegen een cipher suite B
met een zwak (kwetsbaar) algoritme maar met een langere sleutel, dan kún je beter af zijn met cipher suite A,
ook al heeft deze een kortere sleutel.
Probleem is alleen wel: hoe bepaal je nu de mate van kwetsbaarheid van een algoritme?
Want kwetsbaarheden tekenen zich meestal pas later af in de praktijk,
en/of pas als vele geleerden zich er jarenlang over hebben gebogen... Dat is dus het grootste probleem bij de beoordeling.
En daarom hebben we toch de neiging om maar naar de sleutellengte te kijken, want dat weten we tenminste zeker.
Maar eigenlijk kunnen we elkaar daar dus gemakkelijk mee voor de gek houden.
M.a.w.: een cipher met een 256 bits sleutel maar met een nogal beroerd (kwetsbaar) algoritme,
hoeft niet beslist beter te zijn dan een cipher met een 128 bits sleutel en een veel sterker algoritme.
Men moet zich dus niet teveel blind staren op de feitelijke lengte van de sleutel, want dit zegt lang niet alles.
Het is hooguit een indicatie, een indruk. Maar wel met de nodige "slagen om de arm".
Er bestaan ook goede algoritmen waarvan aan de oppervlakte liggende zwakheden al bekend zijn, en die worden soms meteen ingecalculeerd. Bij 3DES is dit het geval. Want 3DES is feitelijk 168 bits (3 x 56 bits), maar wordt meestal als 112 bits gepresenteerd. Het NCSC noemt dit met een mooi woord 112 bits "security-equivalent".
Natuurlijk is het prima dat jij, Erik, er nog eens op wees dat er meestal geen sprake van een ideale situatie is,
en dat ook via een andere weg dan "brute force" (bijv. door kwetsbaarheden/lekken van het algoritme uit te buiten)
op één of andere manier (iets van) de ciphertext (=je versleutelde data die over de lijn gaat) kan worden blootgelegd.
Maar je had het wat mij betreft wat beter (eerlijker) kunnen brengen.
Ten tweede reageer je op mijn "men zou niet zomaar de "cipher strength" moeten afmeten aan de hand van puur en alleen de key-length!" als volgt:
De volgorde in de webpagina is totaal irrelevant als de serverbeheerder geen voorkeurvolgorde heeft geconfigureerd. Het lijstje had net zo goed op alfabet gesorteerd kunnen zijn, of op geboorteddaum van de uitvinder van de cipher. Toevallig kiest SSLlabs ervoor om te sorteren op de geadverteerde sleutellengte.
Waar maak je dat uit op dan? Kijk nog eens heel goed wat SSLLABS boven zo'n cipherlijst zet.Ik citeer: "Cipher Suites (sorted by strength; the server has no preference).
Ik herhaal: sorted by strength!.
Er staat niet "sorted by advertized keysize" of iets dergelijks.
Hadden ze dat maar gedaan, dan had jij mij hier niet over gehoord. Maar nu zaaien ze in zulke
"sorted by strength" -cipherlijsten dus de verwarring dat 3DES (112) sterker zou zijn dan AES (128).
Bekijk het nog maar eens heel nauwkeurig zou ik zeggen. Het is gewoon niet correct.
Ten derde waarschuwde ik voor een MitM attack in geval van ondersteuning van brakke ciphers.
Zelfs ook als de server zo is geconfigureerd, dat deze "geen voorkeur" voor een cipher heeft,
en zelfs ook als de server naast die brakke ciphers ook nog gewoon sterke ciphers ondersteunt.
En dan reageer jij hierop door er op zijsporen van alles omheen te vertellen over zaken die misschien op zichzelf genomen en onder bepaalde omstandigheden helemaal niet onwaar zijn, maar ze doen volgens mij niet zo ter zake.
Zo ontstaat er obfuscatie t.a.v. het punt waar het daar feitelijk om draaide, namelijk:
"denk nu alsjeblieft niet te snel dat je geen extra risico's loopt bij servers die "geen voorkeur"
voor een cipher hebben, en die naast sterke ciphers ook nog hele brakke ciphers ondersteunen."
(En dat servers om die reden liefst totaal geen brakke cipher suites zouden moeten ondersteunen)
Concreet moet je hierbij denken aan een zogenaamde "Cipher suite rollback".
Deze aanval richt zich op het limiteren van de verstrekte cipher-suite lijst tot uitsluitend zwakkere of NULL-ciphers.
Een Man-in-the-middle (MitM) aanvaller zou bijvoorbeeld de initiële ClientHello message kunnen wijzigen
en alle sterke cipher-suites van die ClientHello message afstrippen, zodat er alleen nog maar hele zwakke ciphers op de lijst staan. Desnoods probeert de aanvaller zelf zwakke ciphers toe te voegen.
Deze aldus gemanipuleerde ClientHello wordt vervolgens doorgestuurd naar zo'n server die "zonder voorkeur"
ondermeer die zwakkere cipher suites ondersteunt, et voilá...
Wie als leek dan nog een browser heeft die eveneens dit soort zwakke ciphers nog ondersteunt, krijgt er dan mee te maken dat de hele sessie dus over een zwak versleutelde (afluisterbare) verbinding wordt gecommuniceerd, met alle risico's van dien. Dus nogmaals: servers moeten daarom liefst helemaal geen brakke cipher suites ondersteunen,
want dit is niet altijd geheel zonder risico's. Oók niet als de server "geen voorkeur" voor een cipher heeft.
Voor wat het laatste onderwerp betreft: wat ik dus niet helemaal begreep was deze zinsnede:
de 40 bit ciphers komen vóór de 56 bit ciphers - wisseljebeheerder was een betere naam geweest
Waarom zeg je zo nadrukkelijk "de 40 bits ciphers komen vóór de 56 bit ciphers", en zeg je pas daarna: "wisseljebeheerder was een betere naam geweest"???
Het is toch niet de schuld van de beheerder dat SSLLABS bij een server "ZONDER VOORKEUR"
een 40-bits cipher vóór een 56-bits cipher plaatst?
Wat mij betreft doet het hier weinig ter zake dat het 40-bits cipher vóór de 56 bits in de lijst staat.
Maar het feit dat deze twee brakke ciphers überhaupt in de lijst staan (ongeacht de volgorde),
ja, dat wekt inderdaad bij mij wel vragen op, ja, of die systeembeheerder daar wel op zijn plaats is.
En o ja (-; toegift ;-) je had het ook nog even over die richtlijnen van NCSC. Daarbij moest ik weer denken aan 3DES
dat ik een poosje geleden had betiteld met "veilig genoeg". Maar jij leek het daar toen niet mee eens te zijn.
Zojuist nog even in de onlangs uitgekomen "ICT-beveiligingsrichtlijnen voor Transport Layer Security (TLS)"
van het Nationaal Cyber Security Centrum gelezen wat het NCSC zegt over DES, 3DES en RC4:
1. DES en 3DES
Op blz. 15 is na te lezen dat 3DES cipher suites in de categorie "voldoende" vallen.
De categorie "voldoende" is bedoeld om de nodige compatibliteit met oudere apparaten te behouden.
Een "voldoende" algoritme biedt minstens 112 bits "security-equivalent".
"Security-equivalent" is een term die NCSC gebruikt als indicatie voor de sterkte van een cipher.
Bijvoorbeeld: ECDSA met een sleutellengte van 256 bits en AES met een sleutellengte van 128 bits
hebben allebei een security-equivalent van 128 bits.
De 3DES ciphers voldoen aan de vereiste 112 bits, maar enkelvoudige of tweevoudige DES ciphers niet.
De zogenaamde "triple-DES" (3DES) cipher suites zijn dus "veilig genoeg" (=voldoende veilig) bevonden.
Maar enkelvoudige DES ciphers (56 bits) worden nergens meer aangeraden, en als "verouderd" beschouwd.
2. RC4
Het NCSC schrijft op blz.5 onder "BEAST-aanvalstechniek" betreffend RC4 het volgende voor:
"RC4 kent echter zijn eigen kwetsbaarheden en dient niet gekozen te worden."
Op blz.16 is de waardering voor het RC4-algoritme dan ook een "onvoldoende".
Elders wordt RC4 als "verouderd" beschouwd, samen met DES. (enkelvoudig, 56 bits).
(zie blz. 33 bij "Bulkversleuteling")
In de "ciphersuite richtlijnen" op blz.15 komen RC4 en (enkelvoudig, 56 bits) DES dan ook niet voor.
Kortom: De richtlijn van het NCSC (Nationaal Cyber Security Centrum) is: gebruik geen RC4 en geen (56 bits) DES!
Maar 3DES (bijv. TLS_RSA_WITH_3DES_EDE_CBC_SHA) mag (vooralsnog) als het nodig is nog even blijven.
Lijkt me duidelijk, en "veilig genoeg" om een punt te zetten achter de discussie over DES, 3DES en RC4. :-))
(dat o.a. Triodos daar nog lering uit mag trekken) ;-)
Mvg, cluc-cluc
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.
