Internet-taskforce schrapt ssl 3.0 officieel vanwege onveiligheid

Ssl 3.0 heeft officieel afgedaan en is niet veilig genoeg om te gebruiken, zo heeft de Internet Engineering Task Force gemeld in een request for comments. Wie dat nog niet heeft gedaan, moet overstappen op bijvoorbeeld tls 1.2, aldus het IETF.

Met de afkeuring via IETF's rfc 7568 is het einde van het gebruik van ssl 3.0 tot officieel beleid van de Internet Engineering Task Force geworden. Dat einde komt niet als een verrassing: een draft van de aankondiging verscheen al eerder. Ssl 3.0 is niet veilig genoeg meer voor gebruik. "De vervangende versies, met name transport layer security 1.2, zijn veel veiliger en capabeler", schrijft de taskforce.

De meeste bedrijven en organisaties zijn al gestopt met het gebruik van ssl 3.0. Nu stoppen een officieel IETF-beleid is moeten ook de laatste gebruikers het protocol vaarwel zeggen. Sslv3 was de compleet herschreven opvolger van versie 2 waarvan de versleuteling in 1996 niet sterk genoeg bleek. Het ssl 3.0-protocol werd overigens in 2011 pas officieel door de IETF in een 'historisch document' gespecificeerd.

Ssl 3.0 wordt al jaren als verouderd beschouwd, maar bleef veel gebruikt worden. De doodsteek voor het protocol kwam in oktober vorig jaar, met de ontdekking van de Poodle-kwetsbaarheid. Deze zwakte zat niet in een specifieke ssl-implementatie, maar in het onderliggende protocol.

Reacties (100)

[thorjan]

Ondanks dit zijn er nog héél veel sites die dit ondersteunen.

Testen kan je hier: https://www.ssllabs.com/ssltest/index.html

Deze tests zijn vaak zeer confronterend!

[Faeron]

Deze tests zijn vaak zeer confronterend!

Tenzij je een goede webserver gebruikt, dan krijg je automatisch een A score en met een simpele configuratie optie een A+ score.

[Reactie gewijzigd door Faeron op 27 juli 2024 21:43]

[MadEgg]

Gebruik zelf ook Hiawatha voor een website. Qua security zit het zeker goed, en A+ halen was een eitje. Veel eenvoudiger dan A halen in Apache2.4. Echter, qua snelheid moet het zijn meerdere in zowel nginx als lighttpd erkennen en support voor nieuwe technieken als websockets laat helaas op zich wachten.

Een "goede" webserver is een relatief begrip, dat is wat ik wil zeggen.

[Faeron]

En ook snelheid is een relatief begrip:
https://www.hiawatha-webserver.org/forum/topic/283
https://www.hiawatha-webs...PHP_web_serving_study.pdf
https://www.hiawatha-webserver.org/weblog/64
https://www.hiawatha-webserver.org/weblog/57

Websockets worden wel degelijk ondersteund door Hiawatha. Sinds v9.8:
https://www.hiawatha-webserver.org/changelog

[Reactie gewijzigd door Faeron op 27 juli 2024 21:43]

[MadEgg]

I stand corrected. Ik ging af op de eerste hit op "Hiawatha Websockets": https://www.hiawatha-webserver.org/forum/topic/1626

De changelog zegt echter dat het zou moeten werken. Ik was aan het oriënteren voor een webapp die ik op een VM met Hiawatha wilde gaan bouwen en draaien, maar nog geen websockets gebruikt, ik was er dus nog niet aan toegekomen om het te proberen. Mooi dat het inmiddels dus wel kan

[niqck]

A+ op Apache 2.4... en dat was echt niet moeilijk (als je weet waar je mee bezig bent)...

[MadEgg]

Nu ja, bij Hiawatha is het een kwestie van SSL aanzetten en je zit op A. Schakel je SSL in op Apache2 dan zit je op D ofzo. Vervolgens moet je dus zelf een lijst opstellen van ciphers in de juiste volgorde (of deze ergens van internet plukken) en die whitelisten in Apache2 en de rest blokkeren. Hierbij is het natuurlijk niet de bedoeling om zo min mogelijk ciphers toe te staan omdat je dan veel clients tegenwerkt.

Als je eenmaal uitgezocht hebt hoe het moet is het een kwestie van 2 (lange) regels toevoegen aan de configuratie en is het snel gedaan. De grote vraag is waarom de defaults in Apache2 niet gewoon eens aangepast worden aan de hedendaagse opvattingen over veilige ciphers. Laat de mensen die antieke browsers / clients willen ondersteunen maar de config aanpassen terwijl de default gewoon veilig is.

[mxcreep]

Tsja, inderdaad zeg, tegenwoordig schijnt het cool te zijn om anti Apache te zijn.

[MadEgg]

Apache is een fantastische webserver die zijn sporen ruimschoots heeft verdiend. Het gaat echter wel al heel lang mee en heeft daardoor dermate veel modules en use-cases bemachtigd waardoor de configuratie hier en daar wat omslachtig is. Configuratie van Hiawatha of Lighttpd is een stuk eenvoudiger IMO. Als je de configuratie afgerond hebt werkt het als een trein, ook op Apache2. Maar als je kijkt naar de ruwe cijfers dan is het wel duidelijk dat Apache2 niet de snelste webserver is. Voor het grootste deel van de websites is dat geen enkel probleem aangezien die toch niet miljoenen bezoekers hoeven te bedienen.

[MegaTronics]

Zelfs met mijn eigen selfsigned certificaat haal ik een A (ok, moet je wel de trust issues wegdenken ) op IIS.

[watercoolertje]

Ik krijg een driehoekje in Chrome, das dan weer jammer...

Ik heb een VPS bij transip met CentOS haalt ook gewoon A dus volgens mij is dat niet echt heel speciaal

[Phoenix1337]

Nu nog HTTP Strict Transport Security aanzetten en je hebt een A+

[watercoolertje]

Niet relevant wat jij of ik gebruiken, het gaat toch om de bezoekers?

Chrome heeft het grootste marktaandeel dus daar heb je gewoon rekening mee te houden, tenzij je richt op een bepaald type gebruikers die geen chrome gebruiken

[Reactie gewijzigd door watercoolertje op 27 juli 2024 21:43]

[Faeron]

Ik heb het zojuist bekeken met Chrome op m'n Macbook, geen driehoekje. Op m'n werk is ook Chrome geinstalleerd, ook daar nooit een driehoekje gezien. Wat houdt dat driehoekje in dan?

[abeker]

Het certificaat gebruikt dan SHA1 als certificate signature algoritme en is nog tot eind 2016 geldig. Als het certifcaat in 2017 nog geldig is, dan geeft Chrome een rood kruis en een rode streep door https weer.

[Faeron]

Dan is er iets met jouw verbinding aan de hand, want ik heb toch echt SHA256 certificaten in gebruik. Surf je soms via een of andere proxy? Of loopt je anti-virus software al je SSL verbindingen te kapen? Wie is de uitgever van het certificaat dat je browser voorgeschoteld krijgt?

[MegaTronics]

Volgens mij checkt Chrome ook alle tussenliggende certificaten, dus als jouw (I)CA nog een SHA1 certificaat heeft die langer geldig is, krijg je ook een rood kruis.

[R4gnax]

Volgens mij checkt Chrome ook alle tussenliggende certificaten, dus als jouw (I)CA nog een SHA1 certificaat heeft die langer geldig is, krijg je ook een rood kruis.

Yup. Net als Firefox. Is ook logisch: een trust-chain is immers enkel zo sterk als de zwakste schakel.

[abeker]

Bij hiawatha-webserver.org gaat het uiteraard goed Ik weet niet welke domeinnaam watercoolertje bedoelde.

Wat ik beschreef is het gedrag van Chrome als géén gebruik wordt gemaakt van SHA256. Ik weet niet in welke gevallen Chrome verder nog een driehoekje weergeeft.

[Aikon]

Mits ipv tenzij

[dnrb]

Tenzij is correct de resultaten zijn namelijk niet confronterend met een goede webserver. Bij mits zou dat net omgekeerd zijn

[tjtristan]

Jammer dat je bij Microsoft's IIS altijd nog het register in moet duiken om de juiste SSL/TLS protocollen uit/aan te zetten en verschillende cipher suites te blokkeren. Maar als je het goed doet kan je zelfs nog een 2003 server met IIS redelijk veilig maken. (alleen TLS 1.0 aanzetten, juiste cipher suites uitzetten en hotfix voor nieuwere cipher suites installeren).

Toch zie je dat dit bij veel bedrijven helaas niet gebeurd. Microsoft maakt het ook niet echt makkelijker omdat je het zelfs nog bij server 2012 moet aanpassen in het register in plaats van in een server manager.

[chaoscontrol]

Nartac heeft voor IIS machines een super handig gratis tooltje hiervoor.

https://www.nartac.com/Products/IISCrypto/

[johnkeates]

Waarom heeft Microsoft dat niet zelf bedacht?

[sjongenelen]

Holy Fuck - thanks !

[MegaTronics]

De tool als je met SSL op IIS werkt.

[mxcreep]

Alleen TLS 1.0 aanzetten ?? Dan loop je al enigzins achter hoor... TLS 1.1 en 1.2 worden inmiddels al veelvuldig gebruikt.

[kozue]

Die opmerking ging over windows 2003, wat gezien de leeftijd helemaal niets hogers dan 1.0 zal ondersteunen. Sowieso zou niemand meer zo'n oud OS als server in moeten zetten, maar goed...

[freaky]

Weet je wat vaak ook confronterend is? Lekker voor A+ gaan en achterblijven met redelijk wat gebruikers die niet meer op je site kunnen komen (voor de ene branche wel een groter probleem dan de andere overigens).

3x raden waarom zoveel sites het nog ondersteunen, anders dan laksheid.

[Mindless999]

Zelf op Windows XP wordt al TLS 1.0 ondersteund wat al beter isdan SSL 3.0, mits deze is geupdate. Mochten mensen daadwerkelijk een extreem oude computer hebben, welke dus ouder is dan XP (met IE 7, dat wel), is het in mijn ogen toch echt wel tijd voor het vernieuwe van de computer.

[johnkeates]

Op Java 1.6 en lager niet. Java 7 en 8 zijn voor veel applicaties nog niet supported, dus daarmee werkt een hele hoop business software niet meer als er niet aan onderhoud gedaan wordt.

[SKiLLa]

Java 1.6 en 1.7 zijn beiden al End-of-Live en tjokvol veiligheidslekken. Dat moet je als organisatie gewoonweg niet willen hebben draaien. En als alternatief kun je b.v. de IBM JRE 1.6 gebruiken, die ondersteunt wel TLS 1.0: http://www-01.ibm.com/support/docview.wss?uid=swg21688165

[i-chat]

ja net als dat sommige bedrijven nog unsuported buisyness software draaien waar al 10 jaar niets meer aan is gedaan - wat draait op ie6 en waardoor gebruikers dus ook vast zitten aan browser die zo lek is dat het 't bedrijf verboden zou moeten worden nog gegevens van onschuldige klanten en/of bedrijven te verwerken.

[elmuerte]

Java 1.6 ondersteunt wel TLS 1.0: https://www.ssllabs.com/s...ml?name=Java&version=6u45

[Mr_Light]

The JSSE API is capable of supporting SSL versions 2.0 and 3.0 and Transport Layer Security (TLS) 1.0. These security protocols encapsulate a normal bidirectional stream socket and the JSSE API adds transparent support for authentication, encryption, and integrity protection.The JSSE implementation in the J2SDK, v 1.44 implements SSL 3.0 and TLS 1.0. It does not implement SSL 2.0.

uit oude doc van java 1.4

Java 5 is al meer dan 11 jaar terug (September 30, 2004)
Hebben jullie het toevallig over TLS 1.1 / TLS 1.2 ? Want TLS 1.0 wil je ook gewoon niet meer gebruiken.

Verder is dat stuk van de standaard java library pluggable en geeft The Legion of the Bouncy Castle sinds het stenen tijdperk er een implementatie voor.

en ja tegenwoordig zit het in de standaard lib

[SKiLLa]

Ontwetendheid ? SSL v3 verkeer was vorig jaar namelijk al minder dan 0.5% op de grootste sites ter wereld, dus 1 op de 200 (maar eerder max 1 op 300) bezoekers gebruikte nog SSLv3. Dus dat achterblijven valt hartstikke mee; is gewoon excuus-FUD van die partijen die nog SSLv3 ondersteunen ...

[bogy]

mogelijk komt een groot deel van dit verkeer door hackers en/of instanties die zich op het hacking terrein bevinden;
het aantal gebruikers ligt dus wellicht toch lager dan die 0.5%

[mxcreep]

Ik heb inmiddels de ciphers zo ingesteld dat XP standaard niet meer werkt. Jammer maar helaas... soms moeten mensen misschien een duwtje in de rug krijgen om eens over te stappen. We leven in een tijdperk waar omgaan met digitale gegevens steeds gevaarlijker wordt en groepen met mensen/bedrijven die het daar niet zo nauw mee nemen moeten daarvoor zelf maar de gevolgen dragen.

[freaky]

Prima keus. Helaas zullen je gebruikers dat niet uit de foutmelding kunnen halen wat een van de voornaamste problemen is.

@hierboven, ja het doet TLS 1.0, maar wel alleen met ciphers die ook brak zijn (en als je zo stellig bent zou je er goed aan doen die ook uit te schakelen dus).

[RatedR]

Ik scoor een A met m'n eigen servertje, en alleen IE6/XP en Java6u45 clients worden niet ondersteund. Lijkt mij een redelijk goede balance tussen compatibiliteit en veiligheid.

[frickY]

Lijkt me geen probleem dat sites het blijven ondersteunen; als een (oudere) client dat wil gebruiken moet hij dat zelf weten.
Wat belangrijk is is of TLS1.2 óók ondersteund wordt, zodat clients die dat wél willen dat kunnen.

[Sfynx]

Het vervelende is dan alleen dat je altijd een groep clients houdt die vatbaar zijn voor downgrade aanvallen, afhankelijk van de toepassing kan dat wel of niet acceptabel zijn.

[frickY]

Ook dat is toch een client probleem?

Voorkom dat je client SSLv3 praat en wat de server eventueel kan doet er niet meer toe.

[Yggdrasil]

Het is inderdaad een client-probleem, maar wél een waardoor de communicatie tussen jou en je klant kan worden afgeluisterd. Dit kan ook gevolgen hebben voor jou, dus kan het verstandig zijn om die aanvalsvector te voorkomen door SSLv3 uit te schakelen.

[frickY]

Dat heeft toch geen enkele zin als een MIT wel SSLv3 biedt?

[Meekoh]

Nou sommige clients (Chrome/Firefox) die waarschuwen hun gebruikers wanneer ze een https verbinding hebben en de webserver SSL3 nog accepteerd (ongeacht of de verbinding op dat moment gewoon tls is)
Krijgen ze zo'n mooi uitroeptekentje/driehoekje/whatever die zegt dat ze geen veilige verbinding hebben.
Dus wil je je huis/tuin/keuken gebruikers niet wegjagen daarmee, dan kun je beter SSL3 etc. disablen.

[SKiLLa]

Juist wel; downgrade attacks zijn namelijk vrij simpel uit te voeren voor een MitM aanvaller, enige clients die geen TLS 1.0 ondersteunen zijn Java 1.6 builds < 45. Verder ondersteunt vrijwel elk apparaat en library toch echt wel minstens TLS 1.0, zelfs als ze 10 jaar oud zijn ...

[WoBBeL]

Lichtelijk offtopic, maar deze tool is een must voor iedereen die op zijn webserver de SSL beveiliging wil controleren.

Deze tool kan ook de genoemde Poodle downgrade attack testen en zaken zoals Hearthbleed

[Reactie gewijzigd door WoBBeL op 27 juli 2024 21:43]

[The Zep Man]

Maar alleen op TCP poort 443.

Die van Comodo is minder uitgebreid, maar heeft wel ondersteuning voor andere poorten.

[edit]
Was een reactie op thorjan.

[Reactie gewijzigd door The Zep Man op 27 juli 2024 21:43]

[mxcreep]

Dan zet je voor de test toch even tijdelijk 443 aan ?

[PegOpDeWeg]

Hoe zit het dan met de SSL certificates, kun je deze dan gewoon blijven gebruiken of kun je deze omzetten of vervangen?

[Hoicks]

Voor zover ik weet is het SSL certificaat gebaseerd op domeinnaam en is het puur om the kijken of je wel met de juiste computers babbelt. Het certificaat zelf is een ondersteunend middel voor SSL encrypted communicatie, maar een certificaat encrypt zelf niks.

Je hoeft het certificaat dan ook niet te vervangen. Je kunt zelfs zonder certificaat wel SSL communiceren, je weet dan echter niet of je endpoints wel de echte endpoints zijn.

[Reactie gewijzigd door Hoicks op 27 juli 2024 21:43]

[Yggdrasil]

Dat is niet correct. Het certificaat wordt wel degelijk gebruikt als sleutel voor de versleuteling. Je hebt dus echt een private key en een bijbehorend certificaat nodig.

Het laten ondertekenen door een certificaatautoriteit (en de verificatie die daarbij gedaan wordt, bijv. op bezit van de domeinnaam) is optioneel, maar wel noodzakelijk als je verwacht dat wildvreemde bezoekers je certificaat moeten vertrouwen. Als je zelf de enige gebruiker bent is een zgn. self-signed certificaat net zo veilig.

Welk versleutelingsalgoritme er word gebruikt voor de SSL/TLS-verbinding wordt niet bepaald door het certificaat maar door de Ciphersuite. Zowel de server als de client hebben zo'n lijst met door hen ondersteunde algoritmes (ciphers) en bij het opzetten van de verbinding onderhandelen ze over de best beshikbare cipher die ze beiden aankunnen. Die cipher wordt daarna, samen met het certificaat, gebruikt om de data te versleutelen.

Overigens zijn er ook certificaten niet allemaal gelijk. Recent zijn bijv. de meeste browsers gestopt met het vertrouwen van certificaten die gebruik maken van de SHA-1 hash-methode, omdat de cryptografische techniek die daarvoor gebruikt wordt niet meer als voldoende sterk wordt gezien voor de komende jaren. SHA256 is nu de norm.

[Reactie gewijzigd door Yggdrasil op 27 juli 2024 21:43]

[GigaPixels]

Klopt.

Zelfs banken en de (Belgische) overheid scoorden slecht, bleek in het verleden.

'Belgische overheidssites hebben ssl-beveiliging niet op orde'

'Belgische banken hebben ssl-beveiliging niet op orde'

[catfish]

werken bijna alle mailtoepassingen niet met SSL?
dat gaat veel aanpassingswerk worden

[_Thanatos_]

SSL-de-library ja, maar niet SSL-het-protocol, mag ik hopen.

[chaoscontrol]

SSL is antiek. Mail werkt prima met TLS.

[catfish]

klopt, maar bij vele maildiensten (onder andere imap bij gmail) wordt gebruik gemaakt van SSL

[Dorank]

Je verward SSL als "standaarden voor encryptie" met het maken van "een verbinding waar je begint met encryptie" in tegenstelling tot TLS waar je begint met "een plaintext verbinding en dan encryptie start" (bv met een smtp starttls commando).

Je kan prima een smtp starttls doen en dan encryptie onderhandelen via de ssl rfcs indien de implementatie toestaat of een smtps verbinding opzetten met de in tls rfcs beschreven methodes. Tenminste dat kon je, aangezien iedereen die een beetje oplet hopelijk de SSLv[123] cypher suites heeft uitgeschakeld.

[CAPSLOCK2000]

En jij verwart TLS met StartTLS. TLS is niks anders dan de naam voor de opvolger van SSL.

StartTLS is een manier om SSL/TLS toe te voegen aan een clear-text protocol. Je zet de verbinding clear-text op en schakelt dan over op SSL/TLS.

[Dorank]

En jij verwart TLS met StartTLS. TLS is niks anders dan de naam voor de opvolger van SSL.

Dat doe ik niet, starttls is een smtp commando, lees de gelinkte rfc! Die rfc refereert naar TLS (rfc2246) omdat die backwards compatible is met de voorgaande SSL rfcs. Met starttls kan je dus ook gewoon sslv123 cyphers onderhandelen.

StartTLS is een manier om SSL/TLS toe te voegen aan een clear-text protocol. Je zet de verbinding clear-text op en schakelt dan over op SSL/TLS.

En hoe is dat anders dan wat ik schreef? smtp is een plaintext protocol, smtps (smtp over ssl, analoog aan https voor http over ssl) is smtp over een versleutelde verbinding, tentijde van de reservering van 465 was er nog geen TLS dus dat de S voor SSL zou kunnen staan is logisch. Dat ten tijde van de invoer van "start encryptie" binnen huidige sessie het starttls werd moge ook duidelijk zijn als je de release dates van de rfcs bekijkt.

[CAPSLOCK2000]

Het gaat me om:

TLS waar je begint met "een plaintext verbinding en dan encryptie start"

TLS begint niet met een plaintext verbinding maar zet als eerdere SSL-versie direct een beveiligde verbinding op.

[bas1286]

Een bijkomstigheid van dit soort besluiten is dat wij als systeembeheerders eindelijk eens wat oudere hardware kunnen vernieuwen. Google en Firefox, etc hebben er namelijk voor gekozen om bij een verouderde/onveilige https-verbinding tegenwoordig een melding te geven. Dit valt tegenwoordig natuurlijk bij alle gebruikers op sinds alle internetbankieren-taferelen, uiteindelijk zelfs bij de beslissings-makers. Volgens mij is voor Chrome sha256 tegenwoordig het minimum wanneer met geen melding wilt ontvangen, ook al wordt er TLS gebruikt.

[SKiLLa]

Ligt complexer; het SHA-256 verhaal gaat over de certificate signature; niet over de versleuteling van de verbinding zelf. Zie ook: http://googleonlinesecuri...lly-sunsetting-sha-1.html

Om 'modern cryptography / groene balk / geen warnings / errors ' te krijgen in de nieuwste Chrome, IE en Firefox moet je dus certs hebben die op RSA 2048 with SHA-256 of langer gebaseerd zijn of langer, dus geen RSA-512/1024 of SHA-1 of MD5 meer in de certificaat-chain (op de root CA na) en tevens dient er moderne, veilige ciphers met Forward Secrecy gebruikt te worden; waarbij AES-GCM de meest gangbare is. Ook b.v. AES-256-CBC is dus niet goed, omdat CBC een niet-authenticated blockcipher is en GCM wel authenticated is (en stukken sneller !).

Voor meer info zie b.v: http://googleonlinesecuri...lly-sunsetting-sha-1.html Of de SslLabs blog: https://community.qualys.com/blogs/securitylabs

[Pwuts]

Ik heb al heel lang het idee dat dit soort verbindingen nooit veilig kan zijn. Dat zal hoogstwaarschijnlijk onterecht zijn, maar ik kan er maar niet vanaf komen.

Dit is ongeveer mijn idee:
Bij SSL-verbindingen worden de verstuurde gegevens versleuteld, om te voorkomen dat ze kunnen worden uitgelezen als ze worden onderschept. Voor ontsleuteling is weer diezelfde sleutel nodig, maar hoe verstuur je die naar de ontvanger? Door de sleutel te versleutelen schiet je niks op, en als je 'm niet verstuurt dan kan de ontvanger de boodschap niet ontsleutelen..

Iemand die dit kan ophelderen?

offtopic:
niet eens 1 puntje voor het stellen van de vraag?

[Reactie gewijzigd door Pwuts op 27 juli 2024 21:43]

[chaoscontrol]

Ja, wiki. https://en.wikipedia.org/wiki/Public_key_infrastructure

De server kant heeft een private sleutel en geeft alleen de publieke sleutel aan jou uit. Jij versleuteld je verkeer met de publieke sleutel en de server kan dit weer decrypten met de private sleutel.

[Pwuts]

En dat verkeer is niet te decrypten met de publieke sleutel (die je kunt krijgen door een sessie aan te vragen)?

Anyways, thanks.

[Rafe]

In theorie wel, maar dat kost zoveel moeite dat het in de praktijk als onmogelijk (en dus veilig) wordt beschouwd. Dit filmpje legt de werking van Diffie-Hellman key exchange uit aan de hand van het mengen van kleuren, erg leerzaam https://www.youtube.com/watch?v=YEBfamv-_do

[MegaTronics]

Alleen heeft Diffie-Hellman ook zijn eigen zwakheden: https://weakdh.org/

Zoals altijd met security zaken, je moet altijd bij de les blijven.

[Rafe]

Logjam gaat over hoe Diffie-Hellman zoals gebruikt in het TLS-protocol zwak kan zijn. Als je bij de les blijft en je server goed configureert is er niets aan de hand.

[MegaTronics]

Precies, vandaar bij de les blijven en goed de security bulletins in de gasten houden en daar naar handelen.

[chaoscontrol]

Het antwoord staat in de wiki.

(Welke er ook in het NL is als het wat moelijke woorden zijn: https://nl.wikipedia.org/wiki/Public_key_infrastructure )

[Pwuts]

Te weinig geduld om het op te zoeken.

Gruwelijk veel dank voor deze opheldering, kan ik ook weer eens slapen.

[the_stickie]

neen. Het is asymmetrische cryptografie. Het decrypten heeft een andere sleutel nodig dan het encrypten.

[Bliep]

Het idee is dat die publieke sleutel gewoon voor iedereen te krijgen is. De private key wil je met je leven beschermen als het ware

Als jij een wachtwoord versleuteld met de public key, dan kan deze alleen weer leesbaar gemaakt worden met de private key. Vice versa echter, als ik iets versleutel met de private key, dan kan iedereen met de public key het lezen. Dus voor 2-weg verkeer wil je twee setjes sleutels hebben

Het probleem is inderdaad als ik tussen jou en de server ga inzitten. Jij zet een sessie op naar een server. De server genereert een public key, die ik vervolgens onderschep. Ik genereer zelf een nieuwe private key en public key, en geef jou mijn eigen public key.
De pakketjes die jij nu versleuteld, decrypt ik, sla ik "plain text" op en vervolgens versleutel ik het allemaal weer met de public key die ik van de server heb gekregen en stuur het zwikje op.
Hier op je dus certificaten voor, die de authenticiteit van een server garanderen. Een TLS/SSL/whatever zonder certificaat is dus niet zo veel waard, omdat je de herkomst/afkomst van pakketjes niet kunt garanderen.

In a nutshell dit. Ik ben geen cryptograaf

[CAPSLOCK2000]

In theorie is het wel terug te rekenen maar in praktijk is dat zo veel werk dat de aarde al lang vergaan is voor je klaar bent.

[Yggdrasil]

Iedereen mag de public-key opvragen en kan daarmee data versleutelen. Alleen de bezitter van de bijbehorende private-key kan de data weer ontsleutelen, niemand anders. Die private-key is in het bezit van de webserver waarmee je verbinding hebt gemaakt.

[AmbroosV]

Tegenwoordig is de key exchange met een algoritme dat ondersteuning heeft voor forward secrecy. Dat wil dus zeggen dat de client en server een key afspreken die uniek is per sessie en niet afgeleid kan worden als het verkeer afgetapt wordt. Gaat meestal om een Diffie-Hellman exchange (DHE), eventueel sneller gemaakt met Elliptic Curve Cryptography (ECDHE).

Tweakers bijvoorbeeld heeft over HTTPS ondersteuning voor ECDHE-RSA, wat wil zeggen dat bij een nieuwe connectie je computer met de servers van Tweakers een nieuwe set RSA-keys afspreekt met behulp van een elliptic curve Diffie-Hellman-exchange. De client encrypt alles dan met een key die alleen de server kan decrypten en omgekeerd. De keys om data te decrypten worden nooit verzonden dankzij Diffie-Hellman.

[SKiLLa]

ECDHE is niet alleen sneller dan DHE, maar omdat het op EC gebaseerd is, ook gebaseerd op andere 'mathematische' principes dan DHE (en m.i. veiliger met het oog op de toekomst, het schijnt - naar huidige inzichten - namelijk ook redelijk quantum-proof te zijn; effectieve bitlengte wordt gehalveerd qua security, dus een 256 bit algo houdt zelfs op een quantum machine een 'sterkte' van 128-bit).

Tevens verwoord je het Forward Secrecy gedeelte niet helemaal lekker; waar het om gaat is dat middels (EC)DHE de session-sleutels niet direct afgeleid van het certificaat zijn, maar 'random'. Wordt een verbinding dus afgeluisterd en opgeslagen en krijgt de aanvaller ook nog de private keys van het certificaat in handen, dan kan de aanvaller alsnog niet 'oude' sessies ontsleutelen ondanks dat die wel de private keys bezit. En dat kan bij reguliere, non-forward secrecy ciphers wel ...

Het sleutelmateriaal wordt dan alleen voor authenticatie/identificatie gebruikt van de andere partij; niet voor het genereren van de session-sleutels.

[Reactie gewijzigd door SKiLLa op 27 juli 2024 21:43]

[bwerg]

EC en ECDHE zijn niet quantumbestendig, het zijn varianten op discrete logaritmen.

[SKiLLa]

https://medium.com/@amarc...-quantum-era-6a7f444ce7d5

In huidige staat niet nee, maar er is wel een post-quantum toekomst mogelijk.
Zie b.v.: http://eprint.iacr.org/2014/599.pdf en http://eprint.iacr.org/2015/376.pdf en http://eprint.iacr.org/ep...20704:152925&file=506.pdf. Dat is uitgaande van AES, ben benieuwd naar b.v. ChaCha in TLS (https://tools.ietf.org/ht...iannopoulos-chacha-tls-05)

[Pwuts]

Even googlen, hier staat nog wat abracadabra in. Anyways, thanks voor de samenvatting.

[Verwijderd]

http://stackoverflow.com/.../how-does-ssl-really-work

Lang verhaal kort: De ssl hand shake verzorgt alle "magie".

[Pwuts]

Dank!

[sven wiltink]

Er zijn 2 Keys, een public en een private key. De public key is als het ware een hangslot zonder sleutel, je kan hem alleen op slot doen. De private key kan het hangslot vervolgens openen. Zolang de private key in bezit van de server blijft kan niemand anders het hangslot openen.

[Pwuts]

Bedankt voor de uitleg in niet-abracadabra.

[the_stickie]

Niets is absoluut veilig, maar het is gelukkig niet zo eenvoudig als de public key opvragen

Trechnologie van dienst:
* PKI (Public Key Infrastructure) om certificaten (sleutels, keypairs) uit te geven en te beheren.
* Assymetrische encryptie: zodat de sleutel die je nodig hebt voor het ontcijferen een andere is dan die voor het vercijferen.

[Aaargh!]

Voor ontsleuteling is weer diezelfde sleutel nodig

Ten eerste bestaat er zoiets als asymmetrische encryptie, dan heb je voor decryptie een andere key dan voor encryptie. De encryptiekey mag je van de daken schreeuwen, in een grote advertentie in de krant zetten, etc. enige wat je er mee kan is encrypten. De decryptiesleutel hou je uiteraard geheim

Verder: https://en.wikipedia.org/wiki/Diffie–Hellman_key_exchange

[Phoenix1337]

In de meest simpele situatie is het zo dat berichten welke met de private key versleuteld worden, ontsleuteld kunnen worden met de public key en en andersom.

Deze manier van versleutelen heeft echter wel als nadeel dat, als de private sleutel publiekelijk bekend wordt, alle berichten die verstuurd zijn ontsleuteld kunnen worden. Met een fatsoenlijk geconfigureerde server wordt tegenwoordig gebruik gemaakt van elliptic curve diffie hellmann waarbij sleutels per sessie genenereerd worden en daarnaast ook voor die sessie uniek zijn. Deze staan dan los van de sleutels van het certificaat. Dit wordt ook wel forward secrecy genoemd. Mochten de sleutels op straat komen, dan zijn berichten uit het verleden nog steeds veilig.

[CAPSLOCK2000]

Het ssl 3.0-protocol werd in 2011 officieel door de IETF gespecificeerd.

Dat is een beetje misleidend. In 2011 is het als "historische document" gepubliceerd. IETF wist ook wel dat het al oud was maar er was nooit een officiele standaard gepubliceerd. Voor de volledigheid hebben ze dat toen nog maar even gedaan.

[Verwijderd]

De TLS-richtijnen van NCSC zijn een mooie bron voor veilige TLS-configuratie. SSLv3 wordt daar (uiteraard) ook als onveilig bestempeld. Zie: https://www.ncsc.nl/actue...t-layer-security-tls.html

De website-test op https://Internet.nl hanteert deze TLS-richtlijnen van NCSC als uitgangspunt. Daar kan je dus eenvoudig checken of een website eraan voldoet.

[Pwuts]

Krijgen we nu dan httpt:// in plaats van https:// ? Of shttp://, dat staat leuker.

[the_stickie]

Nee. https kan prima over TLS, dat is nu ook al het geval.
Meer nog, cliënt en server kiezen welk protocol ze gaan gebruiken naargelang wat ze ondersteunen en een (geconfigureerd) lijstje met prioriteiten (SSL handshake). Als het goed is, gebruik je nu al TLS voor de meerderheid van je SSL verkeer.

dit nieuws heeft dan ook vooral impact op sysadmins en devvers. sysadmins moeten misschien nog wat servers herconfigureren en nagaan of SSLv3 clientside overal uitstaat. Devvers kunnen stilaan beginnen met SSLv3 support compleet te slopen (of althans the disablen)

[Verwijderd]

Volgens mij staat de s in https voor "secure". Of je nu SSL of TLS of een andere encryptie gebruikt, zolang het "secure" is kun je het gewoon https blijven noemen.

[heuveltje]

Het ssl 3.0-protocol werd in 2011 officieel door de IETF gespecificeerd.
Ssl 3.0 wordt al jaren als verouderd beschouwd,

Ik weet dat dingen snel gaan. maar dat iets binnen 4 jaar al jaren als verouderd word gezien is wel heel erg

[Robo]

Tja, als de standaard zelf stuk blijkt te zijn dan kan het heel snel gaan. We hebben het hier dus niet over een foutje in een implementatie. Dat kun je nog wel oplossen met een patch. Hier zit de fout in het protocol en dat kun je alleen oplossen door het protocol te vervangen. Bijvoorbeeld dus met TLS1.2

[SKiLLa]

Maar dat is dus NIET zo. RFC 6101 is gewoon de 'final revision' van SSLv3; de intro tekst zegt ook duidelijk 'dit document bevat alleen wat tekstuele aanpassingen' geen nieuwe en/of gewijzigde specificaties. Net zoals dat de bijbel nog elk jaar herdrukt wordt ...

Sterker nog, TLS 1.0 (de opvolger van SSLv3) stamt al uit 1999; dus het werd echt wel tijd dat SSLv3 begraven wordt. Zeker met TLS 1.2 en AES-GCM en Forward Secrecy (ECDHE/DHE) wordt het internet niet alleen veiliger, maar ook stukken sneller. Zo is AES-GCM t.o.v. klassieke 3DES-CBC snel een factor 15-30x sneller op moderne hardware (en dus ook nog veiliger). Waar de SSL/TLS scalability/performance overhead rond 2000 nog rond de 40% lag, is dat anno 2015 eerder maximaal 4%. Alle partijen die dus zeggen 'HTTPS/TLS is moeilijk/duur/schaalt niet', doen gewoon hun huiswerk niet

[bas1286]

Had ik vergeet begrepen dan, bedankt voor je aanvulling.
Al met al toch een positieve vooruitgang.