Ξ welcome to cryptostorm's member forums ~ you don't have to be a cryptostorm member to post here Ξ
Ξ any OpenVPN configs found on the forum are likely outdated. For the latest, visit here or GitHub Ξ
Ξ If you're looking for tutorials/guides, check out the new https://cryptostorm.is/#section6 Ξ

Havenco.com - seriously guys... wtf? "Private" keys not-so

Freewheeling spot to chew the fat on anything cryptostorm-related that doesn't fit elsewhere (i.e. support, howto, &c.). Criticism & praise & brainstorming & requests for explanation... this is where it goes when it's hot & ready for action! :-)
User avatar

Topic Author
cryptostorm_dev
ForumHelper
Posts: 19
Joined: Wed Jan 23, 2013 5:31 am

Havenco.com - seriously guys... wtf? "Private" keys not-so

Post by cryptostorm_dev » Wed Jan 08, 2014 3:10 pm

When people are going about setting up an OpenVPN-based secure networking system, there's a bunch of steps - and decisions - relating to the generation and propagation of RSA keypairs & certificates. This, in turn, gets entangled with the entire PKI/CA framework... which is not always simple to understand without some firsthand experience. There's a handy easy-rsa toolkit that comes bundled with the source package... but it's famously not quite as "easy" as some folks wish it were.

Over the years, we've seen some pretty bad errors of configuration made by "VPN companies" that were clearly staffed by inexperienced operators struggling simply to get the least-complex and/or default version of a "VPN service" running - so that they can start taking creditcards and billing people as fast as possible.

Needless to say, this is rarely a great idea for what are supposed to be "secure" services. And yet, it's very common to see - in part because the "journalists" who cover these services rarely have the technical expertise or even a minimal desire to understand the structural guts of what's going on. If the press release, as in a famous recent example, says that a "VPN service" is immune to all attacks except possible imaginary "alien technology" brought to our planet by green-skinned ones... then most "journalists" will print that right up. Particularly if the logo in the press release matches that of their advertisers.

So, when we've tried to shine a spotlight on these serious errors, we've found ourselves largely ignored. Or, in a surprising number of cases, actively attacked: by trolls, by the "VPN companies" themselves, or by the "journalists" who failed to do this work in the first place. It's sort of a thankless activity. And yet, we keep doing it. Why?

  • note: "we" are Baneki Privacy Labs, a nonprofit tech/OpSec research collective loosely affiliated over they years with the cryptostorm darknet team; we're a separate project and while we do have some staff and subject-focus overlap with cryptostorm, our goals are decidedly more purely focused on digital activism, censorship-busting, and empowerment via tech education & sharp research campaigns


We do it because there's alot of people trusting these "secure" services to protect themselves from serious harm online. Snowden's disclosures of the vast NSA spying infrastructure confirmed what many of us suspected or had inferred already: weaknesses in security online aren't merely "theoretical" in today's day and age, and "crypto snake oil" garbage that promises the moon but delivers nothing can and does cost people their families, their careers, their peace of mind, their freedom... and sometimes their lives.

So, yeah, we think it's a pretty big deal. That's why we keep pounding our heads against this particular wall.

This week, we were doing some testing of the newly-rebirthed HavenCo "security" suite. We routinely run new services, tools, and project through the paces to keep abreast of what's happening in the wild, out there. This time, we found a sadly perfect example of how bad it's become in the "VPN company" industry - just as MORE security is needed, standards seem to have gone through the floor.

Once we set up our test account with HavenCo, we downloaded the "certificate" for OpenVPN (it's not a "certificate" - it's a configuration file, with inlined certs & keys). You can download one, too - it's publicly available right here. The copy we got is found in this file, unedited from downloaded version:
gw1.iad1.vitalng.com.openvpn.udp.ovpn
(6.22 KiB) Downloaded 486 times
Screenshot of the linked-to page (which is, itself, at least requiring user/pass authentication to view... but, sadly, the linked-to .ovpn configuration file is publicly available, as anyone can confirm with a wget):
havencoblurred.png
What's wrong with this picture? Quite a few things, actually. Let's look at the underlying configuration file, in pieces:
# redirect all outgoing traffic to the vpn gateway
redirect-gateway
This directive needs a parameter to be effective, i.e. -- redirect-gateway def1 ...as it stands, it won't do anything and is ignored by the daemon at runtime.
# verify the server certificate for authenticity
remote-cert-tls server
The correct syntax for this directive is -- ns-cert-type server
cipher AES-256-CBC
While this specifies the symmetric cipher used in the data channel, it leaves all control channel and HMAC cipher suite selections to default to lowest-common denominator. This is a bit like locking the windows, but leaving the front door with only a child's bedroom lock to protect against intruders. Essentially pointless.

Now we look at the RSA certificate (for the client? - hopefully):
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
1024-bit RSA keys have been strongly recommended against for nearly ten years - there's absolutely no excuse to still be using them, period. Everyone knows this. And yet, we continue to find "VPN companies" using these old, old keylengths. No, ignorance is not bliss - not in this scenario.

Very bad. But it gets worse, fast....

Here's where the real problems begin. We're going to quote from the OpenVPN manual on this matter:
You should never need to copy a .key file between computers. Normally each computer will have its own certificate/key pair.
But what do we have here... inlined in the shared, common, generic client configuration file? Yep, a "private" key - shared amoungst anyone who downloads this config:
<key>
-----BEGIN PRIVATE KEY-----
MIICeAIBADANBgkqhkiG9w0BAQEFAASCAmIwggJeAgEAAoGBAMqp/gXrFASElUb7
kFDInvlb6ZT8Vfm1QdiBD3AfvzqVisV9cPDue/mvDyn1JYOHrswUrkmSYATBsV3e
DyJfc77TYiKqn0afCtSK7CeJ0syDwm9cCRqjbQV7NjF3hSgUg0JSHFOlTQMxo8DF
unEAzSjUhgVIZQyPSQYCe8tcNcKpAgMBAAECgYEAsHf5M1oQ4iY4fciLT2yB0QvR
huN6UacdINKwiKd8Mh0I6xJhh8mBtlZS0+wcsD0zXY0cff+xEDNAqEW10+5dr11Y
zYpViacZRMQnrzBEYcTSqlfHXg2PZxu4c08ndwDxjm03Vgg5RKvQnGRMRy4lH/HP
OiAkb9oJgR0R5sccZgECQQDmfVZF2UBn4u2scjfcPl4XsUrPO8eyie995c7s7Cz1
TDiecLCesjLRf97RexfhhwNJurfCZUWNJ9hkq5hUGzvJAkEA4Rg/ziL74sBh+jT6
2TaAqnmHDWZlrfCfKtlm1z4TQ5E6WpjKNXN3qfKW069QGnRjZn8zuPwgMpBPXeaT
jHH/4QJBAJslbvchX7sOA1H6qCM2T/u+uU55PNivBGhIUlskNrb/EXWFAT4xUQe3
/PIg21hRmyL77kmKBaEYWw6YerbShhECQQCX2Rb6BamszyGJfAIZVGY6Gp+bz48a
Zy/I5T42R/8Q3sDh6x7GLi30rN1I0oSURB3mQDtxOEy0L5wK+Yhh/2mhAkAGXya9
wUOcSz96jUgnMfiVoBT3BNszzn/HLKCipCPd/eR3FEvpfmNN+olkd09cONMDKCcW
CfHad9moALon0bIV
-----END PRIVATE KEY-----
</key>
As one of our researchers might say, in his inimitable style, when a tragic error has been pushed to production: sigh.

This "private key," which is supposed to be ONLY used for individual clients and NEVER sent "plaintext" across the wire, is available for anyone to download and use. Indeed, keys should be generated locally, if at all possible, and never transmitted to another computer even over secure channels!

Having access to this "private" key enables all sorts of possible MiTM and session-hijacking attacks. We leave it to the imagination of clever readers to brainstorm the various ways in which this obvious vulnerability can be exploited, automated, and extended. It is a big field...

That's bad enough, right? But wait - there's more.

Experience suggested that we do a quick google search on the first line of the private key, to see what comes back. Nothing should, of course - it's supposed to be a PRIVATE key, used only once and custom-generated for each client on the client's own computer. That's the security model. So google shouldn't turn up anything if we search for, say...

Code: Select all

MIICeAIBADANBgkqhkiG9w0BAQEFAASCAmIwggJeAgEAAoGBAMqp
What happens when you do? Give it a try.

Sigh.

Yes, there's another publicly-available config file out there - this time for a me-too "VPN company" calling itself "GhostPath VPN" and bragging about how many servers (121!!!) they have in how many countries (39 countries!!!). They even have a cool little ghost-esque .favicon for their webpage. Yay.

But... how about that actual configuration file for actual "secure" networks sessions? Let's go to the code, shall we?

Here's the full text that's sitting under that link we found via google search on the "private" key for HavenCo:
#viscosity name GhostPath > Spain - Madrid
#viscosity ManageAdapter True
#viscosity startonopen false

remote mad1.gpvpn.com 8888 udp

dev tun
tls-client
persist-tun
persist-key
auth-user-pass
#comp-lzo
nobind
pull
cipher AES-256-CBC
redirect-gateway

<ca>
-----BEGIN CERTIFICATE-----
MIIDQDCCAqmgAwIBAgIJAM8Brk2pUr0KMA0GCSqGSIb3DQEBBQUAMHQxCzAJBgNV
BAYTAlVTMQswCQYDVQQIEwJDQTEMMAoGA1UEBxMDVlBOMQwwCgYDVQQKEwNWUE4x
DDAKBgNVBAsTA1ZQTjEMMAoGA1UEAxMDVlBOMQwwCgYDVQQpEwNWUE4xEjAQBgkq
hkiG9w0BCQEWA1ZQTjAeFw0xMjAzMDMwMjExNDJaFw0yMjAzMDEwMjExNDJaMHQx
CzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEMMAoGA1UEBxMDVlBOMQwwCgYDVQQK
EwNWUE4xDDAKBgNVBAsTA1ZQTjEMMAoGA1UEAxMDVlBOMQwwCgYDVQQpEwNWUE4x
EjAQBgkqhkiG9w0BCQEWA1ZQTjCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkCgYEA
wY2K08N7or1Br/EsD9XBon7gs7dKflWYuymgMLJfeMFWuJloNdsn+3GARIhYBbN6
zhvFGFE214qKPqAydW1WmIIK7KoC0sgndr+Vk/au9gssFzVmmvr6+WN/nfo2L9Kv
vBMoYLrMAiyw/D4cRapZi2pXJLcMDfC+p1VWAX8TYWkCAwEAAaOB2TCB1jAdBgNV
HQ4EFgQUmyvO4rTnu5/ABnp0FngU+SdR8WAwgaYGA1UdIwSBnjCBm4AUmyvO4rTn
u5/ABnp0FngU+SdR8WCheKR2MHQxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJDQTEM
MAoGA1UEBxMDVlBOMQwwCgYDVQQKEwNWUE4xDDAKBgNVBAsTA1ZQTjEMMAoGA1UE
AxMDVlBOMQwwCgYDVQQpEwNWUE4xEjAQBgkqhkiG9w0BCQEWA1ZQToIJAM8Brk2p
Ur0KMAwGA1UdEwQFMAMBAf8wDQYJKoZIhvcNAQEFBQADgYEAoB0kOuGvrzPBTIRX
IDHCCxBMdny+3sKAOllmH4+51j2aWhAJ4Pyc/yBTYyQGNoriABjmNzp+R05oiaxA
D3vTgR80juKDPtQb8LoGLBF18gL7Vtc3+hJXcJasXZaDSSoyh5f+TtGvytIT+ece
JWIrKnFXzlHOvKlyLkcZn15gwKQ=
-----END CERTIFICATE-----
</ca>
<cert>
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 2 (0x2)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=US, ST=CA, L=VPN, O=VPN, OU=VPN, CN=VPN/name=VPN/emailAddress=VPN
Validity
Not Before: Mar 3 02:12:57 2012 GMT
Not After : Mar 1 02:12:57 2022 GMT
Subject: C=US, ST=CA, L=VPN, O=VPN, OU=VPN, CN=client/name=VPN/emailAddress=VPN
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (1024 bit)
Modulus:
00:ca:a9:fe:05:eb:14:04:84:95:46:fb:90:50:c8:
9e:f9:5b:e9:94:fc:55:f9:b5:41:d8:81:0f:70:1f:
bf:3a:95:8a:c5:7d:70:f0:ee:7b:f9:af:0f:29:f5:
25:83:87:ae:cc:14:ae:49:92:60:04:c1:b1:5d:de:
0f:22:5f:73:be:d3:62:22:aa:9f:46:9f:0a:d4:8a:
ec:27:89:d2:cc:83:c2:6f:5c:09:1a:a3:6d:05:7b:
36:31:77:85:28:14:83:42:52:1c:53:a5:4d:03:31:
a3:c0:c5:ba:71:00:cd:28:d4:86:05:48:65:0c:8f:
49:06:02:7b:cb:5c:35:c2:a9
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Basic Constraints:
CA:FALSE
Netscape Comment:
Easy-RSA Generated Certificate
X509v3 Subject Key Identifier:
E7:44:BD:DB:F0:77:30:D0:9E:B8:57:E6:AD:5C:C9:FA:17:07:FB:60
X509v3 Authority Key Identifier:
keyid:9B:2B:CE:E2:B4:E7:BB:9F:C0:06:7A:74:16:78:14:F9:27:51:F1:60
DirName:/C=US/ST=CA/L=VPN/O=VPN/OU=VPN/CN=VPN/name=VPN/emailAddress=VPN
serial:CF:01:AE:4D:A9:52:BD:0A

X509v3 Extended Key Usage:
TLS Web Client Authentication
X509v3 Key Usage:
Digital Signature
Signature Algorithm: sha1WithRSAEncryption
98:8f:26:a8:4d:b4:03:6c:49:98:2b:61:04:75:0c:76:3d:fd:
a9:4a:57:06:14:64:ed:76:50:d5:8c:81:5c:20:27:82:df:da:
d2:c7:e3:30:81:90:26:c0:c5:36:1e:2c:0a:99:4d:d2:61:c1:
1a:a5:fb:e0:6d:ec:4a:24:da:d3:b9:a1:18:d8:6a:83:5f:7a:
2c:a7:db:05:c8:4d:9f:63:67:1d:a0:aa:8c:ed:0d:1b:d4:36:
73:fd:2d:b7:8e:c3:c8:e7:e8:ed:03:93:71:1c:c0:a4:ed:d6:
e9:23:9c:3c:20:4b:69:18:a1:a2:15:26:9e:fd:62:da:41:a1:
25:bc
-----BEGIN CERTIFICATE-----
MIIDizCCAvSgAwIBAgIBAjANBgkqhkiG9w0BAQUFADB0MQswCQYDVQQGEwJVUzEL
MAkGA1UECBMCQ0ExDDAKBgNVBAcTA1ZQTjEMMAoGA1UEChMDVlBOMQwwCgYDVQQL
EwNWUE4xDDAKBgNVBAMTA1ZQTjEMMAoGA1UEKRMDVlBOMRIwEAYJKoZIhvcNAQkB
FgNWUE4wHhcNMTIwMzAzMDIxMjU3WhcNMjIwMzAxMDIxMjU3WjB3MQswCQYDVQQG
EwJVUzELMAkGA1UECBMCQ0ExDDAKBgNVBAcTA1ZQTjEMMAoGA1UEChMDVlBOMQww
CgYDVQQLEwNWUE4xDzANBgNVBAMTBmNsaWVudDEMMAoGA1UEKRMDVlBOMRIwEAYJ
KoZIhvcNAQkBFgNWUE4wgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAMqp/gXr
FASElUb7kFDInvlb6ZT8Vfm1QdiBD3AfvzqVisV9cPDue/mvDyn1JYOHrswUrkmS
YATBsV3eDyJfc77TYiKqn0afCtSK7CeJ0syDwm9cCRqjbQV7NjF3hSgUg0JSHFOl
TQMxo8DFunEAzSjUhgVIZQyPSQYCe8tcNcKpAgMBAAGjggEoMIIBJDAJBgNVHRME
AjAAMC0GCWCGSAGG+EIBDQQgFh5FYXN5LVJTQSBHZW5lcmF0ZWQgQ2VydGlmaWNh
dGUwHQYDVR0OBBYEFOdEvdvwdzDQnrhX5q1cyfoXB/tgMIGmBgNVHSMEgZ4wgZuA
FJsrzuK057ufwAZ6dBZ4FPknUfFgoXikdjB0MQswCQYDVQQGEwJVUzELMAkGA1UE
CBMCQ0ExDDAKBgNVBAcTA1ZQTjEMMAoGA1UEChMDVlBOMQwwCgYDVQQLEwNWUE4x
DDAKBgNVBAMTA1ZQTjEMMAoGA1UEKRMDVlBOMRIwEAYJKoZIhvcNAQkBFgNWUE6C
CQDPAa5NqVK9CjATBgNVHSUEDDAKBggrBgEFBQcDAjALBgNVHQ8EBAMCB4AwDQYJ
KoZIhvcNAQEFBQADgYEAmI8mqE20A2xJmCthBHUMdj39qUpXBhRk7XZQ1YyBXCAn
gt/a0sfjMIGQJsDFNh4sCplN0mHBGqX74G3sSiTa07mhGNhqg196LKfbBchNn2Nn
HaCqjO0NG9Q2c/0tt47DyOfo7QOTcRzApO3W6SOcPCBLaRihohUmnv1i2kGhJbw=
-----END CERTIFICATE-----
</cert>
<key>
-----BEGIN PRIVATE KEY-----
MIICeAIBADANBgkqhkiG9w0BAQEFAASCAmIwggJeAgEAAoGBAMqp/gXrFASElUb7
kFDInvlb6ZT8Vfm1QdiBD3AfvzqVisV9cPDue/mvDyn1JYOHrswUrkmSYATBsV3e
DyJfc77TYiKqn0afCtSK7CeJ0syDwm9cCRqjbQV7NjF3hSgUg0JSHFOlTQMxo8DF
unEAzSjUhgVIZQyPSQYCe8tcNcKpAgMBAAECgYEAsHf5M1oQ4iY4fciLT2yB0QvR
huN6UacdINKwiKd8Mh0I6xJhh8mBtlZS0+wcsD0zXY0cff+xEDNAqEW10+5dr11Y
zYpViacZRMQnrzBEYcTSqlfHXg2PZxu4c08ndwDxjm03Vgg5RKvQnGRMRy4lH/HP
OiAkb9oJgR0R5sccZgECQQDmfVZF2UBn4u2scjfcPl4XsUrPO8eyie995c7s7Cz1
TDiecLCesjLRf97RexfhhwNJurfCZUWNJ9hkq5hUGzvJAkEA4Rg/ziL74sBh+jT6
2TaAqnmHDWZlrfCfKtlm1z4TQ5E6WpjKNXN3qfKW069QGnRjZn8zuPwgMpBPXeaT
jHH/4QJBAJslbvchX7sOA1H6qCM2T/u+uU55PNivBGhIUlskNrb/EXWFAT4xUQe3
/PIg21hRmyL77kmKBaEYWw6YerbShhECQQCX2Rb6BamszyGJfAIZVGY6Gp+bz48a
Zy/I5T42R/8Q3sDh6x7GLi30rN1I0oSURB3mQDtxOEy0L5wK+Yhh/2mhAkAGXya9
wUOcSz96jUgnMfiVoBT3BNszzn/HLKCipCPd/eR3FEvpfmNN+olkd09cONMDKCcW
CfHad9moALon0bIV
-----END PRIVATE KEY-----
</key>
Look familiar? If you're in touch with your inner Rainman, it'll be obvious: it's identical, down to the character, in cert/key detail to the HavenCo data in their config file. So this "private key" is not only shared between all HavenCo customers... it's also being used by an entirely different "VPN company" and all their customers.

This is, as they say, suboptimal. Don't worry, however - according to their marketingspeak...
GhostPath Encrypts Your Traffic

With GhostPath, every packet of data sent from your PC is encrypted. This means that you can access all the data from any website you want to visit, without worrying about criminals being able to intercept your data and without sending out any data about your own web location. It guarantees a safe, secure and stable browsing experience, without the performance issues that come with web-based proxy servers.
{boldface added}

(note that the link to the client configuration file - http://ghostpath.com/servers/filegen/mad1.gpvpn.com/v - seems to suggest that there's some sort of "filegen" thing happening... but there's not, as even basic testing shows that the exact same config file is generated from any browser when that URL is visited; we didn't poke at it to see the underlying server architecture, but it'd be interesting to know what's actually going on behind the scenes... and, yes, you can go to the 'servers' page and confirm that every one of the configs for each of their 'servers' - actually cheap little VPS instances - has exactly the same cert/key/ca information embedded in it... so much for 'filegen' eh?)

- - -

It might be asked whether we contacted HavenCo and/or GhostWhatever about these tragic flaws in their basic secure networking deployments. No, we didn't. This is grade-school level stuff, folks - anyone taking MONEY from paying clients to provide a "secure networking" service should damned well know how to provision certificates and keys. Hell, there's decent YouTube videos explaining the process. This is not, as they say, rocket science.

Now, if we've somehow gotten this all wrong then we certainly welcome feedback from HavenCo and GhostFail - here in this thread, uncensored as always - explaining the finer details of their security model. Perhaps they'll send trolls here to attack our team personally via 1337 skiddie skillz (as Torguard did, last spring, when we pointed out their frightening terms of service and how they directly contradicts the marketingspeak on their own website). Or maybe they'll step up, admit their ugly errors, fix them, and do a better job of securing their paying customers.

How in Dog's green earth did this happen? How did TWO "VPN companies" end up sharing exactly the same cert/key/CI material... and doing so in exactly the same broken manner? We couldn't find a match with the 'default'/testing files in the current OpenVPN builds - but perhaps there's an older easy-rsa package that includes these files as samples? Or perhaps someone stole them from the other company, rather than going to the "trouble" of making their own? We really don't know. In the end, it doesn't really matter.

That two completely separate "VPN companies" are using the same key material to "authenticate" the integrity of their servers is... darkly funny. The whole idea of the server-side RSA validation is to ensure bad actors don't masquerade as 'legitimate' (a somewhat risible word, here) servers and hijack entire "secure" sessions, wholesale: this isn't Man in the Middle, it's Man Stole The Shop. Having key materials floating around out there like this makes a mockery of that whole process (yes, to make a perfect mockery we'd need the server.key file, as well.... do you think it'd be hard to put hands on it, honestly? Neither do we.).

Indeed, it makes a mockery of the entire concept of a "secure network" - or, in the common parlance, a "VPN company." It's a bad joke.

And, no, these aren't the only examples. Last summer, we stumbled on another one - one that's still out there, pumping out insecure sessions and taking money from customers. We've warned them, privately. They've ignored us - it's crossed the corner from incompetence to outright fraud. And, yes, we'll be exposing them in fairly short order. There's a reason we've waited this long, which will be clear when it comes visible. There's surely more lurking out there than these three - we've noted a couple, informally, and a formal survey would likely turn up dozens and dozens. That's not counting the broken cipher suites, nonexistent TLS-layer DHE, corrupted PRNGs, buggy entropy sources, leaking client apps, mis-compiled OpenSSL libraries... it goes on, and on, and on.

It's sad that there's nobody out there doing this work for real: we mean that someone invests real time in exposing these broken "VPN company" models, and putting pressure on to drive out the charlatans and up the quality of service across the market. The formidable technical intellect of Jacob Applebaum pointed out the disastrous level of security offered by these me-too "VPN services" several years ago, but he's got other fish to fry nowadays (to put it mildly)... as, alas, do we. These peer-review efforts to expose broken "VPN companies" are a tiny fragment of Baneki's routine workflow: in a real sense, they take away focus from everything else we do.

Fortunately, we do receive some infrastructure and staffing support from cryptostorm... so we can afford to do a run like this, now and again. But, surely there's someone out there who would do this consistently, and systematically? I think, in the old days, they used to call them "journalists" - they seem to be absent from today's world, eh?

We'll do our best. In "paying it forward," we hope to raise standards across the board - and thus protect actual people from actual surveillance and the enormous costs that can come from a false sense of "security" while operating in a dangerous online environment.
We'll see...

~ Baneki Privacy Labs


coda: according to their footer, their "website protection" is rather impressive, too...
GhostOops.png
It's sad, because their SSL Labs report isn't bad at all - no PFS/DHE/ECDHE support, but still... however, alas, after you leave the main page all the rest of the site defaults down to paintext/bareback http. Oh, well... so much for SSL/TLS/HTTPS eh?

edited to add: actually, the "buy" parts of their website stay within https - but the rest of it seems to fall out into http and/or crash into unavailable .css files, as well.

Q.E.D.

User avatar

marzametal
Posts: 431
Joined: Mon Aug 05, 2013 11:39 am

Re: Havenco.com - seriously guys... wtf? "Private" keys not-

Post by marzametal » Thu Jan 09, 2014 2:46 am

What a read...

User avatar

DesuStrike
ForumHelper
Posts: 287
Joined: Thu Oct 24, 2013 2:37 pm

Re: Havenco.com - seriously guys... wtf? "Private" keys not-

Post by DesuStrike » Thu Jan 09, 2014 5:00 pm

Personally I find the whole history of Sealand very interesting and you probably could make a (short) movie about it. Especially the helicopter raid and the subsequent shootout to free the hostages that were taken by the casino-pirates are material for a pretty good action movie.

The fact that they sell royal titles for discount prices is very funny, too. :mrgreen:

Oh, and somebody told me the Princess of Sealand is a real hottie (though I wasn't able to confirm that.)


(Keep in mind that every royal term I use from now on is purely sarcastic.)
But apart from those things Sealand really hasn't a good reputation in my book. They already had a "censorship free" hosting service in the past and the whole thing died when they bowed to the crown of their protector and snitched on their customers. The royal family of Sealand also stated officially that they side with copyright holders and the related regulations of the United Kingdom when The Pirate Bay wanted to buy Sealand, thus not selling to them because they are "pirates".

Now after a couple of years and a lot of grass that grew over this incident they come back with a VPN-Service and play it all cool like "we are against censorship and for privacy and stuff!". Well, I don't buy their shit one bit! The family desperately needs funds because Sealand is a giant money sink and they just want to jump the bandwagon. Neither have they the knowledge to run such business nor have they the right mindset to not snitch on their customers as soon as some government goon comes along.

So it's really no wonder that this VPN is a pure COPY & PASTE job and overall badly made. Even if it was technically flawless I wouldn't recommend anyone to use their service. These people are not your friends but friends of whoever pays them the most.
home is where the artillery hits

Post Reply