Forums
New posts
Search forums
News
Security News
Technology News
Giveaways
Giveaways, Promotions and Contests
Discounts & Deals
Reviews
Users Reviews
Video Reviews
Support
Windows Malware Removal Help & Support
Inactive Support Threads
Mac Malware Removal Help & Support
Mobile Malware Removal Help & Support
Blog
Log in
Register
What's new
Search
Search titles only
By:
Search titles only
By:
Reply to thread
Menu
Install the app
Install
JavaScript is disabled. For a better experience, please enable JavaScript in your browser before proceeding.
You are using an out of date browser. It may not display this or other websites correctly.
You should upgrade or use an
alternative browser
.
Forums
Software
General Apps
VPN and DNS
Windscribe VPN Security Breach
Message
<blockquote data-quote="windscribe" data-source="post: 952704" data-attributes="member: 58131"><p>Just saw this thread, allow me to retort.</p><p></p><p>Firstly, we make no excuses for this omission. Security measures that should have been in place were not. Going forward, the following is true:</p><p></p><p>1. All keys required for server function are no longer stored permanently on any of our servers and exist solely in memory after they are put into operation</p><p>2. All servers have unique short lived certificates and keys generated from our new CA which are rotated</p><p>3. Each server certificate has uniquely identifying Common Name + SANs</p><p>4. New OpenVPN client configurations enforce server certificate X509 name verification using the common name which is unique.</p><p></p><p>This beings me to my next point: transparency. Had we followed "standard" industry practices, you would have never known this happened. We could have just sunset the CA with no explanation, under the guise of "new better network", <a href="https://www.privateinternetaccess.com/blog/private-internet-access-legacy-vpn-network-sunset-announcement-30-september/" target="_blank">kinda like PIA did</a> over 6 months after <a href="https://securitygladiators.com/pia-vpn-says-russia-servers-seized/" target="_blank">their servers were seized in Russia</a>, which required people to download new OpenVPN configs. There is no reason to do that, unless your keys were compromised.</p><p></p><p>Secondly, providers like Nord and Torguard, who had their servers hacked back in 2019, only came clean when their keys hit the web. Otherwise you can bet you would never hear about it.</p><p></p><p>Thirdly, the above 2 providers, and pretty much every VPN we tested (except IVPN which is doing things correctly, same as we do <strong>now</strong>), are vulnerable to the exact same issue, right now. Which you can empirically test yourself, by <a href="https://serverfault.com/questions/708577/how-do-i-connect-to-an-openvpn-server-and-dump-the-certificate-chain-presented-w/1018262#1018262" target="_blank">fetching their OpenVPN certificates</a> over the wire. Once you do, you will discover the following:</p><p></p><p>1. Pretty much everyone uses long lived certificates 1-50 years until expiry</p><p>2. Pretty much everyone is either deploying the exact same certificate + key to every server OR have unique certificates + keys, but without anything that's uniquely identifying in them. Which makes it useless.</p><p>3. Those who DO have unique common name or SANs on their certificates (nord and express for example), fail to actually make use of this data and perform X509 verification at the client (you should see verify-x509-name in the config). Express actually tried to do this, and simply copy/pasted the example from the OpenVPN manual, which is completely useless and has zero security benefits.</p><p></p><p>Effectively, a compromise of those certs and keys will yield the exact same situation, and considering how opaque the consumer VPN industry is, it likely happened and you just don't know about it.</p><p></p><p>We made a mistake, we researched the best possible way to mitigate it, and did so in under 3 weeks. It's in production, and you can verify that this is the case by looking at the OpenVPN certs + our configs. This guarantees that the same issue cannot happen, even if the server keys were to be compromised again for some reason. You can also verify that those providers that were previously affected did no research, and implemented an equally insecure "solution". Same goes for most other ones. Sure, some claim that their servers are all "RAM based", but can you truly prove that? The only thing you can prove is how their public facing OpenVPN infrastructure is setup, and that leaves no room for interpretation. If that's implemented incorrectly, what makes you think their RAM solution holds water?</p></blockquote><p></p>
[QUOTE="windscribe, post: 952704, member: 58131"] Just saw this thread, allow me to retort. Firstly, we make no excuses for this omission. Security measures that should have been in place were not. Going forward, the following is true: 1. All keys required for server function are no longer stored permanently on any of our servers and exist solely in memory after they are put into operation 2. All servers have unique short lived certificates and keys generated from our new CA which are rotated 3. Each server certificate has uniquely identifying Common Name + SANs 4. New OpenVPN client configurations enforce server certificate X509 name verification using the common name which is unique. This beings me to my next point: transparency. Had we followed "standard" industry practices, you would have never known this happened. We could have just sunset the CA with no explanation, under the guise of "new better network", [URL='https://www.privateinternetaccess.com/blog/private-internet-access-legacy-vpn-network-sunset-announcement-30-september/']kinda like PIA did[/URL] over 6 months after [URL='https://securitygladiators.com/pia-vpn-says-russia-servers-seized/']their servers were seized in Russia[/URL], which required people to download new OpenVPN configs. There is no reason to do that, unless your keys were compromised. Secondly, providers like Nord and Torguard, who had their servers hacked back in 2019, only came clean when their keys hit the web. Otherwise you can bet you would never hear about it. Thirdly, the above 2 providers, and pretty much every VPN we tested (except IVPN which is doing things correctly, same as we do [B]now[/B]), are vulnerable to the exact same issue, right now. Which you can empirically test yourself, by [URL='https://serverfault.com/questions/708577/how-do-i-connect-to-an-openvpn-server-and-dump-the-certificate-chain-presented-w/1018262#1018262']fetching their OpenVPN certificates[/URL] over the wire. Once you do, you will discover the following: 1. Pretty much everyone uses long lived certificates 1-50 years until expiry 2. Pretty much everyone is either deploying the exact same certificate + key to every server OR have unique certificates + keys, but without anything that's uniquely identifying in them. Which makes it useless. 3. Those who DO have unique common name or SANs on their certificates (nord and express for example), fail to actually make use of this data and perform X509 verification at the client (you should see verify-x509-name in the config). Express actually tried to do this, and simply copy/pasted the example from the OpenVPN manual, which is completely useless and has zero security benefits. Effectively, a compromise of those certs and keys will yield the exact same situation, and considering how opaque the consumer VPN industry is, it likely happened and you just don't know about it. We made a mistake, we researched the best possible way to mitigate it, and did so in under 3 weeks. It's in production, and you can verify that this is the case by looking at the OpenVPN certs + our configs. This guarantees that the same issue cannot happen, even if the server keys were to be compromised again for some reason. You can also verify that those providers that were previously affected did no research, and implemented an equally insecure "solution". Same goes for most other ones. Sure, some claim that their servers are all "RAM based", but can you truly prove that? The only thing you can prove is how their public facing OpenVPN infrastructure is setup, and that leaves no room for interpretation. If that's implemented incorrectly, what makes you think their RAM solution holds water? [/QUOTE]
Insert quotes…
Verification
Post reply
Top
