6 ms·

Interesting concept. The blog has a lot more details[1]. One comment/question about the exit nodes. Can someone correct or validate my thoughts: It’s a WireGu

Interesting concept. The blog has a lot more details[1]. One comment/question about the exit nodes. Can someone correct or validate my thoughts: It’s a WireGuard tunnel from the user to Mullvad, so while Obscura can’t see the user traffic, couldn’t the Mullvad exit node see the traffic, and using knowledge of the users WireGuard public key, associate all that users traffic with that key? So even if they can’t associate it with an IP, they could still potentially identify and track you. This assumes they use a customised version of WireGuard to somehow log & associate each decrypted IP packet against the users public key. 1. https://obscura.net/blog/bootstrapping-trust/ https://obscura.net/blog/bootstrapping-trust/

mmooss 2y ago
Also, Obscura can collect metadata on when you use the service, how much data you send/receive, etc. Even if Mullvad doesn't do it, someone else might. Mullvad is, I expect, now a valuable target because it is the VPN service of choice for so many people concerned with security. Does Mullvad have the budget and expertise to protect itself against determined, highly-resourced attackers? Finally, is it possible for a third party, intercepting traffic between Obscura and Mullvad, to identify the public key used to encrypt it? I don't think so - the only way to validate a signature is with both keys; that's kind of the point. But maybe there is an attack I'm unaware of?
- ijustlovemath 2y ago
  Mullvad is near the cutting edge on zero trust deployments; allowing user traffic to pass thru, with guaranteed no logging, assumption of compromise guiding system architecture, etc. Nobody can withstand a nation state, not even other nation states, so I feel like they're doing the best that can be reasonably expected of them
  - ignoramous 2y ago
    > Mullvad is near the cutting edge on zero trust deployments What is "zero trust deployments"?
    - ijustlovemath 2y ago
      Meaning they're achieving their privacy goals without any inherent trust in their systems (eg no databases of user info, etc)
      - ignoramous 2y ago
        > no databases of user info Depends on the payment method. Accounting is mandatory in Sweden. As a customer of [payment] services, these entities would allow us to request this information if we chose to do so. In short, your payment actions with these two methods are not anonymous and the GDPR and other relevant data protection regulations may apply if you are making a payment by credit card, PayPal, Swish or by bank wire. The data must be kept for the statutory retention period described in applicable local laws such as the Swedish Accounting Act (some information must be stored for seven years from the end of the fiscal year). That "some information" according to Swedish Accounting Act (bokföringslagen): "Every transaction, including customer payments, must be supported by proper documentation such as invoices, receipts, and payment confirmations." https://mullvad.net/en/help/no-logging-data-policy https://mullvad.net/en/help/no-logging-data-policy / https://archive.vn/qkvD3 https://archive.vn/qkvD3
        ijustlovemath 2y ago
        Sure, but if privacy matters to you, you have the option of buying credit anonymously and applying it to an anonymized account number. And if your threat model includes nation states, you're definitely not buying anything with a credit card. I also think if you're after payment details, there's more lucrative targets, eg Stripe.
        ignoramous 2y ago
        OK. I was just wondering about your "zero trust" (aka "no database of user info etc") comment in the face of those and other Swedish laws that apply to Mullvad, is all. What you're now telling me is only if I, as a user, don't give Mullvad my info, they wouldn't have to store that. I mean, that's one way or one way of looking at it, alright.
- conradev 2y ago
  Timing attacks are notably not a part of Tor's threat model, i.e. they are a real concern: https://support.torproject.org/about/attacks-on-onion-routing/ https://support.torproject.org/about/attacks-on-onion-routin...
  - Imustaskforhelp 2y ago
    hmm. that is interesting , would you mind sharing some solution , what if I add some insane latency (I know unusable but if it prevents timing attacks) my conspiracy spidey sense is sensing something fishy... Maybe timing attack is not part of .onion addresses ?
    - woofcat 2y ago
      Mixnet would be a solution. Like what you described, have inbound packets held for some period of time and released as a group so that you cannot as easily correlate the inbound and outbound traffic. The downside is that it gets much slower, and feels 'bad' as an end user. Each packet takes longer.
    - conradev 2y ago
      The only solution I know of is essentially to do "bandwidth burning" where you inject a bunch of fake traffic as noise. I don't know how you'd do that within the constraints of this system.
- dongcarl 2y ago
  (Carl from Obscura here) > Does Mullvad have the budget and expertise to protect itself against determined, highly-resourced attackers? I think Mullvad is actively working on [System Transparency](https://www.system-transparency.org/ https://www.system-transparency.org/), which will help a lot. > Finally, is it possible for a third party, intercepting traffic between Obscura and Mullvad, to identify the public key used to encrypt it? I don't think so - the only way to validate a signature is with both keys; that's kind of the point. But maybe there is an attack I'm unaware of? I had asked this question a long time ago on either a noiseprotocol or wireguard IRC channel, and the answer is no, a third party intercepting traffic between Obscura and Mullvad, WON'T be able to identify the public key used to encrypt it.
dang 2y ago
Thanks! that blog post had a thread here: Trust, 2-Party Relays, and QUIC - https://news.ycombinator.com/item?id=43016574 https://news.ycombinator.com/item?id=43016574 - Feb 2025 (33 comments)
- vidyesh 2y ago
  That blog needs some inline padding for mobile view.
  - 0xEF 2y ago
    It's insane to me that this even has to be pointed out with such a relatively simple page, and then I looked at the source; it screams "I'm gonna just bang something out in [popular framework] without knowing basic HTML/CSS and let the world suffer from my <div> rot." I hate modern web development.
    - vidyesh 2y ago
      I agree. Its not that difficult to just have a max-width of 90% for the content or just add some padding to the inner container. I also think people skipping over learning some basic CSS fundamentals also end up skipping over basic UI/UX needed for accessible websites, something every web developer should have some awareness about. Complete reliance on CSS frameworks does not magically make the websites accessible,it gets you 90% there. Also /blog leads of 403!? Wildcard redirects are not that difficult to setup either.
  - gchamonlive 2y ago
    And it's not even that hard if the page is built in a sane way, which for the simplicity of the blog should be a no brainer to go for simplicity. I have my blog hosted at omg.lol and while I had to support mobile by myself, it was really really simple. Here is my blog: https://xd1.dev https://xd1.dev Here is the code for the blog's responsive layout: https://github.com/gchamon/xd1.dev/blob/main/css/responsive-layout.css https://github.com/gchamon/xd1.dev/blob/main/css/responsive-... No injection, no build, just plain inline linking https://github.com/gchamon/xd1.dev/blob/10b98ddb37a9786ca8fef251d37163a2dceca206/configuration/template.html#L11 https://github.com/gchamon/xd1.dev/blob/10b98ddb37a9786ca8fe...
conradev 2y ago
> somehow log & associate each decrypted IP packet against the users public key. Mullvad only needs to associate each decrypted IP packet against an assertion that the packet was paid for. I assume each Obscura node would have a public key, but not associated with a user. They notably offer this service for Tailscale (as an add-on) and I imagine that it works similarly (on the backend)
- yardstick 2y ago
  Yeah my thinking is even if they don’t have the users IP, knowing and seeing all the traffic associated with a specific public key would allow them to build a profile of the user. Eg based on the specific sites visited, payload sizes potentially, domains looked up, etc you’d be able to characterise the person. Especially so if anything they did was not encrypted, or they have their own vanity domain (for emails or anything else). > Mullvad only needs to associate each decrypted IP packet against an assertion that the packet was paid for. The idea of Obscura is by using two middlemen (them + Mullvad) that neither party can figure out who the end user is. So I’m looking at Mullvad from the perspective of: if they were evil, what about this solution are safeguard protecting the end users privacy. And my conclusion is they’d still be able to break the users privacy in the same way as knowing the users IP, just without the IP.
  - conradev 2y ago
    In Tor, individual websites get individual circuits to prevent this sort of profiling, and I think Obscura would need to do the same for the same level of anonymity.
dongcarl 2y ago
(Carl from Obscura here) This is actually quite an interesting point that we’ve been discussing internally. Right now Obscura rotates your WireGuard key on every “Connect”, but in a future release we will start caching (persist) your WireGuard keys on your client. When we flip that switch, we will also enable recurring key rotation and add a button in the UI for manual key rotation. This rotation would make it harder for Mullvad to track a user across the same key. (Not that they would anyway) All of this is available for folks to verify at on our GitHub repository: https://github.com/Sovereign-Engineering/obscuravpn-client https://github.com/Sovereign-Engineering/obscuravpn-client
- yardstick 2y ago
  Thanks for the reply, and glad to know it’s something you’re already thinking about!

mmooss 2y ago

Also, Obscura can collect metadata on when you use the service, how much data you send/receive, etc. Even if Mullvad doesn't do it, someone else might. Mullvad is, I expect, now a valuable target because it is the VPN service of choice for so many people concerned with security. Does Mullvad have the budget and expertise to protect itself against determined, highly-resourced attackers? Finally, is it possible for a third party, intercepting traffic between Obscura and Mullvad, to identify the public key used to encrypt it? I don't think so - the only way to validate a signature is with both keys; that's kind of the point. But maybe there is an attack I'm unaware of?

ijustlovemath 2y ago
Mullvad is near the cutting edge on zero trust deployments; allowing user traffic to pass thru, with guaranteed no logging, assumption of compromise guiding system architecture, etc. Nobody can withstand a nation state, not even other nation states, so I feel like they're doing the best that can be reasonably expected of them
- ignoramous 2y ago
  > Mullvad is near the cutting edge on zero trust deployments What is "zero trust deployments"?
  - ijustlovemath 2y ago
    Meaning they're achieving their privacy goals without any inherent trust in their systems (eg no databases of user info, etc)
    - ignoramous 2y ago
      > no databases of user info Depends on the payment method. Accounting is mandatory in Sweden. As a customer of [payment] services, these entities would allow us to request this information if we chose to do so. In short, your payment actions with these two methods are not anonymous and the GDPR and other relevant data protection regulations may apply if you are making a payment by credit card, PayPal, Swish or by bank wire. The data must be kept for the statutory retention period described in applicable local laws such as the Swedish Accounting Act (some information must be stored for seven years from the end of the fiscal year). That "some information" according to Swedish Accounting Act (bokföringslagen): "Every transaction, including customer payments, must be supported by proper documentation such as invoices, receipts, and payment confirmations." https://mullvad.net/en/help/no-logging-data-policy https://mullvad.net/en/help/no-logging-data-policy / https://archive.vn/qkvD3 https://archive.vn/qkvD3
      - ijustlovemath 2y ago
        Sure, but if privacy matters to you, you have the option of buying credit anonymously and applying it to an anonymized account number. And if your threat model includes nation states, you're definitely not buying anything with a credit card. I also think if you're after payment details, there's more lucrative targets, eg Stripe.
        ignoramous 2y ago
        OK. I was just wondering about your "zero trust" (aka "no database of user info etc") comment in the face of those and other Swedish laws that apply to Mullvad, is all. What you're now telling me is only if I, as a user, don't give Mullvad my info, they wouldn't have to store that. I mean, that's one way or one way of looking at it, alright.
conradev 2y ago
Timing attacks are notably not a part of Tor's threat model, i.e. they are a real concern: https://support.torproject.org/about/attacks-on-onion-routing/ https://support.torproject.org/about/attacks-on-onion-routin...
- Imustaskforhelp 2y ago
  hmm. that is interesting , would you mind sharing some solution , what if I add some insane latency (I know unusable but if it prevents timing attacks) my conspiracy spidey sense is sensing something fishy... Maybe timing attack is not part of .onion addresses ?
  - woofcat 2y ago
    Mixnet would be a solution. Like what you described, have inbound packets held for some period of time and released as a group so that you cannot as easily correlate the inbound and outbound traffic. The downside is that it gets much slower, and feels 'bad' as an end user. Each packet takes longer.
  - conradev 2y ago
    The only solution I know of is essentially to do "bandwidth burning" where you inject a bunch of fake traffic as noise. I don't know how you'd do that within the constraints of this system.
dongcarl 2y ago
(Carl from Obscura here) > Does Mullvad have the budget and expertise to protect itself against determined, highly-resourced attackers? I think Mullvad is actively working on [System Transparency](https://www.system-transparency.org/ https://www.system-transparency.org/), which will help a lot. > Finally, is it possible for a third party, intercepting traffic between Obscura and Mullvad, to identify the public key used to encrypt it? I don't think so - the only way to validate a signature is with both keys; that's kind of the point. But maybe there is an attack I'm unaware of? I had asked this question a long time ago on either a noiseprotocol or wireguard IRC channel, and the answer is no, a third party intercepting traffic between Obscura and Mullvad, WON'T be able to identify the public key used to encrypt it.

dang 2y ago

Thanks! that blog post had a thread here: Trust, 2-Party Relays, and QUIC - https://news.ycombinator.com/item?id=43016574 https://news.ycombinator.com/item?id=43016574 - Feb 2025 (33 comments)

vidyesh 2y ago
That blog needs some inline padding for mobile view.
- 0xEF 2y ago
  It's insane to me that this even has to be pointed out with such a relatively simple page, and then I looked at the source; it screams "I'm gonna just bang something out in [popular framework] without knowing basic HTML/CSS and let the world suffer from my <div> rot." I hate modern web development.
  - vidyesh 2y ago
    I agree. Its not that difficult to just have a max-width of 90% for the content or just add some padding to the inner container. I also think people skipping over learning some basic CSS fundamentals also end up skipping over basic UI/UX needed for accessible websites, something every web developer should have some awareness about. Complete reliance on CSS frameworks does not magically make the websites accessible,it gets you 90% there. Also /blog leads of 403!? Wildcard redirects are not that difficult to setup either.
- gchamonlive 2y ago
  And it's not even that hard if the page is built in a sane way, which for the simplicity of the blog should be a no brainer to go for simplicity. I have my blog hosted at omg.lol and while I had to support mobile by myself, it was really really simple. Here is my blog: https://xd1.dev https://xd1.dev Here is the code for the blog's responsive layout: https://github.com/gchamon/xd1.dev/blob/main/css/responsive-layout.css https://github.com/gchamon/xd1.dev/blob/main/css/responsive-... No injection, no build, just plain inline linking https://github.com/gchamon/xd1.dev/blob/10b98ddb37a9786ca8fef251d37163a2dceca206/configuration/template.html#L11 https://github.com/gchamon/xd1.dev/blob/10b98ddb37a9786ca8fe...

conradev 2y ago

> somehow log & associate each decrypted IP packet against the users public key. Mullvad only needs to associate each decrypted IP packet against an assertion that the packet was paid for. I assume each Obscura node would have a public key, but not associated with a user. They notably offer this service for Tailscale (as an add-on) and I imagine that it works similarly (on the backend)

yardstick 2y ago
Yeah my thinking is even if they don’t have the users IP, knowing and seeing all the traffic associated with a specific public key would allow them to build a profile of the user. Eg based on the specific sites visited, payload sizes potentially, domains looked up, etc you’d be able to characterise the person. Especially so if anything they did was not encrypted, or they have their own vanity domain (for emails or anything else). > Mullvad only needs to associate each decrypted IP packet against an assertion that the packet was paid for. The idea of Obscura is by using two middlemen (them + Mullvad) that neither party can figure out who the end user is. So I’m looking at Mullvad from the perspective of: if they were evil, what about this solution are safeguard protecting the end users privacy. And my conclusion is they’d still be able to break the users privacy in the same way as knowing the users IP, just without the IP.
- conradev 2y ago
  In Tor, individual websites get individual circuits to prevent this sort of profiling, and I think Obscura would need to do the same for the same level of anonymity.

dongcarl 2y ago

(Carl from Obscura here) This is actually quite an interesting point that we’ve been discussing internally. Right now Obscura rotates your WireGuard key on every “Connect”, but in a future release we will start caching (persist) your WireGuard keys on your client. When we flip that switch, we will also enable recurring key rotation and add a button in the UI for manual key rotation. This rotation would make it harder for Mullvad to track a user across the same key. (Not that they would anyway) All of this is available for folks to verify at on our GitHub repository: https://github.com/Sovereign-Engineering/obscuravpn-client https://github.com/Sovereign-Engineering/obscuravpn-client

yardstick 2y ago
Thanks for the reply, and glad to know it’s something you’re already thinking about!