Het viel mij vandaag op dat het "oude" Outlook.com wel een slotje krijgt, maar de mailclients die overgezet zijn naar het nieuwe Outlook Mail (Preview) niet. Heeft Microsoft zijn certificaten niet op orde?

Onverstandig wat mij betreft. Google had beter meteen naar de geplande situatie kunnen gaan, waarbij er ook een streep door https staat als er sprake is van mixed content (en dus een deel van de informatie via http wordt opgehaald).

De site https://mixed.badssl.com/ waar in de plaatjes naar verwezen wordt, laat goed zien waarom het, bij mixed content, niet meer tonen van "het slotje" een slecht idee is - omdat notabene deze site als Favicon een slotje toont. M.a.w. Chrome toont zelf geen slotje meer, maar er is wel een slotje zichtbaar. Hoe moeten leken dit nog begrijpen? En welke leek houdt bij, per Chome versie, wat al die kleine icoontjes betekenen? En waarom is dit in elk "merk" webbrowser ook weer anders?

Overigens is https://badssl.com/, kennelijk opgezet door Lucas Garron (de blogpost waar de Redactie naar verwijst is mede door hem geschreven), wel een interessant initiatief. Blader er eens rond met je browser(s)!

Helaas is werkt nog niet alles perfect: als je met MSIE11 https://hsts.badssl.com/ opent, verschijnt de melding "HSTS is working" wat natuurlijk onzin is (MSIE11 ondersteunt geen HSTS).

De oorzaak daarvan lijkt een configuratiefout van de server te zijn (deze doet iets goed wat je nu juist niet wilt). Vanuit de pagina wordt MSIE gevraagd om http://hsts.badssl.com/hsts-test/status.svg te downloaden, en MSIE doet dat "braaf" (HSTS zou dat juist moeten voorkomen, namelijk door van die URL meteen https te maken). Echter, de webserver die erachter zit, stuurt als response op die http request: "HTTP/1.1 301 Moved Permanently" met daarbij: https://hsts.badssl.com/hsts-test/status.svg - waardoor MSIE alsnog braaf het plaatje via https laadt. Het kwaad kan dan natuurlijk al geschied zijn.

Hetzelfde geldt voor https://mixed.badssl.com/: ook hier wordt het plaatje uiteindelijk wel via https geladen. Alleen is MSIE11 (althans met mijn instellingen) wel zo "slim" om het echte slotje niet te laten zien, dus hier is dat minder erg.

Ik heb Lucas Garron een mailtje gestuurd over deze issues.

Het punt is dat "gemengde content" vrijwel altijd reclame bevat, en daar gaat Google uiteraard niks tegen ondernemen.

Ik zie dat ook Safari 9 bij de site https://mixed.badssl.com/ geen slotje geeft. Dan zie ik direct nog een nadeel. Je kunt nu ook niet het certificaat controleren door op het slotje te klikken. Anderzijds heeft dat certificaat minder waarde omdat, door de mixed content, niet al het verkeer via dat certificaat versleuteld is.

Dit is onzin, google bied advertenties met hun standaard scripts automatish over zowel http en https afhankelijk van het security niveau van de website waarin het ge-enbed word. Dat betekent dat:

Op websites die http gebruiken worden ads over http ge-enbed
over https worden ads over https ge-enbed.

Na de eerste drie checks snap ik er werkelijk geen hond meer van waarvoor deze site dan zou moeten waarschuwen en op welke wijze (met een mozilla browser).

Bijvoorbeeld : https://cbc.badssl.com/
Klik
Grijze pagina met daarin cbc.badssl.com en een grijs slotje in de url balk.
Wat moet ik dan uit deze pagina afleiden?
me no nada nie comprende

Enige toelichtende tekst na alle 'tests' vanaf sha1-2017 is wel nodig.
In ieder geval voor mij ;)

Ik twijfel of dit nu wel zoveel beter is. Ik neig naar "niet".
Het komt er op neer dat men zo tevens stimuleert om ook alle advertenties via https aan te bieden.
Maar juist advertenties zijn nogal eens besmet met malware.
Dus tegelijk dwing je dan gebruikers om AntiVirus software zo in te stellen dat "aan de poort" SSL moet worden opengebroken om het netwerkverkeer eerst te kunnen scannen op malware.
Maar dit vereist weer extra "pseudocertificaten" e.d., die weer nieuwe problemen en kwetsbaarheden introduceren,
waarbij de Antivirus software als een soort "Whitehat Man in the Middle" gaat fungeren,
zodat je daarin zult moeten geloven, waarbij je dus zelf de controle hierover verliest.
Afhankelijk van de AV-Software zelf, en van eventuele malware die in de AV-software is geslopen,
kun je dan bijv. mogelijk niet meer rechtstreeks het certificaat met fingerprint van de website controleren.
Dus is advertenties via https aanbieden nu wel zoveel veiliger?

Microsoft heeft het recent met een Cumulative Security Update voor IE11 toegevoegd:
http://blogs.windows.com/msedgedev/2015/06/09/http-strict-transport-security-comes-to-internet-explorer-11-on-windows-8-1-and-windows-7/

Als die pagina zonder foutmeldingen geladen wordt, zou jouw browser kwetsbaar kunnen zijn voor de BEAST attack. Of dat werkelijk zo is, valt (voor zover ik zie) niet af te leiden uit het resultaat.
Welke snap je nog meer niet?

Overigens is https://www.ssllabs.com/ssltest/viewMyClient.html een andere site die je (wellicht wat duidelijker) vertelt of je bij het gebruik van https risico's loopt met jouw browser.

Je hebt gelijk. Zoiets stond me eerder vandaag ook bij, maar ik heb met F12 (de toets), start opname en Ctrl-F5 in het browservenster gezien dat via http het plaatje opgehaald wordt (dwz de poging daartoe). Morgen zal ik nog eens goed kijken wat er gebeurt (ik heb nu geen MSIE11 bij de hand).

Waarom geen directe waarschuwing, dat de website niet vertrouwd is.
Al die onzin met dat slotje, waar de meeste gebruikers niet eens naar kijken.
Mensen zijn gewoonte dieren, en dus moet je ze verrassen met iets wat
opvalt.

Je kan gewoon op het icoontje klikken, dan geeft Chrome je alle informatie over de verbinding, zelfs wanneer er geen certificaat aanwezig is :]

Ik heb het bovenstaande nogmaals geprobeerd, nu met wireshark erbij aan. Inderdaad wordt er geen informatie onversleuteld uitgewisseld. Conclusie: MSIE11 houdt mij voor de gek in hun debugger (getest met https://hsts.badssl.com/), want deze toont:


Ik kan die middelste regel echt niet anders uitleggen dan dat er via http (niet https) een request wordt gedaan, compleet met return code (de response headers kun je bekijken door op die regel te dubbel-klikken en het tabblad "Response Headers" te bekijken).

Ik vermoed dat Microsoft support voor HSTS in MSIE11 op een laag niveau heeft toegevoegd ("onder" de debugger dus): de HSTS check zit dus als een soort MITM tussen de browser-engine en de daadwerkelijk naar internet verzonden data. Als er een http request voorbij komt, antwoordt die MITM met een "301 moved" response, zonder dat er data via internet wordt uitgewisseld...

Als ik de ondersteuning voor HSTS uitschakel in MSIE11 (zie de registry-wijzigingen genoemd in https://support.microsoft.com/en-us/kb/3071338, let op: voor x64 moet dat op 2 plaatsen), dan wordt http://hsts.badssl.com/hsts-test/status.svg daadwerkelijk uitgevoerd en toont MSIE een waarschuwing met een rode X dat HSTS niet werkt: "X HSTS is not working".

Wat mij overigens ook opvalt, is dat noch Chrome, noch MSIE11 (met HSTS enabled), noch Firefox een hangsslotje (TLS, niet de favicon) laten zien op https://hsts.badssl.com/ - terwijl het certificaat in orde is en er geen gegevens onversleuteld worden uitgewisseld (immers, HSTS dwingt dit af). De reden daarvoor is vermoedelijk dat de makers van deze browsers webapplicatieontwikkelaars proberen op te voeden: zolang zij http:// verwijzingen in hun code laten staan (die tijdens het tonen van de pagina daadwerkelijk worden uitgevoerd), verschijnt er geen slotje.

N.b bij Firefox verschijnt (in de default configuratie), in plaats van een hangslotje, een driehoek met uitroepteken (waarop je kunt klikken voor meer informatie, zie ook https://support.mozilla.org/en-US/kb/how-do-i-tell-if-my-connection-is-secure?as=u&utm_source=inproduct#w_gray-warning-triangle). Als je in Firefox about:config de waarde security.mixed_content.block_display_content op True zet (default = False) en je opent https://hsts.badssl.com/, dan verschijnt er wel een slotje. Het SVG plaatje (dat tekst genereert) onderin de pagina wordt dan echter geheel niet opgehaald. Normaal gesproken gebruik ik Firefox met deze instelling (voer in het zoekveld mixed in om alle relevante instellingen te zien).

Ten slotte: op mijn suggestie gisteren heeft Lucas Garron gisteren de pagina "mixed/form" https://mixed.badssl.com/mixed/form/ toegevoegd, waarbij je kunt controleren of jouw browser een waarschuwing geeft als je gegevens naar een site stuurt (met een HTTP POST commando) en dit onversleuteld gebeurt. Het is namelijk fijn om te weten of jouw browser je op zo'n moment waarschuwt (MSIE11 lijkt dat, by default, NIET te doen).

Voorbeeld: als je op de "Zoek" knop in https://www.overheid.nl/zoeken/ klikt, worden jouw zoektermen, geheel onverwacht, onversleuteld (via http) overgedragen - terwijl je toch echt op een https site zit; m.i. zou je beter mogen verwachten van onze overheid. Op z'n minst verwacht ik een waarschuwing in die pagina zelf dat ingevoerde informatie onversleuteld zal worden verzonden...

Meer info over bovenstaande MSIE11 debugger bug vind je in https://www.security.nl/posting/447422/MSIE11+debugger+bug.