New on LowEndTalk? Please Register and read our Community Rules.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
All new Registrations are manually reviewed and approved, so a short delay after registration may occur before your account becomes active.
Comments
The employees at these larger companies often do have access - how else are they supposed to support the customers? They just don't care what's going on past why you're talking to them. Nobody wants to risk losing their job just to go poking around one of thousands of systems they have access to. Not to mention it's wrong
I'm a Linux SysAd at Rackspace and I work with our enterprise hybrid (dedicated+cloud) customers and even though I surely have access to some sensitive things, it's not worth losing my career/livelihood to go poking around where I shouldn't. I'd be wary of the smaller hosts, which the cheap VPS market is full of.
And you ignored the very part of my message that answers your entire "counterpoint".
Well, just get a cheap old AMD, like FX... they are known for a non backdoored bios.
Put glue into all ports, PCie Lanes, USB Ports...
Just enought to let the disk access to power and SATA.
Encrypt the DIsk, write a bash scripts which ensure if network connection is lost, server will be powered down.
Use also a non redundant power supply, so non one can switch power without you know it.
Profit? Of course its not bullet proof for hacker attacks but if someone tries to confiscate it, they gonna have some fun.
No I didn't - because the same logic applies to that as well.
The host a) can sniff the network and b) has access to the unencrypted part of the disk that has everything needed to establish an SSL session with a remote host supplying the FDE decryption key. LE has a playbook on that as well. Want me to let you in on a shared secret ?
Not saying dedicated is not safer than a VPS but here's some scary stuff for you: https://en.wikipedia.org/wiki/Side-channel_attack
ADD kid, learn to fucking read.
When you are personally at the console of two servers, enable the HTTPS link for 5 seconds on one, switch windows and fetch the key on the target server, then visually check in the logs of the first one that there has been exactly one access. But feel free to misread or skip over something else in this explanation as well, ffs.
Just go with a well known provider if you're worried about your code being stolen. Provider should never access or download client files on a VPS, you should be more worried about cheaper hosts who underpay their staff to incentivize abusing their access.
No - the host has access to the unencrypted part of the disk containing openssl (or whatever) used to establish this HTTPS session. I'm suggesting that the host can overwrite that package with a compromised version that provides no entropy, thus allowing the host to sniff the aforementioned HTTPS session off the network and decrypt it.
I have never done it, but I think it can be done practically w/o the customer knowing that she or he has been compromised. SSL only stops man-in-the-middle -- it doesn't stop man-at-the-end.
That's called an Evil Maid attack, and is an order of magnitude deeper and more complex invasion -- AND it can be rather trivially detected, unless done really well (i.e. replacing not just OpenSSL, but also things such as md5sum/sha1sum/who knows what other kinds of trip-wire you have implemented, heck, you could run a custom kernel which checks digital signatures of everything). AND requires considerable server downtime (for exploration and deployment) anyway.
Compared to a VPS which just can be sniffed stealthily all day long, with the entire RAM contents down to the CPU registers and cache.
I don't think this is doable in modern day SSL, actually. They can do a number of things via a replaced piece of software, but this particular one sounds unlikely.
I agree with this.
The bootloader can be copied pretty quickly for inspection during a short, "ordinary" downtime - no need to copy the encrypted volume.
Possibly - I don't know enough about SSL to say. I just remember that Debian weakened their openssl in the mid-2000s.
Here you go: http://rand.pw/howsecure/
I totally agree:
Basically, any reputable provider will not go snooping through client's files just because they are bored.
Totally agree. In fact any "reputable provider" is never going to be bored. They've got work to do, which is what makes them reputable.
What are the justification moments when the host can/should/must check client's VPS? Will any LET host spy on my porn collection?
They will definitely spy on you porn collection, they will even give you a free recurring promo to let you keep doing this.
What about all the kiddie hosts/summer hosts/one man band hosts which which we have on here.
Don't buy from them? Is it really that difficult to understand.
Trusting that "oh but they will not" is not a good security paradigm. That's like mailing your usernames and passwords around on postcards, and trusting the post workers and the postman not to read them, because the post is "reputable".
I did say reputable.
No, but it's a good first step. Like I put on my website, it's all about how much privacy you need and whether the cost is worth it. For me, I'll gladly pay $1 a month for an OpenVZ VPS to run pings from and if the host wants to look at my Node.js script then that would suck but I wouldn't lose anything because of it (and if they tried to use or sell it I would be sure to make an LET thread about it but I wouldn't lose any sleep over it). It's not worth it for me to host that script on a $2/month KVM VPS so I'd rather go with a host I can trust than fork out more cash.
Now would I host my WHMCS install on a $10/year OpenVZ VPS? Hell no. Would I host my family photos and tax documents on a VPS where I don't own the hardware? Nope.
The OP needs to host sensitive source code on the server. Your "running pings" have relevance to this thread ...exactly how?
No need to copy disk, Simply stop VPS and mount it to a directory and check files, etc.. I no longer remember it how to do this but I was did this for recovering my crashed VPS to recover my data instead of wasting time in rebooting with rescue CD.
It was an example of the risk vs trust.
ssl does not stop MITM somehow magically. As for the server the real nightmare is that someone from the provider could get at your private key. Having that he has you by the balls no matter what funny openssl you use.
To offer a somewhat more constructive line for less experienced users (probably the majority here):
As the short aŕticle linked by @KueJoe correctly says, there is no such thing as a secure server unless you happen to be nsa, gchq or similar (and btw, even they fuck up sometimes). But that doesn't mean that all is lost and you are fucked no matter what.
The probably most important factor on your (any users) side is that your data/communication is almost certainly of very low to low medium interest/value. That's important because - like any war, btw - it comes down to a cost,efforts vs value,gain ratio.
In practical terms that means that the level of safety/security most of us want/need is achievable.
So let's classify things a bit:
Security: Minimal. Stay away with anything of any value to you.
Security: medium. Probably the best compromise in the sub 10$/mo segment.
Up to here the important differentiator is that provider can look at your stuff without you being able to even notice it
Security: high (for normal users)
All that said, by far more dangerous than "KVM or dedi?" is how poorly most users are regarding security. So, keep your system up to date, configure it properly, and have a look at your logs from time to time!
Finally a small hint: If your dedi leasing period comes to an end and you do not intend to stick with your dedi, delete everything yourself!. Do not rely on the provider. Frequent unpleasant events through ebay will tell you why (you don't want someone to buy a 2nd hand hard disk and get your private keys and other sensitive data thrown in for free ...).
I'd probably be ok with storing that providing I'd heavily encrypted it clientside first, no worse than throwing it on cloud storage.
>
What do you mean? That's the whole point of SSL, in regards to HTTP traffic. Or do you mean, it doesn't stop people from bypassing it by sniffing at some other point before the traffic gets encrypted?
But what if it was a provider who promised to secure your data with a dragon?
Not some obese mall cop datacenter guard...I mean an actual Ancient Red Dragon. I know a provider who apparently has them on retainer and uses them to protect their customers' data. It's pretty sweet.
The photos and documents might look like kindling to the dragon... I would wrap it in a fireproof safe (client-side encryption) first.
In theory. In practice we know that there have been successful MITM attacks.
You're saying that hosting providers have 0-day access to crypto exploits?
Unless we're in the "they can do anything" zone, which is a conclusion and not an argument, SSL does what it should.
@endlesslhk I consider my civil duty to share my porn with my hosting provider.