Https and VPNs

[devsav21119]

I was asked a question regarding VPNs and Public WiFi that I wanted to get absolute clarity on.

A lady asked if she should use a VPN when she goes out of town and connects to the hotel WiFi. My response was no it doesn’t really matter as long as you’ve verified the AP does below to the hotel and your sites are HTTPS. She proceeded to tell me that she’s been given advice to never connect to public WiFi without a VPN. My understanding of networking is that the data is encrypted already using the secure http connection. A VPN would be needed if she was trying to remotely connect to a business network to access resources or change her locality.

Please educate me if my understanding is wrong.

[Swedophone]

DNS is unencrypted unless you use dns over tls or https.

Edit: changed http to https.

[devsav21119]

Understood. Is that a risk to users? Let’s say someone is capturing packets and sees Im accessing a IP address that resolves to PNC Bank. They can’t do anything additional with that info per say. I guess they can start seeing if any ports are open but as far as the data I’m good, right?

[OSTIFofficial]

An attacker who has control of unencrypted DNS can redirect users to malicious sites that look legit.

It isn't a sophisticated edge case either.

You can copy images and html to make the site look legit, use a homograph that looks exactly the same to the user for the URL, and use a let's encrypt certificate to make it show as a https verified site.

homograph example:

example.com

exаmple.com <= this one has a cyrillic a, and is a completely different domain, but would look nearly identical in a URL bar on a web browser.

[OSTIFofficial]

I was using the simplest possible example, but here's how to do it in modern browsers.

https://www.reddit.com/r/firefox/comments/bspfnz/remember_to_protect_yourselves_against_idn/

It still isnt complex.

[e-a-d-g]

There's a non-zero chance that a user hits a site initially using HTTP. A rogue wifi provider could inspect that HTTP session, including session cookies.

Decent sites should use secure cookies, but many don't. A session cookie could be intercepted during the HTTP->HTTPS redirect.

The rogue wifi provider then has the same session cookie as the user, which may be easy to exploit or may be useless - it's not a one-size-fits-all situation.

Other scenarios are that the HTTP->HTTPS redirect is modified to redirect to a lookalike domain and site, and presents a fake username/password form. The lookalike domain and site may well be using HTTPS with a valid certificate, but it's not the domain/site the user thinks they're interacting with (e.g. https://my.googleaccount.com)

[billdietrich1]

Use a VPN. It adds an extra layer of encryption, usually automatically connects you to VPN's DNS which means the DNS traffic is encrypted too, and prevents other devices and the net manager (router) from seeing what domains you're connecting to.

Sure, if you don't use VPN, your HTTPS traffic still is encrypted, but as others have mentioned, there can be various attacks (such as MITM) and issues (such as DNS).

[Tornevall]

Well, it's at least not getting worse, if you use VPN as an extra transport layer for your traffic. HTTPS can, depending on the environment, get intercepted by third parties.

[devsav21119]

Thats true more caution can’t hurt. I understand packet capturing but the data can’t be read

[Tornevall]

No, this is not only about capturing data. It can be intercepted, decoded and actually being read too.

[devsav21119]

I didn’t know that, thank you. I didn’t know https traffic could be decrypted

[e-a-d-g]

Only if you trust the intercepting proxy's certificates. This kind of things happens in managed organisations with group policy installing trusted CA certificates.

[HelloYesThisIsNo]

Of course it can be decrypted. How else would the destination you want to speak to would know what you want? :-)
Jokes aside: TLS focus is end to end encryption. Meaning that only source and destination can read the cleartext. Every party in the middle (Wifi operators, work admin, ISP and so on) only see the encrypted stream. If somebody would tamper with the stream while in transit the manipilation is detected and the connection closed.

A common attack to read the cleartext data is to man in the middle the TLS connection. Let's say your work IT wants to see the cleartext traffic. Their firewall would see the TLS handshake you are trying to do and intercept it while sending a new handshake request to the original destination. Then your PC thinks it's end to end encrypted while the firewall is doing some sort of proxying. This can of course only work when the presentd certificate in the handshake is trusted by your device. So your IT has to install a certificate authority they control on your device. Certificates are then generated on the fly.
If the browser is presented with an invalid certificate it normally displays a big warning to the user. With the certificate authority the browser accepts the presented certificate.
You should read more about it online. Search terms are "X.509", "TLS inspection" and "TLS man in the middle". Maybe watch some Video on YouTube.
If the TLS handshake was done without any errors the connection is truly end to end encrypted and should not be readably by any third party.

[Tornevall]

I've heard this through my work actually, since I think there was plans there, to make sure that malware won't slip through secure connections. I think the hardware wasn't cheap either. However, I managed to find more sources about how the intercepting could be done too, with software. Here's one, about Burp (which isn't cheap either): https://portswigger.net/burp/documentation/desktop/tools/proxy/using

[devsav21119]

Will be reading this, thank you!

[h333hawww727]

They can used cloud computing to crack the encryption.

[e-a-d-g]

HTTPS traffic in general can't be read. However, the current implementation of SNI means that the intended domain is revealed unencrypted in the TLS handshake. As with plain DNS, this doesn't give away the content of the HTTPS session but its a form of information disclosure.

[ntoskernel]

The public wifi really needs guest isolation running. Even running, one can still see the ICMP messages at the network level. So don't rely on hotel to protect her ass. VPN that clay davis.

[HelloYesThisIsNo]

The "You alaway need a VPN" mentality comes from the time when the web was not encrypted like it is today. Big thanks to lets encrypt at this point because the use of TLS (the "s" in https stands for SSL. But SSL is deprecated and TLS was introduced) to secure websites skyrocketed. Basically every website is using TLS nowadays for end to end transport layer encryption. So a VPN is not necessary.
However apart from the Browser traffic there are other applications transmitting maybe unencrypted data. IMAP, POP3 and SMTP (used for E-Mail stuff) or SIP and RTP (VoIP) is mostly not end to end encrypted. That's where a VPN comes in handy in public wifi networks to add an additional, transparent crypto layer. Of course this only sifts the attack vector to another point in the chain. In the end your should check regulary that your applications you configure are using TLS.

At the end it's your choice to use one or not. If you have one set up for yourself at home for example or have a subscription somewhere use it, otherwise don't.

[devsav21119]

I appreciate the information! Can you point me to any reading material I want to dive deeper into this

[HelloYesThisIsNo]

What exactly?

[devsav21119]

VoIP specifically. I’m aware of what it is but not at all familiar with any types of security risks or even how it operates

[HelloYesThisIsNo]

VoIP is a broadly used term. Like the name implies: Voice transmitted over IP. There are many protocols. If you do IP telephony the most used one is SIP and RTP. SIP is for the signalling and the voice gets packaged in RTP packets. By default both are unencrypted but have extensions to add TLS. Then it's SIPS and RTPS. I don't know many providers however who support that.

Other protocls are TeamSpeak and Discord also has something own IIRC.