28

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?

pnp
  • 1,818
  • 2
  • 26
  • 42

4 Answers4

50

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.

Iszi
  • 26,997
  • 18
  • 98
  • 163
  • 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 Oct 12 '12 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. Oct 12 '12 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 Oct 12 '12 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 Oct 12 '12 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. Oct 12 '12 at 23:44
  • The alcohol sales analogy is awesome! Just say a little more on this, if you so please- "_websites where the administrator has chosen to use a self-signed certificate_...". – pnp Oct 13 '12 at 10:08
  • @pnp What that means is that the SSL certificate on the website is signed (authenticated) by the website owner himself - usually with the same certificate. Strictly speaking, there's nothing wrong with this so long as you trust the website owner and have a way to validate the signing certificate (i.e.: an authenticated copy of the public key). However, browsers usually throw up a signature error on these because the certificate is not signed by a recognized authority already configured in the Trusted Root Certificates store. – Iszi Oct 13 '12 at 20:54
  • On shared hosting, it seems quite common for a HTTPS request to respond with a certificate made out to `snakeoil.dom` signed by the Snake Oil CA. Strangely, browsers don't trust this (not least because the domain name doesn't match), but the connection is still encrypted. – TRiG Nov 07 '12 at 14:42
  • @TRiG If the browser doesn't trust it, an error should be thrown. After the user bypasses the error, then of course the connection will be encrypted. That's what's supposed to happen. The Root Certificates Authority is just a list of certificates that the browser trusts by default - the user can still choose to trust anything outside that list. – Iszi Nov 07 '12 at 15:00
  • @Iszi. Sorry, perhaps I should have put the word *strangely* in italics. – TRiG Nov 07 '12 at 15:02
  • @TRiG What's strange about it? Is Snake Oil in your browser's Trusted Root CA store? If not (as I expect) then it's not strange at all. – Iszi Nov 07 '12 at 15:16
  • @Iszi. Quite. It's not strange. At all. At all at all. I know that. And I'd expect everyone else to know it. So .... I feel I'm not explaining myself well. – TRiG Nov 07 '12 at 15:29
  • @TRiG I'm lost then - are you saying there's something else strange about it, or was your comment about it being strange meant entirely as sarcasm? – Iszi Nov 07 '12 at 15:35
  • let us [continue this discussion in chat](http://chat.stackexchange.com/rooms/6366/discussion-between-trig-and-iszi) – TRiG Nov 07 '12 at 16:26
  • One feedback on the alcohol analogy. If I understand the responses correctly,the browser is the shop while the server is the customer. Would have been easier if there is an example with browser as the customer. –  Jun 11 '14 at 03:40
  • @Manoj Perhaps, but then the analogy breaks down entirely. For most situations (if not all), customers are not legally required to verify anything about the stores they purchase goods from. So it would make no sense for a customer to ask the store for any proof of identification or permit to sell, let alone expect the customer to have some sort of validation document analogous to the Trusted Root Certificates on them at all times. – Iszi Jun 11 '14 at 14:22
  • There are other possible reasons for the red strike-through, e.g., wrong server name or expired certificate. – musiKk Feb 25 '15 at 10:18
  • @musiKk "Wrong server name" is a bit more of an obvious reason to turn down an ID in the given analogy. "Expired certificate" perhaps less so, but still a familiar issue to anyone who's sold age-restricted materials before. Once, I actually had to decline an alcohol purchase on the customer's 21st birthday because their ID expired on that same day. The question here isn't so much about how certificates are verified or may be invalid (though I did ramble on a good bit about it) as it is about how HTTPS will still function even with invalid certificates. – Iszi Feb 25 '15 at 14:35
  • @Iszi Yeah well, to be honest I didn't read your analogy. An analogy only gets you so far and usually raises more questions than it answers. My comment only refers to the (small) technical part. – musiKk Feb 25 '15 at 14:43
10

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.

ewanm89
  • 2,043
  • 12
  • 15
8

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?

Luc
  • 31,973
  • 8
  • 71
  • 135
6

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

D.W.
  • 98,420
  • 30
  • 267
  • 572
  • 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 Oct 12 '12 at 15:48
  • I checked chrome's error conditions straight after seeing the screenshot before writing out my answer. – ewanm89 Oct 12 '12 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 Oct 13 '12 at 10:11