image

Google gaat sslv3 en rc4 voor Gmail uitschakelen

woensdag 18 mei 2016, 10:13 door Redactie, 9 reacties

Google zal binnen 30 dagen sslv3 en rc4 op de webservers en smtp-servers van Gmail uitschakelen, zo heeft de internetgigant aangekondigd. Zowel sslv3 en rc4 worden gebruikt bij het versleutelen van internetverkeer, maar zijn volgens Google niet meer veilig en het gebruik ervan is een risico.

Eerder liet de Internet Engineering Task Force (IETF) al weten dat zowel het 16 jaar oude sslv3 als het 28 jaar oude rc4 niet meer gebruikt moeten worden. Daarom heeft Google besloten om na 16 juni van dit jaar zowel sslv3 als rc4 op de webservers en smtp-servers van Gmail uit te schakelen. Organisaties die Google Apps gebruiken en nog steeds op hun eigen systemen van sslv3 of rc4 gebruikmaken krijgen het advies om naar modernere encryptiestandaarden te upgraden.

Sslv3 wordt bijvoorbeeld nog gebruikt op gateways, e-mailers van derde partijen en systemen die van smtp-relay gebruikmaken. Na de aanpassing van Google zullen servers die berichten via sslv3 en rc4 versturen geen e-mail meer met de smtp-servers van Google kunnen uitwisselen en sommige gebruikers die met oudere en onveilige e-mailprogramma's werken zullen geen e-mail meer kunnen versturen.

Reacties (9)
18-05-2016, 10:45 door [Account Verwijderd] - Bijgewerkt: 18-05-2016, 10:50
Maar de Google zoek servers ondersteunen SSLv.3 nog steeds!

en dan:

Organisaties die Google Apps gebruiken en nog steeds op hun eigen systemen van sslv3 of rc4 gebruikmaken krijgen het advies om naar modernere encryptiestandaarden te upgraden.

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.
18-05-2016, 10:48 door Erik van Straten - Bijgewerkt: 18-05-2016, 13:50
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):
Strict-Transport-Security: max-age=31536000; includeSubDomains, max-age=31536000; includeSubDomains
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]:
An error occurred during a connection to r1.res.office365.com.
SSL received a record with an incorrect Message Authentication Code.
(Error code: ssl_error_bad_mac_read)

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
[a]: portal.office.com, portal.microsoftonline.com, portalprv.microsoftonline.com, ncuportalprv.microsoftonline.com, scuportalprv.microsoftonline.com, wusportalprv.microsoftonline.com, ncuportal.microsoftonline.com, scuportal.microsoftonline.com, neuportal.microsoftonline.com, weuportal.microsoftonline.com, seaportal.microsoftonline.com, easportal.microsoftonline.com, auth.office.com, auth.microsoftonline.com, authprv.microsoftonline.com, ncuauthprv.microsoftonline.com, scuauthprv.microsoftonline.com, wusauthprv.microsoftonline.com, ncuauth.microsoftonline.com, scuauth.microsoftonline.com, neuauth.microsoftonline.com, weuauth.microsoftonline.com, seaauth.microsoftonline.com, easauth.microsoftonline.com, ncuportal.office.com, scuportal.office.com, neuportal.office.com, weuportal.office.com, seaportal.office.com, easportal.office.com, ncuportalprv.office.com, scuportalprv.office.com, wusportalprv.office.com, ncuauth.office.com, scuauth.office.com, neuauth.office.com, weuauth.office.com, seaauth.office.com, easauth.office.com, ncuauthprv.office.com, scuauthprv.office.com, wusauthprv.office.com, portal-sdf.office.com, auth-sdf.office.com, auth-sdf.microsoftonline.com, prod.msocdn.com, ncuprodprv.msocdn.com, scuprodprv.msocdn.com, ejpportal.microsoftonline.com, wjpportal.microsoftonline.com, eusportal.microsoftonline.com, wusportal.microsoftonline.com, ejpauth.microsoftonline.com, wjpauth.microsoftonline.com, eusauth.microsoftonline.com, wusauth.microsoftonline.com, ejpportal.office.com, wjpportal.office.com, eusportal.office.com, wusportal.office.com, ejpauth.office.com, wjpauth.office.com, eusauth.office.com, wusauth.office.com
18-05-2016, 14:57 door Anoniem
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.
18-05-2016, 15:14 door Erik van Straten
18-05-2016, 14:57 door Anoniem: 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.
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?
18-05-2016, 17:58 door [Account Verwijderd]
[Verwijderd]
18-05-2016, 17:59 door Anoniem
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
18-05-2016, 18:01 door Anoniem
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.
18-05-2016, 22:55 door [Account Verwijderd]
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.
20-05-2016, 06:11 door Erik van Straten
18-05-2016, 17:59 door Anoniem: 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
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:
Cipher Suites (SSL 3+ suites in server-preferred order; deprecated and SSL 2 suites at the end)
[...] (de lijst met overige ondersteunde cipher suites)
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 (0xc02b)
TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) ECDH secp256r1 (eq. 3072 bits RSA) FS 112
TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) ECDH secp256r1 (eq. 3072 bits RSA) FS 112
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
TLS_ECDHE_ECDSA_WITH_RC4_128_SHA (0xc007) ECDH secp256r1 (eq. 3072 bits RSA) FS INSECURE 128
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) ECDH secp256r1 (eq. 3072 bits RSA) FS INSECURE 128
TLS_RSA_WITH_RC4_128_SHA (0x5) INSECURE 128
TLS_RSA_WITH_RC4_128_MD5 (0x4) INSECURE 128

(einde van de lijst)

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):
Cipher Suites (SSL 3+ suites in server-preferred order; deprecated and SSL 2 suites at the end)
TLS_RSA_WITH_RC4_128_MD5 (0x4) INSECURE 128
TLS_RSA_WITH_RC4_128_SHA (0x5) INSECURE 128
TLS_RSA_WITH_3DES_EDE_CBC_SHA (0xa) 112
TLS_RSA_WITH_AES_256_CBC_SHA (0x35) 256
TLS_RSA_WITH_AES_128_CBC_SHA (0x2f) 128
TLS_ECDHE_RSA_WITH_RC4_128_SHA (0xc011) ECDH secp256r1 (eq. 3072 bits RSA) FS INSECURE 128
[...] (de lijst met overige ondersteunde cipher suites)
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/
Reageren

Deze posting is gelocked. Reageren is niet meer mogelijk.