5 ms·
This looks interesting, though it's not entirely clear how it works. The docs go relatively in depth into the code structure, but it doesn't do much else.
by mkdirp 5y ago
This looks interesting, though it's not entirely clear how it works. The docs go relatively in depth into the code structure, but it doesn't do much else.
- yonixw 5y agoLooks like they implemented their own windows kernel driver [1] [2] for intercepting packets. And since I see BOTH domain names and applications that won't trust custom SSL CA in their website, I guess they get the domain name from the ssl handshake packets (sni) [3] which is in plaintext [1] https://github.com/safing/portmaster/blob/22507e879be95c7b0f4e2915e620ec04171e7052/firewall/interception/windowskext/doc.go https://github.com/safing/portmaster/blob/22507e879be95c7b0f... [2] https://github.com/safing/portmaster-windows-kext https://github.com/safing/portmaster-windows-kext [3] https://en.wikipedia.org/wiki/Server_Name_Indication https://en.wikipedia.org/wiki/Server_Name_Indication
- cmeacham98 5y agoThey could also just do a reverse DNS lookup on the IP (and then forward lookup to confirm it). This would be less effective for sites run through CDNs (ex Cloudflare) though.
- sneak 5y agoYou just described almost all major API endpoints. Using PTRs is practically useless for this purpose.
- dhaavi 5y agoCTO of Safing here. We have SNI inspection in progress (currently on hold), but not yet live. Currently, we just match the IP address to all resolved IPs of all domains and pick the most recent one. (The Portmaster handles DNS via DNS-over-TLS.) With TLS1.3, the SNI will be encrypted, so this information will be "gone" for us anyway.
- dhaavi 5y agoHi, CTO of Safing here. Can you explain what you expected? Maybe you can find a good exmaple. We really want to improve on this.