2

Reading this answer on stackoverflow, I understand that certificates help identify that a public key and encrypted data are indeed sent by the one we're talking to.

However, the data I send back to the machine I'm talking to is encrypted with my private key. But I don't have a CA-signed certificate. Is a hacker then able to intercept my connection, and replace the data I'm sending with his own encrypted data and include his own public key?

4
  • 1
    Servers can be configured to check the cert of the client, although I can't say how many are configured to do so. The handshake part of the connection starts custom crypto--so it verifies the server and then starts a custom set of crypto. For a hacker to "intercept" they would have to break that crypto--which is very, very unlikely. SHA1 takes thousands of dollars of cloud compute and a few days. So you'd have to have a long connection and someone very motivated. They could just try and "impersonate" you with a new connection... but we use username/pass to avoid this on most sites.
    – bashCypher
    Commented Aug 20, 2018 at 16:40
  • since most are probably not (and I don't have a cert), doesn't that undermine the whole concept of HTTPS?
    – bluppfisk
    Commented Aug 20, 2018 at 16:44
  • 1
    You don't have a cert? Unlikely. Check here: comodo.com/support/products/authentication_certs/setup/… And no, if you can verify who you are talking to-- and it's a system waiting around to talk to you, why does that break anything? Again client validation is handled with user/pass or other 2 factor. Verifying server means we aren't giving creds to bad guys.
    – bashCypher
    Commented Aug 20, 2018 at 16:46
  • 1
    ok your edit and irfan's answer below clarify. It's not public key cryptography anymore once the session has been established!
    – bluppfisk
    Commented Aug 20, 2018 at 16:54

1 Answer 1

2

The data you send back is not encrypted with your private key. You randomly generate a session key (used for symmetric encryption), which you send to the server, encrypted with the server's public key.

1
  • 2
    "...encrypted with the server's public key..." - this is only true for RSA key exchange which is considered obsolete. With Diffie-Hellmann key exchange instead the key for symmetric encryption is computed at client and server based on information from client and server and the servers public and private key are only used to make sure that one is talking with the expected server, but not for key transfer. Anyway, you are right that in no case the data are encrypted with a private key of the client. Commented Aug 20, 2018 at 17:33

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .