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.
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.
