Privacy
- Wat niemand over je mag weten
TLS 1.0 toch nog steeds veilig?
17-04-2017, 18:00 door Anoniem, 12 reacties
In https://blog.qualys.com/ssllabs/2015/05/22/ssl-labs-increased-penalty-when-tls-12-is-not-supported
heeft Ivan Ristic gezegd dat op 20 mei 2015 elke website die geen TLS1.2 ondersteunt een grade C zal krijgen en geen grade B meer. Hij zegt o.a.:
Echter wat Ivan niet zegt, is dat PCI Security Councel deze beslissing later heeft versoepeld.
Verplichte ondersteuning van TLS1.2 voor commercie, internetbankieren e.d. geldt in de V.S. nu kennelijk pas halverwege het jaar 2018 (onder voorbehoud). Het resultaat is dat bijv. sommige banken nog steeds met een TLS1.0 lijntje werken...
Onverantwoordelijk?
Of is TLS1.0, mits goed gepatcht tegen de bekende aanvallen als BEAST, POODLE, Heartbleed e.d. en zonder RC4,
veiliger dan we misschien denken?
heeft Ivan Ristic gezegd dat op 20 mei 2015 elke website die geen TLS1.2 ondersteunt een grade C zal krijgen en geen grade B meer. Hij zegt o.a.:
Just last month, the PCI Security Council deprecated SSL v3 and TLS 1.0 for commercial transactions. No new systems are allowed to use TLS 1.0 for credit card processing and existing systems must immediately begin to transition to better protocols.
Daarbij hekelt Ivan nog langer gebruik van TLS1.0.Echter wat Ivan niet zegt, is dat PCI Security Councel deze beslissing later heeft versoepeld.
Verplichte ondersteuning van TLS1.2 voor commercie, internetbankieren e.d. geldt in de V.S. nu kennelijk pas halverwege het jaar 2018 (onder voorbehoud). Het resultaat is dat bijv. sommige banken nog steeds met een TLS1.0 lijntje werken...
Onverantwoordelijk?
Of is TLS1.0, mits goed gepatcht tegen de bekende aanvallen als BEAST, POODLE, Heartbleed e.d. en zonder RC4,
veiliger dan we misschien denken?
Reacties (12)
https://tools.ietf.org/html/rfc7525
Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246]; the only exception is when no higher version is available in the negotiation.
- Rationale: TLS 1.0 (published in 1999) does not support many modern, strong cipher suites. In addition, TLS 1.0 lacks a per- record Initialization Vector (IV) for CBC-based cipher suites and does not warn against common padding errors.
. . .
Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to negotiate TLS version 1.2 over earlier versions of TLS.
- Rationale: Several stronger cipher suites are available only with TLS 1.2 (published in 2008). In fact, the cipher suites recommended by this document (Section 4.2 below) are only available in TLS 1.2.
- Rationale: TLS 1.0 (published in 1999) does not support many modern, strong cipher suites. In addition, TLS 1.0 lacks a per- record Initialization Vector (IV) for CBC-based cipher suites and does not warn against common padding errors.
. . .
Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to negotiate TLS version 1.2 over earlier versions of TLS.
- Rationale: Several stronger cipher suites are available only with TLS 1.2 (published in 2008). In fact, the cipher suites recommended by this document (Section 4.2 below) are only available in TLS 1.2.
Nu Windows Vista officieel niet meer wordt ondersteund is het denk ik wachten tot Android 4.4 en lager van de markt verdwenen zijn tot de meeste providers TLS 1.0 zullen droppen.
Door Anoniem: https://tools.ietf.org/html/rfc7525
Implementations SHOULD NOT negotiate TLS version 1.0 [RFC2246]; the only exception is when no higher version is available in the negotiation.
- Rationale: TLS 1.0 (published in 1999) does not support many modern, strong cipher suites. In addition, TLS 1.0 lacks a per- record Initialization Vector (IV) for CBC-based cipher suites and does not warn against common padding errors.
. . .
Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to negotiate TLS version 1.2 over earlier versions of TLS.
- Rationale: Several stronger cipher suites are available only with TLS 1.2 (published in 2008). In fact, the cipher suites recommended by this document (Section 4.2 below) are only available in TLS 1.2.
- Rationale: TLS 1.0 (published in 1999) does not support many modern, strong cipher suites. In addition, TLS 1.0 lacks a per- record Initialization Vector (IV) for CBC-based cipher suites and does not warn against common padding errors.
. . .
Implementations MUST support TLS 1.2 [RFC5246] and MUST prefer to negotiate TLS version 1.2 over earlier versions of TLS.
- Rationale: Several stronger cipher suites are available only with TLS 1.2 (published in 2008). In fact, the cipher suites recommended by this document (Section 4.2 below) are only available in TLS 1.2.
Aha (en dank).
Maar PCI security councel verkondigde: "...the only exception is when no higher version is available in the negotiation."
Dus men faciliteert in feite het doordraaien op TLS1.0 als de software zich niet naar een hogere versie laat configureren.
https://security.stackexchange.com/questions/87071/pci-compliance-scan-failing-for-supporting-tls-1-0-but-removing-support-breaks
Uit deze link begrijp ik dat men door mag gaan met TLS1.0 na 30 juni 2016 (nu 2018?) mits de (bekende) kwetsbaarheden zoals die t.g.v. het IV-probleem en padding probleem (servers-side) zijn verholpen?
1. Begrijp ik dat goed?
2. Kan dat? Is het dan echt veilig?
Ik heb ook nog dit gevonden voor de MAC: http://www.root.org/talks/TLS_Flaw20080110.pdf
Heeft men in Firefox met Windows niets aan de kwetsbaarheden t.g.v. IV en padding gedaan?
TLS 1.0 lacks a per- record Initialization Vector (IV) for CBC-based cipher suites
De "BEAST"-attack maakt hier gebruik van.Gelukkig zijn aanvallen die hierop zijn gebaseerd al een tijdje verholpen in Firefox browsers met een eenvoudige truuk:
https://security.stackexchange.com/questions/63215/why-does-firefox-split-https-request
Hier valt misschien iets voor te zeggen:
https://www.lexiconn.com/blog/2015/12/pci-council-pushes-back-tls-1-0-end-of-life-date-to-june-2018/
https://www.lexiconn.com/blog/2015/12/pci-council-pushes-back-tls-1-0-end-of-life-date-to-june-2018/
Zelfs met TLS 1.2 moet je nog altijd kijken welke cipiers je aan hebt staan. Het systeem is zo sterk als de zwakosten schakel.
Check ook howsmyssl.com
Check ook howsmyssl.com
07-05-2017, 21:15 door
[Account Verwijderd]
-
Bijgewerkt: 07-05-2017, 21:20
[Verwijderd]
Outlook i.c.m. Exchange kan t/m Windows 8 niet zonder TLS 1.0
https://blogs.technet.microsoft.com/schrimsher/2016/07/08/enabling-tls-1-1-and-1-2-in-outlook-on-windows-7/
dus op veel plekken kan TLS 1.0 nog niet uit.
Paul
https://blogs.technet.microsoft.com/schrimsher/2016/07/08/enabling-tls-1-1-and-1-2-in-outlook-on-windows-7/
dus op veel plekken kan TLS 1.0 nog niet uit.
Paul
Door Komsowalski: Neem dan voor het gemak in Firefox ook dit even mee.
(Zie ook de tekst voor OS-instellingen etc)
https://www.eff.org/deeplinks/2015/10/how-to-protect-yourself-from-nsa-attacks-1024-bit-DH
Zo instellen:
https://www.eff.org/files/2015/10/15/ff.png
(Zie ook de tekst voor OS-instellingen etc)
https://www.eff.org/deeplinks/2015/10/how-to-protect-yourself-from-nsa-attacks-1024-bit-DH
Zo instellen:
https://www.eff.org/files/2015/10/15/ff.png
Dat is oud nieuws.
Firefox heeft vanaf versie 39 een fix ingebouwd:
https://scottontechnology.com/how-to-secure-firefox-against-logjam/
En SHA-1 is hard in TLS 1.0 ingebakken. Daar zijn ook al sterke aanvallen tegen. Nog niet specifiek tegen TLS 1.0 maar dat zou zomaar eens kunnen volgen.
https://tools.ietf.org/html/rfc4346#section-5
https://tools.ietf.org/html/rfc4346#section-5
08-05-2017, 11:31 door
[Account Verwijderd]
-
Bijgewerkt: 08-05-2017, 11:33
[Verwijderd]
Door Komsowalski:
Het probleem wat ik naar voren bracht is nog steeds in Firefox aanwezig (zwakke 1024 bit Deffie Hellman ciphersuits) waardoor een NSA-aanval mogelijk gemaakt kan worden (zie daarvoor de tekst die ik eerder meezond).
Wie de proef op de som neemt en de betreffende Firefox instellingen via about:config weer terugzet (intypen: .dhe) zal merken dat het juist de Deffie Hellman ciphersuit is die voor gebruik weer mogelijk wordt gemaakt, iets waar juist EFF voor waarschuwt. Je kunt dit controleren door de website https://www.howsmyssl.com/ te bezoeken. Daar moet alles wat -DHE- heet uit de onderste lijst zijn verdwenen.
Akkoord!Door Anoniem:
Dat is oud nieuws.
Firefox heeft vanaf versie 39 een fix ingebouwd:
https://scottontechnology.com/how-to-secure-firefox-against-logjam/
Dank voor je bijdrage. Door Komsowalski: Neem dan voor het gemak in Firefox ook dit even mee.
(Zie ook de tekst voor OS-instellingen etc)
https://www.eff.org/deeplinks/2015/10/how-to-protect-yourself-from-nsa-attacks-1024-bit-DH
Zo instellen:
https://www.eff.org/files/2015/10/15/ff.png
(Zie ook de tekst voor OS-instellingen etc)
https://www.eff.org/deeplinks/2015/10/how-to-protect-yourself-from-nsa-attacks-1024-bit-DH
Zo instellen:
https://www.eff.org/files/2015/10/15/ff.png
Dat is oud nieuws.
Firefox heeft vanaf versie 39 een fix ingebouwd:
https://scottontechnology.com/how-to-secure-firefox-against-logjam/
Het probleem wat ik naar voren bracht is nog steeds in Firefox aanwezig (zwakke 1024 bit Deffie Hellman ciphersuits) waardoor een NSA-aanval mogelijk gemaakt kan worden (zie daarvoor de tekst die ik eerder meezond).
Wie de proef op de som neemt en de betreffende Firefox instellingen via about:config weer terugzet (intypen: .dhe) zal merken dat het juist de Deffie Hellman ciphersuit is die voor gebruik weer mogelijk wordt gemaakt, iets waar juist EFF voor waarschuwt. Je kunt dit controleren door de website https://www.howsmyssl.com/ te bezoeken. Daar moet alles wat -DHE- heet uit de onderste lijst zijn verdwenen.
Je hoeft er dus niet aan te denken bij FF browsers vanaf versie 39 om de DHE ciphers uit te zetten, want ze staan al uit.
(ik verwacht overigens dat andere browsers ook allang een fix hebben, maar daar bemoei ik me niet zo mee)
Maar het punt is nu nog, dat je wel moet oppassen om die DHE ciphers niet weer "aan" zet (of in elk geval ervan bewust zijn dat dit onveilig is op internet)
Begrijp ik dat goed van je?
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Toezichthouder informatiebeveiliging Overheid
Rijksinspectie Digitale Infrastructuur (RDI)
Vind je het leuk om als toezichthouder bij te dragen aan de verdere groei in informatie-beveiliging van de overheid en in contact te staan met (belangen) organisaties binnen de overheid? Dan kun je komen bouwen aan toezicht op een veilige en betrouwbare Digitale Infrastructuur in Nederland.
Adviseur Informatiebeveiliging
Je bent een belangrijke speler om invulling te geven aan de gemeentelijke ambities op het gebied van informatiebeveiliging. Deze ambities neem jij op in het Informatie-beveiligingsbeleid Gemeente Zoetermeer. Wil je helpen bij het verbeteren van de informatiebeveiliging in Zoetermeer en het versterken van het cyberbewustzijn binnen onze organisatie? Wacht dan niet en kom ons team informatiebeveiliging versterken!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.