Etydhv

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:

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?

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.

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.