Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

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?

share|improve this question
@AviD Because I didn't know that site exist. –  Calmarius Jan 9 '11 at 12:47
I moved the question here for you @Calmarius and @Avid :-) –  Ivo Flipse Jan 9 '11 at 12:55
(Everyone: was @Ivo correct in moving this question from a site for computer enthusiasts and power users to this site for IT security professionals to discuss vulnerabilities like XSS, buffer overflows, SQL injection, CSRF, clickjacking?) –  Arjan Jan 9 '11 at 13:13
It was @Avid's suggestion @Arjan, if you disagree, you can send it back –  Ivo Flipse Jan 9 '11 at 13:39
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 Jan 10 '11 at 9:37
show 2 more comments

migrated from superuser.com Jan 9 '11 at 12:54

This question came from our site for computer enthusiasts and power users.

9 Answers

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.

share|improve this answer
TLS is susceptible to MITM –  Rory Alsop Jan 9 '11 at 15:55
add comment

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.
share|improve this answer
Oh I forgot that we have asymetric encryption systems. –  Calmarius Jan 9 '11 at 12:49
3. You make sure all of your data actually goes over HTTPS (some sites are partially encrypted and partially not) –  Brendan Long Sep 21 '11 at 2:22
add comment

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.

share|improve this answer
Invalid certificates is a problem on all types of connection -- not just a public WI-FI hotspot. –  Richard Jan 9 '11 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 Jan 9 '11 at 10:59
but invalid certs and MITM are much more of a risk on public wifi –  nealmcb Jan 9 '11 at 14:30
add comment

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

share|improve this answer
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. Jan 12 '11 at 1:47
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. Jan 12 '11 at 2:00
@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 Jan 12 '11 at 2:08
add comment

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

share|improve this answer
add comment

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.

share|improve this answer
add comment

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://google.com/, and click the Gmail link, which redirects you to https://mail.google.com/. Since the original HTTP page is not encrypted, that malicious user can modify your traffic, causing the Gmail link to NOT redirect to HTTPS, but maybe somewhere else. For example, if you clicked the Gmail link on Google's homepage, would you notice that it took you to http://mail.goggle.com/? (as an example). You might, someone else might not.
  • If the user hijacks your connection, but provides his own bogus SSL certificate instead of Google'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.
share|improve this answer
add comment

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.

share|improve this answer
add comment

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).
share|improve this answer
add comment

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.