Microsoft schroeft beveiliging Outlook.com en OneDrive op

Microsoft heeft de ondersteuning voor encryptie in Outlook.com en OneDrive verbeterd. E-mails worden nu versleuteld uitgewisseld met andere mailservers en er is in beide diensten nu ondersteuning voor perfect forward secrecy.

Onlangs bleek nog uit statistieken van Google dat 69 procent van alle e-mails in platte tekst tussen mailservers wordt uitgewisseld; met de introductie van encryptie door Microsoft zal dat percentage waarschijnlijk flink dalen. Het gaat om de verbindingen tussen mailservers; andere mailservers moeten eveneens ondersteuning voor tls hebben om de e-mails daadwerkelijk beveiligd te kunnen versturen.

Daarnaast heeft Microsoft perfect forward secrecy toegevoegd aan zijn mailserver, evenals de OneDrive-website en -apps. Bij perfect forward secrecy wordt gebruikgemaakt van tijdelijke sleutels voor het versleutelen van data. Wordt de sleutel in de toekomst bemachtigd, dan kan daardoor enkel recent verkeer worden ontsleuteld: verkeer uit het verleden heeft een andere sleutel gebruikt, die dan al is verwijderd. Daardoor heeft het geen zin om versleutelde data te onderscheppen, in de hoop dat de sleutel ooit uitlekt.

Op hetzelfde moment heeft Microsoft zijn eerste transparency center geopend, waar overheden terecht kunnen om de broncode van Microsoft-software te controleren op backdoors. De komst van de centra, die volgt op de onthullingen van NSA-klokkenluider Edward Snowden over backdoors in software, was eerder al aangekondigd. Binnenkort wordt ook een transparantiecentrum in Brussel geopend.

Reacties (29)

[Mocro_Pimp®]

Het gaat om de verbindingen tussen mailservers; andere mailservers moeten eveneens ondersteuning voor tls hebben om de e-mails daadwerkelijk beveiligd te kunnen versturen.

Betekend dit dat mijn hobby mailserver nu geen emails meer kan versturen naar Microsoft's email adressen? En ontvangen dan?
^{edit: blijkbaar blijft het wel mogelijk om ook plattetekstmail te versturen}

Goeie zet qua veiligheid, maar wel vreemd dat dit niet al jaren de standaard is...

[Reactie gewijzigd door Mocro_Pimp® op 26 juli 2024 16:09]

[geertdo]

Inderdaad en inderdaad. Voor je hobby mailserver zal het STARTTLS moeten kunnen afhandelen. Zo niet, dan valt het terug op un-encrypted text, dus leesbaar.

Het gaat volgens mij ook niet om 'platte tekst' zoals in het artikel staat, maar om encrypted inhoud in tekstcodering. 'Platte tekst' is een vorm van tekst dat leesbaar is, oftewel zonder opmaak, zonder markeringen. Platgeslagen...

De zakelijke mailsystemen zoals Office 365 en Google Apps for Business ondersteunen TLS al heel lang. Dat is altijd een argument van me geweest (en nog) om veiliger onderling, binnen een bedrijf te mailen. Mooi dat outlook.com het sinds iets meer dan een maand ondersteunt. Gmail ondersteunt het al iets langer. Nu alle pruts mailsystemen van onze providertjes nog...(er zijn al wel een paar die het ondersteunen)

Toch zit zo'n fall back systeem me niet echt lekker. Als het STARTTLS commando niet goed wordt verwerkt, wordt teruggevallen op unencrypted communicatie. En dat zie je niet in je ontvangen bericht (tenzij je headers leest ) en dat merk je niet bij een verstuurd bericht. Dit zou wel eens een onzichtbaar vulnerability dingetje kunnen zijn/worden... Het zou mooi zijn als er spoedig een switch gedaan kan worden naar TLS only. Dat maakt het mailsysteem al een heel stuk veiliger...

[Yggdrasil]

TLS staat voor Transport Layer Security en beschermt alleen de mails tijdens transit, dus tussen indidivuele servers. Het is niet bedoeld om de inhoud absoluut te beschermen tegen meekijkers. Na ontvangst op een volgende server is de mail gewoon cleartext en tijdens verwerking op het half dozijn servers waar je mail doorheen gaat is deze ook gewoon cleartext en dus leesbaar door een admin of door software.

Een TLS-only opzet zou dus nog steeds een erg zwakke bescherming geven, ook al is het beter dan nu. Als je de garantie wilt dat je mail onleesbaar is door anderen dan de geadresseerde dan zul je vooralsnog alleen voldoende hebben aan encryptie door middel van S/MIME of GPG. Dan heb je zelf de controle, zonder afhankelijk te zijn van de juiste configuratie door onbekende admins.

[marcelvb]

Ik heb ook STARTTLS geconfigureerd en de laatste paar weken is het aantal geëncrypte verbindingen flink omhoog gegaan. Dus STARTTLS is betere dan geen STARTTLS. De providers die het niet doen probeer ik via name-and-shame op twitter te motiveren dat alsnog te regelen.

Ik raad iedereen aan te leren hoe je email headers kunt zien en daarin eens te kijken of je ontvangen mail verstuurd is via een met TLS versleutelde verbinding. Zoek daarbij in de Received: headers naar een een string als SMTP, ESMTP, ESMTPS, ESMTPSA. Staat er een S na SMTP, dan was de betreffende verbinding versleuteld. Anders niet.

[DCK]

Het is al tijden moeilijk om je eigen mailserver goed te configureren om geaccepteerd te worden. Google's servers zijn ook heel streng. Dit inderdaad om spam te voorkomen.

Hoewel het moeilijk is, is het als je een valide TLS-certificaat en een vrij avondje heb allemaal nog wel te fixen.

[marcelvb]

Gewoon een self-signed certificate maken en TLS "aanvinken" in je mail server configuratie en dan werkt het, ook met google.

Geknipt uit m'n mail server log:
mail-vc0-f177.google.com [209.85.220.177], esmtps, TLS1.0:RSA_ARCFOUR_SHA1:128
mail-yk0-x233.google.com [2607:f8b0:4002:c07::233], esmtps, TLS1.0:RSA_ARCFOUR_SHA1:128
mail-yh0-x22c.google.com [2607:f8b0:4002:c01::22c], esmtps, TLS1.0:RSA_ARCFOUR_SHA1:128
mail-we0-x22d.google.com [2a00:1450:400c:c03::22d], esmtps, TLS1.0:RSA_ARCFOUR_SHA1:128


Hij selecteert trouwens niet de beste encryptie. Bij andere mail servers krijg ik betere.

[Yggdrasil]

Een valide certificaat is (nog) niet nodig. Er wordt niet op identiteit gecontroleerd, maar alleen een versleutelde verbinding opgezet. Een self-signed certificaat is dus genoeg. Gelukkig blijft de barrière daardoor laag.

[Martinspire]

Dat het nog niet jaren een standaard is heeft bij veel zaken te maken met het moeten ondersteunen van ouderwetse systemen.

Misschien is nu een backend eindelijk over waardoor dit nu wel mogelijk is.

[Yggdrasil]

Ik begrijp niet waar je op doelt. SMTP-servers zijn slim genoeg om te onderhandelen over de ondersteunde extensies, via het ESMTP protocol (extended SMTP) dat al 19 jaar bestaat. STARTTLS is één van die extensies. Servers die STARTTLS niet (willen) ondersteunen of niet kunnen begrijpen zijn niet verplicht het te gebruiken waardoor compatibiliteit met oudere systemen geregeld is. Systemen die zelfs ESMTP niet begrijpen zullen terugvallen op SMTP en dus ook blijven werken.

[Vaudtje]

Je kunt natuurlijk TLS aanzetten op je hobby mailserver ,dat gaat ook goed met een self-signed certificaat (je beveiligt de vebinding alleen, er is geen authenticatie).
Ik heb het op dovecot ooit eens aangezet (niet meteen poort 25 dichtgooien, niet iedere mailserver zal TLS doen en dan mis je mails, merkte ik na een tijdje )

[Reactie gewijzigd door Vaudtje op 26 juli 2024 16:09]

[magiel]

Dovecot heeft hier niks mee van doen. Het gaat hier om verkeer tussen MTA's. MTA's hebben de optie om encryptie alleen toepassen wanneer de ontvangende kant in de SMTP headers aangeeft STARTTLS te ondersteunen. Wanneer jouw MTA dat niet ontvangt, zal er geen poging tot STARTTLS gedaan worden.

[Verwijderd]

Jawel. Alleen zal het dan in platte tekst verstuurd worden.

[Martinspire]

Opvallend dat de laatste alinea (over transparantie centra) even erbij wordt gefrommeld, had van mij toch wel een eigen nieuwsbericht mogen zijn. Lijkt me namelijk redelijk belangrijk en geeft een beter beeld in de (nieuwe) strategie van Microsoft.

[Verwijderd]

Er zijn al heel lang programma's van Microsoft waarbij overheden de broncode van Microsoft konden inzien.
Het openen van de transperancy geeft daar alleen wat meer ruchtbaarheid aan en maakt het mogelijk iets eenvoudiger om dat uit te voeren.

[ASS-Ware]

Quote:
Op hetzelfde moment heeft Microsoft zijn eerste transparency center geopend, waar overheden terecht kunnen om de broncode van Microsoft-software te controleren op backdoors.

En wie garandeert mij dat dat geen gestripte versie is van de originele broncode waar de backdoors wel in zaten?
Ik vrees dat niemand dat kan controleren.

[Vipertje]

Daarmee impliceer je dat Microsoft actief meewerkt om backdoors in de eigen software in te bouwen. Als dat ooit zou lekken kan je haast wel opdoeken en gaan particulieren/bedrijven/overheden massaal overstappen op een ander OS. Kan me haast niet voorstellen dat ze zo'n risico durven te nemen.

[madmaxnl]

Wat als ze er wel in zitten, maar Microsoft niet bewust heeft meegewerkt heeft ze in te bouwen? Bijvoorbeeld door bepaalde medewerkers van Microsoft hiertoe te dwingen (NSA).

[Delgul]

@viperke: als dit zo was dan waren al lang volksstammen overgestapt van ms naar iets anders. Ze hebben nou niet precies een squeeky clean security record. Blijkbaar maakt dat 95% van de bedrijven niets uit. Dus als blijkt dat ms backdoors inbouwt dan gebeurt er gewoon niets.

En volgens mij is de NAVO ooit van Exchange afgestapt vanwege een aangetoonde backdoor. De regering van de VS wist bijna sneller wat de NAVO deed dan NAVO zelf. Het is dus wel bijna zeker dat ze er gewoon inzitten. Dat heeft ook verder geen repercussies gehad in het bedrijfsleven.

Nee... Ik denk dat je de security awareness van het gemiddelde bedrijf iets overschat...

[Armin]

Niet andes dan bij laten we zeggen Red Hat Linux. Tenzij je een specifieke audit doet - zoals bij TrueCrypt - waar je echt precies de gecompileerde binary bit voor bit gaat vergelijken, zul je dat altijd hebben.

En zelfs dan kun je nog hyperparanoide zijn en een compiler-backdoor gaan vermoeden

Ooit zul je 'iets' moeten vertrouwen.

[Lennie]

De vraag is ook hoeveel van die centra gebruik gemaakt zal worden.

Welke overheid gaat geld spenderen aan het inhuren van experts om hele grootte delen van bijvoorbeeld de Windows codebase te laten controleren ?

[Loller1]

Weinig overheden zullen dat doen... afzonderlijk. Maar samen enkele experts naar Microsoft sturen zal zeker wel gebeuren. China is daar een van.

[DJFliX]

Of: wie garandeert je dat er geen backdoor in de compiler zit die broncode die in het transparency center getoond wordt voorziet van wat 'extra functionaliteit'...

[Luno]

Als je dan ook de compilers (met hun broncode, anders zit de broncode in de compiler) erbij levert dan kun je byte nivo DLL's etc gaan controleren.
Een KK² weliswaar (KK²= Klopte Klus in het kwadraat)

[Bacchus]

En wie garandeert mij dat dat geen gestripte versie is van de originele broncode waar de backdoors wel in zaten?
Ik vrees dat niemand dat kan controleren.

Ik denk niet dat Microsoft twee versies van al zijn websites gaat onderhouden die precies hetzelfde doen, behalve dat in de een wel en in de andere geen NSA-backdoors zitten. Dan zou de NSA daar wel een hele grote schadevergoeding voor moeten betalen.

Dus: Onmogelijk? -Nee. Onwaarschijnlijk? -Ja.

[Matthijs8]

De inlogpagina van Outlook.com maakt nu gebruikt van Forward Secrecy ja, maar als je eenmaal bent ingelogd is er geen Forward Secrecy meer, en ook geen TLS 1.2:
https://www.ssllabs.com/s...yze.html?d=login.live.com
https://www.ssllabs.com/s...=live.com&s=65.55.157.146

[Armin]

Klopt, zal denk ik nog wel komen.

Overigens is het grootste voordeel van forward secrecy niet zozeer dat men jouw verkeer niet kan opslaan, en later na bekend raken van de sleutel ontsleutelen, maar het beschermen *nu* tegen 'gisteren' uitgelekte sleutels.

Organisaties die in staat zijn zulke bizarre hoeveelheden data op te slaan, zijn enkel grote overheden. En zelfs de NSA is er bijna 2 jaar geleden mee gestopt omdat het ook voor hen teveel werd. En in veel gevallen is dat soort data tegen die tijd niet meer relevant.

Maar als een sleutel vandaag gestolen wordt of gedwongen afgegeven, dan is forward secrecy een uitstekend middel om afluisteren tegen te gaan.

Bedenk bijvoorbeeld verder dat er nog steeds enkele honderduizenden sites zijn die vatbaar waren voor heartbleed en of gewoon hun certifciaat niet vervangen hebben (of zoals geraporteerd vervangen met een niet certificaat gegenereerd met dezelfde private key). In zo'n geval mag je hopen dat men forward secrecy heeft als prefered cypher.

[XRayXI]

Ze zijn zeker aan het werk. Bij het aanklikken van settings word op sommige onderdelen als om een "Code" gevraagd dat je kan koppelen, met een ander Outlook account.

(/Edit:: -1 gemod. Offtopic niet meer aanwezig?)

[Reactie gewijzigd door XRayXI op 26 juli 2024 16:09]

[Armin]

Dat is niet aan het werk zijn maar een beveiliging setting. Google doet hetzelfde, al is Microsoft inderdaad iets 'strenger'.

Bepaalde veiligheid zaken en persoonlijke gegevens kunnen inderdaad niet benaderd/gewijzigd worden zonder expliciete 2-factor. Dat is al minstens 2 jaar zo. Bij het opzetten wordt om een 2e email gevraagd (of telefoon nummer), welke daarvoor gebruikt wordt. Je kunt dat uitzetten en/of trusted devices aangeven.

Dit is een extra stukje beveiliging dat mensen bijvoorbeeld bij het in handen krijgen van je email + password, niet meteen je account kunnen overnemen. Dus nu wellicht lastig, maar als je ooit slachtoffer wordt van zoiets, iets waar je dan heel blij om bent.