DANE - Autentificare bazată pe DNS a entităților denumite

E-mailurile sunt transmise între servere prin SMTP, prin care expeditorul găsește serverul de destinație utilizând înregistrarea MX și transmite e-mailul prin portul 25/TCP. Pentru o lungă perioadă de timp, toate e-mailurile au fost transmise în general necriptate, deși există un standard cu TLS/SSL/STARTTLS de mult timp pentru a cripta e-mailurile cel puțin pe ruta de transport. Certificatele sunt, desigur, necesare pentru această criptare.

Acest site este încă în construcție. DANE permite verificarea certificatului sistemului țintă prin DNSSEC. Din păcate, nu este planificată nicio verificare a emițătorului. Din păcate, nu va fi un filtru de spam.

Certificate utilizate

Certificatele nu sunt un lucru rău în sine, deoarece permit o transmitere destul de sigură a e-mailurilor de care beneficiază ambele părți:

• Expeditorul.
  . poate fi sigur că a ajuns la serverul țintă corect. Acest lucru este comparabil cu accesarea serviciilor bancare la domiciliu. Introduceți un nume mai sus și certificatul trebuie să conțină și acest nume. Altfel ai ajuns în altă parte
• Destinatar.
  . poate identifica opțional computerul prin certificatul expeditorului.

Pe hârtie, acest principiu arată foarte elegant și rezistent la apă, dar nu este. Există mai multe lucruri de reținut:

• Fără autocertificate -> costuri
  O problemă aici este că cel puțin destinatarul trebuie să aibă un „certificat de încredere”. Dacă este permis un autocertificat, un atacator din mijloc poate afișa pur și simplu un certificat, iar securitatea nu este garantată.
• Spoofing DNS
  Mai mult, un atacator ar putea pur și simplu subjuga expeditorul către un alt server pentru o cerere MX pentru care atacatorul are un certificat corect. Cu greu nimeni nu va observa că poșta face un „ocol” dacă destinația nu verifică expeditorul. Destinatarul trebuie, de asemenea, să poată „verifica” expeditorul. Falsurile din interogările DNS pot de ex. preveniți cu DNSSEC.
• CA încredere
  Desigur, trebuie asigurat, de asemenea, că autoritățile de certificare emitente, în care partenerii au încredere, și-au câștigat încrederea. Din păcate, nu ar fi prima dată când o CA emite fals un certificat și multe CA se află în țări în care nu puteți fi siguri că autoritățile de anchetă și serviciile secrete nu pot obține un certificat pentru un nume interesant.

În acest sens, TLS/SSL/STARTTLS este un început de criptare a comunicațiilor, dar doar la jumătatea drumului, atâta timp cât partenerii nu își demonstrează identitatea în mod fiabil.

Verificarea expeditorului și IPv6

Mai ales când vine vorba de SPAM, vom avea din ce în ce mai multe probleme cu listele clasice de blocuri odată cu creșterea conexiunilor IPv6. Astăzi, Internetul este format din maximum 255 * 255 * 255 * 255 adrese. Astăzi acest lucru este „gestionabil”, iar bazele de date și serviciile corespunzătoare pot menține destul de fiabil o listă a „sistemelor nedorite” care pot fi recunoscute ca expeditori de spam, injectori de viruși sau alte programe malware.

Cu IPv6 acest lucru devine mult mai dificil. Listele clasice de blocuri își vor atinge limitele aici, deoarece spammerii pot utiliza teoretic o adresă IP separată pentru fiecare e-mail. Cu siguranță vor exista din nou oportunități de a crea subrețele sau similare. Cu toate acestea, pentru a le grupa la fel de ușor și eficient ca astăzi, filtrarea la nivel de IP nu va mai funcționa. Cu toate acestea, un filtru de spam poate începe filtrarea numai în timpul transmiterii efective a e-mailului. E deja târziu.

Un mod în care companiile pot ajuta este prin publicarea serverelor de poștă de ieșire, de ex. prin DNS. SenderID sau SPF. Serverul destinatar se uită la expeditorul unui e-mail primit, interogă „serverul de ieșire” prin DNS și dacă IP-ul sursă se potrivește, atunci acesta poate accepta e-mailul. Pentru „atacatorul normal” este relativ ușor să falsifici IP-ul sursă al unui pachet, dar pentru a colecta pachetele returnate, un atacator trebuie să schimbe rutele de pe Internet. pentru organizațiile de stat (servicii secrete etc.) ar trebui să fie corespunzător ușor dacă ținta poate fi infiltrată în acest fel.

Atâta timp cât interogările DNS în sine nu sunt „securizate”, răspunsul la o interogare RBL poate fi, desigur, falsificat sau distrus de către un atacator. Atâta timp cât RBL și colab. nu este „obligatoriu”, ci doar opțional, acest lucru este suficient pentru a omite cecul destinatarului.

Verificarea țintei cu TLS și DNSSEC

Este mult mai avantajos dacă includem criptarea de transport dorită și semnarea în verificarea expeditorului. O propunere corespunzătoare este descrisă în „Autentificarea bazată pe DNS RFC 6698 a entităților denumite”, care, de asemenea, în introducere afirmă că certificatele sunt frumoase, dar fiecare CA „de încredere” poate emite o cheie pentru fiecare nume. Acest lucru poate fi îmbunătățit dacă proprietarul domeniului, de ex. informațiile despre certificatele utilizate sunt publicate prin DNS. Cu toate acestea, pentru ca tocmai aceste informații să nu fie modificate de atacatori, transmisia DNS trebuie cel puțin semnată. DNSSEC este utilizat pentru aceasta, prin care zona de mai sus oferă apoi informații despre semnătura subzonei.

În acest fel, un server care vorbește cu o stație la distanță prin TLS poate primi informații prin DNSSEC cu privire la ce certificat este de așteptat. În cele din urmă, este doar o chestiune de coordonare între operatorul de servicii și administratorul DNS pentru a introduce corect datele corecte. Strict vorbind, certificatul nu ar trebui nici măcar eliberat de o autoritate de certificare publică, ci ar putea fi un autocertificat.

Este doar o rușine că DNSSEC este încă în fază incipientă și că un server Exchange nu poate introduce automat „autocertificatul” său în zona DNS prin DynDNS. Din motive de securitate, probabil că nu vor exista actualizări dinamice ale intrărilor de certificate în DNS. Cu Windows DNS, o zonă securizată de DNSSEC nu mai poate fi utilizată pentru actualizări dinamice.

Configurați DANE

DANE este în prezent întotdeauna configurat pe sistemul țintă sau serverul destinatar își poate publica informațiile prin DANE, iar expeditorul poate, dar nu trebuie să folosească aceste informații. Sunt necesare următoarele cerințe.

• Domeniu țintă securizat de DNSSEC
  Abia atunci are sens deloc să stochezi informații pentru verificare.
• Serverul țintă trebuie să facă SSL/TLS
  Conexiunea de date trebuie să fie posibilă prin SSL/TLS. Abia atunci expeditorul va primi un certificat de la țintă și va avea ceva de verificat în consecință
• Clientul/expeditorul trebuie să poată rezolva DNSSEC
  Sistemul gazdă trebuie să poată, desigur, să rezolve și să verifice calea către serverul clientului începând din zona rădăcină și registrator, adică serverele și rezoluțiile DNS trebuie să furnizeze DNSSEC
• Aplicația client/expeditor trebuie să accepte DANE
  În cele din urmă, desigur, aplicația în sine trebuie să dorească în continuare să folosească DANE.

Cu toate acestea, merită efortul de a publica informațiile despre certificatul utilizat. În prima etapă, probabil vor fi programe de completare pentru browser care utilizează valoarea adăugată. Pe termen mediu, sistemele de proxy și relee la companii vor scuti utilizatorul de această muncă, adică un server de mail nu trimite e-mailul dacă certificatul primit nu se potrivește cu informațiile despre certificat stocate în DNS. La un moment dat poate deveni echipamentul standard al sistemelor de operare sau modulul TLS.

Configurarea are loc în mai mulți pași:

---