Chris Pollett > Students > Akash

    (Print View)

    [Bio]

    [Project Blog]

    [CS297_Proposal]

    [PFS_Presentation - PDF]

    [PFS_Checker(PHP Script)]

    [Tor_HiddenService - PDF]

    [Tor_Network - PDF]

    [Zero_Knowledge_Proof - PDF]

    [Tor - Yioop Patch]

    [CS297_Report - PDF]

    [CS298_Proposal]

    [CS298_Presentation - PDF]

    [CS298_Report - PDF]

                          

























PFS Checker

Perfect Forward Secrecy (PFS) is a property of the key-agreement protocol that ensures that the session key used to encrypt the data will not be compromised even if in the future long term private key is compromised. The idea is not to use a single key (e.g. private key) to generate all the session keys. Why do we need to use perfect forward secrecy? In order to understand that, it is helpful to have a basic idea of how HTTPS works in general. When we access a secure website, it uses HTTPS protocol to make the connections. All HTTPS connections are not equal. Once connection is established, Bowser generates a session key from the private key and encrypts the data using a session key. An interceptor can intercept all the communication messages. An interceptor does not know the private key of the client (browser), so the interceptor cannot derive the session key. Thus an interceptor cannot decrypt the messages but can still store all the communication messages. Later on, if interceptor can somehow obtain a client's private key, one can derive the session key and decrypt all the stored messages. The main problem here is that a private key is used for two purposes: authentication and encryption. Authentication only matters while the communication is established, but encryption is expected to last for years. This situation is the motivation factor for the perfect forward secrecy.

In PFS, the client (browser) periodically creates a new session key based on values supplied by both parties in the exchange. Because both parties contribute a random value known only to them, each new key generated is dissimilar to previously created keys. Even if a third party managed to intercept a private key, the third party can only derive the session key for a very small duration.

The session key is a key factor to determine whether a connection has perfect forward secrecy or not. The Transport Layer Security (TLS) Handshake Protocol is responsible for the authentication and key exchange necessary to establish a secure connection. To establish a secure connection, TLS protocol needs to do three things: cipher suite negotiation, authentication of server and key exchange. How the session key is derived is determined by the cipher suite in use. In the beginning of SSL handshake, the client sends a list of supported cipher suites. The server then picks one of the cipher suites, based on a ranking and informs the client which cipher suite will be used from onwards communication. This step determines if future connections will have perfect forward secrecy or not. Cipher suites that use ephemeral Diffie-Hellman (DHE) or the elliptic-curve variant (ECDHE) have perfect forward secrecy.

The purpose of this PHP Script is to check whether web site supports perfect forward secrecy.