Transport TLS ja S/MIME ratkaisevat erilaisia ongelmia. TLS suojaa yhteyttä viereisten järjestelmien välillä. S/MIME voi allekirjoittaa tai salata viestin sisällön niin, että suojaus kulkee viestin mukana. Se, onko tämä todella päästä päähän, riippuu siitä, missä avaimet säilytetään ja missä allekirjoitus tai salauksen purku tapahtuu, ei pelkästään siitä, näyttääkö sähköpostiohjelma suojauskuvakkeen.
Piirrä polku ennen kuin valitset ohjausobjektin
Viitteet: RFC 3207 §1, RFC 8551 §1.
Käytä viestiä Alicen asiakkaalta hänen lähetyspalveluun, sitten lähtevää yhdyskäytävää, vastaanottajan MX palvelua ja Bobin postilaatikkoa ja asiakasohjelmaa. Jokaisella verkkohyppäämällä voi olla oma TLS -yhteys ja -käytäntö. Onnistunut toimialueiden välinen SMTP TLS -yhteys ei kerro mitään lähetyksestä, sisäisistä välityksistä, postilaatikon käytöstä tai tallennustilan salauksesta.
Jokaisella palvelimella, joka lopettaa TLS , tavallinen viestisisältö on saatavilla käsiteltäväksi, ellei sitä ole erikseen salattu. Suodattimet, yhdyskäytävät ja vaarantuneet päätepisteet ovat siksi osa luottamuksellisuusrajaa. MTA-STS ja SMTP DANE parantaa liikenteen todentamista ja valvontaa soveltuvilla reiteillä; kumpikaan ei muuta hop-by-hop TLS ää viestin salaukseksi. RFC 8461 jakso 2.
Erottele allekirjoitus salauksesta
Viitteet: RFC 8551 §3.3, RFC 8551 §3.4, RFC 8551 §3.5, RFC 8551 §3.7, RFC 8551 §4.
S/MIME -allekirjoitettu sisältö tarjoaa eheyden ja allekirjoittajan todennustodistuksen varmenteen luotettavuuden ja validoinnin mukaisesti. Pelkkä allekirjoittaminen ei peitä viestiä. S/MIME -kuorillinen sisältö salaa suojatun materiaalin vastaanottajille, joiden avaimet voivat purkaa sen salauksen; Salaus yksinään ei vastaa vahvistettua tekijän allekirjoitusta. Todennettu kuorittu sisältö voi lisäksi tarjota luottamuksellisuutta ja tietojen eheyttä todistamatta alkuperää, kuten RFC 8551 §3.4 selittää. Älä rinnasta tätä suojaa vahvistettuun tekijän allekirjoitukseen. Työnkulku voi yhdistää allekirjoituksen ja salauksen. RFC 8551 kohdat 2 ja 3.
Avaimet ja varmenneidentiteetit tarvitsevat elinkaaren hallintaa. Tarkista, kuka voi käyttää yksityisiä avaimia, kuinka vastaanottajat saavat varmenteita, kuinka vanhentuneet tai kadonneet avaimet vaikuttavat arkistoitujen sähköpostien käyttöön ja mikä palautusprosessi on valtuutettu. Nämä ovat toiminnallisia suunnittelukysymyksiä, eivät syitä levittää yksityisiä avaimia laajasti tai olettaa, että toimialueen todennustarkistus korvaa varmenteen validoinnin.
Vertaa uhkauksia samassa viestissä
Viitteet: RFC 8551 §3.1, RFC 8551 §6.
Oikein salatun SMTP hyppelyn passiivista tarkkailua varten TLS suojaa kyseisellä hyppyllä lähetetyt tavut. Yhdyskäytävän järjestelmänvalvojalle, joka lukee postia TLS lopettamisen jälkeen, hop-salaus ei tarjoa sisällön luottamuksellisuuden estettä. Asiakaspuolen S/MIME -salaus voi suojata salattua runkoa kyseiseltä yhdyskäytävältä, jos siinä ei ole salauksenpurkuavainta. Sanalla voi olla merkitystä, koska jotkin käyttöönotot purkavat tarkoituksella salauksen yhdyskäytävissä.
Siirron jälkeen tapahtuvaa muutosta varten kelvollinen S/MIME -allekirjoitus voi paljastaa muutoksia allekirjoitettuun sisältöön; se tosiasia, että aikaisempi TLS yhteys onnistui, ei voi. Jos vastaanottajaasiakkaalla on vaarantunut salauksenpurkuavain, TLS tai S/MIME -salaus ei estä asiakasta käyttämästä pelkkää tekstiä. Näkyvien reititysmetatietojen ja ulompien otsikoiden osalta älä lupaa täydellistä piilottamista: kattavuus riippuu viestin pakkauksesta ja toteutuksesta.
Yksityisen tarkastelun todisteet sisältävät nimenomaisen polun ja uhan matriisin, joka kuvaa näitä rajoja. Se on suunnittelumalli, ei kryptografinen yhteentoimivuustesti. Paikallinen TLSA muualla paketissa olevat varmennelaitteet eivät luo S/MIME -allekirjoitus- tai salauksenpurkukäyttäytymistä.
Valitse hallintalaitteet ja hyväksyntätodisteet yhdessä
Viitteet: RFC 8551 §4, RFC 8551 §6.
Määritä, mitkä hyppyt tarvitsevat pakotetun TLS , mikä sisältö tarvitsee allekirjoituksen tai salauksen ja missä salauksen purkaminen on sallittua. Testaa edustavia asiakkaita, liitteitä, edelleenlähetystä ja arkistointia valvotussa ympäristössä. Säilytä sekä positiivinen vahvistus että negatiivinen muutetun sisällön tapaukset, ennen kuin väität, että työnkulku säilyttää allekirjoitukset tai luottamuksellisuuden tietyllä reitillä.
Pitää phishing ja liiketoimintaprosessivaatimukset erillään. Todennettu lähettäjä tai allekirjoitettu viesti voi silti sisältää virheellisen tai vilpillisen maksupyynnön, etenkin tilin vaarantumisen jälkeen. Seuraavien toimien riippumaton todentaminen on edelleen tarpeen. Tässä oppaassa ei allekirjoitettu, salattu, toimitettu tai purettu S/MIME -viestejä; sen todisteena on tarkastettava valvonta-uhka-matriisi, ja asiakkaan yhteentoimivuus on edelleen nimenomaan odottava hyväksymistehtävä.