0

Excuse me if I am being stupid here but how can HTTPS be any safer than HTTP?

There are a few ways I saw HTTPS working.

  1. The server sends the client an encryption key which the client uses to encrypt the data and then send it back to the server. The server then decrypts with the same key. This can clearly be easily hacked by intercepting the key and the data and decrypting it in the same way as the server.

  2. The client sends the server the key and encrypted data which the server then uses to extract the data. Once again if the packet is sniffed someone can simply decrypt it the same way a server can.

  3. The client encrypts without the data without a key and then decrypts it on the other side. Once again easily intercepted and decrypted.

As far as I can see if the server is communicating with the client then all communications can be intercepted and reverse engineered? Also it cant be a simple one way encryption system as the server also needs to decrypt the data itself.

Thanks

kabeersvohra
  • 1,049
  • 1
  • 14
  • 31
  • 2
    "This can clearly be easily hacked by intercepting the key" not if you don't have [the private key](https://en.wikipedia.org/wiki/Public-key_cryptography) of the server. Which you don't – PeeHaa Aug 05 '15 at 08:50
  • The only real danger (when set up correctly) is the initial request over a non tls connection if people just type in the domain name. This is solved by hsts though – PeeHaa Aug 05 '15 at 08:52
  • 1
    possible duplicate of [how does public key cryptography work](http://stackoverflow.com/questions/2853889/how-does-public-key-cryptography-work) – Quentin Aug 05 '15 at 08:54
  • @PeeHaa surely the client needs some sort of key to encrypt the data before sending it? – kabeersvohra Aug 05 '15 at 09:07
  • Yes the public key not the private key – PeeHaa Aug 05 '15 at 09:07
  • @PeeHaa ah! now I get it, thanks – kabeersvohra Aug 05 '15 at 09:10
  • HTTPS is based on SSL and TLS that use two stages of encryption. At the first stage, the client and the server exchange a symmetric encryption key over a communication channel secured using asymmetric encryption (public-key cryptography). Thereafter, the rest of the communication is secured using symmetric encryption with the key exchanged at stage 1. So, the key can be hijacked only if stage 1 of the exchange is compromised. Although that is not impossible, it is quite difficult to achieve for it to be a common issue. – manish Aug 06 '15 at 04:06
  • @manish That is not correct. The client does not generate the session key; does not encrypt it; and does not send it. It is negotiated via a key agreement protocol. – user207421 Mar 19 '17 at 23:36

1 Answers1

-1

Asymmetrical keys solve almost all of these issues just by one party sending the public key and the other encrypting a symmetrical session key with it and sending it back.

The one major issue left is the man-in-the-middle attack. What stops a hostile router from passing on its own public key instead of the server's public key, then encrypting and decrypting back and forth, reading message traffic both ways, both original parties actually talking to this router when they thought they were talking to each other?

That is solved by digital signatures, whereby each party can prove that communications were produced by it because nobody else has the key to produce that signature. Using https there is no publicly known practical way even your ISP can know what your communications contain, though they do know who you are communicating with.

WDS
  • 966
  • 1
  • 9
  • 17
  • The client does not generate the session key; does not encrypt it; and does not send it. It is negotiated via a key agreement protocol. – user207421 Mar 19 '17 at 23:36