It's often said that HTTPS SSL/TLS connections are encrypted and said to be secure because the communication between the server and me is encrypted (also provides server authentication) so if someone sniffs my packets, they will need zillions of years to decrypt if using brute force in theory.

Let's assume I'm on a public wifi and there is a malicious user on the same wifi who sniffs every packet. Now let's assume I'm trying to access my gmail account using this wifi. My browser does a SSL/TLS handshake with the server and gets the keys to use for encryption and decryption.

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?

  • 7
    I think this is appropriate, as understanding the risks of such an environment is within remit of security professionals. Some of us have had to run public hotspots within corporate sites, and some need to work from a variety of locations - which can include public hotspots.
    – Rory Alsop
    Commented Jan 10, 2011 at 9:37
  • 2
    What about sslstrip ? (thoughtcrime.org/software/sslstrip) Also see this video about sslstrip
    – labmice
    Commented Jan 13, 2011 at 20:55
  • To add to the answers below it depends on the security of the website you are visiting - also see my tips here. Commented May 25, 2015 at 11:51
  • 1
    Note that while the HTTPS sites may be secure in this scenario, if at any point during your browisng session an HTTP site ever gets loaded (even in an iframe or seperate tab), a malicious hotspot can leverage that to steal your cookies on all popular non-HTTPS sites (even ones you're not currently browsing), and install backdoors for those sites which persist even after you're no longer connected to the malicious hotspot: samy.pl/poisontap So... yeah.
    – Ajedi32
    Commented Dec 5, 2016 at 16:08

11 Answers 11


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.


  • 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.
  • 2
    Oh I forgot that we have asymetric encryption systems.
    – Calmarius
    Commented Jan 9, 2011 at 12:49
  • 54
    3. You make sure all of your data actually goes over HTTPS (some sites are partially encrypted and partially not) Commented Sep 21, 2011 at 2:22
  • 2
    My local swimming baths (Hillingdon, UK) return their own certificates, so actually have full sight of what you send, even if the https is shown. 99.9% of users wouldn't notice this.
    – Paul
    Commented May 19, 2016 at 8:48
  • Question: Can you clarify how any response from the HTTPS server could be encrypted in such a way that someone listening in the middle could not interpret it? The only key that the client has is the public key which is also available to listener / hacker.
    – Josh G
    Commented Apr 22, 2019 at 18:36
  • 3
    @JoshG The client also has a private key, which only they know about. This is the essence of asymmetric (public/private key-pair) encryption. To decrypt a response from the server, a man in the middle would need the client's private key.
    – Ash
    Commented Jun 18, 2019 at 7:44

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.
  • 7
    All Google sites are HSTS-ed. Better to use example.org.
    – Pacerier
    Commented May 25, 2015 at 7:19
  • 1
    @Pacerier yeah, now, didn't used to be :-) Also their certs are mostly pinned (re my 2nd point), so... yeah. Thanks!
    – AviD
    Commented May 25, 2015 at 8:26

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).

  • 7
    As far as I know, WPA-PSK is not an effective defense against Firesheep-like attacks. It's my understanding that aircrack-ng can decrypt WPA-PSK encryption, if you capture the initial handshake, which is easy to do. WPA-PSK is not secure against these kinds of attacks and provides a false sense of security.
    – D.W.
    Commented Jan 12, 2011 at 1:47
  • 2
    Also, this answer overlooks the risk of MITM attacks (active attacks). Firesheep currently does not conduct MITM attacks, but it could, and then there can be risks even if the site uses HTTPS exclusively. (e.g., if it does not mark its cookies with the SECURE flag.)
    – D.W.
    Commented Jan 12, 2011 at 2:00
  • 1
    @D.W., thanks - thats why I suggested the original question move from superuser.com to here - this question came from there, not from a "security guy". Btw, when you see bad answers, especially answers that are explicitly WRONG, you should downvote them. That helps float the correct answers to the top and sink the wrong ones.
    – AviD
    Commented Jan 12, 2011 at 2:08
  • 3
    Probably worth noting that it's no longer the case that "encryption/decryption" is cpu intensive. Its important not to perpetuate the myth that CPU load is worth considering when thinking about using HTTPS on all parts of your website. see: istlsfastyet.com
    – Mike Graf
    Commented Oct 8, 2014 at 16:32

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.

  • Invalid certificates is a problem on all types of connection -- not just a public WI-FI hotspot.
    – Richard
    Commented Jan 9, 2011 at 10:56
  • Richard quite right, there's nothing special about public Wi-Fi hotspots regarding certificates. I felt it worth mentioning as it also applies there. A rogue hotspot operator could redirect you to their own webserver using a fraudulent certificate.
    – RedGrittyBrick
    Commented Jan 9, 2011 at 10:59
  • but invalid certs and MITM are much more of a risk on public wifi
    – nealmcb
    Commented Jan 9, 2011 at 14:30

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.

  • 1
    TLS is susceptible to MITM
    – Rory Alsop
    Commented Jan 9, 2011 at 15:55

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.


The connection is quite secure as far is secure connections(ssl) is concerned. Provided, if it is used with awareness:

  • There should be no redirection from HTTPS to HTTP
  • Some sites uses HTTP cmd over HTTPS pages also , there shouldn't be any sensitive info transmitted over that
  • Weak configured https servers and outdated browsers are still exploitable even over secure sockets

The sort answer is, as far as we know, if HTTPS is setup correctly you are secure 99% of the time. That's a big if. Its not as simple as just seeing HTTPS in your browser. SSL-Strip still works on some secure sites/browsers.

Lets not forget that before SSL-Strip, no one thought such a tool could work. Cybersecurity is an ever changing field and a game of whak-a-mole so to speak. A new exploit will come out at some point that lets you do the attack you mention on any site. Look at the "unbreakable" WPA2 standard. Not so unbreakable after all. It will be patched but it doesn't do much for the people hacked before then.

Currently there is a way to decrypt properly configured SSL traffic. It requires gaining access to a CA and issuing fully trusted certificates. Your browser will not detect a MiTm attack using that. The good news is, its extremely hard to pull off.....for now. Using a VPN does not guarantee safety because the VPN itself could be the Mitm attacker.

Basically anything online can and at some point will be hacked. There are things you can do (VPN, updated browser etc) to minimize the risk, but you are never 100% secure. Don't let anyone tell you otherwise.

You must log in to answer this question.

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