En ja er gaan 3 wegen naar Rome, en nee weg 2 en 3 zijn niet even veilig.
En het is belangrijk dat andere gebruikers weten dat weg 3 onveiliger is.
En dat is onderdeel van het antwoord op de vraag van @MiK .
Dat ziet er uit alsof iemand z’n MQTT server niet beveiligd heeft 
1 Like
Zo, moest even wat bijlezen 
Ik blijf het een apart geval vinden, kan erg moeilijk de voordelen benoemen van het ‘aan’ zetten van port-forwarding. Als auth nog steeds via Athom gaat, dan ben ik dus nog steeds ‘afhankelijk’.
Ik snap de gevaren/risico’s van port-forwarding, dus daar focus ik nu even niet op.
Ben tevreden over Homey/Athom hoor, maar als ik de marketing/product info van Pro2023 doorlees, krijg ik twee indrukken:
- Geen afhankelijkheid meer van Athom, want alles lokaal.
- Backups ook lokaal te maken.
1: Als ik het goed begrijp is Athom nog nodig om je auth token te vernieuwen in de app, na verlopen van auth sessie kan je niks meer bedienen via de apps/web (flows blijven wel werken, dat snap ik).
2: Half-half methode, want je moet de homey loskoppelen, aansluiten op computer, enz… ik zou met zo’n statement verwachten dat ik in de settings kan aangeven dat de backups opgeslagen moeten worden naar mijn netwerk ergens, of zelfs bijv. dropbox ofzo.
Nou is bovenstaande geen dealbreaker, maar ik interpreteerde deze marketing statements nogal anders hahaha…
1 Like
Jero, de verbinding van de Homey naar de homey cloud is -uitgaand- daarvoor heb je dus geen portforwarding aan staan en zal een connectie van het internet op jou modem niet aan kunnen kloppen.
Enkel homey cloud kan -terug- verbinden over deze staande connectie.
De route die vervolgens staat, via de homey cloud, kent geen directe proxy vanaf de homey cloud endpoints naar je homey toe.
Daar zit een authenticatie laag voor die stricter is dan de standaard laag die je homey te bieden heeft wanneer deze via portforwarding gekoppeld is.
Het is een beetje vergelijkbaar met de manier waarom partijen als CloudFlare je internet verbinding beveiligen door actief vóór iedere connectie te liggen.
Een Zero Trust structuur.
Waar baseer je dat op? Want het lijkt er mij op dat die verbinding praktisch transparant is.
1 Like
Het gaat om het opbouwen, het initiëren van de TCP/IP verbinding. Als die eenmaal staat, dan is de verbinding transparant. Het opbouwen van de verbinding gaat in één richting, de verbinding zelf is twee richtingen. Zonder portforwarding kan A wel een webpagina opvragen van B, maar niet andersom.
Gezien bovenstaande discussies moet dat misschien nog verder toegelicht worden?
1 Like
Hi Robert,
Wanneer je reverse proxying wil doen kun je dit (afhankelijk van het type proxy server) doen op basis van verschillende ACL’s ( dat zijn een soort “triggers” die het systeem de unieke informatie geven wat te doen met het request).
Standaard kun je die ACL’s op 3 verschillende manieren behandelen:
- Je kunt een specifieke domein naam laten “herkennen” en op die basis een bepaalde backend selecteren. ([mijnid].homey.app)
- Je kunt een specifieke endpoint of onderdeel van de URL pad hiervoor inzetten. (cloud.homey.app/[mijnid])
- Je kunt ook headerdata van een request hier voor inzetten; iedere vrije gewenste parameter biedt daar de mogelijkheid toe. (HomeyId=[mijnid])
Het updaten van een dergelijke gedistribueerde (cloud based) reversed proxy kan een vrij zware aangelegenheid zijn, iets waar een normale reversed proxy zich niet enorm voor leent.
Je komt dan al gauw terecht in of zelfgemaakte LUA scripts achter deze proxy of in plaats van reverse proxying kies je voor een mechaniek zoals Zero Trust waar je connecties middels stitching kan verbinden met elkaar.
Omdat de Homey zelf verbinding maakt naar de Homey Cloud omgeving is het eenvoudiger en minder belastend om actief de calls -na authenticatie- op de staande lijn te stitchen naar de beoogde backend (het principe van Zero trust).
Zaken zoals DDOS aanvallen en brute force inlogmethoden evt. Deep packet inspection zoals SQL injectie etc. kunnen op deze manier goed getackled worden door een partij die daar meer in gespecialiseerd is. (bijv. Amazon / Cloudflare)
Homey zal daarbij ook netjes gebruik kunnen maken van hun eigen domein namen en certificates voor een end-to-end beveiliging van de connectie.
Bovenstaand zal men overigens als nagenoeg transparant ervaren; de session stitching gebeurt op een dusdanig niveau dat dit een stuk sneller is dan bijvoorbeeld de VPN connectie; mede omdat ze de sessie in een soort slaapstand brengen die op ieder moment in tijd weer kan worden ingezet, wat TCP sessie verkeer en herauthenticatie uit de weg gaat.
Mocht je ’t interessant vinden om iets dergelijks voor je NAS of thuisnetwerk in te zetten kun je eens kijken naar technieken als WireGuard, Tailscale, zScaler.
Ook Cloudflare heeft er services voor; volgens mij zelfs gratis voor privé gebruik.
Dat begrijp ik allemaal wel, maar wie zegt dat het zo werkt? Een HTTPS call naar de externe hostname van mijn Homey (https://$CLOUDID.connect.athom.com) wordt geserved door Express, dus een Node.js HTTP(S) server. Dat klinkt niet als een authenticatieserver die ergens “voor” zit.
Bij POST requests staat ook de Homey firmware versie van mijn Homey in de headers. Die kan natuurlijk ergens opgeslagen zijn, maar mijn vermoeden is dat die requests gewoon direct en 1-op-1 worden doorgestuurd naar Homey, en dat Homey waarschijnlijk zelf ook de authenticatie afhandelt.
TLS termination doet Homey zelf, lokaal: Homey downloadt met enige regelmaat Let’s Encrypt certificaten van Athom’s servers voor het homeylocal.com domein, en apps gebruiken A-B-C-D.homey.homeylocal.com als hostname (waarbij die hostname resolved naar IP adres A.B.C.D) in plaats van het (lokale) IP adres. En zo werkt externe toegang ook.
1 Like
Is onderstaan scherm geen autorisatie dan? Die ook gebruikt wordt voor https://$cloudid.connect.athom.com/ ? Dan moet ik dat eens verder uitzoeken.
@robertklep Hoe kom ik zogauw aan mijn CloudId, of is dat mijn Homey id?
1 Like
Voor API calls (waar de apps gebruik van maken) wordt een token gebruikt. De inlogprocedure zorgt ervoor dat dat token aangemaakt wordt en wordt doorgegeven aan Homey, en Homey checkt vervolgens bij API calls of het token nog geldig is. Tenminste, zo denk ik dat het werkt.
Ik weet niet wat je Homey id is 
Maar de cloud id kun je hier vinden: Homey Developer Tools
1 Like
Thanks!
En ben je het wel met me eens dat als er géén portforwarding in je modem is ingesteld, je Homey niet direct vanaf het internet te bereiken is?
1 Like
Goede punten, Robert!
Ik begrijp dat het op deze manier als transparant oogt.
Het heeft mij ook weer wat meer een idee gegeven van de structuur.
Wat je aangeeft klinkt heel aannemelijk maar zal enkel kunnen werken als je port forwarding zou hebben geconfigureerd. De structuur is gevoeliger zijn voor XSS achtige aanvallen en zou ook de Homey van een gebruiker eigenlijk onnodig exposen.
Vanuit security zou ik deze vorm in ieder geval proberen te vermijden.
De staande connectie zal dus de weg naar de Homey bewandelen; via Proxy of Stitching; dat kan ik niet uitsluiten zonder diepgaande scans te doen.
Vanuit een andere hoek; als ik de web app versie van homey bekijk lijkt deze een eigen auth naar de homey omgeving te hebben.
Het aangegeven domein https://[mijnid].connect.athom.com/ heeft een lokale service hier achter draaien en lijkt geen transparante proxy naar je homey thuis.
De eenvoudigste manier om dat aan te tonen is door de site te openen voor je eigen homey en vervolgens de stekker uit je homey te trekken.
Je zal zien dat de site blijft werken.
Wat je aangeeft rond homeylocal werpt voor mij wel een iets ander licht op de zaak, als in Homey gebruikt dit domein denk ik om “netjes” via een DNS request bij je IP te komen.
Het is denk ik meer een truuk die ze toepassen op hun eigen DNS server in een Test domein om verkeer om te leiden en om zo ook weinig configuratie te hebben in hun Test omgevingen.
Ik denk dat het wellicht een manier om de Let’s encrypt certificaten te valideren en dat ze dat via eigen DNS registratie, wel op basis van de DNS naam aan het IP van je Homey te koppelen.
Hieronder zie je dat Google hier bijvoorbeeld ook gewoon een “registratie” heeft.
Dit sterkt mijn vermoeden dat het de DNS server gewoon laat uitkomen bij je modem. (Waar het verder compleet geblokkeerd wordt omdat enkel de staande uitgaande connectie toegang heeft naar intern)
eric@Fly ~ % ping 1-1-1-1.homey.homeylocal.com
PING 1-1-1-1.homey.homeylocal.com (1.1.1.1): 56 data bytes
64 bytes from 1.1.1.1: icmp_seq=0 ttl=52 time=12.943 ms
Goeie, en inderdaad, de site blijft werken als ik de stekker er uit trek.
Als ik de code in Homey’s core goed begrijp proxyen de cloudservers de requests ook via een Websocket verbinding naar Homey, dus daar zit inderdaad nog iets tussen.
De certificaten zijn voor het domein homeylocal.com, dus je moet daar wel een DNS “truuk” voor gebruiken, zelfs voor lokale TLS toegang. Wat meteen een probleem opwerpt, want veel thuisrouters accepteren het niet dat een remote DNS server private IP adressen teruggeeft. Die optie (“DNS rebinding protection”) moet je uitzetten als je wilt dat op je lokale netwerk de Homey apps je Homey direct (niet via de cloud) aanspreken.
Het werkt met willekeurige adressen. Er zijn ook online diensten die iets vergelijkbaars aanbieden (nip.io, sslip.io).
1 Like
Ik maak thuis gebruik van PFSense als firewall en heb alles dicht staan en monitor op vrij veel niet-standaard zaken (DNSRBL & IPBL, IDS/IPS).
Homey zit in mijn IoT VLAN zodat het uitgaand kan doen wat het moet doen en mijn IoT devices.
Ik beschouw hem dan ook grootendeels als “untrusted”
Mijn vermoeden is dat voor lokale herkenning gebruik wordt gemaakt van mDNS; een niet-centraal mechaniek om als host in het netwerk voor te leggen welke services je biedt en dat op die basis ook verbinding wordt gemaakt met de homey.
Ik zal als ik thuis ben eens een mDNS discovery starten om te zien wat naar voren komt.
Ik heb wat ESP32 microcontrollers geprogrammeerd met dit protocol en het werkt heel aardig.
Devices van Synology, Sonos, (Apple) Airplay maar ook Windows, Mac en verschillende andere netwerk devices zoals scanners en printers e.d. gebruiken dit om elkaar lokaal te vinden.
Alle endpoints van je Homey zijn benaderbaar via connect. Die pagina die jullie zien is gewoon een webpagina van de server zelf (in dit geval een redirect). De proxy check zit hem in de homey id in de hostname.
De apps zullen vast gebruik maken van mDNS voor discovery, maar alleen om het IP-adres van Homey te vinden (wel mDNS, niet DNS-SD).
Vervolgens wordt het IP-adres gebruikt op de voornoemde manier (herschreven naar A-B-C-D.homey.homeylocal.com) om het mogelijk te maken om een TLS verbinding op te zetten met Homey (wat dat kan niet op IP-adres, alleen op hostname).
Ik ben er goed bekend mee 
1 Like
Hmm ik zie nog niet hoe daarmee de aanvraag bij de lokale Homey uit kan komen, Robert.
Ik zie hoe de A-B-C-D.homey.homeylocal.com een TLS endpoint zou kunnen vormen tot aan de modem via een connectie geopend vanaf het internet.
De hosting van deze endpoint zal echter niet vanaf de modem werken wanneer deze een firewall heeft of portforwarding uit heeft staan plus geen SSL offloading op zich kan nemen om de TLS verbinding tot stand te brengen.
Wat ik vermoed dat er gebeurt is dat de Homey een uitgaande connectie maakt naar de Homey Cloud.
Dat deze op de uitgaande poort op een staande connectie vervolgens verkeer kan toestaan vanaf de host met welke ze op de homey cloud verbonden zijn en deze op zijn beurt via deze uitgaande poort terug bij de homey kunnen komen die op zijn beurt het betreffende TLS certificaat gebruikt.
Dat in ieder geval bij de connectie vanaf internet.
Hoe de connectie lokaal is, zal denk ik via mDNS een identificatie van de Homey zijn en gezien je al in het netwerk zit hoef je dan nog enkel te verbinden met de open staande poorten.
Het valideren van het TLS certificaat kan dan niet meer via de publiek op te halen CA root certificaten van Let’s Encrypt tenzij deze publieke certificaten pre-loaded zijn in de Mobiele Homey app. (Lijkt mij het geval)
Als je dan vanaf intern probeert te connecten naar de A-B-C-D.homey.homeylocal.com zal je firewall in je modem je alsnog blokkeren lijkt me en zonder portforwarding zal je modem ook niet weten wat de route naar je Homey is.
Ik verwacht dus dat de connectie lokaal direct op IP zal zijn en het TLS certificaat wel de (Private / Public) keypair authenticatie kan doen maar de Host authenticatie niet, immers het betreft een lokaal IP waar Let’s Encrypt niets mee heeft gedaan.
Dat is denk ik ook wel afdoende.
Wellicht broadcast de Homey als een http(s) server op mDNS.
Is een dns rebind naar lokaal A.B.C.D.
Apps hebben een ipc socket connectie met de Homey en vragen via die weg de getLocalUrl() dit is alleen van toepassing als de app de web api gebruikt en die permissie ook heeft. Eigenlijk zou dat verkeer net zo goed via de bestaande socket kunnen gaan mja zo werkt het nou eenmaal.
De mobiele app probeert eerst via homeylocal en als dat niet lukt op ip (geen https) en vervolgens als die beide niet lukken gaat het via mdns (homey-someid.local).
1 Like
Klinkt aannemelijk
