Is visiting HTTPS websites on a public hotspot secure?

HTTPS is secure over public hotspots. Only a public key and encrypted messages are transmitted (and these too are signed by root certificates) during the setup of TLS, the security layer used by HTTPS. The client uses the public key to encrypt a master secret, which the server then decrypts with its private key. All data is encrypted with a function that uses the master secret and pseudo-random numbers generated by each side.

Thus,

• the data is secure because it is signed by the master secret and pseudo-random numbers
• the master secret and pseudo-random numbers are secure because it uses public-private key encryption when the TLS handshake occurs
• the public-private key encryption is secure because:
  • the private keys are kept secret
  • public-private key encryption is designed to be useless without the private key
  • the public keys are known to be legitimate because they are signed by root certificates, which either
  • came with your computer
  • or were specifically authorized by you (pay attention to browser warnings!)

Thus, your HTTPS connections and data are safe as long as:

1. you trust the certificates that come with your computer,
2. you take care to only authorize certificates that you trust.

Short answer: it depends.

SSL/TLS itself is no more vulnerable over a public wifi connection, than over "regular" internet. It was designed to be used in open channels.

However, there a few other aspects to consider:

• Often users don't browse directly to the HTTPS site, they start off at the HTTP site and redirect from there. E.g you browse to http://example.org/, and click the Email link, which redirects you to https://mail.example.org/. Since the original HTTP page is not encrypted, that malicious user can modify your traffic, causing the Email link to NOT redirect to HTTPS, but maybe somewhere else. For example, if you clicked the Email link on example.org's homepage, would you notice that it took you to http://mail.exxxample.org/? (as an example). You might, someone else might not.
• If the user hijacks your connection, but provides his own bogus SSL certificate instead of example.org's - your browser will show an error, that the cert is not valid. However, most users will just click through this, allowing the attacker to MITM to your secure site, over SSL.
• Another aspect to consider, don't assume the public hotspot is securely configured. As this question shows, pwned routers are all too common, and can cause way more damage irrelevant of your SSL.

A session which is entirely over HTTPS is fairly safe, as all requests from the browser, and pages transmitted by the server are encrypted.

However, when accessed via HTTPS, many sites will only carry out the authentication step over HTTPS, and then drop back to HTTP for the rest of the session. So, your password itself is safe, but the session ID used by the server to identify you for that session is transmitted in the clear by your browser. This reduces the load on the webserver (because encryption/decryption is CPU-intensive) but makes the site much less secure. Gmail is safe because it uses HTTPS for the whole session, but Facebook and many other sites do not.

This is how tools such as Firesheep are able to hijack users' accounts when an attacker is sharing an unencrypted wireless network.

You can protect yourself from this attack by either using a VPN to encrypt all session data, or by only using networks which have strong, per-user encryption such as WPA-PSK (WEP uses the same key for every user, and so does not offer protection from this attack).

Since the answers seem to be all over the place (yes, no, might be, should be), let me first reiterate @waiwai933's answer: it is secure.

To be specific, you asked: "If that malicious user sniffed all my incoming and outgoing packets. Can he calculate the same keys and read my encrypted traffic too or even send encrypted messages to the server in my name?" The answer is no and no. With a footnote.

The reason he cannot calculate the same keys seems paradoxical, and in fact was a major break-through in cryptography when it was first published by Diffie and Hellman. TLS uses a key exchange protocol, like Diffie-Hellman but more sophisticated to protect from man-in-the-middle attacks. The protocol lets two people who have never exchanged information before compute a secret key that no one seeing all the messages can compute.

Once you have a shared secret key, you can use it to encrypt your traffic. Since the malicious user doesn't know the key, he can't encrypt traffic that looks like it came from you.

Now those footnotes.

• We are assuming that the SSL/TLS protocol is correct. With most involved cryptographic protocols, bugs are found and fixed from time-to-time. SSL/TLS did have a recent bug (mentioned in a few answers as a reason it is not secure), however it has been both temporarily worked around and now fixed (RFC 5746) and the fix is in various stages of deployment. (In your scenario, the bug allowed a malicious user to send packets in your name but not read your traffic.) It is always possible that the attacker knows how to break TLS/SSL due to an unpublished error in the protocol.
• An obvious point but worth repeating: The malicious user could see your request and send his own response using his own certificate. So do check the certificate.
• Perhaps another obvious point: you can only be sure SSL/TLS will be used for future pages if the current page is HTTPS. For example, if you are on an HTTP page that wants you to log-in, and from past experience you know that clicking the log-in button will redirect you to an HTTPS connection, this functionality could be stripped out by an active malicious user on your network. So only log into pages that are already HTTPS (unless if you know how to detect if the log-in page has been modified).

HTTPS is pretty resistant to decryption from packet sniffing. However the server authentication side depends on a somewhat weak method of distributing CA certs and the CAs don't do much in terms of verifying identities. Some years ago a Microsoft cert was issued to an imposter. See Bruce Schneier's article on the subject - in practice, for general public websites, we don't have anything better.

In practice, SSL and TLS both have issues, but they are around the Man In the Middle type of attack. For an example TLS MITM renegotiation issue see here

Of course, this attack requires the attacker to be in the middle of the communication path, which limits the threat a little :-)

If you're concerned about safely browsing to some site over an insecure network, the best steps you can take to ensure security are:

• Make sure that the site uses HTTPS, not HTTP.

• Make sure the site has a valid certificate. Don't click through warnings. Don't accept invalid certificates.

• Use HTTPS Everywhere or Force-TLS to ensure that you are using a HTTPS (i.e., SSL-encrypted) connection for everything related to that site.

Entirely, in practise. The encryption starts off with the root ssl people (Verisign, Thawte, etc) and therefore it's suitable for insecure lines. AFAIK TLS doesn't have a problem with man in the middle attacks, its only weaker/older handshakes that have that problem.

Most are forgetting the user aspect and how they might use that pc at the hotspot also. Most people use similar passwords on other sites, may blog, ...etc. those may not be as secure well as HTTPS/SSL gmail you might be connecting to. Problem I see from security most people will goto other sites expose a packet sniffing program with enough information to get at some of your accounts. Best is as mentioned if you are using an unencrypted wireless connection hopefully you have a vpn you can connect to after that that will add the extra layer of security.