Hello. I’ve noticed that with each new version of the Suite, you block more VPN services that I use to access the application. In other words, with each new version, the number of blocked VPN servers increases. I strongly dislike this. I consider this to be a misguided security policy that should be optional, just like the use of Tor. If a user is not satisfied with this option, they should be able to go into the application settings and disable it, instead of having to search for a new VPN that you haven’t blocked yet.
Enabling Tor partially resolves the issue, but in my case, the Solana blockchain doesn’t work through Tor either. All other blockchains work fine, and I’m convinced that this is also due to your hidden blacklist of VPN services and servers.
In my home network, all devices and applications always work through a VPN that is installed directly on the router. This is my personal security and privacy policy, and there can be no exceptions. Applications either work through VPN or are not used at all. Your blacklist is preventing me from fully using the wallet, as Solana is currently not working. I know it works for other users who use Tor, so the problem is clearly with the VPN blacklist and the fact that it’s specifically used for Solana, even when the wallet is connected through the Tor integrated into your application.
By imposing such restrictions without discussing them with anyone, you’re creating a bad reputation for yourselves. People will talk about this in a negative light, specifically about Satoshi Labs’ unwillingness to respect clients’ private lives, which is very different from the company’s image.
This is my opinion and request. Please fix this. It’s not right.
Trezor Suite does not have any sort of VPN block list, which you can verify in the source code.
The backends, however, are protected by CloudFront anti-DDoS features, which frequently blacklist VPN public addresses, because – you guessed it – the people that run DDoS attacks like to do that through VPNs.
You’ll unfortunately need to take that up with CloudFront, or, better yet, with your local malware distributor.
Note that those blacklists are not totally ever-growing: in a lot of cases, VPNs are unblocked after some time.
The information you provided is not entirely accurate. I use a large, popular VPN provider with good reputation, and its servers are permanently blocked in Suite. Moreover, the number of these blocked servers increases over time, depending on the version of Suite. When updating, you can learn about new blockages. This means that the blacklist is embedded in the program. This should be made optionally disableable. For me, this feature is completely useless. Let those who are afraid of viruses working through VPN use it. I have a clean work PC with nothing extra on it, and I’m sure many others do too. Finances don’t tolerate carelessness. I don’t need this feature, and I’m asking to make it disableable. I understand that the developer wants the best, but there are two sides to every coin. From the user’s perspective, this can be seen as a lack of respect for private life.
I download new version of Suite and has updated ip black list. Becouse my current locatuon is no longer supported. I can use it in my previous version of Suite, and can’t use in current. Current 24.9.2, previous 24.5.3. Appimage in Linux.
About a year ago the same thing happened. I had to change the VPN server then. And the previous one remained permanently on the blacklist. When the VPN is on the (hidden) blacklist, wallets cannot get information from blockchains. Suite starts, but functions as if it has no network.
To second this. Trezor backends are constantly hammered by crawlers, and they are often using various mainstream cloud providers.
IP blacklisting happens on the server side, this can be verified in the Trezor Suite source code.
What I think is happening is you are creating new connection rapidly and the backend is flagging it a new connection from the same IP too quickly after a new connection.
You can experiment by switching the Solana backends, i.e. manually setting them from solana1.trezor(.)io to solana2.trezor(.)io
For the interest in troubleshooting, I’d be interested to know if the web version of suite is giving you trouble too.
to be clear: are you saying that a new suite will not load anything at all, and the old Suite loads recent transactions?
as opposed to, e.g., the old Suite having cached balances and history which is no longer updating?
to restate: you are arguing against a feature that does not exist. Blacklisting is happening on the server side. It would make no sense to do it on the client. Also it does not make sense to prevent users from using a VPN; quite the opposite, it would sometimes make sense to encourage it.
If you like, you can tell us one of your IP addresses that you think is currently blocked, and we can check our logs. If you don’t want to share an IP address publicly, please open a ticket via the chatbot bubble on Support | Trezor Knowledge Base and refer to this forum thread (and ideally also post the ticket id here)
Wrong or or unclearly explained situation. I previously wrote how it was. An update is being made. The program is being restarted. The updated version cannot connect to blockchains, despite the previous one being able to do so just before, and as I wrote, this has happened several times. Therefore, the error is ruled out. Either the black list is directly in Suite or Suite, when connecting to Trezor servers, reports the version and the servers have different black lists for different versions of Suite.
I’ve tried this before, it doesn’t work. Solana is always offline. Whether TOR is enabled or disabled makes no difference. Meanwhile, other users have told me that they can connect to Solana using TOR, but not using a VPN on their home network. And TOR doesn’t interfere with them in any way. This means that the servers are receiving information that Suite is functioning using a VPN connection that is on the blacklists, bypassing the TOR integrated into Suite. And that’s why Solana blocks the connection and can’t be used. There’s no other explanation. Unfortunately. It all looks extremely bad, and I hope you understand how it looks. And understand that other users can also understand this. The percentage of literate people using hardware wallets is very high. I’ve found this out a long time ago.
I explained above how it all happens. And this is not the first time, unfortunately. Therefore, the conclusions are completely obvious.
I don’t see the point in this. I think that the developers will either be satisfied with the criticism above to stop what can be considered suspicious behavior towards clients’ private lives, or they will ignore it, to the detriment of their reputation. It’s unlikely that a direct appeal to the support service will change anything. I don’t need my specific system to be excluded from the blacklists of the servers. I want the blacklists to become a disableable option for clients, wherever and whoever they may be. This is a matter of principle, related to the reputation and security of software that implies openness and trust from clients. I hope you understand me correctly. With respect to you personally and to the company you represent here. Goodbye.
I haven’t studied the details of how it works, but I assume the developers of the hardware wallet and Suite for computers could generate unique keys for encrypted connections to Trezor servers using the hardware wallets themselves. This would allow replacing blacklists with whitelists. And only clients connecting the hardware device would have access to the servers sensitive to attacks.
Interesting idea, but it can’t work, unfortunately.
Trezor firmware is open source, so any encryption keys baked into the firmware would get stolen immediately.
And if you generate the keys from your seed, there’s no way to prove to the server that you own a Trezor – in other words, anyone could make the keys from any wallet.
Even if you somehow managed to tie the keys to a particular Trezor, e.g., via the secure element, this would (a) identify you as a recurring user, so the server could tie your xpubs together and trace you across PCs and IP addresses, and (b) the watch-only feature would stop working.
…or, if you wanted to enable watch-only wallets, that means giving the keys to your PC, so bad actors can buy a single Trezor, grab the keys, and continue to hammer the Trezor backends same as before.
I think that if my proposal is well thought out, a method that suits everyone can certainly be devised. I’m confident that a wallet capable of autonomously signing transactions on the network can generate one-time session keys using only mathematical methods and nothing more. Of course, the seed cannot be used in a way that could compromise it, but there are mathematical methods that allow avoiding seed decoding while still using it to generate unique keys. I think you should be aware of this, and if not, you can study it yourself or consult with a developer who is well-versed in blockchain technology. The method I proposed allows for the existence of whitelists, and even if key theft becomes possible somehow, it won’t achieve anything. Since one device will only be able to connect to the servers once, and the key can be re-generated every time the wallet is physically disconnected.
I’d be happy to help you, but I’m a busy person and, first and foremost, I don’t have the time to deal with this. Secondly, the operation is more complex than it may seem. I simultaneously installed a new firmware and updated Suite. I don’t usually do this often, and the difference between versions was significant. Installing a new version of Suite or a new firmware version resulted in the old Suite, which I also kept, no longer working at all. The old version of Suite launches, but it doesn’t see the USB wallet (Trezor T). I assume this is related to the fact that the new version of Suite writes somewhere in the Linux cache files that the program has been updated, creating a software ban on running previous versions. Or the new version is no longer compatible with old firmware. I’m inclined to think it’s the first option, but it’s just a guess. Therefore, to conduct the experiments you proposed, I would need to clear the Linux cache and perform a clean installation of the Suite application several times. So that it thinks it’s being installed in the system for the first time and doesn’t see any information about updates. I don’t know Linux well enough yet to search for where and how your developers set up bans on using previous versions of the program in the system. In the most complex case, to conduct the experiment you proposed, I would have to reinstall Linux from scratch, on a clean disk, multiple times. This idea seems very labor-intensive and completely useless. I used the wallet just a few hours before installing the updates. I was receiving and sending cryptocurrencies from it. Everything worked perfectly in my usual home network, protected by the same VPN that I used after installing the updates. The updates broke everything again. The updated version only works in Tor. The wallets I used are displayed. I haven’t made any new operations yet, but I think there will be no problems with them. And everything works except Solana. And I essentially installed this update to get access to Solana. As a result, Solana is broken, the wallet only works through Tor, and I have to argue with the developers and think about the most sinister conspiracy theories. I specifically emphasize this because I see that you’re trying, obviously intentionally, to ignore my arguments. The situation has repeated several times in a row, with the installation of previous updates. Therefore, the experiments you propose, despite seeming useful and correct, look like just an attempt to impose a labor-intensive operation on me, which I will obviously refuse, and an attempt to devalue my argumentation. Which obviously proves what I’m writing without any additional experiments.
If you think this is a convincing method for conducting a discussion, then I’m afraid the conversation loses all meaning. And this is, of course, sad. But in principle, I was prepared for this. Given that the topic is partly provocative. And it was obvious that all non-trivial assumptions, in your direction, the developer would reject by all available means.
You’re not wrong here, but riddle me this: how do you propose to ensure that only Trezor devices can use this algorithm?
The algorithm would be a public part of the Trezor firmware. An attacker can run it on their server farm, simulating millions of Trezors.
Orrr you can just ask? There is no “ban on previous versions”, obviously, but our support team (cc @dk_SL ) will gladly tell you where Suite cache files are located on Linux. You have provided some details here so we can try to debug why the older Suite is no longer starting.
You are facing multiple issues at the same time. Far as I can tell, there’s no common factor to them, so they need to be resolved one by one.
Okay, listen.
You are observing some behaviors that are obviously undesirable. To explain the problems, you have come up with a feature and asked for its removal. You have stated multiple well reasoned arguments for its removal.
I am ignoring those arguments, yes, because there is no such feature.
You can verify I’m telling the truth because Trezor Suite is open source. You can review the source code yourself or pay someone unaffiliated with Trezor to do it for you.
But. If you went far enough as to come up with conspiracy theories, there is nothing more I can say that you will not write off as lying. Given that, at this point, you are intentionally ignoring my arguments, I will not be engaging with this line of conversation going forward.
I will still try to help if you provide more technical details to help us trace the actual source of your problem(s), of course.
A Trezor can use serial numbers by adding them to the firmware or on a special chip. The algorithm for generating the serial number is known only to the company, and therefore cannot be counterfeited, using a combination of seed and serial number, but rather only the serial number, it is possible to generate access keys that do not directly reveal the owner of the device, but will indicate that it is a genuine Trezor, whose serial number is not counterfeit, since the algorithm for generating the serial number is known only to Trezor and no one else.
I assume that Trezor already uses a similar algorithm to verify the authenticity of firmware. Therefore, it’s possible to simply extend its capabilities and everything will work out.
Based on this forum and another chat dedicated to hardware wallets, I see that many users are having issues with Solana. Therefore, I’ll hope that you’ll be able to handle it without my help. Maybe I’ll reconsider later, but for now, I don’t have the time to deal with it.