-3

I know that it is very easy to steal a username and password from someone who is signing in to some website over HTTP, but we protect against that with just SSL/TLS. ​ How's that possible?

I mean, when I log in to some non-HTTPS website and I am a victim of a MitM, my username and password are completely revealed to the attacker. But when I log in to a secure website like Facebook, GMail etc., I am safe. ​ How is that possible?

Xander
  • 35,525
  • 27
  • 113
  • 141
ShinobiUltra
  • 782
  • 7
  • 16
  • 3
    you first need to know how the attacker sees your password on a not-https website - do you understand that point? – schroeder Nov 17 '15 at 17:31
  • @Xander - While I don't disagree that the answer to that question answers this question too, I think that that question's answers are more technical than is appropriate for this question. – Neil Smithline Nov 17 '15 at 21:55
  • Perhaps this is a more apropos question [Does using HTTPS, TLS, S/MIME, SSL e.t.c. protect you from Deep Packet Inspection and 'Big Data' analytics?](https://security.stackexchange.com/questions/20814/does-using-https-tls-s-mime-ssl-e-t-c-protect-you-from-deep-packet-inspectio)? Hard to be sure what is appropriate for the questioner. – Neil Smithline Nov 17 '15 at 21:59

2 Answers2

3

One of the key elements here is the concept of public and private key pairs. The idea being that each computer, or In some cases, computer system, has its own set of two keys: each one of which is effectively worthless without the other. There is a public key, which is sent to everyone in the web server's certificate, and the private key which is only stored by the web server itself. Thus, your computer has the public key of the server and can then use it.

A document or a set of web communications (like exchanging a password), can be encoded with the public key of the server. Once done, no one without the corresponding private key can read that file. Since only the web server has that, only it can read your password.

In reference to the comments below, to clarify, here is a highly simplified version of the process:

  1. Your browser gets the public key from the web server when it sends you its certificate.
  2. Your browser then generates a new encryption key that is used for future communications with the web server. (This different key is called a symmetrical key and is used instead of the public private key pairs due to the computational horsepower that is necessary to use the public private key encryption.)
  3. Your browser sends that new symmetrical key to the server after encrypting it with the server's public key.
  4. The server and your browser then use that new symmetrical key to send and receive data including your password.

In addition, your web browser COULD have its own certificate: enabling your own browser to have its own private and public key. This can provide additional security to the server especially in ascertaining that you're who you say you are. However, as mentioned below, this is not common.

Boom. Two way, more secure communications. Nothing's perfect, but public key cryptography is a great step in ensuring privacy and security from digital crime.

Darkstar
  • 216
  • 1
  • 3
  • You're actually wrong about a couple things here. 1) computers are not restricted to 1 pair of keys nor do they all have public/private keys already. For webservers configured to use SSL they generally have 1 for HTTPS traffic but this generalization is wrong to all machines. – d0nut Nov 17 '15 at 22:26
  • 2) *"A document or a set of web communications (like exchanging a password), can be encoded with the public key of the server"*. Can it? Depends. If the message is too long, RSA is out of the question. Additionally, TLS does **not** do this. RSA is generally used only when sending a symmetric key. All further encryption is then done with a symmetric key cipher like AES256. – d0nut Nov 17 '15 at 22:27
  • There is such a thing as being too precise. I specifically left out that public keys are only usually used to exchange the initial symmetric key due to overhead and that machines other than a web server might be configured differently. The reason being that it can be confusing to those just wanting to know how things work in a very simplified fashion. You are correct in the specifics, but going to that level of detail didn't seem necessary here. Teach a person how to drive in a parking lot before you put them on the freeway... – Darkstar Nov 17 '15 at 22:31
  • 3) *"your own browser also has its own private and public key"*.. not true. Unless the server specifically requests a certificate from the client (which is not standard, by the way) the client doesn't send any public keys. The client will use the public key of the server to encrypt the key for the symmetric cipher that the server and client will then proceed to use for the duration of the session. – d0nut Nov 17 '15 at 22:32
  • The problem i have with your answer isn't that you dumbed it down, it's that when you tried to make it less technical you made it wrong as well. – d0nut Nov 17 '15 at 22:33
  • 1
    I updated the answer to better clarify reality and lessen potential errors. – Darkstar Nov 17 '15 at 22:50
  • I like this more. Still a little weird at spots but the errors are mostly removed. +1 – d0nut Nov 17 '15 at 22:55
2

SSL/TLS does not magically makes everything safe. It only cares about protecting the transport of the data from the client (browser) to the server. Through encryption it makes it (if properly used) impossible to sniff passwords or to manipulate the data. This is important if you are using an untrusted network like a public Wifi hotspot.

SSL/TLS does not help you against malware on your own computer which might hijack the browser and read the data before the encryption happens. It also does not protect the server against hacking nor does it protect against all the vulnerabilities in web applications like Cross Site Scripting, SQL Injection...

SSL/TLS also does not protect against phishing attacks. That a website is reachable by https does not mean that it is trustworthy and it can easily transfer malware over the encrypted protection.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • I understand this but i still need to ask where is problem of decrypting the secure communication made between client and server. I know that SSL/TLS basically encrypt communication between client and server and made the communication look like "random trash" for anyone who would try to hijack the communication. But how is possible that some attacker can not decrypt the "trash" and see the original content ? – ShinobiUltra Nov 17 '15 at 18:15
  • 3
    @ShinobiUltra Do you know how encryption works? It's like a lock box, in order to open it, you need the combination to the lock. With encryption this "combination" is the encryption key, and in SSL/TLS only the client and the server have copies of that key. Anybody listening to the traffic can not decrypt it because they do not have the key. – Mike Ounsworth Nov 17 '15 at 18:40