[kwlug-disc] Russia seizes VPN servers

[B. S.]

> On Mon, Jul 11, 2016 at 10:13 PM, Chris Irwin <chris at chrisirwin.ca>
> wrote:
>
>> Not specifically Linux-related, but I thought this might be
>> relevant to users here.
>> ...
>> Today, VPN provider "Private Internet Access" sent out the
>> following information:
>> ...
>>> ... For preventative reasons, we are rotating
>>> all of our certificates. Furthermore, we’re updating our client
>>> applications ...
>>
>> I'm worried they only noticed (and reacted quickly) *because* they
>> take security seriously. What about other services?

Presumably encrypted traffic, e.g. ssh / https, is secure only during 
transmission, and keys are regularly rotated during such. i.e. 'short 
term' encryption.

Doesn't mean source or dest files are encrypted / secure / safe. So if 
they get the server (physical security), all bets may be off. Similarly, 
if something else can get to the server (network security), or on the 
server itself (server / user security). Even encrypted, access means it 
can be broken, eventually, if the actor is sufficiently motivated. 
(Given limited resources, they'll work on apparently low hanging fruit 
first.) i.e. 'long term' encryption.

Presumably little one can do about the latter, except trust the 
provider, I suppose. Use a strong key, I suppose. [Seems typical to use 
a super strong key to negotiate, less so to store. Do I misread the 
typical?]

How effective / useful is rotating the certs, here? I can see how with 
possession of the certs an intermediary (MITM) can be inserted to 
decrypt ongoing / on the fly (i.e. presumably useful only during 
transmission), and rotating the cert soonest obviates that. Is there 
more there than that?


On 07/11/2016 10:33 PM, Mark Steffen wrote:> I've got a VPS hosted in
the basement of a big black building halfway
> between Washington and Baltimore just off the 295, it's apparently a
> VERY secure facility.  Throughput is great, though I do get ssh
> complaining sometimes, I have to clear some stuff out in ~/.ssh/ for
> it to stop complaining and connect. Weird. It was a great price
> though, and secure. I keep all of my passwords, and router configs
> there as an offsite backup as well as archives of all my email,
> financial information, and evil plans.

You're mostly talking about physical security. In theory a given - 
doesn't speak to non-physical access. Again, it seems to go back to how 
trustworthy a vendor is - and under sufficient duress, they aren't, so 
it comes down to how interesting your data is and how motivated they 
are. (If the authorities say give me your disks or face fines or jail or 
worse, you're going to give them your disks.) Presumably they need court 
orders / probable cause to take such possession, but that doesn't have 
to be for your data - it could be on another customer's, and you get 
caught up in that net.

I wonder if you're running into ssh key / cert changes. That could be 
part of a regular rotation (presumably documented somewhere that they do 
that), or casual changes, which makes one wonder about their procedures. 
At the least there should be a different band key / cert fetch process - 
although I don't remember ever seeing such for ssh. (Usually I end up 
taking the line out of known_hosts and just knee-jerk saying yes to the 
new key at next connection. I guess I probably shouldn't, at least not 
without a different band fetch / verification of the change.) [This is 
much like fetching the gpg keys for a repository separately, which are 
then used to verify the files coming down via apt-get - both checksum, 
and verification sourced from the expected producer.]

I suppose I should investigate such ssh connection key rotation 
processes some day. e.g. some ssh parameter to fetch a new cert from a 
different source path, and updated known_hosts before next connecting.