Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 78 reacties

Een onderzoeker heeft een aanval ontwikkeld op HTTP Strict Transport Security, een standaard die websites gebruiken om browsers te dwingen https te gebruiken. Met de methode zou een kwaadwillende via een man-in-the-middle-aanval logingegevens kunnen onderscheppen.

Gebrek aan sslNaast Linux-gebruikers zijn ook gebruikers van OS X Lion kwetsbaar, zo deed beveiligingsonderzoeker Jose Selvi uit de doeken op de Europese editie van de Black Hat-beveiligingsconferentie in Amsterdam. In theorie zijn ook OS X Mavericks en Windows 7 en 8 kwetsbaar, maar in de praktijk is voor die besturingssystemen geen realistische aanval op te zetten. De aanval vereist dat de verbinding van het slachtoffer kan worden onderschept, bijvoorbeeld met een vervalst wifi-toegangspunt.

De aanval die Selvi ontwikkelde maakt het mogelijk om HTTP Strict Transport Security compleet te omzeilen, een feature die ervoor moet zorgen dat een gebruiker een bepaalde website alleen via https kan bezoeken. De veilige methode wordt ondersteund door Chrome en Firefox; Internet Explorer volgt binnenkort.

Standaard verloopt het eerste verzoek aan een webserver altijd via http. Sites die https gebruiken, moeten de gebruiker dan ook forwarden naar de https-versie van hun website. Daar zit een kwetsbaarheid: een aanvaller kan die http-request onderscheppen en ervoor zorgen dat de https-sessie niet met de gebruiker, maar met de aanvaller wordt opgezet. De aanvaller kan de inhoud van de pagina's vervolgens via http doorsturen naar de gebruiker.

Websites kunnen dankzij hsts middels een http-header laten weten dat ze in het vervolg alleen nog maar https kunnen bezoeken; zelfs als de verbinding van een gebruiker daarna wordt onderschept, is hij op websites met hsts in principe veilig, omdat de browser weet dat die sites enkel over https mogen worden bezocht. Daarnaast bevatten Chrome en Firefox een lijst met veelgebruikte websites zoals PayPal en Google die sowieso enkel over https mogen worden bezocht.

In beide gevallen is hsts te omzeilen, stelt Selvi. Dat komt doordat beide features leunen op tijd. Een website laat weten tot hoe ver in de toekomst een https-verbinding moet worden afgedwongen, bijvoorbeeld voor een maand. Hetzelfde gebeurt in de broncode van Chrome: die eist dat websites als PayPal en Google tot drie jaar in de toekomst enkel via https kunnen worden bezocht.

Selvi bedacht daarom een truc om de tijd op het besturingssysteem te veranderen: als die immers drie jaar in de toekomst ligt, geldt de verplichting van de website om enkel https te gebruiken niet meer. Het manipuleren van de tijd bleek op Ubuntu en Fedora vrij eenvoudig: die besturingssystemen updaten de systeemtijd regelmatig via het network time protocol.

Dat protocol heeft wel ondersteuning voor beveiligde verbindingen, maar standaard is dat niet ingeschakeld. Jose was daarom in staat om vervalse ntp-pakketten te versturen, waardoor de systeemtijd op drie jaar in de toekomst werd ingesteld. Daardoor gold de http strict transport security policy van de websites niet meer, en kon de verbinding van websites alsnog worden onderschept. "Tijd is gewoon niet iets waar je op zou moeten vertrouwen", aldus Selvi.

Gebruikers van Fedora zijn het meest kwetsbaar: dat besturingssysteem synchroniseert elke minuut de tijd, waardoor de aanval het meest eenvoudig op is te zetten. Ubuntu synchroniseert de tijd elke keer bij het booten of als er een netwerkverbinding wordt gemaakt. Een aanvaller zou de verbinding met een beoogd slachtoffer kunnen beëindigen, waarna die de verbinding opnieuw moet maken en de tijd weer wordt gesynchroniseerd. OS X Lion is eveneens kwetsbaar: dat besturingssysteem synchroniseert elke negen minuten de tijd.

Windows-gebruikers zijn minder kwetsbaar. Windows 7 en 8 synchroniseren elke zeven dagen, en bovendien accepteert het besturingssysteem geen wijzigingen in de tijd die groter zijn dan vijftien uur. Daardoor is geen realistische aanval op te zetten voor dat besturingssysteem. OS X Mavericks is ironisch genoeg niet kwetsbaar doordat de tijd niet goed op de achtergrond wordt gesynchroniseerd.

Google heeft in een reactie laten weten dat het gaat om 'een bekend probleem met http'; de browsermaker lijkt dan ook niet van plan te zijn om het probleem op te lossen.

Moderatie-faq Wijzig weergave

Reacties (78)

Ah, het probleem zit dus niet in de browser, maar in de standaardinstellingen van NTP. Het lijkt me daarom ook volkomen logisch dat Google niet van plan is het probleem op te lossen.

edit: Interessant om te zien dat er voor Ubuntu al ruim twee jaar een open bug is, maar dat deze als importance 'Wishlist' heeft. De mogelijkheden die in dit artikel worden beschreven zijn ook genoemd in dit report:
Putting the clock several years back allows an adversary to use already revoked, broken, expired certificates; replay old, broken, outdated, known vulnerable updates etc.
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1039420

[Reactie gewijzigd door cyberstalker op 16 oktober 2014 11:55]

Als het in Linux gebaseerde OS's zit, zou Android dan ook niet kwetsbaar zijn? In dat geval lijkt me dat Google dit ook niet zomaar kan negeren?
Dat ligt er aan hoe makkelijk het is om de tijd op een Android device aan te passen is door er kunstmatige ntp packetjes heen te sturen. Als Android elke minuut of 5 minuten de tijd aanpast heb je de mogelijkheid om een verbinding in de toekomst op te zetten.

Wat ik raarder vind is dat er voor sommige sites wel een verplichting is om altijd https te gebruiken (en dat is goed) maar dat het maar voor een beperkte tijd is, waarbij beperkt ook nog eens 3 jaar is. 3 jaar is een eeuwigheid in browser versies, dus je kan het net zo goed zonder tijdslimiet doen. Lijkt mij een simpele fix, maar waarschijnlijk zie ik dan iets over het hoofd.
Lijkt me dat ze die 3 jaar als redelijke tijd zagen voor als je browser een tijd niet bijgewerkt wordt (om wat voor reden dan ook); bij Google gaan ze er (denk ik) meestal van uit dat browsers nooit lang op oude versies blijven staan.
Dan nog is er geen reden om toe te staan dat deze sites na 3 jaar opeens geen https nodig hebben.
Je kan veel beter die sites altijd https laten gebruiken totdat een update van de browser vertelt dat ze van de lijst af mogen. Ik kan namelijk geen scenario bedenken waarin het wenselijk is dat zo'n site na lange tijd wel over alleen http mag verbinden.
Idd waarom een tijdslimiet, het is of niet of wel https.

De tijdserver bug is wat dat betreft een goed voorbeeld van de zwakste schakel.
Zal het niet zo zijn dat die drie-jaars limiet bij elk gebruik opnieuw wordt gereset? Dat de drie jaar onder normale omstandigheden dus allen zou verlopen wanneer je de zite drie jaar niet bezoekt?
Dat zou wel de manier zijn waarop ik het zou implementeren.
Ik zou geen tijdslimiet er op zetten. Zou het nodig zijn om een bepaalde site niet meer standaard op https af te handelen dan is er een update nodig, maar dat is er bij een limiet van 3 jaar ook (of de 3 jaar moet net om zijn.

Nee, ik zie werkelijk geen noodzaak voor een limiet.
Wat ik vreemd vind is dat bij het opzetten van een https sessie met de aanvaller dan toch nog steeds een verkeerd certificaat zichtbaar moet zijn of mis ik iets ?
Telefoons sync'en meestal hun tijd met de GSM masten. Die zijn iets moeilijker om te controleren.
En GPS is een nog betrouwbaardere bron, want die hebben atoomklokken aan boord. Het spoofen van een satelliet op een paar honderd kilometer hoogte die met een paar duizend kilometer per uur vliegt is ook iets lastiger.
Het is wel prima te doen, hoor, althans voor iemand die zich erop toelegt. Je hoeft alleen maar een iets sterker GPS-signaal naar de ontvanger te sturen om het echte GPS-signaal weg te drukken, en GPS is normaliter een zeer zwak signaal, dus dat kan in een koffertje:

"University of Texas team takes control of a yacht by spoofing its GPS"
At a point some 30 miles (48 km) off the coast of Italy, graduate students Jahshan Bhatti and Ken Pesyna began to send a faint set of GPS spoofing signals from their briefcase-sized transmitting device on the upper deck of the yacht. As they increased the strength of their signals, the ship's GPS location system eventually was thoroughly spoofed – paying attention only to the UTexas team's spoofing signals.

At this point, the indicated course of the yacht was altered by a few degrees, although the ship had not actually turned. The spoofed GPS then reported a difference between the ship's location and the desired course, and altered course to return to the correct course. Of course, in doing so it took on a course that same few degrees different from the proper course. By continuing to maintain this discrepancy, the yacht showed in its wake that the ship was turning, even though the electronic chart of the navigational system showed the ship was on a steady course. This is shown in the form of an animation in the video below.

“The ship actually turned and we could all feel it, but the chart display and the crew saw only a straight line,” Humphreys says. “This experiment is applicable to other semi-autonomous vehicles, such as aircraft, which are now operated, in part, by autopilot systems. We’ve got to put on our thinking caps and see what we can do to solve this threat quickly.”
http://www.gizmag.com/gps-spoofing-yacht-control/28644/

[Reactie gewijzigd door Cerberus_tm op 16 oktober 2014 19:15]

Dus zet even een gemanipuleerde femtocel op en je kan van elke gsm in de buurt de tijd laten aanpassen...

Zoals in het artikel staat, op tijd mag je niet vertrouwen.
Telefoons sync'en meestal hun tijd met de GSM masten. Die zijn iets moeilijker om te controleren.
Je bedoelt manipuleren.
standaard zit in Android geen NTP client, enkel een client voor synchronisatie met de tijd van je mobiele netwerk (en dat is in praktijk niet zo'n zuivere methode)
Er bestaat een open source app NTPSync die (op Android met root) de systeemtijd wel via NTP kan aanpassen.
Een website laat weten tot hoe ver in de toekomst een https-verbinding moet worden afgedwongen, bijvoorbeeld voor een maand. Hetzelfde gebeurt in de broncode van Chrome: die eist dat websites als PayPal en Google tot drie jaar in de toekomst enkel via https kunnen worden bezocht.
Als je wilt dat bepaalde site enkel over https bezocht mogen worden waarom zit er dan een tijdslimiet op tot hoever in de toekomst de https-verbinding afgedwongen moet worden? Wat dat betreft kan je weldegelijk stellen dat het probleem in de browser zit. Misschien zelfs in het protocol? Maar als er een limiet op de tijd mag zitten dat je https afdwingt kan je ook verwachten dat met tijdsmanipulatie het afdwingen tot https te omzeilen is.
edit: Interessant om te zien dat er voor Ubuntu al ruim twee jaar een open bug is, maar dat deze als importance 'Wishlist' heeft. De mogelijkheden die in dit artikel worden beschreven zijn ook genoemd in dit report:
https://bugs.launchpad.net/ubuntu/+source/ntp/+bug/1039420
Willen alle Ubuntu gebruikers even 'This bug affects me' aanklikken? Dank!
Ik snap sowieso niet dat bijvoorbeeld Fedora elke minuut de tijd moet syncen... Wat is daar het nut van?
Er zijn 2 manieren om tijd te synchroniseren middels NTP:
1) via ntpdate. Dit is een eenmalige synchronisatie die meestal tijdens bootup gebeurd (of na herstel van netwerkverbindingen). In veel gevallen draait deze ook in een cronjob - dwz elke zoveel minuten.
2) via ntpd: deze draait in de achtergrond en synchroniseert continue. Continue, betekent dat ntpd elke zoveel tijd pakketten uitwisselt met een ntp server.

Er zijn bovendien 2 aspecten aan klok-synchronisatie:
- absolute tijd: Je wil dat de tijd correct staat voor allerhande toepassingen. Maw de absolute afwijking moet klein zijn.
- drift: Je wil dat jouw klok evensnel loopt als de atoomklok. Klokkristallen hebben een afwijking die typisch binnen de 100ppm valt. Dit wil zeggen dat je met een slecht kristal max 8s/dag afwijking kunt hebben. Na 8 dagen loop je dus al een minuut achter. Sommige applicaties rekenen erop dat de klok synchroon loopt tov andere machines, dus moet je deze drift corrigeren.
Helaas moet je, om drift te kunnen corrigeren vrij regelmatig synchroniseren met een ntp server (hoewel die tijd varieert afhankelijk van de nauwkeurigheid die je al hebt).

Met ntpd kun je dus drift corrigeren (en meteen ook een goede absolute tijd hebben), wil je enkel het eerste punt, dan is het voldoende om met enige regelmaat ntpdate te draaien.

Vermoedelijk draait deze met zo'n korte tijdspanne omdat er geen andere trigger (bvb netwerk is terug up&running) is en ze de tijd tussen beschikbaar zijn van correcte tijdsinfo en het updaten van de lokale klok relatief klein willen houden.

Sommige security-gerelateerde protocol vereisen dat de tijd binnen aanvaardbare marges is om replay aanvallen tegen te gaan (waarbij iemand een volledige opname van een transactie afspeelt). Nonces (uniek gegenereerde getallen) zijn hier echter ook afdoende (wat Selvi waarschijnlijk bedoelt met het "niet vertrouwen op tijd").
De ntp deamon zal na opstarten van de verbinding eerst vaak kijken, en daarna steeds minder vaak als eenmaal het verloop van de interne klok gekarakteriseerd is.
En OSX Lion iedere 9 minuten. Dat is nog steeds 160x per 24 uur, wat mij een beetje overdreven lijkt.
Soms heb je systemen waarvan de tijd vreselijk snel verloopt. Heb al computers gezien waar de tijd met meerdere minuten per dag verloopt. Als je dan applicaties hebt waar je een corrrecte tijd wenst te zien kan je niet anders dan te synchroniseren op korte intervallen. Sommige applicaties houden er namelijk niet van dat een klok ineens zomaar verspringt.
Hangt ook een beetje van de toepassing af. Voor een doorsnee desktop toepassing is de tijd niet kritisch, maar als je servers hebt die bijvoorbeeld in een mobiel netwerk de positie van een gebruiker moeten bepalen moet je opeens een veel nauwkeurigere tijdbasis hebben.
Al met al vind ik het een nogal omslachtige manier van hacken. De aanvaller moet dan sowieso binnen het bereik van je WIFI zitten en die verbinding weten te onderscheppen. Aangezien bij mij het hele netwerk is bekabeld zou ik dus praktisch geen gevaar moeten lopen.

Goed dat wordt aangetoond dat dit lek / deze bug aanwezig is zodat er aan gewerkt kan worden, maar feitelijk worden er maar weinig problemen gevonden in Linux die echt een gevaar zijn voor de gemiddelde gebruiker.
Kwestie van op Schiphol gaan zitten en een netwerk op te zetten met de naam "Schiphol_free_wifi" o.i.d. en voila. Een willekeurig café, Starbucks, MacDonnalds, etc. werkt natuurlijk net zo goed. Dus nee: thuis loop je hier geen risico op. Met publieke netwerken is het natuurlijk sowieso uitkijken geblazen. Eigenlijk zou je daarover alles via een VPN moeten tunnelen als je ze al gebruikt.

Wellicht zou linux ook niet standaard zonder interactie erg grote veranderingen in de tijd moeten accepteren.
Ik had ooit mijn ntp server gestart met de '-x' flag welke forceert dat veranderingen in tijd via kleine stappen wordt uitgevoerd. Het bijstellen van 10 minuten (600 s) duurt dan 14 dagen. Klinkt goed, maar veel landen hebben tweemaal per jaar te maken met een grote verandering in de tijd, namelijk de zomer- en wintertijd..

Een van de redenen waarom ntp standaard wijzigingen groter dan 600 s niet via slew mode uitvoert heeft onder andere te maken met zomertijd issues. Slew mode wordt vooral gebruikt om geen te grote veranderingen in tijd te krijgen in de logbestanden.

Veel logdaemons geven een speciale markering om aan te geven dat er in een bepaalde periode geen log activiteit is geweest, maar dat de daemon zelf nog wel draait. Op productie servers wil je niet dat je log daemon uitstaat.

beetje offtopic:
Zelf geeft ik als optie aan syslogd '-m 3' aan welke in elk geval elke 5 minuten een '--MARK--' in de logs moeten terug komen. Ik heb een log parser welke elke 4 minuten een signaal stuurt naar Nagios. Als drie opeenvolgende signalen uitblijven, dan krijg ik een email. Dit is een extra controle naast de 'syslogd' daemon check..

In een ver verleden heb ik het ooit meegemaakt dat door een configuratie fout syslogd niet naar de logbestanden kon schrijven. Op zo'n moment blijft syslogd gewoon doordraaien, waardoor Nagios (destijds BigBrother) niet in de gaten geeft dat de logging niet goed gaat..

Ik behoort dus slechts tweemaal per jaar een melding te krijgen dat de system logs te grote afwijkingen vertonen.

ontopic:
Maar browsers kunnen ook wel het een en ander doen. De reden dat HSTS aanvallen nu zo populair zijn heeft te natuurlijk ook te maken met het feit dat Google websites welke alleen op HTTPS draaien een hogere ranking te geven. Het zou daarom prettig zijn dat browsers eerst controleren of het betreffende domein SSL/TLS ondersteund, ook als expliciet een http url wordt ingevoerd (bijvoorbeeld vanuit een email). Dan vermijd je HSTS exploits..

Eigenlijk is het best wel jammer dat je HSTS niet gewoon via DNS kunt specificeren. Via DNSSEC kun je de authoritive DNS server beschermen. Er is dan ook geen mechanisme meer nodig waarbij browser fabrikanten een expire list moeten bijhouden van 3 jaar..

DNSSEC en SPF is inmiddels een zeer goede combinatie. Dus waarom zou je niet een een 'hsts.(www.)domain.org' txt record kunnen aanmaken waar je vermeld wat het HTTPS adres van de website is?

De gehele ntp time hack is dan in een klap waardeloos..
Klinkt goed, maar veel landen hebben tweemaal per jaar te maken met een grote verandering in de tijd, namelijk de zomer- en wintertijd..
NTP werkt altijd in UTC. De tijd word in het OS omgezet naar je lokale tijdzone, dus dit is geen probleem.

[Reactie gewijzigd door Plofkotje op 16 oktober 2014 14:05]

ik denk dat het helemaal niet zo omslachtig is en het ook regelmatig gebruikt word. Zie de gehackte email accounts van het eu parlement
En het is juist het soort hack dat je uit wilt voeren als je iemand zijn data aan het onderscheppen bent. Ook al kun je het misschien vrij simpel uit zetten de meeste mensen zullen dat niet doen.
Maar IE gebruikers op Windows zijn nog kwetsbaarder, daar worden HTTP sites nooit doorgestuurd naar HTTPS middels HTTP Strict Transport Security, aangezien hier nu nog geen ondersteuning voor is. Dan is dit wel heel veel extra moeite die een aanvaller moet doen om ook een paar Ubuntu/Fedora gebruikers aan te kunnen vallen. Dan moet je je wel echt richten op een specifiek persoon...

[Reactie gewijzigd door Elijan9 op 16 oktober 2014 13:40]

Al met al vind ik het een nogal omslachtige manier van hacken. De aanvaller moet dan sowieso binnen het bereik van je WIFI zitten en die verbinding weten te onderscheppen. Aangezien bij mij het hele netwerk is bekabeld zou ik dus praktisch geen gevaar moeten lopen.
En je kan jezelf in het wild tegen 99% van alle aanvallen op de verbinding beschermen door gewoon altijd een VPN te gebruiken naar huis. Daarnaast is je WiFi thuis relatief lastig om te spoofen als je gebruik maakt van WPA2 (AES). Je kan natuurlijk ook 802.1x authenticatie implementeren met (eigen) certificaten om er zeker van te zijn dat de verbinding die je draadloos opzet ook echt met een eigen apparaat aan de andere kant is.
Goed dat wordt aangetoond dat dit lek / deze bug aanwezig is zodat er aan gewerkt kan worden, maar feitelijk worden er maar weinig problemen gevonden in Linux die echt een gevaar zijn voor de gemiddelde gebruiker.
Het is een instellingsprobleem. De standaardinstellingen aanpassen is voldoende om het een onrealistisch aanvalsscenario te maken.
Dus gebruik een NTP daemon ipv ntpdate. Een ntp daemon zal de tijd geleidelijk aanpassen in plaats van in een keer de tijd aan te passen. Dus als de ntp daemon te horen krijgt dat hij 3 jaar achter loopt zal de NTP daemon de secondes korter maken om zo geleidelijk de tijd in te halen. (maar dat duurt wel even).
Behalve bij een te groot verschil, dan krijg je toch een "step" update?
Standaard doet ntpd niets als de afwijking groter is dan 1024 seconde, juist om deze redenen. Ntpdate kent deze beperking niet.
Dus als gebruiker moet je gewoon altijd 'https' intikken als je bijvoorbeeld naar je internet bankieren site gaat. Lijkt mij.

Kan https niet de default gemaakt worden ?
En mocht de site dit niet ondersteunen kan de browser altijd nog plain http gebruiken.
Browsers kunnen toch zowel een 'https' en een 'http' request sturen ?
HTTPS is bij deze sites de default, alleen als je een URL invoert zal je browser standaard eerst de http versie proberen. De webserver geeft dan terug "Ja leuk maar probeer HTTPS effe", en dat is hetgene wat hier onderschept kan worden. Bepaalde browsers zoals Chrome hebben een lijst ingebakken van sites die hij altijd als https probeert te openen. Het lijkt me trouwens triviaal voor browsers om voor elke ingevoerde URL of bookmarks HTTPS als eerste proberen op te zetten - ik zie dat binnenkort nog wel gebeuren.
Het stuk geeft aan dat HSTS juist wel aangeeft dat de browser eerst HTTPS gaat proberen naar specifieke URL's. De exploit zit hem er in dat de browsers dit ingesteld hebben met een einddatum.
Dus als je een website bezoekt via HTTP, dan werkt het mechanisme niet meer om automatisch over te schakelen naar HTTPS. Volgens mij is dit eenvoudig te verhelpen door https://www.eff.org/https-everywhere te installeren en sowieso altijd de https variant van websites te kiezen?

Maar dit heeft toch niets met Linux te maken, het gaat alleen om de combinatie browser-met-hsts en een OS-distributie dat regelmatig via internet (over een onbeveiligd protocol) de interne tijd synchroniseren, waardoor de tijd ineens een grote sprong kan maken? Alleen in dat geval kan HSTS omzeild worden, maar als de tijd zo ingrijpend verandert, dan valt dat toch ook wel anders op? (Veel SSL certificaten van nu zijn over drie jaar ook ineens verlopen...)

Internet Explorer op Windows lijkt mij trouwens vele malen kwetsbaarder, omdat deze blijkbaar nooit automatisch overschakelt op HTTPS via HSTS en er dus niet eens iets valt om te omzeilen :+
Linuxgebruikers kunnen tlsdate van Jacob Appelbaum gebruiken:
tlsdate: secure parasitic rdate replacement

tlsdate sets the local clock by securely connecting with TLS to remote
servers and extracting the remote time out of the secure handshake. Unlike
ntpdate, tlsdate uses TCP, for instance connecting to a remote HTTPS or TLS
enabled service, and provides some protection against adversaries that try to
feed you malicious time information.

https://github.com/ioerror/tlsdate/
DNSSec - waarom wordt daar niet over gewauweld - ook daar loopt veel mis mee. We bankieren veilig - maar de dns is onversleuteld - walgelijk is dat.
heh, nou zit ik me te bedenken, als je van ergens in de US (UTC -8) naar Japan (UTC + 9) vliegt (niet over de datumlijn), en je windows systeem synchroniseerd z'n tijd. Gaat die dat dan weigeren?

Vreemd dat in de titel enkel Linux gebruikers gewaarschuwd worden, die meestal tech savvy genoeg zijn om dit op te vangen, terwijl OS X Lion gebruikers er ook de dupe van (kunnen) zijn. Die gaan dan minder snel dit artikel bekijken.

[Reactie gewijzigd door Soggney op 16 oktober 2014 12:04]

Nee, dan veranderd de computer tijd namelijk niet. Die houdt zijn tijd bij in UTC, alleen de tijdzone wordt dan veranderd.
Standaard houdt Windows de hardware klok op lokale tijd (nog een MSDOS erfenis). Dus is er altijd een risico dat er een skew van +/- 15 uur optreed. Vooral als je het systeem dual boot gebruikt gaat dit een probleem zijn. Je moet een register instelling in Windows wijzigen om de hardware klok op UTC tijd te laten lopen.

De +/- 15 uur geeft voor Windows wel praktische bescherming tegen al te gekke klok manipulaties. Ben wel benieuwd hoe Mountain Lion dit opgelost heeft zodat die blijkbaar niet meer kwetsbaar is op dit punt. Lion wordt genoemd, maar hoe zit het met oudere OSX versies?
Nou nee, want de Windows tijd is gewoon 'UTC -8' of 'UTC +9'; die UTC tijd wordt gesynchroniseerd, en die wijkt niet zoveel af na een vlucht.
Ik heb standaard op een paar sites
[code]
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule (.*) https://%{HTTP_HOST}%{REQUEST_URI}
[/code]

Op poort 80 staan. Vang je het hier niet mee af?
Nee, want als de HTTP versie al ondergeschept is/gemanipuleerd kunnen er al dingen voorgeschoteld worden..
Op de server valt er niet zo veel af te vangen denk ik. Wat deze hack doet is aan de client kant (de browser) het https host request afvangen en naar zijn eigen site redirecten.
Als ik het goed begrijp is het zo dat de man-in-the-middle-aanval sneller als de website de https verbinding terug stuurt waardoor de browser https gaat doen met de verkeerde server.

dus ik denk dat dit een client-side probleem is die niet kan worden afgevangen op de server.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True