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 , , 51 reacties
Bron: MSDN Blogs

Op MSDN's Internet Explorer Weblog is informatie verschenen omtrent nieuwe HTTPS-veiligheidsfeatures binnen Internet Explorer 7. Het HTTPS-protocol is een versleutelde versie van het HTTP-protocol en wordt voor bijvoorbeeld e-commercetransacties gebruikt. De meeste wijzigingen schroeven de standaardveiligheidsinstellingen van de browser omhoog en zijn in IE6 met de hand in te stellen.

Allereerst zal het standaardoverdrachtsprotocol dat in IE6 wordt gebruikt, SSLv2, in IE7 standaard worden uitgeschakeld; in plaats daarvan zal gebruik worden gemaakt van de krachtigere SSLv3- of TLSv1-protocollen, omdat er nog maar een klein aantal sites zou zijn dat SSLv2 gebruikt. Daarnaast komt er een aantal veranderingen voor de gebruiker in het geval er problemen met de veiligheidscertificaten van een site zijn. Waar de IE6-gebruiker nog om een keuze wordt gevraagd of de website voor de huidige en/of toekomstige sessies vertrouwd dient te worden, zou IE7 de toegang iedere keer blokkeren en de gebruiker waarschuwen. Hierbij is er weliswaar de mogelijkheid de onheilstekens te negeren, maar door de waarschuwingen heenklikken zou wel een prominent roodgekleurde adresbalk opleveren; daarnaast wordt alleen veilig geachte HTTPS-content op de betreffende pagina gerenderd. Via instellingswijzigingen is evenwel te bereiken dat eventueel aanwezige HTTP-content toch te zien is. Volgens Microsoft zijn dit soort wijzigingen in de standaardinstellingen belangrijk omdat weinig webdevelopers, laat staan gebruikers, de risico's zouden begrijpen van het binnen een HTTPS-pagina renderen van objecten die middels HTTP zijn afgeleverd.

Ook biedt IE7 ondersteuning voor een aantal nieuwe versleutelingsalgoritmes, waaronder de Advanced Encryption Standard, die sleutellengtes tot en met 256 bits aankan. Ten slotte is de TLS-implementatie verbeterd, waarbij een oud probleem met virtueel gehoste sites opgelost zou zijn. Door de extra veiligheidseisen van HTTPS moet een server zijn digitale certificaat afgeven voordat het de HTTP-headers van de browser ontvangt. Als er echter meerdere subdomeinen op hetzelfde IP-adres worden gehost kan het misgaan; de server heeft dan geen headers om te bepalen welke content er naar de browser moet. De nieuwe TLS-implementatie zorgt daarom dat de bedoelde hostnaam bekend is in de aanvankelijke handshake tussen client en server.

IE 7 ssl-features
Moderatie-faq Wijzig weergave

Reacties (51)

Ook biedt IE7 ondersteuning voor een aantal nieuwe versleutelingsalgoritmes,
In de bron hebben ze het over Vista. Ik hoop echter dat al deze features gewoon in IE7 komen en IE7 ook voor XP beschikbaar komt.
slotte is de TLS-implementatie verbeterd, waarbij een oud probleem met virtueel gehoste sites opgelost zou zijn.
Ik ben blij dat het eindelijk ondersteund wordt, maar het is wel erg jammer dat het zo lang heeft moeten duren.
Ik hoop het niet, ik hoop liever op dat het OPTIES worden om te installeren..

* 786562 iTec
jij en ik niet.
maar ik ben wel blij als de leek iets word opgedragen om te gebruiken voor zijn eigen veiligheid.
scheeld mij iniedergeval weer een hoop werk en maakt het internet weer een stukje veiliger.
slotte is de TLS-implementatie verbeterd, waarbij een oud probleem met virtueel gehoste sites opgelost zou zijn
http://www.ietf.org/rfc/rfc2817.txt (of http://www.faqs.org/rfcs/rfc3546.html ?) Alleen moet de webserver dat dan ook wel weer ondersteunen...

Hoe zit het eigenlijk met TLS 1.1?
Helaas is 2817 protocol specifiek.
3546 is wel goed.
Ik hoop wel dat de mogelijkheid blijft bestaan om self-signed certificaten permanent te accepteren, anders komen een hoop hobby-projecten en anderen met een kleine beurs toch wel in de problemen.
* 786562 fremar
Mijn webmail is https (https://webmail.xs4all.nl)
Als ik nu daar een HTML-mail bekijk is de content(de plaatjes) vaak gehost bij de verstuurder van de info-mail.

Wat is er gevaarlijk aan deze situatie, althans zo gevaarlijk dat ik gewaarschuwd zou moeten worden door een grote rode balk? :?
Ze kunnen statisieken van die plaatjes halen en evt achter bepaalde gegevens komen als jij je pc niet beveiligt hebt aangezien je toch verbinding moet maken met een server waar die plaatjes gehost staan.
De spammers weten vervolgens dat jouw email adres werkt en gelezen wordt. Kunnen ze meer geld vragen bij het verkopen van je email adres. :)
Niet echt een beveiligings probleem, maar toch.

Bij communicatie naar hetzelfde domijn gaan dezelfde cookies over de http verbinding als over de https verbinding en zou dus je sessie-key onderschept kunnen worden.
Bij communicatie naar hetzelfde domijn gaan dezelfde cookies over de http verbinding als over de https verbinding en zou dus je sessie-key onderschept kunnen worden.
Daar heb je secure cookies voor.
Dit is helemaal niet waar MS (en manicmind waarschijnlijk ook niet) het over heeft als ze het probleem beschrijven. Dat probleem is er namelijk net zo hard bij 2 HTTP verbindingen (HTML-mail + de webmail interface). het gaat erom dat allerlei (cross-site)scripting uitgevoerd kan worden en gegevens uitgelezen kunnen worden over je sessie. Spammerts zijn bijzaak.

Dit is dus een voorbeeld van de webdevelopers en gebruikers die het veiligheidsrisico niet goed inschatten
Het weergeven van plaatjes in mails vind ik inderdaad een hele goede. Een van de standaardmethoden van spammers om te achterhalen of je hun zooi leest, is het plaatsen van unieke ID's in dat soort plaatjes.

Dus standaard uitgeschakeld: graag.

Natuurlijk valt het met mail op zich wel mee, omdat je mails hoe dan ook niet zo kan vertrouwen en is de versleuteling daar puur voor de privacy, maar toch. En ook vwb privacy is het goed om een rode balk te krijgen, dan weet je meteen dat %vriendin% of %baas% kan meekijken ondanks de HTTPS.
Wat is er gevaarlijk aan deze situatie, althans zo gevaarlijk dat ik gewaarschuwd zou moeten worden door een grote rode balk?
Voor plaatjes is het waarschijnlijk geen probleem maar voor scripts (ads) bijvoorbeeld wel.
Voor plaatjes is het wel een probleem, vaak staat er als bron van het plaatje iets van:
www.reclame.com/feclame.php?from=<a href=\"mailto:een@mail.adres\">een@mail.adres</a>
En zo kunnen ze achterhalen wie hun mail leest.
Dat heeft niks met http/https te maken. Dat is een issue van je mail reader.
Ja, en het gaat er hier om dat het webmail is. Dus waardoor zal je mailtje gerenderd worden?
Dus waardoor zal je mailtje gerenderd worden?
Hopelijk door een mail reader die slim genoeg is om img tags te veranderen in a tags. Het blijft de taak van de mail reader, niet van de browser om dat te doen.
wanneer iemand een script laadt, deze de header van een image meegeeft, en in het script weer linkt naar een andere image, dan zie jij dus de image die je moet zien, maar het script zie jij niet. En het wordt wél uitgevoerd. En dat kan dus zeker gevaarlijk zijn.
Hoewel alle verbetering aan Internet Explorer natuurlijk welkom zijn (en dan met name die verbeteringen die het leven van web-developers gemakkelijker maakt) vraag ik me af waarom dat dit zo'n prominent nieuws-item waard is.

Volgens mij ondersteund Firefox namelijk al enige tijd 256 bit SSL certificaten...
Ik kan je redenatie niet echt volgen. Nieuws heeft niet altijd te maken met wie het eerste iets ondersteund.
Nee precies, bovendien, als er in Internet Explorer security-features geimplementeerd worden dan is dit toch echt nieuws waard :)
Nieuws heeft echter wel te maken met verwachtingspatronen.

Je verwacht toch als je > E 80 voor een besturingssysteem lapt, dat je niet meer word afgescheept met de beveiligingststandaarden van gisteren?

Je verwacht van een bedrijf dat $1 miljard aan R&D besteed, dat er af en toe wat nuttigs uitkomt op het gebied van veiligheid?

Net zoals je verwacht dat morgen de zon opkomt, waar meestal maar 2 lullige regeltjes aan gewijd worden in heel de krant (op/ondergang).

In plaats daarvan is het 'nieuws' dat eindelijk de nieuwste bestaande veiligheidsstandaarden geïmplementeerd worden, en dat onder druk van een concurrent.

En blijkbaar is het geen nieuws, als er niks fatsoenlijks met die $1 miljard R&D gebeurd (ter vergelijking: hetzelfde bedrag als Philips besteed) die de kopers van Windows opgehoest hebben, voor dat geld worden alleen een beetje anderen nageaapt, die veel security-dingetjes het als eerste geïmplementeerd hadden, waardoor 10% marktaandeel verloren werd aan een gratis webbladerprogramma.

En kom nou aub niet aanzetten met al die 'leipe' projecten die MS allemaal financiëert, want die onderzoeken zijn leuk, maar leven in de praktijk bitter weinig op.
Firefox ondersteund de AES (256-bits) standaard nog niet.
Echt wel. Probeer maar eens uit. :)
Ik was zelf verrast te zien dat op mijn eigen site "als vanzelf" 256 AES encryptie had met FireFox, en 128 bit encryptie met IE6. De website was Apache met SSL erin gecompileerd.
Precies. Dit is niet echt schokkend bijzonder nieuws. Ik kan bij mij Firefox instellingen gewoon SSL 1.0, 2.0 èn 3.0 aanvinken. Microsoft heeft me nog steeds niet overtuigt met IE (vs. Firefox) :Y)
In Firefox heb ik een tijdje SSLv2 uitgeschakeld maar ik kwam toch nog een aantal sites tegen die deze versie nodig hadden. Slecht natuurlijk. Hopelijk zorgt de introductie van IE7 ervoor dat webmasters zich gedwongen voelen om over te schakelen op betere beveiliging. Veel sites gebruiken ook nog maximaal 128bit versleuteling terwijl 256bit (AES) allang bestaat. IE6 ondersteunt het echter niet dus voelen de meeste webmasters zich niet geroepen het te installeren.

@Luuk: Een webmaster die zo denkt, neemt beveiliging niet serieus. Daarbij, als het je beroep is dan is het toch een kleine moeite om AES te implementeren? Je hoeft geeneens rekening te houden met sitebezoekers zolang de oudere beveiligingsmethoden beschibaar blijven. Als ik echter creditcardgegevens of andere gevoelige informatie verzend dan kijk ik altijd even of er 256bit AES wordt gebruikt. Voelt wel zo prettig :).
Tja, je kan natuurlijk niet verwachten dat elke keer als er een nieuwe standaard uitkomt alle bestaande sites switchen.

Het kan me voorstellen dat je nieuwe sites uiteraard volgens de dan geldende standaarden bouwt, maar om de site daarna te BLIJVEN updaten gaat ook wel ver. Tenzij het natuurlijk een zeer belangrijke site is, maar ja dan wordt die site sowieso al vaak geupdate waarschijnlijk :)
De web server software moet je zoiezo up to date houden. TLS support zit er dan in principe standaard in.
Ik denk dat veel mensen zouden schrikken als ze zien hoe makkelijk het is om een man-in-the-middle attack uit te voeren op https verkeer als de attacker toegang heeft tot je netwerk.

Bovendien denk ik dat veel mensen zouden schrikken als ze zien hoe makkelijk het is toegang te krijgen tot iemands draadloze netwerk zolang 9/10 netwerken nog met WEP worden versleuteld.

Een dagje zoeken met google, wat tutorials lezen, tools downloaden en je leest de gmail van je buurman, of erger....

Meer prominente waarschuwingen als het certificaat van de site die je bezoekt niet in orde is, zijn dus zeker wel zéér welkom!
Meer prominente waarschuwingen als het certificaat van de site die je bezoekt niet in orde is, zijn dus zeker wel zéér welkom!
Het handmatig moeten installeren van een certificaat lijkt mij wel een goede optie. En dan natuurlijk niet meer simpel met een enkele Ja een niet-geinstalleerd certificaat kunnen accepteren.
De meeste wijzigingen schroeven de vstandaardveiligheidsinstellingen van de browser omhoog en zijn in IE6 met de hand in te stellen.

beteknt dat ook dat de beperkingen hoger worden in ie7?in ie6 ervaar ik dat wel met hogere security :?
waaronder de Advanced Encryption Standard, die sleutellengtes tot en met 256 bits aankan

De door M$ gehanteerde implementatie kan misschien maximaal AES-256 aan, maar AES-512 en zelfs AES-1024 zijn gewoon mogelijk met de standaard.

Met de huidige stand van de techniek is AES-256 overigens wel de hoogst praktisch haalbare. Anders overlaad je met name de CPU van de webserver te snel.

ALs je trouwens nu al behoefte hebt aan AES-256: Apache met Firefox als browser gebruikt dit al standaard.
Ondersteunt IE7 dan ook de cacert root certificate, of moet je die nog steeds handmatig importeren?
Was SSL 2 niet de versie welke niet goed geimplementeerd is en daardoor veel beveiligings issues met zich meebracht?

Daarbij in IE 6 kan men toch ook vinken voor SSL2, SSL3 en TLS1

Goed dat de certificaten nu beter in beeld komen voor de gebruiken. Kijk ik begrijp dat de mainstream internetgebruiker geirriteerd is als deze om de 5 minuten een certificaat moet accepteren maar deze gebruikers moeten zich eigenlijk ook realiseren waarom dat zo is. Ik durf te wedden dat nog niet de helft van alle online banking gebruikers een idee heeft dat hun verbinding wordt versleuteld en daardoor de gestuurde gegevens naar de bank veilig zijn. De gebruiker is daarbij vaak al helemaal niet op de hoogte dat het zwaartepunt van deze techniek ligt bij de certificaten (en het accepteren daarvan).

Je moet voor de gein is kijken naar de 10 meestgebruikte FTP clients. Als deze een beveiligde verbinding opzetten vraag 2 op de 10 clients of een bepaald certificaar geaccepteerd moet worden. Anderen accepteren automatisch het certificaat, zelfs wanneer deze niet met zekerheid secure is (zoals self signed certificaten

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