Lek in tls en ssl maakt man-in-the-middle-aanval mogelijk

De Amerikaanse software-ontwikkelaar Marsh Ray heeft een kwetsbaarheid in het transport layer security-protocol naar buiten gebracht. Hierdoor zouden man-in-the-middle-aanvallen op met ssl beveiligde verbindingen mogelijk zijn.

De door Ray beschreven kwetsbaarheid in het tls-versleutelingsprotocol - tezamen met het oudere secure sockets layer-protocol - was deze zomer al ontdekt door de beveiligingsfirma PhoneFactor, maar het bedrijf besloot een geheimhoudingsverklaring te tekenen en de informatie alleen te delen met een aantal bedrijven en de IETF. Ontwikkelaar Martin Rex ontdekte het lek echter ook en publiceerde zijn bevindingen. Inmiddels heeft ook Ray zijn bevindingen openbaar gemaakt.

Het probleem in het tls-protocol doet zich voor tijdens de handshake waarbij een beveiligde server en de webbrowser van de eindgebruiker elkaars certificaten controleren, waarna een unieke sleutel wordt afgesproken. Tijdens een met ssl versleutelde verbinding kan een van de twee partijen om een nieuwe encryptiesleutel verzoeken, waarna een nieuwe ssl-sessie wordt gestart. Dit proces verloopt door enkele beperkingen in het http-protocol echter deels onversleuteld, waardoor een hacker een man-in-the-middle-aanval kan uitvoeren en het verkeer tussen de browser en een server kan worden onderschept.

In theorie kan de hacker ongemerkt data toevoegen, terwijl de eindgebruiker via een beveiligde ssl-verbinding denkt te werken. De kwetsbaarheid in tls en de oudere ssl-protocollen zou al met succes aangetoond zijn op een aantal webservers; beveiligingsonderzoekers slaagden erin om Apache- en IIS-webservers te verbinden met een gemanipuleerde tls-server die zich voordeed als een webbrowser.

Omdat onder andere banktransacties en andere gevoelige informatiestromen met het ssl-protocol worden versleuteld, heeft het IETF een werkgroep in het leven geroepen om een uitbreiding op het tls-protocol te ontwikkelen die het beveiligingslek moet dichten. Naar alle waarschijnlijkheid zijn er in de tijd dat de kwetsbaarheid nog geheim was, al wel patches ontwikkeld voor webservers om het probleem in ieder geval tijdelijk onschadelijk te maken. Ook de ontwikkelaars van OpenSSL en GNU TLS hebben patches aangekondigd.

Reacties (71)

[Orion84]

Voor een uitgebreide uitleg en analyse van de impact vond ik http://www.educatedguessw...ing_the_tls_renegoti.html wel een mooi duidelijk stukje

Het gaat dus echt om een tamelijk beperkte aanval, die minder sterk is dan andere reeds bekende aanvallen op beveiligde verbindingen, maar wel een die wat lastiger is om jezelf tegen te wapenen schijnbaar.

[Verwijderd]

Omdat onder andere banktransacties en andere gevoelige informatiestromen met het ssl-protocol worden versleuteld, heeft het IETF een werkgroep in het leven geroepen om een uitbreiding op het tls-protocol te ontwikkelen die het beveiligingslek moet dichten.

Gelukkig werken we in Nederland bij de banken met een digipas, randomreader etc. Waardoor het man in de middle spelen voor een succesvolle transactie een stuk moeilijker is dan voor de landen waar nog steeds met een plain password gewerkt wordt.

Maar door deze designfout van het protocol is het helaas niet meer onmogelijk.

Tevens zin hierdoor ssl vpns in een keer een stuk onveiliger. Daarom maar terug naar alleen maar IPsec VPN.

[wildhagen]

Gelukkig werken we in Nederland bij de banken met een digipas, randomreader etc.

Behalve dan de Postbank die nog met briefjes en SMS-jes met ouderwetse TAN-codes werkt, dan is het man-in-the-middle alweer een stuk makkelijker, als je toegang hebt tot die codes, bijvoorbeeld doordat je iemands GSM steelt (of hij hem laat liggen).

Bij de overige banken zit je idd iets veiliger omdat je idd een challenge-response systeem gebruikt.

[SirBlade]

En als nu iemand je randomreader steelt? Beide zijn dus evern (on)veilig. Ik zou echter sneller merken dat iemand m'n gsm heeft gestolen dan wanneer m'n randomreader weg is. de eerste gebruik ik meerdere keren per dag, de andere 1 of 2 keer per maand.

[wildhagen]

Random Reader is niet gekoppeld aan je pas of aan een persoon. Ik kan keurig mijn pas gebruiken in de reader van mijn buurman. De hash staat op de pinpas, niet in de reader.

De oude Digipass was volgens mij wel persoons/pas-gebonden, maar dat ding is 6-7 jaar geleden ofzo al uit de roulatie genomen.

[Reactie gewijzigd door wildhagen op 3 augustus 2024 16:13]

[ari3]

Er staat geen hash van je pincode op een pin pas... Anders zou je gewoon 10.000 combinaties kunnen proberen tot je de pincode gevonden hebt.

De random reader controleert helemaal geen pincode, maar gebruikt deze wel om een berekening te maken. De bankserver vergelijkt de uitkomst van deze berekening met zijn eigen berekeking.

[wildhagen]

Er staat geen hash van je pincode op een pin pas... Anders zou je gewoon 10.000 combinaties kunnen proberen tot je de pincode gevonden hebt.

Alleen blokkeert je pas wel als je meer dan 3x een foute pincode intikt op de reader, dus 10.000 pogingen zijn onmogelijk.

De random reader controleert wel degelijk je pincode, die gehashed op de pas staat. Tik maar eens met opzet een foute pincode in, krijg je toch echt een melding "FOUTIEVE PIN!" op het schermpje te zien.

Op het forum is hierover een hele discussie met uitleg geweest, interessant leesvoer. Lees wel ff het hele topic door, want in het begin worden er een aantal onjuistheden gepost die later worden gecorrigeerd.

[Reactie gewijzigd door wildhagen op 3 augustus 2024 16:13]

[stefanass]

Voor zo ver ik weet heb je bij de randomreader ook nog de bankpas & pincode nodig, in ieder geval bij de Rabobank. Aan alleen de randomreader heb je dus niets, sterker nog, je kunt elke willekeurige (Rabo-)randomreader gebruiken voor internetbankieren bi jde Rbaobank.

[smokalot]

Het gaat om de chip op je bankpas die je in de randomreader moet steken, de randomreader kun je gewoon kopen.

Waarschijnlijk heb je het wel snel door als je bankpas gestolen wordt.

[RobertMe]

Dan heb je een randomreader waar je niks aan hebt Randomreaders kun je gewoon uitwisselen, aangezien hij werkt samen met de bankpas (+pincode) waarschijnlijk zal de randomreader gewoon een "challange" doen tussen de chip in de bankpas en de code die je in vult. Ik gok zo dat de code die je terug krijgt door de bankpas word gegenereerd, dus moet je al mijn bankpas + pincode hebben voordat je iets ermee kunt. Met een mobiele telefoon gaat het dan al allemaal iets makkelijker.

[Milt]

De reader is onbelangrijk. Die kun je bij de banken zo krijgen. Als je misbruikt wilt maken moet je iemand zijn bankpas hebben (chip, dus geen kopie van de magneetstrip) en de pincode weten.

[humbug]

Naast de randomreader heb je ook mijn pinpas nodig en moet je mijn pincode weten. Dus zelfs als je alle hardware jat kun je er nog niet.

[dcm360]

[...]
Behalve dan de Postbank die nog met briefjes en SMS-jes met ouderwetse TAN-codes werkt, dan is het man-in-the-middle alweer een stuk makkelijker, als je toegang hebt tot die codes, bijvoorbeeld doordat je iemands GSM steelt (of hij hem laat liggen).

Wie dan ook het idee krijgt om alsnog een opdracht te verzenden terwijl zijn/haar telefoon niet bereikbaar is, snap ik dan ook niet echt. Of is het zo raar dat je eerst je telefoon erbij pakt omdat je die zo nodig hebt? Met de telefoon zou ik dan ook wel veiliger willen noemen dan met alleen papier, omdat een wat intelligentere dief ook het papiertje kan kopieeren (en terugleggen).

[Reactie gewijzigd door dcm360 op 3 augustus 2024 16:13]

[Countess]

maar dit beperkt ook gelijk de scope van de aanval. je moet eerst bij iemand inbreken of zijn telefoon stelen voor je er zelf maar aan kunt denken om zijn bank verkeer te onderscheppen.
en als je dat kan, kan je ook gewoon op zijn computer een aangepaste browser installeren, dat is een stuk gemakkelijker.

[Verwijderd]

Precies. Het concept van TAN codes is daarom juist één van de allerveiligste, aangezien de TAN-codes zelf niet te genereren zijn. Je moet daadwerkelijk spullen stelen van je slachtoffer.

Ouderwets betekent niet per definitie slecht...

[Sfynx]

Precies. Het concept van TAN codes is daarom juist één van de allerveiligste, aangezien de TAN-codes zelf niet te genereren zijn. Je moet daadwerkelijk spullen stelen van je slachtoffer.

Bij de challenge response methode van de andere banken moet je de bankpas en pincode van het slachtoffer stelen (aangezien de smartcard een cruciaal element is van het genereren van de code). Zoals je bij alle banken kan doen om te gaan pinnen van iemands rekening.

En dan is de gegenereerde toegangscode code maar zeer kort geldig. En bij hogere bedragen gebaseerd op een extra invoercode (het bedrag), althans bij de Rabobank. Dus wat is veiliger?

[Reactie gewijzigd door Sfynx op 3 augustus 2024 16:13]

[Glashelder]

Het Challange Response systeem zal veiliger zijn maar is extreem onhandig omdat je altijd zo'n irritante reader bij je moet hebben. Heb jij die altijd bij je?

(Mijn telefoon heb ik altijd bij me ja)

[Reactie gewijzigd door Glashelder op 3 augustus 2024 16:13]

[Verwijderd]

In het geval van de ING:
Iemand moet mijn inlogcode hebben, en mijn mobiel.
Kans is niet heel groot dat ik inlog als mijn mobiel gejat is, want ik kan geen tancodes ontvangen.

[GekkePrutser]

Toch vind ik dat ook niet zo'n goed systeem. Een heel stuk van de beveiliging is nu in handen van de mobiele telefoonmaatschappij, en dus niet onder controle van de bank of de gebruiker zelf. De TAN's worden immers niet versleuteld verstuurd. Wel door de lucht, maar niet binnen het netwerk van de mobiele operator.

Dat is voor mij een reden dat ik nog steeds met de papieren versie werk.

[markjanssen]

Goedzo... de papieren versie gaat met de post (niet in controle van bank of klant) en kan onderschept (of achteraf gekopieerd worden).
Je weet niet of de papieren versie is gestolen (kopie). Bij de sms-tancodes worden ze verstuurd zodra ze nodig zijn, en altijd binnen een minuut. Je hebt vrij snel door als er iets mis is, of je ineens tancodes aan het ontvangen bent zonder dat je zelf aan het bankieren bent.
Ik ben daarom toch gewoon naar de sms-versie geswitched... die vertrouw ik een stuk meer (vooral vanwege reactiesnelheid, inzicht in de situatie)

[mcDavid]

knappe jongen die mijn mobiel steelt, ontdekt dat ik een postbank-rekening heb, ontdekt wat mijn accountnaam is én mijn password via deze SSL-lek ontfrutselt, vóórdat ik mijn nummer geblokkeerd heb... Een pasje skimmen is makkelijker.

[latka]

Om het nog lastiger te maken: de hacker moet ook nog de juiste SSL connectie breken en dit zijn er nogal wat richting de Postbank. Kans dat het lukt: nihil.

[SkyStreaker]

Ten eerste:

Als jij je telefoon niet meer kan vinden en je bent hem echt kwijt, dan meldt je dat aan de politie en in dit geval ook aan ING. TAN wordt geblokkeerd.

Bovendien, deze persoon moet EN je loginnaam hebben en je wachtwoord. Als je dat laat slingeren oid dan ben je gewoon niet handig bezig.

Je moet dergelijke dingen gewoon meteen melden.

[mjtdevries]

Behalve dan de Postbank die nog met briefjes en SMS-jes met ouderwetse TAN-codes werkt, dan is het man-in-the-middle alweer een stuk makkelijker, als je toegang hebt tot die codes, bijvoorbeeld doordat je iemands GSM steelt (of hij hem laat liggen).

Bij de overige banken zit je idd iets veiliger omdat je idd een challenge-response systeem gebruikt.

Grappig dat mensen blijkbaar automatisch denken dat wanneer iets ouderwets is, dat het dan ook minder goed is.

Juist het TAN code systeem is extreem veilig.
Een challenge-response systeem zoals de andere banken gebruiken is in principe te kraken. Een TAN code systeem is dat per definitie niet omdat er geen algortime aan ter grondslag ligt. En wat er niet is, kun je ook niet kraken.

Niet voor niets gebruiken CIA (en de voormalige KGB) een soortgelijk systeem.

[Pixeltje]

Natuurlijk ligt er iets van een algoritme achter de TAN codes. Het is niet alsof de ING 3500 mensen in dienst heeft die dag in dag uit hele velden voltikken met door hun getrokken cijfers. De bankapplicatie van ING controleert of jou tancode voldoet aan de code die bij de ING in het systeem staat.

[YopY]

Gelukkig bestaat de Postbank niet meer, .

[jbtbnl]

De Postbank klanten die automatisch naar de ING zijn gegaan gebruiken nog altijd het systeem van de Postbank, dus met TAN-codes.

[MAher]

Heerlijk systeem, geen aparte reader of een lijstje met codes, gewoon een sms-je en klaar.
En zoals beneden gezegd niet minder veilig dan die andere 'nieuwerwetse' systemen.

[Drexz]

Dat snap ik niet helemaal, als ik 10 euro overschrijf naar rekening 1234 en jij voert een MITM aanval uit en wijzigt de 10 euro in 100 en de 1234 in 1422 dan is de code die ik via mijn digipas apparaat heb gemaakt toch nog geldig? Of werkt de code ook op basis van bedrag en rekening nummer?

Want bij een MITM aanval zie je ook mijn response code.

[Reactie gewijzigd door Drexz op 3 augustus 2024 16:13]

[YopY]

Dat snap ik niet helemaal, als ik 10 euro overschrijf naar rekening 1234 en jij voert een MITM aanval uit en wijzigt de 10 euro in 100 en de 1234 in 1422 dan is de code die ik via mijn digipas apparaat heb gemaakt toch nog geldig? Of werkt de code ook op basis van bedrag en rekening nummer?

Nou, nee, want bij een beetje encryptie met een bevestigingssleutel die je in moet voeren (zie rabobank) wordt het bedrag en het rekeningnummer (en nog andere gegevens, zoals identificatie van je browser (dwz de bron van het request) en nog meer sleutels) meegenomen. Dus jij zegt 'Stuur 10 euro naar 1234', Rabobank zegt 'Hey, voer de code <willekeurig>101234 eens in je apparaatje', apparaatje genereert een code op basis van <willekeurig>101234 én nog gegevens die alleen jij en je bank weten (pas informatie, pincode), en die stuur je terug. Als ook maar één van die dingen afwijkt (ander rekeningnummer, ander bedrag, of andere afzender) dan wordt de betaling niet doorgevoerd.

De basis van encryptie: De gegevens (doel rekeningnummer, bedrag), en gegevens die alleen jij en je bank horen te weten (pas informatie, PIN-code, en de pasinformatie weet je zelf niet eens). Dat, plus verificatie dat degene die het request start en ook afmaakt, én nog een keer een beveiligde verbinding (SSL / TLS) zorgt ervoor dat je betaling veilig zou moeten zijn.

[ls470]

Toch lijkt't me iets ingewikkelder dan dat:

jij zegt aan de aanvaller: 'stuur 10 euro naar 12345'
Die geeft dat door aan de bank als 'stuur 666 euro naar 31337' (de bankwebsite weet dus niet dat je maar 10 euro wou overschrijven)
De bank geeft een code die je intikt (voor die transactie) en als dat apparaatje zelf geen schermpje heeft waarop staat voor welke bestemming en bedrag die code dient weet je niet dat je de toestemming aan het vragen/geven bent voor een andere transactie...
Wat uit dat apparaatje komt is dan uiteraard een geldige authorisatie voor 'stuur 666 euro naar 31337' en niet voor wat je op het (fake) scherm van webbanking ziet: 'stuur 10 euro naar 12345'

[MBV]

Bij de ABN-amro werkt dat zo. Vroeger was dat moeilijker, dan werden willekeurige getallen uit de opdracht gehaald, wat de Rabo nog steeds doet. Dat maakt MITM moeilijker, maar niet onmogelijk: ipv €10 naar 12341234 wordt het nu €750 naar 12344321...

[sickyb]

Bij hogere bedragen moet je eerst een signeercode in de reader invullen en daarna nog het bedrag (voor de komma) in de random reader invullen voordat je je authorisatie code krijgt.

[MadEgg]

En bij nog hogere bedragen moet je ook nog het rekeningnummer (of was het een deel van?) van de begunstigde invoeren.

De mate van beveiiging is dus adaptief aan hoeveel geld er over gemaakt zal worden, best netjes geregeld vind ik.

[wildhagen]

Ik weet niet of het bij alle banken zo is, maar bij de Rabobank zit het bedrag afaik verwerkt in de code, via een of ander algoritme. Het bedrag zomaar aanpassen gaat dan dus niet werken.

Iig werkt het zo met de Random Reader. Of het met de ouderwetse Digipass ook zo werkt weet ik niet, maar bijna niemand gebruikt dat ding nog.

Ik mag aannemen dat dit bij andere banken op een vergelijkbare manier werkt.

[stefanass]

En bij grotere bedragen (ik dacht boven 1000 euro) moet je als extra controlecijfer ook in de randomreader het bedrag invoeren, alvorens je de transactiecode terugkrijgt.

[wildhagen]

Boven de 750 euro is dat volgens mij, en boven (ik dacht) 1500 euro moet je zelfs twéé extra controlegetallen invoeren.

Onder de 750 euro hoeft je maar één controlegetal (8 cijfers) in te tikken, maar volgens mij zit daar e.e.a. in verwerkt. Naast het bedrag iig ook datum/tijd, want als je te lang wacht met het invoeren werkt de code niet meer en moet je een nieuwe aanmaken.

[GravGunner]

ook moet je het totale bedrag invoeren als je meer als 3-4 overschrijvingen tegelijk maakt(zonder boven de 750 uit te komen)

Ook mag je maar een x bedrag overmaken(dacht max 2200 ofzo) alles hoger als dat bedrag MOET je bij de bank langs

[mr.zeno]

Dit is bij mijn abn-amro reader helaas helemaal niet het geval.

Ben nog nooit iets anders tegengekomen dan de standaard challenge en response (en ik heb toch wel al betalingen gedaan die ruim boven de genoemde bedragen vallen).

[Ozzie]

Bij de ABN moet soms ook extra nummers en het bedrag worden ingevuld. Ik weet neit uit me hoofd precies meer bij welke bedragen maar volgens mij pas boven de 1000 euro en bedragen invullen boven de 3000 euro.

[Sunbeam-tech]

Ik weet niet wat het maximale bedrag is maar iig geen 2200 euro
Ik heb wel eens 5500 Euro overgemaakt met de random reader en dat ging prima.
Alleen moest ik wel drie keer een controle getal en één keer het bedrag in typen.
Waarschijnlijk zal het ergens bij de 10.000 Euro liggen voor dat je naar de bank moet om het over te maken.

[ASS-Ware]

Ik weet niet wat het maximale bedrag is maar iig geen 2200 euro
Ik heb wel eens 5500 Euro overgemaakt met de random reader en dat ging prima.
Alleen moest ik wel drie keer een controle getal en één keer het bedrag in typen.
Waarschijnlijk zal het ergens bij de 10.000 Euro liggen voor dat je naar de bank moet om het over te maken.

Veel meer dan dat gaat ook prima, dus ik vrees van niet.

[ASS-Ware]

ook moet je het totale bedrag invoeren als je meer als 3-4 overschrijvingen tegelijk maakt(zonder boven de 750 uit te komen)

Ook mag je maar een x bedrag overmaken(dacht max 2200 ofzo) alles hoger als dat bedrag MOET je bij de bank langs

Ik heb laatst vanaf de ABN geld overgemaakt voor de aanschaf van een auto en die was veel duurder dan 2200 euro en dat ging toch echt goed.
Jouw stelling klopt dus niet.

[RobertMe]

Ik weet niet of het bij alle banken zo is, maar bij de Rabobank zit het bedrag afaik verwerkt in de code, via een of ander algoritme. Het bedrag zomaar aanpassen gaat dan dus niet werken.

Niet altijd, deze extra invoer is pas nodig als het bedrag boven een bepaald aantal euro's uit komt. Je moet altijd 1 code invullen, bij een laag bedrag blijft het daarbij, bij een hoger bedrag komen daar nog 1 of 2 codes bij (waarvan eentje het bedrag is)

[graceful]

Klopt, ook bij transacties boven de duizend euro wordt er nog een extra code gevraagd die een combinatie van deze twee verwerkt in de response code van je random reader.

[Abom]

Door het gebruik van jouw pinpas en randomreader, ben jij de enige die de transactie kan bevestigen. Stel jouw ssl verbinding met de bank is onderschept, dan is het alleen mogelijk voor de hacker om mee te lezen, zodra er mutaties plaats vinden, moeten die bevestigd worden door pinpas + pincode + randomreader + code van bank.

[A4-tje]

waarom maken ze het dan niet onmogelijk om een nieuwe sleutel aan te vragen voor een nieuwe SSL-verbinding?
ben je meteen van de problemen af... misschien dat je dan een keertje opnieuw moet inloggen omdat hij de verbinding niet in stand kan houden ofzo, maar dat weegt natuurlijk wel op tegen geld kwijt zijn...

[Orion84]

Omdat er verschillende toepassingen zijn waar wel degelijk met goede redenen gebruik wordt gemaakt van deze functionaliteit. Bijvoorbeeld om keys te verversen, of om voor het ene deel van een applicatie een sterkere key te vereisen dan voor een ander deel etc.
Oké, het kan ook best zonder, een aantal redenen zijn inmiddels achterhaald. Maar dat neemt niet weg dat je dat niet zomaar even van de een op de andere dag omgooit.

De huidige fix voor OpenSSL bestaat dus uit het uitschakelen van die renegotiation functie. Maar applicaties die het nog nodig hebben kunnen het wel weer inschakelen (anders zouden immers een boel applicaties om zeep geholpen worden).

De uiteindelijke fix zal moeten bestaan uit een verbeterde renegotiation functie die niet voor de gek gehouden kan worden. Of het definitief afschaffen van het gebruik van die functie en alle applicaties die het gebruikten aanpassen. Beide zaken die je niet even van de een op de andere dag doorvoert.

[Orion84]

Of die toepassingen kwetsbaar zijn voor deze aanval is maar de vraag. De aanvaller kan, als ik het goed begrijp, het eerste pakketje dat van de client naar de server gaat lezen en/of aanpassen, omdat het plaintext is. Bijvoorbeeld voor http, de allereerste GET request die de client doet.
Doordat de MITM vantevoren een beveiligde verbinding heeft opgezet, namens de client, accepteert de server de opdracht in een aangepast pakketje ook als daar eigenlijk al een beveiligde verbinding voor had moeten zijn. Want die beveiligde verbinding is er immers al en wordt door misbruik te maken van de renegotiation functionaliteit hergebruikt.

De vraag is dus of dergelijke toepassingen kwetsbaar zijn als een attacker één kwaadaardige opdracht kan injecteren. Zonder daarbij resultaten te kunnen zien en dergelijke.

Het is niet zo dat de attacker ineens complete SSL verbindingen plain text kan meelezen hè

[Reactie gewijzigd door Orion84 op 3 augustus 2024 16:13]

[cdwave]

Dan moet ik je toch wakker schudden.

TLS beveiligt de verbinding tussen jou en je bank, niet alleen door de encryptie, maar vooral door ervoor te zorgen dat je zeker weet dat je ook met de bank communiceert en niet met "iets ertussen", een man-in-the-middle dus.

Je digipas helpt hier niet tegen - de man in the middle kijkt rustig toe tot je een betaalopdracht verstuurt. Hij wijzigt alleen het rekeningnummer van de begunstigde (om maar een voorbeeld te noemen), daarna geef jij netjes je codes door en hupsakee daar gaat je geld.

[Verwijderd]

Hoogste tijd voor TLSv2.
Kunnen ze eindelijk misschien ook fixen dat je voor elke https site een apart ip nodig hebt (of dat je met alternatieve poorten moet gaan kutten).

[latka]

Dat kan al met TLSv1 mits je browser (en server!) het ondersteunen. Alle moderne browsers kunnen dit (IE8, Firefox & Opera). Aan de serverside: Apache kan het, maar IIS niet. M.a.w. het kan gewoon maar als je IIS gebruikt wordt het tijd voor een serverupgrade.

[toonp]

Het klopt niet.
Als je je realiseert op welke OSI-laag TLS zit en op welke OSI-laag virtual hosting
is geïmplementeerd, dan begrijp je dat de combinatie (TSL+virtual hosting) gewoon
niet mogelijk is.
Nou ja... je kunt per IP-adres één host voorzien van SSL/TLS, maar daar houdt het dan ook op.

[Verwijderd]

Dat betekent dus niet dat virtual hosting niet op de tls laag geimplementeerd kan worden. Zie paragraaf 3.1 van de TLS Extensions specificatie: SNI. Dat is precies wat ik bedoelde.

[Verwijderd]

Volgens http://httpd.apache.org/docs/2.2/ssl/ssl_faq.html#vhosts kan dat nog steeds niet. Dus als jij een methode weet hoe dat wel kan, hoor ik dat graag.

Edit: mod_gnutls lijkt dat inderdaad te kunnen. Niet standaard, maar misschien wel interessant om eens te bekijken.

[Reactie gewijzigd door Verwijderd op 3 augustus 2024 16:13]

[brompot758]

Standaard staat in een certificaat de DNS naam van de server waar je naartoe gaat als subject (het CN gedeelte om precies te zijn). Als je extra servernamen in de Subject Alternative Name opneemt (in het formaat DNS=www.wat.dan.ook) kun je met een moderne browser ook over HTTPS met name based virtual hosts werken.

[PolarBear]

http://support.microsoft.com/kb/187498

[Verwijderd]

Kunnen ze eindelijk misschien ook fixen dat je voor elke https site een apart ip nodig hebt (of dat je met alternatieve poorten moet gaan kutten.

Dat gaat lastig worden, en ten koste van de beveiliging. Voordat het SSL verkeer gedecrypt kan worden, moet eerst een handshake plaatsvinden mbv het certificaat.
Je weet pas welk certificaat je kunt gebruiken als je weet welke naam er in het request staat. Kortom, er zou dan al een vorm van decryptie plaats moeten vinden voordat het verkeer gecontroleerd is tegen een certificaat. Dat levert weer andere veiligheidsproblemen op.

[Verwijderd]

Dat hoeft niet lastig te zijn.
Je zegt zelf: je weet pas welk certificaat je kunt gebruiken as je weet welke naam er in het request staat. De oplossing is simpel: haal de naam uit het request.

De hostname is niet geheim, die is namelijk ook te sniffen (probeer maar met wireshark of zo). Dus als de eerste conversatie niet is het uitwisselen van de ssl certificaten maar onderhandeling over de hostname, dan gaat het niet ten koste van de veiligheid, maar levert het wel virtual name hosts op.

Kort gezegt: Als het HTTPS request voor de inhoudelijke afhandeling zou beginnen met "STARTTLS <hostname>" is dit probleem opgelost.

[Oguz286]

Niet helemaal on-topic, maar ik heb over een half uur een tentamen Network Security waarbij we hebben geleerd dat TLS en SSL veilig zijn Toch maar even met de docent praten hierover

[wildhagen]

Ze zijn ook veilig, en zeker veiliger dan unencrypted HTTP. PAP etc.

Zoals uit het artikel ook op te maken is, is het risico vrij klein, en er zullen binnenkort ongetwijfeld wel patches voor de relevante zaken komen.

[SirNobax]

Ach, je heb ook bepaalde SSL "exploits" d.m.v. Certificate chaining, het is voornamelijk heel theoretisch en absoluut mogelijk, maar puntje bij paaltje is het voor de 'geldverlangende criminelen' veel makkelijker om met een bivakmuts op een tankstation te overvallen.

[Reactie gewijzigd door SirNobax op 3 augustus 2024 16:13]

[Orion84]

* Orion84 is wel benieuwd wat Pras er over te vertellen heeft, of geeft inmiddels iemand anders dat vak?

[Verwijderd]

Dit proces verloopt door enkele beperkingen in het http-protocol echter deels onversleuteld,

In mij beleving kan dit niet.

Het HTTP protocol draait in laag 7 van het OSI model, de applicatielaag. SSL en TLS draaien in laag 6 van het OSI model, de presentatielaag. Dit houdt in dat het SSL gebeuren voor HTTP transparant is, en het HTTP protocol dus ook niet van invloed moet zijn op SSL, gezien het feit dat deze niets anders doet dan optreden als een versleutelde tunnel.

[Orion84]

Die opmerking ben ik in het oorspronkelijke artikel ook niet tegengekomen en volgens mij heeft het ook niks met een beperking van het HTTP protocol te maken. Ik denk een gevalletje ongelukkige formulering van de auteur die het probeert in eigen woorden uit te leggen

[TeddyBeertje]

En dat is nou net het probleem. Hoe kan SSL weten dat het een tunnel moet opzetten en welke encryptie sleutels. Dit wordt dus eerst door een request van HTTP gedaan (webbrowser). Daarna wordt pas de tunnel gemaakt.

Misschien raar voorbeeld.
Wij spreken wat af in het openbaar dat we de volgende code gebruiken. Maar 1 iemand hoort die code omdat wij in het openbaar spreken. Nu gaan wij briefen schijfen in die code die persoon weet de code omdat wij in het openbaar hebben gepraat. Dus kan hij ook de briefen ontcijferen.

[Reactie gewijzigd door TeddyBeertje op 3 augustus 2024 16:13]

[Verwijderd]

Misschien raar voorbeeld.
Wij spreken wat af in het openbaar dat we de volgende code gebruiken. Maar 1 iemand hoort die code omdat wij in het openbaar spreken. Nu gaan wij briefen schijfen in die code die persoon weet de code omdat wij in het openbaar hebben gepraat. Dus kan hij ook de briefen ontcijferen.

Nee, zo werkt het nou net niet.
Het systeem dat gebruikt wordt om codes af te spreken werkt op basis van variant van Diffie-Hellman encrypte. DH zorgt ervoor dat 2 personen over een onveilig communicatiepad een sleutel kunnen afspreken, zonder dat iemand die afluistert iets met die code kan.

Waar dit systeem op gebaseerd is, dat jij met iemand een code aan het afspreken bent, maar dat ik vlak daarvoor (waarschijnlijk door tussen jullie in te gaan staan en jouw bericht even tegenhouden) ook een code met die ander heb afgesproken. Daarna stuur ik jouw code-verzoek door, met een boodschap erbij: "Joh, ik ben toch niet zo blij met die code die we afgesproken hebben, laten we een nieuwe code afspreken!". Ik kan daarna nog steeds jouw bericht aan die ander niet ontcijferen, maar ik kan wel een bericht invoegen voor jouw bericht, waarvan die ander denkt dat jij 'm gestuurd hebt.

[Keiichi]

Openssl is reeds ook al met een patch uitgekomen

Changes between 0.9.8k and 0.9.8l [5 Nov 2009]

*) Disable renegotiation completely - this fixes a severe security
problem (CVE-2009-3555) at the cost of breaking all
renegotiation. Renegotiation can be re-enabled by setting
SSL3_FLAGS_ALLOW_UNSAFE_LEGACY_RENEGOTIATION in s3->flags at
run-time. This is really not recommended unless you know what
you're doing.
[Ben Laurie]

[Thrilseeka]

dit fixen ze vast wel wss. alleen best lullig dat je denkt lekker beveiligd te werken

[Orion84]

Er is al een quickfix: renegotiation mogelijkheid slopen op de server. Maar dat is niet altijd handig, aangezien er een boel applicaties zijn die daar gewoon gebruik van maken. Daarnaast kan je als client niet goed zien of een server wel of niet renegotiation uitgeschakeld heeft. Een attacker kan de foutmelding namelijk faken, waardoor de client denkt dat er geen renegotiation mogelijk is en hij veilig zit.

Een echte fix betekent een aanpassing aan het TLS protocol, wat niet ff 1-2-3 klaar is natuurlijk. Of het herschrijven van al die individuele applicaties die gebruik maken van renegotiation, zodat ze zonder kunnen.

Maargoed, zo dramatisch is het allemaal niet. Iemand voert niet zomaar ff een MITM aanval op je uit, dat is nog niet zo makkelijk als het klinkt (tenzij je je wifinetwerk niet goed beveiligt, of je op een of ander netwerk zit waarvan je niet weet wie er nog meer op zit). En dan nog zijn de mogelijkheden met deze aanval best beperkt, voor zover ik kan overzien.

Neemt niet weg dat er hopelijk inderdaad zo snel mogelijk een goede fix voor komt

[Reactie gewijzigd door Orion84 op 3 augustus 2024 16:13]

[Barleone]

Hurray, ik heb zojuist een XSS attack op hotmail.com gehad. Kreeg gezellig een "hi" op mijn beeldscherm. Meer mensen met dit probleem? Of kan ik hiervoor beter een topic voor openen op GoT?
Zie Hotmail: javascript pop-up "HI"

[Reactie gewijzigd door Barleone op 3 augustus 2024 16:13]