Pordid, krüpteerimine ja sisselogimine

Moodul 1: Kuidas e-post töötab · Lugemisaeg: 10 minutit

Õpieesmärk: pärast seda tundi oskad iga meilipordi kohta öelda, milleks see on, selgitada STARTTLS ja otsese TLS erinevust ning selgitada sertifikaaditeadet või tagasilükatud sisselogimist.

Põhimõisted: port 25, 587, 465, 993, 995, 143, 110, STARTTLS, otsene TLS (implicit TLS, RFC 8314), sertifikaat, serverinimi, SMTP-autentimine (SMTP AUTH), avatud relee (open relay), pordi 25 blokeerimine, rakenduse parool, OAuth

Port on uks

Serveril on üks IP-aadress, aga palju uksi. Iga teenus kuulab oma pordil, mis on number. Sinu veebibrauser koputab pordile 443, meiliprogramm pordile 993, et meili lugeda, ja pordile 587 või 465, et meili saata. Kui valid vale ukse, siis keegi ei vasta, või vastab keegi, kes räägib teist keelt. See tekitab ebamääraseid veateateid nagu "ei saa ühendust luua" või "server ei vasta".

Meilipordid ülevaates:

Miks mitte lihtsalt pordile 25 saata?

Varem seadistasid meiliprogrammis pordi 25. See on kahel põhjusel minevik.

Esiteks: pordil 25 võtab meiliserver vastu meile kõigilt, oma domeenide jaoks. Sisse ei logita. Serverit, mis pordil 25 edastab ka meile kõigilt teistele domeenidele, nimetatakse avatud releeks (open relay), ja seda kasutavad rämpspostisaatjad ära juba mõne tunni jooksul. Seepärast on oma meili saatmine kogu maailma jaoks eraldi teenuseks muudetud: submission pordil 587 (ja 465), kus sa logid alati enne sisse.

Teiseks: paljud internetiteenuse pakkujad blokeerivad väljuva liikluse pordile 25 koduühendustest. Nii ei saa nakatunud arvuti elutoas saata rämpsposti otse meiliserveritesse. Sinu jaoks tähendab see: kui proovid meiliprogrammist pordi 25 kaudu saata, siis see ei pruugi kodus toimida, aga tööl toimib, või vastupidi.

Pea meeles: meiliprogrammid saadavad pordi 587 või 465 kaudu, alati sisse logides. Port 25 on serverite vaheliseks suhtluseks.

STARTTLS või otsene TLS?

Meiliühenduse krüpteerimiseks on kaks võimalust.

Otsene TLS (implicit TLS): ühendus on krüpteeritud esimesest baidist alates, nagu veebisait https-iga. See toimub portidel 465, 993 ja 995.

STARTTLS: ühendus algab krüpteerimata. Server ütleb "ma oskan krüpteerida", klient vastab STARTTLS, ja sellest hetkest on kõik krüpteeritud. See toimub pordil 587 (ja portidel 25, 143 ja 110).

Turvalisuse jaoks ei ole suurt vahet, kuni sinu programm nõuab STARTTLSi kohustuslikult. STARTTLSi risk peitub alguses: keegi, kes on sinu ja serveri vahel, saab eemaldada pakkumise "ma oskan krüpteerida". Programm, mis siis vaikselt jätkab krüpteerimata, saadab su parooli loetaval kujul üle liini. Seepärast soovitab RFC 8314 (2018) meiliprogrammidele otsest TLS-i (465, 993, 995) STARTTLSi asemel. Praktikas on 587 koos STARTTLSiga ja 465 koos SSL/TLS-iga mõlemad head, kui seadistad oma programmis krüpteerimise valikule "kohustuslik", mitte "kui saadaval".

Levinud viga on vale kombinatsioon: port 587 koos "SSL/TLS"-iga, või port 465 koos "STARTTLS"-iga. Siis ootab programm midagi muud, kui server pakub, ja ühendus jääb kinni või ebaõnnestub. Pea meeles paarid: 587 + STARTTLS ja 465 + SSL/TLS. Programmid nimetavad otsest TLS-i mõnikord "SSL", "SSL/TLS" või "TLS"; STARTTLSi nimetatakse mõnikord ka "TLS". Vaata seega porti.

Sertifikaat ja serverinimi

Iga krüpteeritud ühenduse puhul näitab server sertifikaati, mis tõendab, et ta on see, kes ta väidab end olevat. Sinu meiliprogramm kontrollib kahte asja: kas sertifikaadi on väljastanud usaldusväärne osapool ja kas see on veel kehtiv, ning kas sertifikaadis on olemas nimi, mille sina sisestasid serverina?

Viimasega läheb kõige sagedamini valesti. Kui sisestad mail.example.com, aga sertifikaadis on ainult server12.hosting.example, saad teate nagu "Serveri identiteeti ei saa kinnitada" või "Sihtmärgi põhinimi on vale". Ühendus ise on sel juhul küll krüpteeritud, aga sinu programm ei saa olla kindel, et ta räägib õige serveriga.

Ära sellist teadet lihtsalt ära klõpsa. Lahendus on sisestada serverinimi, mis on sertifikaadis olemas (vaata tund 2.1). Jagatud serveri puhul on see tihti serveri enda nimi, mille su teenusepakkuja annab. Veel üks tuntud põhjus: viirusetõrje, mis krüpteeritud meili "skaneerib" ja paneb selleks vahele oma sertifikaadi. Teates on siis "väljastaja" kohal skanneri nimi.

Sisselogimine saatmisel

Portidel 587 ja 465 pead enne sisse logima, kui server on nõus su meili välja saatma. Seda nimetatakse SMTP-autentimiseks (SMTP AUTH). Sinu programmis kannab see valik nime "väljuv server nõuab autentimist", "sisselogimine on nõutav" või "autentimine: tavaline parool". Tavaliselt kasutad sama kasutajanime ja parooli, mis IMAPi jaoks.

Kui autentimine on väljas, või väljuva serveri kasutajanimi on jäetud tühjaks, saad meili lugeda, aga mitte saata. Server vastab siis millegagi nagu 530 5.7.0 Authentication required või 554 5.7.1 Relay access denied. See on kõige levinum põhjus olukorras, kus "vastuvõtmine toimib, saatmine mitte".

Teine liik tagasilükkamisest: 535 5.7.8 Authentication failed. Siis ei klapi kasutajanime ja parooli kombinatsioon. Pane tähele: pärast mitut ebaõnnestunud katset blokeerivad paljud serverid IP-aadressi, kust need katsed tulevad, kaitseks parooli äraarvamise vastu. Vana telefon vana parooliga võib nii blokeerida kogu sinu kontori.

Rakenduse paroolid ja OAuth

Suurte teenusepakkujate, nagu Google ja Microsoft, juures töötab sisselogimine ainult tavalise parooliga eraldiseisvas meiliprogrammis üha harvemini. Nemad kasutavad OAuthi: sinu programm suunab su teenusepakkuja sisselogimislehele, sa logid seal sisse (vajadusel kahesammulise autentimisega), ja programm saab parooli asemel võtme. Programmid, mis seda ei toeta, saavad mõnikord rakenduse parooli: eraldi pika parooli, mis kehtib ainult selle ühe programmi jaoks ja mille saad eraldi tühistada.

Tavalises hostinguettevõtte mailboksis logid tavaliselt sisse mailboksi enda parooliga. See muudab tugeva ja unikaalse parooli eriti oluliseks (tund 3.4).

Praktikas: mailboksi seadistused

WebOké mailboksi puhul on seadistused järgmised: IMAP 993 koos SSL/TLS-iga, POP3 995 koos SSL/TLS-iga, saatmine 587 koos STARTTLSiga või 465 koos SSL/TLS-iga, autentimine sees, kasutades oma täielikku e-posti aadressi ja mailboksi parooli. Teistel teenusepakkujatel töötab see sarnaselt: pordid on peaaegu kõikjal samad, ainult serverinimi erineb. Millist serverinime valida, näed tunnist 2.1.

Kokkuvõte

• Meiliprogrammid saadavad pordi 587 (STARTTLS) või 465 (otsene TLS) kaudu, alati sisse logides. Port 25 on serverite vaheliseks suhtluseks ning kodus tihti blokeeritud.
• Lugemine toimub pordi 993 (IMAP) või 995 (POP3) kaudu, mõlemad otsese TLS-iga.
• Kombineeri õigesti: 587 + STARTTLS, 465 + SSL/TLS. Sea krüpteerimine kohustuslikuks.
• Sertifikaaditeade tähendab enamasti, et sisestatud serverinimi ei ole sertifikaadis olemas. Teate kõrvaleklõpsamine ei ole lahendus.
• "Lugemine toimib, saatmine mitte" on peaaegu alati seotud sellega, et väljuva serveri autentimine on väljas või tühi.

Test

Ülesanne

Ülesanne Z1.4: Poordid ja serveri sertifikaat. Sisesta sissetuleva ja väljuva serveri nimi, mida kasutad oma mailboksi jaoks (kui sul ei ole oma mailboksi, kasuta imap.gmail.com ja smtp.gmail.com). Vali pordi 993 (sissetulev) ning portide 465 ja 587 (väljuv) jaoks see, mida ootad: otsene TLS, STARTTLS või ei ole kättesaadav, ning märgi, kas sa arvad, et nimi on sertifikaadis olemas. Programm loob ise ühenduse kolme pordiga ja paneb tulemuse sinu vastuste kõrvale.

Loe edasi

Nende artiklite sammud kehtivad WebOké paneelide kohta; teistel teenusepakkujatel töötab see sarnaselt.

• DirectAdmin juhend 8.1: Kõik seadistused ühes kohas: serverid, pordid ja turvalisus
• DirectAdmin juhend 8.8: Saatmine või vastuvõtmine ei õnnestu: nii lahendad selle
• Sertifikaadi veateade e-posti allalaadimisel
• E-kirja saatmine ei õnnestu (vastuvõtmine töötab)
• RFC 8314 (otsene TLS meiliprogrammide jaoks), RFC 6409 (submission), RFC 3207 (STARTTLS), RFC 4954 (SMTP AUTH)