S/MIME: Czym jest, dlaczego powinienem się tym interesować i jak ma to się do SparkPost?
Ptak
19 gru 2018
1 min read
Najważniejsze informacje
Założenie: S/MIME (Bezpieczne/Wielofunkcyjne Rozszerzenia Internetowej Poczty) jest długoletnim standardem przesyłania podpisanych i zaszyfrowanych e-maili—kluczowym dla branż, które obsługują wrażliwe dane, takich jak finanse, opieka zdrowotna i administracja.
Cel: Wyjaśnij, co robi S/MIME, dlaczego to ważne, jak odróżnia się od DKIM/DMARC/TLS oraz jak integruje się z SparkPost.
Najważniejsze informacje:
Definicja: S/MIME umożliwia dwie podstawowe funkcje:
Szyfrowanie → Chroni treść wiadomości (prywatność).
Podpisywanie → Potwierdza tożsamość nadawcy, zapobiega manipulacjom i zapewnia niedopuszczalność zaprzeczenia.
Użycie w branży: Wymagane lub preferowane przez regulowane sektory, które potrzebują prywatności wiadomości od początku do końca oraz weryfikowalnej tożsamości.
Porównanie z innymi zabezpieczeniami e-mail:
TLS: Zabezpiecza transmisję pomiędzy serwerami (warstwa transportowa).
S/MIME: Zabezpiecza treść wiadomości (warstwa prezentacji).
DKIM/DMARC: Uwierzytelniają domeny, a nie osoby, i działają na poziomie administratora/serwera.
Mechanika:
Używa par kluczy publicznych/prywatnych oraz certyfikatów cyfrowych wydawanych na poszczególne tożsamości e-mail (np. alice@company.com).
Wymaga wspieranych klientów pocztowych (Apple Mail, Outlook, Thunderbird, iOS Mail, itd.).
Ograniczenia:
Klucze i certyfikaty mogą być skomplikowane do zarządzania.
Zaszyfrowane ładunki nie mogą być skanowane pod kątem złośliwego oprogramowania.
Nagłówki (Od, Do, Temat) pozostają widoczne.
Integracja z SparkPost:
Użytkownicy SparkPost mogą podpisywać wiadomości za pomocą S/MIME w celu zwiększenia autentyczności.
Aby umożliwić szyfrowane przesyłanie, odbiorcy muszą najpierw udostępnić swój klucz publiczny (np. wysyłając podpisaną wiadomość).
Partnerzy komercyjni, tacy jak Virtru i Echoworx, upraszczają to dla procesów przedsiębiorstw.
Kolejne kroki:
Część 2 serii demonstruje, jak podpisywać i szyfrować wiadomości przez SparkPost.
Późniejsze części pokazują ustawienia lokalne przy użyciu PowerMTA i Momentum.
Podsumowanie pytań i odpowiedzi
Dlaczego S/MIME jest ważne, jeśli już korzystam z TLS lub DKIM?
TLS chroni połączenie między serwerami, podczas gdy S/MIME chroni zawartość—zapewniając, że pozostaje prywatna i weryfikowalna nawet po dostarczeniu.
Kto najbardziej potrzebuje S/MIME?
Regulowane branże (finanse, rząd, opieka zdrowotna) oraz każda organizacja, która wysyła poufne, prawnie wiążące lub wrażliwe na tożsamość wiadomości e-mail.
Jakie problemy rozwiązuje S/MIME?
Zapobiega przechwytywaniu i podszywaniu się, gwarantuje autentyczność nadawcy oraz dostarcza dowodu, że wiadomość nie została zmieniona.
Czy SparkPost natywnie obsługuje S/MIME?
SparkPost obsługuje wysyłanie wiadomości sformatowanych S/MIME; wystarczy, że podpiszesz/encryptujesz swoją treść przed przesłaniem za pomocą API lub SMTP.
Jak mogę zdobyć certyfikaty?
Certyfikaty mogą być wydawane przez dostawców takich jak Comodo (bezpłatnie do użytku niekomercyjnego) lub samopodpisane do testów wewnętrznych.
Co jeśli mój odbiorca nie potrafi czytać zaszyfrowanych e-maili?
Wciąż zobaczą podpisany nagłówek wiadomości, ale aby odszyfrować, muszą zainstalować kompatybilnego klienta i mieć zaimportowany klucz prywatny.
Jak odbywa się wymiana kluczy dla e-maili generowanych przez aplikację?
Odbiorcy mogą wysłać wiadomość e-mail do Twojej usługi z podpisaną wiadomością; ich klucz publiczny może być następnie automatycznie wyodrębniony za pomocą webhooków przekazujących przychodzące wiadomości.
S/MIME to długo ustalona metoda wysyłania szyfrowanych, podpisanych wiadomości e-mail, oparta na standardach publicznych Internetu. Regularnie spotykamy się z wymaganiami dotyczącymi S/MIME, szczególnie z regulowanych branż, takich jak bankowość, zdrowie i finanse. S/MIME jest często wymagane podczas komunikacji między firmami a agencjami rządowymi, na przykład.
Kolejny standard bezpiecznej poczty, PGP (zabawnie nazwaną „Bardzo Dobrą Prywatnością”), jest używany głównie do bezpiecznej komunikacji osobistej. Obecnie jest mniej popularny, ponieważ wersje konsumenckie popularnych klientów poczty e-mail opartych na sieci, takich jak Gmail i Outlook/Hotmail, nie mogą wyświetlać szyfrowanej poczty. To jeden z powodów, dla których wiele osobistych komunikacji wymagających prywatności przeniosło się na platformy takie jak WhatsApp (i wiele innych), które oferują natywne, end-to-end szyfrowanie.
Zarówno PGP, jak i S/MIME wymagają klienta poczty, który potrafi korzystać z kluczy i certyfikatów. Wiele klientów na komputery stacjonarne i urządzenia mobilne, w tym Apple Mail, Microsoft Outlook i Mozilla Thunderbird, sprawdza się, podobnie jak wersje biznesowe niektórych klientów internetowych, takich jak Microsoft Office 365. Ustawienie kluczy wymaga pracy, ale wiele organizacji wciąż uważa to za warte zachodu, mimo niedawnych ujawnień luk, które wymagają remediów w celu zablokowania ładowania zdalnej zawartości.
S/MIME istnieje od 1995 roku i przeszedł przez kilka rewizji; obecna wersja jest objęta RFC 5751. Wymaga wymiany kluczy publicznych, co jest zadaniem niebanalnym, które często wymaga wsparcia zespołu IT lub podobnego zasobu. Dla organizacji działających na lokalnej infrastrukturze poczty e-mail, wdrożenie S/MIME wymaga dodatkowych rozważań dla platform takich jak PowerMTA i Momentum, które omawiamy w naszym przewodniku po S/MIME dla lokalnej bezpiecznej poczty e-mail. Niemniej jednak istnieją zautomatyzowane podejścia, aby uprościć ten proces, takie jak zbieranie publicznych kluczy odbiorców przez systemy oparte na e-mailu, co może uprościć zarządzanie kluczami dla generowanych przez aplikacje strumieni e-mailowych. Tutaj wchodzą komercyjne rozwiązania z firm takich jak partnerzy SparkPost Virtru i Echoworkx, które ułatwiają bezpieczeństwo w biznesowej poczcie osobistej (zobacz nasz jak-to SparkPost/Echoworkx po więcej informacji).
To powiedziawszy, zanurzmy się nieco głębiej w zwykłego S/MIME i zobaczmy, co możemy z tym zrobić.
S/MIME to długo ustalona metoda wysyłania szyfrowanych, podpisanych wiadomości e-mail, oparta na standardach publicznych Internetu. Regularnie spotykamy się z wymaganiami dotyczącymi S/MIME, szczególnie z regulowanych branż, takich jak bankowość, zdrowie i finanse. S/MIME jest często wymagane podczas komunikacji między firmami a agencjami rządowymi, na przykład.
Kolejny standard bezpiecznej poczty, PGP (zabawnie nazwaną „Bardzo Dobrą Prywatnością”), jest używany głównie do bezpiecznej komunikacji osobistej. Obecnie jest mniej popularny, ponieważ wersje konsumenckie popularnych klientów poczty e-mail opartych na sieci, takich jak Gmail i Outlook/Hotmail, nie mogą wyświetlać szyfrowanej poczty. To jeden z powodów, dla których wiele osobistych komunikacji wymagających prywatności przeniosło się na platformy takie jak WhatsApp (i wiele innych), które oferują natywne, end-to-end szyfrowanie.
Zarówno PGP, jak i S/MIME wymagają klienta poczty, który potrafi korzystać z kluczy i certyfikatów. Wiele klientów na komputery stacjonarne i urządzenia mobilne, w tym Apple Mail, Microsoft Outlook i Mozilla Thunderbird, sprawdza się, podobnie jak wersje biznesowe niektórych klientów internetowych, takich jak Microsoft Office 365. Ustawienie kluczy wymaga pracy, ale wiele organizacji wciąż uważa to za warte zachodu, mimo niedawnych ujawnień luk, które wymagają remediów w celu zablokowania ładowania zdalnej zawartości.
S/MIME istnieje od 1995 roku i przeszedł przez kilka rewizji; obecna wersja jest objęta RFC 5751. Wymaga wymiany kluczy publicznych, co jest zadaniem niebanalnym, które często wymaga wsparcia zespołu IT lub podobnego zasobu. Dla organizacji działających na lokalnej infrastrukturze poczty e-mail, wdrożenie S/MIME wymaga dodatkowych rozważań dla platform takich jak PowerMTA i Momentum, które omawiamy w naszym przewodniku po S/MIME dla lokalnej bezpiecznej poczty e-mail. Niemniej jednak istnieją zautomatyzowane podejścia, aby uprościć ten proces, takie jak zbieranie publicznych kluczy odbiorców przez systemy oparte na e-mailu, co może uprościć zarządzanie kluczami dla generowanych przez aplikacje strumieni e-mailowych. Tutaj wchodzą komercyjne rozwiązania z firm takich jak partnerzy SparkPost Virtru i Echoworkx, które ułatwiają bezpieczeństwo w biznesowej poczcie osobistej (zobacz nasz jak-to SparkPost/Echoworkx po więcej informacji).
To powiedziawszy, zanurzmy się nieco głębiej w zwykłego S/MIME i zobaczmy, co możemy z tym zrobić.
S/MIME to długo ustalona metoda wysyłania szyfrowanych, podpisanych wiadomości e-mail, oparta na standardach publicznych Internetu. Regularnie spotykamy się z wymaganiami dotyczącymi S/MIME, szczególnie z regulowanych branż, takich jak bankowość, zdrowie i finanse. S/MIME jest często wymagane podczas komunikacji między firmami a agencjami rządowymi, na przykład.
Kolejny standard bezpiecznej poczty, PGP (zabawnie nazwaną „Bardzo Dobrą Prywatnością”), jest używany głównie do bezpiecznej komunikacji osobistej. Obecnie jest mniej popularny, ponieważ wersje konsumenckie popularnych klientów poczty e-mail opartych na sieci, takich jak Gmail i Outlook/Hotmail, nie mogą wyświetlać szyfrowanej poczty. To jeden z powodów, dla których wiele osobistych komunikacji wymagających prywatności przeniosło się na platformy takie jak WhatsApp (i wiele innych), które oferują natywne, end-to-end szyfrowanie.
Zarówno PGP, jak i S/MIME wymagają klienta poczty, który potrafi korzystać z kluczy i certyfikatów. Wiele klientów na komputery stacjonarne i urządzenia mobilne, w tym Apple Mail, Microsoft Outlook i Mozilla Thunderbird, sprawdza się, podobnie jak wersje biznesowe niektórych klientów internetowych, takich jak Microsoft Office 365. Ustawienie kluczy wymaga pracy, ale wiele organizacji wciąż uważa to za warte zachodu, mimo niedawnych ujawnień luk, które wymagają remediów w celu zablokowania ładowania zdalnej zawartości.
S/MIME istnieje od 1995 roku i przeszedł przez kilka rewizji; obecna wersja jest objęta RFC 5751. Wymaga wymiany kluczy publicznych, co jest zadaniem niebanalnym, które często wymaga wsparcia zespołu IT lub podobnego zasobu. Dla organizacji działających na lokalnej infrastrukturze poczty e-mail, wdrożenie S/MIME wymaga dodatkowych rozważań dla platform takich jak PowerMTA i Momentum, które omawiamy w naszym przewodniku po S/MIME dla lokalnej bezpiecznej poczty e-mail. Niemniej jednak istnieją zautomatyzowane podejścia, aby uprościć ten proces, takie jak zbieranie publicznych kluczy odbiorców przez systemy oparte na e-mailu, co może uprościć zarządzanie kluczami dla generowanych przez aplikacje strumieni e-mailowych. Tutaj wchodzą komercyjne rozwiązania z firm takich jak partnerzy SparkPost Virtru i Echoworkx, które ułatwiają bezpieczeństwo w biznesowej poczcie osobistej (zobacz nasz jak-to SparkPost/Echoworkx po więcej informacji).
To powiedziawszy, zanurzmy się nieco głębiej w zwykłego S/MIME i zobaczmy, co możemy z tym zrobić.
Dlaczego powinienem się tym przejmować?
Krótka wersja:
Szyfrowanie zapewnia prywatność wiadomości.
Podpisanie zapewnia uwierzytelnienie (nadawcy), niemożność zaprzeczenia pochodzeniu oraz kontrole integralności wiadomości.
S/MIME działa inaczej niż DKIM i DMARC i może współistnieć z nimi.
Prywatność
Jeśli twoje wiadomości nie zawierają nic osobistego, prywatnego lub prawnie ważnego, to prawdopodobnie nie będziesz musiał myśleć o S/MIME. Nowoczesne systemy dostarczania e-maili, takie jak SparkPost, już używają „opportunistic TLS”, aby zabezpieczyć transport wiadomości od serwera nadawczego do serwera odbiorcy.
„Opportunistic” oznacza jednak, że jeśli serwer nadawczy nie może negocjować bezpiecznego połączenia, wyślemy wiadomość w czystym tekście. To nie nadaje się, jeśli chcesz wymusić, aby wiadomość była bezpieczna przez cały czas. Możesz zajrzeć do które usługi poczty twierdzą, że wspierają TLS i które w rzeczywistości to robią. Zakładając, że serwer odbiorcy rzeczywiście wspiera TLS, twoja wiadomość jest zabezpieczona w ten sposób:
TLS zabezpiecza rozmowy między serwerami pocztowymi (dlatego nazywa się to bezpieczeństwem warstwy transportowej). MIME (w tym S/MIME) zajmuje się treścią wiadomości i jej przetwarzaniem i można go uważać za część „warstwy prezentacji”.
S/MIME zabezpiecza treść wiadomości przez cały czas („od końca do końca”) od miejsca pochodzenia wiadomości do klienta pocztowego odbiorcy, kapsułkując treść wiadomości.
S/MIME szyfruje treść wiadomości kluczem publicznym odbiorcy. Treść nie może być odszyfrowana bez klucza prywatnego odbiorcy – nie przez żadną „osobę pośredniczącą”, taką jak twój dostawca usług internetowych, SparkPost lub serwer pocztowy odbiorcy.
Klucz prywatny nigdy nie jest ujawniany; jest przechowywany w wyłącznym posiadaniu odbiorcy. Zaszyfrowana wiadomość przemieszcza się przez Internet do odbierającego serwera pocztowego. Gdy ląduje w skrzynce odbiorczej odbiorcy, jest (zwykle automatycznie) odszyfrowana ich kluczem prywatnym i staje się czytelna.
Kilka pułapek S/MIME, o których warto wiedzieć:
S/MIME szyfrowanie ma skutki uboczne zapobiegające skanowaniu wiadomości przychodzących na serwerze w poszukiwaniu złośliwego oprogramowania, ponieważ ładunek wiadomości jest w postaci zaszyfrowanej i dlatego nie da się go zidentyfikować.
Zauważ, że nagłówki wiadomości (Od:, Do:, Temat: itd.) nie są szyfrowane, więc treść linii tematu musi być tworzona z tym na uwadze.
Podpisywanie – uwierzytelnienie
S/MIME zapewnia również odbiorcy możliwość sprawdzenia, że tożsamość nadawcy wiadomości jest tym, kim mówi, że jest.
Email nadawcy ma dołączony certyfikat, który, podobnie jak certyfikat na bezpiecznej stronie internetowej, może być śledzony do organu wydającego. Aby uzyskać pełny opis procesu podpisywania, zobacz proces podpisywania S/MIME PDF.
Przyjmiemy podejście polegające na podpisaniu wiadomości najpierw, a następnie jej zaszyfrowaniu, więc proces wygląda tak.
Niemożność zaprzeczenia
Kolejną przydatną zaletą podpisywania dla odbiorcy jest niemożność zaprzeczenia pochodzeniu. Rozważ sytuację, w której wiadomość e-mail jest używana do zatwierdzenia umowy. Odbiorca otrzymuje umowę w wiadomości od nadawcy. Jeśli nadawca później próbuje powiedzieć: „Nie, nigdy nie wysłałem ci tej wiadomości”, to otrzymana wiadomość pokazuje, że certyfikat nadawcy został w rzeczywistości użyty.
Integralność wiadomości
Proces podpisywania tworzy odcisk palca zwykłej wiadomości źródłowej (znanej jako skrót wiadomości), szyfruje skrót przy użyciu klucza prywatnego nadawcy i dołącza go do dostarczonej wiadomości. Klient pocztowy odbiorcy może stwierdzić, czy treść wiadomości została zmieniona.
Możesz powiedzieć: „Myślałem, że DKIM zapewnia kontrole integralności wiadomości!” Tak, DKIM zapewnia kontrole integralności treści wiadomości i nagłówków wiadomości - gwarancje antytampering. Jednak niepowodzenie DKIM (lub jego brak) zazwyczaj nie spowoduje oznaczenia przychodzącej wiadomości jako całkowicie nieważnej ... chyba że polityka DMARC o p=reject jest w mocy (zobacz nasz post na blogu DMARC: Jak chronić swoją reputację e-mailową). DKIM jest jednym z wielu czynników używanych przez dostawcę usług internetowych do niezawodnego przypisywania reputacji do domeny i jest oczywiście istotną częścią twojego stosu komunikacyjnego.
Twój klient pocztowy wyraźnie pokaże ci, jeśli wiadomość S/MIME niespełnia wymagań weryfikacji podpisu:
Podsumowanie: od końca do końca (S/MIME) vs serwera do serwera (DKIM, DMARC, TLS)
S/MIME to funkcjonalność warstwy prezentacji, która może działać między dwoma użytkownikami e-mail (z ważnymi certyfikatami/kluczami) bez żadnej akcji ze strony administratora e-mail. S/MIME zapewnia szyfrowanie i podpisywanie i jest osobiste dla każdego użytkownika.
S/MIME jest związane z pełnym adresem wysyłania (część lokalna i część domeny), zatem na przykład alice@bigcorp.com i bob@bigcorp.com muszą mieć różne certyfikaty. W przeciwieństwie do tego, DKIM weryfikuje, że e-mail pochodzi z podpisanej domeny. DKIM to całkiem osobny temat; ten artykuł jest dobrym miejscem na początek.
DKIM i DMARC są konfigurowane przez twojego administratora poczty (pracującego na serwerze pocztowym i rekordach DNS). Po skonfigurowaniu są aktywne dla domen, a nie dla poszczególnych użytkowników.
Krótka wersja:
Szyfrowanie zapewnia prywatność wiadomości.
Podpisanie zapewnia uwierzytelnienie (nadawcy), niemożność zaprzeczenia pochodzeniu oraz kontrole integralności wiadomości.
S/MIME działa inaczej niż DKIM i DMARC i może współistnieć z nimi.
Prywatność
Jeśli twoje wiadomości nie zawierają nic osobistego, prywatnego lub prawnie ważnego, to prawdopodobnie nie będziesz musiał myśleć o S/MIME. Nowoczesne systemy dostarczania e-maili, takie jak SparkPost, już używają „opportunistic TLS”, aby zabezpieczyć transport wiadomości od serwera nadawczego do serwera odbiorcy.
„Opportunistic” oznacza jednak, że jeśli serwer nadawczy nie może negocjować bezpiecznego połączenia, wyślemy wiadomość w czystym tekście. To nie nadaje się, jeśli chcesz wymusić, aby wiadomość była bezpieczna przez cały czas. Możesz zajrzeć do które usługi poczty twierdzą, że wspierają TLS i które w rzeczywistości to robią. Zakładając, że serwer odbiorcy rzeczywiście wspiera TLS, twoja wiadomość jest zabezpieczona w ten sposób:
TLS zabezpiecza rozmowy między serwerami pocztowymi (dlatego nazywa się to bezpieczeństwem warstwy transportowej). MIME (w tym S/MIME) zajmuje się treścią wiadomości i jej przetwarzaniem i można go uważać za część „warstwy prezentacji”.
S/MIME zabezpiecza treść wiadomości przez cały czas („od końca do końca”) od miejsca pochodzenia wiadomości do klienta pocztowego odbiorcy, kapsułkując treść wiadomości.
S/MIME szyfruje treść wiadomości kluczem publicznym odbiorcy. Treść nie może być odszyfrowana bez klucza prywatnego odbiorcy – nie przez żadną „osobę pośredniczącą”, taką jak twój dostawca usług internetowych, SparkPost lub serwer pocztowy odbiorcy.
Klucz prywatny nigdy nie jest ujawniany; jest przechowywany w wyłącznym posiadaniu odbiorcy. Zaszyfrowana wiadomość przemieszcza się przez Internet do odbierającego serwera pocztowego. Gdy ląduje w skrzynce odbiorczej odbiorcy, jest (zwykle automatycznie) odszyfrowana ich kluczem prywatnym i staje się czytelna.
Kilka pułapek S/MIME, o których warto wiedzieć:
S/MIME szyfrowanie ma skutki uboczne zapobiegające skanowaniu wiadomości przychodzących na serwerze w poszukiwaniu złośliwego oprogramowania, ponieważ ładunek wiadomości jest w postaci zaszyfrowanej i dlatego nie da się go zidentyfikować.
Zauważ, że nagłówki wiadomości (Od:, Do:, Temat: itd.) nie są szyfrowane, więc treść linii tematu musi być tworzona z tym na uwadze.
Podpisywanie – uwierzytelnienie
S/MIME zapewnia również odbiorcy możliwość sprawdzenia, że tożsamość nadawcy wiadomości jest tym, kim mówi, że jest.
Email nadawcy ma dołączony certyfikat, który, podobnie jak certyfikat na bezpiecznej stronie internetowej, może być śledzony do organu wydającego. Aby uzyskać pełny opis procesu podpisywania, zobacz proces podpisywania S/MIME PDF.
Przyjmiemy podejście polegające na podpisaniu wiadomości najpierw, a następnie jej zaszyfrowaniu, więc proces wygląda tak.
Niemożność zaprzeczenia
Kolejną przydatną zaletą podpisywania dla odbiorcy jest niemożność zaprzeczenia pochodzeniu. Rozważ sytuację, w której wiadomość e-mail jest używana do zatwierdzenia umowy. Odbiorca otrzymuje umowę w wiadomości od nadawcy. Jeśli nadawca później próbuje powiedzieć: „Nie, nigdy nie wysłałem ci tej wiadomości”, to otrzymana wiadomość pokazuje, że certyfikat nadawcy został w rzeczywistości użyty.
Integralność wiadomości
Proces podpisywania tworzy odcisk palca zwykłej wiadomości źródłowej (znanej jako skrót wiadomości), szyfruje skrót przy użyciu klucza prywatnego nadawcy i dołącza go do dostarczonej wiadomości. Klient pocztowy odbiorcy może stwierdzić, czy treść wiadomości została zmieniona.
Możesz powiedzieć: „Myślałem, że DKIM zapewnia kontrole integralności wiadomości!” Tak, DKIM zapewnia kontrole integralności treści wiadomości i nagłówków wiadomości - gwarancje antytampering. Jednak niepowodzenie DKIM (lub jego brak) zazwyczaj nie spowoduje oznaczenia przychodzącej wiadomości jako całkowicie nieważnej ... chyba że polityka DMARC o p=reject jest w mocy (zobacz nasz post na blogu DMARC: Jak chronić swoją reputację e-mailową). DKIM jest jednym z wielu czynników używanych przez dostawcę usług internetowych do niezawodnego przypisywania reputacji do domeny i jest oczywiście istotną częścią twojego stosu komunikacyjnego.
Twój klient pocztowy wyraźnie pokaże ci, jeśli wiadomość S/MIME niespełnia wymagań weryfikacji podpisu:
Podsumowanie: od końca do końca (S/MIME) vs serwera do serwera (DKIM, DMARC, TLS)
S/MIME to funkcjonalność warstwy prezentacji, która może działać między dwoma użytkownikami e-mail (z ważnymi certyfikatami/kluczami) bez żadnej akcji ze strony administratora e-mail. S/MIME zapewnia szyfrowanie i podpisywanie i jest osobiste dla każdego użytkownika.
S/MIME jest związane z pełnym adresem wysyłania (część lokalna i część domeny), zatem na przykład alice@bigcorp.com i bob@bigcorp.com muszą mieć różne certyfikaty. W przeciwieństwie do tego, DKIM weryfikuje, że e-mail pochodzi z podpisanej domeny. DKIM to całkiem osobny temat; ten artykuł jest dobrym miejscem na początek.
DKIM i DMARC są konfigurowane przez twojego administratora poczty (pracującego na serwerze pocztowym i rekordach DNS). Po skonfigurowaniu są aktywne dla domen, a nie dla poszczególnych użytkowników.
Krótka wersja:
Szyfrowanie zapewnia prywatność wiadomości.
Podpisanie zapewnia uwierzytelnienie (nadawcy), niemożność zaprzeczenia pochodzeniu oraz kontrole integralności wiadomości.
S/MIME działa inaczej niż DKIM i DMARC i może współistnieć z nimi.
Prywatność
Jeśli twoje wiadomości nie zawierają nic osobistego, prywatnego lub prawnie ważnego, to prawdopodobnie nie będziesz musiał myśleć o S/MIME. Nowoczesne systemy dostarczania e-maili, takie jak SparkPost, już używają „opportunistic TLS”, aby zabezpieczyć transport wiadomości od serwera nadawczego do serwera odbiorcy.
„Opportunistic” oznacza jednak, że jeśli serwer nadawczy nie może negocjować bezpiecznego połączenia, wyślemy wiadomość w czystym tekście. To nie nadaje się, jeśli chcesz wymusić, aby wiadomość była bezpieczna przez cały czas. Możesz zajrzeć do które usługi poczty twierdzą, że wspierają TLS i które w rzeczywistości to robią. Zakładając, że serwer odbiorcy rzeczywiście wspiera TLS, twoja wiadomość jest zabezpieczona w ten sposób:
TLS zabezpiecza rozmowy między serwerami pocztowymi (dlatego nazywa się to bezpieczeństwem warstwy transportowej). MIME (w tym S/MIME) zajmuje się treścią wiadomości i jej przetwarzaniem i można go uważać za część „warstwy prezentacji”.
S/MIME zabezpiecza treść wiadomości przez cały czas („od końca do końca”) od miejsca pochodzenia wiadomości do klienta pocztowego odbiorcy, kapsułkując treść wiadomości.
S/MIME szyfruje treść wiadomości kluczem publicznym odbiorcy. Treść nie może być odszyfrowana bez klucza prywatnego odbiorcy – nie przez żadną „osobę pośredniczącą”, taką jak twój dostawca usług internetowych, SparkPost lub serwer pocztowy odbiorcy.
Klucz prywatny nigdy nie jest ujawniany; jest przechowywany w wyłącznym posiadaniu odbiorcy. Zaszyfrowana wiadomość przemieszcza się przez Internet do odbierającego serwera pocztowego. Gdy ląduje w skrzynce odbiorczej odbiorcy, jest (zwykle automatycznie) odszyfrowana ich kluczem prywatnym i staje się czytelna.
Kilka pułapek S/MIME, o których warto wiedzieć:
S/MIME szyfrowanie ma skutki uboczne zapobiegające skanowaniu wiadomości przychodzących na serwerze w poszukiwaniu złośliwego oprogramowania, ponieważ ładunek wiadomości jest w postaci zaszyfrowanej i dlatego nie da się go zidentyfikować.
Zauważ, że nagłówki wiadomości (Od:, Do:, Temat: itd.) nie są szyfrowane, więc treść linii tematu musi być tworzona z tym na uwadze.
Podpisywanie – uwierzytelnienie
S/MIME zapewnia również odbiorcy możliwość sprawdzenia, że tożsamość nadawcy wiadomości jest tym, kim mówi, że jest.
Email nadawcy ma dołączony certyfikat, który, podobnie jak certyfikat na bezpiecznej stronie internetowej, może być śledzony do organu wydającego. Aby uzyskać pełny opis procesu podpisywania, zobacz proces podpisywania S/MIME PDF.
Przyjmiemy podejście polegające na podpisaniu wiadomości najpierw, a następnie jej zaszyfrowaniu, więc proces wygląda tak.
Niemożność zaprzeczenia
Kolejną przydatną zaletą podpisywania dla odbiorcy jest niemożność zaprzeczenia pochodzeniu. Rozważ sytuację, w której wiadomość e-mail jest używana do zatwierdzenia umowy. Odbiorca otrzymuje umowę w wiadomości od nadawcy. Jeśli nadawca później próbuje powiedzieć: „Nie, nigdy nie wysłałem ci tej wiadomości”, to otrzymana wiadomość pokazuje, że certyfikat nadawcy został w rzeczywistości użyty.
Integralność wiadomości
Proces podpisywania tworzy odcisk palca zwykłej wiadomości źródłowej (znanej jako skrót wiadomości), szyfruje skrót przy użyciu klucza prywatnego nadawcy i dołącza go do dostarczonej wiadomości. Klient pocztowy odbiorcy może stwierdzić, czy treść wiadomości została zmieniona.
Możesz powiedzieć: „Myślałem, że DKIM zapewnia kontrole integralności wiadomości!” Tak, DKIM zapewnia kontrole integralności treści wiadomości i nagłówków wiadomości - gwarancje antytampering. Jednak niepowodzenie DKIM (lub jego brak) zazwyczaj nie spowoduje oznaczenia przychodzącej wiadomości jako całkowicie nieważnej ... chyba że polityka DMARC o p=reject jest w mocy (zobacz nasz post na blogu DMARC: Jak chronić swoją reputację e-mailową). DKIM jest jednym z wielu czynników używanych przez dostawcę usług internetowych do niezawodnego przypisywania reputacji do domeny i jest oczywiście istotną częścią twojego stosu komunikacyjnego.
Twój klient pocztowy wyraźnie pokaże ci, jeśli wiadomość S/MIME niespełnia wymagań weryfikacji podpisu:
Podsumowanie: od końca do końca (S/MIME) vs serwera do serwera (DKIM, DMARC, TLS)
S/MIME to funkcjonalność warstwy prezentacji, która może działać między dwoma użytkownikami e-mail (z ważnymi certyfikatami/kluczami) bez żadnej akcji ze strony administratora e-mail. S/MIME zapewnia szyfrowanie i podpisywanie i jest osobiste dla każdego użytkownika.
S/MIME jest związane z pełnym adresem wysyłania (część lokalna i część domeny), zatem na przykład alice@bigcorp.com i bob@bigcorp.com muszą mieć różne certyfikaty. W przeciwieństwie do tego, DKIM weryfikuje, że e-mail pochodzi z podpisanej domeny. DKIM to całkiem osobny temat; ten artykuł jest dobrym miejscem na początek.
DKIM i DMARC są konfigurowane przez twojego administratora poczty (pracującego na serwerze pocztowym i rekordach DNS). Po skonfigurowaniu są aktywne dla domen, a nie dla poszczególnych użytkowników.
Jak to się ma do SparkPost?
Systemy pocztowe do wiadomości osobistych, takie jak Microsoft Exchange Server, od dawna wspierają S/MIME.
Jeśli używasz SparkPost do wysyłania do konkretnych odbiorców z klientami pocztowymi, które potrafią odczytać S/MIME, to może to mieć sens, aby podpisać swoje wiadomości S/MIME. Podpisywanie S/MIME dodaje dodatkowe zapewnienie, że wiadomość faktycznie pochodzi od Ciebie (lub Twojego systemu) i nie została zmieniona, co może być cenne w niektórych przypadkach. Wszystko, czego potrzebujesz, to klucz oraz darmowe oprogramowanie, które zademonstrujemy w części 2 tego artykułu.
Używanie szyfrowania S/MIME to oddzielny wybór do podjęcia. Będziesz potrzebować klucza publicznego dla każdego z Twoich odbiorców. Uzyskanie go może być tak proste, jak poproszenie ich o wysłanie do Ciebie (lub Twojej aplikacji) podpisanego maila. Zbadamy praktyczne narzędzie do wysyłania podpisanych i zaszyfrowanych maili S/MIME za pośrednictwem SparkPost w kolejnym wpisie.
Systemy pocztowe do wiadomości osobistych, takie jak Microsoft Exchange Server, od dawna wspierają S/MIME.
Jeśli używasz SparkPost do wysyłania do konkretnych odbiorców z klientami pocztowymi, które potrafią odczytać S/MIME, to może to mieć sens, aby podpisać swoje wiadomości S/MIME. Podpisywanie S/MIME dodaje dodatkowe zapewnienie, że wiadomość faktycznie pochodzi od Ciebie (lub Twojego systemu) i nie została zmieniona, co może być cenne w niektórych przypadkach. Wszystko, czego potrzebujesz, to klucz oraz darmowe oprogramowanie, które zademonstrujemy w części 2 tego artykułu.
Używanie szyfrowania S/MIME to oddzielny wybór do podjęcia. Będziesz potrzebować klucza publicznego dla każdego z Twoich odbiorców. Uzyskanie go może być tak proste, jak poproszenie ich o wysłanie do Ciebie (lub Twojej aplikacji) podpisanego maila. Zbadamy praktyczne narzędzie do wysyłania podpisanych i zaszyfrowanych maili S/MIME za pośrednictwem SparkPost w kolejnym wpisie.
Systemy pocztowe do wiadomości osobistych, takie jak Microsoft Exchange Server, od dawna wspierają S/MIME.
Jeśli używasz SparkPost do wysyłania do konkretnych odbiorców z klientami pocztowymi, które potrafią odczytać S/MIME, to może to mieć sens, aby podpisać swoje wiadomości S/MIME. Podpisywanie S/MIME dodaje dodatkowe zapewnienie, że wiadomość faktycznie pochodzi od Ciebie (lub Twojego systemu) i nie została zmieniona, co może być cenne w niektórych przypadkach. Wszystko, czego potrzebujesz, to klucz oraz darmowe oprogramowanie, które zademonstrujemy w części 2 tego artykułu.
Używanie szyfrowania S/MIME to oddzielny wybór do podjęcia. Będziesz potrzebować klucza publicznego dla każdego z Twoich odbiorców. Uzyskanie go może być tak proste, jak poproszenie ich o wysłanie do Ciebie (lub Twojej aplikacji) podpisanego maila. Zbadamy praktyczne narzędzie do wysyłania podpisanych i zaszyfrowanych maili S/MIME za pośrednictwem SparkPost w kolejnym wpisie.
Które klienty obsługują S/MIME?
Konsumencki Gmail
Standardowy klient internetowy Gmail wyświetla podpisy przychodzącej poczty (patrz poniżej), ale nie jest skonfigurowany do przechowywania twojego klucza prywatnego do odczytu zaszyfrowanych wiadomości. Nawet jeśli byłoby to możliwe za pomocą wtyczek osób trzecich, przesyłanie swojego klucza prywatnego nie jest najlepszym pomysłem z punktu widzenia bezpieczeństwa.
Nie mogłem sprawić, by Yahoo! Mail w ogóle dekodował podpisy w wiadomościach.
Konsumencka wersja kont Microsoft Outlook/Hotmail informuje cię o obecności podpisu S/MIME, ale nie daje pełnego dostępu do wyświetlania lub sprawdzania certyfikatu.
Hostowany mail biznesowy
Dla organizacji z hostowaną pocztą, Microsoft Office 365 i G Suite Enterprise mają wsparcie S/MIME.
Klienci poczty Outlook
Klientowy Microsoft Outlook (np. 2010 dla Windows) działa:
Kliknięcie na ikony daje więcej informacji:
W programie Outlook 2010 / Windows, magazyn certyfikatów jest dostępny przez Plik / Opcje / Centrum zaufania / Ustawienia centrum zaufania / Bezpieczeństwo e-mail / Importuj / Eksportuj.
Thunderbird – wieloplatformowy i darmowy
Jeśli szukasz darmowego klienta, Mozilla Thunderbird spełnia wymagania. Jest dostępny na PC, Mac i Linux, i wspiera S/MIME na wszystkich z tych platform. Oto jak wygląda wiadomość na Macu. Ikona "zapieczętowanej koperty" wskazuje, że wiadomość jest podpisana, a kłódka oznacza, że została zaszyfrowana.
Klikając na kopertę/kłódkę wyświetlasz informacje o wiadomości:
Thunderbird ma własny magazyn kluczy, dostępny w podobny sposób na każdej platformie:
Mac przez Preferencje / Zaawansowane / Certyfikaty / Zarządzaj certyfikatami
PC: menu ("hamburger" w prawym górnym rogu), Zaawansowane / Certyfikaty / Zarządzaj certyfikatami
Linux: menu ("hamburger" w prawym górnym rogu), Preferencje / Zaawansowane / Zarządzaj certyfikatami
Poczta Mac
Poczta Mac także wspiera S/MIME. Polega na twoim schowku kluczy Mac do przechowywania twoich kluczy.
Poczta iOS
Po pierwsze, zaimportuj certyfikat swojego konta e-mail w ten sposób, a następnie będziesz mógł przeglądać podpisane i zaszyfrowane e-maile S/MIME. Na ekranie przeglądania nie wyglądają one wcale inaczej.
Android
Niektóre urządzenia i aplikacje wspierają S/MIME; jest wiele różnorodności w tej dziedzinie. Samsung ma przewodnik.
Konsumencki Gmail
Standardowy klient internetowy Gmail wyświetla podpisy przychodzącej poczty (patrz poniżej), ale nie jest skonfigurowany do przechowywania twojego klucza prywatnego do odczytu zaszyfrowanych wiadomości. Nawet jeśli byłoby to możliwe za pomocą wtyczek osób trzecich, przesyłanie swojego klucza prywatnego nie jest najlepszym pomysłem z punktu widzenia bezpieczeństwa.
Nie mogłem sprawić, by Yahoo! Mail w ogóle dekodował podpisy w wiadomościach.
Konsumencka wersja kont Microsoft Outlook/Hotmail informuje cię o obecności podpisu S/MIME, ale nie daje pełnego dostępu do wyświetlania lub sprawdzania certyfikatu.
Hostowany mail biznesowy
Dla organizacji z hostowaną pocztą, Microsoft Office 365 i G Suite Enterprise mają wsparcie S/MIME.
Klienci poczty Outlook
Klientowy Microsoft Outlook (np. 2010 dla Windows) działa:
Kliknięcie na ikony daje więcej informacji:
W programie Outlook 2010 / Windows, magazyn certyfikatów jest dostępny przez Plik / Opcje / Centrum zaufania / Ustawienia centrum zaufania / Bezpieczeństwo e-mail / Importuj / Eksportuj.
Thunderbird – wieloplatformowy i darmowy
Jeśli szukasz darmowego klienta, Mozilla Thunderbird spełnia wymagania. Jest dostępny na PC, Mac i Linux, i wspiera S/MIME na wszystkich z tych platform. Oto jak wygląda wiadomość na Macu. Ikona "zapieczętowanej koperty" wskazuje, że wiadomość jest podpisana, a kłódka oznacza, że została zaszyfrowana.
Klikając na kopertę/kłódkę wyświetlasz informacje o wiadomości:
Thunderbird ma własny magazyn kluczy, dostępny w podobny sposób na każdej platformie:
Mac przez Preferencje / Zaawansowane / Certyfikaty / Zarządzaj certyfikatami
PC: menu ("hamburger" w prawym górnym rogu), Zaawansowane / Certyfikaty / Zarządzaj certyfikatami
Linux: menu ("hamburger" w prawym górnym rogu), Preferencje / Zaawansowane / Zarządzaj certyfikatami
Poczta Mac
Poczta Mac także wspiera S/MIME. Polega na twoim schowku kluczy Mac do przechowywania twoich kluczy.
Poczta iOS
Po pierwsze, zaimportuj certyfikat swojego konta e-mail w ten sposób, a następnie będziesz mógł przeglądać podpisane i zaszyfrowane e-maile S/MIME. Na ekranie przeglądania nie wyglądają one wcale inaczej.
Android
Niektóre urządzenia i aplikacje wspierają S/MIME; jest wiele różnorodności w tej dziedzinie. Samsung ma przewodnik.
Konsumencki Gmail
Standardowy klient internetowy Gmail wyświetla podpisy przychodzącej poczty (patrz poniżej), ale nie jest skonfigurowany do przechowywania twojego klucza prywatnego do odczytu zaszyfrowanych wiadomości. Nawet jeśli byłoby to możliwe za pomocą wtyczek osób trzecich, przesyłanie swojego klucza prywatnego nie jest najlepszym pomysłem z punktu widzenia bezpieczeństwa.
Nie mogłem sprawić, by Yahoo! Mail w ogóle dekodował podpisy w wiadomościach.
Konsumencka wersja kont Microsoft Outlook/Hotmail informuje cię o obecności podpisu S/MIME, ale nie daje pełnego dostępu do wyświetlania lub sprawdzania certyfikatu.
Hostowany mail biznesowy
Dla organizacji z hostowaną pocztą, Microsoft Office 365 i G Suite Enterprise mają wsparcie S/MIME.
Klienci poczty Outlook
Klientowy Microsoft Outlook (np. 2010 dla Windows) działa:
Kliknięcie na ikony daje więcej informacji:
W programie Outlook 2010 / Windows, magazyn certyfikatów jest dostępny przez Plik / Opcje / Centrum zaufania / Ustawienia centrum zaufania / Bezpieczeństwo e-mail / Importuj / Eksportuj.
Thunderbird – wieloplatformowy i darmowy
Jeśli szukasz darmowego klienta, Mozilla Thunderbird spełnia wymagania. Jest dostępny na PC, Mac i Linux, i wspiera S/MIME na wszystkich z tych platform. Oto jak wygląda wiadomość na Macu. Ikona "zapieczętowanej koperty" wskazuje, że wiadomość jest podpisana, a kłódka oznacza, że została zaszyfrowana.
Klikając na kopertę/kłódkę wyświetlasz informacje o wiadomości:
Thunderbird ma własny magazyn kluczy, dostępny w podobny sposób na każdej platformie:
Mac przez Preferencje / Zaawansowane / Certyfikaty / Zarządzaj certyfikatami
PC: menu ("hamburger" w prawym górnym rogu), Zaawansowane / Certyfikaty / Zarządzaj certyfikatami
Linux: menu ("hamburger" w prawym górnym rogu), Preferencje / Zaawansowane / Zarządzaj certyfikatami
Poczta Mac
Poczta Mac także wspiera S/MIME. Polega na twoim schowku kluczy Mac do przechowywania twoich kluczy.
Poczta iOS
Po pierwsze, zaimportuj certyfikat swojego konta e-mail w ten sposób, a następnie będziesz mógł przeglądać podpisane i zaszyfrowane e-maile S/MIME. Na ekranie przeglądania nie wyglądają one wcale inaczej.
Android
Niektóre urządzenia i aplikacje wspierają S/MIME; jest wiele różnorodności w tej dziedzinie. Samsung ma przewodnik.
W końcu…
To nasze szybkie omówienie praktycznych zastosowań S/MIME. Jeśli chcesz uzyskać własne certyfikaty poczty, lista dostawców znajduje się tutaj. Znalazłem, że Comodo działa dobrze (darmowe do użytku niekomercyjnego – otwórz to w Firefoxie, nie w Chrome).
W części 2 omówimy, jak zastosować podpisywanie i szyfrowanie S/MIME do wiadomości, które wysyłasz za pośrednictwem SparkPost.
Dalsza lektura
Microsoft ma dobry artykuł wprowadzający na temat S/MIME w swojej dokumentacji.
Aby uzyskać więcej informacji o podatności EFAIL i o tym, jak została rozwiązana, zobacz oficjalną stronę EFAIL. Inne łatwe do zrozumienia wyjaśnienia są dostępne na stronie wiki EFAIL oraz w poście na blogu CipherMail EFAIL: Kto jest podatny, PGP, S/MIME, czy twój klient pocztowy?.
To nasze szybkie omówienie praktycznych zastosowań S/MIME. Jeśli chcesz uzyskać własne certyfikaty poczty, lista dostawców znajduje się tutaj. Znalazłem, że Comodo działa dobrze (darmowe do użytku niekomercyjnego – otwórz to w Firefoxie, nie w Chrome).
W części 2 omówimy, jak zastosować podpisywanie i szyfrowanie S/MIME do wiadomości, które wysyłasz za pośrednictwem SparkPost.
Dalsza lektura
Microsoft ma dobry artykuł wprowadzający na temat S/MIME w swojej dokumentacji.
Aby uzyskać więcej informacji o podatności EFAIL i o tym, jak została rozwiązana, zobacz oficjalną stronę EFAIL. Inne łatwe do zrozumienia wyjaśnienia są dostępne na stronie wiki EFAIL oraz w poście na blogu CipherMail EFAIL: Kto jest podatny, PGP, S/MIME, czy twój klient pocztowy?.
To nasze szybkie omówienie praktycznych zastosowań S/MIME. Jeśli chcesz uzyskać własne certyfikaty poczty, lista dostawców znajduje się tutaj. Znalazłem, że Comodo działa dobrze (darmowe do użytku niekomercyjnego – otwórz to w Firefoxie, nie w Chrome).
W części 2 omówimy, jak zastosować podpisywanie i szyfrowanie S/MIME do wiadomości, które wysyłasz za pośrednictwem SparkPost.
Dalsza lektura
Microsoft ma dobry artykuł wprowadzający na temat S/MIME w swojej dokumentacji.
Aby uzyskać więcej informacji o podatności EFAIL i o tym, jak została rozwiązana, zobacz oficjalną stronę EFAIL. Inne łatwe do zrozumienia wyjaśnienia są dostępne na stronie wiki EFAIL oraz w poście na blogu CipherMail EFAIL: Kto jest podatny, PGP, S/MIME, czy twój klient pocztowy?.
