Mullvad exit IPs as a fingerprinting vector

[Alvah.Lind64]

Mullvad exit IPs as a fingerprinting vector

[anon7180143]

Mullvad’s preliminary response:

Mullvad exit IPs are surprisingly identifying

[The_Learner]

Nice that they seem on it. Thanks for sharing.

[jonah (Jonah Aragon)]

Huh? How is this a problem?

There is no information to be gained here except some relational information between exit servers.

I can maybe see this being a potential problem for you if you:

1. Use the same online identifier switching between multiple Mullvad servers (which you probably should not do), and
2. Also use switching VPN servers as a way to compartmentalize different identities (which you should not do)

Even still, practically speaking this is not going to create a unique deanonymizing fingerprint because people are still sharing IP addresses.

This is not going to impact anyone except people who vastly overestimate how much anonymity a VPN provides you with. Why are you switching servers so excessively in a 30 day period anyways?

It’s commendable that Mullvad will improve this behavior anyways, but this is not a serious concern.

Everyone I’ve seen making a big deal about this on social media platforms feels like a fed to me tbh, for example,

[mika]

@jonah

Why are you switching servers so excessively in a 30 day period anyways?

There are a number of legit reasons for switching servers:

• Many websites / services block some Mullvad servers but not others.
• Sometimes a connection to a preferred server will be slow due to network characteristics so switching is necessary to get acceptable speeds.
• The Mullvad app will automatically cycle servers when it encounters connectivity issues with your chosen server - whether user-side connectivity issues or server-side.

I was connected to Mullvad on my phone yesterday and walked into a building with poor reception. I checked the Mullvad application and saw it rapidly cycling through my list of preferred servers trying to find one it could connect to. That’s typical behavior with a VPN, no?

It’s encouraging to see the Mullvad team taking this so seriously, though, as it seems like some improvements could and should happen on their end.

[any1]

@mika

Many websites / services block some Mullvad servers but not others.

You could use the Mullvad Browser Extension for this instead

[mika]

I do, and in my experience its proxies only sometimes succeed in unblocking websites.

[privacy.slouchy]

They’re trying to make your public IP anonymous. But this ‘multiple exit nodes’ IP setup feels like a half measure.

Imo, If you want your public IP to be anonymous, use Tor. VPNs really a privacy tool, not an anonymity tool

That being said, I support Mulvad’s efforts to continue working towards infrastructure that may allow some anonymity

[jonah (Jonah Aragon)]

@mika

There are a number of legit reasons for switching servers

Yeah but this is mainly a problem when you do so and you are using multiple identities you want to keep separate. The ‘attack’ implies that the attacker somehow knows you’re using multiple Mullvad IP addresses and (magically?) which IP addresses you are using.

Let’s say I wanted to attack you. You’re logging in here to the Privacy Guides forum as @mika via multiple Mullvad servers, and then I log all of them. Then what, I could get a likely idea of what other IP addresses you might use in the future? I have no use for that information, unless I then collude with some other website. So let’s say maybe you sign in to the GrapheneOS forum with a totally different username, and they really want to know if that account is @mika on the Privacy Guides forum: So they give me your Mullvad IP there, and I check whether it’s likely that it’s one of your Mullvad IP addresses in this 30 day window, and I tell them yes it likely is? (But you can never be certain in this case because some people are still sharing IPs on Mullvad, your plausible deniability remains intact even if it does become less likely).

All of this is not likely to occur, and shouldn’t even be a problem because if you actually want these identities to be separate you really should not be using the same VPN for them at all.

This does not in any way impact the primary use-case of a VPN, which is to shift trust from your ISP to the VPN provider.

It also does not impact the secondary (lesser) use-case of a VPN to thwart passive tracking between websites who are not colluding with each other.

There are potential (unlikely IMO) use-cases in an active attack against you. With this risk in your threat model you should be using Tor.

[obscuracarl (Carl @ Obscura)]

Reposting my reply on HN:

Carl here (Obscura CEO, one of Mullvad’s partners)

This was an interesting finding, though as kfreds mentioned it would have been better to notify the vendor before publishing.

The main finding (IP-position-in-pool correlation between servers) seems to include genuinely unintended behaviour. Given our great experience with the Mullvad team, I’m sure this will be addressed soon.

In general, if you want different “identities”, you should make sure to rotate or use different WireGuard keys.

One small thing I’ll comment on:

Surprisingly, the exit IP you are given is not randomized each time you connect to the server, but deterministically picked based on your WireGuard key, which rotates every 1 to 30 days (unless you use a third-party client, in which case it never rotates).

Context: WireGuard is by design a “Connection-less Protocol”, there’s no concept of a connection, there’s only a “re-keying handshake” (key here refers to the ephemeral Diffie-Hellman key, not the WireGuard key) every 2-3 minutes ONLY IF there’s traffic flowing.

The above statement is not too surprising if you consider the counterfactual: What would happen if, even with the same WireGuard key, the exit IP were randomized each time you “connect” to the server (say each time there is a “re-keying handshake” or at more frequent cadence (e.g. every 15 minutes) than the WireGuard key rotation).

In this scenario, ~every 15 minutes:

• At the Transport layer, all your in-tunnel connections that are on non-roaming protocols (basically everything except QUIC) would be disrupted, and the connections would have to be re-established.
• At the Application layer, many application-level sessions that treat “same cookie, new IP” as suspicious would trigger logouts, CAPTCHAs, or risk scoring.

Both are terrible UX, and would also make users much more uniquely fingerprintable (“this person keeps reconnecting from a different IP, they must be using Mullvad”).

[jonah (Jonah Aragon)]

@obscuracarl

notify the vendor before publishing

Or… even while publishing. I am of the opinion that “responsible disclosure” is nice but should not be mandatory, but kinda rude if they have to find out from Hacker News instead of a quick email

@obscuracarl

The above statement is not too surprising

I will say, to be fair it might not be an obvious fact to customers that connecting to one Mullvad server could result in having different exit IP addresses in the first place.

I assume this is a result of Mullvad considering “servers” to be actual servers, while other VPN providers list “virtual” servers in their clients which instead correspond to individual IP addresses rather than servers.

[obscuracarl (Carl @ Obscura)]

@jonah

while other VPN providers list “virtual” servers in their clients which instead correspond to individual IP addresses rather than servers.

Oh interesting I didn’t know that! It’s always a tough challenge to balance surfacing enough things to the user and making sure the UX isn’t too overwhelming.

[PixelatedWizard]

DAITA support is limited to certain countries’ servers, so if you want to turn it on my periodically but switch back to closer servers when not using it, that would be one use case.

[ignoramous]

@jonah

Even still, practically speaking this is not going to create a unique deanonymizing fingerprint because people are still sharing IP addresses.

TFA ends with

Now apply this to IP logs obtained through data breaches and legal channels and you can see how you could get deanonymized behind a VPN through similar correlation attacks.

@jonah

This is not going to impact anyone except people

The impact is, all that marketing engineering effort on DAITA and “audits”, metadata leaks like is frustrating at some level. There may be other such issues that lurk, all the while folks are sold protection against “traffic analysis” on a rather (comparatively) expensive $5 plan.

[jonah (Jonah Aragon)]

@ignoramous

TFA ends with

Now apply this to IP logs obtained through data breaches and legal channels and you can see how you could get deanonymized behind a VPN through similar correlation attacks.

Really nothing to do with what I said

[ignoramous]

@obscuracarl

WireGuard is by design a “Connection-less Protocol”, there’s no concept of a connection

Not true at all. This is a misunderstanding of how Peer association works.

@obscuracarl

the exit IP were randomized each time you “connect” to the server

Our WireGuard client changes keys & peer every 45m. Yet to hear complaints from testers about broken streams etc. We’ll see.

@obscuracarl

connections that are on non-roaming protocols (basically everything except QUIC) would be disrupted

Some L4 load balancers are clever. They pin clients (destination) only on source tuple (of the LB) to backends. That is, as long as the client connects to the same LB (same IP & port), it’ll have an unbroken stream to backend that served it.

@obscuracarl

this person keeps reconnecting from a different IP, they must be using Mullvad

Disingenuous when public VPN provider exit IP ranges are not secret and/or published openly.

@jonah

Really nothing to do with what I said

Probably. I assumed you wrote precisely whatever you want said.

[anon7180143]

Official update from Mullvad:

Exit IP fingerprinting between VPN servers | Mullvad VPN

[Expert4870]

As of update on May 25:

Below are the servers with the new mitigation applied.

• au-mel-wg-402

• au-syd-wg-001

• ca-mtr-wg-302

• de-fra-wg-103

• fi-hel-wg-201

• fr-par-wg-101

• ie-dub-wg-101

• no-osl-wg-101

• se-sto-wg-208

• us-dal-wg-701

• us-lax-wg-002

• us-nyc-wg-601

• us-slc-wg-303

[polyester_apricot650]

Use it for what?

[polyester_apricot650]

What are the implications if I use Mullvad on a router?