Vraag Is STARTTLS minder veilig dan TLS / SSL?


In Thunderbird (en ik neem aan dat ook bij veel andere klanten) heb ik de optie om te kiezen tussen "SSL / TLS" en "STARTTLS".

Voor zover ik het begrijp, betekent "STARTTLS" in eenvoudige woorden "coderen als beide uiteinden TLS ondersteunen, anders versleutelen de overdracht niet". En "SSL / TLS" betekent in eenvoudige woorden "altijd coderen of helemaal niet verbinden". Is dit correct?

Of met andere woorden:

Is STARTTLS minder veilig dan SSL / TLS, omdat het kan terugvallen op gewone tekst zonder me op de hoogte te stellen?


43
2017-07-16 19:07


oorsprong




antwoorden:


Het antwoord, gebaseerd op de STARTTLS RFC voor SMTP (RFC 3207) is:

STARTTLS is minder veilig dan TLS.

In plaats van zelf te praten, zal ik de RFC toestaan ​​om voor zichzelf te spreken, met de vier relevante bits erin gemarkeerd STOUTMOEDIG:

Een man-in-the-middle-aanval kan worden gestart door de "250 te verwijderen      STARTTLS "-reactie van de server, waardoor de client niet      om een ​​TLS-sessie te starten. Een andere man-in-the-middle-aanval is      om de server toe te staan ​​zijn STARTTLS-mogelijkheid aan te kondigen, maar deze te wijzigen      het verzoek van de client om TLS te starten en de reactie van de server. In      Om zich te kunnen verdedigen tegen dergelijke aanvallen MOETEN zowel klanten als servers het doen worden      in staat worden geconfigureerd om een ​​succesvolle TLS-onderhandeling van een te vereisen      geschikte coderingssuite voor geselecteerde hosts voordat berichten kunnen worden      succesvol overgedragen. De aanvullende keuze van het gebruik van TLS wanneer      mogelijk MOET ook worden verstrekt. Een implementatie MEI lever de      mogelijkheid om te registreren dat TLS werd gebruikt om met een gegeven te communiceren      peer en genereert een waarschuwing als deze niet in een latere sessie wordt gebruikt.

Als de TLS-onderhandeling mislukt of als de client een 454 ontvangt      reactie, de klant moet beslissen wat hij vervolgens moet doen. Er zijn er drie      belangrijkste keuzes: ga door met de rest van de SMTP-sessie, [...]

Zoals u ziet, vermeldt de RFC zelf (niet erg duidelijk, maar duidelijk genoeg) dat er NIETS is die van clients eist dat ze een veilige verbinding tot stand brengen en gebruikers informeren als een beveiligde verbinding is mislukt. Het uitdrukkelijk geeft klanten de mogelijkheid om stil tot stand te brengen platte tekst verbindingen.


43
2017-12-01 16:43



Uw punt is zeker geldig, maar door het ontbreken van een RFC of officiële specificatie met betrekking tot SMTPS (dwz SMTP + "impliciete SSL / TLS" waarbij SSL / TLS het eerst wordt vastgesteld), konden SMTP / SMTPS-clients ook besluiten terug te vallen op een gewone verbinding als het ze niet lukt om een ​​SSL / TLS-verbinding op poort 465 te starten. Dat is nog steeds puur een implementatiekeuze. - Bruno
Er zijn veel RFC's om TLS-verbindingen tot stand te brengen. Nergens is er "allow plain-text connection" bestaan ​​als een optie om te voldoen aan de RFC (dat zou voor veel mensen nieuws zijn). Dus SMTPS vereist geen afzonderlijke RFC om veiliger te zijn dan STARTTLS. - Greg
Er zijn RFC's over TLS (RFC 5246 en voorgangers), PKI (RFC 5280), naamverificatie (RFC 6125), maar niets om de interactie tussen SMTP en SSL / TLS in SMTPS officieel AFAIK te beschrijven, niet op dezelfde manier als u krijgt een specificatie voor HTTPS: RFC 2818. Men zou kunnen zeggen: "het is duidelijk, stel eerst de SSL / TLS-verbinding eerst tot stand", maar niet alles is zo duidelijk (met name het aspect van identiteitsverificatie, dat pas vrij recent in RFC 6125 werd geformaliseerd). - Bruno


Er is geen verschil in beveiliging tussen de twee opties.

  • SSL / TLS opent eerst een SSL / TLS-verbinding en begint vervolgens met de SMTP-transactie. Dit moet gebeuren op een poort die niet al een niet-SSL / TLS SMTP-server heeft; het is onmogelijk om een ​​enkele poort te configureren voor het verwerken van zowel platte tekst als gecodeerde verbindingen vanwege de aard van de protocollen.

  • STARTTLS start de SMTP-transactie en zoekt naar ondersteuning van de andere kant voor TLS in de reactie op EHLO. Als de client STARTTLS in de lijst met ondersteunde opdrachten ziet, verzendt deze STARTTLS en begint de onderhandeling voor codering. Dit alles kan (en gebeurt meestal) op de standaard SMTP-poort van 25, deels vanwege achterwaartse compatibiliteit, maar ook voor opportunistische codering tussen eindpunten die beide ondersteunen maar niet noodzakelijkerwijs vereisen.

Over het algemeen wordt SSL / TLS alleen gebruikt tussen eindklanten en servers. STARTTLS wordt vaker gebruikt tussen MTA's om inter-server transport te beveiligen.

Gegeven die twee implementaties, zou STARTTLS als onveilig kunnen worden geïnterpreteerd als de gebruiker of beheerder ervan uitgaat dat de verbinding is gecodeerd maar deze niet echt heeft geconfigureerd om codering te vereisen. De gebruikte codering is echter precies hetzelfde als SSL / TLS en daarom niet meer of minder kwetsbaar voor een 'Man-in-the-Middle'-aanval die verder gaat dan dit type configuratiefout.


21
2017-07-16 19:40



Als de verbinding is gecodeerd, zijn zowel SSL / TLS als STARTTLS hetzelfde, ja. Maar dat is niet wat ik vroeg. Ik bedoelde: als ik STARTTLS gebruik, hoe weet ik dan (als gebruiker) of mijn verbinding echt is beveiligd? Als ik SSL / TLS probeer te gebruiken, kan ik geen verbinding maken als de server dit niet ondersteunt, maar er wordt in ieder geval niets als leesbare tekst verzonden. Maar als STARTTLS terugvalt naar gewone tekst, wordt mijn e-mail in leesbare tekst verzonden zonder dat ik weet dat deze in gewone tekst is verzonden (waardoor ik denk dat ik veilig ben als ik niet echt ben). - Foo Bar
Ik weet niet waarom dit antwoord als correct werd gekozen. Het is verkeerd. Zoals Christopher opmerkt, is STARTTLS minder veilig dan TLS omdat het een vals gevoel van veiligheid geeft aan clients. - Greg
@greg er is niets mis met het protocol. De fout is dat clients die de rfc niet volgen en de gebruiker niet waarschuwen wanneer de verbinding niet is gecodeerd. - longneck
@longneck dus ... misschien is dit een semantisch iets, maar clients kunnen het TLS-protocol niet "volgen" en een e-mail doorlopen, punt. dus dat is een zinvol verschil. - Greg
@Bruno "Het is alleen minder veilig als de client slecht wordt geïmplementeerd" <= je maakt gewoon mijn punt voor mij aan. Als er iets is dat de client kan doen om de verbinding onveilig te maken terwijl nog steeds een werkende verbinding tot stand wordt gebracht, dan is STARTTLS minder veilig dan expliciete TLS (waar dat niet mogelijk is). - Greg


Vooral voor e-mail, in januari 2018 RFC 8314 werd uitgebracht, die expliciet aanbeveelt dat "Impliciete TLS" bij voorkeur wordt gebruikt in plaats van het STARTTLS-mechanisme voor IMAP-, POP3- en SMTP-inzendingen.

In het kort beveelt deze memo nu aan dat:

  • TLS versie 1.2 of hoger kan worden gebruikt voor alle verkeer tussen MUA's     en Mail Submission Servers, en ook tussen MUA's en Mail Access     Servers.
  • MUA's en Mail Service Providers (MSP's) (a) ontmoedigen het gebruik van     cleartext-protocollen voor e-mailtoegang en e-mailverzending en     (b) afkeuren van het gebruik van cleartext-protocollen voor deze doeleinden als     snel mogelijk.
  • Verbindingen met Mail Submission Servers en Mail Access Servers zijn     gemaakt met behulp van "Impliciete TLS" (zoals hieronder gedefinieerd), als voorkeur boven     verbinden met de "cleartext" -poort en onderhandelen over TLS met behulp van de     STARTTLS-opdracht of een vergelijkbaar commando.

(nadruk toegevoegd)


6
2018-02-01 19:38





Het antwoord hangt tot op zekere hoogte af van wat u met "veilig" bedoelt.

Ten eerste vat je samenvatting niet precies het verschil tussen SSL / TLS en STARTTLS.

  • Met SSL / TLS opent de client een TCP-verbinding met de "SSL-poort" die is toegewezen aan het toepassingsprotocol dat hij wil gebruiken en begint TLS onmiddellijk te spreken.
  • Met STARTTLS opent de client een TCP-verbinding met de "cleartext-poort" die is gekoppeld aan het toepassingsprotocol dat hij wil gebruiken, en vraagt ​​vervolgens de server "welke protocol-extensies ondersteunt u?". De server antwoordt vervolgens met een lijst met extensies. Als een van die extensies "STARTTLS" is, kan de client vervolgens zeggen "oké, laten we TLS gebruiken" en de twee beginnen met TLS te spreken.

Als de client is geconfigureerd om TLS te vereisen, zijn de twee benaderingen min of meer even veilig. Maar er zijn enkele subtiliteiten over hoe STARTTLS moet worden gebruikt om het veilig te maken, en het is een beetje moeilijker voor de STARTTLS-implementatie om die details juist te krijgen.

Als de client echter is geconfigureerd om alleen TLS te gebruiken wanneer TLS beschikbaar is en cleartext te gebruiken wanneer TLS niet beschikbaar is, probeert de client eerst verbinding te maken met de SSL-poort die door het protocol wordt gebruikt en als dat het geval is. mislukt, maak dan verbinding met de cleartext-poort en probeer STARTTLS te gebruiken, en val uiteindelijk terug naar cleartext als TLS in beide gevallen niet beschikbaar is. Het is redelijk gemakkelijk voor een aanvaller om ervoor te zorgen dat de SSL-poortverbinding mislukt (het enige dat nodig is, zijn goed getimede TCP RST-pakketten of het blokkeren van de SSL-poort). Het is een beetje moeilijker - maar slechts een klein beetje - voor een aanvaller om de STARTTLS-onderhandelingen te verslaan en ervoor te zorgen dat het verkeer in cleartext blijft. En dan kan de aanvaller niet alleen uw e-mail lezen, maar ook uw gebruikersnaam / wachtwoord vastleggen voor toekomstig gebruik.

Dus het simpele antwoord is dat als u verbinding maakt met een server waarvan u weet dat deze TLS ondersteunt (zoals het geval zou zijn wanneer u e-mail verzendt of leest), u SSL / TLS moet gebruiken. Als de verbinding wordt aangevallen, mislukt de verbindingspoging, maar worden uw wachtwoord en e-mailadres niet aangetast.

Aan de andere kant, als u verbinding maakt met een service waarvan u niet weet of deze TLS ondersteunt, kan STARTTLS iets beter zijn.

Toen STARTTLS werd uitgevonden, waren 'passieve' alleen-luisterenaanvallen heel gebruikelijk, en 'actieve' aanvallen waarbij de aanvaller verkeer zou injecteren om te proberen de beveiliging te verlagen, kwamen minder vaak voor. In de ongeveer 20 jaar sindsdien zijn actieve aanvallen meer haalbaar en gebruikelijker geworden.

Als u bijvoorbeeld een laptop op een luchthaven of een andere openbare plaats probeert te gebruiken en uw e-mail probeert te lezen via de wifi die daar wordt geboden, heeft u geen idee wat dat wifi-netwerk doet met uw verkeer. Het komt vaak voor dat wifi-netwerken bepaalde soorten verkeer naar "proxies" leiden die zich tussen uw clienttoepassingen en de servers waarmee ze proberen te communiceren, verbinden. Het is triviaal voor die proxy's om zowel STARTTLS als "probeer de ene poort dan de andere" uit te schakelen in een poging om uw klant terug te laten vallen naar cleartext. Ja, dit gebeurt, en het is slechts een voorbeeld van hoe uw verkeer bespioneerd kan worden door een netwerk. En dergelijke aanvallen zijn niet beperkt tot door de staat gesteunde agentschappen met drie letters, ze kunnen worden uitgevoerd door een tiener met een computer van $ 35 die ergens op een openbare plek is verborgen.


2
2018-02-02 09:29





Ja, je hebt de basis goed. En ja, STARTTLS is zeker minder veilig. Niet alleen kan het foutloos worden zonder kennisgeving, maar ook omdat het onderhevig is aan man-in-the-middle-aanvallen. Omdat de verbinding in het wissen begint, kan een MitM het STARTTLS-commando verwijderen en voorkomen dat de codering ooit optreedt. Ik geloof echter dat mailservers kunnen specificeren dat transfers alleen plaatsvinden nadat een gecodeerde tunnel is ingesteld. Dus je kunt hier omheen werken.

Dus waarom bestaat zoiets zelfs? Om compatibiliteitsredenen. Als een van beide zijden codering niet ondersteunt, wilt u mogelijk toch dat de verbinding correct wordt voltooid.


1
2017-07-16 19:20



Dus een server die STARTTLS ondersteunt, kan ook altijd SSL / TLS gebruiken, toch? Dus het is altijd beter om eerst SSL / TLS te proberen en te kijken of het werkt? - Foo Bar
@FooBar nee, de ene wil niet zeggen dat de andere beschikbaar is. in feite kunnen ze worden geconfigureerd met volledig verschillende verificatiedomeinen. - longneck
STARTTLS is niet kwetsbaar voor MitM tenzij u certificaten niet valideert of zwakke gebruikt. Het certificaat wordt nog steeds precies hetzelfde gepresenteerd als altijd en de client kan eisen dat de TLS-upgrade slaagt voordat hij doorgaat. Het is vermeldenswaard dat dit precies dezelfde situatie is als SSL / TLS. - Falcon Momot
Weet niet waarom mensen je een bericht sturen, dit is het juiste antwoord, STARTTLS is minder veilig dan TLS en geeft een vals gevoel van veiligheid. ISP's kunnen het gewoon aangeven: arstechnica.com/tech-policy/2014/11/... - Greg
Voor zover het protocol zelf gaat, is STARTTLS minder veilig dan TLS omdat het expliciet onbewerkte tekstcommunicatie toestaat zonder de gebruiker te waarschuwen: serverfault.com/a/648282/207987 - Greg


Ben het eens met @Greg. Die aanvallen zijn mogelijk. De MTA's kunnen echter worden geconfigureerd (afhankelijk van de MTA) om "verplichte TLS" te gebruiken, niet "opportunistische TLS". Wat dit betekent is dat TLS en alleen TLS wordt gebruikt (dit omvat ook STARTTLS) voor de e-mailtransacties. Als de externe MTA STARTTLS niet ondersteunt, wordt de e-mail geretourneerd.


1
2018-04-02 23:47





Nee het is niet minder veilig, als uw applicatie het correct verwerkt.

Er zijn vier manieren om met TLS om te gaan en met veel programma's kun je kiezen:

  • Geen TLS
  • TLS op speciale poort (probeert alleen TLS)
  • Gebruik TLS indien beschikbaar (Trots starttls, gebruikt een niet-versleutelde verbinding wanneer deze mislukt)
  • Gebruik altijd TLS (gebruik starttls en mislukt als het niet werkt)

Het voordeel van TLS op een speciale poort is dat u er zeker van kunt zijn dat er geen terugval is wanneer u een programma gebruikt dat u nog niet kent of dat de detailinstellingen voor foutafhandeling niet onthult in de wizard voor het eerste starten.

Maar over het algemeen hangt de beveiliging af van de afhandeling van beveiligingsfouten. Een programma kan besluiten om over te schakelen naar de plaintext-poort wanneer TLS op de TLS-poort ook mislukt. U moet weten wat het zal doen en veilige instellingen kiezen. En programma's zouden veilige standaardinstellingen moeten gebruiken.


0
2018-02-02 10:10