Re: lug-bg: TLS + MTA (malko teoria + praktika)

[vlk@email.domain.hidden (Vesselin Kolev)]

<em class="quotelev1">>Vapreki che moje da se izpolzva, tai kato certificate ne se izdava za
<em class="quotelev1">>usluga, a za host - triabva uslugite da sa na edin i sasht hostname!
<em class="quotelev1">>T.e. ako imenata sa www.something.com i mail.something.com, a
<em class="quotelev1">>certificate e izdaden za www.something.com, to email clientite shte
<em class="quotelev1">>se jalvat, che certificate ne e validen za mail.something.com.

<p><p>Pravilno, taka e...

Kato dopylnenie samo. Kogato TLS se poddyrzha ot strana na MTA ima dve
principno razlichni deistvia po udostoveriavaneto: server i client.

Edin MTA e client,kogato predava edno syobshtenie kym drug MTA.
Edin MTA e server, kogato priema elektronen poshtenski potok za
lokalna ili posledvashta obrabotka.

V zavisimost ot tova ima DVA vida udostoverivane na MTA serverite
v ramkite na TLS. Pri udostoverivaneto na nivo "client", MTA, koito e
v tazi rolia, proveriava certficate-a na servera, s koito ustanoviava
sesia. Sled kato se ubedi, che vsichko e nared, priema da se svyrzhe
s drugia MTA. Imenno tuk se proveriava i imeto na hosta, koeto e
opisano v certificate-a.V syshtoto vreme obache i drugia MTA (koito e
server ot gledna tochka na vryzkata) proveriava certificate-a na
clienta. Tuk e nuzhno da se napravi edno vazhno utochnenie. Kogato
servera proveriava certificate-a na clienta, toi ne izvyrshva proverka
na imeto na hosta (obratnoto bi znachelo da se obvyrzhe systemata ot
sertificati s in-addr.arpa ierarhichnoto tyrsene). Ako tova
ne be taka, to ne bi syshtestuval virtualen hosting.

Pri udostoverivaneto na nivo "server", klientyt proveriava i imeto
na host na servera, kym koito se svyrzva, a ne samo validnostta
na certificate-a.

Edin MTA mozhe da operira s dva certificate-a. Ediniat toi mozhe
da izpolzva, kogato e v roliata na server, a drugia, kogato e v
roliata na client. Serverskia certificate e obvyrzan s imeto na hosta,
no tova ne e zadylzhitelno da e taka za clientskia certificate (tova
mezhdu drugoto stana iasno i malko po-gore pri obiasniavane na
principa na deistvie v dvete situacii).

Ako edin client se opitva da se svyrzhe sys server i pri proverka na
certificate-a stane iasno, che certificatyt na servera e nevaliden,
vypreki, che nosi v poleto za ime imeto na hosta, to iavno ima
sluchai na IP izmama.

============= *** ===============
Configuration
============= *** ===============

<p>V m4 prototipa na sendmail.cf, faila sendmail.mc se pravi slednoto
razgranichenie za certificatite izpolzvani za client i za server
configuraciata na MTA

dnl
dnl Tova sa redovete, koito zadavat certificatite i key za servera
define(`confSERVER_CERT',`/usr/share/ssl/certs/host.cert')dnl
define(`confSERVER_KEY',`/usr/share/ssl/certs/host.key')dnl
dnl
dnl a tova sa tezi, koito zadavat configuraciata na clienta
define(`confCLIENT_CERT',`/usr/share/ssl/certs/mta.cert')dnl
define(`confCLIENT_KEY',`/usr/share/ssl/certs/mta.key')dnl

<p>============= *** ===============
Log
============= *** ===============

Eto edna ilustracia na tova, kakvi zapisi v zhurnalnia file na
Sendmail se praviat za vsiaka TLS sesia.

Eto kak MTA priema TLS sesia ot domashno baziran klient, obtabotva ia i ia
izprashta kym drug server:

Mar 19 23:22:04 lcpe sendmail[10459]: NOQUEUE: connect from
Mandrake.nat-lan.lcpe.pip.digsys.bg [193.68.191.198]
Mar 19 23:22:04 lcpe sendmail[10459]: STARTTLS=server,
relay=Mandrake.nat-lan.lcpe.pip.digsys.bg [193.68.191.198], version=TLSv1/SSLv3,
verify=OK, cipher=EXP1024-RC4-SHA, bits=128/56
Mar 19 23:22:04 lcpe sendmail[10459]: STARTTLS=server,
cert-subject=/C=BG/ST=Sofia/L=Sofia/O=LCPE,+20University+20of+20Sofia/OU=LCPE+20Staff/CN=Vesselin+20Kolev
/Email=vlk_at_lcpe.uni-sofia.bg,
cert-issuer=/C=BG/ST=Sofia/L=Sofia/O=LCPE,+20University+20of+20Sofia/OU=Net+20Division/CN=Vesselin+20Kolev/Email=vlk_at_lcpe.uni-sofia.bg

#
# STARTTLS=server ukazva na tova, che Sendmail uchastva v TLS sesia kato server
# sled cipher e opianieto na izpolzvania kodirash algorithm
# cert-subject opisva poletata na X.509 certificate ot strana na clienta
# cert-issuer opisva poletata na X.509 certificate na izdatelia na certificate na
clienta.
# Nai-otgore stoi "verify=OK", koeto znachi, che certificate-a na clienta e
potvyrden kato validen
# Interesnoto tuk e, che clientyt ne e MTA, a e nai-obiknoven Netscape Messenger
4.78 nastroen
# da izpolzva PKCS#12
#
Mar 19 23:22:04 lcpe sendmail[10459]: h2JLLpAh010459:
from=<vlk_at_lcpe.uni-sofia.bg>, size=331, class=0, nrcpts=1,
msgid=<3E78EC44.2A4B2636_at_lcpe.uni-sofia.bg>, proto=ESMTP, daemon=MTA,
relay=Mandrake.nat-lan.lcpe.pip.digsys.bg [193.68.191.198]
Mar 19 23:22:04 lcpe sendmail[10461]: h2JLLpAh010459: SMTP outgoing connect on
eth-out.backbone-1.lcpe.uni-sofia.bg
Mar 19 23:22:04 lcpe sendmail[10461]: STARTTLS=client, init=1
Mar 19 23:22:04 lcpe sendmail[10461]: STARTTLS=client, start=ok
Mar 19 23:22:04 lcpe sendmail[10461]: STARTTLS=client,
relay=ns.lcpe.uni-sofia.bg., version=TLSv1/SSLv3, verify=OK,
cipher=EDH-RSA-DES-CBC3-SHA, bits=168/168
Mar 19 23:22:04 lcpe sendmail[10461]: STARTTLS=client,
cert-subject=/C=BG/ST=Sofia/L=Sofia/O=LCPE,+20University+20of+20Sofia/OU=Server+20Division/CN=eth-in.backbone-1.lcpe.uni-sofia.bg/Email=vlk_at_l,
cert-issuer=/C=BG/ST=Sofia/L=Sofia/O=LCPE,+20University+20of+20Sofia/OU=Net+20Division/CN=Vesselin+20Kolev/Email=vlk_at_lcpe.uni-sofia.bg

Mar 19 23:22:06 lcpe sendmail[10461]: h2JLLpAh010459: to=<vlk_at_lcpe.uni-sofia.bg>,
delay=00:00:02, xdelay=00:00:00, mailer=esmtp, pri=30325,
relay=ns.lcpe.uni-sofia.bg. [62.44.103.1], dsn=2.0.0, stat=Sent (h2JMaPsx031783
Message accepted for delivery)
Mar 19 23:22:04 lcpe sendmail[10461]: h2JLLpAh010459: done; delay=00:00:02,
ntries=1
#
# Tuk veche MTA smenia roliata si ot server na client i prepredava poluchenoto ot
clienta pismo na drug MTA
# cert-subject tuk opisva poletata na X.509 certificate-a na servera, kym koito
se predava maila
# cert-issuer opisva poletata na X.509 certificate-a na izdatelia na certificate
opisan v cert-subject
# verify=OK znachi uspeshno udostoveriavane
#

Eto kak drugia server priema poshtata i ia dostavia localno:
(Tylkuvaniata sa podobni ne tezi po-gore, napravete gi za uprazhnenie)

Mar 19 23:22:05 lcpe sendmail[31783]: NOQUEUE: connect from
eth-out.backbone-1.lcpe.uni-sofia.bg [62.44.103.2]
Mar 19 23:33:05 lcpe sendmail[31783]: STARTTLS=server,
relay=eth-out.backbone-1.lcpe.uni-sofia.bg [62.44.103.2], version=TLSv1/SSLv3,
verify=OK, cipher=EDH-RSA-DES-CBC3-SHA, bits=168/168
Mar 19 23:33:05 lcpe sendmail[31783]: STARTTLS=server,
cert-subject=/C=BG/ST=Sofia/L=Sofia/O=LCPE,+20University+20of+20Sofia/OU=Server+20Division/CN=lcpe.pip.digsys.bg/Email=vlk_at_lcpe.uni-sofia.bg,
cert-issuer=/C=BG/ST=Sofia/L=Sofia/O=LCPE,+20University+20of+20Sofia/OU=Net+20Division/CN=Vesselin+20Kolev/Email=vlk_at_lcpe.uni-sofia.bg

Mar 19 23:33:05 lcpe sendmail[31783]: h2JMaPsx031783:
from=<vlk_at_lcpe.uni-sofia.bg>, size=601, class=0, nrcpts=1,
msgid=<3E78EC44.2A4B2636_at_lcpe.uni-sofia.bg>, proto=ESMTP, daemon=MTA,
relay=eth-out.backbone-1.lcpe.uni-sofia.bg [62.44.103.2]
Mar 19 23:33:05 lcpe sendmail[31784]: h2JMaPsx031783: alias
<vlk_at_lcpe.uni-sofia.bg> => vlk
Mar 19 23:33:05 lcpe sendmail[31784]: h2JMaPsx031783: to=<vlk_at_lcpe.uni-sofia.bg>,
ctladdr=<vlk_at_lcpe.uni-sofia.bg> (1002/100), delay=00:00:00, xdelay=00:00:00,
mailer=local, pri=30918, dsn=2.0.0, stat=Sent
Mar 19 23:33:06 lcpe sendmail[31784]: h2JMaPsx031783: done; delay=00:00:00,
ntries=1

  Pozdravi
    Vesselin Kolev

============================================================================
A mail-list of Linux Users Group - Bulgaria (bulgarian linuxers).
http://www.linux-bulgaria.org - Hosted by Internet Group Ltd. - Stara Zagora
To unsubscribe: http://www.linux-bulgaria.org/public/mail_list.html
============================================================================