Šifrované hovory ZRTP a Odorik

tls,srtp,zrtp a bezpečnostní potíže VoIP
Odpovědět
kapetr
Příspěvky: 224
Registrován: stř 12. říj 2011 7:14:21

Re: Šifrované hovory ZRTP a Odorik

Příspěvek od kapetr »

Ano, ten CN mishmash je IMHO nepřípustný - znemožňuje ověření, neboť nelze poznat (?), zda je serverový certifikát podepsán sám sebou nebo tím CA certifikátem.

Ale bez ohledu na to - zásadní problém v SFLPhone vidím v tom, že to projde (což by nemělo). Čili - i kdybych zadal správné certifikáty na správná místa, tak co z toho ?! Co by se změnilo, když to projde stejně vždycky ? Nic.

Čili - buď je ještě někde třeba nastavit vyžadování správného ověření (nevím kde), nebo je v programu chyba a nastavování těchto položek je na ....
:?:

Zkoušel jsem také známější Linphone, tam ověřování naopak neprošlo - a mně se kontrolu nepodařilo správně nastavit. Viz http://forum.odorik.cz/viewtopic.php?f= ... =20#p25811

Zdravím.

EDIT: Že by ?

Kód: Vybrat vše

$ openssl s_client -connect sip.odorik.cz:5061
CONNECTED(00000003)
depth=0 C = CZ, ST = czech, L = brno, O = odorik.cz, OU = odorik.cz, CN = odorik.cz
verify error:num=20:unable to get local issuer certificate
verify return:1
depth=0 C = CZ, ST = czech, L = brno, O = odorik.cz, OU = odorik.cz, CN = odorik.cz
verify error:num=21:unable to verify the first certificate
verify return:1
---
Certificate chain
 0 s:/C=CZ/ST=czech/L=brno/O=odorik.cz/OU=odorik.cz/CN=odorik.cz
   i:/C=CZ/ST=czech/L=brno/O=odorik.cz/OU=odorik.cz/CN=odorik.cz
...
    Start Time: 1435696946
    Timeout   : 300 (sec)
    Verify return code: 21 (unable to verify the first certificate)
selže, ale

Kód: Vybrat vše

hugo@zly-hugo:~$ openssl s_client -CAfile /tmp/1.pem -connect sip.odorik.cz:5061
CONNECTED(00000003)
depth=1 C = CZ, ST = czech, L = brno, O = odorik.cz, OU = odorik.cz, CN = odorik.cz
verify return:1
depth=0 C = CZ, ST = czech, L = brno, O = odorik.cz, OU = odorik.cz, CN = odorik.cz
verify return:1
---
Certificate chain
 0 s:/C=CZ/ST=czech/L=brno/O=odorik.cz/OU=odorik.cz/CN=odorik.cz
   i:/C=CZ/ST=czech/L=brno/O=odorik.cz/OU=odorik.cz/CN=odorik.cz
...
    Start Time: 1435696893
    Timeout   : 300 (sec)
    Verify return code: 0 (ok)
projde ! Pozn.: ten /tmp/1.pem je ten z http://www.odorik.cz/w/srtp

Možná, že selfsigned certifikáty, které přitom nejsou CA, mají nějaký atribut, podle kterého se to pozná.
Tudíž ten serverový NENÍ selfsigned. A možná tedy není nepřípustné, aby 2 certifikáty v chain-u měly shodné CN, nevím. Ale stejně si myslím, že to opravdu není dobrý nápad. Je to přinejmenším matoucí nejen pro mě, ale třeba i pro ověřovací SW.
Uživatelský avatar
kovik
Příspěvky: 505
Registrován: stř 16. lis 2011 11:07:52

Re: Šifrované hovory ZRTP a Odorik

Příspěvek od kovik »

Dobry den,
zrejme budu muset vygenerovat novy.
Proverim,opravim a dam vedet.
Diky
alfi
Příspěvky: 716
Registrován: čtv 03. led 2013 15:31:10

Re: Šifrované hovory ZRTP a Odorik

Příspěvek od alfi »

kapetr píše: Možná, že selfsigned certifikáty, které přitom nejsou CA, mají nějaký atribut, podle kterého se to pozná.
Tudíž ten serverový NENÍ selfsigned. A možná tedy není nepřípustné, aby 2 certifikáty v chain-u měly shodné CN, nevím. Ale stejně si myslím, že to opravdu není dobrý nápad. Je to přinejmenším matoucí nejen pro mě, ale třeba i pro ověřovací SW.
Ty certifikáty jsou dva, nemají stejné klíče, ani přesně stejné datum (liší se vteřiny či minuty vytvoření), jeden má v sobě, že je CA, druhý že není (a bude tou CA podepsaný) :-)
Ověřovacímu SW by mělo být CN pro CA celkem jedno, stejně tam jsou vždycky (pro stroj) bláboly. U serveru naopak musí odpovídat DNS názvu serveru, tj. pokud se připojuju na sip.odorik.cz, potom CN=odorik.cz stejně neodpovídá (a nebo musí mít alternate CN, což tenhle stejně nemá a nebo by CN muselo být "wildcard" *.odorik.cz, ale tam zase bude otázka, jak si s tím poradí různí SIP klienti)
kapetr
Příspěvky: 224
Registrován: stř 12. říj 2011 7:14:21

Re: Šifrované hovory ZRTP a Odorik

Příspěvek od kapetr »

alfi píše: Ty certifikáty jsou dva, nemají stejné klíče, ani přesně stejné datum (liší se vteřiny či minuty vytvoření), jeden má v sobě, že je CA, druhý že není (a bude tou CA podepsaný) :-)
Ověřovacímu SW by mělo být CN pro CA celkem jedno, stejně tam jsou vždycky (pro stroj) bláboly.
To že se ty 2 liší bylo od počátku jasné, a že je jeden CA certifikátem bylo také uvedeno.

Dle https://www.openssl.org/docs/apps/verify.html verifikační proces v první kroku pracuje s těmi "bláboly" (výběr potencionálních podpisových certifikátů, jejichž Subject == Issuer ověřovaného certifikátu). Čili tomu SW ta jména tak úplně jedno nejsou (nebo přinejmenším nemusí být), byť samozřejmě následně pracuje s
X509v3 Subject Key Identifier a
X509v3 Authority Key Identifier
[z nich je ostatně poznat, že u serverové certifikátu nejde o podepsaný sebou samým, ale podepsaný tím CA]

Ohledně toho CN_serveru je ještě otázkou, zda ono "CN mishmash" je pouze důsledkem toho, že
1 - CN_serveru != DNS_name_serveru (docela častá chyba), nebo vadí i to, že
2 - Subject_serveru == Issuer == Subject_CA (kteréžto obsahují CN serveru resp. CA)

Ad 2 - pro OpenSSL před 0.9.6 by ověřování mohlo selhat, pokud by bylo mezi CA vícero certifikátu se stejným jménem (Subject) a ten první vzatý nebyl zrovna ten správný. Čili je to potencionálně implementačně závislé ("matoucí i pro SW") a proto by ta jména certifikátů neměla být raději stejná.
Uživatelský avatar
kovik
Příspěvky: 505
Registrován: stř 16. lis 2011 11:07:52

Re: Šifrované hovory ZRTP a Odorik

Příspěvek od kovik »

Dobry den,
vytvoril a nasadil jsem novy certifikat, verejny klic certifikacni autority jsem aktualizoval na http://www.odorik.cz/w/srtp?&#verejny_k ... i_autority.

Testoval jsem pomoci pjsua z pjsip.org
pjsua --registrar=sips:sip.odorik.cz --id=sips:XXXXXX@sip.odorik.cz --realm=* --username=XXXXXX --password=XXXXXXXXX --use-tls --use-srtp=2 --tls-ca-file=/root/odorik_ca.pem --tls-verify-server

Version : v3
Serial : 01
Subject : sip.odorik.cz
/C=CZ/ST=Czech Republic/O=miniTEL/OU=odorik.cz/CN=sip.odorik.cz/emailAddress=kontakt@odorik.cz
Issuer : odorik.cz
/CN=odorik.cz/ST=Czech Republic/C=CZ/emailAddress=kontakt@odorik.cz/O=odorik.cz
Valid from : Thu 2015-07-02 12:21:57.000 GMT
Valid to : Mon 2035-03-19 11:21:57.000 GMT
subjectAltName extension
DNS : sip.odorik.cz
IP : 81.31.45.51

00:02:33.233 pjsua_app.c TLS cert verification result of [sip.odorik.cz:5061] : OK
00:02:33.234 tlsc0x2595fb8 TLS transport 192.168.2.100:47550 is connected to sip.odorik.cz:5061
kapetr
Příspěvky: 224
Registrován: stř 12. říj 2011 7:14:21

Re: Šifrované hovory ZRTP a Odorik

Příspěvek od kapetr »

Certifikáty jsem se kdysi zabýval podrobněji, byť přiznávám - ne do velkých detailů.

U těchto nových certifikátů si nejsem jist, zda nevadí chybějící rozšíření X509v3 Subject Key Identifier a
X509v3 Authority Key Identifier, které jsou důležité pro vytvoření řetězce.

rfc3280 https://www.ietf.org/rfc/rfc3280.txt v odstavci 4.2.1.2 Subject Key Identifier uvádí:
To facilitate certification path construction, this extension MUST
appear in all conforming CA certificates, that is, all certificates
including the basic constraints extension (section 4.2.1.10) where
the value of cA is TRUE. The value of the subject key identifier
MUST be the value placed in the key identifier field of the Authority
Key Identifier extension (section 4.2.1.1) of certificates issued by
the subject of this certificate.
Nicméně v OpenSSL mi validace prošla:

Kód: Vybrat vše

openssl s_client -connect sip.odorik.cz:5061 -CAfile /tmp/Odorik_CA-new.pem
Ještě zkusím Linphone ...

... ANO, prošlo OK - tedy i s nastavením:
verify_server_certs=1
verify_server_cn=1
Uživatelský avatar
kovik
Příspěvky: 505
Registrován: stř 16. lis 2011 11:07:52

Re: Šifrované hovory ZRTP a Odorik

Příspěvek od kovik »

Dobry den,
diky za otestovani.
Cert. jsem vytvoril +- podle navodu u TLS modulu.
kapetr
Příspěvky: 224
Registrován: stř 12. říj 2011 7:14:21

Re: Šifrované hovory ZRTP a Odorik

Příspěvek od kapetr »

To já/my děkujeme za úpravu :-)
Jak jsem si všiml, je CA cert jen s roční platností, tak snad jen až ho za rok budete updatovat, tak by možná nezaškodilo doplnit ty extejšny, aby to bylo úplně perfetto.
Zdravím.

EDIT: jen mě napadlo, jestli změna CA certifikátu nezpůsobí potíže těm, kteří ten původní mají naimportován. Vzhledem k tomu, že jste stejně zachovali pro CA jméno CN=odorik.cz, tak by možná stačilo ponechat starý CA certifikát a jen vygenerovat nový server certifikát s CN=sip.odorik.cz. Tak by validace procházela korektně a současně by to nepostihlo nikoho - snad krom těch, kdo mají natvrdo nastaven jako trusted přímo starý serverový certifikát.
kapetr
Příspěvky: 224
Registrován: stř 12. říj 2011 7:14:21

Re: Šifrované hovory ZRTP a Odorik

Příspěvek od kapetr »

alfi píše:
Do klienta bych zkusil CA z webu jako "certificate of authority list" (v souboru jich může být i víc) a certifikát ze serveru jako "public endpoint", ale ty popisky taky nejsou úplně jednoznačné, tj. chovat se to může i jinak. Obvykle by mělo stačit zadat CA + common name v serverovém certifikátu = certifikát se potom může v čase měnit, dokud je podepsaný stále stejnou CA a se stejným jménem (např. v případě vyzrazení privátního klíče je třeba hned udělat nový a tisícům klientů se to těžko oznamuje předem)
Poněkud off-topic douška - pro úplnost k tomu SFLPhone & SIPS-TLS, pokud by měl někdo potřebu si to také nastavit:

nakonec jsem se zeptal na fóru SFL a zjistil, že je, věřte, či ne, nutné zaškrtnout volbu "Verify incoming certificates, as a server" - viz ten výše uvedený screenshot.
Usuzuji, že autoři prohodili význam těch checkboxů a tento znamená pravý opak, tedy to co jsem chtěl: jakožto klient (SFL) kontrolovat cert. serveru (Odoriku).
Když je tedy tento zaškrtnut, tak bez zadání certifikátu selže spojení TLS (což bohužel sflphoned indikuje jen jako reg. timeout (nedostupný host)).

A kolega <alfi> to odhadl přesně - ten CA certifikát je třeba dát jako "Certificate of authority list". Autoři zřejmě chtěli říci: "List of CA certs", tedy soubor obsahující certifikát CA (issuer), která podepsala serverový certifikát Odoriku.

Jestli "Public endpoint cert. file" je alternativa k zadání CA, kdy se zde zadá natvrdo serverový certifikát jako trusted, tedy bez kontroly vydavatele, nevím - už to nemám sílu zkoušet. Kombinace IMHO nejasných označení položek dialogu v SFL v kombinaci s !E dokumentací mě poněkud zmohla :-/
m142857
Příspěvky: 40
Registrován: čtv 02. čer 2016 11:39:04

Re: Šifrované hovory ZRTP a Odorik

Příspěvek od m142857 »

Zdravím, podařilo se někomu v CSipSimple připojit s ověřením serverového certifikátu?
(trojtečka vravo dole -> Settings -> Network -> Secure transport -> Check Server - Verify server's certificate)
Pokud jen povolím ten TLS transport a volbu Verify server's certificate nezaškrtnu (což je kupodivu výchozí volba), připojím se. (Ale nemůžu si být jist, že jsem třeba nedostal podvrženou DNS odpověď a nepřipojuju se na podvržený SIP server)
Pokud zaškrtnu, nepřipojím se (chybová hláška zní Error while registering - Service Unavailable).

TLS certifikát pro SIPS sip.odorik.cz je bohužel self-signed.

V nastavení je i volba pro příslušný CA certifikát (TLS CA file), ale poněkud nešikovně, je potřeba ručně zadat cestu.
Serverový CA certifikát jsem si stáhnul a předhodil mu ho jako .pem soubor. To nepomohlo. Nepomohlo ani předhození .crt souboru jak v PEM tak DER formátu.

Nepomohla ani instalace CA certifikátu přímo do Android (Marshallow) systému (Settings -> Security -> Credential storage: Install from SD card).
Jsou tam 2 možnosti - jako WiFi certifikát anebo certifikát pro aplikace a VPN. Instalace jako WiFi certifikát samozřejmě nezabere, to je špatně.
Druhá varianta bohužel nezabere taky (a jako bonus mi pak systém vyhrožuje že můžu být sledován.. takže stovkám předinstalovaných certifikátů pocházejících kdoví odkud musím důvěřovat, ale vlastnoručně nainstalovanému certifikátu z ověřeného zdroje ne.. genitální)

Tak si nejsem jistý jestli CSipSimple umí pracovat se systémovými certifikáty, nebo kde případně dělám chybu. Nějaký log aplikace jsem nenašel.

Asi bych se přimlouval při vydání nového certifikátu v srpnu, jestli by bylo možné použít "důvěryhodnou" autoritu, třeba LetsEncrypt.
Odpovědět