Transport TLS en S/MIME lossen verschillende problemen op. TLS beschermt een verbinding tussen aangrenzende systemen. S/MIME kan de inhoud van berichten ondertekenen of coderen, zodat de bescherming met het bericht meegaat. Of dat echt end-to-end is, hangt af van waar de sleutels worden bewaard en waar de ondertekening of decodering plaatsvindt, en niet alleen of een e-mailclient een beveiligingspictogram weergeeft.
Teken het pad voordat u een besturingselement kiest
Referenties: RFC 3207 §1, RFC 8551 §1.
Gebruik een bericht van de klant van Alice naar haar indieningsservice, vervolgens een uitgaande gateway, de MX service van de ontvanger en de mailbox en client van Bob. Elke netwerkhop kan zijn eigen TLS -verbinding en -beleid hebben. Een succesvolle SMTP TLS verbinding tussen domeinen zegt op zichzelf niets over indiening, interne relays, mailboxtoegang of opslagversleuteling.
Op elke server die TLS beëindigt, is de gewone berichtinhoud beschikbaar voor verwerking, tenzij deze afzonderlijk wordt gecodeerd. Filters, gateways en gecompromitteerde eindpunten blijven daarom onderdeel van de vertrouwelijkheidsgrens. MTA-STS en SMTP DANE de transportauthenticatie en -handhaving voor hun toepasselijke routes verbeteren; geen van beide transformeert hop-by-hop TLS in berichtversleuteling. RFC 8461 sectie 2.
Maak onderscheid tussen ondertekening en encryptie
Referenties: RFC 8551 §3.3, RFC 8551 §3.4, RFC 8551 §3.5, RFC 8551 §3.7, RFC 8551 §4.
Met S/MIME ondertekende inhoud biedt bewijs van integriteit en ondertekenaarauthenticatie op basis van certificaatvertrouwen en -validatie. Alleen ondertekenen verbergt de boodschap niet. S/MIME omhulde inhoud codeert beschermd materiaal voor ontvangers wier sleutels het kunnen ontsleutelen; encryptie alleen is niet hetzelfde als een geverifieerde handtekening van de auteur. Geauthenticeerde omhulde inhoud kan bovendien vertrouwelijkheid en gegevensintegriteit bieden zonder de herkomst te bewijzen, zoals RFC 8551 §3.4 uitlegt. Stel die bescherming niet gelijk aan een geverifieerde handtekening van de auteur. Een workflow kan ondertekening en encryptie combineren. RFC 8551 secties 2 en 3.
Sleutels en certificaatidentiteiten hebben levenscyclusbeheer nodig. Bevestig wie toegang heeft tot privésleutels, hoe ontvangers certificaten verkrijgen, hoe verlopen of verloren sleutels de toegang tot gearchiveerde e-mail beïnvloeden en welk herstelproces is geautoriseerd. Dit zijn operationele ontwerpvragen, geen redenen om privésleutels breed te verspreiden of om aan te nemen dat een domeinauthenticatiecontrole de certificaatvalidatie vervangt.
Vergelijk bedreigingen op hetzelfde bericht
Referenties: RFC 8551 §3.1, RFC 8551 §6.
Voor passieve observatie van een correct gecodeerde SMTP hop beschermt TLS de verzonden bytes op die hop. Voor een gatewaybeheerder die e-mail leest na beëindiging TLS , vormt hop-encryptie geen barrière voor de vertrouwelijkheid van de inhoud. S/MIME -versleuteling aan de clientzijde kan de versleutelde instantie tegen die gateway beschermen als deze geen decoderingssleutel bevat. Het woord kan ertoe doen omdat sommige implementaties opzettelijk bij gateways worden gedecodeerd.
Voor wijzigingen na transport kan een geldige S/MIME -handtekening wijzigingen in de ondertekende inhoud blootleggen; het feit dat een eerdere TLS verbinding is gelukt, kan dat niet. Voor een gecompromitteerde ontvangende client die over de decoderingssleutel beschikt, verhindert noch TLS noch S/MIME -codering dat de client toegang krijgt tot leesbare tekst. Voor zichtbare routing-metagegevens en buitenste headers mag u geen volledige verhulling beloven: de dekking hangt af van de berichtverpakking en -implementatie.
Het privébeoordelingsbewijs bevat een expliciete pad-en-dreigingsmatrix die deze grenzen beschrijft. Het is een ontwerpmodel, geen cryptografische interoperabiliteitstest. De lokale TLSA certificaatarmaturen elders in het pakket zorgen niet voor S/MIME -ondertekenings- of decoderingsgedrag.
Kies samen controles en acceptatiebewijs
Referenties: RFC 8551 §4, RFC 8551 §6.
Geef op welke hop afgedwongen TLS nodig heeft, welke inhoud moet worden ondertekend of versleuteld, en waar ontsleuteling is toegestaan. Test representatieve clients, bijlagen, doorstuur- en archieftoegang in een gecontroleerde omgeving. Bewaar zowel positieve verificatie als negatieve gevallen van gewijzigde inhoud voordat u claimt dat de workflow handtekeningen of vertrouwelijkheid via een bepaalde route behoudt.
Houden phishing en bedrijfsprocesclaims gescheiden. Een geverifieerde afzender of een ondertekend bericht kan nog steeds een foutief of frauduleus betalingsverzoek bevatten, vooral nadat een account is gecompromitteerd. Onafhankelijke verificatie van vervolgacties blijft noodzakelijk. Voor deze handleiding is geen S/MIME bericht ondertekend, gecodeerd, afgeleverd of gedecodeerd; het bewijs hiervan is de inspecteerbare controle-tot-dreigingsmatrix, en de interoperabiliteit van de cliënt blijft een expliciet wachtende acceptatietaak.