Transport TLS og S/MIME løser ulike problemer. TLS beskytter en forbindelse mellom tilstøtende systemer. S/MIME kan signere eller kryptere meldingsinnhold slik at beskyttelse følger med meldingen. Hvorvidt det virkelig er ende-til-ende, avhenger av hvor nøkler holdes og hvor signering eller dekryptering skjer, ikke bare om en e-postklient viser et sikkerhetsikon.
Tegn banen før du velger en kontroll
Referanser: RFC 3207 §1, RFC 8551 §1.
Bruk en melding fra Alices klient til innsendingstjenesten hennes, deretter en utgående gateway, mottakerens MX tjeneste og Bobs postboks og klient. Hvert nettverkshopp kan ha sin egen TLS tilkobling og policy. En vellykket SMTP TLS tilkobling mellom domene sier ingenting i seg selv om innsending, interne releer, postbokstilgang eller lagringskryptering.
På hver server som avslutter TLS , er vanlig meldingsinnhold tilgjengelig for behandling med mindre det er separat kryptert. Filtre, gatewayer og kompromitterte endepunkter forblir derfor en del av konfidensialitetsgrensen. MTA-STS og SMTP DANE forbedre transportautentisering og håndhevelse for deres gjeldende ruter; ingen av dem forvandler hop-by-hop TLS til meldingskryptering. RFC 8461 del 2.
Skille signering fra kryptering
Referanser: RFC 8551 §3.3, RFC 8551 §3.4, RFC 8551 §3.5, RFC 8551 §3.7, RFC 8551 §4.
S/MIME -signert innhold gir bevis for integritet og signerautentisering i henhold til sertifikattillit og validering. Signering alene skjuler ikke meldingen. S/MIME omhyllet innhold krypterer beskyttet materiale for mottakere hvis nøkler kan dekryptere det; kryptering alene tilsvarer ikke en bekreftet forfattersignatur. Autentisert innhyllet innhold kan i tillegg gi konfidensialitet og dataintegritet uten å bevise opprinnelse, som RFC 8551 §3.4 forklarer. Ikke sidestill denne beskyttelsen med en bekreftet forfattersignatur. En arbeidsflyt kan kombinere signering og kryptering. RFC 8551 seksjoner 2 og 3.
Nøkler og sertifikatidentiteter trenger livssyklusadministrasjon. Bekreft hvem som har tilgang til private nøkler, hvordan mottakere får sertifikater, hvordan utløpte eller tapte nøkler påvirker tilgangen til arkivert e-post og hvilken gjenopprettingsprosess som er autorisert. Dette er operative designspørsmål, ikke grunner til å distribuere private nøkler bredt eller å anta at en domeneautentiseringssjekk erstatter sertifikatvalidering.
Sammenlign trusler på samme melding
Referanser: RFC 8551 §3.1, RFC 8551 §6.
For passiv observasjon av et riktig kryptert SMTP hopp, beskytter TLS de overførte bytene på det hoppet. For en gatewayadministrator som leser e-post etter TLS avslutning, gir hop-kryptering ingen innholdskonfidensialitetsbarriere. S/MIME -kryptering på klientsiden kan beskytte den krypterte kroppen fra den gatewayen hvis den ikke har en dekrypteringsnøkkel. Ordet kan ha betydning fordi noen distribusjoner med vilje dekrypterer ved gatewayer.
For endring etter transport kan en gyldig S/MIME -signatur avsløre endringer i det signerte innholdet; det faktum at en tidligere TLS tilkobling lyktes, kan ikke. For en kompromittert mottakerklient som har dekrypteringsnøkkelen, hindrer verken TLS eller S/MIME -kryptering klienten i å få tilgang til klartekst. For synlige rutingmetadata og ytre overskrifter, ikke lov fullstendig fortielse: dekningen avhenger av meldingspakken og implementeringen.
Beviset for private vurderinger inneholder en eksplisitt bane-og-trusselmatrise som beskriver disse grensene. Det er en designmodell, ikke en kryptografisk interoperabilitetstest. Det lokale TLSA sertifikatfixturer andre steder i pakken etablerer ikke S/MIME -signering eller dekrypteringsadferd.
Velg kontroller og akseptbevis sammen
Referanser: RFC 8551 §4, RFC 8551 §6.
Spesifiser hvilke hopp som trenger håndhevet TLS , hvilket innhold som trenger signering eller kryptering, og hvor dekryptering er tillatt. Test representative klienter, vedlegg, videresending og arkivtilgang i et kontrollert miljø. Behold både positiv bekreftelse og negativt endret innholdssaker før du hevder at arbeidsflyten bevarer signaturer eller konfidensialitet på tvers av en bestemt rute.
Beholde phishing og forretningsprosesskrav separat. En autentisert avsender eller signert melding kan fortsatt inneholde en feilaktig eller uredelig betalingsforespørsel, spesielt etter at kontoen er kompromittert. Uavhengig verifisering av følgehandlinger er fortsatt nødvendig. Ingen S/MIME meldinger ble signert, kryptert, levert eller dekryptert for denne veiledningen; beviset er den inspiserbare kontroll-til-trussel-matrisen, og klientinteroperabilitet forblir en eksplisitt påventende akseptoppgave.