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.
