TLS handshake

Written on 12 February 2015, 09:59pm

Tagged with: , ,

The initial communication in a HTTPS connection relies on a traditional D-H key exchange – which will serve as symmetric encryption key for the rest of the HTTPS conversation.
The outline of the handshake is:
– client/server hello: list the available encryption algorithms
– certificate exchange
– certificate validation
– key exchange
– finished

Here is the process explained in layman words:

1. Client sends a Client hello message to the server with some metadata (TLS version, cipher algorithms, compression methods)
2. The server replies with a Server hello message to the client with the corresponding metadata + the Server public certificate signed by a CA.
3. The client verifies the server digital certificate and cipher a symmetric cryptography key using an asymmetric cryptography algorithm, attaching the server public key and an encrypted message for verification purposes.
4. The server decrypts the key using its private key and decrypts the verification message with it, then replies with the verification message decrypted and signed with its private key
5. The client confirm the server identity, cipher the agreed key and sends a finished message to the server, attaching the encrypted agreed key.
6. The server sends a finished message to the client, encrypted with the agreed key.
From now on the TLS session communicates information encrypted with the agreed key
https://github.com/alex/what-happens-when

The same process – explained in full details.

Note: Excepting the initial TLS handshake, the other HTTPS content (headers + payload) is encrypted with the key agreed during the TLS handshake.

Understanding more about hashing

Written on 11 February 2015, 11:21pm

Tagged with: , ,

Brute force vs dictionary attack vs rainbow tables

Brute force: least efficient, tries all the possible values.
Dictionary attack: tries a predefined list of values
Rainbow tables: contain pre-computed hashed values. If a single salt per db is used, then the pre-computed hashed values have to be updated (to include the salt). If a single salt per password is used, then the pre-computed hashed values have to be updated for each password.
More here.
Note: rainbow table can only be used if the hashed values are available.

Hashing properties

1. Collision resistance: it should not be realistically possible to find two messages giving the same hash
2. Pre-image resistance: given the hash, it should not be realistically possible to obtain the message (we ask an adversary, given only H(m), to find m or some m′ such that H(m′) = H(m) )
3. Second pre-image resistance: given both the hash and the message, it should not be realistically possible to obtain another message with the same hash.
More here and here

Remember:
Hashing is not compression (you can’t go back to the original string)
Hashing is not encryption (for encryption you need a key)

What are you hashing

– not sensible data: use MD5/SHA family of hashing functions
– sensible data (like passwords): PBKDF2 (*), bcrypt or scrypt

Key derivation

This is about transforming a password into a key that can be used for encryption. Think about encrypting a file with a password.

The output of a password hashing function is acceptable as a symmetric key, after possible truncation to the required size.
link
LastPass utilizes the PBKDF2 function implemented with SHA-256 to turn your master password into your encryption key.
LastPass user manual

(*) PBKDF2 is in fact a Key derivation function, not a hashing function.

Digital certificates

Written on 9 February 2015, 09:33pm

Tagged with: , ,

TL;DR:
A digital certificate binds an individual’s identity to its public key; it proves the ownership of a public key.
Digital certificates are used in Asymmetric encryption and are part of the PKI (Publick Key Infrastructure)

Class of certificates (this might differ according to the issuer):
class 1: individual (email + domain verification)
class 2: software developer (physical ID verification)
class 3: company (face to face verification)

Creation, storage and distribution of digital certificate
CA – Certificate Authority – issues and verifies the digital certificates
RA – Registration Authority – verifies the identity of users requesting a digital certificate

The RA verifies the identity of the certificate requestor on behalf of the CA.
The CA generates the certificate using information forwarded by RA

Root certificate
All web browsers come with an extensive built-in list of trusted root certificates.
certificate root

X.509 is a standard – for the structure of the digital certificate

Types of certificates
A certificate provider can opt to issue three types of certificates, each requiring its own degree of vetting rigor. In order of increasing rigor (and naturally, cost) they are:
– Domain Validation
– Organization Validation and
– Extended Validation ->Activates the green address bar :)

ev-ssl-browser-bar-safari

ExtendedSSL is an Extended Validation Certificate, the highest class of SSL available today.

ExtendedSSL activates the green address bar and displays your organization name in the browser interface. These prominent security indicators increase user trust in your website and increase its credibility, leading to more sales conversions.
From €679/year
https://www.globalsign.com/en/ssl/ev-ssl/

Digital certificates can also be used for client authentication.
client authentication
You can install a certificate in the browser and authenticate with it on certain websites. However, it is your responsibility that no one else gets physical access to your workstation (3rd law of security).
More about this