Wat beveiligd STARTTTLS nou eigenlijk?

[HeepH]

Op het werk ben ik bezig met de beveiliging van onze emails. Wij mailen klantgegevens naar diverse (eigen) smtp servers en willen dit graag beveiligen.

Nu ben ik me aan het inlezen en kom ik over STARTTLS tegen. Hiervan staat omschreven dat hij na een handshake doormiddel van certificaten de bevinding beveiligd. NIET de inhoud van de email. Ok, begrijp ik. Maar wat word er dan wel beveiligd?

Ofwel, welke risico's loop ik nog?

Word mijn username ge-encrypt? Mijn Password? Mijn IP? Mijn Mac? Of moet ik voor al deze zaken al over op SMIME of PGP?

Kortom : wat beveilig ik en wat voorkom ik met tls?

Als dit verhaal niet helemaal consistent is, ik ben er pas net mee begonnen en nog niet volledig op de hoogte van deze protocollen en hun doen en laten...

[ Voor 3% gewijzigd door HeepH op 25-04-2014 12:54 ]

[Cyphax]

Het is niet zozeer dat je naam of wachtwoorden worden versleuteld, maar wel de verbinding waar het overheen wordt gestuurd. Daar stuur je vervolgens iets overheen, zoals bijvoorbeeld mail en dergelijke.

Als je ook nog met PGP aan de slag wilt, dan zou je daarmee wel echt het bericht (maar niet de overigen eigenschappen van het bericht, zoals afzender en ontvanger) versleutelen maar dat is echt end-to-end. De een vervangt niet de ander in principe. Voor PGP moet je ook je eigen public key gaan publiceren (maar nooit je private key uiteraard).

[ Voor 18% gewijzigd door Cyphax op 25-04-2014 13:00 ]

[HeepH]

Ik begrijp dat het elkaar niet uitsluit.

De verbinding is versleutelt. Maar username, password, endergelijke gaan onversleuteld over die verbinding? Dus bij aankomst aan de andere kant van de verbinding, en eventueele verdere verzending, is alles ontsleuteld?

Ik zou graag willen dat vooral username/password/ip en INHOUD versleuteld waren, en dan maakt het mij niet eens echt zo uit wie die versleutelde kluis dan ook kan ontvangen

Kies publiceren voor PGP of een CA een key laten maken voor SMIME is iets waar ik van op de hoogte ben.

Als ik het goed begrijp kan SMIME eenvoudiger kies distribueren dan PGP omdat smime via CA's kan en PGP alleen zelf of via PGP key hubs?

[Cyphax]

Heephstan schreef op vrijdag 25 april 2014 @ 13:07:
Ik begrijp dat het elkaar niet uitsluit.

De verbinding is versleutelt. Maar username, password, endergelijke gaan onversleuteld over die verbinding? Dus bij aankomst aan de andere kant van de verbinding, en eventueele verdere verzending, is alles ontsleuteld?

Ja, en nee: username en password gaan in tekstvorm over de versleutelde verbinding. Dan is het ook nog eens zo dat het alleen de verbinding tussen jou en je SMTP-server is: je weet niet hoe de verbinding tussen die server en de ontvangende SMTP-server is en ga er dus maar vanuit dat dat niet versleuteld is (kan wel gewoon). Dan gaat het wel weer over de inhoud van je mail, niet je credentials.

Ik zou graag willen dat vooral username/password/ip en INHOUD versleuteld waren, en dan maakt het mij niet eens echt zo uit wie die versleutelde kluis dan ook kan ontvangen

De inhoud kan je zelf versleutelen; de rest niet. Username/password gaat dus wel versleuteld over jouw lijn maar het versleutelen gaat op een andere laag dan wanneer je wachtwoord en username apart zou gaan versleutelen.

Als je de ontvangende partij vertrouwt (via het certificaat), dan is het versleuteld tot daar aan toe en heb je in principe wat je wilt, zolang het certificaat goed is.

Als ik het goed begrijp kan SMIME eenvoudiger kies distribueren dan PGP omdat smime via CA's kan en PGP alleen zelf of via PGP key hubs?

Dat zou kunnen; S/MIME hangt af van CA's en PGP niet. Het is dezelfde vraag weer: vertrouw je de CA? In principe zal dat meestal wel zo zijn, maar de ellende met Diginotar leert wel dat het ook mis kan gaan.

[ Voor 5% gewijzigd door Cyphax op 25-04-2014 13:29 ]

[HeepH]

Cyphax schreef op vrijdag 25 april 2014 @ 13:27:


Ja, en dan is het ook nog eens zo dat het alleen de verbinding tussen jou en je SMTP-server is: je weet niet hoe de verbinding tussen die server en de ontvangende SMTP-server is en ga er dus maar vanuit dat dat niet versleuteld is (kan wel gewoon). Dan gaat het wel weer over de inhoud van je mail, niet je credentials.

Hmhm. Dus in het geval van het gebruik van een externe smtp (itt ons lokale intranet) is het sowieso aan te raden gebruik te maken van SMIME of PGP bij het verzenden van vertrouwelijke gegevens?

De inhoud kan je zelf versleutelen; de rest niet. Username/password gaat dus wel versleuteld over de lijn, maar dan generiek met alles wat je daar naartoe opstuurt.

Versleutelen met pgp/smime? Ok. En ja ik begrijp dat ik dan 1 "kluis" met daar al mijn info er in verstuur. Zolang deze dan goed beveiligd is zit ik echter goed

Als je de ontvangende partij vertrouwt (via het certificaat), dan is het versleuteld tot daar aan toe en heb je in principe wat je wilt, zolang het certificaat goed is.

Ik begrijp wat je bedoeld met vertrouwen (en idd dignotar). Toch ga ik er even vanuit dat het certificaat wat wij gaan hanteren te vertrouwen is en blijft. Ergens moet een streep getrokken worden door onze paranoia

Dat zou kunnen; S/MIME hangt af van CA's en PGP niet. Het is dezelfde vraag weer: vertrouw je de CA? In principe zal dat meestal wel zo zijn, maar de ellende met Diginotar leert wel dat het ook mis kan gaan.

Vertrouwen ga ik dus wel even vanuit. Dus een CA certificaat en SMIME en ik ben "veilig"

Even los hiervan :

STEL dat ik alleen gebruik maak van intranet (in de letterlijke zin) dus alle servers van onze cliënten hangen aan onze servers via een directe lijn (zoals nu het geval is). Kan ik dan ook gewoon mijn eigen certificaten uitgeven en gebruiken ter validatie? Begrijp dat ik (omdat het toch over een directe lijn gaat) mss een beetje paranoia ben maar het zijn persoonsgegevens van patienten en dus zeer vertrouwelijk. Ik wil koste wat het kost eigenlijk voorkomen dat (bijv. dmv sniffing) alsnog deze gegevens benaderd worden...

In de toekomst zal toch naar CA certificaten gekeken moeten worden ivm buitenlandse klanten..

Heel erg bedankt voor de info in ieder geval

[CyBeR]

Om 't kortste antwoord maar te geven: STARTTLS is een manier om een TLS-verbinding (ook wel bekend als SSL, maar dat is eigelijk een oudere versie) te beginnen over een reeds bestaande plain-text verbinding. Zo hoef je niet aparte poorten te gebruiken, zoals 80 voor http en 443 voor http met ssl.

[HeepH]

CyBeR schreef op vrijdag 25 april 2014 @ 13:39:
Om 't kortste antwoord maar te geven: STARTTLS is een manier om een TLS-verbinding (ook wel bekend als SSL, maar dat is eigelijk een oudere versie) te beginnen over een reeds bestaande plain-text verbinding. Zo hoef je niet aparte poorten te gebruiken, zoals 80 voor http en 443 voor http met ssl.

Mja, maar alleen veilig tot aan de deur van smtp, en de informatie is vrij publiek beschikbaar hierna. Dat is duidelijk

[CyBeR]

Heephstan schreef op vrijdag 25 april 2014 @ 13:40:
[...]


Mja, maar alleen veilig tot aan de deur van smtp, en de informatie is vrij publiek beschikbaar hierna. Dat is duidelijk

Dat is niet 100% waar. Ten eerste werken heel veel mail servers met opportunistic tls tegenwoordig, wat betekent dat als STARTTLS besschikbaar is bij de 'volgende' mail server, dat dat gebruikt wordt.

Verder: jij hebt 't over de inhoud van de mail. Die is inderdaad niet vertrouwelijk te achten zonder S/MIME of pgp of iets dergelijks te gebruiken. Je kunt er namelijk niet van uit gaan dat de server 'm niet zonder crypto verstuurt. Maar, zo werkt e-mail al sinds het begin der tijden en daar zijn we allemaal wel aan gewend.

De voornaamste reden om TLS te gebruiken is dan ook niet het versleutelen van de inhoud van je e-mail, maar het versleuteld versturen van je gebruikersnaam en wachtwoord, zodat die niet afgetapt kunnen worden. En daar is TLS uitermate effectief in.

[HeepH]

CyBeR schreef op vrijdag 25 april 2014 @ 13:44:
[...]


Dat is niet 100% waar. Ten eerste werken heel veel mail servers met opportunistic tls tegenwoordig, wat betekent dat als STARTTLS besschikbaar is bij de 'volgende' mail server, dat dat gebruikt wordt.

Verder: jij hebt 't over de inhoud van de mail. Die is inderdaad niet vertrouwelijk te achten zonder S/MIME of pgp of iets dergelijks te gebruiken. Je kunt er namelijk niet van uit gaan dat de server 'm niet zonder crypto verstuurt. Maar, zo werkt e-mail al sinds het begin der tijden en daar zijn we allemaal wel aan gewend.

De voornaamste reden om TLS te gebruiken is dan ook niet het versleutelen van de inhoud van je e-mail, maar het versleuteld versturen van je gebruikersnaam en wachtwoord, zodat die niet afgetapt kunnen worden. En daar is TLS uitermate effectief in.

Afgetapt en gebruikt op je smtp en dan is het huilen

Ja, ik begin het te begrijpen. Van opportunistic TLS ben ik op de hoogte, maar dat blijft "opportunistic" en ik wil graag een grotere garantie dan dat.

En inderdaad, "het werkt al zo sinds het begin der tijden" maar dat is voor mij nog geen reden om dan maar te accepteren dat het zo blijft Als ik met een paar dagen werk mijn klanten de garantie kan bieden dat hun gegevens binnen 99.9% veilig zijn dan is mij dat de tijd waard. Komt nog eens bij dat deze manier van werken natuurlijk ook als verkoopargument naar de klanten toe kan gebruiken

Heel erg bedankt voor de informatie in ieder geval, je hebt het een stuk overzichtelijker gemaakt voor me.

Voor TLS heb ik geen CA certificaat nodig maar kan ik een selfsigned? zolang ik maar er voor zorg dat beide clients dit certificaat hebben? En zodra ik besluit ook SMIME te gebruiken kan ik dan dat certificaat voor beide gebruiken? Of kan ik ook smimen met mijn selfsigned - ook al komt ie dan als untrusted aan bij sommige?

Ben je op de hoogte van een snelle manier om certificaten te deployen op onze klantsystemen?

[ Voor 10% gewijzigd door HeepH op 25-04-2014 14:09 ]

[CyBeR]

De simpelste en snelste manier is gewoon bij een CA een cert aanvragen.

S/MIME certs volgen hetzelfde proces maar de inhoud (specifiek, de common name) is anders.

[ Voor 39% gewijzigd door CyBeR op 25-04-2014 14:10 ]