Public Wi-Fi risks explained, and how to use it more safely

Public Wi-Fi is useful, but using it safely means checking HTTPS certificates, protecting the traffic that needs a VPN, and understanding what happens when that VPN stops working. Wi-Fi encryption and HTTPS provide important protection without guaranteeing uninterrupted TCP connections. Choose a VPN by its authentication, transport, failure behavior, kill switch, and vulnerability response as well as its provider’s reputation.

Hotel, cafe, and airport networks let us work remotely without consuming a mobile data allowance. “Public Wi-Fi” here includes both open networks and networks that share a password with many guests.

While researching another networking issue, I came across the NDSS 2025 paper Off-Path TCP Hijacking in Wi-Fi Networks: A Packet-Size Side Channel Attack. It offers a useful starting point for separating what encryption protects from the risks it leaves behind.

Can an encrypted Wi-Fi network still expose TCP connections to attack?

Yes, under the conditions studied in the paper. The researchers inferred TCP state from the sizes of encrypted wireless frames without decrypting their contents. They demonstrated SSH connection termination in 19 seconds and injection into unencrypted HTTP traffic within 28 seconds. In their field evaluation, attacks against researcher-controlled connections succeeded in 75 of 80 Wi-Fi networks.

That result is not a worldwide success rate. The attacker needed to join the same Wi-Fi, observe the victim’s wireless frames, and send packets with forged source addresses. Target identification and TCP response behavior also mattered. This is not an attack that anyone can launch from an arbitrary remote location.

Client isolation can restrict direct communication between guests without eliminating observation of wireless frames. WPA2, WPA3, and client isolation remain valuable; none should be treated as protection against every traffic-analysis or connection attack.

HTTPS protects application data, not every aspect of its connection

TLS provides confidentiality and integrity for application data. With HTTP/1.1 and HTTP/2, that data normally travels over TCP. TLS does not encrypt or authenticate TCP’s own sequence numbers or reset flag.

An attacker able to deliver an acceptable forged TCP reset can therefore interrupt a TLS connection without decrypting its contents. TCP includes defenses against blind injection, described in RFC 5961; the research examines a side channel that helps infer the state those defenses depend on.

This does not mean a TCP attacker can freely read HTTPS or inject arbitrary application data that valid TLS will accept. The HTTP injection demonstration used unencrypted HTTP. HTTP/3 uses QUIC over UDP, so it is not the same outer-TCP case.

A stalled video, interrupted download, or dropped remote session is not evidence of this attack. Weak radio coverage, congestion, timeouts, and ordinary network faults are common explanations.

HTTPS encryption and TCP connection disruption concern different layers.

A past OpenVPN experience, with an unknown cause

I previously experienced unexplained disconnections while using OpenVPN in TCP mode on external Wi-Fi. Sometimes they coincided with login or authentication activity. At the time, I had chosen TCP because I associated it with reliability.

The practical concern was that a disconnected VPN could leave the device using its ordinary internet connection. I added both a kill switch and connection monitoring with automatic reconnection to the application I was working on.

The old logs are unavailable, so I cannot establish the cause or attribute those events to this research technique. The enduring lesson is about failure behavior: a kill switch limits unintended traffic, while automatic recovery reduces downtime. They serve different purposes.

A TCP-based VPN can lose its outer transport

Some SSL VPNs, OpenVPN configurations, and VPN relay paths use TCP outside the encrypted tunnel. If that TCP connection is terminated, the tunnel can become unavailable.

What happens next depends on routing and firewall policy. With a working kill switch, intended traffic should remain blocked while protection is unavailable. Without one, traffic that can use the ordinary internet connection may leave directly. Private destinations reachable only through the VPN may simply stop working.

For a full-tunnel VPN, a possible sequence is:

1. An attack interrupts its outer TCP connection.
2. The kill switch is absent, disabled, or ineffective.
3. New or retried internet traffic uses the local connection directly.
4. Direct HTTPS-over-TCP connections become exposed to TCP disruption on that path.
5. A separate flaw in fallback, authentication, or session handling could create further risk.

The final step is conditional. The paper does not demonstrate that entire chain, and a TCP reset does not defeat TLS. An existing connection also does not necessarily survive a change of public source address; applications may establish new connections instead.

Similarly, resetting TCP does not disconnect Wi-Fi itself or force a new login. Evil-twin access points, captive-portal phishing, HTTP fallback, and stolen session cookies are separate risks that should not be presented as automatic consequences of TCP disruption.

Behavior after VPN loss depends on the kill switch and routing policy.

Confidentiality, integrity, and availability all matter

Property	What it means here
Confidentiality	Prevent unintended disclosure, including unprotected traffic after a tunnel failure
Integrity	Reject unauthorized changes, such as injected plaintext HTTP data
Availability	Keep legitimate users able to connect and recover from interruptions

A kill switch can help confidentiality by blocking traffic, while also making the loss of connectivity visible. Reconnection improves availability but cannot replace blocking rules. Strong authentication also needs a recovery path when a legitimate user’s device fails.

Session protection needs its own checks

A session cookie represents an authenticated state. If a token can be stolen and replayed, an attacker may not need the account password. Observing correctly protected HTTPS on the same Wi-Fi does not by itself reveal that token.

For service operators, review the following separately from TCP resilience:

• Require HTTPS for authentication and session-bearing requests.
• Mark authentication cookies Secure and HttpOnly, and select SameSite deliberately.
• Use appropriate session expiry, logout invalidation, and reauthentication for sensitive operations.
• Apply authorization to every protected endpoint and API.
• Implement CSRF defenses appropriate to the application.

For example:

Set-Cookie: __Host-session=...; Path=/; Secure; HttpOnly; SameSite=Lax

The __Host- prefix requires a secure origin, Path=/, and no Domain attribute in supporting browsers. HttpOnly restricts script access to the cookie; it does not make an application immune to XSS. SameSite controls cross-site cookie sending and is not a complete authorization or CSRF strategy.

https://www.example.com and https://api.example.com are different origins but ordinarily the same site. Separating an API does not automatically require SameSite=None. Truly cross-site cookie authentication may require SameSite=None; Secure, additional CSRF protection, and consideration of browser restrictions on third-party cookies. CORS configuration alone is not a CSRF defense.

CloudFront: decide what HTTP should do

CloudFront’s Viewer Protocol Policy supports allowing HTTP and HTTPS, redirecting HTTP to HTTPS, or rejecting HTTP with HTTPS Only. For authenticated applications, plan to keep session-bearing traffic off plaintext HTTP. Choose rejection or redirection according to client and entry-point requirements, with HSTS where appropriate.

A redirect cannot encrypt the initial HTTP request. HSTS protects requests once the browser knows the policy, or through applicable preloading. See AWS’s HTTPS guidance.

Do redirects and reauthentication stay on HTTPS?

CloudFront or a reverse proxy may terminate HTTPS and communicate with the backend application over HTTP. That internal HTTP hop does not itself expose the traffic to an attacker on the user’s Wi-Fi. The relevant risk arises when the application mistakes the original HTTPS request for HTTP and generates an absolute http:// redirect or reauthentication URL.

For example, it might return Location: http://example.com/dashboard instead of Location: https://example.com/dashboard. CloudFront or the proxy may pass that Location header through unchanged. The browser then attempts the HTTP navigation; an effective HSTS policy for that host upgrades it to HTTPS. Without such protection, an actual HTTP request and response can be observed or modified on untrusted Wi-Fi.

A reload or reauthentication after a TCP interruption may exercise a rarely used code path and expose this defect. A TCP interruption does not automatically downgrade HTTPS. This is a conditional secondary risk involving an application flaw, not an attack directly demonstrated by the NDSS paper. A relative redirect such as Location: /callback normally resolves against the current HTTPS URL and is not itself a downgrade.

The cookie protection discussed above remains distinct: Secure prevents a session cookie from being sent in ordinary HTTP requests, but does not prevent HTTP response tampering or a forged login page. An incorrectly generated HTTP OAuth callback will also often be rejected by an authorization server’s redirect-URI matching or HTTPS requirements; it does not necessarily leak an authorization code.

Check the application’s public URL configuration and its handling of trusted proxy headers, such as X-Forwarded-Proto. Do not blindly trust client-supplied forwarding headers or assume that enabling HTTPS on every backend hop necessarily fixes URL generation. Alongside HSTS and cookie settings, verify login, logout, OAuth, and reauthentication after session expiry. Starting on HTTPS is not enough: browser-facing communication must remain on HTTPS throughout those flows.

If a SaaS provider controls these settings, ask for its documented behavior. A VPN cannot fix the service’s authorization or session-management defects.

Do the SPA’s API requests also use HTTPS?

A single-page application (SPA) loads HTML and JavaScript, then sends API requests from the browser. Those requests may pass through a reverse proxy or connect directly to a separate API, depending on their URLs and server-side routing. First, check that browser-to-API requests use HTTPS too; serving the frontend over HTTPS through CloudFront does not establish that.

For example, the application might use http://api.example.com as its API endpoint. From an HTTPS page, browsers normally block HTTP API calls made through fetch() or similar APIs as mixed content.

Internal applications may also rely on browser exceptions or enterprise policies that relax mixed-content restrictions to keep legacy HTTP APIs working during development or operation. Microsoft Edge, for example, provides a policy allowing insecure content on specified sites. An application working on the corporate LAN does not ensure that it remains protected when the same device leaves the office. If the API remains reachable and the path is not protected by a VPN or another secure transport, its HTTP traffic may cross untrusted Wi-Fi. Check browser exceptions, managed policies, and the actual API destinations and routes.

Separately, if an incorrect redirect or reauthentication flow loads the SPA itself over HTTP, without protection such as HSTS preventing it, subsequent API calls may also use HTTP. Login information actually sent over HTTP and API responses can then be observed or modified on untrusted Wi-Fi. A TCP interruption alone does not cause this situation.

Check more than the initial page: API calls, post-login navigation, and reauthentication after session expiry must also keep browser-facing communication on HTTPS.

Keep private administration services private where practical

Databases, SSH, and remote desktop commonly use TCP. Publishing them adds authentication, patching, and access-control responsibilities. An IP allowlist or bastion can reduce exposure, but an IP allowlist is not authentication , and neither guarantees the availability of the path to it.

One alternative is to connect authorized devices to a private site or VPC through a VPN, leaving databases and administration services off the public internet. A UDP-based authenticated tunnel can also avoid exposing its inner TCP connection directly to the local Wi-Fi attacker.

The tunnel does not replace application authentication, authorization, patching, VPC security groups, or network access controls. Nor does it guarantee that the underlying network will carry UDP.

Zero trust is not simply “stop using a VPN”

Using SaaS directly can be appropriate. HTTPS and well-designed authentication can protect it without a VPN. But moving applications outside a corporate LAN does not by itself establish zero trust.

NIST’s Zero Trust Architecture focuses on decisions about resources, identities, devices, and access rather than assuming trust from network location. A VPN can coexist with those principles.

A reverse proxy or ZTNA gateway can centralize authentication and restrict access per application. It also remains an entry point that needs maintenance and protection. Check that:

• Every protected route and API actually enforces authentication and authorization.
• Backends cannot be reached through an unintended bypass.
• Identity headers are accepted only from the trusted proxy and cannot be supplied by arbitrary clients.
• Session revocation works after logout, account disablement, or incident response.
• Cookies and tokens remain protected after the initial MFA or passkey login.

Public websites and webhook receivers may reasonably need a public gateway. Private development systems may fit a private-network design better. Evaluate the exposure and operational requirements rather than treating either architecture as universally safer.

ZTNA and SASE can add valuable controls, including device evaluation and application-level authorization. Their names do not specify every transport or failure behavior. Ask whether a path uses TCP/TLS or UDP, what happens when it fails, and which authentication and session systems it depends on.

Do SPA API calls also use the reverse proxy?

The earlier SPA section examined HTTP versus HTTPS. Here, the question is which access controls each request passes through. Putting an internal application behind a reverse proxy does not ensure that API requests use it: they may bypass the proxy and connect to a separate endpoint. This can happen with SPAs built using React or Vite, and with client-side API calls in SSR applications such as those built with Next.js. The choice of technology alone does not establish the actual route.

Through the proxy

Browser → HTTPS → Reverse Proxy → HTTP → Internal API

For example, the SPA requests /api/users and the proxy forwards that path to the API. Browser-to-proxy traffic uses HTTPS. If the proxy applies authentication and authorization to the API routes too, it can enforce access there. HTTP on a private proxy-to-API segment is not directly exposed to the user’s public Wi-Fi.

Direct API access

Browser → HTTPS → Reverse Proxy → SPA delivery
Browser → HTTP :8080 → EC2 API Server

Here, the API request bypasses the proxy. Authentication protecting SPA delivery does not automatically protect that direct request. Independent API authentication and authorization can protect it; without them, business functions may be reachable without passing the proxy’s access checks.

The mixed-content conditions in the earlier SPA section also apply to this direct HTTP example. Ordinary HTTP fetch() or XHR calls from HTTPS pages are blocked; requests that actually succeed under exceptions or other conditions must be considered separately. CORS is a different control: allowing an origin through CORS does not itself disable mixed-content protection.

If the API is reachable and HTTP actually crosses untrusted Wi-Fi without a VPN or equivalent path protection, transmitted login information and API requests or responses can be observed or modified. An internal-only API is not necessarily reachable from outside. Reconnection or reauthentication may expose an existing HTTP configuration, but TCP interruption does not itself cause a downgrade. This is a conditional application risk, not an attack directly demonstrated by the NDSS paper.

Proxy access controls do not automatically apply to a direct API path. HTTP is normally blocked; when it actually succeeds without VPN or equivalent path protection, plaintext can cross the Wi-Fi network.

Is a backend inbound port exposed for direct API access?

Consider a Node.js or Spring Boot API on EC2 accessed directly at http://api.example.com:8080. If an internet route reaches the instance’s public IP, its security group and host firewall may allow inbound traffic to the API port. The actual port might be 80, 3000, 5000, 8080, or another configured value.

With a reachable path and a broad source rule such as 0.0.0.0/0, the API may be directly accessible from the internet. Proxy-side restrictions do not apply to that path. Even when the API independently enforces authentication and authorization, vulnerabilities in the publicly reachable API server remain a separate concern.

This exposure is not inevitable. An architecture that restricts backend traffic to the ALB, or uses an API Gateway private integration, need not open the EC2 API port to the whole internet. Direct API calls do not imply that every deployment exposes port 8080 globally.

Verify the route and the exposed entry points

• Use the browser’s Network panel to inspect API URLs and HTTP/HTTPS during login, session renewal, and reauthentication.
• Confirm whether API calls traverse the proxy. For direct calls, check HTTPS and the API’s own authentication and authorization.
• Review security groups and firewalls for unnecessary API ports and overly broad source ranges such as 0.0.0.0/0.
• Check production devices for leftover development HTTP URLs or mixed-content exceptions and policies, and verify whether the actual route is protected by a VPN.

Where direct exposure is unnecessary, a properly secured reverse proxy or API gateway can provide access to a private backend. Applications used only by selected devices may instead be restricted to a VPN. Verify which requests pass through which controls, and which ports are exposed, rather than assuming the proxy protects every path.

Check the VPN’s actual transport, endpoint, and recovery path

Direct connections and relays have different conditions

Some peer-to-peer VPNs fall back to a relay when direct connectivity fails. A TCP/TLS relay introduces an outer TCP connection even if the encapsulated VPN originally uses UDP. Others use UDP relays. The paper does not directly establish successful attacks against every such product.

A self-hosted direct VPN needs an inbound-reachable endpoint. IPv4 may require port forwarding; IPv6 still needs suitable addressing, inbound firewall policy, and IPv6 at the connecting device. NAT traversal can change those requirements for peer-to-peer products.

Do not equate every exposed VPN port with an exposed web login interface. WireGuard normally stays silent toward unauthenticated requests, which reduces the processing exposed before authentication. Software maintenance and endpoint exposure still deserve consideration.

For those details, see WireGuard troubleshooting outside the home and WireGuard silence and outbound-only design.

Authentication is part of availability

A service may require a web login or token before bringing up its tunnel. Correct TLS prevents a reset from exposing the credentials, but repeated interruption can still stop the user from completing authentication.

Passkeys add phishing-resistant authentication tied to the legitimate service. Plan for recovery too. A synced passkey depends on recovery of its sync account; a device-bound credential or security key needs an independent backup or another supported recovery mechanism.

Avoid circular dependencies, such as needing approval from the failed phone to recover the account that restores its passkeys. Register supported backup credentials, protect recovery codes, and verify that the recovery process works. Recovery should remain resistant to account takeover.

How WireGuard and HomeGrid VPN differ from an outer-TCP design

WireGuard’s transport and HomeGrid VPN’s topology are separate design choices. Standard WireGuard uses UDP, while HomeGrid VPN connects Remote devices and site-side Grid or Spoke devices through a Cloud Hub.

Item	VPN using outer TCP	WireGuard / UDP with HomeGrid VPN
Forged TCP reset	Outer TCP may be a target	No outer TCP connection to reset
Recovery	May need a new TCP connection	WireGuard performs handshakes as needed
User login during ordinary recovery	Product-dependent	Registered peers use WireGuard keys; routine recovery does not require a new web login
Inner TCP traffic	Can be encrypted within the VPN	Encrypted and authenticated within the VPN
Kill switch	Product and setting-dependent	Depends on the client and connection method
Site-side inbound VPN endpoint	Architecture-dependent	Site initiates outbound communication to the Cloud Hub
Network disruption	TCP-specific and general failure modes	UDP blocking, loss, and other failures remain possible

WireGuard’s connectionless design retains state for keys and handshakes without using TCP connection setup. It handles packet loss and authenticated endpoint changes, performing fresh handshakes when needed. A long outage can still cause inner SSH, RDP, or application connections to time out.

An attacker on the local Wi-Fi cannot simply send forged inner TCP packets through the tunnel without passing WireGuard authentication. This prevents directly transplanting the paper’s technique into the authenticated tunnel. It does not hide all packet sizes or defeat every traffic-analysis method.

A kill switch is not a feature of the WireGuard protocol itself. HomeGrid VPN’s behavior depends on the client and connection method. In particular, the documented Linux connection command has no kill switch and tunnels IPv4 only. Check the Linux device guide before relying on it to protect internet traffic. Split-tunnel traffic outside a VPN is outside its protection by design.

With HomeGrid VPN, site-side devices initiate connections to the Cloud Hub, so port forwarding and IPv6 inbound rules at the site are not prerequisites. This changes the entry points exposed at home or in an office; it does not eliminate trust in the Cloud Hub or its availability.

The Cloud Hub is not necessarily the internet exit. When a home Grid is the exit, internet destinations see the home’s public IP. The hub remains part of the route. See how HomeGrid VPN works for the topology.

Client-generated WireGuard keys authenticate registered peers. Initial registration and dashboard access still have their own authentication requirements. Lost devices need revocation and replacement. LAN ACLs restrict reachable LAN subnets; VPC-side controls and application authorization remain necessary.

With a home exit, traffic crosses the Cloud Hub before leaving through the home ISP.

A practical checklist for public Wi-Fi

1. Confirm the network name with the venue and avoid lookalike access points.
2. Never bypass unexpected HTTPS certificate warnings.
3. Complete a required captive portal with only necessary information, then verify the VPN before sensitive work.
4. Check the active transport, including relay fallback, and which traffic the VPN actually covers.
5. Enable and verify supported kill-switch behavior, including reconnection, IPv6, and DNS handling.
6. Check monitoring and recovery rather than assuming a disconnected VPN will reconnect.
7. If the connection remains unreliable, use another network, such as mobile data, while considering its data allowance.

For work, also follow organizational policy and establish a recovery procedure for failed authentication devices. A TCP reset alone is not a reason to assume compromise, but persistent connectivity problems deserve investigation.

Review your home Wi-Fi too

Public Wi-Fi is not the only place where network membership matters. A weak or widely shared home password can let unwanted devices join.

WPA2 and offline password guessing

WPA2-Personal can expose material that lets an attacker test password candidates offline after capturing a suitable handshake. A published RTX 5090 Hashcat benchmark reports about 3.36 million candidates per second for mode 22000. It is one measurement, not a guaranteed cracking rate.

For a password chosen uniformly from 62 uppercase letters, lowercase letters, and digits, a full search at that fixed rate would take approximately:

Length	Time to exhaust the search space
8 characters	2 years
10 characters	7,900 years
12 characters	30 million years
16 characters	450 trillion years
20 characters	6.6 × 10²¹ years
24 characters	9.8 × 10²⁸ years

This assumes one GPU, no password bias, no dictionary advantage, and a constant rate. Expected discovery time is roughly half a full search. It is a scale illustration, not a lifetime security guarantee.

A long phrase composed of predictable names, dates, or substitutions does not have the same distribution. Attackers prioritize likely candidates instead of exhaustively enumerating every string.

WPA3 improves authentication without removing every risk

WPA3-Personal’s SAE is designed to resist the ordinary passive offline dictionary attack against WPA2-PSK. It does not make weak passwords, implementation defects, password disclosure, or online guessing irrelevant. WPA2/WPA3 transition deployments can retain risks associated with the shared password’s WPA2 use.

Where devices support it, consider WPA3-Personal-only mode with a long random password. Check compatibility after changing the setting and keep supported firmware current.

Python’s cryptographic random generator can create one:

import secrets
import string

alphabet = string.ascii_letters + string.digits
password = ''.join(secrets.choice(alphabet) for _ in range(32))
print(password)

A 24–32 character random password is practical when devices support it and manual entry is infrequent. Store it with the SSID in a protected password manager, or keep an accurate paper backup in a controlled physical location. Plan for loss of the password manager or its authentication device. Avoid uncontrolled plaintext copies.

If manual transcription matters, exclude ambiguous characters and compensate with sufficient length:

import secrets

alphabet = (
    "ABCDEFGHJKLMNPQRSTUVWXYZ"
    "abcdefghijkmnopqrstuvwxyz"
    "23456789"
)
password = ''.join(secrets.choice(alphabet) for _ in range(32))
print(password)

EAP-TLS is also a learning project

WPA2/WPA3-Enterprise with EAP-TLS uses client certificates and private keys rather than a shared password. It can support per-device lifecycle management, but requires a CA, certificate issuance and renewal, revocation, RADIUS, and appropriate validation of the authentication server’s certificate and name.

I recently built a WPA2-Enterprise EAP-TLS environment using a Cisco Aironet 1830 and FreeRADIUS, with configuration profiles for iOS. Treat this as a learning example, and check equipment support and firmware lifecycle when choosing hardware.

Protect profiles containing private keys during distribution and storage. PMF helps protect selected management frames, and guest isolation limits unnecessary device-to-device access. Neither should be described as a complete mitigation for the TCP side channel discussed here.

A familiar provider name is no longer enough

Reports of data breaches and unauthorized access continue to show why security services need technical scrutiny. The IPA’s 2026 threat assessment is one current reference on organizational threats in Japan.

A provider’s size, history, and adoption can inform a decision. Going forward, they should not replace checking how the service protects traffic and behaves when protection fails. This does not mean reputation used to guarantee safety or that the NDSS paper suddenly made every VPN unsafe.

Ask a provider:

1. How are users and registered devices authenticated?
2. What happens when a direct connection cannot be established?
3. Can transport fall back to a TCP relay, and how can a user tell?
4. Which traffic is blocked when the tunnel fails, including IPv6 and DNS?
5. How do monitoring and automatic recovery work?
6. How are authentication tokens protected and revoked?
7. How can a legitimate user recover after losing an authentication device?
8. How are outages communicated and resolved?
9. How are vulnerabilities fixed and users notified?

Providers need not disclose sensitive implementation details to explain their basic security properties. If a serious issue remains unresolved and you cannot compensate for it, consider a different service.

Apply exactly the same questions to HomeGrid VPN. WireGuard, client-generated keys, outbound connections, ACLs, and recovery behavior should be evaluated against your actual devices and requirements, rather than accepted as guarantees because of the product name.

Use public Wi-Fi with an informed plan

Encryption, reliable recovery, and authentication protect different things. HTTPS remains essential. A properly configured VPN can protect a chosen path, while its transport and failure rules determine what happens during disruption. Strong Wi-Fi authentication controls network membership; it does not replace application protection.

Keep confidentiality, integrity, and availability in view. Understand what your service does, verify its supported behavior, and prepare a usable recovery path. That is a more practical response than either avoiding every public network or assuming an encrypted connection cannot be interrupted.

References

• Wang et al., NDSS 2025 paper and PDF
• RFC 5961: TCP robustness against blind in-window attacks
• OWASP Session Management Cheat Sheet
• OWASP CSRF Prevention Cheat Sheet
• NIST SP 800-207: Zero Trust Architecture
• FIDO Alliance: Passkeys
• WireGuard protocol and cryptography
• HPE Aruba Networking: WPA3-Personal
• Published RTX 5090 Hashcat benchmark
• Python secrets module
• FreeRADIUS

Originally published at https://www.homegrid-vpn.com/blog/en/free-wifi-safety/