Category Archives: SSL

SSL Exploration and Analysis

Posted on November 25, 2010 | Leave a comment

During the recent investigation of certificates and SSL, a co-worker (Ola) forwarded a web link about an organization that is analyzing web SSL certificates.  The information was very relevant and interesting.

The EFF SSL Observatory


Quote from site:

The EFF SSL Observatory is a project to investigate the certificates used to secure all of the sites encrypted with HTTPS on the Web. We have downloaded a dataset of all of the publicly-visible SSL certificates, and will be making that data available to the research community in the near future.

 

The best way to get started is by looking at the slide deck.  The overall summary indicates that things need to tighten up quite a bit to provide a more secure environment.  It is too easy to make mistakes and open security holes.  The philosophy of exposure reminds me of the work done by W. Richard Stevens for TCP/IP many years ago.  The more an item is explored, the more likely its vulnerabilities and flaws will be seen.

This post resulted from cleaning up the inbox and realizing that this information was valuable enough to share.

→ Leave a comment

Posted in Certificates, SSL

Tagged , ,

SSL Handshake

Posted on September 8, 2010 | Leave a comment

How do you exchange secrets without knowing the codes to use?  Typically it is a recursive kind of problem.  With the classic mode of symmetric encryption keys, it is necessary to magically transport the key to the other side.  This would often entail using a secure non-digital technique like carrying it there.

In the web, this is impractical and would hinder the use of encryption.  Thank goodness for PKI with its ability to keep the key secret while still enabling everyone to form secure communication with the owner of that key.

Years ago I researched what was necessary to support SSL with one of our products.  It was an interesting technology to study and it was impressive how effective it was.  The modern name is supposed to be TLS but it does not seem to be sticking in the market as a name.  To me, SSL sounds better.

Today I found an old Sun page talking about SSL Handshake.  It is funny how the older pages reveal more detail than the newer ones.  Perhaps we had more time to focus on it back then.

Some items that are often forgotten about:

  • It is possible to support client certificates to authenticate the user
  • The encryption used for the bulk of SSL data is actually symmetric key based (negotiated during initial handshake)
  • The client and server negotiate the type of encryption algorithm used
  • SSL was pioneered by Netscape around 1995

Here is another description of the SSL handshake from IBM.

If you would like to learn more about SSL/TLS, please review the TLS 1.2 RFC 5246.

From the RFC:

The TLS Handshake Protocol involves the following steps:

   -  Exchange hello messages to agree on algorithms, exchange random
      values, and check for session resumption.

   -  Exchange the necessary cryptographic parameters to allow the
      client and server to agree on a premaster secret.

   -  Exchange certificates and cryptographic information to allow the
      client and server to authenticate themselves.

   -  Generate a master secret from the premaster secret and exchanged
      random values.

   -  Provide security parameters to the record layer.

   -  Allow the client and server to verify that their peer has
      calculated the same security parameters and that the handshake
      occurred without tampering by an attacker.

So much traffic on the Internet is based on HTTPS which in turn is dependent on SSL/TLS. If fact, it is largely this technology which has enabled doing business on the web.

→ Leave a comment

Posted in SSL

Tagged

Digital Certificates (part 1 of 2)

Posted on September 7, 2010 | Leave a comment

This post will explore digital certificates.  Consider this as a result of a need to learn more detail about how certificates work.

Start here:

  1. VeriSign: Introduction to Digital Certificates
  2. VeriSign: Introduction to Public Key Cryptography

Paraphrasing:

Cryptography solves many key computer issues (like identification).  Traditional security based on physical devices is useless in the digital world.   In order to protect information and identity, complex algorithms are needed to hide the content and user.

Early generation encryption solved the problem but had a big problem with how far it could transfer its secret keys.  It became too difficult and expensive to safeguard the symmetric keys.  Beyond this, the key trust required new keys for each new trust relationship.  It also implied prior knowledge of the other person.

Since both parties know the secret key, there is no way to know which of the two parties might have modified content or acted as the other.  The shared key does not indicate identification.  Therefore it can not be used to authenticate.

Public key encryption was first created in the mid 1970′s.  For the first time it was possible to transfer secret data without exposing the secret key.   There are two keys (one public and one private) that do the opposite of each other.  If you use the public key to encrypt, only the private key can decrypt.  Likewise, if data is encrypted using the private key, it can only be decrypted by the public key.

The public key is made widely available for all to use.  The private key is only available to the owner.  SSL uses the public keys of servers to encrypt traffic to the web.  The SSL protocol requests the public key from the server directly as part of its negotiation.

If a user wants to send a private message to another person, they use the public key of that person to encrypt the message.  The recipient uses their private key to decrypt the message.

The power of this is that the public key can be used by anyone and the content sent to the private key owner cannot be decrypted by anyone else (assuming that the encryption is strong enough).

Since only one person owns the private key, it is therefore true that if you decrypt data from the users public key, you can be guaranteed that it came from that person.  This introduces the concept of digital signatures.

Sometimes it is only necessary to prove that someone sent data.  The actual data does not necessarily need to be encrypted but the producer and the consumer want to guarantee that nothing has changed and that the content came from the producer.  This is used extensively in code signing.

The quick summary is that a hash algorithm is run against a section of data and the resulting digest (like SHA1) is encrypted using the private key of the producer.  The consumer receives the data and decrypts the digest and compares this against the digest calculated from the received data.  If they do not match, something has been altered that should not have been.

The problem however is that just because a public key is published it does not necessarily mean that the owner is the person you want to trust.  Someone could send you a public key that actually belongs to someone else.  There is a need to guarantee trust.

Digital certificates are the answer.  Similar in nature to a passport or driver license, they uniquely identify you based on a trusted organisation.    The user’s public key is signed by a certificate authority (think VeriSign) that can vouch for you being a valid user/company.  They only sign public keys they trust through a process of proving identity.  Years ago I needed a certificate for Citrix and had to prove to VeriSign that we were who we said we were.  It can be an extensive process based on the level of verification.

Digital certificates contain a number of data items to help verify identity and trust.  This includes the concept of expiration.  Proof of identity only lasts for a specific time (usually a year).

Certificates can be allocated based on a trust hierarchy.  Trust is relative to the parent which can be mapped to many layers before it gets back to a certificate authority root.  Web browsers have a list of certificate authorities they trust and that is the basis of determining trust with HTTPS sites.  Only trusted CAs are allowed.

More in the next post…

→ Leave a comment

Posted in Certificates, Security, SSL

Tagged , ,