4.1.1 MLLVD-CR-24-01: Signal Handler’s Alternate Stack Too Small
4.1.2 MLLVD-CR-24-02: Signal Handler Uses Non-Async-Safe Functions
4.1.3 MLLVD-CR-24-03: Virtual IP Address of Tunnel Device Leaks to Net-
work Adjacent Participant
4.1.4 MLLVD-CR-24-04: Deanonymization Through NAT
4.1.5 MLLVD-CR-24-05: Deanonymization Through MTU
4.1.6 MLLVD-CR-24-06: Sideloading Into Setup Process
All pretty straightforward IMO. They lean on "DAITA" aka Defence against AI Traffic Analysis pretty heavily, which I don't fully understand yet, but is probably worth some further reading.
Safe signal handling has so many footguns that it seems worth re-considering the entire API.
Even OpenSSH has had issues with it [1].
It seems very difficult to build good abstractions for it in any programming language, without introducing some function colouring mechanism explicitly for this. Maybe a pure language like Haskell could do it.
Haskell's runtime is so complex that I don't think you can write signal handling functions in Haskell. The best you can do is to mark a sigatomic boolean inside the real signal handler and arrange the runtime for check for that boolean outside the signal handler.
Yup: see https://hackage.haskell.org/package/ghc-internal-9.1001.0/do... where it is clear that setting a handler simply writes to an array inside an MVar. And when the signal handler is run, the runtime starts a green thread to run it, which means user Haskell code does not need to worry about signal handler safe functions at all, since from the OS perspective the signal handler has returned. The user handler function simply runs as a new green thread independent of other threads.
But I like the fact that you brought up this idea. Haskell can't do it but in a parallel universe if there were another language with no runtime but with monads, we can actually solve this.
I am not sure but I think rust already allows safe signal handlers? The borrow checker makes you write thread safe code even without any active threading and signals are just emergency threads with some extra limitations... right? I don't understand this too deeply so I could be wrong here.
Rust does allow for safe signal handling, but it's sort of the same way that it allows for safe and correct interrupt handlers for people writing os kernels (signals are basically interrupts, just from kernel->user instead of hardware->kernel). You're basically constrained to no_std and have to be very careful about communications with the rest of the system using lock free mechanisms.
If handling a signal was equivalent to handling concurrency then it wouldn’t be as much of a problem.
IIRC a signal can take over execution of a running thread, so it will completely invalidate any critical sections etc. You cannot access any shared resource easily, cannot allocate memory and a lot more restrictions of this form.
Yes but the signal handling code acts as if it is on a different thread. So it cannot access the critical sections or mess up any existing state on the thread anyways. Sure the other parts need to be managed manually but just that should still go a long way. ...Right?
Not quite, by default the signal handler hijacks an existing thread. It is possible to keep a dedicated thread around that solely waits for signals, but that’s a workaround and you end up needing to also mask all signals from all other threads for correctness. And then there are also synchronous signals, which can’t be handled this way (eg. segfaults)
Imagine a scenario where the original thread state is in a critical section, in the middle of allocating memory (which may need a mutex for non-thread local allocations) etc.
The code within the signal handler can’t guarantee access to any shared resource, because the previous execution of the thread may have been in the middle of the critical section. With normal concurrency, the thread that doesn’t hold the mutex can just suspend itself and wait.
However, because the thread has been hijacked by the signal handler, the original critical section cannot complete until the signal has been handled, and the signal handling cannot yield to the original code because it is not suspendable.
Signal handling is distinct from a different thread because it blocks the execution of the “preempted thread” until the signal handler completes.
As a example, if the preempted code grabs a lock for a resource, then signal handler completion can not depend on grabbing that lock because that lock will never be released until the preempted code runs again and the preempted code can never run again until the signal handler completes.
A correct signal handler can never wait for a resource held by regular code. This precludes coordination or sharing via normal locks or critical sections.
The best thing you can do is set a global variable value and that’s it. Let your main even loop mind the value and proceed from there. Only do this in a single thread and block singles in all others as the first thing you do. Threads and signals do not mix otherwise.
You want signalfd, which may optionally fed to epoll or any of the other multiplexing syscalls.
Signalfd can mostly be implemented on any platform using a pipe (if you don't have to mix 32-bit and 64-bit processes, or if you don't need the siginfo payload, or if you read your kernel's documentation enough to figure out which "layout" of the union members is active - this is really hairy). Note however the major caveat of running out of pipe buffer.
A more-reliable alternative is to use an async-signal-safe allocator (e.g. an `mmap` wrapper) to atomically store the payloads, and only use a pipe as a flag for whether there's something to look for.
Of course, none of these mechanisms are useful for naturally synchronous signals, such as the `SIGSEGV` from dereferencing an invalid pointer, so the function-coloring approach still needs to be used.
> Another option is to use a proper OS that includes the ability to receive signals as a part of your main event loops
Every 'nix can do that. Your signal handler just writes a byte to a pipe and your main loop reads the pipe or fifo. The pipe/fifo is your event queue, which your main loop reads.
> The best thing you can do is set a global variable value and that’s it.
Seems kinda limiting.
If I've got a slow file download going on in one thread, and my program gets a Ctrl+C signal, waiting for the download to complete before I exit ain't exactly a great user experience.
Use select() or epoll() or kqueue() to see if your socket is ready for reading. That way you can monitor your global variable too. That’s the correct way to do it.
If you have multiple threads, you start one just to mind signals.
Signal handlers are extremely limited in what they can do, that’s the point. They are analogous to hardware interrupt handlers.
In fish-shell we have to forego using the niceties of the rust standard library and make very carefully measured calls to libc posix functions directly, with extra care taken to make sure so memory used (eg for formatting errors or strings) was allocated beforehand.
Or it's nearly impossible for a pure functional language if the result of the async signal means you need to mutate some state elsewhere in the program to deal with the issue.
I think that’s slightly orthogonal. It would still be safe, because you’d design around this restriction from the start, rather than accidentally call or mutate something you were not supposed to.
The problem with safe signal handling is that you need to verify that your entire signal handler call stack is async safe. Assuming purity is a stronger property, signal handling is a safe API without any more work.
The inflexibility due to the purity might cause other issues but that’s more a language level concern. If the signal handling API is safe and inflexible, it still seems better for a lot of use cases than an unsafe by default one.
Monads can be thought of as arbitrary function colourings, hence the prior mention of Haskell potentially being a good fit. Of course monads are implementable in almost any other language, but few have as much syntax sugar or general library support as Haskell does, except maybe Ocaml
Yeah, but how do you design a Monad that does the "tell this other thread to unblock and unwind its state because an external error has triggered? You know, the basic function of an interrupt?
1) Monads used to restrict the computation available in the context of a signal handler (or function coloring etc, basically a way for a compiler or static checker to determine that a block of code does not call unsafe functions)
2) The actual process of handling a signal received by the signal handler
I think me and the parent are referring to 1). 2) is also important, but it is not a signal specific concern. Even without a signal handler, if you want to write an application which handles async input, you have to handle the case of processing the input to do something useful (eg. let’s say you are writing an HTTP server and want to have a network endpoint for safely killing the thing).
I think the generally recommended way to represent 2) in a pure way is to model the signal as a state machine input and handle it like all other communication.
Stack too small - there's no proof the 8k allocated is too small, is it really exploitable?
Non async functions - pretty common problem but difficult to actually exploit. Every developer who has worked with signal handlers has probably made this mistake at some point because the issues it causes are extremely difficult to reproduce (some incredibly unlucky timing is required)
Arp leaking addresses - Not really a Mullvad issue and only exploitable on the local network
Deanonymization attacks - these work against all VPNs and you can always anonymize traffic more but it has a cost to do this.
Sideloading - Yeah this is probably the worst one but is not exploitable on it's own.
I was going to go on a little rant about public audit reports that say stuff like "this company is very secure and is doing things great and this audit confirms that" --- not at all an x41-specific complaint, virtually all assessment firms are guilty of it, some much more than x41.
But: they found a triggerable heap corruption vulnerability in a Rust program, which is a nice catch.
I do think giving the vulnerability that follows that one a sev:hi, despite it being both theoretical (I don't think they have a POC) and not corrupting memory, is grade inflation though.
This is a nice audit report. The dedicated threat model section is something that a lot of auditing outfits skip over in their reports. While I'm positive Cure53, Assured, and Atredis (the previous auditors) established an appropriate threat model with Mullvad prior to engagement, it's not explicitly written out for the reader, which opens up room for misinterpretation of the findings.
> established an appropriate threat model with Mullvad prior to engagement
Doesn't this make it kinda pointless? If the target has a say in how they should perform their audit/attack, how does that not produce results biased to the targets favor? Wouldn't the most unbiased way to do such a thing would be for the target to have zero idea what the auditor would be doing?
> which opens up room for misinterpretation of the findings
If Mullvad dictated how to do things or imposed limits on the reach of the testing, the results are worthless anyway
Because the client often has actual knowledge of their design and the places where they want force to be applied to find weaknesses, because they're trying to evaluate the results with regards to specific outcomes, not every possible open-ended question you can think up. On top of that there is a reasonable limit in terms of time/money/staff/resources that can be spent on these kinds of audits, etc. For example, if you're using a cloud provider it's not like you're going to pay them infinity money to compromise GCP over the course of 9 months through a background operator compromise or some nation-state attack. You're not going to pay them to spend all day finding 0days in OpenSSL when your business runs a Django app. You're going to set baseline rules like "You need to compromise our account under some approaches, like social engineering of our own employees, or elevating privileges by attacking the software and pivoting."
It's mostly just a matter of having a defined scope. They could of course say "You can only attack this one exact thing" that makes them look good, but this is true of many things.
Defining the threat model is standard in the infosec auditing/pentest world, FWIW.
> If Mullvad dictated how to do things or imposed limits on the reach of the testing, the results are worthless anyway
That's only true if your threat model is "literally every possible thing that could ever happen", which is so broad to be meaningless and impossible to test anyway.
Computer programmers also do not typically design their programs under the assumption that someone stuffed newspaper between their CPU and heatsink and it caught on fire. They work on the assumption the computer is not on fire.
Say I manufacture door locks, and I ask you to audit the security of my system. Wouldn't it make sense to agree with you that stuff like lockpicking is fine, but going around the building, breaking a window and entering the room doesn't count as "breaking the lock security"?
That's the whole point of a threat model: Mullvad has a threat model, and they build a product resistant to that. When someone audits the product, they should audit it against the threat model.
No, the results would be worthless only if your threat model were significantly different than the one that Mullvad was operating under. In which case, having the threat model detailed explicitly is already valuable to you.
For example, this X41's threat model only supposes that an attacker could execute code on the system as a different, unprivileged user. They don't consider the situation where an attacker might have an administrative account on the system.
For my personal devices today, this matches my threat model. If an attacker has an administrative account on my machine, I assume that my VPN isn't going to be able to protect my traffic from them. There's no need to worry about laying out all the ways this could impact Mullvad's client.
> We believe the reason these vulnerabilities exist is because gocryptfs doesn’t have a clearly spelled-out threat model. Some of the attacks seem hard to avoid given gocryptfs’s performance goals and may have been introduced “by design” to meet these goals. We suggest writing down an explicit threat model and updating the website to better communicate the security guarantees that gocryptfs provides. This way, users are less likely to rely on it in ways which would make them vulnerable.
The way I see it you have to have a threat model, otherwise your problem space is way to big.
If I ask a person to do a audit I will tell them what the scope of their audit is, e.g. check the physical security measures of our server rooms. Otherwise they would have to take literally everything into consideration (what if the accountant is a malicous actor, what if the server rooms are attacked by a military, what if our hardware is swapped out during delivery, what if..) and they would never be able to stop.
If you take security seriously you try to defend against likely attack scenarios first. Your way to control that is by choosing the scope of audit.
It depends. Auditing the mitigations defined in threat model does make sense with say IEC 62443. This would not be only penetration testing done. But it is reasonable process. You want to know if the mitigations you have put in place against identified threats work or can be thwarted from outside perspective.
To do an audit you have to audit against some sort of pre-established criteria. That is how audits work. In security, that will typically be a standard (or set of standards) alongside a threat model. In finances, you audit against what is legal in the areas you operate.
>[...] zero idea what the auditor would be doing?
That's a practical impossibility. From the client side you want to be able to evaluate quotes, stay within a budget, etc. You don't want to pay good money (audits are really expensive!) for areas that you are works-in-progress, or non-applicable threat models (e.g. lots of security software explicitly does not protect against nation-state actors, so they don't do audits from the perspective of a nation-state actor).
From the auditor side, you want to know what staff to assign (according to their expertise), how to schedule your staff, etc.
>If Mullvad dictated how to do things or imposed limits on the reach of the testing, the results are worthless anyway
Not at all. The company says "This is the set of standards we are auditing against and our threat model. This is how we performed". The results are useful for everything covered by those standards and threat model. By explicitly stating the threat model, you as a consumer can compare your threat model to the one that was audited and make an informed decision.
Mullvad used to be great. But their stopping port forwarding makes torrents much worse. Their deprecation of openvpn sucks for me too. I have a couple usecases that need that. So I'm going to move to another one.
They still are great by any reasonable standard. Dropping port forwarding massively reduces the amount of abuse they have to deal with and only affects a tiny fringe of super nerds.
I still see tons of NordVPN sponsorship messages on youtube. I wonder if they've managed to pick up any good amount of regular people users or not. They sure do seem to be trying.
Pretty much every non-techy person I know under the age of about 50 uses VPNs for accessing regionally restricted streaming TV and sports[0] content, and getting around geoblocks (on US news sites that won't serve to Europe due to GDPR, trading/gambling sites, etc.).
I am pretty sure the sheer quantity of VPN ads on YT are also good evidence that they work and people are signing up. It wouldn't make sense to scale up a marketing approach to those levels unless earlier, smaller campaigns had positive returns.
[0] It's worth calling out explicitly the crazy lengths people will go to to both (a) find a free stream of a sports match; and (b) find a way to watch a match when they're travelling and can't access whatever service they usually watch it on.
I like NordVPN still. If there's any reason I shouldn't I'm all ears but haven't had an issue so far. I travel a lot and I definitely do feel better having my traffic routed through a VPN vs opening it up to whatever random entity happens to control the wifi I'm connected to, despite all the issues with them
I have nothing against NordVPN. I just generally agree with the statement that VPN users are either nerds or employees of companies that mandate it. But at the same time, I see Nord aggressively advertising to the general population - genuinely curious how successful that might be.
How long has it been like that? I've been torrenting via Mullvad for a while and occasionally low-seed torrents take a while to initialize but eventually I get them. Sometimes it means thinking ahead a few days for media that's more niche.
Mullvad did away with port forwarding about 1.5 years ago. https://mullvad.net/en/blog/removing-the-support-for-forward.... If im not mistaken its not your ability to download the torrents that is effected but your ability to really upload the torrents. If you belong to a private tracker with a strict seeding to downloading ratio i would use another VPN service for that
If a torrent has no seed with an open port, a peer without an open port won't be able to download.
This means having no port-forwarding shouldn't be much of an issue on private trackers (because most people have it to improve their ability to seed) but on public trackers some torrents might not download.
Unless you were actively using port forwarding before it wouldn't be any different. If you need a VPN for your torrents, despite these faults I don't know of a better one myself. I use the Firefox VPN (which is Mullvad under the hood and it's worked at least as well if not better than any alternatives for me so far.
Yeah it's a really important feature for many people. Torrents just don't really work without it. Three quarters of peers are behind NAT or VPN so without port forwarding they won't connect. If you have some Torrents with only a handful of seeders it makes it really difficult.
With the availability and ease of use of Seed boxes, this feature is kinda moot. It doesn't even cater to power users any more because they've all moved to seed boxes a really long time ago. This just leaves semi-serious individuals that want to take the risk of torrenting on their private internet connection.
Yeah I'm not a big torrenter but sometimes I want an old show that is only offered by a few seeders. And then most of them don't work due to this.
If you just want to grab the latest blockbuster it's no problem no.
I've never thought of getting a seedbox, i always thought the amount of storage required would be prohibitively expensive for a VPS. Also, I'd still want to use a VPN so the VPS provider isn't the only protection layer.
You'd be surprised how much storage space these seed boxes provide for very little cost. And these things aren't VPSs anymore. They're glorified SaaS products that give you Netflix streaming in a box, for less than the cost of Netflix itself. I would recommend doing a "reddit" search on the topic and you'll find many many recommendations and ideas.
Personally, I do it because of the "Netflix effect". Movies and series don't exist if they're not on Netflix (or your chosen streaming platform). And with my kids growing up, I want them to see the good shows and movies I grew up with just as they share the shows they enjoy now with me. I can comfortably say that 99.9% of that media is never offered on Netflix.
Everyone wants to seed, so it's over saturated. Thus you won't be hitting the limits any time soon, and if you get close you just manage it with limits.
But to answer your question, for 25TB I've seen packages that cost 20euro, which is pretty much the same as what Netflix premium charges in the US.
I'm not gonna advertise them here. Next thing you know the wrong person takes an interest in this area of the internet and spoils it for the rest of us.
Trust me, I looked at the page of my provider just now and that's what they offer.
They are not impossible to track, but that would be relevant only if Mullvad were severely compromised — and even then, we would only be in almost impossible territory.
There are no central repositories as to the location of arbitrary banknote serial numbers.
Lets assume, for the sake of argument, that a cash-paying user were to make the mistake of paying every single time to renew the same suspicious Mullvad account using cash which was always newly withdrawn from cash machines from a banking institution which meticulously tracks them and is able to report from which location they originated (maybe even the card which withdrew them!).
In that case, if Mullvad were to be compromised (or if the targeted user was such an absolute threat to humankind that Mullvad were to agree to collaborate in his or her capture), it would only be possible if Mullvad's mail receivers were to either a) actively keep track of either banknote serial number and link it to a customer, or b) be fully aware of the requirement to make a note of it only of received to renew the target account.
Anything short of that and even the perfectly traceable banknote serial number just becomes one of hundreds? thousands? deposited by Mullvad in their bank accounts — assuming they don't even use some of them as petty cash if needed.
If a user of Mullvad were to reach that level of a threat model I would argue they would be much more likely to be caught by tracking of their sent mail, in the style of Ted Kaczyński.
> There are no central repositories as to the location of arbitrary banknote serial numbers.
Why do you say that?
All that's needed is banks tracking serial numbers and associated persons as cash leaves the bank and enters it. The serial numbers on American cash seem machine readable, and on each bill they are printed in two places near opposite corners - as if they are designed for automated reading.
It doesn't have to be perfect, logically infallible, alibi-proof evidence. You could build a pretty good graph of who is doing business with whom, especially by examining repetitions of the same edges. At worst, it seems useful for intelligence tasks and to obtain worthwhile leads to pursue.
A serial number is not a tracking device. A sufficiently determined adversary with unlimited resources and access could maybe track you via it
But practically speaking an afternoon of shopping, exchanging coins for banknotes, breaking those into coins and back again will make it as untraceable as possible.
Especially since we're talking about 60 euro per year
I pay for VPN service with a credit card in my name that I have had for years. I'm not trying to hide the fact that I occasionally use a VPN. The ISP sees the tunnel, the websites I visit see the VPN IP, netflow logs the time, duration, bytes transferred, etc. It's no secret that I am using a VPN.
IMO, most VPN users are normal people, like me, who just want privacy from online advertisers and data aggregators. I do not want or expect privacy from the VPN provider. After all, I connect to their VPN service from my home ISP (which has an IP) that has an account in my name too.
No matter how you try to hide your payment for the VPN service, they know who you are.
IMO, technical people often 'go too far' and become unreasonable about these things (especially security people). They have lost touch with real-world threat models and use cases. James Mickens has a good short paper on this called 'This World of Ours' https://www.usenix.org/system/files/1401_08-12_mickens.pdf
It is probably the most reliable yeh, tho spending time here I’ve grown increasingly aware that the great firewall is more than aware of this vpn traffic, even if it’s wrapped up to look like normal traffic. They periodically will seem to ‘dial down’ the internet, especially at politically sensitive times. They are fully aware great swathes of the populace and visitors use VPNs, and they choose to allow it. They’d rather control and monitor than inspire even more opaque channels.
I should point out getting bitcoin anonymously requires some work too (if you buy BTC it is tied to your CC, and many exchanges require your ssn). Mullvad does allow you to send them cash anonymously in the mail as well.
That’s for accessing the website, not for sending your traffic via TOR to Mullvad. I don’t think they have a built-in way to send traffic to them via TOR without going through an exit node.
Oh, huh that's odd, why provide website access but then not actually product access when your product is a network service. Didn't think to read further than the headline because of that I guess, thanks for correcting me
same as with cash and crypto payment method it's to minimize data exposure outside of the service itself. If you don't trust them to connect with your ip why bother using a VPN instead of just tor.
I know it's a whole field of research and I'm not familiar with any of it, so I'm not saying this is a good reason, but what I understood from upthread (where the person mentioned you'd connect to Mullvad with your real IP address) is that they don't want either the ISP (or perhaps a tap) or someone subpoenaing Mullvad, to know that they're using Mullvad. By connecting via Tor, they don't know what you're connecting to, and if they go through the trouble of attacking Tor for you, they'll still land at Mullvad and they probably have to get a warrant for them to start keeping logs on all Tor users until they eventually can tie activities to an ISP subscriber
So I can see the reasoning, though anyone who considers this: I've heard years ago that they're not sure whether VPN-in-Tor or vice versa improves or degrades the anonymity, there are apparently reasons for either way, please read up on it before you feel safe using whatever solution in a regime without freedom of speech or something
I’ve never understood the neighbor approach. What’s the logic for that? Instead of your skin, it’s a person one door down from you, that was generous enough to share their connection with you? That’s not anonymity, that’s just outsourcing the identity to someone that probably extended trust to you. And if other things like Tor remove that connection, then what was the point of using a neighbor in the first place?
Generous to share? What makes you think the neighbor even knows about it? Also, one door down? They make antennas that can reach much further than that. If you're in a high rise building, you can even be picking up something from another floor in a different building more than one door down.
You're just not trying very hard if you're using your immediate next door neighbor.
This is an unnecessarily obtuse and pedantic response to the thought being raised.
Yes, a neighbor may not realize they're sharing their network, however, interpreting their "next door" comment as a literal unit of proximity doesn't make your comment look as intelligent as you may think it does.
This is an unnecessarily obtuse and pedantic response to the thought being raised and doesn't make your comment look as intelligent as you may think it does.
Ignoring BTC anonymity fallacy, does it even matter? If they don't store any logs as they claim, they can know anything about you, but won't be able to rat you out to authorities even if they wanted to, because you are just one of thousands of customers and any of them could have been using that IP the police is asking about. Am I missing something?
VPNs are a great business these days, but I don't feel that they treat their customers properly, or that they're transparent about what they provide.
My sense is that there's a lot of BS going on. Including the fact that "cool" VPNs are supposed to be coming from Scandinavian countries (but most of them aren't).
I don't understand this comment. At best it's tangentially related, but it's also worded vaguely enough to sound like Mullvad (the topic of this post) is doing something bad.
Mullvad states they're based on Sweden -- are you claiming they aren't? They list where all there servers are located and who owns them, if that's your concern.
They seems to have extensive information about why you'd want to use a VPN or not. They don't log customer data and moved to a RAM-only infra. They're cheap with one flat rate.
So what exactly would you call BS? What would you like to see them do different?
> Including the fact that "cool" VPNs are supposed to be coming from Scandinavian countries (but most of them aren't).
I don't understand what you are implying. Neither why are they supposed to, nor why it isn't true. To be fair, the only "strong privacy", etc VPN I know that is not Scandinavian is ProtonVPN. Is there something else?
Yeah it's a mess as a consumer you have to verify that even the most basic things work. Years ago I was using Nord when I discovered that it was silently failing to actually connect me to the VPN despite showing I had connected, so I reported the issue and they told me not to worry it was a known issue. To my knowledge, they never issued any security disclosures.
I work for IPinfo and am trying to find out if any open-source projects would implement this feature, particularly in a status bar configuration.
The implementation will be super simple. Set up your local IP address or IP address range (if you are on a dynamic IP address connection). Consistently call 'ipinfo.io/ip' every 5 seconds to check if the IP address is changing from your home IP address. You will get an alert if the IP address changes. So, when you turn on your VPN, this notification should alert you that your IP address has changed.
I would recommend using the 'ipinfo.io/ip' with a public IP address-based implementation as you can get a virtually infinite amount of queries. With just an 'ipinfo.io' query which gets you the location information as well, you get 1,000 queries without a token. This could work if you reduce the API call rate to a higher interval (not at a second level but only at a minute-level interval). But you do get the location information, which validates the VPN's location information.
I am a happy mullvad customer since about 5 years. I find it somewhat reassuring that they are not spending a gazillion dollars advertising on YouTube or affiliate websites.
And of course prefer that they are in a jurisdiction that isn't a haven for shady companies.
In short: I like them because there is little bullshit and they seem to be OK. I don't think I could ever trust PIA or all of those companies.
I never said I was against their AFK advertising. The EU chat control advertisement was great. The NYC stuff is pretty meh. Advertisement is was on my brain. I mostly treat it like that.
I just find it weird that there seems to be so many companies spending a seemi gly infinite amount on affiliate advertisement (through bought reviews) and on influencer ads.
Youtube and Reddit are the worst. I am pretty convinced the aggressive blocking is not because of abuse, but because VPNs actually have become a problem for tracking and data mining.
I have the suspicion the IP blocking is somewhat coordinated between Youtube and Reddit, to maximize annoyance and discourage VPN usage, since I frequently find exit server working for either one of them, but not both. Disrupting the ping pong of social media for VPN users, seems like an effective strategy to influence their behavior. And since they are natural monopolies respectively, they hardly risk alienating anyone doing so. Similar to how cookie banners are abused to modify people's sentiment on privacy regulations in favor of data mining. Even many tech people believe annoying cookie banners are the EU's fault, when common practice is either malicious compliance, unwarranted or straight illegal.
That said, it is actually fucking annoying. Then again, just a nuance in the greater enshittification and rapidly growing dissatisfaction with the web overall for me.
>Youtube and Reddit are the worst. I am pretty convinced the aggressive blocking is not because of abuse, but because VPNs actually have become a "problem" for tracking and data mining.
FTFY (added scare quotes)
I don't see blocking tracking and data mining as a problem at all, but rather a very good thing.
A lot of their endpoints are rented or hosted from ASes that are well known, e.g. M247 Ltd. If I wanted to vastly reduce annoying VPN traffic, I'd simply block these ASes as well. That's likely the cause of these.
There isn't a lot Mullvad can do about it. Not all providers of hosting are willing to tolerate VPN endpoints in the same way they don't like hosting tor exit nodes.
hCaptcha seems to be increasing in popularity, have tasks that actually stump current bots, and not discriminate by IP address.
reCAPTCHA is the GoDaddy of CAPTCHA services. It doesn't achieve its purpose and the CAPTCHA task is often just a time waster. It's already decided whether you're a bot or not - which is not based on your mouse movements, but rather your IP address reputation and whether you're signed into Google. It only still exists because of brand inertia. I'd like to see a Google executive put before Congress and forced to complete a reCAPTCHA over Tor.
Is there any serious website that reviews (rank list) these VPNs? I say this because it is always difficult to find information that is not sponsored on the internet. In fact, I've always heard that Mullvad is one of the best, even supporting P2P
These rankings are going to be meaningless and littered with blog spam. VPNs as a category are mostly snake oil. The only real world use for vpns is circumventing censorship if you live in a place that censors. The only privacy you're gaining is that from your ISP.
But you are giving very little to the ISP to begin with. You can use encrypted DNS and most web content has TLS. The only gap there is SNI, which we should be able to close with TLS ECH. I don't know why ECH has been so slow to roll out.
Encrypted DNS is certainly an improvement, but it's only as anonymous as the IP address you are connecting to.
I am not aware of any firewalls that enforce the rule 'only attempt to connect to massively-shared cloud IPs that can't be easily subject to a reverse DNS lookup'.
I don't think that's the only real world use for VPNs. For instance, you might be working remote from a foreign country and not want your employer to know that. It's not something that I would recommend, but you know it happens.
Yup. I am in awe of what a great job VPN providers have done marketing this stuff to people, just how utter convinced they are they need them.
It's next level marketing and it's amazing. Making an entire market almost overnight out of nothing.
How so? If Mullavad says about their no-loggind policy[0], they couldn't help any authorities that are asking about particular IP and particular timestamp. Obviously doesn't save you from Mossad spies under your bed, but it seems to be a big deal nevertheless. Isn't it so?
I get what you're getting at, but no, in hindsight, I like my privacy and security watchdogs to be transparent. Like Bruce Schneier. And for a counterexample, Satoshi. I lost my trust in anonymous randos, for authenticity, I like someone with a professional face and contact info.
It's nice to see confirmation that Mullvad isn't smoke and mirrors. It's the only VPN I use. It's pretty much guaranteed that if you go looking, you're going to find vulnerabilities. They took it seriously and fixed it immediately, which is reassuring. I'll continue using Mullvad.
If you’re lucky enough to structure your entire app in advance to keep in mind how sync signals are delivered, you can ususllly get away with only setting an atomic Boolean, incrementing an atomic int, or setting a binary semaphore.
The presence of signals in UNIX made me reach the following conclusion: event loop should be mandatory (or at least opt-out), something setup in the CRT before main(). Of course, we're not living in such a well-made C world.
> Virtual IP Address of Tunnel Device Leaks to Network Adjacent Participant
> X41 recommends to mitigate the issue by setting the kernel parameter arp_ignore to 1 on Linux.
> It is also recommended to randomize the virtual IP address for each user on each connection if possible.
... isn't randomizing the virtual IP address makes the situation worse? sounds like the best solution would be just give every user the same boring static IP address like 169.254.199.1/30.
For each session. Keys are rotated frequently, so a lot of noise could be produced. The only and one address is a good strategy for anti fingerprint though, but it is not easy to achieve for WG tunnels and pure L3 routing.
Personally I don't really get their multi hop when you connect on a predefined port on an ingress server to get redirected to egress in a different region. Easy guessable for a powerful observer.
Anyway any VPN is only an encryption tool, not an anonymizer.
A key selling point of WireGuard is it can roam between networks very well, without interruption to the connections within tunnel. Rotating IP address once you roam to another network (or just flaky wifi) ruins this.
One of my use cases for VPN is to watch free, legal anime on YouTube from Muse-Asia. I use a VPN to connect to Indonesia, which allows me to watch anime like Dandadan. a US IP won't show anything on their Youtube page. I'm using Mullvad VPN.
That's a very stupid and offensive response, considering the OP explicitly wrote: "One of my use cases for VPN is to watch free, legal anime on YouTube from Muse-Asia."
You are probably aware of the "Great Firewall of China" that blocks access from mainland China to Google, Meta, etc... Which means that if you are a westerner in China and want to access the internet as you know it, or if you are Chinese and access the rest of the world, then you need some kind of VPN to bypass the restrictions.
The Great Firewall is quite advanced, and you need some layers of stealth not to be detected and blocked. Furthermore, they actively search for VPN endpoints and block their IP addresses. It limits your choice of VPNs, and Mullvad is one of the good ones for that purpose, along with Astrill and LetsVPN.
Not in China, but in a similar country using DPI inspections to block. Neither Mullvad nor any other rank and file VPN works. Need to use something like xray to bypass.
What I understand is that they are using machine learning techniques to detect access patterns. Even if they don't understand the bytes because it is encrypted, they can match the sizes and timing of packets. So if the tunnel over SSH technique is common, and they detect a SSH connection that behaves in a specific way, for example because of fixed-size handshake packets, they can guess it is tunneling a VPN.
When I was in China I would use my own VPN using ec2 and the now defunct Streisand (which uses stunnel). First few requests were always fast but as you use more bandwidth your requests would start to slow down considerably.
Oddly a foreign sim gets uncensored internet, so that's what I've recommended to travelers, but haven't been back since COVID so that might be outdated info.
do you mean, xray to a vps and install mullvad on that vps? Tried that, but as soon as I install mullvad on a vps, I'm no longer able to ssh into it. Gave up, too complex.
Have you cared to check the tiers they offer?
Hint: not that many, and no free ones.
And knowing that mullvad doesn’t come close to the mainstream marketing others (well in essence one) VPN providers, your comment comes of as malicious.
It had a vary suspicions statement.
They stated that they see specifically a lot of Mullvad ads.
Not general VPN ads. That is what makes is sound malicious.
Mullvad is not even close to being in the group of biggest marketing spenders.
You need a minute on their website to see that they have a very simple approach to funding their business. No "life time subscription" exclusive offers, no BS privacy claims...
Also this is HN, not a comment section on something like Yahoo news, really hard to consider people commenting here as being detached from tech trends and news.
>They stated that they see specifically a lot of Mullvad ads. Not general VPN ads.
I've only seen VPN ads from one company actually plastered in metro stations and inside subway cars: Mullvad. I've never seen physical ads for any other VPN provider.
I've seen lots of horribly annoying ads (or "sponsor segments") from various other VPNs, and I'm sure I've blocked orders of magnitude more of them by using SponsorBlock. But for real, in-person ads? Only Mullvad.
I'm not criticizing Mullvad here. In fact, this is probably a smart strategy on their part: if you're too clueless to use an ad-blocker online, you're not going to see other VPN providers' ads very much. But if you're highly privacy-focused, you'll already be using an ad-blocker and probably SponsorBlock too if you watch YouTube videos, so you really won't see other companies online ads much. But you can't miss physical ads on your subway ride. Their ads are also cute and clever, pointing out that a piece of paper stuck to the wall isn't tracking you the way most internet advertising does.
Mullvad has a small number of well targeted ads in my experience.
If the person above frequents certain torrent trackers, reads Torrent Freak, or travels in other small VPN adjacent circles then it's no stretch to imagine they have seen Mullvad mentioned a great deal, both through ads and through unsponsered forum members ranking Mullvad high on their HOWTO safely do {X} guides.
Thinking outside the uBlock box most of the Mullvad advertorial placement I see is from Best VPNs for the coming Dystopia articles and host forum site banners (not on typical ad black lists), fellow user guides, etc.
So, not Mullvad ads being blocked but actual Mullvad themed content positioned as of direct interest to the target demographic.
Especially from someone who doesn't know all that much about the VPN business beyond seeing ads for it in some public locations and the very basics of what it is.
Nit: they have a partnership with Tailscale to offer the VPN as a part of a tailnet that subscribes to the service.
But, it's not white label. White label implies it would be Tailscale VPN (or similar) with no reference to Mullvalad in their docs or marketing. But that's not what is happening with their offering.
and they've been accepting bitcoin since 2010. I assume they've done very well from that (I'm afraid to calculate what the present value of my mullvad subscription would be)
Why would they have done well? they likely use a payment processor who dynamically price their € fees in Bitcoin and immediately liquidate all Bitcoin received.
I have never use Mullvad VPN but I can give two recommendations:
If money is no concern, use Astrill. Easy of software, number of countries, GFC, circumvent geoblocking, it is one of the best, if not the best, but it comes with a big price tag attached. I think 300 USD/2 years if I remember correctly.
If you don't need the best, AirVPN has often deals for 50USD/2 years. But the servers are very "spammy" (tons of captchas for you to solve).
Mullvad has had multiple public audits and even contributed to other security-related open source projects. You don't have to create an account and they even take cash by mail. It can't be more anonymous than that.
Astrill on the other hand has had no public audits, and costs more than twice as much. It is not worth the price, since their security can't be checked by normal users. Also they require an account.
Furthermore even in their FAQ they don't say that they wouldn't give the data to a court. They ask the question, but don't really answer it.
Please don't give judgements if you dont have an idea what are you talking about.
Just use the best programming language. Ups? For what application? Yes, everything depends on the application. Honestly, I doubt that many VPNs are better then Astrill if it comes to the GFC. I mentioned, it comes at a price. But if you are price sensitive, Mullvad is still nearly double the price of AirVPN....
"Mullvad has had multiple public audits and even contributed to other security-related open source projects."
"You don't have to create an account, and they even take cash by mail. It can't be more"
Well, I dont think any of my recommendations takes cash by mail, but that may take bitcoin. And for the applications you are hinting at, it is much more important that you connect via Tor to your VPN. One thing gives anonymity, the other privacy.
"Furthermore even in their FAQ they don't say that they wouldn't give the data to a court."
ROTFL. Every company will give data, or the data they have, to a court. At least in their own jurisdiction. Yet, there are (or were) VPNs that were cyberspace only. No corporation, just a website. A business that is not incorporated and only exits in cyberspace may indeed have a lot of leverage. At this point, you may ask yourself what you are doing. But if it is really so important, I would start setting up my own servers and selling my own VPNs. A tree you can hide best in a Forrest.
"I would never buy a VPN from a company like that."
If everything you have is a hammer, every problem becomes a nail. Everything depends on your application and what you want to achieve.
Why do you think Astrill is one of the best? And why do you think it is better than Mullvad?
I trust Mullvad because it does security audits like this. And it stores no data and has a history of police showing up without any data compromised [1].
Astill works on most OS, software is extremely slick, has many servers, at my time even Mainland china IPs were possible. Works reliable in China, is often NOT detected as a VPN (geo-blocking, Banks, captchas). They even offer fixed IP addresses, if desired. If you ask why would you have a fixed ip address and if this does not contradict the idea of a VPN you may have little international experience and don't understand the different applications of a VPN. Hey, there may be people that give a f... about the privacy it offers because they have totally different applications.
If you want a Mercedes of VPNs, likely Astrill is the choice. If privacy is your main concern, there are many options. Dont mistake privacy for anonymity. If in doubt, pay with Bitcoin and use TOR to connect to your VPN.
For my current application, AirVPN is more than enough. Two years: are 79 €, if they have a special, it is 49 euro. If you are cost sensitive, Mullvad is double the price already, but at least only less than half of the Astrill price.
Not true. There are enough places where you can buy BTC for cash. In Austria, you can buy at gas stations or in the post office. As long as you use a fresh wallet and only one time, I don't see who this could identify you. It may be backtracked to Austria, of which I am not a citizen.
Bitcoin are non fungible and by design traceable. Anybody can figure out where they came from and gas station and post office have security cameras. Use the right tool for the job which is monero.
Not sure why you are giving plugs for two lesser-known VPN providers (at least I’ve never heard of them) that are adopting less secure practices such as requiring email for sign-up and are more expensive than Mullvad, that is widely considered one of the most trusted VPN providers. Also I’m currently using Mullvad in mainland China right at this moment, it works perfectly fine.
https://x41-dsec.de/static/reports/X41-Mullvad-Audit-Public-...
Titles of issues they found:
4.1.1 MLLVD-CR-24-01: Signal Handler’s Alternate Stack Too Small
4.1.2 MLLVD-CR-24-02: Signal Handler Uses Non-Async-Safe Functions
4.1.3 MLLVD-CR-24-03: Virtual IP Address of Tunnel Device Leaks to Net- work Adjacent Participant
4.1.4 MLLVD-CR-24-04: Deanonymization Through NAT
4.1.5 MLLVD-CR-24-05: Deanonymization Through MTU
4.1.6 MLLVD-CR-24-06: Sideloading Into Setup Process
All pretty straightforward IMO. They lean on "DAITA" aka Defence against AI Traffic Analysis pretty heavily, which I don't fully understand yet, but is probably worth some further reading.
https://mullvad.net/en/vpn/daita