legal contact rss


This is still under construction as I have only limited time...

So please be patient and come back soon.

openssl bug history

can be found here.

Transport Layer Security (TLS)

As per wiki:

Transport Layer Security (TLS) and its predecessor, Secure Sockets Layer (SSL), are cryptographic protocols designed to provide communications security over a computer network. They use X.509 certificates and hence asymmetric cryptography to authenticate the counterpart with whom they are communicating, and to negotiate asymmetric session key. This session key is then used to encrypt data flowing between the parties. This allows for data/message confidentiality, and message authentication codes for message integrity and as a by-product, message authentication. Several versions of the protocols are in widespread use in applications such as web browsingelectronic mailInternet faxinginstant messaging, and voice-over-IP (VoIP).


In short:

TLS provides us with a secure communication to fight against:

  • Someone is reading (or changing) what we are sending/receiving with our counterpart.
  • Someone is acting as the legitimate counterpart


How is this done:

Client Action Server
1. -> Client send a message to the server "Hi there, I'd like to setup an encrypted session. These are the cipher suites and the SSL/TLS version I'm able to use.

Nice to meet you. Let's use this particular cipher from your list.

Also let's use this version of TLS from your list and we are good.

3. Now here is my certificate AND my public key, so you can verify I'm really the one you want to talk to and you can decrypt my further messages. <-
4. -> The client verifys the certificate if the "common name" matches the URL (or domain part of it) If this doesn't match, you'll get one of the well known warning in your browser.
5. -> The client uses the servers public and hi private key to create a "pre-master key" and sends it to the server.
6. The server uses its private key to decrypt the pre-master key. <-
7. -> Client and server now both use this pre-master key to compute a shared secret key, called the "shared secret" <-
8. -> The client send an encryted message. "Hey there, here is an encrypted message. Try to decrypt it and verify thas it's according to our agreed specs. Also note, everything I send from here on will be done using our agreed "shared secret".

The server decrypts and verifies the message. If that works out, he send back a message saying: "Cool, it's working. Here is an encrypted message too. Decrypt it and verify at yourself.

Myself will encrypt everything from now on to you as well.

10.   The client and the server have now have the same shared secret to protect their communication  <->


Intresting steps


Certificate verification first tries to search through the locally stored certificates. Only if no match is found, the online CA is contacted.

Reasons for failing the validation of  the certificates can be:

    • The "common name" of the cert does not match the FQN in the request.
    • The signing CA is not in your trusted CA's list and can not be reached online.
    • The valid time of the cert has been passed.

The more interesting part of step -4- is, why the verification is NOT failing although the certificate is invalid... Read more on that at my CVE-2015-1793.