Today I was exploring a website used for keeping track of student grades and everything related to school. Basically like a school progress tracker for your child which is used by 90% of schools in my country.

I fired up Charles proxy and connected my phone to it and installed Charles's root certificate so I can use https (the site uses it). Anyway, I logged into the site and checked what Charles captured.

It captured a simple ajax call with 4 fields containing all the login credentials. Here's a screenshot:

enter image description here

Everything is even labeled - uporabnik means "user" and geslo means "password" So if I am understanding this correctly (I am really really just a beginner), everyone that manages to capture this can look at it?

Is this only possible with a proxy or can wireshark for example also do this and just capture packets over wifi?

Are my assumptions true and if they are, what should I do about it?

  • 8
    But how would anyone capture this without installing the root certificate on your phone first?
    – Luc
    May 17 '19 at 13:15
  • 42
    Protip: If you censor an url, do it right. It's pretty easy to deduct what the URL is.
    – MechMK1
    May 17 '19 at 13:16
  • @Luc Oh, I see what you mean. Im really gonna have to look into how Charles works. Haven't tought about it that way. I guess it is safe then.
    – user208234
    May 17 '19 at 13:16
  • @MechMK1 got it. Was in a hurry, sorry.
    – user208234
    May 17 '19 at 13:17
  • 4
    note that you can view the same info with the browser's built-in developer tools.
    – dandavis
    May 17 '19 at 18:10

You seem to fundamentally misunderstand what TLS does.

TLS takes the regular plain HTTP traffic and encrypts it and adds integrity checks. Together with the certificate of the server, this ensures

  • Confidentiality: An attacker who captures the network traffic can not read the content of the communication.
  • Integrity: If an attacker modifies the network traffic, this would result in errors.
  • Authenticity: You can be sure that your communication partner is the server you think you communicate with. (We get to this in a second.)

If you were to look at the underlying HTTP communication, you would see your username and password in plain text, because this is what you have sent to the server.

What does the proxy do now?

If you use a TLS Proxy such as Charles, you essentially communicate with the proxy and the proxy communicates with the web server. So what stops an attacker from just using a TLS proxy? The certificate!

When you installed the TLS Proxy, the proxy generated a new CA-certificate, which you then imported. This means you gave the proxy the authority to create a certificate for any domain. For the purpose of being a proxy, this is fine.

An attacker however would have to make you import their certificate (or steal the private key of yours!) so you would trust certificates by their proxy.

So, is this an issue now?

No, it's not. Everything is working as it's supposed to. At the end of the day, when you send your username and password to a website, it somehow has to actually reach that website.

  • 4
    @JohnDvorak Certificates are unique per installation. If I use a proxy, that does not make me vulnerable to other people using the same proxy, as their keys will differ from mine.
    – MechMK1
    May 17 '19 at 13:51
  • 2
    Thank you. I completely understand now.
    – user208234
    May 17 '19 at 13:51
  • 4
    @MechMK1 Well, at least they should be unique per installation. Of course people managed to mess even this simple thing up, so be careful about what certificates you import. arstechnica.com/information-technology/2015/02/… May 17 '19 at 14:21
  • 3
    when you send your username and password to a website, it somehow has to actually reach that website. unless you use an authentication scheme like SQRL May 17 '19 at 16:19
  • 1
    @jpmc26 Sorry I meant the "as of v3.10" portion is a bit concerning, because it leads me to wonder what previous versions did and whether they used a static root certificate that was shared between installations. 3.10 should be quite old though, so perhaps any such certificate has expired. May 18 '19 at 23:15

How do you think most web sites handles login? By sending usernames and passwords in POST data and recognizing the logged in user with session cookies afterwards. There's no reason for hashing the credentials client side, and even less to obfuscate the variable names: it would be equally easy to figure out that uporabnik or ugcbuzsq is a variable that carries usernames.

That's why the connection is encrypted using TLS, and that's also why you weren't able to see this information before you installed the Charles proxy's root certificate.

  • 1
    I see. TLS takes care of security so even if I can see the password, others cannot as that would require deeper access in my phone. Thats why the certificate is there
    – user208234
    May 17 '19 at 13:53
  • 1
    @K.Vovk no, that is not why the certificate is there. The certificate allows you to identify whether you are connecting to the server you think you are. For example, if you access www.google.com, your browser will open an encrypted connection to google, but how do you know it is really google and not just a hacker that's impersonating them?
    – fabspro
    May 17 '19 at 15:32
  • 4
    … and that is precisely why you had to install Charles's certificate in the first place to make HTTPS work again. Because Charles is nothing but a man-in-the-middle-attacker in this scenario, and if you didn't install its root certificate, you would get a security warning in your browser, and it would not send the data without warning you. May 17 '19 at 15:43
  • Oooooh, got it. Thank you for your time.
    – user208234
    May 17 '19 at 16:11

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy