Apple's “iCloud Private Relay” broke risk based authentication
zitadel.ch
zitadel.ch
I just scoped my IMO to our Identity and Access Management World.
That’s what’s different with iCloud relay - Apple’s weight to force changes upstream.
Either Etsy changes their policy now during the beta (my guess is they will), or they change it in a panic in November when iPhones can no longer access the site to buy anything.
(No-one is going to switch off private relay to convenience a single website).
If you're a seller and a decent chunk of your income comes from Etsy you definitely would. They already do that with avoiding VPNs to not get suspended.
That prevents buyers from buying also.
Etsy will adapt, quickly.
At least, it would if their Etsy accounts weren't getting locked until they can contact support.
That said, the Etsy app won't be subject to Private Relay, so if the functionality is there then a lot of users won't have to worry about it as much.
Why? As far as I know it will apply to apps as well.
> In iOS 15 and macOS 12, Private Relay will apply to all web browsing in Safari, all DNS name resolution queries, and a small subset of traffic from apps.
> Specifically, this will include all insecure HTTP traffic, such as TCP port 80.
This implies that app traffic won't apply to HTTPS traffic, which supports my assertion, but then later in the video:
> Not all networking done by your app occurs over the public internet, so there are several categories of traffic that are not affected by Private Relay.
> Any connections your app makes over the local network or to private domain names will be unaffected.
> Similarly, if your app provides a network extension to add VPN or app-proxying capabilities, your extension won't use Private Relay and neither will app traffic that uses your extension.
> Traffic that uses a proxy is also exempt.
So this says that HTTPS traffic will be included, which disproves my assertion, and seems more likely to be true.
99.9% of etsy userbase would not.
99% of computer users do not inhabit the same galaxy as you do when it comes to understanding and managing technical details.
At the same time, 99% of computer users have no idea why we can’t just ‘slap x button there and make it do x’ and that is just as infuriating.
I'm sorry to tell you this, but sooo many people in the US alone are not technically literate enough to know how to debug an issue like this.
Private Relay guarantees that users can't use the system to pretend to be from a different region, so you can continue to enforce region-based access restrictions. Details about the proxy IP addresses will be available as an article associated with this session.
Though I haven't been able to find the aforementioned article.
[1]: https://developer.apple.com/videos/play/wwdc2021/10096/
https://developer.apple.com/support/prepare-your-network-for...
And their IPs, as mentioned in that article:
https://mask-api.icloud.com/egress-ip-ranges.csv
Seems to be mostly Fastly IP addresses right now, but I'm sure that'll change over time.
Let’s say ~30% of Etsy.com views are through Safari (iOS + macOS; ignoring that Chrome on iOS is a viewframe around WebKit anyway). Of those, 25% have iCloud+.
Let’s say they did this and 50% of people did visit the site through Chrome.
That’s ~4% less revenue for them. I don’t know what Etsy makes per year, but ~4% of whatever that is will be on the order of millions of dollars. So, this is a no-brainer.
Let's say that ~100% of Etsy.com views are through Safari. Of those, 100% have iCloud+.
Let's say they did this and 0% of people visit the site through chrome.
That's 100% less revenue for them. Pretty amazing that this one feature could completely kill Etsy's revenue stream.
(For what it's worth, I agree with you that Etsy is not going to tell Safari users to pound sand, but your arbitrary numbers don't make an actual point unless they're based in facts and figures.)
In other words, your comment reads as “if everyone stops visiting Etsy, then they will make $0”, which…yeah. Makes sense to me.
They plug the numbers into the formula and see "If we block IE11 users from being able to use the site, we lose 1% of our traffic, which equates to X dollars. Is that a substantial amount? If so, we support IE11, if not, IE11 support goes out the door."
So yeah, you can plug in the numbers you did and try to negate his argument, but that doesn't make his argument wrong. Just means you understand the argument but fail to accept it.
2. The point of the math was to show that it's a big deal for basically any reasonable values. It doesn't depend on the exact numbers.
I’m not an expert on Risk Based authentication, but your Etsy example sounds exactly like RBA. They use IP address as a factor in determining the risk associated with allowing the login, and suspend accounts with random IPs to prevent the “attacker” from wreaking havoc.
RBA: https://en.wikipedia.org/wiki/Risk-based_authentication
Could an attacker use a VPN? Sure—and there are also plenty of evildoers in the US. But it's an extra barrier.
What I really don't want, however, is for my password manager (or any other service) to make these decisions for me. I will probably travel some day, and when I do, I don't want to be locked out of my account due to "unusual traffic" (yes, it is unusual for me to travel, that doesn't mean it won't happen).
Wait, so my data will be routed to US servers, as an EU resident, where the data protection laws are not as strong as where I live? This is a really bad idea, as US is known to tap any data they can get on their soil.
At least in the Developer Beta 2
There are clearly some bugs. Occasionally I, in Canada, get routed through the US. This guy got routed through the US. Neither case should happen by Apple's description. Apple is quite intentionally trying to avoid their relays getting around geo-restrictions (likely to avoid them getting blacklisted).
It's supposed to, but that is definitely not currently the case.
If that will be fixed during the beta period is unclear.
1. Settings -> Apple ID -> Private Relay
2. Settings -> Network -> Use iCloud Private Relay
Is private relay still in Beta? That might explain it if the serve side component only got deployed in one or two of Apple's US datacentres.
I think you meant to say, the US is known to tap ALL data we can get our grubby little paws on. We don't care if it's on our soil or not.
AIUI, it's arguably harder if it's on our soil, as then we might be spying on US citizens which requires a touch more paperwork.
NOTE: I'm not condoning this behaviour, just stating my understanding of it.
Personal data should be protected by TLS (edit: and/or application-level encryption) so packet routing is irrelevant to privacy and data protection.
I am very worried that the demand for protection of personal data (which is good) is mutating into an expectation of fully regional Internets that do not peer with each other (which IMO is bad).
But from a threat model I would dare to say, if you control the platform (OS, Cloud Service) you can easy bypass encryption or deploy your own keys as well.
In the end it is still a trust question.
And while I may not have direct control over where my data is actually routed, but there absolutely are legal restrictions on where companies may route them.
I guess it's sort of a good thing that Apple is getting into the business of giving away snake oil to combat people selling it. The big iOS privacy changes that would help are DNS over HTTPS (maybe it already does this and requiring permissions for non-HTTPS network access. Maybe they could limit relay routing to non-HTTPS browser traffic?
When any server in USA soil can be changed into a backdoor, accompanied with a gag order on disclosure, I certainly do not want all my egress traffic routed into any computer in USA.
It's fantastic that Apple is continuing to mitigate commercial surveillance. It's easy to discriminate against us lone individuals who hide our IP addresses, but Apple's market is too big to reject. If they're successful here, I'll have to consider buying a Mac purely for their VPN service.
Perhaps they'll take on CAPTCHAs next.
So if you only ever log in to your financial institution from NY city, they shouldn't be suspicious if they see an attempt to log in from North Macedonia?
My bank sends me a card with a grid of coordinates and I have to enter the character at the coordinate when I login, after entering my password, thereby proving something I know and something I have, without also requiring me to have a phone
It would honestly be revolutionary for a bank to require hardware authentication and send a security key to every client upon registration.
Also, yes, I really wish recaptcha dies a painful death because it often does discriminate me for my IP address and non-acceptance of third-party cookies.
Have fun everyone!
I can think of a few orgs that aggressively block VPN traffic from employees - in some cases the metadata leaked by the end user is a security risk. (Ie you’re doing work stuff in one tab and researching or doing related matters in another)
Please kill opt-out-less 2FA while you’re at it. (Thanks Amazon, been enjoying that change!)
Also a strange approach by Cloudflare, who sell IP based risk management.
Is it though? To me it seems more like the iCloud Private Relay will make it harder for everyone else maybe but not necessarily much harder for Cloudflare themselves.
And, yes, I do hate Cloudflare and other CDNs with burning passion because the internet is meant to be decentralized. But especially Cloudflare and their "one more step".
I think of it like reputation in real life. If you come knocking on my door, and I can see and recognize you, I'll open it. If you cover up my peephole or hide yourself so that I can't recognize you, why would I even let you know I'm home? Even if you tell me who you are, shouldn't I be worried that someone is impersonating you?
At the very least I'd expect users from anonymizing IPs to have to jump through some extra hoops like captcha and 2FA.
However, with Relay, that signal is lost. Legit users and malicious parties become indistinguishable. The service can't tell if traffic from the relay is from a customer or an attacker.
What to do? Trust everything? Not good. Treat everything as potentially malicious? Safe, but makes the user experience worse.
To use your analogy, if you look through your peephole and can't tell if the person is your best friend or your worst enemy, how do you react? If you assume it's your best friend, you could be in trouble. If you treat the visitor like your worst enemy, you've pissed off your best friend.
Another analogy I could make is someone that is blocking their caller ID. Should they be surprised that fewer people will take their call? They're lumping themselves in with spammers.
I think Apple -- and anonymizing proxy/VPN services in general -- should be communicating that to their customers.
Websites will have to choose if they're willing to provide a worse UX to Apple customers.
Why should everyone between me and my data have access to an IP address that is tied to my personal data? And when did choosing to not allow that become a shady thing to do?
— edited autocorrect of ruins to features
I think everyone's view is tinted by the over-collection of data that some companies are doing. A real-life analogy would be having someone record everything that you do. We've come to accept that to an extent when going into stores, but probably wouldn't hang out with a friend that did that. I don't think the best solution to that is to put a bag over yourself and change your voice so that you're anonymous but still hang out with that friend -- I think it's to tell your friend that you don't want to be recorded. If some service is recording you too invasively, don't do business with them. If you don't know who is recording you, get your government to pass a law like GDPR.
If you want to live in a world without reputation, there will be drawbacks. Attackers will be indistinguishable from regular users, so you have to treat regular users as if they could be attackers; you can't have a tiered approach. The person banned for posting threats (or worse) or otherwise misbehaving on a message platform will be indistinguishable from a new account. The brute force attack will be indistinguishable from the legitimate user. Etc.
To throw out the whole concept of reputation so that you can be perfectly anonymous seems like the wrong solution to the problem.
They're not doing it because they want to annoy anonymous users; they're doing it because they're not getting any signal that they can trust this connection. That's the price you pay for removing reputation, and no number of Apple Relay users can change that. Website operators can't simply start trusting completely anonymous connections simply because there are a lot of them.
That's why I say Apple should be communicating this to users: there's a price to pay for anonymity. You may see more captchas, you may get challenged with 2FA more often, etc. Not to mention, you might be making it easier for actual criminals to hide amongst the other traffic.
When she logged in, the privacy issue becomes moot of course, yes. At that point her credential can be trusted the same way as before.
The only thing that should signal my reputation is my identity, and despite the best efforts of the adtech world, you can’t reliably correlate that to an IP address.
They do give you valid login and password, why is that not enough?
Btw, none of Apple services complained yet about my vpn usage.
I didn't say that. In the example I gave, you looked through your peephole and couldn't identify the visitor. Perhaps there's a problem with the peephole.
If there is a problem with my peephole, I'm still not trusting the person at the door until I can check it out and fix it.
No. It's not on me to justify my use-case. How the hell did we get here?
Perhaps… but if the culture changes and _everyone_ starts covering the peephole, regardless of their intentions, you'll eventually stop looking because you know it's pointless. That doesn't necessarily mean you'll just open your door willy-nilly, it just means you'll come up with some alternative way of having your visitors prove their unmaliciousness.
Combine that with a bank that would freak out if you used the account from abroad it was often a multi-day operation to get a transaction to go through (between support calls to bank and merchant)
Though i guess a signal vs hard lock/logic.
It’s a thing in Europe as well.
I have a little app in my phone from my credit card company where I confirm when I am really buying something and it looks more secure than relying on fraud detection.
It shifts fraud loss liability onto the customer who is even less prepared to deal with it than the merchant. Only a few merchants tried it like Newegg.com. It flopped because the hit to conversion was more than the fraud prevention. It usually fails open (allows transaction to proceed). Merchant side fraud detection is inherently inferior to the bank doing fraud filtering, but banks don't care. Not their liability not their problem.
I wonder if there's rules depending on which country. When I worked for a small-time credit card "vendor" we could put pretty much anything we wanted in our iFrame.
SCA is therefore likely to become a requirement in the US once it's reached maturity in Europe, as we saw with EMV.
Further reading: https://www.jonesday.com/en/insights/2020/12/strong-customer...
Initially my IP was showing up all over the US. My guess is they were working on the logic and adding more CDNs. So far I've seen Cloudflare and Fastly.
I wonder if you could abuse this to bypass ACLs on Fastly customers that block direct origin traffic.
Great point about the ACL.
I was very surprised when I checked and saw Fastly on my iPad as I wasn't aware Fastly had any similar product, in my mind they are (were?) strictly a reverse proxy CDN.
Money solves a lot of problems. Fastly already has a geographically diverse set of servers, so I could see them building a feature like this just for Apple (at least initially).
In the meantime: https://zitadel.ch/blog/imo-passkey-in-icloud-keychain/
I live in Spain, I'm from the Netherlands and have lived in Ireland as well, leading to tons of "soft block" nightmares.
OpenVPN has a noticeable impact.
Well I'm not sure everyone will be happy to do that. Tying session tokens to source IP addresses is usually not a bad practice and is rarely the only mitigation used.
Using the IP as means is IMO nonsense with todays use of CG-NAT, VPN and so on. It does not rely help securing something.
But these are just my 2 cents ;-)
Disclaimer: I wrote the article
For preventing malware from using stolen cookies on a botnet, it's reasonable to argue that it's easier for the malware to steal the TLS client cert (which is no less accessible than the cookie jar itself) than it is for the malware to maintain access to the "good" client IP. As silly as IP-binding of sessions is.
From a threat model perspective it is absolutely true that when attacker gains control over the device they could extract the secrets from that said device (they can act as you as well). However token-binding would at least allow for some safeguards against attacks from the application layer (in this case web apps and extensions) in the browser but not against device attacks.
My point was only that lamenting the demise of TB as implemented is a bit overdramatic. Lamenting the demise of TB as (perhaps) dreamed about—yeah, I buy that.
If the UX for mTLS (client certs) just was not so terrible it might be a great alternative with even better Security, but that is a dream as well ;-)
A client cert is also not shared among all users behind a NAT, can be durable across roaming across IPs, and is actually meant to be a security measure unlike IPs.
Can be, indeed, but was not in existing implementations, to my knowledge. My point (perhaps I was more clear in my followup comment) was that we shouldn't shed too many tears given the actual implementations did not provide the promised security gains. Were they stepping stones? Maybe. But they didn't (yet) deliver.
> A client cert is also not shared among all users behind a NAT, can be durable across roaming across IPs, and is actually meant to be a security measure unlike IPs.
Yes, but, bizarrely, IPs actually provide more security against some threats, as I noted. I don't think this is because IPs are a great security measure--they're not!--but because token binding as implemented was pretty weak.
You're comparing a fundamentally bad design that had decades of "refinement" but cannot go further to a first stab at a good idea that has many ways to improve (storing keys on hardware tokens or TPMs, preforming signing on a TEE). Storing the keys on a hardware token might even make sessions portable without having to enter secrets into an untrusted machine.
I think token binding itself had some design flaws that made it hard to realize these improvements, but that's not to say that I think IP signals are better (or obviate) cryptographic replacements for bearer tokens—I don't think that. I just think it's an irony of token binding's design that the design suggested an implementation which in practice provided less value than IP binding.
The very nature of the internet makes it impossible to guarantee that none of your packets ever route through a specific country (especially one as connected as the US).
I meant that most consent systems that companies add to their site to determine if a user is in EU or not (and hence covered by GDPR) won’t work reliable with Apple users.
Most of their geolocation relies on IP addresses.
Technically untrue, since you can add "strict source routing" as an IP packet option that specifies exactly where it will be routed.
Also, SSR doesn’t involve geography - IPs and ASNs can move.
Now there there is no reliable way to tell
Just assume that no consent is granted. Access to the site or specific services cannot depend on granting consent, which implies that anyone who does grant consent probably failed to understand that it was optional, or did so only to avoid being harassed with further consent requests. The GDPR already makes the "consent" completely one-sided with no possibility of consideration; it might as well have disallowed the requests altogether and saved everyone a great deal of hassle.
If the IP address can’t be reliably used then many EU users are going to appear to be in the US and their data collected without consent. The opposite may happen too.
This is not Apples fault and Apple aren’t violating GDPR. I’m just flagging that it creates downstream problems and headaches.
Did they just reïnvent opinion pieces?