Maar de Google zoek servers ondersteunen SSLv.3 nog steeds!

en dan:


Je moet dus wel een enorme berg boter op je hoofd hebben om dit te durven adviseren. Schaamteloos.
Onbegrijpelijk dat dit maar door blijft gaan. Het lijkt verdorie wel onderdeel van het verdienmodel.

Ach, de bij Office365 nog gebruikte prod.msocdn.com (wildcard cert *.msocdn.com [1]) ondersteunt, naast RC4, zelfs nog de 56bit sterke DES encryptie (ze hebben de eeuwwisseling daar gemist vermoed ik) en gebruikt een SHA1 certificaat (met intermediate cert "Verizon Akamai SureServer CA G14-SHA1", ook met SHA1, en zelfs nog geldig tot 2021-04-02).

Na openen van [1] (voor IPv6 sites zie [2]) word je doorgestuurd naar "login.microsoftonline.com" welke geen EV certificaat gebruikt, en met die naam moet je maar gokken dat dit een site is van Microsoft.com.

Inloggen kan via [3] waarbij, in die inlogpagina dus, verbinding gemaakt wordt met bovengenoemde prod.msocdn.com (er worden, zo te zien, o.a. fonts en plaatjes vandaan gedownload - maar als een aanvaller die kan manipuleren, kan deze gebruikers natuurlijk volledig op het verkeerde been zetten).

Ook [3] gebruikt geen EV certificaat (waardoor een gemiddelde gebruiker geen onderscheid kan maken tussen zo'n certificaat en DV speelgoedcertificaten waaronder die van Let's Encrypt - met als gevolg dat relatief eenvoudig MitM aanvallen mogelijk zijn op dit soort cloudsites).

Dat certificaat kan ook geen EV cert zijn, want het is geldig voor een hele berg sites [a] - waaronder bovengenoemde prod.msocdn.com (waarom de werkelijke site zelf dan nog een SHA1 cert gebruikt mag Joost (of de baas van Akamai) weten). Dit betekent dat de bijbehorende private key, het feitelijke identiteitsbewijs van deze servers, zich op veel verschillende plaatsen bevindt (ik hoop niet rondslingert). Wat de kans op lekken daarvan alleen maar vergroot natuurlijk; zo'n private key is, op de zwarte markt, vermoedelijk heel wat geld waard. En je hebt maar 1 foute medewerker nodig, niet alleen bij Microsoft maar bijv. ook bij de betrokken CDN provider(s).

Ah, outlook.office365.com ondersteunt ook nog RC4 [4]. Het was, notabene de heer A. Popov, een Microsoft medewerker, die RC4 heeft geprullebakkeerd [5] in februari 2015, waarbij de eerste aanvraag daarvoor bijna 3 jaar geleden, op 21 augustus 2013, werd ingediend [6].

Een deel van de vele sites waarmee verbinding wordt gemaakt (als je Outlook365 gebruikt), ondersteunt HSTS, maar een ander deel weer niet (zoals clientlog.portal.office.com, xsi.outlook.com, r1.res.office365.com en appsforoffice.microsoft.com). Nog even verder kijkend, [7] geeft momenteel een onjuiste HSTS header (doordat deze dubbel is):
In elk geval Firefox keurt die header af. Of daarmee "outlook.office365.com" geheel uit de HSTS database geknikkerd wordt, weet ik niet. Iemand?

Tip voor Microsoft: openen van [8] geeft helemaal geen HSTS header. Dat is op zich niet onveilig, maar waarom wordt de HSTS header in vredesnaam pagina-afhankelijk meegegeven? Dat is toch vragen om fouten zoals een dubbele header?

Bovendien trad er een (onder water) een foutmelding op bij het laden van een font vanaf [9]:
Dit nog even los van de ergernis dat het 20 karakter wachtwoord dat ik wilde gebruiken, niet werd geaccepteerd met de melding dat het wachtwoord minstens 8 karakters lang moet zijn met gebruik van kleine en hoofdletters, cijfers en symbolen (er staat niets over een maximale lengte). Pas toen ik de lengte naar 16 karakters had teruggeschroefd (entropie van 99 bits volgens KeePass, ruim minder dan de gewenste 112 bit zoals minstens vereist bij versleutelde verbindingen) werd mijn wachtwoord geaccepteerd.

@Mensen die mijn wachtwoord (of van andere security-aware personen) willen brute-forcen: je kunt het beste beginnen met wachtwoorden met een lengte van 16 karakters (dus 8 t/m 15 overslaan). Scheelt een boel werk! No thanks Microsoft.

P.S. vandaag heb ik mijn eerste ervaringen met Office365 opgedaan. Nou ik ben onder de indruk - van de onveiligheid.

[1] https://www.ssllabs.com/ssltest/analyze.html?d=prod.msocdn.com&s=23.59.200.134
[2] https://www.ssllabs.com/ssltest/analyze.html?d=prod.msocdn.com
[3] https://portal.office.com/
[4] https://www.ssllabs.com/ssltest/analyze.html?d=outlook.office365.com
[5] https://tools.ietf.org/html/rfc7465
[6] https://tools.ietf.org/html/draft-popov-tls-prohibiting-rc4-00
[7] https://outlook.office365.com/owa/
[8] https://outlook.office365.com/O365SuiteService/api/Notifications/
[9] https://r1.res.office365.com/owa/prem/fonts/segoeui-semilight.woff

Daarom kunnen we alleen maar concluderen dat bij Google, Twitter en Facebook het alleen maar gaat om de zakelijke kostenafwegingen, het was goedkoper om RC4 te blijven gebruiken.
Dat is namelijk snel, simpel en goedkoop en dus doorgegaan tot het niet meer kan vanwege het oplopend veiligheidsrisico.

Ze zijn dus meer in hun eigen businessmodel geïnteresseerd, dan in de veiligheid van de eindgebruiker,
maar dat wisten we toch al een tijdje, mag ik aannemen.

Geef het volgende commando eens in vanaf de shell/terminal:
openssl speed rsa

Beoordeel de resultaten en kom tot de conclusie dat onveilig
dus 3,5 x sneller is voor operaties en .........dat telt in euries.

Het nog ondersteunen van RC4 kun je. als buitenstaander, eenvoudig vaststellen.

Mijn vraag hierbij is vooral: als de van buitenaf zichtbare beveiliging al leidt onder kostenbesparingen, hoe zit het dan met beveiliging van de minder-/niet zichtbare onderdelen? D.w.z. waaruit "de cloud" is opgebouwd waar velen hen gegevens (en die van anderen) aan toevertrouwen?

Ha Erik,

Dit boezemt in ieder geval voor facebook niet al te veel vertrouwen in: https://securityheaders.io/?q=https%3A%2F%2Fstatic.xx.fbcdn.net%2F
Certificate valid through: Dec 30 12:00:00 2016 GMT
Certificate Issuer: DigiCert Inc
SSL Protocols Supported: TLSv1 TLSv1.1 TLSv1.2

Ach, er bestaan ook nog altijd smalle B-weggetjes en zelfs zandweggetjes in Nederland met bomen en sloten aan weerszijden. Maar lang niet altijd is de gebruiker van het wegennet verplicht om die weg te nemen.
EN gelukkig gaat het veel vaker goed dan mis.

IE op WP 8.1 ondersteunt ook nog altijd SSL3.0 en via https://www.ssllabs.com/ssltest/viewMyClient.html krijg ik ook te zien nog altijd kwetsbaar te zijn voor Logjam en FREAK. (zelfde geldt ook voor UC browser). Zelfs nintendo lijkt het op hun 3DS met de laatste update geïnstalleerd nog beter voor elkaar te hebben aangezien dan bij POODLE, Logjam en FREAK wordt aangegeven dat de user agent niet vulnerable is.

Uit jouw bijdrage zelf blijkt niet dat er wat mis is met static.xx.fbcdn.net, maar uit [1] blijkt dat wel: ook deze server ondersteunt nog RC4, notabene ook in combinatie met ECDHE. Het lijkt dus om een bewuste keuze te gaan: klanten die performance belangrijker vinden dan security kunnen hier gebruik van maken:

Eerlijkheidshalve ter vergelijking: RC4 is geen voorkeurscipher van die site, terwijl dat, op dit moment, bijv. wel zo is bij sso.verizonenterprise.com [2] (die domainname viel mij op op [3] toen ik daar toevallig keek):
Bij het opzetten van de SSL verbinding vertelt de browser aan de server welke cipher suites die browser ondersteunt, waarna de server een keuze maakt. Dus als jouw browser aangeeft zowel RC4 als AES128 te ondersteunen, krijg je bij de FB site in principe altijd AES128 en bij de andere site RC4.

Echter, bij de FB site ligt altijd het risico op protocol downgrade attacks op de loer. D.w.z. waarbij een MitM "aanvaller" (kan ook een losstaand SSL/TLS inspectie device zijn, of een overijverige virusscanner of malware op de PC zijn) op de een of andere manier afdwingt dat de hele of gedeeltelijke verbinding met een verouderde en gekraakte cipher wordt "versleuteld".

Het risico bij beide sites, dat klanten met oudere browsers en die geen idee hebben dat zij onveilige protocollen (ciphers in dit geval) gebruiken, wordt dus op de koop toegenomen.

Oorzaak: er zijn veel te veel managers, maar ook politici, die -niet gehinderd door enige kennis terzake- denken dat security iets is waar je in alle gevallen concessies aan kunt doen. Echter, vergeleken met "op vakantie gaan":

- Je kunt geen concessies doen aan het aantal ramen en deuren dat je op slot doet (een aanvaller heeft genoeg aan 1 gat, jij zult dus alle gaten moeten localiseren en dichten);

- Je kunt wel concessies doen aan de kwaliteit van het hang- en sluitwerk, maar er is wel een minimum niveau vereist. Want de niet al te stomme inbreker zoekt de zwakste plek.

In deze context: RC4 is een veel te zwakke plek en moet worden uitgeroeid.

[1] https://www.ssllabs.com/ssltest/analyze.html?d=static.xx.fbcdn.net&latest
[2] https://www.ssllabs.com/ssltest/analyze.html?d=sso.verizonenterprise.com
[3] https://www.ssllabs.com/ssltest/