Hotel privacy

[1 Z]

I used the computer at my latest stay, and as always browsed for diapers.                  

What was different this time was the look the manager gave me when I came out of the little office. I wonder if he somehow was monitoring my screen. Any thoughts?

 

 

[Dartplayerinwvc]

NEVER USE hotel wifi... it has the same password as the next room and office

[Little BabyDoll Christine]

How many times have I said "KEEP IT AT HOME?!"

You are using SOMEONE ELSE'S property. They have the right to control its use and monitor what goes on  both on their property and with their property, if only to see to it there is no criminal activity

If you put your bedroom in the public square, then the public square will be in your bedroom. None of my public-use devicesk go anywhere NEAR DD or anything related to it

As I always say; just DON'T. Now you know how come

[Babygeebee]

If you are using any kind of public WiFi you should be using a VPN at the very least. 

Cue ad for NordVPN, et al. 

[oznl]

9 hours ago, 1 Z said:

I used the computer at my latest stay, and as always browsed for diapers.                  

What was different this time was the look the manager gave me when I came out of the little office. I wonder if he somehow was monitoring my screen. Any thoughts?

 

 

Fairly unlikely the manager could see your screen I would have thought (unless some seriously illegal stuff was going on such as mal-ware injection, hidden cameras etc).

Your internet traffic IS likely to be being monitored and logged on a network like that, yes.  For the legal protection of the provider if nothing else.

The next question is about WHAT is logged.  If you're on an https web page, the traffic to and from that page is encrypted.  That log can still see the domain that you've visited though (and in the case of www.dailydiapers.com, that would be fairly self-explanatory).  It just couldn't read the traffic inside the session.

The question after that is whether or not the hotel manager would have access to those logs.  If it was a small, family hotel then yes, probably.  If it was a larger chain hotel, that kind of stuff is usually locked down (possibly even outsourced to a third party provider) and access to those logs would be on some kind of need to know basis.

Generally speaking however, public access wifi networks cannot be considered secure.  I would preferentially hot-spot data off my smartphone to using one of those unless I was using a VPN.  If you're using a VPN, the hotel logging system would see you make the connection to the VPN endpoint but then lose visibility into any traffic after that.

 

 

[Dubious]

Always use incognito mode on stuff you share with others.

[ozziebee]

Incognito mode only stops others from looking at the local machine's browsing history.  The mode does not provide any security of the browsing session outside of the browser, so URL's and such can still be captured and reviewed if the browser is configured to use a proxy (and they normally are in commercial contexts).  

It's more likely that the hotel manager was looking at such URL logs from their proxy server, and doing their own research upon seeing such dubious URL's as browsing to DD and such. 

[Crinklz Kat]

4 hours ago, oznl said:

Your internet traffic IS likely to be being monitored and logged on a network like that, yes.  For the legal protection of the provider if nothing else.

The next question is about WHAT is logged.  If you're on an https web page, the traffic to and from that page is encrypted.  That log can still see the domain that you've visited though (and in the case of www.dailydiapers.com, that would be fairly self-explanatory).  It just couldn't read the traffic inside the session.

Actually -- that is not true.  It's entirely possible they're proxying the traffic out to the internet, not just simple NAT (network address translation).  That means the hotel gateway is the terminus for the HTTPS connection - it then initiates a new HTTPS session (the proxy part) to the actual remote host on behalf of the client.   This is very common, even in corporate and govt network environments.  It's a sure way to be able to enforce content restrictions.

I would also recommend using the phone as a hot spot vs hotel system and not only for privacy, but also for performance.  Even at bigger hotel chains, unless you're paying for their premium services, you usually get mediocre performance on their network.  VPN can be useful to mask your activity -- but again, be wary of those services.  If it's free, they have to recoup their costs somehow, and it comes from selling the data you generate while using their services! 

[oznl]

2 hours ago, Crinklz Kat said:

Actually -- that is not true.  It's entirely possible they're proxying the traffic out to the internet, not just simple NAT (network address translation).  That means the hotel gateway is the terminus for the HTTPS connection - it then initiates a new HTTPS session (the proxy part) to the actual remote host on behalf of the client.   This is very common, even in corporate and govt network environments.  It's a sure way to be able to enforce content restrictions.

An https session uses digital certificates to establish the endpoint identity and the encryption channel.  For a corporate proxy to get "inside" an https session, they'd have to fake the certificates and get themselves elected as some kind of certificate authority (that wouldn't be simple) to cover that up (to stop your browser from going nutso about the security breach).  In short, they'd have to implement a "man in the middle" attack. 

As I understand it, a corporate proxy can proxy the packets but it can't decrypt their payloads.

I'm a little rusty but I think I have this,  @ozziebee will correct me if I don't ?

NAT happens further down the protocol stack and is just a way of sharing a routable internet address across a private subnet.  It's kind of a different thing but you would very commonly encounter it.

[ozziebee]

Not quite right @oznl . The client browser will make a connection to the proxy in order to “proxy” the connection to the destination URL. The proxy will make the connection, and fake itself as the client. From the client’s perspective it is talking to the URL directly, but it’s actually talking to the proxy. 

This works, as the proxy will have its HTTPS certificate in the client’s cert chain, so the proxy's cert will be trusted by the client browser.

Thus the proxy can read the client comms and perform URL and such content filtering, and content injection  

Where this falls over is URLs requiring a client-side certificate, or a client app requiring a server-side certificate for authentication of each other. If a proxy sits in the middle, the authentication/ authorisation process fails. 

Which is why we see lots of proxy bypass / whitelisting requests at work. 

[Dubious]

14 hours ago, ozziebee said:

and doing their own research upon seeing such dubious

?

[oznl]

15 hours ago, ozziebee said:

Not quite right @oznl . The client browser will make a connection to the proxy in order to “proxy” the connection to the destination URL. The proxy will make the connection, and fake itself as the client. From the client’s perspective it is talking to the URL directly, but it’s actually talking to the proxy. 

This works, as the proxy will have its HTTPS certificate in the client’s cert chain, so the proxy's cert will be trusted by the client browser.

Thus the proxy can read the client comms and perform URL and such content filtering, and content injection  

Where this falls over is URLs requiring a client-side certificate, or a client app requiring a server-side certificate for authentication of each other. If a proxy sits in the middle, the authentication/ authorisation process fails. 

Which is why we see lots of proxy bypass / whitelisting requests at work. 

Thanks @ozziebee and @Crinklz Kat I must withdraw my counterpoint and concede you are correct on that point and I was wrong.  I've just given myself a 10 minute crash course in forward HTTPS proxying by way of punishment.

I'm vaguely annoyed on two fronts.  Firstly, that there was a hole in my proxy knowledge there and secondly, that forward HTTPS proxying is even possible:  FFS that's just a MiTM attack dressed up as respectable ?  It's not 100% clear to me how the proxy cert comes to be trusted by the client but I'll read some more and figure it out...

[PoopyDiaperDude]

VPN at all times.  Even at your home. 

[zzyzx]

On 11/24/2022 at 7:13 PM, Crinklz Kat said:

Actually -- that is not true.  It's entirely possible they're proxying the traffic out to the internet, not just simple NAT (network address translation).  That means the hotel gateway is the terminus for the HTTPS connection - it then initiates a new HTTPS session (the proxy part) to the actual remote host on behalf of the client.   This is very common, even in corporate and govt network environments.  It's a sure way to be able to enforce content restrictions.

This is why you need to be very careful about what you accept for root certificate authorities -- so you can detect the man in the middle and abort a session where you aren't properly end-to-end with the remote server you *think* you are talking to....  The intermediate proxies can't get proper certs to get around this, unless you are using something like the French Government's controlled root CA...

20 hours ago, ozziebee said:

Where this falls over is URLs requiring a client-side certificate, or a client app requiring a server-side certificate for authentication of each other. If a proxy sits in the middle, the authentication/ authorisation process fails.

@ozziebee:  Ah....  One of the few people who would understand why I use (and require) both client and server certificates signed under a private root CA I run for securing connections where I have some control on both ends -- with out a lengthy explanation of what I'm doing. And yes, I've aborted at least one user's connection due to a required corporate proxy - man-in-the-middle - or at least that is my best explanation why the user couldn't successfully connect, and they couldn't establish a proper connection due to corporate requirements.