X509-as certificate-ek abúzálása

Tegyük fel, hogy korszerű rendszeremben SSL/TLS-t is akarok, meg olyat is akarok, hogy a szolgáltatásokat ide-oda tologatom fizikai és virtuális gépek között, adott esetben terheléselosztókkal súlyosbítva.

Namostan a certificate DNS-nevek és IP-címek véges halmazára szól, ami ütközni látszik az előző feltétellel.

Esetleg szólhatna a certificate egy szolgáltatás-névre, pl 'UrsaMaior-WS', és a kliens feladata a default ellenőrzést felülbírálni.

A curl nevű komponensnél a --resolve opcióval lehet ilyesmit bűvészkedni: 

curl --resolve UrsaMaior-WS:someport:someip https://UrsaMaior-WS:someport/

Itt a someport, someip értéke változó, futási paraméter.

Ha ez így működni látszik, akkor már csak az összes többi kliens van hátra, pl wget, SoapUI, JAX-WS, stb.

Szerk: Illetve végső esetben a kliensoldali /etc/hosts vagy ~/.hostaliases fájl haxolása is megoldás lehet....

Szerk: Rávezető kérdés: TLS-kliens-certificate-et hogyan szoktunk csinálni: IP-címre szóljon, vagy hostnévre (DNS)?

Szerk: javax.net.ssl.hostnameVerifier-t sikerült tákolni, csak még azt az eszközkészletet keresem, amivel egy java.security.cert.Certificate-ből ki lehet emelni a mezőket.. nyilván naqyon kézenfekvő lesz az egész -- utólag

Szerk: a getSubjectX500Principal-ból kicsit mesterkélt a 'CN' kibányászása, de a getSubjectAlternativeNames elég barátságos.

( asm v | 2019. 04. 02., k – 11:55 )

A loadbalanceren a VIP legyen fix, arra mutasson egy FQDN. Ez az FQDN legyen a certben.
Ha a hatterben uj IP cimre migralod a szolgaltatast, akkor csak a loadbalanceren kell lekovetni a valtozast.

( dap | 2019. 04. 02., k – 12:08 )

Ha erre van szükséged, akkor szerintem valamit nem úgy használsz ahogy az a nagykönyv szerint tanácsos lenne.

( p2pking | 2019. 04. 02., k – 12:45 )

Kerem a megfejtest!

Imadom ezeket az onszopato idoolo dolgokat olvasni amiket bemutatsz.
Istentelenul nagy hakolas lehet ott. Az erdekelne, hogy melyik bank ? :D

Vagy telko... :) Az a másik terület, ahol notóriusan DNS-mentes infrastruktúrát akar szinte mindenki üzemeltetni. IPv6-tal különösen kellemes.
Továbbá rendszeres feature request, hogy legyen az alkalmazásban "insecure mód" (TLS legyen, de cert ellenőrzés kikapcsolva), és "fél-insecure mód" (cert ellenőrzés van, de subject name validálás nincs).
---
Régóta vágyok én, az androidok mezonkincsére már!

( kadlec | 2019. 04. 02., k – 13:23 )

A kliens a cert ellenőrzésekor semmilyen DNS ellenőrzést nem végez. Nem old fel nevet. Nem old fel IP címet. Nem ellenőrzi a reverse feloldást.

A kliens dolga annyi, hogy a megszólított szolgáltatás ("UrsaMaior-WS") által visszaadott cert vagy a szolgáltatás nevére legyen kiállítva ("UrsaMaior-WS"), vagy az szerepeljen a subjectAltName kiterjesztésben.

Ebből következően bármilyen IP címmel/hostnévvel rendelkező szerveren futtathatod az UrsaMaior-WS-t, csak a kliens találja meg a szervert (itt kell a DNS) és a szerver a megfelelő certet adja vissza. (A subjectAltName-be tehetsz IP címet és akkor kliensből IP címmel hivatkozhatsz a szolgáltatásra.)

> ... csak a kliens találja meg a szervert (itt kell a DNS)

A DNS-t (vagy /etc/hosts fájlt) szívesen kihagynám a történetből, de egyébként igazad van, ez a topik a kliens konfigurálásáról szól: hogyan mondom meg pl. a JAX-WS-nek, hogy a 10.11.12.13-ra connectáljon, de a certificate-ben CN/SAN=UrsaMaior-WS-t ellenőrizzen.

Miért van az, hogy máshova kell konnektálni, mint ahova a cert szól?
Az az információ, hogy hova csatlakozom, és azt, ahova csatlakozom, hogyan verifikálom, az párban jár.
Hiszen pont ez lenne a TLS-nek az egyik lényege - azonosítod azt a felet, akivel kommunikálsz.
Mint a valóságban: a Belügyminisztérium mindenkinek ad egy tanúsítványt arról, hogy ő kicsoda (ez a személyi igazolványod), és ezt felhasználhatja a személy azonosításra.
Nagyon para lenne, ha két személynek is ugyanaz lenne a személyi igazolványa.
Hasonlóan, nagyon para, ha több, egymástól teljesen független gépnek ugyanaz lenne az SSL certificate-je.

Több megoldás létezik:
- Ha a géphalmazod fix, akkor Subject Alternative Name-t használsz, oda fel tudsz venni több elemet is, a kliensek ezt értelmezik
- Ha a géphalmazod nem fix, akkor máshol terminálod az SSL-t: ott, azon a proxy-n, aki dinamikusan eldönti, hogy kihez kell csatlakozni.

Az elsőt talán már írtam is: várhatóan betanított munkás üzemeltetők, vagy éppen szoftverek fogják ide-oda dobálni a szolgáltatásokat fizikai és virtuális gépek között, tehát kb. 10.*.*.*-ra szóló tanusítványt kellene kiállítanom. [Off: oké, igen, én sem hiszem, hogy az előbb vázolt dolog a valóságban működhetne, de a haladásnak nem szabad útjába állni.]

A másodikat már ajánlották a kollégák; ha nem használunk SSL-t, akkor tényleg nem lesznek certificate-es problémák.

Szerk: de kiindulhatunk a SZIG-es hasonlatodból: ugyebár a SZIG-je egy személynek van, nem pedig egy lakásnak; tehát ha én történetesen Szlovákiában vagyok, akkor is érvényes a SZIG-em. Valahogy így néz ki az a modell, amit én itt vizsgálok: certificate-je nem egy készüléknek, hanem egy szolgáltatásnak lesz (Ursa Maior Web Service), amely szolgáltatás hol az egyik készüléken fut, hol a másikon

Viszont a TCP kapcsolat az géphez szól, nem pedig a szolgálatáshoz (kivéve persze, ha virtual IP-vel dolgozol virtualizálst hálózaton, de az jelenleg szerintem neked túl nagy ugrás lenne a sok legacy szarral, amivel szopsz).

Azaz a te hasonlatoddal élve, nézzük a postát.
Te feladsz egy levelet, ahol megadsz egy címet (IP címet) meg egy szolgáltatást (TCP portot). Hitelesítés (TLS) nélül a levelet nem egy adott személynek küldöd el, senki nem fogja ellenőrizni, hogy tényeg az bontja ki a levelet, akinek szól. A postás kiviszi az adott címre és kész, a postás nem fogja nézni, hogy ki veszi át és ki bontja ki a levelet.

Viszont ha "csak a címzett veheti át" típusú levelet küldesz (ez a TLS), akkor a postás meg fog győződni arról, hogy azon a címre, ahova ő kézbesítette a levelet, tényleg a címzett lakik - kimegy, és a címzettnek be kell mutatnia a tanúsítványát, csak akkor veheti át a levelet.

Sokféleképpen meg lehet oldani a problémádat, sokféleképpen megoldották már, nem tudom, miért keresel mindig egy olyan utat, ami ezektől eltér. Csak saját magadat szopatod vele.

Utolsó hasonlat: hogyan változik a mobilom telefonszáma, amikor egyik cellából a másikba lépek át?

Segítek: nem kell megváltozzon, mert ez egy olyan technikai részlet, ami sem a hívót, sem a hívottat nem érdekli, ezzel törődjön egy alsóbb réteg, lehetőleg transzparensen; a hívónak az fontos, hogy kivel beszél, nem pedig az, hogy hol tartózkodik az a személy, akivel beszél.

Mint ahogyan az SSL-t sem érdekli, hogy milyen routereken keresztül ment a TCP csomag, amíg a célhoz elért. Viszont a hívás konkrétan egy eszközhöz route-olódik.
Amit fel kell fogni: a TLS az a TLS kapcsolatot (ami viszont konkrét kapcsolat két TCP végpont között) titkosítja, hitelesíti, nem pedig egy absztrakt üzenetváltást.

Csinálhatnád azt, hogy magában az üzenetben helyezed el a hitelesítési és titkosítási információt (például titkosított, aláírt XML-t küldesz), ekkor minden egyes üzenetről tök mindegy, hova megy, alkalmazásszinten döntöd el, hogy valid-e. És ekkor tök mindegy, melyik végpont kapja el.

Azt kell végiggondolnod, hogy nálad melyik legyen az "alsóbb réteg", ami elfedi a szolgáltatás mozgását. A kliensnek valahogy el kell találnia a mozgó szolgáltatáshoz, ez a probléma független a cert ellenőrzéstől.

1. Legyen az IP cím konstans. Ez esetben a certet az IP subject altname-re írod alá, nincs DNS, nincs hosts file. A kliensbe a szerver IP-t konfigurálod be.
1.a Amikor a szolgáltatás mozog, akkor az IP cím is megy vele együtt. Ez viszonylag triviálisan adott, ha a szolgáltatás VM-ben van és a VM migrálódik ide-oda.
1.b Ha a szolgáltatás mozog a VM-ek között, mert pl failoverelni kell, akkor kell egy kijelölt virtual IP, és a pillanatnyilag aktív node mindig magára rántja alias IP-nek.
1.c Vagy legyen egy dedikált load balancer (mondjuk haproxy, bár ma már nem trendy mert túl jól működik), ami monitorozza a backend URL-eket, és amelyiket élőnek látja odaküldi a forgalmat. A kliens csak az LB-vel beszél, a kliens-oldali TLS-t az LB végződteti. A backend service fele lehet ízlés szerint plain http vagy másik TLS, a kliens azt már nem látja.

2. Legyen az FQDN konstans. Ez esetben a certet DNS subject altname-re írod alá. A kliens mindig csak FQDN név alapján csatlakozik.
2.a A DNS szerver tudja (valamilyen módon update-elve van), ha a szolgáltatás IP-t vált.

3. Az FQDN nem konstans, de van egy közös domain végződés, ami mindegyikre egyforma. Hogy a kliensbe milyen endpointot állítasz be, az 'beyond the scope'.
3.a Aláírsz egy certet wildcard DNS bejegyzésre: *.ursamajor.service.example.tld. Ez minden gep1.ursamaior.service.example.tld, gep2.ursamaior.service.example.tld, ... cimre valid lesz.

4. Semmi nem konstans. A klienst mindig át kell konfiguralni az új endpointra.
4.a Csinálsz egy CA-t (ez amúgy sem rossz ötlet, a fenti esetekben sem - a self-signed server certek trustolása különféle kliensekben nem univerzálisan megoldott kérdés). A CA certet konfigolod be a kliens truststore-ba. Az összes hely, ahol a szolgáltatás felbukkanhat kap egy-egy dedikált server certet, mindenki a saját címére aláírva.

Szerintem ezek közül a lehetőségek közül kell lennie legalább egynek, ami a környezetedben használható.
---
Régóta vágyok én, az androidok mezonkincsére már!

Szolgáltatáshoz rendelünk fix IP-t, ahhoz csinálunk DNS bejegyzést. Nem kell így semmi hókamóka se a DNS-ben, se a certnél.

Saját CA: Na ezzel nagyon csúnyán meg lehet szívni, ha valaki nem ért hozzá. Saját CA nélkül is meg tudod oldani a truststore beállítását és a cert validációt.

Igen, ez a lehetőség az első pont. Én is első helyre ezt venném.

Saját CA: sajnos mi többször belefutottunk, hogy self-signed server cert-et nem minden alkalmazás tud trustolni. Java-nál biztosan bele kell piszkálni az SSLConnectionSocketFactory implementációba. Sőt ha jól emlékszem a RHEL system truststore-ja is csak a CA certeket kezeli. (Illetve persze felveheted a CA certek közé a BasicConstraint=isCA nélküli certeket is, csak kb minden kliens ignorálni fogja. Talán wget kivétel.) [citation needed, pár évvel ezelőtt próbáltam alposan utánamenni, nem gyűjtöttem ki a linkeket, de elég általános konszenzus volt, hogy nincs általános megoldás self-signed server certek közvetlen trustolására]
---
Régóta vágyok én, az androidok mezonkincsére már!

Saját CA: Igen, ez eggyel jobb, mint a self-signed cert. Viszont magadra veszel olyan problémákat, amelyeket nem szeretnél: a saját CA tanúsítványainak terjesztése és elfogadtatása, kulcsok menedzselése, tanúsítványok megújítása folyamatainak kidolgozása, megvalósítása stb.
Ezért még nagy cégek is inkább odamennek egy bizalmi szolgáltatóhoz és tőlük veszik igénybe a szolgáltatást.

De ne hagyd ki a DNS-t :)

A kliensek a szolgáltatáshoz a DNS név alapján csatlakoznak és ez is van a tanúsítványban.

Aztán csinálsz ACL-t +view-t a DNS szerveredben (unbound, bind9 tudja ezt), hogy ha 1.2.3.4-ről jön a kérés akkor az x.y.z.v névhez az 5.6.7.8 IP tartozik , und so weiter.
Vagy akár dinamikusan updatelheted a DNS szerveredet tetszőleges feltétel szerint scriptből stb.

Ahogy már írták, másik megközelítés, hogy egy (vagy többet virtuális IP-vel) központi terheléselosztót használsz. Erre felveszed az összes Certet ami neked kell, és az összes DNS is ide mutat.

Aztán a terheléselosztóval akár SNI, akár kliens IP, akár Host header, akár "szinte" bármi más alapon oda dobálod a kapcsolatokat ahová akarod.

Azt egyébként nem írod, hogy le lehet terminálni az SSL-t egy terheléselosztón (és esetlegesen visszacsomagolni), vagy mindenképpen az appnak kell.

A Haproxy nevű app mindent meg tud oldani neked, akár SSL terminálás nélkül is tud SNI alapú app routingot:

https://www.haproxy.com/blog/enhanced-ssl-load-balancing-with-server-na…

Sorry ezt nem értem sajnos. Pont azt írtam, hogy nem kell feltétlenül kicsomagolni a HTTPS-t, mehet end-to-end. Vagy ha az LB kicsomagolja, hogy belelásson pl a HTTP headerekbe és tudjon döntést hozni ezek alapján, utána vissza tudja csomagolni az SSL-t és az app felé megint HTTPS lesz.

> Vagy ha az LB kicsomagolja, hogy belelásson pl a HTTP headerekbe és tudjon döntést hozni ezek alapján, utána vissza tudja csomagolni az SSL-t és az app felé megint HTTPS lesz.

Igen, de ő maga garantálja, hogy ő nem jelent biztonsági kockázatot... Rosszhiszemű emberek ezt a dolgot hívják 'MitM attack'-nak.

Így van. Az SSL termináló LB-k már csak ilyenek :) Ha end-to-end SSL kell akkor kevesebb infó alapján tudsz app routingot csinálni. De pl a source ip, clienthello(SNI), serverhello alapján igen..

Addig egyébként amíg el nem terjed ez a TLS 1.3 extension :)

https://tools.ietf.org/html/draft-ietf-tls-esni-03

( uid_4263 v | 2019. 04. 02., k – 17:04 )

A JAX-WS nem egy konkrét kliens vagy alkalmazás, csak egy valag specifikáció.

--
arch,ubuntu,windows,android
zbook/elitebook/rpi3/motog4_athene

Off: Hát ez igaz, az implementációk pedig egymással érintőlegesen kompatibilisak... Ha esetleg nem vagyok jövőbelátó, tehát programozáskor még nem tudom, hogy melyik implementáció lesz érvényben futáskor, akkor akár ilyeneket is alkothatok: 


javax.xml.ws.BindingProvider bd= (javax.xml.ws.BindingProvider)port;
java.util.Map<String,Object> ctxt = bd.getRequestContext();
ctxt.put ("com.sun.xml.internal.ws.connect.timeout", 10*1000);
ctxt.put ("com.sun.xml.ws.connect.timeout", 10*1000);

A két utolsó sor egyike az integrált verzióhoz jó, a másik a standalone-hoz. De az Oracle ezt is megoldja: kivezeti az integrált verziót.

Kieg: de most jut eszembe, hogy az egyik terméknél meg a JBoss nevű megkönnyítő komponenst használtuk, az valami ilyesmit szeret: 


ctxt.put ("javax.xml.ws.client.connectionTimeout", ""+10*1000);

( n.balazs v | 2019. 04. 02., k – 21:07 )

Biztos bennem van a hiba, de nem igazán értem a problémád.
1. A szolgáltatások minden gond nélkül mozoghatnak gépek között.
2. A szolgáltatáshoz MINDIG szolgáltatás IP-t rendelünk, amihez csinálunk rendes DNS bejegyzést is. Így bármikor megtaláljuk a hálózatban magát a szolgáltatást.
3. (a) Az SSL/TLS terminálódhat LB-n (mások is írták), de (b) terminálódhat a szolgáltatást nyújtó gépen is (önszivatás a köbön nagy rendszernél).
4. MINDENHOL a DNS neveket használjuk. Nem szivatjuk se magunkat, se másokat. A tanúsítványban ez a DNS név mindenképp szerepel.

Ha LB-n terminálódik az SSL/TLS, akkor a szolgáltatás mozgatásakor úgyis bele kell nyúlni az LB-be. A tanúsítvánnyal viszont semmit sem kell bűvészkedni. 3/b esetnél meg semmit se kell piszkálni. Simán mozog a szolgáltatás és kész.

A kliensen a szerver certjét minden gond nélkül validálhatod. Ha nagy biztonságot akarsz, akkor csinálj 2 irányú SSL-t. Legfeljebb utálni fognak a hálózatosok, de nagyoooon. :)

Szóval mit is szeretnél? Hogy oldaná meg a problémát a kliens oldalon a /etc/hosts fájl haxolása?

( dap | 2019. 04. 03., sze – 10:03 )

> TLS-kliens-certificate-et hogyan szoktunk csinálni: IP-címre szóljon, vagy hostnévre (DNS)?

Loginra. A logint pedig korlátozhatod IP-re vagy domainre, de az már nem a TLS dolga.

Akkor ne TLS-t használj (ami mondom, TCP kapcsolatot hitelesít), hanem használj üzenet-hitelesítést.
Ha már a JAX_WS-t említetted, akkor a Web Service szabványok között ott van a WS-Security.
Az egész üzenet titkosított lehet, digitálisan aláírt lehet, a kliens meg a szerver meg lefocizza a dolgot.
És ekkor TCP szinten nem is kell semmilyen titkosítást végezned, megoldja az alkalmazás.

Mondom, lehet, hogy neked nem kell TLS.
Kliens certificate-t nem IP-címre és nem is hostnévre csinálj konkrétan. A kliens CN-je a klienst azonosító érték. Ez lehet DNS név, lehet IP cím, lehet e-mail cím, más azonosító is lehet. A lényeg, hogy egyértelműen azonosítsa a klienst.

Szóval akár az is rendjén van, hogy a kliens akárhol lehet, feltéve, hogy nála van a privátkulcs + CA által aláírt certificate, és a szervernek tetszik a CN mező tartalma?

Az viszont nincs rendjén, hogy a szerver akárhol lehet, feltéve, hogy nála van a privátkulcs + CA által aláírt certificate, és a kliensnek tetszik a CN mező tartalma?

De, rendjén van - raw TLS esetén.
Csak éppen a HTTPS protokollban elő van írva, hogy miként kell megvalósítani a tanúsítvány ellenőrzését, mely mezőket kell kötelezően figyelembe venni a kliens és a server identity ellenőrzésekor.

https://tools.ietf.org/html/rfc2818#page-4
Az egész 3.1 arról szól, hogy amint HTTP-t TLS felett forgalmaznak, akkor a szervert miként ellenőrzik.
A 3.2 pedig a kliens ellenőrzési szabályairól.
Ez kötelező előírás a HTTPS számára, ezen nem tudsz változtatni.

És emiatt lehet, hogy neked nem HTTP over TLS kell, hanem üzenetszintű titkosítás, vagy más, TLS-jellegű dolog. Például SSH-n is proxyzhatod a dolgokat. De használhatsz s_tunnelt is.

Igazságod vagyon, ennek a történetnek nem sok köze van a hagyományos User – UserAgent – Server történethez, itt programok beszélnek programokkal (ha trendi-bendi lennék, azt mondanám, hogy mikroszervizek).

Ezek a programok persze lehetnek mind cimbi haverok, akik egy gépteremben futkorásznak, nem is kell közöttük az a nagy éberség, hisz' csak nincs köztük olyan, aki üres perceit hálózatfigyeléssel tölti ki...

De azért tegyük fel, hogy meg akarom teremteni az SSL lehetőségét, valahogy úgy, hogy a CA-nak ne kelljen 'mindenre jó' tanusítványt kiállítania, de ne is kelljen minden programáthelyezésnél új cert-et generálni.

De ezt tökéletesen megoljda neked a DNS. DNS nevet ugyebár akármennyit felvehetsz egy IP-hez.
Fogod, és azon kívül, hogy a gépeknek infrastruktúra alapján lenne neve (pl. melyik datacenter, melyik rack stb), az egyes szolgáltatások is kaphatnak DNS bejegyzést egy privát DNS zónában (.corp például), vagy subdomainként.
És a tanúsítványokban ezek a domain nevek szerepelnek, minden szolgáltatáshoz 1 név. A szolgáltatások egymásra pedig szépen névvel hivatkoznak.
IP címet csak és kizárólag a DNS konfigurácóba írsz, a szolgáltatások egymásról nevük alapján tudnak csak, a DNS meg megoldja, hogy az a szolgáltatás hol is van, ha épp költözteted. Költöztetéskor csak a DNS bejegyzést frissíted, a tanúsítványok érvényesek maradnak, mégis tudod költöztetni a szolgáltatást.