I did a Wireshark capture of my login into a drupal-based website. The website does not use https. And so, quite obviously, I was able to capture my username and password in plain text by simply using the http.request.method==POST filter in Wireshark.

Then, I tried to access the same web page by manually adding a s to http in the url. Quite naturally, my browser showed this:

enter image description here

Then I went ahead and did my login again, and did the Wireshark capture again.

To my surprise, I do not have the any captures corresponding to the http.request.method==POST filter.

So, my questions:

  1. When I am not really using https, why wasn't I able to capture login id and password in plain text?

  2. What effect did manually adding s to http have?

  • @JustinEthier It exists?
    – pnp
    Commented Oct 12, 2012 at 13:58
  • Sorry, my mistake. Looks like it's been too long since I've used wireshark :( Commented Oct 12, 2012 at 14:02

4 Answers 4


Despite what you may think, you actually were using HTTPS. This is perhaps an over-simplification, but here's more or less what happened:

When you accessed the website with http:// as the protocol in your Address Bar, you effectively told your computer "Make a request for this webpage, from this server, and send that request to port 80 on the server". If the server is configured to allow access via plain HTTP (apparently, it was), the server will respond and your session (unless re-directed) will continue over HTTP.

By changing the protocol to https://, you instead directed your computer to attempt an SSL/TLS handshake via port 443 on the server and then send the HTTP requests through that tunnel. Obviously, this worked or you would not have been able to access the page. Since the SSL/TLS connection was successful, that meant that all subsequent HTTP requests sent through that tunnel would be secured from casual eavesdropping (e.g.: via Wireshark).

But now, you ask, what about that nasty red slash through https, and the "x" on the lock? These indicators do not mean that the SSL/TLS connection was unsuccessful, or that your communications to the website are not encrypted. All these negative indicators mean is that the website is not signed by an authority your browser recognizes. This is often the case for the web interfaces on SOHO networked equipment, business applications, or websites where the administrator has chosen to use a self-signed certificate instead of purchasing one from a well-recognized authority (e.g.: VeriSign).

This is analogous in some ways to selling alcohol in a jurisdiction where such sales are age-restricted. Since I don't know all the intricacies of the real-world laws, let's say for the sake of argument that the law only goes so far as to say it is illegal to sell alcohol to a person who is younger than a given age. What the law in this hypothetical case does not specify is whether you are required to check I.D. prior to a sale, or which forms of I.D. are considered to be valid proofs of age at time of sale. Authoritative proof of the buyer's age is only ultimately required in court if the legality of the sale is ever challenged. However, it is still of course a good idea to check I.D.s on every sale just to be safe.

Here, you are a clerk at a convenience store in the great state of Comodo. Most of your customers will be fellow Comodoans, and so you are naturally able to easily recognize and verify their I.D.s which are issued by the Comodo Government.

One day though, you get a customer from the distant state of VeriSign. What do you do now? Fortunately, your store has a book called Trusted Root Certificates which has pictures and tips on how to verify I.D.s issued from various states in your country. You check your book, compare the customer's I.D. to the relevant photograph and notes, and judge that the I.D. is indeed issued by an authority trusted by your store. Given this, you can now trust that the information on the I.D. (particularly, stating the customers identity and age) is accurate, and therefore be comfortable in knowing that you are making a legal sale.

On another day, a customer comes in from overseas. His name is Drupal, and he hails from the land of DigiNotar. He says he is old enough to buy alcohol, and his DigiNotarian Government I.D. concurs with his statement. However, your Trusted Root Certificates book does not have any information to help you verify an I.D. from his country. What do you do here?

Strictly speaking, by the letter of the law in this hypothetical country, your sale would still be legal if your customer is in fact as old as he says he is. You could choose to assume he is telling the truth and, if he actually is, go on with your life without ever being convicted of any crime related to that action.

But, without any documentation from an authority you recognize, you are still taking the risk that he is not telling the truth. It's very possible that he is not of the proper age, despite what he and his I.D. may claim. In this case, the sale will still be completed. The product will still only be transferred between you and your customer (not immediately available to anyone else, unless your customer chooses to distribute it), but now the problem is that the alcohol has been given to someone who legally should not have it - and you could be in trouble for this.

TL;DR: As long as your browser shows https:// as the protocol, you can be assured that the data in your communications are secured between your computer and some endpoint. If there's any warning signs around that https:// area though, that means that the browser does not trust that endpoint to be what it claims to be. It is then up to you to decide whether you trust the endpoint's claims to identity enough to transfer sensitive data over the connection. The connection is still secure in the sense that nobody between you and the other end of the HTTPS connection can sniff the data, but you are taking the chance that the other end isn't what it claims to be.

UPDATE: Some browsers are now beginning to incorporate checks on the cipher suites and other properties of the HTTPS connection, and providing warnings accordingly. In these cases, the above still applies, but you should be aware that it will be easier for an eavesdropper or Man-in-the-Middle to break that security than if the site used stronger encryption protocols.

  • Note that you can also get free certificates, purchasing one from a company like Verisign isn't needed to make the certificate trusted. The sysadmin either doesn't know this or doesn't care.
    – Luc
    Commented Oct 12, 2012 at 15:33
  • 2
    "As long as your browser shows https:// as the protocol, you can be assured that the data in your communications are secured between your computer and some endpoint." - Not true. If the https is crossed-out due to mixed content, you have no assurance whatsoever. (In any case it's not clear what it would mean to say there's assurance that the communications are secured to "some endpoint", when that endpoint might be the attacker. That's a pretty meaningless thing to assure. There's not really any useful sense in which "the connection is still secure".)
    – D.W.
    Commented Oct 12, 2012 at 15:46
  • 2
    @D.W. That the communication might be getting sent to an attacker is exactly what I was saying by specifically phrasing it to some endpoint. The question asked here isn't whether or not the transmission is going to the right place. It's whether or not it's encrypted.
    – Iszi
    Commented Oct 12, 2012 at 15:59
  • 5
    @D.W. There's also an alcohol sales analogy that's relevant for mixed content: If a group of people walks into the store together, and especially if they all appear to be participating in the purchase decision, you card every single one of them and don't sell unless they've all got good I.D..
    – Iszi
    Commented Oct 12, 2012 at 17:56
  • 1
    Love the alcohol sales analogy! That's absolutely brilliant. I'm going to have to save that one up so I can dig it out at the right moment in the future. Thank you!
    – D.W.
    Commented Oct 12, 2012 at 23:44

You are negotiating ssl/tls, else you would get connection refused ("Oops! Google Chrome could not connect to ...") or connection timed out error ("This webpage is not available Google Chrome could not load the webpage because ... took too long to respond.") or finally SSL protocol error ("SSL connection error").

You are negotiating ssl/tls and encrypting the connection, however the server certificate is not trusted (as it it doesn't know the key belongs to the server) and therefore the connection can not be trusted and so google chrome is marking this as such with a cross on the lock and a slash through the https:// and it would have come up with a "this certificate is not trusted" page and you clicked on the "proceed anyway" button.


That your browser crosses out the https and turns it red, is because the server could not be verified. You might be talking to an attacker's server as well as your own because you don't have a trusted certificate.

However, that the server is not verified does not mean it doesn't encrypt the connection. All traffic is still encrypted, only the browser can't make sure the "password" sent to him by the server (a.k.a. the "public key") was really from your server. When you try to use https and the browser can't setup an encrypted channel, it would simply have rejected connecting, giving you one of the errors @ewanm89 mentioned.

So Wireshark has no idea what's going on over this https connection. Because it's port 443, Wireshark can do a guess that it's encrypted HTTP traffic, but it can't actually tell.

To learn more about SSL (the technique behind https), see this question: How does SSL/TLS work?


The most likely explanation is that the server's certificate is not signed by a CA ("not trusted"), as others have said.

However, there is another potential explanation: it is possible this could be due to "mixed content". If you have a HTTPS page that includes Javascript (or possibly images) from a HTTP source, then the browser will still display the page, but the browser will refuse to trust the page as secure and will indicate the problem in some way, such as by crossing out the https in the address bar. This is because there are a number of attacks when you use "mixed content", so such pages really should not be treated the same as a page that uses only HTTPS (the use of HTTP resources effectively undermines the protection provided by HTTPS).

  • It'll show grey https with a yellow warning icon on mixed content. But yeah I guess non-tech people wouldn't know and ask the same question as is asked now.
    – Luc
    Commented Oct 12, 2012 at 15:48
  • I checked chrome's error conditions straight after seeing the screenshot before writing out my answer.
    – ewanm89
    Commented Oct 12, 2012 at 17:51
  • Although mixed content is not my case (since I know what I was accessing), your answer adds good value from another point of view not much touched by others. +1. Thanks
    – pnp
    Commented Oct 13, 2012 at 10:11

You must log in to answer this question.

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