S/MIME: Czym to jest, dlaczego powinienem się tym interesować i jak to się ma do SparkPost?
Ptak
19 gru 2018
1 min read
Kluczowe Wnioski
Premise: S/MIME (Secure/Multipurpose Internet Mail Extensions) jest długotrwałym standardem wysyłania podpisanych i zaszyfrowanych e-maili—krytycznym dla branż, które zajmują się danymi wrażliwymi, jak finanse, opieka zdrowotna i administracja.
Cel: Wyjaśnić, co robi S/MIME, dlaczego jest ważny, jak różni się od DKIM/DMARC/TLS i jak integruje się z SparkPost.
Najważniejsze punkty:
Definicja: S/MIME umożliwia dwie podstawowe funkcje:
Szyfrowanie → Chroni treść wiadomości (prywatność).
Podpisywanie → Potwierdza tożsamość nadawcy, zapobiega fałszowaniu i zapewnia niezaprzeczalność.
Użycie w przemyśle: Wymagane lub preferowane przez regulowane sektory, które potrzebują prywatności wiadomości end-to-end i weryfikowalnej tożsamości.
Porównanie z innymi zabezpieczeniami e-mail:
TLS: Zabezpiecza przesyłanie pomiędzy serwerami (warstwa transportowa).
S/MIME: Zabezpiecza samą treść wiadomości (warstwa prezentacji).
DKIM/DMARC: Uwierzytelniają domeny, nie osoby, i działają na poziomie admin/serwer.
Mechanika:
Używa par kluczy publiczny/prywatny i certyfikatów cyfrowych wydawanych na podstawie tożsamości e-mail (np. alice@company.com).
Wymaga obsługiwanych klientów poczty (Apple Mail, Outlook, Thunderbird, iOS Mail itp.).
Ograniczenia:
Zarządzanie kluczami i certyfikatami może być skomplikowane.
Zaszyfrowane ładunki nie mogą być skanowane pod kątem złośliwego oprogramowania.
Nagłówki (From, To, Subject) pozostają widoczne.
Integracja z SparkPost:
Użytkownicy SparkPost mogą podpisywać wiadomości przy pomocy S/MIME dla zwiększonej autentyczności.
Do zaszyfrowanego wysyłania 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 przedsiębiorstw.
Kolejne kroki:
Część 2 serii demonstruje, jak podpisywać i szyfrować wiadomości przez SparkPost.
Kolejne części pokażą ustawienia na miejscu przy użyciu PowerMTA i Momentum.
Q&A Highlights
Dlaczego S/MIME jest ważne, jeśli już używam TLS lub DKIM?
TLS chroni połączenie między serwerami, podczas gdy S/MIME chroni samą zawartość — zapewniając jej prywatność i możliwość weryfikacji nawet po dostarczeniu.
Kto najbardziej potrzebuje S/MIME?
Regulowane branże (finanse, rząd, opieka zdrowotna) i każda organizacja, która wysyła poufne, prawnie wiążące lub tożsamość-wrażliwe e-maile.
Jakie problemy rozwiązuje S/MIME?
Zapobiega przechwytywaniu i podszywaniu się, gwarantuje autentyczność nadawcy oraz zapewnia dowód, że wiadomość nie została zmieniona.
Czy SparkPost natywnie obsługuje S/MIME?
SparkPost obsługuje wysyłanie wiadomości w formacie S/MIME; wystarczy podpisać/zaszyfrować swoją treść przed przesłaniem przez API lub SMTP.
Jak uzyskać certyfikaty?
Certyfikaty mogą być wydawane przez dostawców takich jak Comodo (darmowe do użytku niekomercyjnego) lub podpisane własnoręcznie do wewnętrznych testów.
Co jeśli mój odbiorca nie może odczytać zaszyfrowanych wiadomości e-mail?
Nadal będą widzieć nagłówek podpisanej wiadomości, ale aby ją odszyfrować, muszą zainstalować kompatybilnego klienta i zaimportować swój klucz prywatny.
Jak obsługiwane jest wymienianie kluczy dla wiadomości e-mail generowanych przez aplikację?
Odbiorcy mogą wysyłać e-maile do Twojej usługi z podpisaną wiadomością; ich klucz publiczny może być następnie automatycznie wyodrębniany za pomocą przychodzących webhooków przekaźnikowych.
S/MIME to długo ustanowiona metoda wysyłania zaszyfrowanych, podpisanych emaili, oparta na publicznych standardach internetowych. Regularnie spotykamy wymagania dotyczące S/MIME, szczególnie od branż regulowanych, takich jak bankowość, zdrowie i finanse. S/MIME jest często wymagane przy komunikacji pomiędzy firmami a agencjami rządowymi, na przykład.
Inny standard bezpiecznej poczty, PGP (zabawnie nazwany jako „Pretty Good Privacy”), jest bardziej używany do bezpiecznej komunikacji między osobami. Jest obecnie mniej popularny, ponieważ wersje konsumenckie popularnych klientów poczty internetowej, takich jak Gmail i Outlook/Hotmail, nie są w stanie wyświetlać zaszyfrowanej poczty. To jeden z powodów, dla którego wiele komunikacji osoba-do-osoby, która wymaga prywatności, przeniosło się na platformy takie jak WhatsApp (i wiele innych), które oferują wbudowane szyfrowanie end-to-end.
Zarówno PGP, jak i S/MIME wymagają klienta poczty, który może korzystać z kluczy i certyfikatów. Wiele klientów na komputerach stacjonarnych i urządzeniach mobilnych, w tym Apple Mail, Microsoft Outlook i Mozilla Thunderbird, spełnia te wymagania, podobnie jak wersje biznesowe niektórych klientów internetowych, takich jak Microsoft Office 365. Konfiguracja kluczy wymaga pracy, ale wiele organizacji nadal uważa to za wartościowe, pomimo niedawnych wykryć luk bezpieczeństwa, które wymagają działań naprawczych w celu zablokowania ładowania zdalnej zawartości.
S/MIME istnieje od 1995 roku i przeszło kilka poprawek; obecna wersja jest objęta RFC 5751. Wymaga wymiany kluczy publicznych, zadanie niezbyt proste, które często wymaga wsparcia zespołu IT lub podobnego zasobu. Dla organizacji korzystających z infrastruktury poczty e-mail na miejscu, wdrożenie S/MIME wymaga dodatkowych rozważań dla platform takich jak PowerMTA i Momentum, które omawiamy w naszym przewodniku S/MIME dla bezpiecznej poczty e-mail na miejscu. Istnieją jednak zautomatyzowane podejścia do usprawnienia tego procesu, takie jak zbieranie kluczy publicznych odbiorców przez systemy oparte na emailach, które mogą uprościć zarządzanie kluczami dla strumieni wiadomości generowanych przez aplikacje. W tym miejscu pojawiają się komercyjne rozwiązania firm takich jak partnerzy SparkPost, Virtru i Echoworkx, ułatwiając zabezpieczenie korespondencji biznesowej osoba-osoba (zobacz nasz SparkPost/Echoworkx how-to po więcej informacji).
To powiedziawszy, zgłębmy trochę tradycyjne S/MIME i zobaczmy, co możemy z niego zrobić.
S/MIME to długo ustanowiona metoda wysyłania zaszyfrowanych, podpisanych emaili, oparta na publicznych standardach internetowych. Regularnie spotykamy wymagania dotyczące S/MIME, szczególnie od branż regulowanych, takich jak bankowość, zdrowie i finanse. S/MIME jest często wymagane przy komunikacji pomiędzy firmami a agencjami rządowymi, na przykład.
Inny standard bezpiecznej poczty, PGP (zabawnie nazwany jako „Pretty Good Privacy”), jest bardziej używany do bezpiecznej komunikacji między osobami. Jest obecnie mniej popularny, ponieważ wersje konsumenckie popularnych klientów poczty internetowej, takich jak Gmail i Outlook/Hotmail, nie są w stanie wyświetlać zaszyfrowanej poczty. To jeden z powodów, dla którego wiele komunikacji osoba-do-osoby, która wymaga prywatności, przeniosło się na platformy takie jak WhatsApp (i wiele innych), które oferują wbudowane szyfrowanie end-to-end.
Zarówno PGP, jak i S/MIME wymagają klienta poczty, który może korzystać z kluczy i certyfikatów. Wiele klientów na komputerach stacjonarnych i urządzeniach mobilnych, w tym Apple Mail, Microsoft Outlook i Mozilla Thunderbird, spełnia te wymagania, podobnie jak wersje biznesowe niektórych klientów internetowych, takich jak Microsoft Office 365. Konfiguracja kluczy wymaga pracy, ale wiele organizacji nadal uważa to za wartościowe, pomimo niedawnych wykryć luk bezpieczeństwa, które wymagają działań naprawczych w celu zablokowania ładowania zdalnej zawartości.
S/MIME istnieje od 1995 roku i przeszło kilka poprawek; obecna wersja jest objęta RFC 5751. Wymaga wymiany kluczy publicznych, zadanie niezbyt proste, które często wymaga wsparcia zespołu IT lub podobnego zasobu. Dla organizacji korzystających z infrastruktury poczty e-mail na miejscu, wdrożenie S/MIME wymaga dodatkowych rozważań dla platform takich jak PowerMTA i Momentum, które omawiamy w naszym przewodniku S/MIME dla bezpiecznej poczty e-mail na miejscu. Istnieją jednak zautomatyzowane podejścia do usprawnienia tego procesu, takie jak zbieranie kluczy publicznych odbiorców przez systemy oparte na emailach, które mogą uprościć zarządzanie kluczami dla strumieni wiadomości generowanych przez aplikacje. W tym miejscu pojawiają się komercyjne rozwiązania firm takich jak partnerzy SparkPost, Virtru i Echoworkx, ułatwiając zabezpieczenie korespondencji biznesowej osoba-osoba (zobacz nasz SparkPost/Echoworkx how-to po więcej informacji).
To powiedziawszy, zgłębmy trochę tradycyjne S/MIME i zobaczmy, co możemy z niego zrobić.
S/MIME to długo ustanowiona metoda wysyłania zaszyfrowanych, podpisanych emaili, oparta na publicznych standardach internetowych. Regularnie spotykamy wymagania dotyczące S/MIME, szczególnie od branż regulowanych, takich jak bankowość, zdrowie i finanse. S/MIME jest często wymagane przy komunikacji pomiędzy firmami a agencjami rządowymi, na przykład.
Inny standard bezpiecznej poczty, PGP (zabawnie nazwany jako „Pretty Good Privacy”), jest bardziej używany do bezpiecznej komunikacji między osobami. Jest obecnie mniej popularny, ponieważ wersje konsumenckie popularnych klientów poczty internetowej, takich jak Gmail i Outlook/Hotmail, nie są w stanie wyświetlać zaszyfrowanej poczty. To jeden z powodów, dla którego wiele komunikacji osoba-do-osoby, która wymaga prywatności, przeniosło się na platformy takie jak WhatsApp (i wiele innych), które oferują wbudowane szyfrowanie end-to-end.
Zarówno PGP, jak i S/MIME wymagają klienta poczty, który może korzystać z kluczy i certyfikatów. Wiele klientów na komputerach stacjonarnych i urządzeniach mobilnych, w tym Apple Mail, Microsoft Outlook i Mozilla Thunderbird, spełnia te wymagania, podobnie jak wersje biznesowe niektórych klientów internetowych, takich jak Microsoft Office 365. Konfiguracja kluczy wymaga pracy, ale wiele organizacji nadal uważa to za wartościowe, pomimo niedawnych wykryć luk bezpieczeństwa, które wymagają działań naprawczych w celu zablokowania ładowania zdalnej zawartości.
S/MIME istnieje od 1995 roku i przeszło kilka poprawek; obecna wersja jest objęta RFC 5751. Wymaga wymiany kluczy publicznych, zadanie niezbyt proste, które często wymaga wsparcia zespołu IT lub podobnego zasobu. Dla organizacji korzystających z infrastruktury poczty e-mail na miejscu, wdrożenie S/MIME wymaga dodatkowych rozważań dla platform takich jak PowerMTA i Momentum, które omawiamy w naszym przewodniku S/MIME dla bezpiecznej poczty e-mail na miejscu. Istnieją jednak zautomatyzowane podejścia do usprawnienia tego procesu, takie jak zbieranie kluczy publicznych odbiorców przez systemy oparte na emailach, które mogą uprościć zarządzanie kluczami dla strumieni wiadomości generowanych przez aplikacje. W tym miejscu pojawiają się komercyjne rozwiązania firm takich jak partnerzy SparkPost, Virtru i Echoworkx, ułatwiając zabezpieczenie korespondencji biznesowej osoba-osoba (zobacz nasz SparkPost/Echoworkx how-to po więcej informacji).
To powiedziawszy, zgłębmy trochę tradycyjne S/MIME i zobaczmy, co możemy z niego zrobić.
Dlaczego powinienem się tym przejmować?
Krótka wersja:
Szyfrowanie zapewnia prywatność wiadomości.
Podpisy zapewniają uwierzytelnienie (nadawcy), niepodważalność pochodzenia i kontrolę 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 ani prawnie istotnego, prawdopodobnie nie będziesz musiał myśleć o S/MIME. Nowoczesne systemy dostarczania e-maili, takie jak SparkPost, już używają „TLS oportunistycznego” do zabezpieczenia transportu wiadomości od serwera nadawcy do serwera odbiorcy.
Część „oportunistyczna” oznacza jednak, że jeśli serwer nadawcy nie może wynegocjować bezpiecznego połączenia, wyślemy pocztę w postaci zwykłego tekstu. Nie jest to odpowiednie, jeśli chcesz wymusić, aby wiadomość była bezpieczna na całej drodze. Możesz sprawdzić które skrzynki pocztowe deklarują wsparcie TLS i które rzeczywiście to robią. Zakładając, że serwer odbiorcy obsługuje TLS, Twoja wiadomość jest zabezpieczona w następujący sposób:
TLS zabezpiecza rozmowy między serwerami pocztowymi (dlatego nazywa się to Transport Layer Security). MIME (w tym S/MIME) dotyczy treści wiadomości i jej traktowania i można go uważać za część „warstwy prezentacji”.
S/MIME zabezpiecza treść wiadomości na całej drodze („end to end”) od źródła wiadomości do klienta pocztowego odbiorcy, kapsułkując ciało wiadomości.
S/MIME szyfruje ciało wiadomości z wykorzystaniem klucza publicznego odbiorcy. Ciało nie może być zdekodowane bez prywatnego klucza odbiorcy — nie przez żadną „osobę w środku”, taką jak twój ISP, SparkPost, ani serwer pocztowy odbiorcy.
Prywatny klucz nigdy nie jest ujawniany; jest przechowywany wyłącznie w posiadaniu odbiorcy. Zaszyfrowana wiadomość podróżuje przez Internet do odbierającego serwera pocztowego. Kiedy trafia do skrzynki odbiorczej odbiorcy, jest (zwykle automatycznie) deszyfrowana za pomocą ich prywatnego klucza i staje się czytelna.
Oto kilka pułapek S/MIME, na które należy uważać:
S/MIME szyfrowanie ma efektem ubocznym uniemożliwianie skanowania przychodzących wiadomości na serwerze w poszukiwaniu złośliwego oprogramowania, ponieważ ładunek wiadomości jest w formie zaszyfrowanej i dlatego nie do zidentyfikowania.
Zauważ, że nagłówki wiadomości (Od:, Do:, Temat: itp.) nie są szyfrowane, więc treść w linii tematu musi być tworzona z uwzględnieniem tego.
Podpis – uwierzytelnienie
S/MIME oferuje również odbiorcy możliwość sprawdzenia, czy tożsamość nadawcy wiadomości jest taka, jaką twierdzą, że jest.
Email nadawcy ma dołączony certyfikat, który, podobnie jak certyfikat na bezpiecznej stronie internetowej, można śledzić do autorytetu wydającego. Pełny opis procesu podpisywania znajdziesz w PDF procesu podpisywania S/MIME.
Przyjmiemy podejście polegające na podpisywaniu poczty najpierw, a następnie szyfrowaniu jej, więc proces wygląda tak:
Niepodważalność
Kolejną użyteczną korzyścią z podpisywania dla odbiorcy jest niepodważalność pochodzenia. 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 odebrana wiadomość pokazuje, że użyto certyfikatu nadawcy.
Integralność wiadomości
Proces podpisywania tworzy odcisk palca źródłowej wiadomości w postaci zwykłego tekstu (znanej jako skrót wiadomości), szyfruje skrót przy użyciu prywatnego klucza nadawcy i załącza go do dostarczonej wiadomości. Klient pocztowy odbiorcy może stwierdzić, czy ciało wiadomości zostało naruszone.
Może powiesz: „Myślałem, że DKIM daje mi kontrolę integralności wiadomości!” Cóż, tak, DKIM zapewnia integralność ciała wiadomości i nagłówków wiadomości – gwarancje przeciwdziałania manipulacji. Jednak niepowodzenie DKIM (lub jego brak) zwykle nie spowoduje, że przychodząca wiadomość będzie oznaczona jako całkowicie nieważna... chyba że jest w grze polityka DMARC o p=reject (zobacz nasz wpis na blogu DMARC: Jak chronić reputację swojej poczty elektronicznej). DKIM jest jednym z wielu czynników, które ISP używa do wiarygodnego przypisywania reputacji domenie i jest oczywiście istotną częścią twojego stosu wiadomościowego.
Twój klient pocztowy wyraźnie pokaże ci, czy wiadomość S/MIME jest niezgodna z kontrolą podpisów:
Podsumowanie: end-to-end (S/MIME) vs server-to-server (DKIM, DMARC, TLS)
S/MIME to funkcja warstwy prezentacji, która może działać między dwoma użytkownikami końcowi poczty elektronicznej (z ważnymi certyfikatami/kluczami) bez żadnego działania ze strony administratora poczty. S/MIME zapewnia szyfrowanie i podpisywanie i jest osobiste dla każdego użytkownika.
S/MIME jest powiązane z pełnym adresem nadawcy (część lokalna i część domeny), więc na przykład alice@bigcorp.com i bob@bigcorp.com musieliby mieć różne certyfikaty. W przeciwieństwie do tego, DKIM weryfikuje, że poczta elektroniczna pochodzi z podpisanej domeny. DKIM to cały temat sam w sobie; ten artykuł jest dobrym miejscem na rozpoczęcie.
DKIM i DMARC są skonfigurowane przez administratora poczty (działają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.
Podpisy zapewniają uwierzytelnienie (nadawcy), niepodważalność pochodzenia i kontrolę 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 ani prawnie istotnego, prawdopodobnie nie będziesz musiał myśleć o S/MIME. Nowoczesne systemy dostarczania e-maili, takie jak SparkPost, już używają „TLS oportunistycznego” do zabezpieczenia transportu wiadomości od serwera nadawcy do serwera odbiorcy.
Część „oportunistyczna” oznacza jednak, że jeśli serwer nadawcy nie może wynegocjować bezpiecznego połączenia, wyślemy pocztę w postaci zwykłego tekstu. Nie jest to odpowiednie, jeśli chcesz wymusić, aby wiadomość była bezpieczna na całej drodze. Możesz sprawdzić które skrzynki pocztowe deklarują wsparcie TLS i które rzeczywiście to robią. Zakładając, że serwer odbiorcy obsługuje TLS, Twoja wiadomość jest zabezpieczona w następujący sposób:
TLS zabezpiecza rozmowy między serwerami pocztowymi (dlatego nazywa się to Transport Layer Security). MIME (w tym S/MIME) dotyczy treści wiadomości i jej traktowania i można go uważać za część „warstwy prezentacji”.
S/MIME zabezpiecza treść wiadomości na całej drodze („end to end”) od źródła wiadomości do klienta pocztowego odbiorcy, kapsułkując ciało wiadomości.
S/MIME szyfruje ciało wiadomości z wykorzystaniem klucza publicznego odbiorcy. Ciało nie może być zdekodowane bez prywatnego klucza odbiorcy — nie przez żadną „osobę w środku”, taką jak twój ISP, SparkPost, ani serwer pocztowy odbiorcy.
Prywatny klucz nigdy nie jest ujawniany; jest przechowywany wyłącznie w posiadaniu odbiorcy. Zaszyfrowana wiadomość podróżuje przez Internet do odbierającego serwera pocztowego. Kiedy trafia do skrzynki odbiorczej odbiorcy, jest (zwykle automatycznie) deszyfrowana za pomocą ich prywatnego klucza i staje się czytelna.
Oto kilka pułapek S/MIME, na które należy uważać:
S/MIME szyfrowanie ma efektem ubocznym uniemożliwianie skanowania przychodzących wiadomości na serwerze w poszukiwaniu złośliwego oprogramowania, ponieważ ładunek wiadomości jest w formie zaszyfrowanej i dlatego nie do zidentyfikowania.
Zauważ, że nagłówki wiadomości (Od:, Do:, Temat: itp.) nie są szyfrowane, więc treść w linii tematu musi być tworzona z uwzględnieniem tego.
Podpis – uwierzytelnienie
S/MIME oferuje również odbiorcy możliwość sprawdzenia, czy tożsamość nadawcy wiadomości jest taka, jaką twierdzą, że jest.
Email nadawcy ma dołączony certyfikat, który, podobnie jak certyfikat na bezpiecznej stronie internetowej, można śledzić do autorytetu wydającego. Pełny opis procesu podpisywania znajdziesz w PDF procesu podpisywania S/MIME.
Przyjmiemy podejście polegające na podpisywaniu poczty najpierw, a następnie szyfrowaniu jej, więc proces wygląda tak:
Niepodważalność
Kolejną użyteczną korzyścią z podpisywania dla odbiorcy jest niepodważalność pochodzenia. 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 odebrana wiadomość pokazuje, że użyto certyfikatu nadawcy.
Integralność wiadomości
Proces podpisywania tworzy odcisk palca źródłowej wiadomości w postaci zwykłego tekstu (znanej jako skrót wiadomości), szyfruje skrót przy użyciu prywatnego klucza nadawcy i załącza go do dostarczonej wiadomości. Klient pocztowy odbiorcy może stwierdzić, czy ciało wiadomości zostało naruszone.
Może powiesz: „Myślałem, że DKIM daje mi kontrolę integralności wiadomości!” Cóż, tak, DKIM zapewnia integralność ciała wiadomości i nagłówków wiadomości – gwarancje przeciwdziałania manipulacji. Jednak niepowodzenie DKIM (lub jego brak) zwykle nie spowoduje, że przychodząca wiadomość będzie oznaczona jako całkowicie nieważna... chyba że jest w grze polityka DMARC o p=reject (zobacz nasz wpis na blogu DMARC: Jak chronić reputację swojej poczty elektronicznej). DKIM jest jednym z wielu czynników, które ISP używa do wiarygodnego przypisywania reputacji domenie i jest oczywiście istotną częścią twojego stosu wiadomościowego.
Twój klient pocztowy wyraźnie pokaże ci, czy wiadomość S/MIME jest niezgodna z kontrolą podpisów:
Podsumowanie: end-to-end (S/MIME) vs server-to-server (DKIM, DMARC, TLS)
S/MIME to funkcja warstwy prezentacji, która może działać między dwoma użytkownikami końcowi poczty elektronicznej (z ważnymi certyfikatami/kluczami) bez żadnego działania ze strony administratora poczty. S/MIME zapewnia szyfrowanie i podpisywanie i jest osobiste dla każdego użytkownika.
S/MIME jest powiązane z pełnym adresem nadawcy (część lokalna i część domeny), więc na przykład alice@bigcorp.com i bob@bigcorp.com musieliby mieć różne certyfikaty. W przeciwieństwie do tego, DKIM weryfikuje, że poczta elektroniczna pochodzi z podpisanej domeny. DKIM to cały temat sam w sobie; ten artykuł jest dobrym miejscem na rozpoczęcie.
DKIM i DMARC są skonfigurowane przez administratora poczty (działają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.
Podpisy zapewniają uwierzytelnienie (nadawcy), niepodważalność pochodzenia i kontrolę 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 ani prawnie istotnego, prawdopodobnie nie będziesz musiał myśleć o S/MIME. Nowoczesne systemy dostarczania e-maili, takie jak SparkPost, już używają „TLS oportunistycznego” do zabezpieczenia transportu wiadomości od serwera nadawcy do serwera odbiorcy.
Część „oportunistyczna” oznacza jednak, że jeśli serwer nadawcy nie może wynegocjować bezpiecznego połączenia, wyślemy pocztę w postaci zwykłego tekstu. Nie jest to odpowiednie, jeśli chcesz wymusić, aby wiadomość była bezpieczna na całej drodze. Możesz sprawdzić które skrzynki pocztowe deklarują wsparcie TLS i które rzeczywiście to robią. Zakładając, że serwer odbiorcy obsługuje TLS, Twoja wiadomość jest zabezpieczona w następujący sposób:
TLS zabezpiecza rozmowy między serwerami pocztowymi (dlatego nazywa się to Transport Layer Security). MIME (w tym S/MIME) dotyczy treści wiadomości i jej traktowania i można go uważać za część „warstwy prezentacji”.
S/MIME zabezpiecza treść wiadomości na całej drodze („end to end”) od źródła wiadomości do klienta pocztowego odbiorcy, kapsułkując ciało wiadomości.
S/MIME szyfruje ciało wiadomości z wykorzystaniem klucza publicznego odbiorcy. Ciało nie może być zdekodowane bez prywatnego klucza odbiorcy — nie przez żadną „osobę w środku”, taką jak twój ISP, SparkPost, ani serwer pocztowy odbiorcy.
Prywatny klucz nigdy nie jest ujawniany; jest przechowywany wyłącznie w posiadaniu odbiorcy. Zaszyfrowana wiadomość podróżuje przez Internet do odbierającego serwera pocztowego. Kiedy trafia do skrzynki odbiorczej odbiorcy, jest (zwykle automatycznie) deszyfrowana za pomocą ich prywatnego klucza i staje się czytelna.
Oto kilka pułapek S/MIME, na które należy uważać:
S/MIME szyfrowanie ma efektem ubocznym uniemożliwianie skanowania przychodzących wiadomości na serwerze w poszukiwaniu złośliwego oprogramowania, ponieważ ładunek wiadomości jest w formie zaszyfrowanej i dlatego nie do zidentyfikowania.
Zauważ, że nagłówki wiadomości (Od:, Do:, Temat: itp.) nie są szyfrowane, więc treść w linii tematu musi być tworzona z uwzględnieniem tego.
Podpis – uwierzytelnienie
S/MIME oferuje również odbiorcy możliwość sprawdzenia, czy tożsamość nadawcy wiadomości jest taka, jaką twierdzą, że jest.
Email nadawcy ma dołączony certyfikat, który, podobnie jak certyfikat na bezpiecznej stronie internetowej, można śledzić do autorytetu wydającego. Pełny opis procesu podpisywania znajdziesz w PDF procesu podpisywania S/MIME.
Przyjmiemy podejście polegające na podpisywaniu poczty najpierw, a następnie szyfrowaniu jej, więc proces wygląda tak:
Niepodważalność
Kolejną użyteczną korzyścią z podpisywania dla odbiorcy jest niepodważalność pochodzenia. 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 odebrana wiadomość pokazuje, że użyto certyfikatu nadawcy.
Integralność wiadomości
Proces podpisywania tworzy odcisk palca źródłowej wiadomości w postaci zwykłego tekstu (znanej jako skrót wiadomości), szyfruje skrót przy użyciu prywatnego klucza nadawcy i załącza go do dostarczonej wiadomości. Klient pocztowy odbiorcy może stwierdzić, czy ciało wiadomości zostało naruszone.
Może powiesz: „Myślałem, że DKIM daje mi kontrolę integralności wiadomości!” Cóż, tak, DKIM zapewnia integralność ciała wiadomości i nagłówków wiadomości – gwarancje przeciwdziałania manipulacji. Jednak niepowodzenie DKIM (lub jego brak) zwykle nie spowoduje, że przychodząca wiadomość będzie oznaczona jako całkowicie nieważna... chyba że jest w grze polityka DMARC o p=reject (zobacz nasz wpis na blogu DMARC: Jak chronić reputację swojej poczty elektronicznej). DKIM jest jednym z wielu czynników, które ISP używa do wiarygodnego przypisywania reputacji domenie i jest oczywiście istotną częścią twojego stosu wiadomościowego.
Twój klient pocztowy wyraźnie pokaże ci, czy wiadomość S/MIME jest niezgodna z kontrolą podpisów:
Podsumowanie: end-to-end (S/MIME) vs server-to-server (DKIM, DMARC, TLS)
S/MIME to funkcja warstwy prezentacji, która może działać między dwoma użytkownikami końcowi poczty elektronicznej (z ważnymi certyfikatami/kluczami) bez żadnego działania ze strony administratora poczty. S/MIME zapewnia szyfrowanie i podpisywanie i jest osobiste dla każdego użytkownika.
S/MIME jest powiązane z pełnym adresem nadawcy (część lokalna i część domeny), więc na przykład alice@bigcorp.com i bob@bigcorp.com musieliby mieć różne certyfikaty. W przeciwieństwie do tego, DKIM weryfikuje, że poczta elektroniczna pochodzi z podpisanej domeny. DKIM to cały temat sam w sobie; ten artykuł jest dobrym miejscem na rozpoczęcie.
DKIM i DMARC są skonfigurowane przez administratora poczty (działającego na serwerze pocztowym i rekordach DNS). Po skonfigurowaniu są aktywne dla domen, a nie dla poszczególnych użytkowników.
Jak to się odnosi do SparkPost?
Systemy pocztowe do komunikacji między osobami, takie jak Microsoft Exchange Server, od dawna obsługują S/MIME.
Jeśli używasz SparkPost do wysyłania wiadomości do określonych odbiorców z klientami poczty, które potrafią czytać S/MIME, może mieć sens podpisanie wiadomości S/MIME. Podpisywanie S/MIME dodaje dodatkową pewność, że wiadomość faktycznie pochodzi od Ciebie (lub Twojego systemu) i nie została zmieniona, co może być wartościowe w niektórych przypadkach użycia. Wszystko, czego potrzebujesz do tego, to własny klucz i darmowe oprogramowanie, które zaprezentujemy w części 2 tego artykułu.
Użycie szyfrowania S/MIME to osobny wybór. Będziesz potrzebować klucza publicznego dla każdego ze swoich odbiorców. Uzyskanie tego może być tak proste, jak skłonienie ich do przesłania Tobie (lub Twojej aplikacji) podpisanego emaila. W kolejnej części omówimy praktyczne narzędzie do wysyłania poczty podpisanej i zaszyfrowanej S/MIME przez SparkPost.
Systemy pocztowe do komunikacji między osobami, takie jak Microsoft Exchange Server, od dawna obsługują S/MIME.
Jeśli używasz SparkPost do wysyłania wiadomości do określonych odbiorców z klientami poczty, które potrafią czytać S/MIME, może mieć sens podpisanie wiadomości S/MIME. Podpisywanie S/MIME dodaje dodatkową pewność, że wiadomość faktycznie pochodzi od Ciebie (lub Twojego systemu) i nie została zmieniona, co może być wartościowe w niektórych przypadkach użycia. Wszystko, czego potrzebujesz do tego, to własny klucz i darmowe oprogramowanie, które zaprezentujemy w części 2 tego artykułu.
Użycie szyfrowania S/MIME to osobny wybór. Będziesz potrzebować klucza publicznego dla każdego ze swoich odbiorców. Uzyskanie tego może być tak proste, jak skłonienie ich do przesłania Tobie (lub Twojej aplikacji) podpisanego emaila. W kolejnej części omówimy praktyczne narzędzie do wysyłania poczty podpisanej i zaszyfrowanej S/MIME przez SparkPost.
Systemy pocztowe do komunikacji między osobami, takie jak Microsoft Exchange Server, od dawna obsługują S/MIME.
Jeśli używasz SparkPost do wysyłania wiadomości do określonych odbiorców z klientami poczty, które potrafią czytać S/MIME, może mieć sens podpisanie wiadomości S/MIME. Podpisywanie S/MIME dodaje dodatkową pewność, że wiadomość faktycznie pochodzi od Ciebie (lub Twojego systemu) i nie została zmieniona, co może być wartościowe w niektórych przypadkach użycia. Wszystko, czego potrzebujesz do tego, to własny klucz i darmowe oprogramowanie, które zaprezentujemy w części 2 tego artykułu.
Użycie szyfrowania S/MIME to osobny wybór. Będziesz potrzebować klucza publicznego dla każdego ze swoich odbiorców. Uzyskanie tego może być tak proste, jak skłonienie ich do przesłania Tobie (lub Twojej aplikacji) podpisanego emaila. W kolejnej części omówimy praktyczne narzędzie do wysyłania poczty podpisanej i zaszyfrowanej S/MIME przez SparkPost.
Którzy klienci obsługują S/MIME?
Consumer Gmail
Typowy klient sieciowy Gmail wyświetla podpisy przychodzących wiadomości (patrz poniżej), ale nie jest skonfigurowany do przechowywania klucza prywatnego w celu odczytywania zaszyfrowanych wiadomości. Nawet jeśli byłoby to możliwe za pośrednictwem wtyczek stron trzecich, przesyłanie klucza prywatnego nie jest dobrym pomysłem z punktu widzenia bezpieczeństwa.
Nie udało mi się w ogóle skłonić Yahoo! Mail do dekodowania podpisów w wiadomościach.
Wersja konsumencka kont Microsoft Outlook/Hotmail informuje o obecności podpisu S/MIME, ale nie daje pełnego dostępu do oglądania lub sprawdzania certyfikatu.
Poczta biznesowa hostowana
Dla organizacji z hostowaną pocztą, Microsoft Office 365 i G Suite Enterprise mają wsparcie dla S/MIME.
Klienci poczty Outlook
Klient-based Microsoft Outlook (np. 2010 dla Windows) działa:
Kliknięcie ikon daje więcej informacji:
W Outlook 2010 / Windows, magazyn certyfikatów jest dostępny poprzez File / Options / Trust Center / Trust Center Settings / Email Security / Import / Export.
Thunderbird – wieloplatformowy i darmowy
Jeśli szukasz darmowego klienta, Mozilla Thunderbird spełnia wymagania. Jest dostępny na PC, Mac i Linux, i obsługuje S/MIME na wszystkich tych platformach. Oto jak wygląda wiadomość na Macu. Ikona „zamkniętej koperty” wskazuje, że wiadomość jest podpisana, a kłódka wskazuje, że została zaszyfrowana.
Kliknięcie na kopertę/kłódkę wyświetla informacje o wiadomości:
Thunderbird ma własny magazyn kluczy, dostępny w podobny sposób na każdej platformie:
Mac poprzez Preferences / Advanced / Certificates / Manage Certificates
PC: menu („hamburger” na górze po prawej), Advanced / Certificates / Manage Certificates
Linux: menu („hamburger” na górze po prawej), Preferences / Advanced / Manage Certificates
Mac Mail
Mac Mail również obsługuje S/MIME. Opiera się na Twoim kluczu dostępowym Mac, aby przechowywać klucze.
iOS Mail
Na początek zaimportuj certyfikat swojego konta e-mailowego w ten sposób, wtedy możesz oglądać podpisane i zaszyfrowane e-maile S/MIME. Nie wyglądają one naprawdę inaczej na ekranie przeglądania.
Android
Niektóre urządzenia i aplikacje obsługują S/MIME; istnieje wiele różnych wariantów. Samsung ma przewodnik.
Consumer Gmail
Typowy klient sieciowy Gmail wyświetla podpisy przychodzących wiadomości (patrz poniżej), ale nie jest skonfigurowany do przechowywania klucza prywatnego w celu odczytywania zaszyfrowanych wiadomości. Nawet jeśli byłoby to możliwe za pośrednictwem wtyczek stron trzecich, przesyłanie klucza prywatnego nie jest dobrym pomysłem z punktu widzenia bezpieczeństwa.
Nie udało mi się w ogóle skłonić Yahoo! Mail do dekodowania podpisów w wiadomościach.
Wersja konsumencka kont Microsoft Outlook/Hotmail informuje o obecności podpisu S/MIME, ale nie daje pełnego dostępu do oglądania lub sprawdzania certyfikatu.
Poczta biznesowa hostowana
Dla organizacji z hostowaną pocztą, Microsoft Office 365 i G Suite Enterprise mają wsparcie dla S/MIME.
Klienci poczty Outlook
Klient-based Microsoft Outlook (np. 2010 dla Windows) działa:
Kliknięcie ikon daje więcej informacji:
W Outlook 2010 / Windows, magazyn certyfikatów jest dostępny poprzez File / Options / Trust Center / Trust Center Settings / Email Security / Import / Export.
Thunderbird – wieloplatformowy i darmowy
Jeśli szukasz darmowego klienta, Mozilla Thunderbird spełnia wymagania. Jest dostępny na PC, Mac i Linux, i obsługuje S/MIME na wszystkich tych platformach. Oto jak wygląda wiadomość na Macu. Ikona „zamkniętej koperty” wskazuje, że wiadomość jest podpisana, a kłódka wskazuje, że została zaszyfrowana.
Kliknięcie na kopertę/kłódkę wyświetla informacje o wiadomości:
Thunderbird ma własny magazyn kluczy, dostępny w podobny sposób na każdej platformie:
Mac poprzez Preferences / Advanced / Certificates / Manage Certificates
PC: menu („hamburger” na górze po prawej), Advanced / Certificates / Manage Certificates
Linux: menu („hamburger” na górze po prawej), Preferences / Advanced / Manage Certificates
Mac Mail
Mac Mail również obsługuje S/MIME. Opiera się na Twoim kluczu dostępowym Mac, aby przechowywać klucze.
iOS Mail
Na początek zaimportuj certyfikat swojego konta e-mailowego w ten sposób, wtedy możesz oglądać podpisane i zaszyfrowane e-maile S/MIME. Nie wyglądają one naprawdę inaczej na ekranie przeglądania.
Android
Niektóre urządzenia i aplikacje obsługują S/MIME; istnieje wiele różnych wariantów. Samsung ma przewodnik.
Consumer Gmail
Typowy klient sieciowy Gmail wyświetla podpisy przychodzących wiadomości (patrz poniżej), ale nie jest skonfigurowany do przechowywania klucza prywatnego w celu odczytywania zaszyfrowanych wiadomości. Nawet jeśli byłoby to możliwe za pośrednictwem wtyczek stron trzecich, przesyłanie klucza prywatnego nie jest dobrym pomysłem z punktu widzenia bezpieczeństwa.
Nie udało mi się w ogóle skłonić Yahoo! Mail do dekodowania podpisów w wiadomościach.
Wersja konsumencka kont Microsoft Outlook/Hotmail informuje o obecności podpisu S/MIME, ale nie daje pełnego dostępu do oglądania lub sprawdzania certyfikatu.
Poczta biznesowa hostowana
Dla organizacji z hostowaną pocztą, Microsoft Office 365 i G Suite Enterprise mają wsparcie dla S/MIME.
Klienci poczty Outlook
Klient-based Microsoft Outlook (np. 2010 dla Windows) działa:
Kliknięcie ikon daje więcej informacji:
W Outlook 2010 / Windows, magazyn certyfikatów jest dostępny poprzez File / Options / Trust Center / Trust Center Settings / Email Security / Import / Export.
Thunderbird – wieloplatformowy i darmowy
Jeśli szukasz darmowego klienta, Mozilla Thunderbird spełnia wymagania. Jest dostępny na PC, Mac i Linux, i obsługuje S/MIME na wszystkich tych platformach. Oto jak wygląda wiadomość na Macu. Ikona „zamkniętej koperty” wskazuje, że wiadomość jest podpisana, a kłódka wskazuje, że została zaszyfrowana.
Kliknięcie na kopertę/kłódkę wyświetla informacje o wiadomości:
Thunderbird ma własny magazyn kluczy, dostępny w podobny sposób na każdej platformie:
Mac poprzez Preferences / Advanced / Certificates / Manage Certificates
PC: menu („hamburger” na górze po prawej), Advanced / Certificates / Manage Certificates
Linux: menu („hamburger” na górze po prawej), Preferences / Advanced / Manage Certificates
Mac Mail
Mac Mail również obsługuje S/MIME. Opiera się na Twoim kluczu dostępowym Mac, aby przechowywać klucze.
iOS Mail
Na początek zaimportuj certyfikat swojego konta e-mailowego w ten sposób, wtedy możesz oglądać podpisane i zaszyfrowane e-maile S/MIME. Nie wyglądają one naprawdę inaczej na ekranie przeglądania.
Android
Niektóre urządzenia i aplikacje obsługują S/MIME; istnieje wiele różnych wariantów. Samsung ma przewodnik.
Wreszcie…
To nasze szybkie podsumowanie praktycznych zastosowań S/MIME. Jeśli chcesz zdobyć własne certyfikaty pocztowe, lista dostawców jest dostępna tutaj. Uważam, że Comodo działa dobrze (bezpłatnie do użytku niekomercyjnego – otwieraj w Firefoxie, a nie w Chrome).
W części 2 zbadamy, jak zastosować podpisywanie i szyfrowanie S/MIME do wiadomości dostarczanych za pomocą SparkPost.
Dalsza lektura
Microsoft ma dobry artykuł wprowadzający na temat S/MIME w swojej dokumentacji.
Aby uzyskać więcej informacji na temat podatności EFAIL i sposobu jej rozwiązania, 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 podsumowanie praktycznych zastosowań S/MIME. Jeśli chcesz zdobyć własne certyfikaty pocztowe, lista dostawców jest dostępna tutaj. Uważam, że Comodo działa dobrze (bezpłatnie do użytku niekomercyjnego – otwieraj w Firefoxie, a nie w Chrome).
W części 2 zbadamy, jak zastosować podpisywanie i szyfrowanie S/MIME do wiadomości dostarczanych za pomocą SparkPost.
Dalsza lektura
Microsoft ma dobry artykuł wprowadzający na temat S/MIME w swojej dokumentacji.
Aby uzyskać więcej informacji na temat podatności EFAIL i sposobu jej rozwiązania, 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 podsumowanie praktycznych zastosowań S/MIME. Jeśli chcesz zdobyć własne certyfikaty pocztowe, lista dostawców jest dostępna tutaj. Uważam, że Comodo działa dobrze (bezpłatnie do użytku niekomercyjnego – otwieraj w Firefoxie, a nie w Chrome).
W części 2 zbadamy, jak zastosować podpisywanie i szyfrowanie S/MIME do wiadomości dostarczanych za pomocą SparkPost.
Dalsza lektura
Microsoft ma dobry artykuł wprowadzający na temat S/MIME w swojej dokumentacji.
Aby uzyskać więcej informacji na temat podatności EFAIL i sposobu jej rozwiązania, 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?.
