A Web of Trust    



We see them every day as we surf the public Internet. This little lock icon shows up in different positions depending on the browser used, to provide you with assurance that the site you are visiting is secure.

And this is almost true - but what the lock is actually showing you is that the communication channel between you and the site is secure.

First let’s examine what the little lock represents. The lock indicates that the SSL/TLS certificate has the following qualities:
  1. The certificate comes from a server whose name matches the name listed in the certificate
  2. The time and date range on the certificate are accurate
  3. The issuer of the certificate is trusted
If any one of these three qualities is not true, then you will be presented with a certificate error. Today we are looking at the final quality in order to provide a better understanding of the web of trust.

First let us look at a certificate. You can examine one of your own, try your online banking site. Just go to a secured website and double click on the little lock.

On the certificate, you will see three pieces of information.
  1. Issued to:
  2. Issued by:
  3. Valid from _____ to _____.
These match the qualities mentioned above. If you are looking at a certificate, select the Details tab to see what else you get. Another important item of note is the button ‘Install Certificate…”, we will return to this later on. How it all works
When you go to a site which has a certificate bound to it, the following happens:
  1. The client, typically a web browser, sends to the server the encryption type, and some random characters for the encryption process.
  2. The web server sends the certificate and its own random string of characters to be used for the encryption process. Included here is the servers ‘public key’ (The public would have been found under the Details tab if you looked)
  3. Upon receipt of the certificate your workstation examines the 3 criteria -
    a. There is a check to see that the requested URL matches the “Issued To”
    b. There is a check to see that the date range is valid
    c. There is a check to see that the “issued by” is trusted (“issued by” is used as insurance against a ‘man in the middle attack’)
  4. If all of these checks pass then a the client generates a premaster secret which it will use for the rest of the session, this is sent off to the server along with the servers ‘public key’ thus creating a “master secret”
  5. With the master secret in place both the browser and server not only communicate through a unique encrypted tunnel, but they can verify that the data sent over the tunnel can not be tampered with.
Okay, now what?
Those of you who have purchased certificates (typically from Verisign, Thawte or Entrust) have seen the kind of pricing associated with them. The cost of certificates may have deterred you in the past from properly securing sensitive data on your network, or more importantly with your Intra-net environment.

We now return back to that “Install certificate” button. You can be your own Certificate Authority (CA) just like Verisign and the rest of them. But, there is a catch. Your computer comes with a series of preinstalled certificates. These are the ‘root’ certificates and come from Verisign, Thawte, Entrust and others. Your workstation does not know about the ‘root’ certificate from your own CA.

Please read the documentation for the server you are running about setting it up as a CA; you then issue the certificate request, as you would if you were paying Verisign and you are almost done. Distribute and install the ‘root’ certificate from your CA to the clients and there you go, free secure communications. If you are working with computers out side your Organization, you may wish to purchase a certificate from one of the providers, there are options and I highly recommend you look into them. There are security requirements vs. economies of scale issues here. After all, we are all watching the bottom line.

More Information...
Man-in-the-middle attacks occur when the communication is intercepted en route. This is where an unauthorized program sends its own certificate back to the client and makes a client request to the server. Rather than the client and server validating with each other, they validate with the unauthorized program.

Originally published May 2008
Republished: June 2008 in TLOMA Today


PDF this Page
Fragment - Current Release


Articles
Administration

IT Roles and Responsibilities
App_Sec
BCP STATS
On Passwords
Spending Enough
Planning to Fail
Living With the Enemy
A Reason for Policy
Mission Critical Messaging – Do you have a policy
Globalizing the SMB
High Availability: People and Processes
Case for Project Management
Risk Management
Networking

On Routing
VLAN Tutorial
IPs 4 Golden Rules
WAN Technology primer
DHCP Primer
Your Head in the Cloud(s)
DNS: Terms and Process
VPN Surfing Challenge
Network Slowdown
Importance of Time
High Availability: Technologies
Security

Spammers Go Full Circle
Beyond the Lock
The Guardian at the Gate
A Web of Trust
Data Breach Notification
Misc

Electricity Primer
Documentation-101
Data Control
Open Source in the Enterprise
Closing the Loop
Helping IT to help you
Your ICT Keystone

eSubnet Services

Contact us regarding your network,
security and Internet services needs




All content © eSubnet 2003-2017
ESUBNET ENTERPRISES INC. TORONTO CANADA