Mitä sinun on tiedettävä SSL/TLS:n käyttämisestä sähköpostipalvelimesi muodostamien yhteyksien salaamiseen

Kun minua lähestyttiin
tämän blogikirjoituksen aiheella, suostuin mielelläni. Tässä parafraasi
siitä, miten se meni:

”Voisitko
kirjoittaa postauksen TLS:n merkityksestä sähköpostipalvelimissa?” Patrick kysyi.

”Toki”, sanoin.

Huh, se oli hullu
keskustelu elää uudelleen! Kuin pyörremyrsky!

Sitten aloin miettiä asiaa vähän aikaa. Onko oikeasti olemassa sähköpostipalvelimia, jotka eivät käytä salausta kauttakulussa? En tarkoita päästä päähän -salausta, kuten olemme käsitelleet aiemmin (S/MIME, PGP jne.). Tarkoitan palvelimelta palvelimelle tai kaikkea siltä väliltä tapahtuvaa salausta tietojen suojaamiseksi matkan varrella.

Tänä päivänä kukaan ei varmasti jättäisi saapuvaa ja lähtevää postiaan selväkielisenä kulkemaan ties mitä reittiä, jotta se voitaisiin siepata ja käyttää hyväksi. Monet ihmiset käyttävät sähköpostipalveluja, eivätkä ne mitenkään sulje transit-salausta pois palvelustaan. Tietomurrot maksavat heille miljoonia
oikeudenkäyntejä ja liiketoiminnan menetyksiä ja häpeää……Hmmmm…..

Palasin Patrickille
kysymyksellä.

”Onko meillä tilastoja
tai tietoa sähköpostipalvelimista, jotka eivät käytä salausta?”. Arvaukseni on, että se olisi
vähäistä. Toisin sanoen, mikä sai sinut kysymään minulta tästä artikkelista?””

Patrick vastasi: ”Minulla
ei oikeastaan ole. Ajattelin, että se olisi hyvä aihe ottaen huomioon sähköpostin
tärkeyden ja kaikki tietoturvan edellyttämät näkökohdat.”

OK. Tuossa on järkeä. Todennäköisesti on joitakin sähköpostipalvelimia, jotka eivät käytä sitä lainkaan, vaikka epäilemättä paljon suurempi osa saattaa käyttää vanhentuneita protokollia tai vanhentuneita varmenteita ja saattaa vain tarvita päivitystä.

Tässä artikkelissa käydään
läpi, missä mennään sähköpostin ja kauttakulkusalauksen kanssa, jotta voit
toimia optimaalisella turvallisuustasolla, joka on saatavilla.

Salaus sähköpostipalvelimissa

Tässä vaiheessa meillä on luultavasti yleinen käsitys siitä, miten TLS toimii, mutta tehdäänpä yhteenveto siltä varalta, että tämä on sinulle uutta.

Henkilö A haluaa lähettää
turvallista viestintää Ihminen B. Henkilöllä A ja ihmisellä B on ennalta laadittu
varmenne. Henkilö A käyttää varmennetta tiedon salaamiseen ja lähettää
salatun tiedon ihmiselle B. Tieto on lukukelvotonta, kunnes ihminen
B käyttää varmennetta salatun tiedon purkamiseen.

Jos ihminen B haluaa
vastata henkilölle A salatulla tiedolla, ihminen B käyttää
varmentetta tiedon salaamiseen ja henkilö A käyttää varmentetta viestin
purkuun.

Tämä on yleisesti ottaen tapa, jolla
salaus/purkaminen toimii. Korvaa nyt tässä esimerkissä luetellut henkilöt
palvelimilla ja muilla vastaavilla yhteyksillä. Sama konsepti.

Nyt jos ihminen B haluaa vastata takaisin henkilölle A salatulla tiedolla, niin ihminen B käyttää juuri luotua symmetristä avainta ja he voivat nyt sekä salata ja lähettää että vastaanottaa ja purkaa tietoja toisilleen.

Tämä on yleisesti ottaen tapa, jolla salaus/purkaminen SSL/TLS:llä toimii. Korvaa nyt tässä esimerkissä luetellut henkilöt palvelimilla ja muilla vastaavilla yhteyksillä. Sama konsepti. Näin TLS toimii sähköpostin kanssa, joka on hieman erilainen kuin HTTPS-yhteyden helpottaminen, koska sähköposti käyttää eri protokollia. Mutta on silti joitakin selviä yhtäläisyyksiä:

• Kättely tapahtuu
• Tunnistautuminen tapahtuu (tosin molemmat osapuolet tunnistautuvat tässä yhteydessä)
• Session avaimia käytetään sähköpostiviestien kulun välittämiseen.

Ebb and (Mail) Flow

Tämän
”ymmärtämään miksi” -artikkelin seuraava vaihe on ”ymmärtämään miten” -osa.

Lyhyesti sanottuna sähköpostiohjelma lähettää sähköpostin lähtevälle palvelimelle. Lähtevä palvelin tekee DNS-haun, joka perustuu kohdesähköpostin verkkotunnukseen, ja kyseisen DNS:n MX-tietue määrittää, mille palvelimelle sähköposti lähetetään, ja mahdollisesti kyseinen palvelin määrittää, onko se lähetettävä edelleen, kunnes se saapuu määränpään postilaatikon sähköpostin toimitusagenttiin (Mail Delivery Agent, MDA).

Ei riitä, että
luotetaan DNS:n MX-tietueisiin, mikä on kokonaan toinen luottamuskysymys, vaan SMTP
(lähtevän postin, MTA:n jne.) palvelimen ja saapuvan postin ( POP3:n, IMAP:n,
Exchange:n kautta) on pystyttävä tunnistamaan toisensa ja niillä on oltava oikeat avaimet, jotta ne voivat
viestittää toistensa kanssa. Ja reitistä riippuen sähköpostipalvelimella voi olla muitakin
kuin vain yhden hyppyyhteyden päässä olevia sähköpostipalvelimia. Reitin varrella voi olla sähköpostinvaihtajia, välityspalvelimia
ja muuta. Jokaisen siirtymän (pitäisi) vaatia
salattua yhteyttä. Usein näin onkin. Joskus ei. Käyttäjät haluaisivat
että arkaluonteiset tiedot salattaisiin matkan varrella. Päästä-päähän-salaus
auttaa varmistamaan, että koko matkalla on jonkinlainen salaus, mutta
turvakerrokset ovat aina parempia.

Respect Thy Securi-Tie

Tiedoksi,
Securi-Tie ei ole oikea sana. Keksin tuon sanan vain, koska se rimmaa. Se on
leikki sanasta turvallisuus.

Taaksepäin
edellisestä osiosta, meidän pitäisi puhua tietoturva-asetuksista, jotka, vaikka
sitä asetettaisiinkin asiakkaan puolelta, itse asiassa antaisivat
postipalvelimen puolelle joitakin ohjeita
turvallisuuteen liittyviä tarkoituksia varten.

Kun konfiguroidaan
sähköpostiohjelmaa (Outlook, Thunderbird jne.), oletuksena on salaamaton
konfiguraatio. Mutta, kuten tämän artikkelin tarkoitus on, haluamme yleensä käyttää
salattua vaihtoehtoa. Tavallaan se ei ole täysin asiakkaan päätettävissä: se
riippuu siitä, mitä palvelinpuoli pystyy tukemaan. Jos oletetaan, että saapuva
ja lähtevä palvelimesi tukevat salausta, miksi et tukisi? Jos tilaat
pihvin ravintolassa ja sinulle tarjotaan sisäfileetä tai Kobe (wagyu) ribeye
palaa samaan hintaan, miksi et tilaisi parempilaatuista palaa?

Jos siis haluat käyttää
TLS/SSL:ää sähköpostissasi (tämä koskee kauttakulkuosuutta eikä päästä päähän
S/MIME-osuutta, jota käsitellään muissa blogikirjoituksissa), ota se käyttöön. Käytä portteja 465
tai 587 SMTP:lle (’jäsen, lähtevä posti) ja 993 (IMAP) tai 995 (POP3)
lähtevälle liikenteelle.

Sähköpostipalvelimien keskuudessa käytetään edelleen
mielenkiintoista salausprotokollaa. Siinä
on hyvät ja huonot puolensa kuten useimmissa asioissa. Viime kädessä sanoisin, että
sen aikomukset ovat hyvät, mutta reaalimaailman sovellus ei ole aivan niin ihanteellinen kuin se
voisi olla. Hyvät naiset ja herrat, tuo protokolla on STARTTLS.

STARTTLS on tietoturva
protokolla, joka on periaatteessa SSL/TLS. Yksinkertaisesti sanottuna STARTTLS ottaa
olemassa olevan tavallisen tekstin ja siten turvattoman yhteyden ja yrittää muuntaa
sen suojatuksi yhteydeksi TLS:n (tai SSL:n) avulla. Niinpä
STARTTLS:n ja SSL/TLS:n turvallisuustaso ei itse asiassa eroa toisistaan. Jos kaikki on asetettu oikein, ne
kumpikin salaa tiedot TLS:n (tai SSL:n) avulla.

Pääasiallinen ero perustuu
yhteyden tilaan ja/tai viestinnän aloittamiseen. STARTTLS
ei takaa salattua viestintää. Se tarkoittaa periaatteessa, että jos
yhteys on salaamaton ja pystyt siihen, tee siitä suojattu
yhteys. Jos yhteyden solmu (todennäköisesti palvelin) ei pysty muuttamaan
yhteyttä salatuksi yhteydeksi, voi olla asiakkaan päätettävissä
päättää, miten sitä käsitellään.

Vaikkakin käytin
karsintatermiä STARTTLS ”hyödyllisenä”, sitä voidaan pitää vähemmän turvallisena
kuin SSL/TLS:n valitsemista. Normaali SSL/TLS-valinta on periaatteessa: ”Käytä
salausta tai paskat”. STARTTLS sanoo: ”Jos voisit, tee niin. Jos
ei, voimme jatkaa muiden ohjeiden perusteella.”

Tässä on joitain lopullisia lausuntoja

Usein itsestäänselvyyksiä on todettava ja ehkä
ylikorostettava. Joten tässä se on, khmm: Käytä salausta. Etenkin sellaisessa asiassa, joka
on niin tärkeä, niin ratkaiseva ja joka on integroitu näennäisesti suurimpaan osaan
jokaista organisaatiorakennetta, joka voi kuljettaa ratkaisevaa tai rikkovaa tietoa. Siihen ei
tarvitse nähdä paljon vaivaa. Käyttäkää sekä päästä päähän – että siirron aikaista
salausta. Kaksi on parempi kuin yksi.

Jos joku kokee, että ylimääräinen vaivannäkö sähköpostin
palvelimen asentamiseksi salatuksi verrattuna salaamattomaan ei ole sen arvoista, niin tämä joku ei ole
sen arvoinen. Tämä on yksinkertaisesti ilmiselvän liioittelua. S/MIME:n kaltainen päästä-päähän-salaus vaatii
mielenkiintoisemman lähestymistavan, mutta sekin on sen arvoista, kun lisätään kerroksia ja kerroksia
turvallisuutta. Mutta ei ole mitään tekosyytä olla käyttämättä aikaa
suojattujen linkkien luomiseen ja ylläpitoon.

Kun näkyvyys sallii, kaikki sähköpostipolut, jotka eivät näytä turvallisilta tai vaarantuneilta, tulisi pitää silmällä. Ja sen myötä, olkaa tyytyväisiä tutkiessanne turvallisemman internetin puolesta. Kippis!

*** This is a Security Bloggers Network syndicated blog from Hashed Out by The SSL Store™ authored by Ross Thomas. Lue alkuperäinen viesti osoitteessa: https://www.thesslstore.com/blog/encryption-and-email-servers/