Mit kell tudni az SSL/TLS használatáról az e-mail szerverek által létrehozott kapcsolatok titkosításához

Amikor megkerestek
a blogbejegyzés témájával, boldogan beleegyeztem. Íme egy kis parafrázisa
annak, hogyan történt:

“Képes lennél
írni egy bejegyzést a TLS fontosságáról az e-mail szervereken?” – kérdezte Patrick.

“Persze” – mondtam.

Hú, ez egy őrült
beszélgetés volt, amit újra át kell élni! Mint egy forgószél!

Aztán egy kicsit gondolkodni kezdtem rajta. Tényleg vannak olyan e-mail szerverek, amelyek nem használnak titkosítást az átvitelhez? Nem a végponttól-végpontig titkosításra gondolok, mint amivel korábban foglalkoztunk (S/MIME, PGP, stb.). A szervertől szerverig vagy a kettő közötti titkosításra gondolok, hogy megvédje az adatokat a tranzitútvonal mentén.

A mai korban senki sem hagyná a bejövő/kimenő leveleit plaintextben, hogy Isten tudja, milyen útvonalon haladva lehallgassák és kihasználják. Sokan használnak e-mail szolgáltatásokat, és kizárt, hogy kizárnák a tranzit titkosítást a szolgáltatásukból. Az adatvédelmi incidensek milliókba kerülnek nekik
perekben, üzletveszteségben és szégyenben……Hmmmm…..

visszamentem Patrickhoz
egy kérdéssel.

“Vannak statisztikáink
vagy információink a titkosítást nem használó e-mail szerverekről? Az a gyanúm, hogy ez
alacsony lenne. Más szóval, mi késztetett arra, hogy megkérdezd ezt a cikket?”

Patrick így válaszolt: “Nekem
valójában nincs. Úgy gondoltam, hogy ez egy jó téma lenne, figyelembe véve az e-mail fontosságát
és a biztonsághoz szükséges összes szempontot.”

OK. Ennek van értelme. Valószínűleg vannak olyan e-mail szerverek, amelyek egyáltalán nem használják, bár kétségtelen, hogy sokkal nagyobb százalékuk használ elavult protokollokat vagy lejárt tanúsítványokat, és lehet, hogy csak egy frissítésre van szükségük.

Ez a cikk
átnézi, hogy hol tartunk az e-mail és a tranzit titkosítással, hogy megbizonyosodjon arról, hogy
a rendelkezésre álló optimális biztonsági szinten működik, ami elérhető.

Titkosítás az e-mail szervereken

Ezzel a ponttal valószínűleg már nagyjából értjük, hogyan működik a TLS, de foglaljuk össze, ha esetleg még nem ismeri a témát.

Személy A szeretne
biztonságos kommunikációt küldeni Ember B. Személy A és Ember B rendelkezik egy előre létrehozott
tanúsítvánnyal. A személy A a tanúsítványt használja az információ titkosítására, és elküldi
a titkosított információt Ember B-nek. Az információ mindaddig olvashatatlan, amíg Ember
B nem használja a tanúsítványt a titkosított információ visszafejtésére.

Ha az Ember B titkosított információval akar
visszaválaszolni az A személynek, akkor az Ember B a
tanúsítványt használja az adatok titkosítására, az A személy pedig a tanúsítványt használja az üzenet
visszafejtésére.

Általában így működik a
kódolás/dekódolás. Most a példában felsorolt személyeket helyettesítsük
kiszolgálókkal és más hasonló kapcsolatokkal. Ugyanaz a koncepció.

Most ha ember B titkosított információval akar válaszolni személy A-nak, akkor ember B az imént generált szimmetrikus kulcsot használja, és most már mindketten tudnak egymásnak adatokat titkosítani és küldeni, illetve fogadni és visszafejteni.

Az SSL/TLS segítségével történő titkosítás/dekódolás általában így működik. Most cseréljük ki a példában felsorolt embereket szerverekre és más hasonló kapcsolatokra. Ugyanaz a koncepció. Így működik a TLS az e-mailekkel, ami egy kicsit más, mint ahogyan megkönnyíti a HTTPS-kapcsolatot, mivel az e-mailek más protokollokat használnak. De még mindig van néhány határozott hasonlóság:

• Kézfogás történik
• A hitelesítés történik (bár ebben a kontextusban mindkét fél hitelesíti magát)
• Munkamenetkulcsokat használnak az e-mailek áramlásának továbbításához.

Ebb és (Mail) Flow

A következő lépés ebben a
“megértjük, miért” cikkben a “megértjük, hogyan” rész.

Röviden, egy e-mail kliens elküldi az e-mailt a kimenő szervernek. A kimenő kiszolgáló DNS-keresést végez a cél e-mail tartomány alapján, és a DNS MX rekordja meghatározza, hogy melyik kiszolgálóra kell küldeni az e-mailt, és esetleg ez a kiszolgáló határozza meg, hogy tovább kell-e továbbítani, amíg el nem éri a cél postafiók Mail Delivery Agent (MDA).

Nem elég
megbízni a DNS MX rekordokban, ami egy teljesen más bizalmi kérdés, hanem az SMTP
(kimenő levelek, MTA, stb.) szervernek és a beérkező leveleknek ( POP3, IMAP,
Exchange segítségével) azonosítaniuk kell egymást és rendelkezniük kell a megfelelő kulcsokkal az egymással való
kommunikációhoz. És az útvonaltól függően több
minden lehet, mint csak egy ugrásra lévő e-mail szerverrel való kommunikáció. Az útvonal mentén lehetnek levélváltók, proxy
szerverek és egyebek. Minden egyes ugráshoz titkosított kapcsolatra van (kellene) szükség. Gyakran ez így is van. Néha nem. A felhasználók azt szeretnék, ha az érzékeny információk titkosítva lennének az útvonal mentén. A végponttól végpontig terjedő titkosítás
segít biztosítani, hogy az egész út során legyen valamilyen titkosítás, de
a biztonsági rétegek mindig jobbak.

Respect Thy Securi-Tie

Apropó, a
Securi-Tie nem egy igazi szó. Csak azért találtam ki ezt a szót, mert rímel. Ez
egy játék a biztonság szóval.

Az előző részből
olyan ugródeszkaként
beszélnünk kell a biztonsági beállításokról, amelyeket ugyan
a kliens oldalról állítanánk be, de valójában valamilyen utasítást
adnánk a levelezőszerver oldalának a biztonsággal kapcsolatos célokra.

E-mail kliens (Outlook, Thunderbird stb.) beállításakor az alapértelmezett beállítás a titkosítás nélküli
konfiguráció. De, ahogyan ennek a cikknek a lényege is, általában a titkosított
opciót szeretnénk választani. Bizonyos értelemben ez nem teljesen a kliensen múlik: ez
attól függ, hogy a szerveroldal mit tud támogatni. Feltételezve, hogy a bejövő
és a kimenő szerverek támogatják a titkosítást, miért ne tenné? Ha rendel egy
steaket egy étteremben, és ugyanolyan áron kínálják a szűzpecsenyét vagy a Kobe(wagyu) ribeye
t, miért ne rendelné a jobb minőségű darabot?

Szóval, ha használni akarod a
TLS/SSL-t az e-mailekben (ez az átviteli részre vonatkozik, és nem a végponttól végpontig tartó,
S/MIME részre, amelyet más blogbejegyzésekben tárgyalunk), kapcsold be. Használja a 465
vagy 587-es portot az SMTP (‘tag, kimenő levelezés) és a 993-as (IMAP) vagy 995-ös (POP3) portot a
bejövő forgalomhoz.

Egy
érdekes titkosítási protokollt még mindig használnak az e-mail szerverek között. Ennek
van jó és rossz oldala, mint a legtöbb dolognak. Végső soron azt mondanám, hogy
a szándékai jók, de a valós alkalmazás nem egészen olyan ideális, mint amilyen
lehetne. Hölgyeim és uraim, ez a protokoll a STARTTLS.

A STARTTLS egy biztonsági
protokoll, ami alapvetően az SSL/TLS. Egészen egyszerűen, a STARTTLS fog egy
meglévő plaintext és ezért nem biztonságos kapcsolatot, és megpróbálja átalakítani
egy biztonságos kapcsolattá TLS (vagy SSL) segítségével. Tehát a
STARTTLS és az SSL/TLS biztonsági szintje valójában nem különbözik. Ha minden megfelelően van beállítva, mindkettő
TLS (vagy SSL) használatával titkosítja az információkat.

A fő különbség
a kapcsolat állapotán és/vagy a kommunikáció kezdeményezésén alapul. A STARTTLS
nem garantálja a titkosított kommunikációt. Alapvetően azt jelenti, hogy “ha a
kapcsolat titkosítatlan, és képes vagy rá, tedd biztonságos
kapcsolattá”. Ha a kapcsolati csomópont (valószínűleg egy kiszolgáló) nem képes a
kapcsolatot titkosított kapcsolattá alakítani, akkor az ügyfél végére maradhat, hogy
eldöntse, hogyan kezelje azt onnantól kezdve.

Míg a STARTTLS
minősítő kifejezést “hasznosnak” használtam, kevésbé biztonságos
nak tekinthető, mint az SSL/TLS választása. A szabványos SSL/TLS kiválasztás alapvetően azt jelenti, hogy “Használj
titkosítást vagy bukdácsolj”. A STARTTLS azt mondja: “Ööö, ha megtehetnéd, kérlek, tedd meg. Ha nem, akkor más utasítások alapján folytathatjuk.”

Itt van néhány meggyőző kijelentés

Gyakran előfordul, hogy a nyilvánvalót ki kell mondani, és talán
túl kell hangsúlyozni. Szóval itt van, khm: Használj titkosítást. Különösen olyasvalamihez, ami
olyan fontos, olyan döntő fontosságú, és látszólag beépül
minden olyan szervezeti struktúra túlnyomó többségébe, ami döntő fontosságú információkat hordozhat. Nincs
nagy erőfeszítés, amit bele kell fektetni. Használjon mind a végponttól végpontig tartó, mind az átvitel közbeni
titkosítást. Kettő jobb, mint egy.

Ha valaki úgy érzi, hogy nem éri meg a plusz erőfeszítést egy e-mail
szerver titkosításra való beállítása a titkosítatlanhoz képest, akkor az a valaki
nem éri meg. Ez egyszerűen túlzás a nyilvánvalón. A végponttól végpontig tartó titkosítás, mint például az S/MIME, egy
nagyobb erőfeszítést igényel, de ez is megéri a
biztonság rétegeinek és rétegeinek hozzáadásakor. De nincs mentség arra, hogy ne szánjunk időt a
biztonságos kapcsolatok beállítására és karbantartására.

Ha a láthatóság megengedi, minden olyan e-mail útvonalat, amely nem tűnik biztonságosnak vagy veszélyeztetettnek, alapos vizsgálatnak kell alávetni. És ezzel együtt örüljetek a biztonságosabb internetért folytatott vizsgálódásnak. Egészségünkre!

*** This is a Security Bloggers Network syndicated blog from Hashed Out by The SSL Store™ szerzője Ross Thomas. Olvassa el az eredeti bejegyzést a következő címen: https://www.thesslstore.com/blog/encryption-and-email-servers/