Neat use case. But in fairness, you've simply 'offloaded' NAT traversal/port forwarding to automagic helper protocols over which you have no control even if you wanted it.
I recently tried whitelisting IPv6 prefixes at the network border and running straight IPv6 traffic from end to end.
It works really well so long as there's an encrypted transport, although I'm a little annoyed that the routes are very different and the ping times are different too. Although at the moment I can't remember if they're worse ¯\_(ツ)_/¯
Things are much more unscrupulous than potentially ceasing to be free tomorrow. Nobody who values their privacy would ever route their network traffic through a 'free' service.
Tailscale is not marketed as an "anonymity VPN". You're still using the devices in your Tailnet.
Tailsacle provides managed, policy-driven secure connectivity, where the network admin controls access, and where packet payloads are end-to-end encrypted between their nodes using device-to-device links that are WireGuard-based. Their TCP relay system (DERP) helps connectivity when direct peer-to-peer isn’t possible, but traffic through DERP still remains end-to-end encrypted.
They need to know how/where to route your outbound traffic. That inherently includes plaintext DNS, TLS handshakes, and otherwise plaintext traffic (like HTTP for example).
Anybody wanting to see what Tailscale is able to see can simply sniff any router interface passing outbound traffic before it enters the WireGuard tunnel interface.
No, that’s not quite true. The wireguard tunnels that the Tailscale daemon creates only go to your own machines. Nothing going through those tunnels goes to or is seen by Tailscale the company. Sometimes those tunnels go through a proxy (especially when you’re afflicted by CGNAT), but the proxy sees only encrypted traffic.
Pretty much this. DNS, SNI, and otherwise plaintext traffic sniffing. That together with user/device 'fingerprinting' (a much more amorphous concept), and that's why such-and-such thing you were just talking about with so-and-so pops up on your screen/feed/whatever, sometimes only minutes later.
I highly doubt any of this can actually be opted-out of. How else would they stay in business?
The `TS_NO_LOGS_NO_SUPPORT` option opts out of all log collection, and says in the name why it is collected in the first place. Tailscale has support for all users, including free, and having access to logs has to be how they can provide free support. Having quick access to logs reduces the time it takes to handle tickets, so they can help more people quickly and don't need to limit support to only paying users.
The core client code is open source, feel free to inspect it yourself.
They specifically avoid sending traffic through tailscale servers whenever possible. That’s how the free tier stays free. Most connections are direct, P2P.
The traffic that does go through their servers is encrypted, and bandwidth limited on the free plan. Any snooping on client behavior would have to be done client side, and the clients are all open source. To some extent the coordination server might be able to deduce some metadata about connections; but definitely not snoop all plaintext traffic.
I think they do have some “service detection” which can basically port-scan your devices to make services visible in the web UI. But that is easy to disable. And premium/enterprise tiers can intentionally log traffic statistics.
> To some extent the coordination server might be able to deduce some metadata about connections; but definitely not snoop all plaintext traffic.
Metadata is as good as data for deducing your behavior. Think what conclusions can be drawn about a person's behavior from a log of their network connections, from each connection's timestamp, source, destination, and port. Think about the way each additional thing-which-makes-network-requests increases the surveillance value of all the others.
Straight away, many people's NTP client tells the network what OS they use: `time.windows.com`? Probably a Windows user. `time.apple.com`? Probably Mac or iOS. `time.google.com`? You get the idea. Yeah, anyone can configure an NTP client to use any of those hosts, but the vast vast majority of people are taking the default and probably don't even know what NTP is.
Add a metadata point: somebody makes a connection to one of the well-known Wi-Fi captive portal detection hosts around 4PM on a weekday? Maybe somebody just got home from school. Captive portal detection at 6PM on a weekday? Maybe somebody just got home from work. Your machines are all doing this any time they reconnect to a saved Wi-Fi network: https://en.wikipedia.org/wiki/Captive_portal#Detection
Add a metadata point: somebody makes a network connection to their OS's default weather-widget API right after the captive-portal test, and then another weather-API connection exactly $(DEFAULT_INTERVAL} minutes later? That person who got home is probably still home.
I don’t mean P2P in the same sense that BitTorrent or something is P2P. (Splitting one connection into many distributed ones) But more like how a game that does P2P multiplayer has the clients connect directly instead of through a centralized service.
For the router itself? No. For the 'prosumer' admin? Sure.
How many prosumers or otherwise network admins filter outbound traffic though? And of the select few that do—how many are actually 'inspecting' say, outbound TCP/443 (e.g., monitoring traffic volume, looking up destination addresses, and/or inspecting SNIs) for example?
So how did you identify this as a breach? I'm struggling to find this credible, and you've yet to provide specifics.
Right now it comes across as "just enough knowledge to be dangerous"-levels, meaning: you've seen things, don't understand those things, and draw an unfounded conclusion.
Feel free to provide specifics, like log entry lines, that show this breach.
Please feel free to ignore this sub-thread. I'm merely happy that Apple finally shipped an iPad that would last (for me! no claims about anyone else!) more than a few weeks without falling over.
To learn iOS forensics, try Corellium iPhone emulated VMs that are available to security researchers, the open-source QEMU emulation of iPhone 11 [1] where iOS behavior can be observed directly, paid training [2] on iOS forensics, or enter keywords from that course outline into web search/LLM for a crash course.
I worked at Corellium tracking sophisticated threats. Nothing you’ve posted is indicative of a compromise. If you’re convinced I’d be happy to go through your IOCs and try to explain them to you.
Thanks. In this thread, I was trying to share a positive story about the recent iPad Pro _NOT_ exhibiting the many issues I observed over 5 years and multiple generations of iPhones and iPad Pros. If any new issues surface, I'll archive immutable logs for others to review.
With the link I provided, a hacker can use iOS emulated in QEMU for:
• Restore / Boot
• Software rendering
• Kernel and userspace debugging
• Pairing with the host
• Serial / SSH access
• Multitouch
• Network
• Install and run any arbitrary IPA
Unlike a locked-down physical Apple device. It's a good starting point.
I'm much more convinced that you're competent in the field of forensics. But I still don't think suspicious network traffic can be categorically defined as a 'device breach.'
For all you know, the traffic you've observed and deem malicious could just as well have been destined for Apple servers.
Apple traffic goes to 17.0.0.0/8 + CDNs aliased to .apple.com, which my egress router blocks except for Apple-documented endpoints for notifications and software update, https://support.apple.com/en-us/101555
They said upthread that they had blocked 17.0.0.0/8 ("Apple"), but maybe there are teams inside Apple that are somehow operating services outside of Apple's /8 in the name of Velocity? I kind of doubt it, though, because they don't seem like the kind of company that would allow for that kind of cowboying.
I don't doubt it in the slightest. Every corporate surveillance firm—I mean, third-party CDN in existence ostensibly operates in the name of 'velocity'.
reply