Opportunistisk TLS - Opportunistic TLS

"STARTTLS" omdirigerer her. For certifikatmyndighed, se StartCom § StartSSL .

Opportunistisk TLS (Transport Layer Security) refererer til udvidelser i almindelige tekstkommunikationsprotokoller, som tilbyder en måde at opgradere en ren tekstforbindelse til en krypteret ( TLS eller SSL ) forbindelse i stedet for at bruge en separat port til krypteret kommunikation. Flere protokoller bruger en kommando med navnet " STARTTLS " til dette formål. Det er en form for opportunistisk kryptering og er primært tænkt som en modforanstaltning til passiv overvågning .

Kommandoen STARTTLS for IMAP og POP3 er defineret i RFC  2595 , til SMTP i RFC  3207 , til XMPP i RFC  6120 og til NNTP i RFC  4642 . For IRC har IRCv3 -arbejdsgruppen defineret STARTTLS -udvidelsen. FTP bruger kommandoen "AUTH TLS" defineret i RFC  4217 og LDAP definerer en protokoludvidelse OID i RFC  2830 . HTTP bruger opgraderingsoverskrift .

Lagdeling

TLS er applikationsneutral; med ordene i RFC  5246 :

En fordel ved TLS er, at den er applikationsprotokoluafhængig. Højere protokoller kan lag oven på TLS-protokollen gennemsigtigt. TLS -standarden angiver imidlertid ikke, hvordan protokoller tilføjer sikkerhed med TLS; beslutningerne om, hvordan man starter TLS -håndtryk, og hvordan man fortolker de udvekslede godkendelsescertifikater, overlades til designere og implementatorer af protokoller, der kører oven på TLS.

Den stil, der bruges til at angive, hvordan man bruger TLS matcher den samme lagforskel, der også bekvemt understøttes af flere biblioteksimplementeringer af TLS. F.eks. Illustrerer RFC  3207 SMTP -udvidelsen med følgende dialog, hvordan en klient og server kan starte en sikker session: 

  S: <waits for connection on TCP port 25>
  C: <opens connection>
  S: 220 mail.example.org ESMTP service ready
  C: EHLO client.example.org
  S: 250-mail.example.org offers a warm hug of welcome
  S: 250 STARTTLS
  C: STARTTLS
  S: 220 Go ahead
  C: <starts TLS negotiation>
  C & S: <negotiate a TLS session>
  C & S: <check result of negotiation>
  C: EHLO client.example.org
  . . .

Den sidste EHLO -kommando ovenfor udsendes over en sikker kanal. Bemærk, at godkendelse er valgfri i SMTP, og det udeladte serversvar kan nu sikkert annoncere en AUTH PLAIN SMTP-udvidelse, som ikke findes i klartekstsvaret.

SSL -porte

Udover brugen af ​​opportunistisk TLS blev der defineret et antal TCP-porte til SSL-sikrede versioner af velkendte protokoller. Disse etablerer sikker kommunikation og præsenterer derefter en kommunikationsstrøm, der er identisk med den gamle ukrypterede protokol. Separate SSL-porte har fordelen ved færre rundrejser ; også mindre metadata overføres i ukrypteret form. Nogle eksempler omfatter:

Protokol Formål Normal port SSL -variant SSL -port
SMTP Send e-mail 25/587 SMTPS 465
POP3 Hent e -mail 110 POP3S 995
IMAP Læs e -mail 143 IMAPS 993
NNTP Nyhedslæser 119/433 NNTPS 563
LDAP Katalogadgang 389 LDAPS 636
FTP Filoverførsel 21 FTPS 990

I hvert fald for de e -mailrelaterede protokoller foretrækker RFC  8314 separate SSL -porte i stedet for STARTTLS.

Svagheder og afbødninger

Opportunistisk TLS er en opportunistisk krypteringsmekanisme . Fordi det første håndtryk finder sted i almindelig tekst, kan en angriber med kontrol over netværket ændre serverbeskederne via et man-in-the-middle-angreb for at få det til at se ud som om TLS ikke er tilgængelig (kaldet et STRIPTLS-angreb ). De fleste SMTP -klienter sender derefter e -mailen og muligvis adgangskoder i ren tekst, ofte uden meddelelse til brugeren. Især forekommer mange SMTP -forbindelser mellem mailservere, hvor brugermeddelelse ikke er praktisk.

I september 2014 viste det sig, at to internetudbydere i Thailand gjorde dette mod deres egne kunder. I oktober 2014 blev Cricket Wireless , et datterselskab af AT&T , afsløret for at gøre dette mod deres kunder. Denne adfærd startede allerede i september 2013 af Aio Wireless , der senere fusionerede med Cricket, hvor øvelsen fortsatte.

STRIPTLS -angreb kan blokeres ved at konfigurere SMTP -klienter til at kræve TLS til udgående forbindelser (f.eks. Exim Message -overførselsagenten kan kræve TLS via direktivet "hosts_require_tls"). Men da ikke alle mailservere understøtter TLS, er det ikke praktisk bare at kræve TLS for alle forbindelser.

Et eksempel på et STRIPTLS -angreb af den type, der bruges i thailandsk masseovervågningsteknologi :

Dette problem løses af DNS-baseret Authentication of Named Entities (DANE), en del af DNSSEC , og især af RFC  7672 til SMTP. DANE giver mulighed for at annoncere support til sikker SMTP via en TLSA -post. Dette fortæller forbindelsesklienter, at de skal kræve TLS og forhindrer dermed STRIPTLS -angreb. STARTTLS Everywhere -projektet fra Electronic Frontier Foundation fungerer på en lignende måde. På grund af implementeringskomplekser og ejendommelig kritik stod DNSSEC imidlertid over for en lav vedtagelsesrate, og en ny protokol kaldet SMTP MTA Strict Transport Security eller MTA-STS er blevet udarbejdet af en gruppe større e-mail-tjenesteudbydere, herunder Microsoft, Google og Yahoo. MTA-STS kræver ikke brug af DNSSEC til at godkende DANE TLSA-poster, men er afhængig af certificeringsmyndighedens (CA) system og en tillid-til-første-brug (TOFU) tilgang for at undgå aflytninger. TOFU -modellen reducerer kompleksiteten, men uden garantier ved første brug, der tilbydes af DNSSEC. Derudover introducerer MTA-STS en mekanisme til fejlrapportering og en rapport-only-tilstand, der muliggør progressiv udrulning og revision for overholdelse.

Popularitet

Efter afsløringerne af Edward Snowden i lyset af den globale masseovervågningsskandale har populære e -mail -udbydere forbedret deres e -mail -sikkerhed ved at aktivere STARTTLS. Facebook rapporterede, at efter at have aktiveret STARTTLS og opfordret andre udbydere til at gøre det samme, indtil Facebook afbrød sin e -mailtjeneste i februar 2014, blev 95% af udgående e -mail krypteret med både Perfect Forward Secret og streng certificeringsvalidering.

Referencer

eksterne links