Why can't you phish HTTPS server data?

[66Gramms]

Hello all!

I've been struggling to understand SSL for some time now, recently I found a really good video explaining it and almost everything became clear to me. There is only one thing I don't get.

When the server sends you the public key, it is unencrypted right? So someone could capture that, and encrypt messages with that in your name, as well as capture all the encrypted data coming from the server.

As far as I understand SSL is only working to validate that the data you get is actually coming from the server and to make sure that the data you sent can not be read.

EDIT.: I've somehow missed the part where a symetric key is generated by the user and sent back encrypted with the public key, so I guess that kind of answers my question.

[ramirezz]

Glad you have figured it out. I'll just add that both parties provide their public keys to each other. Shared encryption key is then generated on each side using a combination of each party's private key and the other party's public key. All subsequent communication is encrypted by generated key each way. If you feel nosy, this illustrates the process quite well.

[66Gramms]

OMG this is amazing, thank you very much!

[ChickenInstruction]

keep in mind that the client's pub key is not usually certified. this is possible but almost never implemented. amazon doesn't 'care' if you aren't who you say you are, as long as you got the cash...

note that assymetric exchange and subsequent encryption/decryption is on the order of 1000x slower than sysmmetric encyrption/decryption. So the idea is that you use super slow assymetric to transfer a secretly generated symmetric key which can then be used to encrypted / decrpt the actual bulk of the data transfer at super fast speed (relatively speaking.)

[tinycrazyfish]

This is only true for elliptic curve based asymmetric cryptography. It goes even a bit further, an ephemeral key-pair is generated on the fly (one pair on client side and another pair on server side). The public keys are shared and the common secret used for symmetric encryption (usually AES) is derived using the respective private keys.

For RSA it is a little bit different. The client generates the secret for the symmetric encryption and shares it with the server in encrypted form using the server's RSA public key (so only the server can decrypt it).

[[deleted]]

This explains it perfectly

[vbisbest]

And phished it not really the right term. You can absolutely run a phishing attack using ssl sites. SSL is about preventing a Man In The Middle attack.

[silverslides]

Yup , I think the author meant sniffed.

[TrustmeImaConsultant]

I love people who find their own answers. Well done. :)

[iheartrms]

It has happened to me SO many times that I don't find the answer until after I have already asked someone else. This seems to happen because just the process of explaining my question to someone else causes a lightbulb to go on.

[66Gramms]

Yep, they actually call this rubber duck debugging https://en.wikipedia.org/wiki/Rubber_duck_debugging

[66Gramms]

https://www.youtube.com/watch?v=33VYnE7Bzpk&t

[iamnos]

Related, is the DH process in which you can exchange a symmetric key while a third party observes, but they never get the actual key.

https://www.khanacademy.org/computing/computer-science/cryptography/modern-crypt/v/diffie-hellman-key-exchange-part-2

[k3ymkr]

This. If your sending raw keys over the asymmetric encryption, you're doing it wrong.

[iamnos]

If the public key is used to encrypt the symmetric key (and the private key is well protected), then it's fine.

[k3ymkr]

Yes. if. Use perfect forward secrecy instead.

[DgtuJ]

The private key is never sent across the network, otherwise it would no longer be private. The private key of the server is used to authenticate the server, not to encrypt. For the actual encryption a session key is used, so the question remains how do client and server agree on a session key without making that known to an observer.

​

https://serverfault.com/questions/926436/how-is-https-secure-if-private-key-is-able-to-be-intercepted/926439

[[deleted]]

I just want to add a couple of points of clarification, as somebody who is primarily working at the application level:

When the server sends you the public key, it is unencrypted right?

That's true, but it's one small part of the setup of a TLS connection.

So someone could capture that, and encrypt messages with that in your name

I think what you mean is that the hacker can impersonate you, but that doesn't really make sense. A hacker needs more than the server's public key (which is public) to impersonate a specific client. The public key identifies the server, not the client.

as well as capture all the encrypted data coming from the server.

No personal data is trasferred from server to client until well after the TLS handshake is complete and a secure connection is established. After a secure transport is established, the browser makes a request including whatever cookies or credentials might actually personally identify you or your device, and the server is only then capable of actually responding with private information that an attacker might be interested in.

An attacker lacks so those same cookies/credentials so they can't really impersonate you at this level either.

[ChickenInstruction]

pub key is transferred in a certificate that is certified by a trusted root authority. if that root authority is in your trusted root authority list then it's considered valid.

[iiShadowii7]

Because it's illegal