I read that HTTPS can be compromised and is not as safe as you think. With a free VPN you have to put some trust in a free VPN server with your data, and surely your data from when it leaves the VPN server to the destination has to be uncrypted unless the VPN is set up at both ends.

So is HTTPS within VPN a lot more secure than HTTPS or VPN on their own, e.g. can the VPN server can access your data when HTTPS is used inside the VPN tunnel?

Or is HTTPS safe enough on its own?

I use public WiFi a lot and would like to use as a secure connection as possible for just the sensitive email and important stuff whilst not being a hassle to set up and also free.

Would HTTPS within Hotspot Shield be more secure than HTTPS? Would you use WiFi for important browsing?

  • 1
    (One) Sorry, I don't have enough points yet to leave a comment, so I have to use the answer form. But I have a question for you. You said, "I read that HTTPS can be comprimised and is not as safe as you think[.]" Can you provide some links? (Two) Not all Wifi are the same. I would never use anything with WEP for important browsing, but WPA does not worry me. Besides, anything important should be over HTTPS.
    – Kenzo
    Nov 22, 2012 at 4:30
  • Kenzo,I'm trying to find out myself giving what i have read about it. security.stackexchange.com/questions/6489/…
    – joe
    Nov 22, 2012 at 8:17
  • 1
    IMHO biggest current issue with HTTPS is the trust model - and in particular the number of root CAs bundled in most implementations. After fixing the boot / disk encryption and firewall, I'd prune the list a bit to secure a mobile device
    – symcbean
    Nov 22, 2012 at 22:42

3 Answers 3


Regarding your 'session jacking' comments on Terry Chia's answer:

Session jacking and the technique that Firesheep uses is to target HTTP site logins taking place over a shared network connection, ie: WiFi. This is acomplished by intercepting the session cookies that the site sends back after a successful login takes place. If the connection uses SSL [aka HTTPS] then these cookies cannot be read by a third party.

When your browser indicates "not everything on this page is secure" that means that some resource was loaded over a plain HTTP connection. This does not necessarily mean you're vulnerable, since it is usually simply an image file or an included CSS/JS file.

As for VPNs, you should only trust the VPN connection as much as you trust the provider. That is to say if you're using a free service like HotSpotShield then you had better be OK with them being able to intercept every single packet you send to them. Also, since you install their VPN client software there's nothing stopping them from also installing forged root/intermediate SSL certificates on your computer that will allow them to strip off SSL protection if they feel like it.

In summary, you're best off not using a VPN that you didn't set up yourself, and ensuring that your logins and important data is transmitted via SSL/TLS protected connections, eg: HTTPS, IMAPS, POPS, etc.

  • A fine answer. Do note, though, that "an included JS file" is a prime vector for attacks on mixed-content pages. While you are correct that it doesn't necessarily mean a vulnerability, it does reduce the effective security to that of HTTP. Nov 27, 2012 at 21:50
  • @JonathanGarber All an attacker needs to do is spend 5 minutes looking through a list of compromised websites to find one with a valid SSL cert, post his JS there, and then include that into whatever page and it won't trigger a warning unless you've got something like NoScript. Trust me, I worked for a hosting company a looong time and saw many a moron with VPASP carts that hadn't been updated for 5 years, but god help you if their $10 SSL cert expires because they're yelling at you on the phone within the hour.
    – Sammitch
    Nov 28, 2012 at 16:36

You do not understand the technologies you have mentioned.

First, let's identify the threats of surfing on a public wifi network. Anyone who is on the same network as you will be able to sniff the packets you send. This means that any non-encrypted data you send over public wifi networks can be easily compromised.

This problem is mitigated by HTTPS. What HTTPS does is encapsulate the HTTP communication within an SSL layer. What this means is that any data sent between your browser and the website is encrypted. HTTPS also guarantees that the website is who they say they are through certificates.

Hotspot Shield creates a VPN tunnel between your computer and their internet gateway. Any traffic between your computer and the gateway will be encrypted. However, any data traffic between the gateway and other websites can still be sniffed, unless they are communicating over HTTPS.

For your use case, I'd say a simple HTTPS connection will prove sufficient.

  • OK people what do you make of ''session jacking''? Quote - ''There's an increasing tendency for websites to use the https Secure Sockets Layer (SLL) system, shown by a padlock in the browser, and this already encrypts data to protect it from casual snoopers. However, the appearance of "session jacking" software such as the Firesheep add-on for Firefox means a VPN is probably a good idea when using public Wi-Fi hotspots for important data''
    – joe
    Nov 22, 2012 at 7:59
  • Another thing i've noticed is that sometimes the HTTPS green padlock symbol on a supposedly secure website like online banking can sometimes change to the less secure ''not everything is secure on the page'' symbol without warning. Would VPN serve as a back up for this ?
    – joe
    Nov 22, 2012 at 8:37
  • I should add that i'm travelling alot in countries where the laws are....the best that money can buy. So if i could even secure my end in a VPN tunnel it would be great. But i'm looking to be educated on this.
    – joe
    Nov 22, 2012 at 9:04

The Question you link to (in a comment) doesn't really talk about weaknesses in HTTPS. The distribution of e-mail has nothing to do with HTTPS.

It's important to understand the weaknesses related to HTTPS and SSL/TLS before jumping to alternative solutions, some of which may present similar problems.

  • The renegotiation issue (CVE-2009-3555) was rather directly related to the TLS protocol itself. There were mitigations using configuration options (by disabling renegotiation), and there has since been a fix (RFC 5746). (Despite it being a flaw, I think it was rather difficult to exploit consistently.)

  • The CRIME issue can be addressed by disabling TLS compression.

  • The BEAST issue can be mitigated in a number of ways, in particular upgrading to TLS 1.1 or above.

Most of these problems require some configuration changes or changes of options in the way certain applications use their SSL/TLS libraries. Nevertheless, if you're up to date with your software, you should be fine.

The whole specification of SSL/TLS is very modular, so if certain weaknesses are found with certain cipher suites, for example, there are often other options available. Good and up-to-date configuration is essential to any security system.

Most people who say "SSL is broken" in fact target the PKI system (i.e. the certificate model). The TLS specification doesn't actually mandate using X.509 certificates, but it's true the HTTPS over TLS implies using X.509 certificates.

PKIs and certificates are about checking the remote party's identity. This is a technical solution to a problem that happens in every day life (bank verifying your ID at the desk, ...). The technical aspect is only part of the problem. CAs are far from perfect, but they offer a system that's manageable. Modelling trust is actually a very difficult problem.

Remember that, ultimately, checking that the HTTPS is used and is used with the right party is the responsibility of the client and its user. Servers can at best tell the clients to use HTTPS, that redirection might not be secured. It's always up to the user to check. (Admittedly, is also a GUI problem, to give the user the right information, with as little confusion as possible.)

Comparing HTTPS (and SSL/TLS) to VPNs doesn't make sense. These systems have two different purposes. HTTPS is about securing the communication between the client/browser and the server. VPNs are about linking two sub-networks together.

There are a number of VPN technologies, with there advantages and disadvantages. Like all security solutions, they have to be configured and used properly to be effective.

  • VPNs using SSL/TLS (like OpenVPN): in principle they can suffer from some of the same problems as SSL/TLS with HTTPS when it comes to checking the certificates. This being said client-certificate authentication is more common in this environment (which makes MITM attacks also detectable by the server with SSL/TLS, this applies to HTTPS too, but client certificates are rarer there).

  • VPNs using IPsec and certificates. Again, identity verification can also be a problem there. One way of addressing this is to reduce the number of CA certificates trusted by the IPsec implementation. This is generally more manageable for a VPN because you're using fewer VPNs than remote websites in general, but the fundamental problem remains.

  • VPNs using IPsec and shared secret. This could work fine if the shared secret wasn't shared as widely (and stayed more secret). It seems that a few universities (for example) publish their VPN shared secret widely, which can potentially open the door to MITM attacks.

If you check your certificate properly, adding a VPN under your HTTPS connection doesn't generally add any actual security. There is a small window where it can help: when a CA you trust (willingly or by default in your OS/browser) has been compromised and a rogue certificate can be used on the section of network that could otherwise be protected with a VPN. This may also help on that section of the network with badly implemented clients.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .