E-posta kimlik doğrulaması - Email authentication

Kafanı karıştırmamak SMTP Kimlik Doğrulaması.

E-posta kimlik doğrulamasıveya doğrulama, e-posta mesajlarının kaynağı hakkında doğrulanabilir bilgi sağlamayı amaçlayan bir teknikler koleksiyonudur. etki alanı sahipliği herhangi bir mesaj aktarım aracıları (MTA) bir mesajın aktarılmasına ve muhtemelen değiştirilmesine katılan.

İnternet e-postasının orijinal tabanı, Basit Posta Aktarım Protokolü (SMTP) böyle bir özelliğe sahip değildir, bu nedenle e-postalardaki sahte gönderen adresleri ( e-posta sahtekarlığı ) yaygın olarak kullanılmaktadır e-dolandırıcılık, e-posta spam ve çeşitli dolandırıcılık türleri. Bununla mücadele etmek için, birçok rakip e-posta kimlik doğrulama önerisi geliştirildi, ancak yalnızca oldukça yakın zamanda üçü geniş çapta kabul edildi - SPF, DKIM ve DMARC.[1][2] Bu tür doğrulamanın sonuçları otomatik olarak kullanılabilir e-posta filtreleme veya uygun bir eylem seçerken alıcılara yardımcı olabilir.

Bu makale kullanıcıyı kapsamaz kimlik doğrulama e-posta gönderme ve alma.

Gerekçe

1980'lerin başında Basit Posta Aktarım Protokolü (SMTP) tasarlandı, gönderen kullanıcı veya sistemin gerçek bir doğrulaması için sağlanmadı. Bu, e-posta sistemleri güvenilir şirketler ve üniversiteler tarafından çalıştırılırken bir sorun değildi, ancak İnternetin ticarileştirilmesi 1990'ların başında, istenmeyen e, e-dolandırıcılık ve diğer suçlar giderek daha fazla e-postayı içeriyor.

E-posta kimlik doğrulaması, mesajların kökenini belirlemeye yönelik gerekli bir ilk adımdır ve böylece politikaları ve yasaları daha uygulanabilir hale getirir.

Etki alanı sahipliğine bağlı kalmak, 2000'in başlarında ortaya çıkan bir duruştur.[3][4] Etki alanlarının e-posta adreslerinin sağ tarafında, e-posta adreslerinden sonra göründüğü göz önüne alındığında, genel bir kimlik doğrulaması anlamına gelir işaretini. Kullanıcı düzeyinde ince taneli kimlik doğrulama, aşağıdakiler gibi başka yollarla sağlanabilir: Oldukça iyi Gizlilik ve S / MIME. Şu anda, dijital kimlik her birey tarafından yönetilmesi gerekiyor.

E-posta kimlik doğrulaması için olağanüstü bir mantık, alıcı sunucularda e-posta filtrelemesini otomatikleştirme yeteneğidir. Bu şekilde, sahte iletiler bir kullanıcının Gelen Kutusu'na ulaşmadan reddedilebilir. Protokoller, güvenilmeyen postaları güvenilir bir şekilde engellemenin yollarını bulmaya çalışırken, güvenlik göstergeleri hala Gelen Kutusu'na ulaşan kimliği doğrulanmamış iletileri etiketleyebilir. 2018'de yapılan bir araştırma, güvenlik göstergelerinin tıklama oranını on puandan daha fazla düşürebildiğini gösteriyor; bu, sahte mesajlar açan kullanıcıların% 48,9'undan% 37,2'sine.[5]

Sorunun doğası

SMTP mesajı tanımlar Ulaşım, mesaj değil içerik. Böylece postayı tanımlar zarf ve onun gibi parametreleri zarf gönderen, ancak başlık değil (hariç izleme bilgisi) ne de mesajın gövdesi. STD 10 ve RFC  5321 SMTP'yi (zarf) tanımlarken, STD 11 ve RFC  5322 resmi olarak adı geçen mesajı (başlık ve gövde) tanımlayın İnternet Mesaj Formatı.

SMTP, izleme bilgisi Aşağıdaki iki alan kullanılarak başlıkta kaydedilen bir mesajın[6]

  • Alınan: bir SMTP sunucusu bir mesajı kabul ettiğinde, bu izleme kaydını başlığın en üstüne (sondan ilke) ekler.
  • Dönüş yolu: teslimat SMTP sunucusu, Nihai teslimat mesajın üst kısmına bu alanı ekler.

Bir posta kullanıcı aracısı (MUA) bilir giden posta SMTP sunucusu yapılandırmasından. Bir MTA (veya bir aktarma sunucusu) genellikle hangi sunucuya bağlanılacağını belirler. MX (Mail eXchange) DNS her alıcının kaynak kaydı alan adı

Aşağıda tasvir edilen yol, arazi üzerinde yeniden inşa edilebilir. başlık alanları izleme her ana bilgisayar, iletiyi aldığında başlığın üstüne ekler:[6]

E-posta kimlik doğrulaması, bir ara geçişin varlığı ile karmaşık hale gelebilir. Bir ve B açıkça yazar ADMD'ye aittir. D ve E alıcı ağın bir parçasıdır. Ne rolü var C Oyna?
Dönüş yolu:<[email protected]>Alınan:itibarenD.example.orgtarafındanE.example.orgileSMTP;Sal, 5 Şubat 2013 11:45:02 -0500Alınan:itibarenC.example.nettarafındanD.example.orgileSMTP;Sal, 5 Şubat 2013 11:45:02 -0500Alınan:itibarenB.example.com(b.example.com[192.0.2.1])tarafındanC.example.net(hangidır-dirben mi)ileESMTPİD936ADB8838Ciçin<[email protected]>;Sal, 5 Şubat 2013 08:44:50 -0800(PST)Alınan:itibarenA.example.comtarafındanB.example.comileSMTP;Salı, 05 Şubat 2013 17:44:47 +0100Alınan:itibaren[192.0.2.27]tarafındanA.example.comileSMTP;Salı, 5 Şubat 2013 17:44:42 +0100

Başlığın üst kısmındaki ilk birkaç satıra genellikle alıcı tarafından güvenildiğinin farkında olmak önemlidir. Aslında, bu satırlar alıcının İdari Yönetim Alanındaki (EKLE ), kendi açık yetkisine göre hareket eden. Buna karşılık, katılımını kanıtlayan çizgiler Bir ve Byanı sıra sözde yazarın MUA sahte olabilir C. Alınan: yukarıda gösterilen alan, başlığın çığır açan bir parçasıdır. Dönüş yolu: tarafından yazılmıştır E, posta dağıtım acentesi (MDA), mesaja göre zarf. E-posta kimlik doğrulaması için tasarlanmış ek izleme alanları, başlığın üst kısmını doldurabilir.

Normalde, bir yazarın ADMD'si tarafından gönderilen mesajlar doğrudan hedefin MX (yani B → D şekillerde). Gönderenin ADMD'si, yalnızca mesaj kutularından geçerse kimlik doğrulama belirteçleri ekleyebilir. En yaygın durumlar aşağıdaki gibi şematize edilebilir:

Bir e-posta mesajının yazarından alıcısına aktarılmasının en yaygın yollarının şematik temsili.

ADMD'nin ağı (MUA 1) içinden gönderme

  • ADMD'ler MSA ya göre kullanıcının kimliğini doğrular IP adresi veya başka bir SMTP Kimlik Doğrulaması anlamına gelir. Alıcının adresine bağlı olarak, mesaj normal yolu izleyebilir veya bir posta listesinden veya bir yönlendirme hizmetinden geçebilir.[not 1] B giden olabilir SMTP proxy veya a akıllı ana makine.[not 2]
  • Yerel ağ, giden bağlantı noktası 25 bağlantılarını engellemiyorsa,[not 3] kullanıcı bazı "doğrudan mx'e" yazılımları kurabilir.[not 4] Tipik, zombiler ve diğer kötü niyetli ana bilgisayarlar bu şekilde davranır.
  • MUA kötü yapılandırılmışsa, modası geçmiş gibi farklı bir röle de kullanabilir. açık röle, bu genellikle kullanıcının kimliğini doğrulamaz.

Gezici kullanıcı (MUA 2)

  • Çoğu zaman kişinin kendi ADMD MSA'sını kullanmak hala mümkündür.[not 5]
  • 25 numaralı bağlantı noktasına giden bağlantılar durdurulabilir ve şeffaf bir proxy'ye tünellenebilir.[not 4]
  • Bir MUA, yerel ağ sağlayıcısının bonus olarak sunduğu bir SMTP geçişini kullanacak şekilde yapılandırılabilir.[not 4]

Bağlantısı kesilmiş kullanıcı

  • Bir e-kart e-posta adreslerini yerel klavyede yazan bir müşteri adına posta gönderebilir; biraz web formları benzer şekilde çalıştığı düşünülebilir.[not 4]

Bölüm notları

  1. ^ Örneğin, bir alıcı talimat verebilir Gmail Mesajları farklı bir e-posta adresine iletmek için. Gönderenin bunun farkında olması gerekmez.
  2. ^ Düzgün yapılandırılmış proxy'ler yazar ADMD'nin bir parçası olarak görünür.
  3. ^ Bazı ADMD'ler bunu önlemek için 25 numaralı bağlantı noktasına (SMTP) giden bağlantıyı engeller. Bu proaktif teknik, RFC 5068. Ek olarak, bazı gelen SMTP bağlantılarını IP'ler Olarak listelenmiş çevirmek / DSL / kablo.
  4. ^ a b c d Bu durumda, yazarın ADMD'si hiç dahil değildir.
  5. ^ Bazı ISS'ler 587 numaralı bağlantı noktasını engeller, ancak RFC 5068 açıkça diyor ki:

    Erişim Sağlayıcılar, kullanıcıların GÖNDERİM bağlantı noktası 587'yi kullanarak harici İnternet'e erişimini ENGELLEMEMELİDİR.

Yaygın kullanımda kimlik doğrulama yöntemleri

SPF

Ana makale: Gönderen Politikası Çerçevesi
SPF, gönderenin IP adresini doğrular.

SPF, alıcının belirli bir etki alanından geldiği iddia edilen bir e-postanın, o etki alanının yöneticileri tarafından yetkilendirilmiş bir IP adresinden gelip gelmediğini kontrol etmesine olanak tanır. Genellikle, bir alan yöneticisi, herhangi bir proxy veya akıllı ana makine dahil olmak üzere kendi giden MTA'ları tarafından kullanılan IP adreslerini yetkilendirir.[7][8]

Gönderen MTA'nın IP adresinin geçerli olduğu garanti edilir. Geçiş kontrol protokolü uzak ana bilgisayarın erişilebilir olup olmadığını kontrol ederek bağlantı kurduğu için.[9] Alıcı posta sunucusu, HELO SMTP bağlantı kurulduktan hemen sonra komut ve bir Mail şu kişiden geldi: her mesajın başında. Her ikisi de bir alan adı içerebilir. SPF doğrulayıcı, Alan Adı Sistemi Eşleşen bir SPF kaydı için (DNS), eğer varsa, bu alan adı yöneticisi tarafından yetkilendirilen IP adreslerini belirtir. Sonuç "başarılı", "başarısız" veya bazı ara sonuçlar olabilir - ve sistemler genellikle spam önleme filtrelemelerinde bunu dikkate alır.[10]

DKIM

Ana makale: Alan Anahtarları Tarafından Tanımlanan Posta
DKIM, mesaj içeriğinin bazı kısımlarını doğrular.

DKIM, mesaj içeriği, dağıtılıyor dijital imzalar. Dijital sertifikalar kullanmak yerine, imza doğrulama anahtarları DNS aracılığıyla dağıtılır. Bu şekilde, bir mesaj bir alan adıyla ilişkilendirilir.[11]

DKIM uyumlu bir alan yöneticisi, bir veya daha fazla çift oluşturur asimetrik anahtarlar, daha sonra özel anahtarları imzalayan MTA'ya verir ve DNS'de genel anahtarları yayınlar. DNS etiketleri şu şekilde yapılandırılmıştır: seçici._domainkey.example.com, nerede seçici anahtar çiftini tanımlar ve _domainkey sabit bir anahtar kelimedir ve ardından imza alan adı gelir, böylece yayın, söz konusu alanın ADMD yetkisi altında gerçekleşir. SMTP taşıma sistemine bir mesaj enjekte etmeden hemen önce, MTA imzalama başlığı ve gövdenin seçili alanlarını (veya sadece başlangıcını) kapsayan bir dijital imza oluşturur. İmza, aşağıdaki gibi önemli başlık alanlarını kapsamalıdır: Kimden:, Kime:, Tarih:, ve Konu:ve ardından bir izleme alanı olarak ileti başlığının kendisine eklenir. Herhangi bir sayıda röle mesajı alabilir ve iletebilir ve her atlamada, imza DNS'den genel anahtar alınarak doğrulanabilir.[12] Ara geçişler bir mesajın imzalı kısımlarını değiştirmediği sürece, DKIM imzaları geçerliliğini korur.

DMARC

Ana makale: Etki Alanı Bazlı Mesaj Kimlik Doğrulaması, Raporlama ve Uygunluk

DMARC, kimliği doğrulanmış iletiler için bir ilkenin belirtilmesine izin verir. Mevcut iki mekanizmanın üzerine inşa edilmiştir, Gönderen Politikası Çerçevesi (SPF) ve Alan Anahtarları Tarafından Tanımlanan Posta (DKIM).

Bir alan adının yönetici sahibinin kendi DNS o etki alanından e-posta gönderirken hangi mekanizmanın (DKIM, SPF veya her ikisi) kullanıldığını belirten kayıtlar; nasıl kontrol edilir Kimden: son kullanıcılara sunulan alan; alıcının hatalarla nasıl başa çıkması gerektiği ve bu politikalar altında gerçekleştirilen eylemler için bir raporlama mekanizması.

Diğer yöntemler. Diğer metodlar

Bir dizi başka yöntem önerilmiş, ancak şu anda ya kullanımdan kaldırılmıştır ya da henüz yaygın bir destek kazanmamıştır. Bunlar dahil Gönderen Kimliği, Sertifikalı Sunucu Doğrulaması, DomainKeys ve aşağıdakiler:

ADSP

Ana makale: Yazar Etki Alanı İmzalama Uygulamaları

ADSP, yazarın etki alanı tarafından imzalanan iletiler için bir ilkenin belirtilmesine izin verdi. Bir iletinin önce DKIM kimlik doğrulamasından geçmesi gerekiyordu, daha sonra ADSP, ileti yazar alan (lar) ı tarafından imzalanmamışsa cezalandırıcı bir muamele talep edebilir. Kimden: başlık alanı.[13]

ADSP, Kasım 2013'te tarihe indirildi.[14]

VBR

Ana makale: Referans Kefil

VBR, zaten kimliği doğrulanmış bir kimliğe bir makbuz ekler. Bu yöntem, etki alanlarının itibarını onaylayan bazı küresel olarak tanınan yetkililer gerektirir.

Bir gönderen, bir belge makamına referans için başvurabilir. Referans kabul edilirse, o otorite tarafından yönetilen DNS şubesinde yayınlanır. Kefil olan bir gönderen bir VBR-Bilgisi: gönderdiği mesajların başlık alanı. Ayrıca bir DKIM imzası eklemeli veya SPF gibi başka bir kimlik doğrulama yöntemi kullanmalıdır. Bir alıcı, gönderenin kimliğini doğruladıktan sonra, talep edilen makbuzu doğrulayabilir VBR-Bilgisi: referansa bakarak.[15]

iprev

Ana makale: İleri onaylı ters DNS

Uygulamalar, bu yöntemi bir kimlik doğrulama aracı olarak kullanmaktan kaçınmalıdır.[16] Bununla birlikte, genellikle gerçekleştirilir ve sonuçları, varsa, Alınan: SMTP belirtiminin gerektirdiği TCP bilgilerinin yanı sıra başlık alanı.

Yeni bulunan adın IP adresine bakılarak onaylanan IP tersi, IP'nin DNS'de doğru şekilde ayarlandığının bir göstergesidir. ters çözünürlük bir dizi IP adresi, bunları kullanan ADMD'ye devredilebilir,[17] veya şebeke sağlayıcısı tarafından yönetilmeye devam edebilir. İkinci durumda, mesajla ilgili hiçbir yararlı kimlik elde edilemez.

DNSWL

Bir DNSWL (DNS tabanlı beyaz liste), muhtemelen kimliği de dahil olmak üzere gönderenin bir değerlendirmesini sağlayabilir.

Kimlik Doğrulama Sonuçları

RFC 8601 bir izleme başlığı alanı tanımlar Kimlik Doğrulama Sonuçları: bir alıcının, gerçekleştirdiği e-posta kimlik doğrulama kontrollerinin sonuçlarını kaydedebileceği yer.[16] Birden çok sonuç için birden çok sonuç yöntemler aynı alanda, noktalı virgülle ayrılmış ve uygun şekilde kaydırılarak raporlanabilir.

Örneğin, aşağıdaki alan sözde şöyle yazılmıştır: alıcı.example.org ve raporlar SPF ve DKIM Sonuçlar:

Kimlik Doğrulama Sonuçları:alıcı.example.org;spf = passsmtp.mailfrom=ornek.com;dkim = geçmek[email protected]

Alan adından sonraki ilk simge, alıcı.example.org, kimlik doğrulama sunucusunun kimliğidir; authserv-id. Destekleyen bir alıcı RFC 8601 kendi etki alanına ait olduğunu iddia eden herhangi bir yanlış başlığı kaldırmaktan (veya yeniden adlandırmaktan) sorumludur, böylece aşağı akış filtreleri karışmaz. Ancak, etki alanının hangi kimlikleri kullanabileceğini bilmeleri gerektiğinden, bu filtrelerin yine de yapılandırılması gerekir.

Bir Posta Kullanıcı Aracısı (MUA) için, hangi kimliklere güvenebileceğini öğrenmek biraz daha zordur. Kullanıcılar birden fazla alandan e-posta alabildiğinden (ör. Birden fazla e-posta adresleri varsa) bu alan adlarından herhangi biri Kimlik Doğrulama Sonuçları: alanlar nötr göründükleri için geçer. Bu şekilde, kötü niyetli bir gönderen, authserv-id ileti farklı bir etki alanından gelirse kullanıcının güveneceği. Meşru Kimlik Doğrulama Sonuçları: tipik olarak a'nın hemen üstünde görünür Alınan: alan, iletinin aktarıldığı aynı etki alanına aittir. Ek Alınan: Mesaj aynı, güvenilen ADMD'ye ait sunucular arasında dahili olarak aktarılırken, bununla başlığın üstü arasında alanlar görünebilir.

İnternette Atanan Numaralar Kurumu kaydını tutar E-posta Kimlik Doğrulama Parametreleri. Yine de tüm parametrelerin kaydedilmesi gerekmez. Örneğin, bir sitenin yalnızca dahili kullanımı için tasarlanmış, yerel yapılandırmaya karşılık gelen ve kayıt gerektirmeyen yerel "ilke" değerleri olabilir.

Ayrıca bakınız

Referanslar

  1. ^ Hang Hu; Peng Peng; Gang Wang (2017). "Anti-Spoofing Protokollerinin Kabulüne Doğru". arXiv:1711.06654 [cs.CR ].
  2. ^ Kerner, Sean Michael. "DMARC E-posta Güvenliğinin Kabulü ABD Hükümetinde Büyüyor". eWeek. Alındı 24 Kasım 2018.
  3. ^ "E-posta Kimlik Doğrulama Zirvesi". atölye. Federal Ticaret Komisyonu. 9-10 Kasım 2004. 3 Haziran 2012 tarihinde orjinalinden arşivlendi. Alındı 4 Şubat 2013. Bununla birlikte Rapor, etki alanı düzeyinde kimlik doğrulamayı ümit verici bir teknolojik gelişme olarak tanımladı.CS1 bakımlı: uygun olmayan url (bağlantı)
  4. ^ Michael Hammer (14 Ağustos 2020). "üçüncü taraf yetkilendirme". dmarc-ietf (Mail listesi). Alındı 14 Ağustos 2020.
  5. ^ Hang Hu; Gang Wang (15 Ağustos 2018). "E-posta Sahtekarlığı Saldırılarının Uçtan Uca Ölçümleri". 27'si USENIX Güvenlik Sempozyumu.
  6. ^ a b John Klensin (Ekim 2008). "İzleme Bilgileri". Basit Posta Aktarım Protokolü. IETF. sn. 4.4. doi:10.17487 / RFC5321. RFC 5321. Alındı 1 Şubat 2013. SMTP sunucusu, geçiş veya son teslimat için bir mesajı kabul ettiğinde, posta verilerinin üstüne bir izleme kaydı (aynı zamanda "zaman damgası satırı" veya "Alınan" satırı olarak da değiştirilerek anılır) ekler. Bu izleme kaydı, mesajı gönderen ana bilgisayarın kimliğini, mesajı alan (ve bu zaman damgasını ekleyen) ana bilgisayarın kimliğini ve mesajın alındığı tarih ve saati gösterir. İletilen mesajların birden çok zaman damgası satırı olacaktır.
  7. ^ Scott Kitterman (Nisan 2014). E-postada Etki Alanlarının Kullanımına Yetki Vermek için Gönderen Politikası Çerçevesi (SPF), Sürüm 1. IETF. doi:10.17487 / RFC7208. RFC 7208. Alındı 26 Nisan 2014. Arabulucularla istenmeyen SPF arızalarını iyileştirmek için tekniklerin kullanılabileceği üç yer vardır.
  8. ^ J. Klensin (Ekim 2008). "Alias". Basit Posta Aktarım Protokolü. IETF. sn. 3.9.1. doi:10.17487 / RFC5321. RFC 5321. Alındı 15 Şubat 2013.
  9. ^ IP Adresi sahteciliği mümkündür, ancak genellikle tipik bir bilgisayar korsanı veya spam gönderen için çok riskli olan veya uygulamayan güvenli olmayan sunucular için çok riskli olan daha düşük düzeyde suç davranışı (içeri girme, telefon dinleme vb.) İçerir. RFC 1948, Ayrıca bakınız İletim Kontrol Protokolü # Bağlantı kaçırma.
  10. ^ Scott Kitterman (21 Kasım 2009). "SPF başarısız olduğunda engellemek / reddetmek ne kadar güvenilir?". spf-yardım. gossamer-threads.com. SRS dışı ileticilerin beyaz listeye alınması için bir mekanizma sunduğunuz sürece genel olarak sorun olmadığını düşünüyorum.
  11. ^ D. Crocker; T. Hansen; M. Kucherawy, eds. (Eylül 2011). DomainKeys Identified Mail (DKIM) İmzaları. IETF. doi:10.17487 / RFC6376. RFC 6376. Alındı 18 Şubat 2013. Etki Alanı Anahtarları Tarafından Tanımlanan Posta (DKIM), bir kişinin, rolün veya kuruluşun, bir etki alanı adını kullanma yetkisine sahip oldukları iletiyle ilişkilendirerek bir ileti için bazı sorumluluklar talep etmesine izin verir.
  12. ^ Dave Crocker (16 Ekim 2007). "DKIM Sık Sorulan Sorular". DKIM.org. Alındı 17 Şubat 2013.
  13. ^ E. Allman; J. Fenton; M. Delany; J. Levine (Ağustos 2009). DomainKeys Identified Mail (DKIM) Yazar Etki Alanı İmzalama Uygulamaları (ADSP). IETF. doi:10.17487 / RFC5616. RFC 5616. Alındı 18 Şubat 2013.
  14. ^ Barry Leiba (25 Kasım 2013). "ADSP'nin (RFC 5617) durumunu Geçmiş olarak değiştirin". IETF.
  15. ^ P. Hoffman; J. Levine; A. Hathcock (Nisan 2009). Referans Kefil. IETF. doi:10.17487 / RFC5518. RFC 5518. Alındı 18 Şubat 2013.
  16. ^ a b Murray Kucherawy (Ağustos 2015). Mesaj Kimlik Doğrulama Durumunu Göstermek için Mesaj Başlığı Alanı. IETF. doi:10.17487 / RFC7601. RFC 7601. Alındı 30 Eylül 2015.
  17. ^ H. Eidnes; G. de Groot; P. Vixie (Mart 1998). Sınıfsız IN-ADDR.ARPA delegasyonu. IETF. doi:10.17487 / RFC2317. RFC 2317. Alındı 18 Şubat 2013.