Fórumok
Sziasztok!
Jelenleg igy nez ki az MQTT brokerem configja:
#webui
- "traefik.enable=true"
- "traefik.http.routers.emqx-rohu.entrypoints=websecure"
- "traefik.http.routers.emqx-rohu.tls=true"
- "traefik.http.routers.emqx-rohu.rule=Host(`emqx-rohu.server.com`)"
- "traefik.http.services.emqx-rohu.loadbalancer.server.port=18083"
#mqtt
- "traefik.tcp.routers.emqx-mqtt_unencrypted.service=emqx-mqtt_unencrypted"
- "traefik.tcp.routers.emqx-mqtt_unencrypted.entrypoints=mqtt"
- "traefik.tcp.routers.emqx-mqtt_unencrypted.rule=HostSNI(`*`)"
- "traefik.tcp.services.emqx-mqtt_unencrypted.loadbalancer.server.port=1883"
#mqtt-ssl
- "traefik.tcp.routers.emqx-mqtt.service=emqx-mqtt"
- "traefik.tcp.routers.emqx-mqtt.entrypoints=mqtt-ssl"
- "traefik.tcp.routers.emqx-mqtt.tls=true"
- "traefik.tcp.routers.emqx-mqtt.tls.passthrough=true"
- "traefik.tcp.routers.emqx-mqtt.rule=HostSNI(`emqx-rohu.server.com`)"
- "traefik.tcp.services.emqx-mqtt.loadbalancer.server.port=8883"
Amit szeretnek, hogy az unencrypted port is csak egy domain-en lehessen elerheto, ne az osszesen. (mint a titkositott) ha viszont ida beirom ugyanazt a domain-t vagy egy masikat akkor hibat dob. A doku szerint TLS nelkuli tcp-vel ezt nem lehet megcsinalni mert nincsenek meg (nyilvan) azok az informaciok, amik kellenenek es http eseten megvannak. Maskepp esetleg meg lehetne ezt oldani?
Hozzászólások
Kérdések:
Traefiket nem vágom, de sima tcp kapcsolatban, ahogy a doksi is irja, elméleti nehézségek vannak 🙂 másik ip, vagy a server konfigban vmi (már ha az mqttben van vmi host info, szerintem nincs). Egyébként mi lenne az igazi cél?
Amit fontebb irtam, csak a emqx-rohu.server.com-on legyen elerheto a 1883 es a 8883, a xy-rohu.server.com on ne.
Ezt nem tudod megoldani, mivel az MQTT nem tartalmaz ilyen leíró infót.
A HTTP-nél van ugye a Host header, amivel ez kezelhető (így működnek a virtuális szerverek), de ha az emqx-rohu.server.com és az xy-rohu.server.com valójában ugyanarra az IP címre mutat, akkor nem fog menni.
Gondolj bele, az egész mélyén a hosztok között IP, TCP/UDP/SCTP van, a DNS nevek csak abban segítenek, hogy nevet adjanak az IP címeknek.
Ha egy protokollban nincs arra vonatkozóan támogatás, hogy az adott IP címek között felépített TCP csatornán belül a szolgáltatást multiplexeld és megkülönböztess név szerint hosztokat, akkor ez nem fog menni.
Gondolj bele, legyen mondjuk az example.com és example.net a két DNS név, és mindkettő az 1.2.3.4 IP címre mutat. Amikor a szerveralkalmazás fogadja a bejövő socketet, ő nem tudja, hogy a kliensoldal az example.com névfeloldása után csatlakozott az 1.2.3.4-es IP címhez, vagy az example.net névfeloldása után. De még az is lehet, hogy kihagyta a névfeloldást, mert tudja az example.com IP címét közvetlenül.
Ezt csak a protokollban tudod leírni, hogy kihez akartál csatlakozni - amennyiben a protokoll fel van arra készítve, hogy valamiféle címzést definiáljon, és ennek még köze sem kell legyen a DNS nevekhez. A HTTP Host headerbe is írhatok ám olyan nevet, ami totál más domainre szól. Például az 1.2.3.4-es hostra is küldhetek olyan HTTP fejlécet, aminek a Host mezőjében google.com van, senki nem akadályoz meg ebben.
És az MQTT nem tud ilyet, a szabvány ezt nem tartalmazza. A HTTP tud ilyet, a Host headerrel. A TLS tud ilyet, a certificate-ben lévő nevekkel. Az MQTT nem tud ilyet protokollszinten. Eleve nem tudja megkülönböztetni logikai szinten a csatlakozó feletekt.
De ha meg tudna is, a traefik nem tud belenézni az MQTT csomagba, mert nem tudja értelmezni azt, a Traefik a TCP streamben csak a HTTP-t beszéli, más protokollt, ami TCP felett menne, nem tud. És plugin sincs hozzá a Traefik pluginjai között.
Köszi, hogy legépelted, így nekem már nem kell. :)
Kicsi pontosítás, csak az utókornak: A TLS nem a certificateben levő nevekkel tudja ez, hanem az SNI-ben levővel (ugye pont azért kell az SNI, hogy már a hostnak megfelelő certificatet lehessen kiszolgálni).
Tegyük hozzá még, hogy a TLS bontás nélküli SNI routingnak /fingerprintingnek/whatevernek meg vannak számlálva a napjai a TLS1.3 + ESNI vagy újabban az ECH miatt.
https://blog.cloudflare.com/encrypted-client-hello/
Hát, szerintem elég lassan számolódnak azok a napok :) Ugye ESNI már azért elég régen vad, de szopizni kell hozzá a DNSsel, ennek a letolása a világ torkán már a levelezés körül (DMARC) is elég nyögve nyelősen ment, pedig ott sokkal több a benefit üzemeltető oldalról: a spam sokkal több usert zavar, mint ez a homályos privacy dolog, ráadásul ott nem vette át a leveled az akárki, itt max akkor lesz valami kényszer, ha a böngészők hangos csipogásba kezdenek (amire persze azért volt már példa).
Egyébként cuki az ECH, a "ha nincs meg, akkor majd akkor elárulom, hogy ez a publikus kulcsom, cserkészbecsszó", még meg is értem, hogy a valódi trustba végül is nem szól bele, de azért, hát szóval na. Meg hát ez a fallback domain name, szóval kissé pofozza a szart szerintem, így ránézésre.
ECH is enabled in Firefox by default since version 119.
Google Chrome announced their intent (Sep 11, 2023) to switch on ECH by default from v117 onwards.
Szóval ja már most is ki kell kapcsolni a böngészőben (menedzselt környezetben) ha nem akarod különben a CDN-ek nagy része felé ECH-val fogsz menni.
Nyilván ügyes middleboxokkal lehet downgradelni forward TLS bontás esetén (enterprise körnxezetben) (bár az összes ilyen zero trust valaminek az lenne a lényege , hogy a middleboxokat torkonszúrja) Ha meg reverse proxyzni/lb-zni akarsz akkor úgyis bármit meg tudsz csinálni TLS bontással.
https://labs.ripe.net/author/kathleen_moriarty/security-control-changes…
Az egy dolog, hogy default on, de ez csak a "tud működni". Én arról beszéltem, hogy én nem látom, hogy ez kisebb helyeken rohamosan elterjedne. Nincs olyan kényszer, mint mondjuk a cert transparencynél vagy a dmarcnál, hogy muszáj vagy csinálni, különben szar lesz a userednek.
De igen, a nagy content providerek várható, hogy csinálják majd, és az nyilván nagyon sok mindent jelent.
en ugy emlekszem, az mqtt protokolban nincs hostnev. itt a traefik sima tcp proxykent mukodik
A vegtelen ciklus is vegeter egyszer, csak kelloen eros hardver kell hozza!
Egy kis olvasgatás után az a konklúzió, amit te is írtál.
Traefik oldalon AllowIpList opcióval lehet szűkíteni a kört.
https://doc.traefik.io/traefik/middlewares/tcp/ipallowlist/
Alkalmazás (MQTT) oldalon kellene szűrni auth-al, kliens IP-vel.
Mqtt oldalon természetesen van Auth csak szebb lett volna ha csak ott hallgat, ahol kell neki.
de megbarátkozom vele. Lehet nem is kell sokáig , az app fejlesztőjet aki miatt be kellett kapcsolnom a plan mqtt talán meggyőzom hogy csinálja meg a tlst használó verziót is
Ott hallgat, ahol kell neki. Mert a TCP portok nem tudnak semmit arról, hogy van egy adatbázis valahol a világban, ahol domain neveket képezünk le IP címekre. A TCP portok IP címekre kötődnek, nem DNS nevekre. A DNS ebből a szempontból olyan, mintha nem is létezne (eleve nem is létezett még akkor, amikor kitalálták az IP-t és a TCP-t, csak hosts file volt).
Hiszen a Traefikod hallgat azon az interfészen és porton, függetlenül attól, hogy az adott IP-hez te milyen nevet társítasz. Ha azt akarnád, hogy ne hallgasson rajta, akkor azt a Traefiknek kéne megmondanod. De nem véletlenül van elválasztva a Traefikban az, hogy milyen portokon hallgat, meg az, hogy a porton beeső csomaggal mit kezd, melyik szolgáltatáshoz route-olja.
Ha csak a szebb lett volna érzés miatt kell, akkor szerintem nyugodtan engedd el, kutya mindegy igazából, semmit nem adna hozzá szűrés (mire a TCP csatlakozásig jutsz, már csak IP van, ha nem belső kliens, fogalmad se lesz, hogy mi alapján talált oda). Ha nagyon akarod, akkor tényleg adj neki egy külön IPt, és arra csak azt a domaint oldd fel, de ha egyebet nem tervezel ezzel, akkor csak fölösleges bonyolítás valójában, mint a menő verdák alatt a neonfény +15 mentális lóerőért :)
Koszi mindenkinek, elengedtem a temat :)