0

I have studied how SSL/TLS works when we use HTTPS connection. After authentication stage is over, using Diffie–Hellman both client and server share secret session key which is used for encryption/decryption.

I have also read using Wireshark or Fiddler one can decrypt HTTPS traffic in case Server private key is known and when Diffie–Hellman is not used for exchange of secret session key .

I have following doubts with respect to my Linux System -

(1) In case my root/admin password is compromised or my admin becomes untrusted, will the Intruder with root permission / untrusted admin can retrieve Secret Session Key used for HTTPS communication (With Known Server private key) and still able to decrypt the HTTPS traffic?

(2) Can I say with 100% confidence that without Server private key, it is not possible to decrypt HTTPS traffic even for an root/admin user? (This is the reason HTTPS is used).

(3) Is it true, when Diffie-Hellman is used to share Secret Shared Key,the connection is 100% secure , means no tools are available to retrieve decrypted HTTPS traffic?

Any help to clear my doubts or relevant links will be highly appreciated. Thank you in advance.

Improve this question
0

2 Answers 2

Reset to default
1

When SSL handshake starts, the first step is, server is authenticated using a private key associated to the server's certificate.

In a 2nd step, client and server exchange a session key used to encrypt the payload of the connection.

The session key is used for one session means when the session is closed the same key can't be used to encrypt the traffic of another session.

Now the problem is SSL often use RSA cipher suites in which the session key is derived from private key. So the session key can be calculated in future if the underlying private is known.

DHE and ECDHE provides Perfect Forward Secrecy(PFS), means session keys are not derived from private key. So the attacker cannot decrypt the traffic even when he has the private key used in the session handshake.Also Session key is not generated by client & nor derived from private key. Session key is not encrypted/decrypted/transmitted

Improve this answer
2
  • in case Session key is not encrypted then it is stored in somewhere(in memory probably , I am not sure) in normal plaintext, so the admin can read it. Don't you think then entire HTTPS communication become visible to admin ?
    – bholanath
    Jun 1, 2017 at 4:50
  • the session key, is derived from complex mathematical operations carried out on the numbers exchanged between the client and the server, that are too difficult for an attacker to brute force,Even if the attacker managed to compromise this shared secret somehow, it would only compromise that particular session. No previous or future sessions would be compromised.
    – Rupesh
    Jun 1, 2017 at 6:19
1

The answer is it depends, but the general rule is that an admin can read almost everything on his own host. You are right on one point: if the protocol uses DHE, wireshark or any other network analyzer cannot be used to decrypt the network exchanges.

But at one point on the host, the SSL will be decrypted for the server to be able to process requests! Depending on the application, an admin could set the log system to a level logging all the requests with their IP origin. Or it could configure the apache or nginx front server to divert everything to a log file if it is relevant for the server architecture. Or it could add a filter into the web application for extensive logging, if the architecture provides a filtering mechanism. As all that occurs after the SSL decryption, all will be in plain text.

Of course, if the application server does its own SSL processing, and it only exists in compiled form and the evil admin has no knowledge on its configuration or no logging is provided by the full application stack, the admin will only be able to examine the process memory to find interesting parts which is unlikely to be usable. But common architectures do provide configurable logging precisely to allow the admin and developer teams to understand what happens when things go wrong.

So as a general rule, you cannot trust more a server than you can trust his administrators.

Improve this answer

You must log in to answer this question.

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